PCI DSS Requirements - Managing Security Vulnerabilities when Handling Payment Card Processing

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.

How can these requirements be met?

Debricked’s services primarily include assistance in the identification and evaluation of vulnerabilities in third-party and open source components. Such components are extensively used in all types of software and applications. Virtually all organizations handling credit card information heavily rely on open source components, and keeping track of, and respond 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 Debricked can improve the security of your software.

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. Debricked uses a number of vulnerability sources in order to continuously populate its database of vulnerabilities. We integrate seamlessly into your CI/CD pipeline and notify you when any of your included software components has a new vulnerability. Since we automatically identify all your components, we relieve 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 us with your source code. We do all this without access to any of your code - regardless of language and build system. In the meantime, by keeping track of all software components, we also help 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. We also provide a suggested fix, showing exactly how and to which version you must 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.

Our 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.