On Friday, April 15, 2016 while a lot of you were probably getting your US income taxes done, the PCI SSC decided to release the draft of v3.2 of the PCI DSS. I know the announcement message to me from the Council ended up in my company’s spam filter, so you may want to check there if you did not receive a message. I was lucky enough for a colleague to forward his copy along to me. However to get the draft, you need access to the PCI Portal to obtain the draft PCI DSS v3.2 and the requisite change log.
These are some of the more notable changes in the new PCI DSS version.
- The draft provides an official sunset date for v3.1 of the PCI DSS. Regardless of the date in April that v3.2 is released, v3.1 will be withdrawn on October 31, 2016. So any assessments done after that date will need to comply with and use v3.2.
- Two new sections to Appendix A have been added. In addition to the Appendix for shared hosting providers (now marked A.1), we get Appendices A.2 and A.3. 2 covers SSL and early TLS for those of you that will miss the June 30, 2016 date. For those of you that thought 2018 was the deadline and missed discussions on the Webinar about the SSL/early TLS deadline, while the deadline was extended to June 30, 2018, any organizations missing the June 30, 2016 date must fill out Appendix A.2. A.3 is where the Council added the designated entities supplemental validation (DESV) requirements.
- There are a number of new requirements for service providers that are best practices until February 1, 2018. Those new requirements include: (1) maintain a documented description of the cryptographic architecture, (2) detect and report on failures of critical security control systems, (3) perform penetration testing on segmentation controls at least every six months, (4) executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program, and (5) perform reviews at least quarterly, to confirm personnel are following security policies and operational procedures. I would bet that numbers three and five will likely create a lot of contention with service providers. But you have until February 1, 2018 to get those in place. However, if experience teaches us anything, service providers had better start now getting these new requirements in place and operating.
- All organizations picked up the following new requirements that are best practices until February 1, 2018: (1) change control processes to include verification of PCI DSS requirements impacted by a change, and (2) multi-factor authentication for all personnel with non-console administrative access to the CDE. As with the aforementioned new requirements for service providers, these will also require a lot of organizations to get started now to ensure these new requirements are in place and operating.
- The Council clarified requirement 8.1.5 to show that it is intended for all third parties with remote access, rather than only vendors. While most organizations understood the intent of this requirement, there were a few that played “legal eagle” and refused to require compliance for non-vendors.
- Requirement 6.5 has been clarified that developers must go through secure coding training at least annually. This change will likely create some consternation for some organizations that are developing their own software that is in-scope for PCI compliance.
- Clarified 11.5.a by removing “within the cardholder data environment” from the testing procedure for consistency with requirement, as the requirement may apply to critical systems located outside the designated CDE. This will likely expand the number of systems that require critical file monitoring.
- Clarified 12.8 1 by saying that the list of service providers now must include a description of the service(s) provided.
- Clarified 12.8.2 by adding guidance that service provider responsibility will depend on the particular service(s) being provided and the agreement between the two parties.
- One of my pet peeves has finally been addressed. I have always had an issue with requirement 1.1.6 and the use of the terminology “insecure protocols”. The reason is that in one way or another, all protocols have their insecurities whether they are known or not. In v3.2, the Council has finally removed the “insecure” designation as, in their words, “these may change in accordance with industry standards.” It is those small battles at times that make your day.
There are other clarifications and edits that have been made to the new version.
For all of us QSAs, we await the Reporting Template which will detail out the actual testing to be performed which will allow us to assess the real impact to the effort required to conduct an assessment. As a result, there could still be some surprises with this new version of the PCI DSS. So stay tuned.
PCI Guru 
Question regarding Hardening. Hopefully okay that i am asking in this thread. We’ve been trying to use CIS but proving to be a bit challenging.
Could we follow something like this and state that this is what we follow as a hardening guide?
http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/ssg-rhel7-guide-pci-dss.html
It is not hard and fast that you must follow a particular hardening standard. What the DSS states is that your standards are consistent with a recognized standard. The key is that your hardening standard does not enable something insecure such as telnet or SSL.
That said, your reference to the Red Hat security guide should be acceptable and recognized as well as the ones mentions in the DSS.
Has anyone seen any pushback on requirement 6.5 (annual developer training)? I would have called this an “evolving requirement” rather than a “clarification” since 3.1 did not have any annual requirement. Not giving a whole lot of time to put a program like this in place…
It is my understanding that QSACs are starting to hear some complaints about this new training requirement. But most organizations that understand security have questioned why secure coding training was not required at least annually given that threats to Java, PHP, .NET, etc. are constantly changing and evolving. So it is typically those organizations that are trying to skate on PCI compliance that are complaining the loudest.
Do you have a link to what NIST, SANS, or OWASP, considers to be a “insecure Port or Protocol”?
Every port/protocol can be abused. Therefore they are all insecure in some form. It all depends on how they are implemented. This is why some of us in the security profession always chuckled at the fact that the PCI DSS said that HTTP and HTTPS were considered “secure”.
I completely agree with that, though since they make that reference in the rules, the question was asked, what NIST, OWASP, or SANS list was to be the starting point. My preference is to limit all traffic to only what is needed, and have true segmentation and other local server firewalls as well. Not to mention why do servers that are not patch management (as an example), need to talk to the internet.
So in this case, I was just looking to see if you know what they were suggesting as the minimum, as the “compliance staff” would like that, rather than what I think, for now.
That all depends on your cardholder data environment (CDE) and what it requires to properly function. Every organization is different, therefore it is impossible to say that one organization’s requirements for ports/protocols is “correct” and another organization’s requirements are “wrong”. That is why it is up to each organization to document those ports/protocols that are necessary for the functioning of their CDE with the business justification for each of those ports/protocols.
Again, while I agree with you, I am referring to what the PCI 3.2 states in 1.1.6. “For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (e.g., NIST, ENISA, OWASP, etc.).”
Since they call out guidance from others as to what is insecure, there has to be a document at these groups that lists it. Do you know which documents that the PCI 3.2 is referring too. This is important as many companies do not understand about locking down ports and need examples. This is likely the reason this was added, due to how many breaches have occurred of late, due to port 80 being opened to the web, or using telnet for management of routers.
The OWASP side is easy as the DSS is referencing the OWASP Top 10 vulnerabilities list. I would use the National Vulnerability Database (NVD) for the NIST reference. ENISA is the EU’s version of the NIST Computer Security Resource Center. NIST and ENISA both have issued publications that call out issues with ports/services, but I am not aware of any consolidated list that either entity maintains or has published. Other sources you could reference are the Verizon Data Breach Investigation Report (DBIR) or the Symantec Internet Security Threat Report (ISTR) that discuss ports/services with issues.
v3.2 says: . Multi-factor authentication can be performed either upon authentication to the particular network or to the system component. So, if the CDE is on a separate network, a jump box can be used with 2 FA and once on the remote network, single-factor authentication to the system component can still be used, right ?
You are correct. Two factor authentication or better is only required upon entering the cardholder data environment (CDE). So you example with a jump box would be compliant.
Thanks for this. Do you have a link to the 3.2 draft? Thanks!
You need an account with the PCI SSC, but the URL for the portal is https://programs.pcissc.org/