Requirement 6: Develop And Maintain Secure Software

Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For bespoke and custom software, numerous vulnerabilities can be avoided by applying software lifecycle (SLC) processes and secure coding techniques. Code repositories that store application code, system configurations, or other configuration data that can impact the security of account data or the CDE are in scope for PCI DSS assessments.

Requirement 6: Develop And Maintain Secure Software

6.1 Processes And Mechanisms For Developing And Maintaining Secure Systems And Software Are Defined And Understood

6.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

6.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

6.2 Bespoke And Custom Software Are Developed Securely

6.2.1 Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development • In accordance with PCI DSS (for example, secure authentication and logging) • Incorporating consideration of information security issues during each stage of the software development lifecycle

Understanding how sensitive data is handled by the application including when stored, transmitted, and in memory can help identify where data needs to be protected.

PCI DSS requirements must be considered when developing software to meet those requirements by design, rather than trying to retrofit the software later.

6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: • On software security relevant to their job function and development languages • Including secure software design and secure coding techniques • Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software

Training for developers may be provided in-house or by third parties.

Training should include, but is not limited to, development languages in use, secure software design, secure coding techniques, use of techniques/methods for finding vulnerabilities in code, processes to prevent reintroducing previously resolved vulnerabilities, and how to use any automated security testing tools for detecting vulnerabilities in software.

As industry-accepted secure coding practices change, organizational coding practices and developer training may need to be updated to address new threats.

6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, 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

The following items should be considered for inclusion in code reviews:

Searching for undocumented features (implant tools, backdoors).

Confirming that software securely uses external components’ functions (libraries, frameworks, APIs, etc.). For example, if a third-party library providing cryptographic functions is used, verify that it was integrated securely.

Checking for correct use of logging to prevent sensitive data from getting into logs.

Analysis of insecure code structures that may contain potential vulnerabilities related to common software attacks.

Checking the application’s behavior to detect logical vulnerabilities.

6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are: • Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices • Reviewed and approved by management prior to release

Having a formal review methodology and review checklists has been found to improve the quality of the code review process.

Code review is a tiring process, and for this reason, it is most effective when reviewers only review small amounts of code at a time.

To maintain the effectiveness of code reviews, it is beneficial to monitor the general workload of reviewers and to have them review applications they are familiar with.

Code reviews may be performed using either manual or automated processes, or a combination of both.

Entitles that rely solely on manual code review should ensure that reviewers maintain their skills through regular training as new vulnerabilities are found, and new secure coding methods are recommended.

6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following: • Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws • Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data • Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation • Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF) • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process

For both bespoke and custom software, the entity must ensure that code is developed focusing on the prevention or mitigation of common software attacks, including:

Attempts to exploit common coding vulnerabilities (bugs).

Attempts to exploit software design flaws.

Attempts to exploit implementation/configuration flaws.

Enumeration attacks automated attacks that are actively exploited in payments and abuse identification, authentication, or authorization mechanisms.

Researching and documenting software engineering techniques or other methods helps to define how software developers prevent or mitigate various software attacks by features or countermeasures they build into software. This might include identification/authentication mechanisms, access control, input validation routines, etc. Developers should be familiar with different types of vulnerabilities and potential attacks and use measures to avoid potential attack vectors when developing code.

6.3 Security Vulnerabilities Are Identified And Addressed

6.3.1 Security vulnerabilities are identified and managed as follows: • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs) • 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 to be a high-risk or critical to the environment • Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered

Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk-assessment strategy.

When an entity is assigning its risk rankings, it should consider using a formal, objective, justifiable methodology that accurately portrays the risks of the vulnerabilities pertinent to the organization and translates to an appropriate entity-assigned priority for resolution.

An organization’s processes for managing vulnerabilities should be integrated with other management processes for example, risk management, change management, patch management, incident response, application security, as well as proper monitoring and logging of these processes. This will help to ensure all vulnerabilities are properly identified and addressed. Processes should support ongoing evaluation of vulnerabilities. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities, individually considered to be low or medium risk, could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE.

6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management

An entity’s inventory should cover all payment software components and dependencies, including supported execution platforms or environments, third-party libraries, services, and other required functionalities.

There are many different types of solutions that can help with managing software inventories, such as software composition analysis tools, application discovery tools, and mobile device management.

6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Critical or high-security patches/updates are installed within one month of release • All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release)

Prioritizing security patches/updates for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released.

An entity’s patching cadence should factor in any re-evaluation of vulnerabilities and subsequent changes in the criticality of a vulnerability. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities individually considered to be low or medium risk could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE.

6.4 Public-Facing Web Applications Are Protected Against Attacks

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 or methods as follows: – 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 – All vulnerabilities are corrected – The application is re-evaluated after the corrections OR • Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows: – Installed in front of public-facing web applications to detect and prevent web-based attacks – Actively running and up to date as applicable – Generating audit logs – Configured to either block web-based attacks or generate an alert that is immediately investigated

Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities.

Common assessment tools include specialized web scanners that perform automatic analysis of web application protection.

When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated.

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: • Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks • Actively running and up to date as applicable • Generating audit logs • Configured to either block web-based attacks or generate an alert that is immediately investigated

When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated. Such solutions may also be used to automate mitigation, for example rate-limiting controls, which can be implemented to mitigate against brute-force attacks and enumeration attacks.

6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: • A method is implemented to confirm that each script is authorized • A method is implemented to assure the integrity of each script • An inventory of all scripts is maintained with written justification as to why each is necessary

Scripts may be authorized by manual or automated (e.g., workflow) processes.

Where the payment page will be loaded into an inline frame (IFRAME), restricting the location that the payment page can be loaded from, using the parent page’s Content Security Policy (CSP) can help prevent unauthorized content being substituted for the payment page.

6.5 Changes To All System Components Are Managed Securely

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 before being deployed into production • Procedures to address failures and return to a secure state

Approval by authorized parties confirms that the change is legitimate and that the change is sanctioned by the organization. Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change.

Thorough testing by the entity confirms that the security of the environment is not reduced by implementing a change and that all existing security controls either remain in place or are replaced with equal or stronger security controls after the change. The specific testing to be performed will vary according to the type of change and system component(s) affected.

For each change, it is important to have documented procedures that address any failures and provide instructions on how to return to a secure state in case the change fails or adversely affects the security of an application or system. These procedures will allow the application or system to be restored to its previous secure state.

6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable

Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed.

6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls

Organizations must clearly understand which environments are test environments or development environments and how these environments interact on the level of networks and applications.

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

The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access.

The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity).

Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets.

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

Entities can minimize their storage of live PANs by only storing them in pre-production when strictly necessary for a specific and defined testing purpose and securely deleting that data after use.

If an entity requires PANs specifically designed for test purposes, these can be obtained from acquirers.

6.5.6 Test data and test accounts are removed from system components before the system goes into production

This data may give away information about the functioning of an application or system and is an easy target for unauthorized individuals to exploit to gain access to systems. Possession of such information could facilitate compromise of the system and related account data.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your software development environment and cardholder data is sitting on the server dz-win10.

Requirement 6.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirement 6.2

This requirement is very detailed. First, the developers should be trained on information security at least once every 12 months. It includes secure software design and secure coding techniques etc. The developers should prevent common attacks e.g. SQL injection, cross-site scripting etc.

Requirement 6.3

This requirement is about software vulnerabilities. Critical or high-security patches/updates are installed within one month of release. If the software depends upon other components (frameworks, operating systems etc), it should be assessed for known vulnerabilities. In our example, virtualization software is one of the dependencies.

Requirement 6.4

If the software is a public-facing website, it should be reviewed at least once every 12 months and after significant changes. It should be protected by a web application firewall (WAF). In our example, dz-win10 is not accessible from the internet.

Requirement 6.5

This requirement highlights the segregation of production and pre-production environments, concerning roles and functions, data sensitivity e.g. live PAN. Most of the requirements can be managed with Source code management (SCM) tools and best practices.