PCI DSS Requirement 6: Develop and Maintain Secure Systems

PCI DSS Requirement 6 highlights the importance of installing security patches in order to protect systems from being accessed by anyone with malicious intentions. For this to be effective - and to prevent exploitation or compromise of account data - all system components must have the necessary software patches installed in a reasonable timeframe.

Following software development lifecycle best practices, and using secure coding techniques, can mitigate vulnerabilities in bespoke and custom software. It’s important to note, however, that any code repositories or system configurations impacting account data security are subject to PCI DSS assessments, and should be considered during reviews.

For additional details on all 12 of the Requirements, read our PCI DSS Requirements overview.

Requirement 6 Details and Sections

Requirement 6 contains five sections that detail the procedures to develop and maintain secure systems and software.

• Requirement 6.1: Processes for developing and maintaining secure systems and software are defined and understood.
• Requirement 6.2: Custom software is developed securely.
• Requirement 6.3: Security vulnerabilities are identified and addressed.
• Requirement 6.4: Public-facing web applications are protected against attacks.
• Requirement 6.5: Changes to all system components are managed securely.

Requirement 6.1: Processes for developing and maintaining secure systems and software are defined and understood.

Requirement 6.1.1 details how to manage and maintain the various policies and procedures specified throughout Requirement 6. While defining the specific policies or procedures is important, it is equally critical to ensure these policies are properly documented, maintained, and shared as needed.

Defined approach requirements include:

• Requirement 6.1.1: All security policies and operational procedures that are identified in Requirement 6 are documented, up-to-date, used, and known to all affected parties.
• Requirement 6.1.2: Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood. 

Requirement 6.2: Custom software is developed securely.

Security should always be a primary consideration during the definition, design, and testing phases of software development to best prevent the introduction of vulnerabilities into any production environment.

For this to happen, all personnel having any impact on the software development process must be trained on security best practices relevant to their respective roles. This enables personnel to prevent, identify, and fix any security issues - even lesser known issues - before they’re introduced into any production environment.

Defined approach requirements include:

• Requirement 6.2.1: Bespoke and custom software are developed securely, based on industry standards and best practices for secure development, in accordance with PCI DSS, and in consideration of information security issues during each stage of the software development lifecycle.
• Requirement 6.2.2: Software development personnel are trained at least once every 12 months on software security relevant to their job function and development languages, including secure software design and secure coding techniques and how to use tools for detecting vulnerabilities in software.
• Requirement 6.2.3: Custom software is reviewed prior to release into production, to identify and correct potential coding vulnerabilities, as follows:
  • Code reviews ensure code is developed according to secure coding guidelines.
  • Code reviews look for both existing and emerging software vulnerabilities.
  • Appropriate corrections are implemented prior to release. 
  • Requirement 6.2.3.1: If manual code reviews are performed for custom software prior to production release, code changes are reviewed by individuals (other than the originating code author) knowledgeable in code review techniques and secure coding practices, and reviewed and approved by management prior to release. 
• Requirement 6.2.4: Software engineering techniques are defined by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in custom software, including:
  • Injection attacks
  • Attacks on data and data structures
  • Attacks on cryptography usage
  • Attacks on business logic
  • Attacks on access control mechanisms
  • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process

Requirement 6.3: Security vulnerabilities are identified and addressed.

Classifying risks into categories helps organizations identify, prioritize, and address the highest risk items first, with a special focus on secure vulnerabilities that pose the greatest security risk. This should include keeping track of all custom software, third-party components, and potential risks that these could introduce into the process.

Defined approach requirements include:

• Requirement 6.3.1: Security vulnerabilities are identified and managed as follows:
  • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information.
  • Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
  • Risk rankings identify, at a minimum, all vulnerabilities considered high risk to the environment.
  • Vulnerabilities for custom and third-party software are covered. 
• Requirement 6.3.2: Maintain an inventory of custom software and third-party components incorporated into software to facilitate vulnerability and patch management. 
• Requirement 6.3.3: All system components are protected from known vulnerabilities by installing applicable security patches and updates as follows:
  • Critical patches and updates are installed within one month of release.
  • All other security patches and updates are installed within an appropriate time frame as determined by the entity.

Requirement 6.4: Public-facing web applications are protected against attacks.

Public-facing applications - especially those without strong security posture - can become easy targets for attackers. Consistently scanning these applications, and implementing automated processes to do so, will help detect and mitigate any attacks that could occur.

Defined approach requirements include:

• Requirement 6.4.1: For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:
  • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools:
    • At least once every 12 months and after significant changes.
    • By an entity that specializes in application security.
    • Including, at a minimum, all common software attacks.
    • All vulnerabilities are ranked in accordance with requirement 6.3.1, and corrected.
    • The application is re-evaluated after the corrections.
  • OR, Installing automated technical solutions that detect and prevent web-based attacks:
    • Installed in front of public-facing web applications.
    • Actively running and up-to-date as applicable.
    • Generating audit logs.
    • Configured to either block web-based attacks or generate immediate alerts.
• Requirement 6.4.2: For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
  • Installed in front of public-facing web applications.
  • Actively running and up-to-date as applicable.
  • Generating audit logs.
  • Configured to either block web-based attacks or generate immediate alerts.
• Requirement 6.4.3: All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
  • Implement a method to confirm that each script is authorized.
  • Implement a method to assure the integrity of each script.
  • Maintain an inventory of all scripts with written justification as to why each is necessary. 

Requirement 6.5: Changes to all system components are managed securely. 

Change management procedures should be applied to all changes—including the addition, removal, or modification of any system component—in any production environment. Reasons for any change should be documented so that relevant parties understand and confirm the change is needed. 

Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes. 

Defined approach requirements include:

• Requirement 6.5.1: Changes to all system components in the production environment are made according to established procedures that include:
  • Reason for, and description of, the change.
  • Documentation of security impact.
  • Documented change approval by authorized parties.
  • Testing to verify that the change does not adversely impact system security.
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.
  • Procedures to address failures and return to a secure state.
• Requirement 6.5.2: Upon completion of a significant change, all applicable PCI DSS requirements are in place on all new or changed systems and networks, and documentation is updated as applicable. 
• Requirement 6.5.3: Pre-production environments are separated from production environments and the separation is enforced with access controls. 
• Requirement 6.5.4: Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. 
• Requirement 6.5.5: Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements. 
• Requirement 6.5.6: Test data and test accounts are removed from system components before the system goes into production.

How Basis Theory can help you Satisfy PCI DSS Requirement 6

Securing cardholder data in a CDE satisfies many PCI DSS requirements and provides companies greater control and flexibility over their payment stack. However, building and maintaining the necessary infrastructure and programs can require hundreds of thousands of dollars and months to implement and assess. Basis Theory provides the platform, infrastructure, and tools to secure cardholder data in minutes and without these costs and distractions.

As a PCI Level 1 compliant service provider, Basis Theory extends an independently assessed and approved CDE to customers. Combined with a suite of configurable tools, services, and tokens, companies can collect, secure, and share credit cards without bringing their systems into scope. This approach allows companies to avoid the costs and distractions associated with 95% of the requirements in the Payment Card Industry Data Security Standard (PCI DSS) while retaining complete control over their cardholder data.

*PCI DSS Requirement information contained in this post is for educational purposes only and references material from the guide "Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0" published by the PCI SSC in March 2022. Please refer to the PCI Security Standards Council website for the complete, up-to-date, accurate requirements.