As promised, the Payment Card Industry Security Standards Council (PCI SSC) released version 3.2 of its payment card requirements on Thursday.
This release is arguably more significant for the way it is being introduced and the underlying message than for the changes themselves, which are few and have been recommended security best practices for some time.
With fewer changes in this release and a longer-than-usual runway for the changes to take effect, PCI Security Standards Council Chief Technology Officer Troy Leach said he believes the updated version gives organizations a chance to plan for and implement security processes that help mitigate against cyberattacks.
Approaching the PCI standard from a security perspective is a mantra that Trustwave has delivered on for 20 years. In fact, if you have been practicing a security-first, "business as usual" approach with your PCI compliance, you may have already considered implementing some of these changes.
On the other hand, maintaining a secure posture in the face of today's cyberthreats is never easy. The potentially devastating and unexpected nature of new threats is one of the reasons the PCI SSC cites for moving away from its previous three-year cycle for releasing updated versions. The council has even removed from the standard specific references to technologies being "strong" and "secured." As we learned with SSL vulnerabilities like Heartbleed, today's strong and secured technology is tomorrow's weak link.
Let's take a look at the highlights of PCI DSS 3.2 and their impact on you:
Key Dates
What's New in 3.2 for the Enterprise?
Here are key new requirements in PCI DSS 3.2:
- Requirement 3.3 updates specifications around displaying primary account numbers (PANs) to ensure that only the minimum number of digits are displayed as necessary to perform a specific business function.
- Requirement 6.4.6, which goes into effect on Feb. 1, 2018, is designed to ensure that security controls are in place following changes to the cardholder data environment.
- One of the more significant changes is focused on multifactor authentication in Requirement 8.3. It updates the language from "two-factor authentication" and expands the requirement from personnel with remote access to all personnel with non-console administrator access to card data and systems.
8.3.1, which goes into effect Feb. 1, 2018, requires an individual to present a minimum of two separate forms of authentication (such as a password, a smart card or a fingerprint) before access to the cardholder data environment is granted. This extra layer of authentication means that a password alone is not enough and provides additional assurance that the individual attempting to gain access is who they claim to be. With multifactor authentication, an attacker would need to compromise at least two different authentication mechanisms, which increases the difficulty of compromise and thus reduces the risk.
Authentication weaknesses leave systems highly vulnerable. The need for multifactor authentication and the risks of not employing it are so concerning that your organization should be moving as quickly as possible to implement it, regardless of the compliance requirement. In fact, the 2016 Trustwave Global Security Report (GSR) found that authentication ranked second on the list of the most common critical vulnerabilities uncovered by penetration testing in 2015.
What else do you need to know?
UPDATE YOUR SSL AND TLS COMMUNICATION CHANNELS ASAP
One of the reasons the PCI council gave for releasing version 3.2 now instead of waiting until fall is to be clear about the extended deadlines for replacing SSL and TLS 1.0 protocols. Despite the 2018 deadline, you should move to replace these protocols as quickly as possible. Of the top 10 critical vulnerabilities identified through penetration testing by Trustwave in 2015, SSL protocol vulnerabilities ranked first.
EVOLVING REQUIREMENTS FOR SERVICE PROVIDERS
New requirements for third-party service providers are focused on additional security best practices and their documentation, as well as penetration testing on segmentation controls at least every six months and quarterly reviews to confirm personnel are following security policies and operational procedures. Of the 12 core requirements of the PCI DSS, there are five new sub-requirements for service providers within requirements 3, 10, 11 and 12. These requirements (3.5.1, 10.8, 10.8.1, 11.3.4.1, 12.4.1) are considered "best practices" until they go into effect on Feb. 1, 2018.
BEST PRACTICES FOR IMPLEMENTING PCI DSS INTO "BUSINESS AS USUAL" PROCESSES
PCI DSS 3.2 clarifies that some continuous "business-as-usual" controls may be requirements for certain entities, such as those defined in the Designated Entities Supplemental Validation (DESV) in Appendix A3. As the PCI DSS notes in relation to the new appendixes, including the DESV, "All organizations should consider implementing these best practices into their environment, even where the organization is not required to validate to them."
How to Get Help
Trustwave can help you complete your PCI DSS assessment or begin your preparation for PCI DSS 3.2. In either case, the changes announced in version 3.2 are security best practices that you should begin implementing regardless of the standard.
Dixie Fisher is product marketing manager of compliance solutions at Trustwave.
