The Payment Card Industry (PCI) is a coalition of credit card companies including American Express, Discover, MasterCard and Visa that is built on the backbone of 12 requirements specified in the PCI Data Security Standards (DSS). These requirements were implemented to ensure the continued financial safety of businesses and consumers alike. The number and severity of data breaches constantly on the rise and the PCI DSS requirements are there to provide organizations with the compliance framework they need to maintain a high level of network security.
With 69% of consumers being less inclined to do business with a breached organization that has fallen to the threats of an outsider gaining access to sensitive data, it is essential that during the companys process of building out their systems and applications that security is at the forefront of their focus. This article aims at giving you a comprehensive overview of the pertinent PCI DSS requirements that companies should focus on adhering to if they are committed to securing applications and systems only to be accessed by an authenticated user.
PCI DSS Requirements
One of the PCI DSS requirements that is thoroughly cited amongst organizations is requirement 6. This requirement is broken up into seven subsections which are important to companies to comply with during the building of applications and finalization of system processes. To maintain compliance with PCI DSS requirement 6, your organizations must develop and maintain appropriate security patches for all systems and applications (not just applications youve bought commercially or ones that youve developed) that are implemented within an appropriate amount of time. Doing so enables further protection of the cardholder data environment (CDE). The areas of focus that specifically pertain to the securing of applications and systems are detailed primarily within requirements 6.3, 6.4, and 6.5 below that we will be covering in the following headings:
| Section |
Requirements |
| 6.3 |
Incorporate information security throughout the software development life cycle [SDLC]. |
| 6.4 |
Follow change control processes and procedures for all changes to system components. |
| 6.5 |
Address common coding vulnerabilities in software-development processes. |
PCI DSS Requirement 6.3
Requirement 6.3 calls for companies to develop and maintain secure internal and external software applications specifically addressing the implementation of a secure software development lifecycle (SDLC), change controls, and secure coding standards. PCI DSS recommends that complying with this requirement be done via incorporating information security into several phases of your development process: requirement gathering, design, development, and testing:
| Phases |
Overview |
| Requirement Gathering |
Identify the necessary functional and technical specification requirements for applications to safely operate on. |
| Design |
Design an application that adheres to the appropriate PCI DSS requirement specifications. |
| Development |
Adequately train your developers regarding the necessary procedures to develop secure code on at least an annual basis. |
| Testing |
Before your application is pushed into production, assess how secure it is. This can be done via gathering test cases to verify that the application meets PCI DSS requirement specifications, design functions, and necessary security functionality. |
If your system is not adequately secured at the end of the testing phase, you will open your production environment to unintentional malicious security vulnerabilities. For this reason, PCI DSS policy requires that applications are validated via proper role-based access controls (RBAC). This is defined by PCI DSS as a Control used to restrict access by specific authorized users based on their job responsibilities. When RBACs are property implemented, they allow for a more systematic and repeatable setup for controls during the production phase. This allows the organization to audit user rights and correct any issues identified on the fly.
A securely developed software application should be able to function in a hardened application or operating system and be able to encrypt sensitive authentication data (SAD) in storage and transmission. The application should also be able to operate on a system that runs an antivirus program with the necessary supports for authentication controls. Doing so allows the application to be patched and updated regularly to ensure the safety and security of the companys network.
When your team is constantly under fire to innovate at rapid speeds, they must not lose sight of keeping the system secure through maintaining relevant code testing procedures. Management must be aware of these time constraints and factor in the appropriate amount of time into the SDLC to implement industry best practices and incorporate proper information security measures.
PCI DSS Requirement 6.4
Requirement 6.4 requires that your organization develops the appropriate methodology via a change control program that allows for the system or application to be fully secured during any changes. For your organization to be compliant with Requirement 6.4, you must ensure that the following essential security features are not unintentionally or deliberately omitted or rendered inoperable:
| Requirement |
Testing Procedures |
| 6.4 |
Obtain and examine company change control procedures related to implementing security patches and software modification. The organization must be able to trace changes back to related change control documentation. |
| 6.4.1 |
Verify that documentation of customer impact is included in the change control documentation for each sampled change. |
| 6.4.2 |
Verify that management sign-off by appropriate parties is present for each sampled change. |
| 6.4.3 |
Verify that operational functionality testing is performed for each sampled change. |
| 6.4.4 |
Verify that back-out procedures are prepared for each sampled change. |
| 6.4.5 |
Examine documented change control procedures related to implementing security patches and software modifications. Interview personnel to determine recent application changes and security patches. Verify that the interview information has been accurately documented. |
| 6.4.6 |
Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. |
PCI DSS requires that the change control program have a roll-back plan, testing phase, managements approval, and updated documentation in place prior to making any changes to applications. Your roll-back plan should outline the contingencies and processes that your company should follow if emergency changes should ever need to be implemented. The testing phase should be put in place to ensure that the CDE does not experience any negative impact during production testing. Managements approval deals with the necessary chain of command that is implemented for the change control program to go into effect. Lastly, organizations must have updated documentation that details any changes that your CDE has experienced. This documentation must include network diagrams, data flow diagrams, and inventory lists.
Requirement 6.4.6
A new update to PCI DSS Requirement 6 is Requirement 6.4.6 which was included in the recent PCI DSS changes that were required to be implemented February 1st, 2018 for organizations to stay compliant. It requires that your organization make some significant changes to your new or changed systems and networks with the necessary updated documentation.
The enforcement of this requirement ensures that organizations are in compliance with other PCI DSS requirements that might share similar qualities. This requirement ensures that change management isnt an afterthought for vulnerability scans, penetration tests, security risk assessments, and other security system tests. This way, even if significant changes were to affect the CDE, the organization would be able to quickly enforce the necessary changes within the change management process.
Organizations must be able to explain what constitutes a signification change to their CDE. This will look different for every organization. If any significant changes have been identified, they must be adequately documented to where a Quality Security Assessor (QSA) can assess that all relevant PCI requirements are still being adhered to after the necessary changes to the system or application. The implementation of this requirement ensures that the controls that are implemented allow for more efficiency and consistency in an emergency change management scenario.
PCI DSS Requirement 6.5
Compliance with Requirement 6.5 is incredibly important as it is the key step for securing web-based applications and protecting the financial data and personal information of thousands or potentially millions of customers. Requirement 6.5 requires that organizations adhere to stringent guidelines during the development of web applications. These guidelines are reinforced via the validation of potential vulnerabilities that web applications may incur. Testing and validating these potential vulnerabilities is essential to securing web applications that are documented in PCI DSS requirements 6.5.1 to 6.5.10 in the table below:
| Requirement |
Testing Procedures |
| 6.5 |
Obtain and review software development processes for web-based applications. Verify that developers are fully trained in secure coding techniques. Interview developers to obtain evidence that they are knowledgeable in these techniques. |
| 6.5.1 |
Validate all parameters of cross-site scripting (XSS) to ensure no vulnerabilities are present. |
| 6.5.2 |
Validate no injection flaws exist in web applications (particularly SQL Injection flaws). |
| 6.5.3 |
Validate there are no instances of malicious file execution in your web applications. |
| 6.5.4 |
Validate that insecure direct object references are not being exposed to users on web applications. |
| 6.5.5 |
Validate no instances of Cross-site request forgery (CSRF) are present in your web browsers. |
| 6.5.6 |
Validate that any instances of web application errors and/or information leakage are being handled appropriately. |
| 6.5.7 |
Ensure your web applications are not vulnerable to instances of broken authentication. |
| 6.5.8 |
Prevent insecure cryptographic storage flaws in your web applications. |
| 6.5.9 |
Properly encrypt all authenticated and sensitive communications that originate from your web applications. |
| 6.5.10 |
Consistently enforce access controls in the presentation layer and business logic for all web application URLs. |
Compliance with Requirement 6.5 requires a robust and ongoing program of web application security that includes consistent and rigorous testing that checks for key vulnerabilities during all phases of the SDLC. This requirement goes past the need for organizations to test their in-house web applications. The requirement also demands that the organization test their third-party software and open-source applications for the same potential vulnerabilities highlighted in Requirements 6.5.1 to 6.5.10.
Compliance with Requirement 6.5 entails that your organization addresses all common coding vulnerabilities in your software development processes via training your developers. Your developers must all have the necessary training on all secure coding techniques to ensure that they can develop web applications that adhere to secure coding guidelines. This can get costly for companies that keep dozens of developers on staff, thus it is recommended to outline a calendar for updates to training at least on an annual basis that covers all necessary vulnerability training updates.
If a QSA is auditing your organization, they will require that you show them evidence of these annual developer trainings. These trainings can be carried out in a format that best suits your organization if the trainings are carried out by a PCI approved instructor. The QSA will thoroughly analyze your web applications from the inside to gain the necessary visibility into how the secure code was developed and implemented. After this, the QSA will consolidate this information and judge whether the organizations developers need further training or security patches need to be implemented to keep vulnerabilities from developing.
Building a knowledgeable team of developers has many benefits for your organization, thus making compliance with Requirement 6.5 more of a positive for your company than you may think. Through extensive training, your developers can minimize the possibility of security vulnerabilities and become more efficient and effective at coding secure systems.
Closing Thoughts
Maintaining strong, role-based access controls (RBAC) and having a dedicated approach to ironing out potential vulnerabilities in your web applications will help our organization maintain its systems via secure coding techniques. With more than 234 million records with sensitive authentication data (SAD) having been breached since January 2005, the first line of defense for your organization should be patching up common vulnerabilities immediately. Complying with PCI DSS Requirements 6.3, 6.4, and 6.5 will ensure that your organization doesn’t become a data breach statistic that causes customers to run in the opposite direction of your web applications. Organizations who are unsure how to perform PCI DSS compliance measurements should contact RSI Security to seek cyber security solutions immediately.
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.