It’s hard to believe that over a decade has passed since PCI DSS(Payment Card Industry Data Security Standard) was first introduced in 2004 as the information security standard for organizations that store, process or transmit cardholder data. Although it’s become a mature industry standard, two problems remain. First, breaches are still occurring, and second, “compliant” organizations are often the victims. According to the PCI Security Standards Council, analysis of recent cardholder data breaches and PCI DSS compliance trends reveal that many organizations don’t have processes in place to ensure that PCI DSS security controls are continuously enforced. However, the most recent release of PCI DSS 3.2 aims to address these shortcomings.

In hopes of changing the perception of PCI compliance from a “once-a-year” event to an on-going security process, PCI DSS 3.2focuses on giving organizations a chance to plan for and implement security processes that help mitigate against cyberattacks. Version 3.1 expires on October 31, 2016, and new requirements set for by the 3.2 release have a grace period, giving organizations until February 1, 2018, to meet them.

What’s New?

Let’s take a closer look at the additions and updates to PCI DSS 3.2:

1. Section 6.4.6 requires organizations to ensure security controls are in place following any change in their cardholder data environment (CDE). For example, if an individual who is unaware of security-relevant issues or the responsibility to protect cardholder data adds a new device to the network. Essentially, this change-management process helps ensure that device inventories and configuration standards are kept up-to-date and security controls are applied where needed.
2. Section 11.3.4.1 requires service providers do penetration testing every six months. Previously, organizations were required to demonstrate annually that their segmented environment was truly isolated. As with other changes to the standard, this is another way to confirm that security controls are in place and working.
3. Sections 12.11 and 12.11.1 requires that service providers perform quarterly reviews to confirm that personnel are following security policies and procedures beyond the week that the assessor comes to visit.
4. Section 12.4.1 mandates executive responsibility for PCI compliance and protection of cardholder data. This change is interesting in that it seems to require a CSO position. The goal seems to be a cultural change away from “compliance in a point in time” to “securing data all of the time.”

Multi-Factor Authentication Front and Center

Multi-factor authentication was already a requirement for remote access, but perhaps the most significant change with PCI DSS 3.2 is the requirement of multi-factor authentication for non-console administrative access to the systems handling card data.

What does this mean? Think about it in terms of a router handling traffic that includes cardholder data and thus, is in the CDE. Console access means you have your keyboard connected to the serial port. Non-console refers to any other connection (SSH, a Web UI etc.) even within your company’s own network.

It may sound complex, but it isn’t. Most enterprise-class routers and VPNs support using RADIUS or TACACS for authentication administrator access, and most enterprise-class two-factor authentication systems support those same protocols. For Linux, disabling root login via SSH and requiring two-factor authentication for sudo using PAM-RADIUS should also suffice. Windows is a bit more challenging, but only in that it requires a more proprietary approach and validation that your multi-factor authentication solution can provide it.

These changes, if implemented correctly, could have a significant impact. Almost all attacks require hackers to escalate privilege to the administrative level so they can access data. Requiring multi-factor authentication for administrators makes this incredibly difficult. Even the well-known and seemingly unstoppable “pass-the-hash” attack will fail with the use of one-time passcodes. No hash would be valid more than once.  

Are the Standards Working?

PCI has often been criticized for inherent conflicts of interest. Although the PCI Security Standards Council states that Qualified Security Assessors must act ethically and independently, the QSAs are contracted and paid by the organizations they assess, which could obviously lead to situations where assessors overlook items or allow compensating controls that are less than compensating. Then there is the recent FTC investigation requesting information from several large QSAs, marking yet another high profile instance of the FTC exercising its authority.

Perhaps these investigations, combined with the new requirements in PCI DSS 3.2, will have an impact. Both seemed to be grounded in prevention, but only time will tell.