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 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. Payment Card Industry Data Security Standard (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 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. PCI DSS Build and Maintain a Secure Network and Systems Install and maintain a firewall configuration to protect cardholder data Requirement 1: Do not use vendor-supplied defaults for system passwords and other security parameters Requirement 2: Protect Cardholder Data Protect stored cardholder data Requirement 3: Encrypt transmission of cardholder data across open, public networks Requirement 4: Maintain a Vulnerability Management Program Protect all systems against malware and regularly update anti-virus software or programs Requirement 5: Develop and maintain secure systems and applications Requirement 6: Implement Strong Access Control Measures Restrict access to cardholder data by business need to know Requirement 7: Identify and authenticate access to system components Requirement 8: Restrict physical access to cardholder data Requirement 9: Regularly Monitor and Test Networks Track and monitor all access to network resources and cardholder data Requirement 10: Regularly test security systems and processes. Requirement 11: Maintain an Information Security Policy Maintain a policy that addresses information security for all personnel Requirement 12: 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. This is the actual requirement that compliance is validated against. PCI DSS Requirement: : This describes how compliance is validated by the assessor. Testing procedure : This is a more general description of the requirement aimed at helping to understand the intent of the requirement. Guidance 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, , 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 and the lists. developing and maintaining secure systems and applications OWASP Top 10 SANS Top 25 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 , 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. NVD 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 scoring system. You can also browse vulnerabilities on repo-, branch-, and even down to individual commit-level. CVSS 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: Address common coding vulnerabilities in software-development processes as follows: Requirement 6.5: 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.

Target

PCI DSS – Compliance Requirements and How to Meet Them

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Myths about Open Source Software (OSS)

A Guide to Building a Java Payment App Using Marqeta

Card vs. Open Banking Payments: A Comparative Analysis in the Fintech Landscape

Heard You are Into Modern Card Issuing and the Open API

"Millennials and Gen-Z are Managing Credit with Technology" - Leo Goriev

RuPay: The Indian Card Payment Alternative Rivals Visa and Mastercard

5 Myths about Open Source Software (OSS)

A Guide to Building a Java Payment App Using Marqeta

Card vs. Open Banking Payments: A Comparative Analysis in the Fintech Landscape

Heard You are Into Modern Card Issuing and the Open API

"Millennials and Gen-Z are Managing Credit with Technology" - Leo Goriev

RuPay: The Indian Card Payment Alternative Rivals Visa and Mastercard

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps