A Guide to Stronger Security in PCI DSS 3.2
The PCI SSC (Payment Card Industry Security Standards Council) released PCI DSS 3.2, the newest version of the technical security requirements for companies and vendors that deal with customer credit and debit card transactions.
Released a year after 3.1, the new version shows greater security maturity as it expands the use of multi-factor authentication to system administrators, requires more pentesting and checks for security control resilience, as well as extending the deadline to migrate from SSL and early TLS to newer versions of TLS.
The new standards for protecting customer credit and debit card data show an acknowledgement that attackers are leveraging stolen or social engineered credentials to easily access a company’s systems to steal customer data. Stolen credentials allow an attacker to move around the cardholder data environment (CDE) unhindered and undetected, posing as a legitimate user.
The cardholder data environment (CDE) refers to a computer system or networked group of IT systems that process, store and/or transmits cardholder data. This also includes any component that directly connects or supports this network, according to SearchSecurity, such as firewalls, switches, access points, security appliances, point-of-sale systems, web servers, app servers, all applications, virtual components and more.
Expanding Use of Multi-Factor Authentication
The previous versions of PCI DSS require the use of multi-factor authentication to protect remote access to the CDE, and prevent access-based attacks from resulting in successful breaches.
This standard, 8.3 has been expanded to include sub-requirements that require any system administrator locally accessing CDE to also use multi-factor authentication, whether third party or internal. That includes sysadmins that can change systems and other credentials within that network, which could allow an attacker to wreak havoc and take over a company’s systems.
Adding multi-factor authentication to every login across every user in your organization is highly recommended. Attackers often target non-privileged users to get their foot in the door with the intent to move laterally within your systems until they find customer data to steal. That means protecting your marketing, HR, sales and other teams is equally important as protecting sysadmins.
Single-factor authentication (such as a username and password) is no longer acceptable for local access to CDEs, according to PCI SSC Chief Technology Officer Troy Leach, as reported by DarkReading. Additionally, the language has been changed from two-factor to multi-factor authentication to clarify that more than two factors can be used.
How to Prepare for New 8.3 Sub-Requirements
How can organizations prepare for this change? According to the PCI SSC’s blog on Preparing for PCI DSS 3.2:
- Review how they’re currently managing authentication in their CDE
- Review current administrator roles and access
- Identify where changes to authentication may likely be impacted by the new requirement
Detect and Report on Security Control Failures
A new PCI DSS requirement 10.8 and sub-requirement 10.8.1 requires service providers to detect and report on the failures of critical security control systems (goes into effect February 1, 2018). These control systems include firewalls, IDS/IPS (Intrusion Detection/Protection Systems), antivirus, physical and logical access controls, audit logging mechanisms and segmentation controls.
This is to ensure there’s a system in place that alerts companies when critical controls fail, since they can go unnoticed for a long time, allowing attackers to compromise systems and steal data, according to PCI DSS 3.2.
Penetration Testing Checks and Balances
To ensure resilience, service providers are now required to perform penetration testing on segmentation controls at least every six months, according to a new sub-requirement 11.3.4.1. The PCI SSC also added a testing procedure 11.3.4 to ensure that penetration testing is performed by a qualified internal or external third party.
Firming Up The People Part of Security
Other requirements aim to ensure the administrative side of security is covered - 12.4 requires that executives ensure that the security policy and procedures clearly define information security responsibilities for all personnel.
Meanwhile, sub-requirement 12.4.1 requires executive management to establish responsibility for the protection of cardholder data and a PCI DSS compliance program.
Requirement 12.6 mandates the implementation of a formal security awareness program to ensure personnel are aware of the cardholder data security policy and procedures.
Migrating to TLS? Now You Have More Time
PCI DSS 3.2. now offers extended migration dates for SSL/early TLS, easing the transition to a more secure versions of TLS (1.1 or higher) by adding a two years to the deadline - companies must now migrate to TLS by July 1, 2018.
Unsupported Old Apps Are, Unsurprisingly, Deemed Unsecure
There’s also a new note about evolving threats, in the section about the relationship between PCI DSS and PA-DSS (Payment Application Data Security Standard) for applications that store, process or transmit cardholder data.
“As security threats are constantly evolving, applications that are no longer supported by the vendor (e.g., identified by the vendor as “end of life”) may not offer the same level of security as supported versions.”
They’re basically saying that any outdated or unsupported apps aren’t secure enough to hold sensitive financial data, which reflects the shift of new threats to targeting old versions with known vulnerabilities.
Zero-days are rarely the initial point of entry - the easier, and more effective route for attackers is leveraging old bugs as the point of entry. Operating systems like Windows XP and browsers like Internet Explorer v.10 and earlier are examples of unsupported, and therefore, unpatched technology that has been left behind by Microsoft in favor of newer, more secure versions.
Your best bet is to upgrade and patch regularly when routine or emergency fixes are released by your software vendors to ensure you’re closing up any security gaps. Using Duo’s Device Insight feature, you can get visibility into any outdated devices, and even block them with our Endpoint Remediation policy and control feature until they’re updated to the most secure version.
Other PCI DSS 3.2 Resources
Here’s a timeline of the key dates to help in preparation for 3.2: Planning for PCI DSS 3.2: Key Dates. One important date is when 3.1 will retire, and that’s scheduled for October 2016 - six months after the release of 3.2. That means all compliance audit assessments must measure against the new standards in version 3.2.
See the full version of PCI DSS 3.2, and a summary of the changes from 3.1 to 3.2 from the PCI SSC.
For an overview of migrating from SSL and early TLS and a comprehensive FAQ, see the Bulletin on Migrating from SSL and Early TLS: A Resource Guide from the PCI SSC (PDF).