At the end of April, the Payment Card Industry (PCI) Security Standards Council released version 3.2 of the PCI Data Security Standard (DSS). A couple changes are noteworthy, even though most were incremental or for clarification purposes.
Multi-Factor Authentication
In version 3.1 of the standard, requirement 8.3 mandated the use of “two-factor authentication for all remote access into the CDE” (Cardholder Data Environment). It was a single requirement with no sub-requirements. In this latest version, two sub-requirements have been added and all references to “two-factor” have been change to “multi-factor.” I wasn’t sure why they used two-factor instead of multi-factor in the first place.
More importantly, the updated 8.3 requirement now mandates the use of multi-factor authentication for all “individual non-console administrative access and all remote access to the CDE.”
Requirements 8.3.1 and 8.3.2 explicitly state that multi-factor is required for:
- All non-console, administrative access (8.3.1) and for
- All remote access – not just administrative – and for third-parties as well as employees (8.3.2).
Requirement 8.3.1 is listed as a best practice until January 31, 2018, when it becomes a requirement.
Troy Leach, the CTO of the PCI Security Standards Council, stated in “Preparing for PCI DSS 3.2″ that these changes in section 8.3 “will not impact machine authentication where one system is communicating with another” and that it would also not “impact administrators accessing directly from the console.”
The same article states that “making security an everyday priority instead of a compliance checklist continues to be a struggle for organizations.” Leach says that the “changes PCI DSS 3.2 emphasize the importance of” ongoing monitoring and measuring of your security controls. I’ve been harping on this topic lately. It’s not good enough to use a “set-it-and-forget-it” security configuration strategy! I’m happy that this crucial element is getting more emphasis.
Help with Multi-Factor Authentication Requirements
January 2018 might seem like a long way off, but it’s only 19 months away! Best start planning now. Let me know if you’d like Botz & Associates to help you design and implement your compliance with multi-factor related requirements. As of today, you can choose between biometrics, cell phone texts, and email notification of one time pin numbers for the second factor for UNIX/Linux and IBM i systems.
Penetration Testing Now a Requirement
Requirement 11.3, Penetration Testing, was a best practice in version 3.1 but it became a requirement July, 1, 2015. Therefore, while there have been no additional changes, in version 3.2 you are required to perform some type of penetration testing from the get-go.
Additional Requirements for Shared Hosting Providers
Most of the other changes in 3.2 are clarifications of existing requirements. However, Appendix A, which contained additional requirements for Shared Hosting Providers, now has two additional sub-appendices: A2 and A3. Appendix A.2 addresses additional requirements for entities that are still using SSL or early TLS implementations. A.3 contains additional requirements for Designated Entities Supplemental Validation (DESVs). Most IBM i customers will not be impacted by the requirements in section A.3.
Key Dates for PCI Requirements
Along with the updated requirements there are a couple of key dates to be aware of:
- October 2016 — PCI DSS 3.1 becomes retired and all assessments will need to use version 3.2 of the standard.
- January 31, 2018 — New requirements introduced in PCI DSS 3.2 will be considered best practices until this date.
- February 1, 2018 — New requirements introduced in PCI DSS 3.2 become effective as requirements.
Your Next Steps
If you are affected by the PCI DSS standards, I suggest you begin by reviewing the changes in detail and creating a plan for how you will address the new requirements for multi-factor authentication.
I also strongly suggest that you consider how you can make compliance with PCI DSS part of your normal business processes. I harp on this because it works! One of the most rewarding things I do is mentor organizations in defining, implementing and managing their information security management business process. Check out our TeamSecurity webpage to find out more. Of course, you can always get a hold of us by phone, email or contact form from our Contact page.
