Is your business involved in any type of payment card processing? Then you need to be aware of the PCI DSS requirements. In this article, we take a closer look at some of the requirements defined by PCI DSS and show how they can be met.
Laws and regulations related to security and privacy are increasing, both in number and complexity. In the last two decades, we have witnessed a fast-evolving landscape dealing with how to best collect, process, store, and protect data and information. New regulations replace older ones, changing the scope, and court rulings set the current interpretations.
Understanding which apply to your business, and how to implement proper controls, can be a daunting task. GDPR applies to all organizations that collect or process data from EU residents, even non-EU organizations. HIPAA (extended by HITECH) only applies to U.S. organizations dealing with personal health information.
While these are examples of laws, the Payment Card Industry Data Security Standard (PCI DSS) is a contractual obligation that is not dictated by law. It applies to any organization that handles payment card information. Basically, if you want to handle such information, the payment card companies require you to meet the requirements set by PCI DSS.
PCI DSS originates from all major credit card companies seeing the need to sort out the interoperability between their respective requirements. Having one set of requirements, backed by all companies, allowed them to combine the efforts when setting the requirements. It also simplified the interpretation and implementation of security controls by companies that want to meet the requirements.
PCI DSS Requirements
The PCI DSS includes 12 overall requirements, divided into 6 general groups. These should be seen as minimum requirements. Additional controls may need to be used in order to comply with national or local laws and regulations.
Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security for all personnel
The requirements are general in the sense that they include aspects such as network security, physical security, vulnerability management, testing, and policies.
At the same time, these aspects are placed in the context of securing credit card transactions. Thus, they provide an excellent platform for understanding how to best implement security controls in an organization with this particular purpose. Network segmentation is not a requirement but should be used since it reduces the scope of the PCI DSS assessment.
The PCI DSS document provides a large number of more detailed descriptions for what is needed in order to meet the overall requirements. Each of these sub-requirements comes with three different descriptions.
- PCI DSS Requirement: This is the actual requirement that compliance is validated against.
- Testing procedure: This describes how compliance is validated by the assessor.
- Guidance: This is a more general description of the requirement aimed at helping to understand the intent of the requirement.
PCI DSS and Open Source Components
Most businesses these days use open source in their applications, and e-commerce is no exception. Keeping track of, and responding to, vulnerabilities in these components is part of the PCI DSS requirements.
In the following, we will particularly address this problem, see how it relates to PCI DSS, and show how it can be more easily managed.
The 6th requirement, developing and maintaining secure systems and applications, consists of sub-requirements focusing on secure software development and how to avoid vulnerabilities. It also lists particular vulnerabilities that the organizations must make sure to protect against. This list is inspired by the OWASP Top 10 and the SANS Top 25 lists.
The first two sub-requirements (6.1 and 6.2) specifically target identification, evaluation, and remediation of vulnerabilities. The first of these is stated as follows:
Requirement 6.1: Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.
Meeting this requirement is a difficult, time-consuming, and error-prone task. Many new vulnerabilities are disclosed every single day. Information about these can be in databases such as NVD, but they can also appear on mailing lists, security advisories or as issues on e.g., GitHub. In order to manage this more effectively, we would suggest to use the Debricked tool.
Debricked uses a number of vulnerability sources in order to continuously populate its database of vulnerabilities. It integrates seamlessly into your CI/CD pipeline and notifies you when any of your included software components has a new vulnerability.
Since it automatically identifies all your components, it relieves you of the pain of keeping track of all dependencies, both direct and transitive. Instead, you get an overview of all vulnerabilities, including their severity according to the CVSS scoring system. You can also browse vulnerabilities on repo-, branch-, and even down to individual commit-level.
You do not even need to trust it with your source code. It does not request access to any of your code, regardless of language and build system. In the meantime, by keeping track of all software components, Debricked also helps you with the requirement “2.4 Maintain an inventory of system components that are in scope for PCI DSS”.
The next requirement that Debricked handles is stated as follows:
Requirement 6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
Debricked not only identifies all your vulnerabilities and gives you the severity level for each. It also provides a suggested fix, showing exactly how and to which version you should update the dependency. Often, within minutes from the disclosure of a new vulnerability, you are provided with information on how to fix it.
Training and Awareness
In addition to the vulnerability assessment requirements described above, Debricked also provides training sessions, both for developers and other personnel. The need for such training is also recognized by PCI DSS:
Requirement 6.5: Address common coding vulnerabilities in software-development processes as follows:
Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. Develop applications based on secure coding guidelines.
Courses in web security and secure coding practices help developers stay on top of the fast-evolving technologies and threats organizations and their customers are facing today. It further provides developers with the knowledge and tools needed to avoid introducing new vulnerabilities in the in-house developed code. This results in higher security in the software and applications developed by the organization.