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

in Continuous Integration , Quality Assurance , DevSecOps , Monitoring and Observability , Process Management , DevOps

PCI DSS - Card Payment Requirements

Are you aware of what the new PCI DSS requirements entail?


    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.


    Get similar stories in your inbox weekly, for free



    Share this story with your friends
    debricked
    Debricked

    Debricked is a Swedish tech start-up on a journey to secure open source, one dependency at a time.

    Latest stories


    What Developers Think About GitHub Copilot

    GitHub Copilot is a controversial developer assistant introduced to the public in June 2021. It …

    Why Golang Is Widely Used in the DevOps and Cloud Native Space?

    The Golang programming language has been rising to popularity in the DevOps community in recent …

    The app used by the organization's staff for their activities, Facebook Workplace, is also down.
    Facebook, WhatsApp, Instagram Prolonged Downtime: Facts and Impacts

    A news report on a recent outage to the apps managed by Facebook inc.

    What are the criteria for selecting a Magento agency?

    Magento development company can help the business step up its eCommerce website to ensure its …

    7 Remote Working Tools That Simplify Your Work

    With the tools mentioned below, remote work has proven to become much more manageable.