PCI Tips'n'Tricks, part 2 - "PCI DSS March 31st requirements for service providers"

As PCI DSS (and the payment ecosystem altogether) is so heavily leaning towards service providers, there were so many points to raise that I ran out of allowed space to publish this as a post only. :) But here's the complete list of requirements, naturally all service providers need to evaluate whether these are applicable to you operations or not:

3.2.1 Retention policy need to include storage of Sensitive Authentication Data (SAD) before authorization.

3.3.2 SAD stored before authorization must be (strong) encrypted.

3.4.2 Remote access technologies must prevent copy-paste of PAN from all users except specially approved ones.

3.5.1.1 Hashed PAN need to use keyed hash protocol.

3.5.1.2 If disk-level encryption used for protecting PAN, removable media must also be encrypted.

3.6.1.1 CryptoArchitecture need to be documented, including certificates used in untrusted network (4.2.1.1).

5.2.3.1 Technology "not needing malware protection" needs to be re-evaluated with a frequency based on Targeted Risk Analysis (TRA).

5.3.3 Removable drives need to be malware scanned when inserted, or system processes continually monitored.

5.4.1 Automated mechanisms need to be in place to detect and protect against phishing attacks, for example Domain-based Message Authentication, Reporting & Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM).

6.3.2 All third-party libraries need to be listed and covered in vulnerability management (Bill of Materials, BOM).

6.4.2 Automated solution to protect the web-based attacks, either block or alert.

6.4.3 Payment scripts on payment page need to be authorized, integrity-checked and business-justified. Please see PCI DSS Councils write-up on this topic.

7.2.4 All user accounts and applied access privileged are reviewed every 6 months. Management acknowledgement that access remains appropriate.

7.2.5 All system accounts use least privilege and limited to system/application where they need to run.

7.2.5.1 All system accounts reviewed with a frequency defined by TRA, with management acknowledgement that remaining access is appropriate.

8.3.6 If passwords used, need to be 12 character long. Characters & numbers, at least.

8.3.10.1 If passwords used as only authentication vector, changed every 90 days or dynamically analysed for indicators of compromise.

8.4.2 MFA implemented on all access to CDE (and not just administrative as it was before).

8.5.1 MFA not sustainable to replay attacks and cannot be bypassed by any user (even admins).

8.6.1 If system accounts can be used for interactive login, need to be minimized to systems and occasions where needed, justified by business and approved by management. Logging in with system account need to be first authenticated to identifiable user account (audit trail!).

8.6.2 Passwords/passphrases not in scripts (Duh!).

8.6.3 Passwords for application- and system accounts changed with a period defined by TRA. Password complexity must be on par with the TRA evaluation.

10.4.1.1 Log reviews must be automated.

10.4.2.1 All non-critical but still in-scope systems security logs reviewed with frequency from TRA.

10.7.2 and 10.7.3 requirement for (secondary) monitoring the proper function of implemented security controls adds log analysis mechanisms and change-detection mechanisms (FIM) on the list. All deviations must be analysed for root causes and implications, and threated accordingly.

11.3.1.1 Frequency of installing vulnerabilities rated non-critical is decided based on TRA.

11.3.1.2 Internal vulnerability scan performed using authenticated scan. Systems that don't support it need to be documented.

11.5.1.1 IDS systems need to detect covert malware communication channels.

11.6.1 Change- and tamper detection mechanism is deployed to alert on unauthorized changes on HTTP headers content of the payment page. There needs to be a monitoring system in place the actually loads and analyses the payment page and its HTTP headers at least once every 7 days or base on TRA.

12.3.3 Cryptographical cipher suites are documented and evaluated at least every 12 months.

12.3.4 Hardware and software needs to be reviewed and evaluated every 12 months. Are we still using the best possible solutions, are there sunset devices in our environment?

12.5.2.1 PCI DSS Scope needs to be reviewed and confirmed every 6 months.

12.5.3 PCI DSS responsibilities and controls need to be reflected to any significant organisational changes.

12.6.3 Annual awareness training of personnel must include coverage on social engineering and phishing and must contain refreshers on Acceptable use Policy. The last one in practice means that people need to be reminded how to use, and how not to use company assets. This is often taught to people on day 1 but not reminded on annual basis. Reminding of them ever now and then is a good practice.

12.10.4.1 Personnel appointed with incident response duties must be trained with a frequency defined by TRA, to confirm they know what to do if/when needed.

Incident response plan needs to include pointers that detection of unauthorized wireless access points (or NIC's), change management alerts of critical files / anything related to payment pages need to trigger IR investigation (12.10.5) as well as finding any PAN data on any unexpected locations (12.10.7).

Anything that makes you think "what on earth does that mean in practice", do let me know! :) Let's work on it together. This is what we do.