PCI DSS Requirements - Managing Security Vulnerabilities when Handling Payment Card Processing
in DevOps , DevSecOps , Process Management , Monitoring and Observability , Quality Assurance , Continuous Integration
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:
Debricked is a Swedish tech start-up on a journey to secure open source, one dependency at a time.
The all-in-one monitoring solution for IT admins, DevOps and SREs
Get deep visibility into the performance of your complex enterprise applications and cloud native workloads. Identify potential issues, improve productivity, and ensure that your business and end users are unaffected by downtime and substandard performance ...
How ManageEngine Applications Manager Can Help Overcome Challenges In Kubernetes Monitoring
We tested ManageEngine Applications Manager to monitor different Kubernetes clusters. This post shares our review …
IT Monitoring Powered by AIOps
Harness the power of artificial intelligence (AI) and machine learning (ML) to monitor your IT resources with Site24x7's artificial intelligence for IT operations (AIOps) and machine learning operations (MLOps). Improve mean time to repair (MTTR) issues with the help of Site24x7 AIOps ...
AIOps with Site24x7: Maximizing Efficiency at an Affordable Cost
In this post we'll dive deep into integrating AIOps in your business suing Site24x7 to …
A Review of Zoho ManageEngine
Zoho Corp., formerly known as AdventNet Inc., has established itself as a major player in …
Should I learn Java in 2023? A Practical Guide
Java is one of the most widely used programming languages in the world. It has …
The fastest way to ramp up on DevOps
You probably have been thinking of moving to DevOps or learning DevOps as a beginner. …
Why You Need a Blockchain Node Provider
In this article, we briefly cover the concept of blockchain nodes provider and explain why …
Top 5 Virtual desktop Provides in 2022
Here are the top 5 virtual desktop providers who offer a range of benefits such …