Note: This is a two-part series that will go over the latest Data Security standard from PCI, explaining the new changes and how they impact organizations. For Part I, visit paladion.azurewebsites.net/an-introduction-to-pci-dss-3-1.
The PCI Security Standards Council published the latest version of the Payment Card Industry Data Security Standard to put an end to the use of the outdated Secure Sockets Layer (SSL) encryption and early versions of Transport Layer Security (TLS) after experts discovered that they can put payment data at risk. Instead, PCI DSS 3.1 calls for the use of current, secure versions of TLS and stronger cryptography. In addition to burdening companies that have already started implementing PCI DSS 3.0, the new set of requirements will impact business processes in the following ways.
Shift from SSL and Early TLS to Secured Technologies
Requirement 2.2.3 mandates the use of additional security features to protect services, protocols or daemons that are categorized as insecure. After warning against the use of SSL and early TLS, PCI DSS 3.1 recommends technologies such as SSH and IPSec VPN for protecting services like file-sharing and non-console administrated access. 4.1.1 also deems SSL an insecure transmission method, forcing organizations to make the necessary changes to their web servers. While the change is typically easy, protecting administrator usernames and passwords on web-based integrated management interfaces can be difficult since several systems of this kind don’t provide access to the website configuration.
Development of an Inventory of Cardholder Data (CHD)
According to requirement 2.4, organizations should keep a full inventory of all CHD systems in scope for PCI DSS. Previously, most organizations kept an informal inventory whereas several had none. However, with this new requirement, all companies will be significantly burdened with the task of tracking down scattered items, entering them into a formal systems inventory, and maintaining them accordingly.
Addition of Specific Controls for Hashed and PANs
The new 3.4 requirement explained a set of controls necessary if both hashed and truncated primary account numbers (PANs) exist on the same environment. The same applies to certain types of tokens depending on how they’ve been generated. Previously, the limitations of hashing and encryption algorithms gave hackers the chance to use hash/cypher-text and the remaining characters to reverse engineer the key and ultimately find the full PAN on all numbers in the database. Moreover, some tokenization solutions obscure the middle six numbers, making the real number too easy to guess or making it possible to reverse engineer the tokenization process.
Complying with this requirement can be relatively difficult. First off, organizations need to find out if they’re retaining portions of the full pan in their databases. Next, when it comes to tokenization decisions, companies should check with the tokenization guidance released by the PCI as certain tokenization implementations could limit the scope of the PCI assessment. Therefore, you’ll need to have PCI compliance professionals tackle this matter on your behalf.
The Need for Disk Encryption
As per requirement 3.4.1, disk encryption that uses logical access control shouldn’t use the same logical access control as that for operating system authentication and access control. For many organizations, this means finding a different disk encryption solution to ensure their compliance with PCI DSS 3.1. Now this can be expensive, which is why experts recommend eliminating the need for disk encryption by simply changing the program to encrypt at the entry point.
Addition of Websites Handling CHD to the Scope of PCI
This is one of the vital changes which PCI DSS 3.1 introduced. According to 4.1, websites that never stored, processed and transmitted cardholder data are in the scope for PCI. Before this requirement, organizations removed these applications from scope, allowing hackers to compromise the initial site with the shopping cart and probably send shoppers to a malicious site instead of the card processor site. While complying with this requirement will remedy the situation, adding these sites to the scope of compliance will be a hassle to many organizations. For starters, all the applications brought into the scope will need full change controls, reviews for application security, penetration tests and vulnerability scans, and looping and monitoring. As a result, you’re going to invest a lot of money and effort to comply.
Accountability of Application Development Processes for Storing CHD
A new requirement, 6.56 mandates that application development processes account for how CHD is stored in memory. As these applications don’t store, process or transmit data, they were removed from the scope of PCI DSS. However, their addition is vital for the same reason mentioned earlier. Besides, malware is more sophisticated now than ever, allowing its coders to design it to pull the necessary data from memory banks without being written to disk. Therefore, you’ll need to integrate PAN- and SAD-handling procedures in in-house developed apps to protect data in memory.
Holding Coding Practices Accountable for Vulnerabilities
Coding practices are to account for broken authentication or vulnerabilities in session management. This change became necessary as compromised web applications tend to exhibit the two issues mentioned in the requirement. This means that your company will need to incorporate development processes that ensure the accuracy and security of session management while designing pages that properly authenticate users and block potential backdoors.
Elimination of the Concept of Shared Passwords
Effective July 1, 2015, service providers will need to provide different authentication credentials for different clients. This hasn’t always been the case as service providers tend to use a common password for multiple clients to ensure ease of use. However, this compromises the data of multiple organizations and makes tracking the source of data breach very difficult. Now, to be compliant, service providers will need to establish a password safe for all client locations to provide unique passwords at each location. Service providers may also investigate robust authentication methods to avoid storing passwords in the likes of Outlooks or Excel files.
Addition of Physical Security Technologies to POS Terminals
Merchants are to physically secure their point of sale (POS) systems to ensure that they aren’t tampered, modified or substituted by unauthorized individuals. This requirement detailed in 9.9 is necessary as POS terminals have been targeted to install skimmers, malicious firmware and similar software. By implementing it, organizations can prevent hackers from accessing the machines and even detect modifications or substitutions in a timely manner. Moreover, meeting this requirement will ensure your compliance with PCI DSS.
Improvement of Penetration Tests
From July 1, 2015, only the penetration tests enhanced by PCI DSS 3.1’s requirement 11.3 will be used to identify how attackers penetrate into environments and ultimately develop counter attacks. The requirement mandates that the test be:
- Based on industry-approved approaches
- Comprehensive to cover all cardholder environment components
- Capable of testing inside and outside the network
- Able to validate segmentation and scope reduction controls
- Proficient in defining application layer and network layer penetration tests
- Capable of reviewing threats over the span of 12 months and offer remediation steps
Previously, guidance on penetration tests was week and insufficient. Moreover, network segmentation was reviewed via firewall configurations, causing confusion when it came to understanding the segmentation. Now, PCI DSS 3.1 requires penetration tests to verify that the segmentation is working as expected and capable of preventing traffic from or to the CHD environment. This, again, means that your company will be spending more time and money to facilitate additional testing and documentation. Expect to spend more of these resources for remediating certain elements of your systems. For the future, though, remember to schedule penetration tests ahead of time.
Segregation of Information Security Functions from Network Administration
In smaller companies, information security and network administration may be handled by the same individual. This can put vital data at risk if this individual becomes malicious. Rather than worrying about the aftermath of their theft and spending resources trying to detect tracks they expertly covered, it’s better to separate individuals who perform information security duties and those who maintain the systems. Meeting this requirement will also push higher-level individuals to become more responsible while monitoring their teams. It can even make them open to further training to understand their responsibility properly.
Tracking Requirements by the Entity Managing Them
Requirement 12.8.5 highlights the need to track which PCI requirements are managed by service providers and which are to be managed by the organization itself. The biggest benefit of this new requirement is eliminating the confusion surrounding how third parties receive CHD should be managed, which PCI DSS requirements they should comply with, and which requirements are considered a shared responsibility. As for its impact, your organization will need to develop a matrix of responsibilities to ensure that all the responsibilities assigned to the service provider, organization or both are clearly defined. With that in hand, a complete control environment will be created, ensuring that data breaches aren’t caused by failure to communicate each organization’s responsibilities. To further emphasize the need to define roles, service providers are obliged to acknowledge in writing that they’ll be able to maintain all applicable PCI DSS requirements entrusted to them.
After this quick look at the effect and impact of the main changes in PCI DSS 3.1, make sure to meet all the new requirements to remain compliant with this standard and ensure the security of your transactions.
About the Author
Giles Witherspoon-Boyd is a certified PCI Professional (PCIP) with years of experience in helping companies secure there critical IT assets and comply with mandatory security compliance requirements. Giles is also the President of Kaizen Data Security Group and the strategic security consultant for Paladion’s Enterprise Security Services.