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.
Many businesses across the world deal regularly with the Payment Card Industry (PCI) Data Security Standards (DSS), so it should come as no surprise that many security programs (including your own) mandate compliance with PCI DSS. With the release of Version 3.1 in April 2015, it’s time for your company once again to make a few vital changes to maintain compliance.
The Purpose of Version 3.1
PCI DSS 3.1 was released outside the Payment Card Industry Security Standards Council’s (PCI SSC) usual cycle (36 months). In addition to the surprise, it was received without much excitement since many practitioners were still busy upgrading their systems to Version 3.0 after it went into full effect in January. However, Version 3.1 was vital after the National Institute of Standards and Technology (NIST) announced the vulnerabilities in SSLv3.0.
Released in 1996 by Netscape, SSL Version 3.0 has always been deemed weak. However, it was considered safe until October 2014, which is when POODLE and FREAK were discovered. A major flaw in SSL 3.0, Padding Oracle On Downgraded Legacy Encryption (POODLE) and Factoring Attack on RSA-EXPORT Keys (FREAK) allow malicious Wi-Fi hotspots or compromised ISPs to extract data from secure HTTP connections. As SSL omits validation of certain data that accompanies messages, attackers can decipher an individual byte and the time of the encrypted data, extracting the plain text of communicated messages.
The Changes in PCI DSS 3.1
According to the ‘Summary of Changes from PCI DSS Version 3.0 to 3.1’, the newer document addressed typographical errors and incorporated updates to ensure better readability. However, it’s the following changes that practitioners should focus on.
Requirement 2.2.3
According to this requirement, organizations need to provide additional security features to services, protocols or daemons that may be categorized as insecure. PCI DSS 3.1 recommends the use of secured technologies such as SSH, S-FTP, IPSec VPN, and TLS, especially for services such as file-sharing, FTP, Telnet and NetBIOS. The new standard also warns against using SSL and early TLS as they are “not considered strong cryptography” and won’t be in use as a security control by June 2016.
Requirement 2.3
This requirement mandates that all non-console administrated access should be encrypted by technologies such as SSH, VPN or TLS. PCI removed SSL as an example of a secure technology and even reiterated the warning under Requirement 2.2.3. Through these measures, sensitive administrative or operational level information won’t be revealed to eavesdroppers or stolen by fake administrators.
Requirement 2.4
A unique requirement for Version 3.1, Requirement 2.4 mandates storing a full inventory of all system components that are within the scope of PCI DSS. Previously, organizations had the choice between establishing an informal inventory to keep track of important systems and having none at all. However, this requirement will help organizations track system components and ensure the implementation of configuration standards across all the components in the PCI DSS scope.
Requirement 3.4
In the new document, the PCI Council clarified that primary account numbers (PANs) should be unreadable regardless of where they are stored. Also applicable to tokens depending on how they’re generated, this requirement recommends the use of one of the following four approaches:
- One-way hashes based on strong cryptography (to render cardholder data unreadable)
- Truncation (to permanently remove a segment of PAN data and ultimately store a portion of it)
- Index tokens (to replace the PAN based on a given index for an unknown value) and pads (to randomly generate a private key that would be used once to encrypt a message)
- Strong cryptography with key-management processes (to encrypt PANs with industry-tested algorithms)
Requirement 3.4.1
Traditionally, disk level encryption encrypts the entire disk on a computer, but decrypts the information when an authorized user requests it. According to the new version of this requirement, if disk encryption is used instead of file- or column-level database encryption, organizations should manage logical access separately of native operating system access control mechanisms. Therefore, to comply, you need to ensure that system users do not use the same user authentication credentials as the operating system or use a decryption key that’s associated with the system’s local user account database or network login credentials.
Requirements 4.1
One of the important PCI DSS 3.1 requirements, Requirement 4.1 clarifies that websites which never store, process or transmit cardholder data are in scope for PCI. To comply, you need to use robust cryptography and security protocols such as trusted keys and certificates. As a result, sensitive information transmitted over public networks will be encrypted and protected from malicious individuals even if they succeed in intercepting or diverting data in transit.
Requirement 6.5.6
Another new requirement, it mandates identifying all ‘high risk’ vulnerabilities by a vulnerability risk-ranking process in order to address them during application development. The process is identified in Requirement 6.1 which aims to help organizations identify new security vulnerabilities, assign a risk ranking to vulnerabilities, and use trustworthy outside sources for vulnerability information such as vendor websites or RSS feeds.
Requirement 8.5.1
Applicable to service providers only, Requirement 8.5.1 instructs service providers with remote access to customer premise to provide a unique authentication to each of their clients. Previously a best practice, this requirement recommends the use of technologies like two-factor mechanisms to provide unique credentials for each connection and meet this requirement.
Requirement 9.9
To meet this requirement, merchants need to ensure the physical safety of their POS terminals, preventing unauthorized personnel from modifying, substituting or tampering with them. Requirement 9.9 and its subsections emphasize on the need for inventories, inspections and trainings to prevent skimmers and fraudulent devices from collecting payment card information. However, it’s only recommended for manual key-entry components, not required.
Requirement 11.3
This requirement updates the PCI DSS Version 2.0 requirements for penetration tests. The purpose of a penetration test is to simulate an attack situation to identify how far an attacker can penetrate into an environment. This allows organizations to assess their potential exposure limit and develop strategies to counter attacks. According to PCI DSSS 3.1, the test should:
- Be based on industry approved penetration testing approaches
- Cover all the cardholder environment components and systems
- Test inside and outside the network
- Test to validate segmentation and scope reduction controls
- Define application layer penetrate tests to check for vulnerabilities such as injection flows, buffer overflows, and improper error handling
- Define network layer penetration tests
- Review threats and vulnerabilities that occurred within the last 12 months
- Offer remediation activities results
Requirement 12.4
Based on this requir`ment, organizations need to create security policy and procedures which define the information security responsibilities of all personnel. Without this practice, inconsistent interaction with the security group will be inevitable, leading to the implementation or use of outdated or unsecured technologies.
Requirement 12.8.5
Another vital requirement, Requirement 12.8.5 highlights the need to maintain information about which PCI DSS requirements are managed by service providers and which are managed by the organization itself. Through this requirement, the PCI Council aims to erase the industry’s confusion as to how third parties should be managed when only some aspects of PCI DSS apply to it while other requirements are considered shared responsibilities.
Requirement 12.9
An additional requirement for service providers only, Requirement 12.9 mandates that service providers acknowledge in writing which PCI DSS requirement they will maintain as part of their service. This requirement complements 12.8.5, but it targets service providers rather than merchants.
The Bottom Line
You have until June 30, 2016 to comply with PCI DSS 3.1, but new implementations won’t be using SSL or early TLS anymore. So make sure to have a Risk Mitigation and Migration plan that covers the following five aspects:
- A description of usage (e.g. what data is transmitted and the number of systems supporting the protocols)
- Risk assessment results and risk reduction controls
- Detailed processes to monitor and detect POODLE and FREAK
- Change control processes to prevent SSL and older TLS from being implemented in new environments
- Overview of migration project plan
