PCI-DSS 3.0 - Key Drivers

June 12, 2014 by

Security Ninja

Every organization should follow a proactive rather than a reactive approach to protect against threats, risks, and vulnerabilities to which if their IT infrastructure is exposed can lead to data loss, regulatory penalties, lawsuits, and damaged reputation. Moving on the same lines, to reduce credit card fraud via its exposure, a standard known as Payment Card Industry Data Security Standard (PCI DSS) was formed.

• History

Payment Card Industry Security Standards Council (PCI SSC) had developed a standard known as PCI Data Security Standard (PCI DSS), which comprises 12 core security areas to protect credit card holder data from theft, misuse, etc. These requirements apply to all entities involved in payment card processing, including merchants, processors, and 3rd party service providers that store, process and transmit cardholder data. PCI DSS originally began as five different programs:

• Visa's Cardholder Information Security Program
• MasterCard's Site Data Protection
• American Express' Data Security Operating Policy
• Discover's Information Security and Compliance
• JCB's Data Security Program

The motive of the above listed companies was to protect the card holder by providing some guidelines to merchants or any other entity which is involved in storing, processing and transmitting cardholder data. From the above listed companies, a PCI Security Standards Council (SSC) was formed, and the first version of PCI DSS 1.0 was released in December 2004. Because of rapid changes in technology, new mode of payments, attack vectors, regulatory laws, etc., this version got back to back updates from 1.1 to 1.2. PCI subsequent versions 2.0 and 3.0 were released in October 2010 and November 2013 respectively.

One major theme that forms the basis of PCI-DSS 3.0, apart from some notable ones like education and awareness around payment security, increased flexibility to handle risks, and security as a shared responsibility, is to make PCI-DSS a Business As Usual (BAU) practice. The purpose of this document is to outlay the key drivers that led to PCI-DSS 3.0. Below are the key drivers and challenges that lead to PCI-DSS 3.0.

• Lack of education and awareness around payment security

Due to lack of education and awareness around payment security, employees usually leave security holes in their developed applications by not following best security practices to code, picking up weak passwords, and sharing company information on public and social platforms. PCI-DSS 3.0 has incorporated requirements such as 8.4 that focus on personnel trainings, guidance around payment security, guidance for selecting and protecting authentication credentials, instructions to change passwords in case of any suspicion detected, etc.

The PCI-DSS council has gone a step ahead and also focuses on major sales points where card data is processed ie. POS terminal and brings these terminals under scope, as attacks on POS devices like cloning, addition of card skimmers, etc. are on a high. Requirement 9.9 which is to "Protect devices that capture card data via direct physical interaction with the card from tampering and substitution" is added to address the POS threat challenge. This requirement will now make organizations maintain an up-to date list of devices deployed at various sites. This list will contain information about POS devices such as:

This requirement also focuses on providing training for end-personnel to be aware about the attempted tampering or replacement of authentic POS devices. Organizations need to conduct periodic reviews of devices to check for any evidence of substitution or tampering.

• Third party security challenges

As per the security investigation report, 63 percent of security deficiencies that can result in breach or loss of cardholder data falls in the 3rd party IT landscape, whose business function is to process, transmit and store cardholder data received either from merchant or service providers. To handle crises whenever there is a breach resulting in cardholder data loss and no one to take ownership of that, PCI has added requirements 12.8, 12.9 to made it clear that both the engaging parties need to seal the deal with a written agreement, which should state a clear responsibility matrix. This requirement also requires the organization to do a proper due-diligence of the IT landscape, process, services offered, and security controls in place before entering into a formal agreement.

Along with the above stated requirement, PCI has also stated an additional requirement for service providers with requirement number 8.5.1 to maintain unique credentials for each customer when accessing their premises remotely for services like support of POS systems. This requirement will prevent the compromise of multiple customers' account profiles in case the service provider used the same credentials for all the service providers and that in turn is compromised. Also service providers must set up strong credentials to access customer premises and should adopt best practice policies like a password change policy, etc.

• Anti-malware solutions

The earlier PCI-DSS 2.0 standard specifies that there should be an antivirus solution deployed to protect the CDE environment from viruses, malware, etc. and that it should be completely updated with the latest patches and signatures, but the requirement did not specify about the access control settings over the AV software, such as access control over the AV manager, meaning who can only disable the AV solution and who can view its logs and edit the configuration changes. However in PCI-DSS 3.0, requirement 5.3 now requires organizations to deploy tighter policy based controls around antivirus solution that will require authorization to access and alter the configuration settings of the AV solution.

To keep controls deployment and maintenance costs in check, merchants generally come up with a classification of important endpoints that will be covered under security controls deployment like antivirus. Though asset classifications is a good practice, merchants do not generally update these lists with the ever-changing threat landscape. Keeping this in check, PCI-DSS has added a new requirement 5.1.2 which requires merchants to identify and evaluate evolving threats against systems which are not commonly affected by malicious software like mainframes, so as to develop a tighter antivirus security around all the systems in the CDE environment. Merchants can take guidance from vendors to understand the changing threat landscape and to evaluate whether their unprotected systems come under newly discovered vulnerabilities.

• Penetration testing

One of the key drivers and significant changes in PCI-DSS 3.0 is addition of the requirement for merchants to conduct penetration testing on their cardholder environment. SSC has laid emphasis on the point that merchants/service providers must adopt an industry wide accepted penetration testing like NIST SP 800-15. PCI requirements also need to conduct penetration tests not only at the application level but also at the network level against devices that are deployed at the perimeter (say for segregation) or deployed inside CDE environment. PCI requirement 13.4 would require providers to conduct:

• Inventory list

PCI has made it mandatory for retailers to maintain an inventory list of all the in-scope devices for CDE environment. With addition of requirement 2.4 which states, "Maintain an inventory of systems components that in scope of PCI DSS", PCI made sure that retailers keep updating their inventory list with the already in action system components or to any newly added one. To avoid any confusion, PCI has also mentioned in some drilled down requirements what all needs to be put in the inventory list, such as:

However, the above stated requirement to maintain an inventory list will be very difficult for organizations to maintain until they fully practice the requirement no 1.1.3 which requires organizations to maintain an updated data flow diagram (DFD) to showcase all the controls that are in CDE environment. With an updated DFD, organizations will be able to classify what is in-scope and out of scope for their CDE environment.

• Business as Usual (BaU)

One of the major themes of PCI-DSS 3.0 is to make it as a Business as Usual (BAU) Practice rather than compliance. As PCI-DSS covers a majority of mid-sized business that either do not have a large IT department or they have very few information security groups which can work to keep their business PCI-DSS-ready for audits and to incorporate any last minute hiccups. Making PCI-DSS as a BAU will require organizations to keep their PCI-DSS checklist updated regularly with any change in their CDE environment. Merchants should keep a check and document all the changes done in their cardholder data environment (CDE). These includes:

Conclusion

PCI-DSS 3.0 has incorporated some good new requirements as per the changing threat landscape, included the end user to understand about payment security, and clarified some statements for proper understanding of merchants and 3rd party service providers. Some of the changed requirements that are incorporated in PCI DSS 3.0 are termed as best practice for some time now, after which they will become mandatory for every organization to implement. PCI DSS 3.0 will surely make merchants, service providers or any entity that is processing, storing and transmitting cardholder data and is under PCI scope to revisit and enhance their existing strategy for protecting cardholder information.

References

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf