Access Security: Meeting the PCI DSS Compliance 3.0 Deadline
Although the chances of everyone that deals with payment card data being fully in compliance with the newest version of PCI DSS version 3.0 by January 1, 2015 is pretty slim, it’s never too late (unless you’ve been hacked or audited). And since the majority of breaches this year can be traced back to the classic low-tech case of stolen credentials, starting with standard 8.0’s focus on access and authentication security might be in your organization’s best interest.
In the preliminary document detailing changes from version 2.0 to 3.0, PCI and PA-DSS Version 3.0 Change Highlights (PDF), the PCI SSC (Security Standards Council) acknowledged the need to address the issue of weak passwords and authentication, as well as third-party security challenges.
And as Verizon’s 2014 Data Breach Investigation Report (DBIR) revealed, a number of POS intrusions could be attributed to “truly awful passwords;” reporting that when it came to remote criminal attacks against environments with retail transactions, the top three methods targeted the inherent weaknesses of our most basic access security attempts.
Brute force (53 percent) and offline cracking (9 percent) use tools and techniques to remotely guess passwords and number combinations, including attempts to crack cryptographic hashes. Another 38 percent of hacking attempts involved stolen credentials, those of which can be somewhat easily acquired with minimum effort, thanks to phishing and other targeted social engineering attacks.
So all of those statistics and findings build a fairly compelling case for a focus on strengthening access security - but what does the PCI DSS 3.0 change mean when it comes to standard 8.0? Here’s a quick summary of the top changes, as found in the Summary of Changes from PCI DSS Version 2.0 to 3.0 (PDF):
PCI DSS 8.0: Identify and authenticate access to system components
First of all, the name of the standard itself was broadened from “assign a unique ID to each person with computer access” to a title that suggests a focus on user authentication, rather than user identification. The PCI SSC acknowledges that identifying each entry point of access to their systems is more important than merely assigning a unique ID to each user, which hasn’t proven effective when it comes to keeping attackers out.
This may come as a response to our increasing use of cloud/web-based services, which can introduce a lot of different entry points into corporate networks. While convenient for remote and anytime access, this means likewise for attackers working remotely.
8.1.5: Manage IDs used by vendors to remotely access, support or maintain system components (enabled only when needed/disabled when not in use, and monitored when in use).
PCI DSS 3.0 clarifies that allowing vendors 24/7 access can increase the chances of unauthorized access; suggesting that having an always-available external entry point into your network increases your chances of getting breached.
One way to ensure control/monitoring over vendor access is to use the administrative controls offered by your authentication provider. If you’re using two-factor authentication, one way to give vendors one-time or time-based access is by creating bypass codes that expire after a set amount of time.
While monitoring tools also give you access to track user activity after logging into your network, authentication monitoring tools can also give you the data needed to see where your users are logging in from, as well as who. Check out Duo Security’s Maps and Flags feature that does just that.
8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
This requirement was changed to clarify that strong cryptography should be used to protect authentication credentials, with the new guidance pointing out that network devices and apps that transmit or store passwords without encryption leaves them vulnerable to interception by a sniffer, or they could be directly accessible wherever they’re stored.
Sadly, there are still many cases in which passwords are stored in plaintext, even in this case of a company that offered a security plugin to WordPress users. After they were breached and their database of usernames/passwords were stolen, their users were forced to change administrative passwords on every site they owned. Find out more in The True Cost of a Data Breach.
8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys.
The user identity has to be verified before modifying auth credentials - this requirement added in the provisioning of new tokens and new keys as examples of modifications.
The revised requirement points out that in the potential threat of social engineering, some attackers might try to get a password changed by calling a help desk and impersonating a user.
8.3 Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).
This distinction from the 2.0 version of the same requirement explicitly points out the type of users that need to use two-factor authentication when they’re connecting remotely, including users, admins and third-parties that need vendor access for support or maintenance.
Target’s breach was attributed to the initial point of entry into their network granted by their third-party HVAC company’s credentials that were stolen and used to steal millions of customers’ data.
8.4 Document and communicate authentication procedures and policies to all users including guidance on choosing strong auth credentials, how to protect credentials, how to not reuse old passwords, and how to change passwords if compromise is suspected.
The PCI DSS 3.0 includes new requirements around educating users on how to protect credentials, not use old passwords and how to change passwords if a breach is suspected. It would appear that more emphasis is placed on how to educate and equip users with better security training in order to protect organizations at large.
8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
This is a totally new requirement that refers to service providers and how they manage their own authentication to their different customers (retail organizations). It’s in efforts to limit the amount of different organizations a potential intruder can get access to if they were to steal just one set of admin credentials, an important security measure, particularly in the case of POS system vendors that may provide access to the payment systems of several different retailers.
8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
- Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
- Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access
As an evolving requirement, this is a new addition in 3.0 that clarifies that any auth mechanisms shouldn’t be shared or used across different accounts. Just another way to limit the scope and power of one method of authenticating in order to stop potential attackers from accessing more than one account if they were somehow able to steal or mimic a user’s auth mechanism.
Those are the most important changes to note in the case of the changes in the authentication requirement from PCI DSS version 2.0 to 3.0. Hopefully this helps your team in navigating compliance in time for the fast-approaching deadline - for more PCI and retail guidance, check out:
A Modern Guide to Retail Data Risks Lack of PCI & PA-DSS Compliance in Recent POS Vendor Breach PCI DSS 3.0 and Two-Factor Authentication PCI SSC Releases Security Guidance on Protecting POS Terminals