Companies that process credit card payments must comply with the Payment Card Industry (PCI) Data Security Standard (DSS). Compliance efforts require all PCI-eligible companies to implement all Requirements within the DSS framework, then document the security controls protecting cardholder data (CHD) via official PCI assessment. Read on for an in-depth description of what to expect when implementing and reporting PCI DSS Requirement 6.
Securing Applications and Systems: PCI DSS Requirement 6
In total, the PCI DSS breaks down into six goals, which house twelve Requirements. The sixth Requirement—sometimes incorrectly referred to as PCI level 6 or PCI DSS 6 control objectives—concerns securing all systems and applications developed or used by the company. Most Requirements break down further into sub-requirements, and PCI Requirement 6 comprises seven of these:
- PCI DSS Requirement 6.1
- PCI DSS Requirement 6.2
- PCI DSS Requirement 6.3
- PCI DSS Requirement 6.4
- PCI DSS Requirement 6.5
- PCI DSS Requirement 6.6
- PCI DSS Requirement 6.7
Three of these sub-requirements break down further into sub-sub-requirements, which detail the actual controls companies need to implement. The PCI DSS framework also comprises Testing Procedures that prescribe how sub-requirements’ controls will be tested.
PCI DSS 6.1: Establish a Risk Ranking System for Vulnerabilities
The first sub-requirement of Requirement 6 is PCI DSS Requirement 6.1. It mandates that DSS-applicable companies establish formalized processes for identifying and addressing vulnerabilities that impact applications and systems they develop or use.
Specifically, 6.1 stipulates that reputable outside sources, like the Common Vulnerabilities and Exposures (CVE) list, should inform merchants’ policies. In addition, companies must also assign risk rankings (i.e., low, medium, high) to all identified vulnerabilities.
There are no explicit sub-sub-requirements within PCI DSS Requirement 6.1. Instead, its Testing Procedures begin with examining company policies and procedures. Merchants must verify that risk identification and ranking processes are formally defined, per reputable outside sources (6.1.a). Assessors will also interview relevant personnel to confirm these controls are pragmatically carried out in the execution of daily tasks (6.1.b).
Request a Free Consultation
PCI DSS 6.2: Apply Patches for all Known Security Vulnerabilities
Next up is the second sub-requirement, PCI DSS Requirement 6.2. It mandates that DSS-applicable companies ensure protection against all known vulnerabilities by installing security patches as soon as possible—once they’re made available by vendors.
Specifically, PCI DSS 6.2 calls for the installation of critical patches no later than one month after their publication. Necessity depends upon the affected resources’ risk ratings, as determined by the processes established for Requirement 6.1.
Like PCI DSS Requirement 6.1, there are no sub-sub-requirements under 6.2. However, Testing Procedures begin with scanning applicable policies and procedures to confirm patch installation (6.2.a). Assessors will also scan a representative sample of system components. The scan results will be cross-referenced with vendors’ lists of available patches to ensure that they were installed within a proper time frame.
PCI DSS 6.3: Develop Internal, External, and Web Apps Securely
The third sub-requirement for PCI Requirement 6 is the first to feature sub-sub-requirements. Namely, PCI DSS Requirement 6.3 mandates secure development of internal and external apps via:
- PCI DSS 6.3.1 – Remove any accounts and settings created for development or testing purposes prior to making applications or software publicly available or usable by clients.
- PCI DSS 6.3.2 – Review all custom code for vulnerabilities, manually or via automation, prior to making developed applications or software publicly available or usable by clients.
Testing Procedures for each of these sub-sub-requirements include examining all policies for staff involved in their execution, along with interviewing personnel to confirm proper protocols.
PCI DSS 6.4: Install Change Control Processes and Procedures
Next up is the fourth sub-requirement for secure systems and apps, DSS Requirement 6.4. It mandates that PCI-eligible companies ensure all personnel follow change control procedures, including:
- PCI DSS 6.4.1 – Separate all development or test environments from production ones.
- PCI DSS 6.4.2 – Separate duties between development and production environments.
- PCI DSS 6.4.3 – Ensure production data is not used for any development or testing.
- PCI DSS 6.4.4 – Remove all test-related data from components prior to activation.
- PCI DSS 6.4.5 – Implement change control procedures, including but not limited to:
- Documentation of change impact (per 6.4.5.1) and approval (6.4.5.2)
- Testing of functionality (6.4.5.3) and back-out procedures (6.4.5.4)
- PCI DSS 6.4.6 – Ensure implementation of all DSS Requirements after changes.
Testing Procedures for each of these sub-sub-requirements include examining all policies for staff involved in their execution, along with interviewing personnel to confirm proper protocols.
PCI DSS 6.5: Address All Common Development Vulnerabilities
The fifth sub-requirement at Requirement 6—PCI DSS Requirement 6.5—mandates controls for mitigating the most common coding vulnerabilities. As of the publication of v.3.2.1 (May 2018), the sub-sub-requirements for Requirement 6.5 are:
- PCI DSS 6.5.1 – Protect against all injection flaws for all applications (e.g., SQL, OS Command).
- PCI DSS 6.5.2 – Protect against all buffer overflow or buffer overrun vulnerabilities.
- PCI DSS 6.5.3 – Protect against all insufficiently secure cryptographic key storage.
- PCI DSS 6.5.4 – Protect against insufficiently secure communications and traffic
- PCI DSS 6.5.5 – Protect against all improper error handling behaviors by users.
- PCI DSS 6.5.6 – Protect against all threats rated as “high risk” per Requirement 6.1.
- PCI DSS 6.5.7 – Protect against cross-site scripting (XSS) risks across web apps.
- PCI DSS 6.5.8 – Protect against improper access control measures across web apps.
- PCI DSS 6.5.9 – Protect against cross-site request forgery (CSRF) across web apps.
- PCI DSS 6.5.10 – Protect against authentication management flaws across web apps.
Testing Procedures for each of these sub-sub-requirements include examining all policies for staff involved in their execution, along with interviewing personnel to confirm proper protocols.
PCI DSS 6.6: Adjust for New and Known Threats in Web Apps
The penultimate sub-requirement for securing apps and systems is PCI Requirement 6.6. It mandates review of all public-facing web applications to protect external users against known attacks and other threats.
Specifically, 6.6 stipulates that companies engage in regular, automated or manual reviews of public-facing web apps with at least annual frequency. Another option is to install an automated detection or prevention solution within or in front of web apps to monitor traffic.
There are no sub-sub-requirements specified for PCI DSS Requirement 6.6. However, its Testing Procedures require ensuring that one of the solutions specified just above is present, appropriately configured, and documented. Note that these assessments or scans operate independently of those similarly focused and established in one of PCI Requirement 11’s sub-requirements: 11.2.
PCI DSS 6.7: Document all System and Application Controls
The final sub-requirement within PCI Requirement 6 mandates formal documentation for all other controls, roles, and responsibilities contained within the following six sub-requirements. The Testing Procedures for Requirement 6.7 include examining all documentation and conducting interviews with personnel. Assessors will gauge whether all policies and procedures for Requirements 6.1 to 6.6 are:
- Formally documented, including appropriate, prescriptive language for all personnel
- In use throughout the company and by all stakeholders to whom the sub-requirements are applicable
- Known by all parties directly responsible for control or that are otherwise impacted by it
All PCI DSS Requirements except Requirement 12 have a sub-requirement similar to this one, mandating formal documentation. Requirement 12 comprises further specifications for all other Requirements’ individual documentation sub-requirements—including those in Requirement 6.7.
Rethink Your PCI Compliance and Cyberdefense with RSI Security
Companies seeking PCI compliance must implement all controls within the DSS framework, not just for PCI DSS Requirement 6. Regardless, the seven sub-requirements within Requirement 6 are among the most critical to your company’s success defending CHD—especially if you rely heavily on internal and external applications to process it.
RSI Security is well equipped to help you rethink your implementation of all PCI requirements—contact us today to get started!