PCI DSS Requirement 6 Explained

Table of Contents show

PCI DSS Requirement 6: Develop and maintain secure systems and applications

Malicious people are exploiting vulnerabilities to gain privileged access to systems. Most of these vulnerabilities may be addressed by people who manage the systems or by security patches provided by the manufacturers.

All systems must have all appropriate software patches to protect against misuse and compromise of cardholder data by malicious individuals and malicious software.

Appropriate software patches are patches that have been properly evaluated and tested to determine that patches do not conflict with current security configurations. A large number of vulnerabilities can be avoided by using standard system development processes and secure coding techniques for in-house applications.

PCI DSS Requirement 6 deals with the development of secure applications and systems. It aims to properly manage security patches and secure system and application configurations to ensure continued protection against misuse or compromise of cardholder data.

Let’s take a look at all the sub-requirements found in PCI DSS requirement 6.

PCI DSS Requirement 6.1: Establish a process to identify vulnerabilities using reputable outside sources and assign a risk ranking to newly discovered vulnerabilities.

The purpose of this requirement is to make organizations aware of new vulnerabilities that could affect their environment. Vulnerability information sources must be reliable and can often be obtained from sources such as manufacturer’s websites, industry newsgroups, mailing lists, or RSS feeds.

See Also: Patching for Complying with PCI DSS Requirement 6

When an organization identifies a vulnerability that could affect its environment, the vulnerability risk must be assessed and rated. For this reason, the organization must have a method for continuously assessing and assigning risk rankings to vulnerabilities.

However, this method cannot be achieved with an ASV scan or internal network vulnerability scan. Instead, it is necessary to monitor industry resources for vulnerability information actively.

Classifying risks as “high”, “medium” or “low” allows organizations to identify, prioritize and address the highest risk vulnerabilities faster. In this way, attackers are less likely to exploit security vulnerabilities that pose the greatest risk.

The risk rankings should be based on industry best practices and consideration of the potential impact. For example, criteria for rating vulnerabilities may include taking into account the type of CVSS baseline or manufacturer classification and systems affected.

Methods for assessing vulnerabilities and assigning risk ratings can vary depending on an organization’s environment and risk assessment strategy. The risk ranking should at least describe all vulnerabilities that are considered “high risk” to the environment.

In addition to the risk rating, vulnerabilities can be considered “critical” if they pose a high threat to the environment, affect critical systems, or cause a potential compromise if not addressed.

Examples of critical systems may include security systems, public devices and systems, databases, and other systems that store, process or transmit cardholder data.

The process to identify vulnerabilities and assign risk rankings to vulnerabilities should include the following items:

  • New security vulnerabilities should be identified.
  • A risk ranking should be assigned that includes identification of all “high risk” and “critical” vulnerabilities.
  • Processes to identify new vulnerabilities should include using reputable outside sources for vulnerability information.

PCI DSS Requirement 6.2: Ensure that all system components and software are protected from known vulnerabilities by installing the applicable security patches provided by the manufacturer. Install critical security patches within a month.

There is a constant stream of attacks against otherwise secured systems that exploit widely published vulnerabilities, often referred to as a “zero-day” or an attack that exploits a previously unknown vulnerability.

The latest patches should be applied to critical systems as soon as possible. If critical patches are not applied in time, a malicious person could exploit these vulnerabilities to attack or disable a system or access sensitive data.

Prioritizing patches for critical infrastructures ensures that high priority systems and devices are protected from vulnerabilities as soon as a patch is released.

Critical or risky systems require the installation of critical or high-risk security patches within 30 days and other low-risk patches within 2-3 months.

This requirement applies to patches that apply to all installed software, including payment applications.

Critical security patches should be identified by the risk ranking process defined in PCI DSS Requirement 6.1.

PCI DSS Requirement 6.3: Develop internal and external software applications securely.

Security should be included in the definition, design, analysis and testing phases of the software development process. If security controls are not added to software development processes, vulnerabilities may be included unintentionally or maliciously in the live environment.

Understanding how sensitive data is processed by the application (when it is stored, when it is transmitted, and when it remains in memory) will help determine where the data should be protected.

Internal and external software applications should be developed securely, and the following items should be addressed in secure software development procedures:

  • The software must be developed by PCI DSS requirements. (For example, secure authentication and logging)
  • Must be based on industry standards or best practices.
  • Information security must be included throughout the software development lifecycle.

It should be noted that this requirement applies to all software developed internally as well as to custom software developed by third parties.

PCI DSS Requirement 6.3.1: Remove development, test or custom application accounts, user IDs, and passwords before applications become active or available to customers.

Development, test or custom app accounts, user IDs, and passwords must be removed via live code before the app becomes active or available to customers because these items can give important information about the operation of the application to malicious people. Having such important information can make it easier to compromise the app and associated cardholder data.

PCI DSS Requirement 6.3.2: Perform code reviews before applications are become active or released to customers to identify possible coding vulnerabilities.

Vulnerabilities in private code are commonly used by malicious actors to gain access to a network and compromise cardholder data.

The review process should involve a person who is knowledgeable and experienced in code review techniques. Code reviews should be carried out by someone other than the code developer to allow an independent and objective review.

Automated tools or processes can also be used for code reviews instead of manual reviews. Still, it should be noted that an automated tool can be difficult or even impossible to identify some coding issues.

Correcting coding errors before a live code is deployed or made available to customers prevents the code from exposing environments to potential abuse. Bad code is much more difficult and expensive to fix after it is deployed or released in production environments.

The management should establish a formal review and approval process before the code is published. Having a formal approval process helps ensure that the code is approved and developed by the procedures.

This code review requirement applies to all custom code as part of the system development lifecycle. Code reviews may be carried out by knowledgeable internal personnel or third parties.

Code reviews should include the following items:

  • Code changes should be reviewed by people other than the source code author and those who are familiar with code review techniques and secure coding practices.
  • Code reviews should ensure that the code is developed by safe coding guidelines.
  • Corrections with relevant results should be applied before the code is published.
  • Code review results should be reviewed and approved by management before they are published.

PCI DSS Requirement 6.4: Follow change control processes and procedures for all changes to system components.

Without properly documented and enforced change controls, security features can be deliberately or unintentionally neglected or rendered inoperable, transactional irregularities, or malicious code.

See Also: Change Control Management for PCI DSS

Change control processes and procedures should include the following:

  • Development/test environments must be separate from production environments with access control.
  • Duties should be separated between the staff assigned to the development/test environments and the staff assigned to the live environment.
  • Production data (live PANs) should not be used for testing or development purposes.
  • Test data and accounts must be removed before a production system can be activated.
  • Change control procedures should be documented for implementing security patches and changes to the software.

PCI DSS Requirement 6.4.1: Separate development and test environments from live environments and implement separation with access controls.

Ever-changing development and test environments tend to be less secure than live environments. If there is insufficient separation between environments, it may be possible for the live environment and cardholder data to be compromised due to fewer security configurations and possible vulnerabilities.

PCI DSS Requirement 6.4.2: Separation of duties between development, testing and live environments is required.

Reducing the number of staff with access to live media and cardholder data minimizes risk and helps ensure that access is limited to those with a business need to know.

The purpose of this requirement is to separate the development and test functions from the production functions. For example, a developer can use an administrator-level account with elevated privileges in the development environment and have a separate account with user-level access to the production environment.

See Also: What is the Separation of Duties Principle and How Is It Implemented?

In environments where an employee takes on multiple roles, tasks should be assigned so that no one has end-to-end control of a process that does not have an independent control mechanism. For example, responsibility for the development, authorization, and monitoring functions can be delegated to separate individuals.

PCI DSS Requirement 6.4.3: Production data (live PANs) are not used for testing or development.

Security controls are generally not that strict in test or development environments. The use of production data in such environments provides malicious individuals with the opportunity to gain unauthorized access to production data (cardholder data).

Payment card brands and many buyers can often provide appropriate account numbers for this purpose if realistic PANs are needed to test system functionality.

PCI DSS Requirement 6.4.4: Test data and accounts must be removed from system components before the system is enabled before going live.

Test data and accounts must be removed before the system component becomes active because these items can provide various important information about the functioning of the application or system. The fact that malicious people have such information can make it easier to compromise the system and related cardholder data.

PCI DSS Requirement 6.4.5: Change control procedures should include the following:

Suppose change control procedures are not properly managed. In that case, the impact of system changes such as hardware or software updates and the installation of security patches may go unnoticed and have unintended consequences.

Therefore, documented change control procedures should be established and include the following items:

  • Impact analysis documentation
  • Documented change approval by authorized parties
  • Functionality testing to verify that the change does not adversely affect the security of the system
  • Back-out procedures

PCI DSS Requirement 6.4.5.1: Document the impact of the change.

The impact of the change must be documented so that all affected parties can properly plan for any changes. In this way, a smooth process can be created by analyzing the possible effect of the change in advance.

PCI DSS Requirement 6.4.5.2: Changes require documented change approval by authorized parties.

The approval given by the authorized parties indicates that the change is legitimate and approved by the organization.

PCI DSS Requirement 6.4.5.3: Perform functionality test to verify that the change does not adversely affect the security of the system.

Extensive testing should be done to verify that the security of the environment is not compromised by implementing a change. The test should verify that all existing security controls remain in place, are replaced with equally robust controls, or strengthened after any changes have been made to the environment.

PCI DSS Requirement 6.4.5.4: Establish back-out procedures for changes.

For each change, there should be documented rollback procedures to allow the system to revert to its previous state if the change fails or adversely affects the security of an application or system.

PCI DSS Requirement 6.4.6: After a significant change is complete, all relevant PCI DSS requirements should be applied to all new or modified systems and networks, and documentation updated accordingly.

The use of mechanisms that evaluate significant changes helps ensure that all relevant PCI DSS controls are applied to all devices or networks implemented or modified in the covered environment.

Establishing this verification in change management processes helps ensure that device inventories and configuration standards are kept up to date, and security controls are enforced when necessary.

The change management process should include supporting evidence that PCI DSS requirements are implemented or maintained through the iterative process.

Examples of PCI DSS requirements that may be affected include the following:

  • The network diagram should be updated to reflect the changes.
  • Systems should be configured according to configuration standards by changing all default passwords and disabling unnecessary services.
  • Systems must be protected with necessary controls. Examples of controls include file integrity monitoring (FIM), anti-virus, patches, audit logging.
  • Sensitive authentication data (SAD) should not be stored, and the storage of all cardholder data (CHD) should be documented and included in data collection policy and procedures.
  • New systems should be included in the quarterly vulnerability scanning process.

PCI DSS Requirement 6.5: Address common coding vulnerabilities in software development processes.

The application layer carries a high risk and can be targeted by both internal and external threats. Requirements 6.5.1 through 6.5.10 specified by the PCI are the minimum controls that must be applied, and organizations should include relevant secure coding practices as applicable to the specific technology in their environment.

Application developers should be appropriately trained to identify and resolve issues with common coding vulnerabilities. Having staff knowledgeable about secure coding guidelines should minimize the number of vulnerabilities caused by poor coding practices.

Training for developers can be provided in-house or by third parties and must be valid for the technology used. As secure coding practices accepted by the industry change, corporate coding practices and developer training should likewise be updated to address new threats.

Be aware of vulnerability trends and include appropriate safeguards in secure coding practices.

Common coding vulnerabilities in software development processes should be addressed as follows:

  • Software developers are required to receive training at least annually in current secure coding techniques, including how to avoid common coding exploits.
  • Applications based on secure coding guidelines need to be developed.

Up-to-date secure code development methods should be followed by industry best practices such as OWASP Guidelines, SANS CWE Top 25, CERT Secure Coding.

PCI DSS Requirement 6.5.1: Consider injection flaws, specifically SQL injection, also OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

Injection flaws, especially SQL injection, are a common method used by attackers to gain unauthorized access to applications. Injection attacks happen when user-supplied data is sent to an interpreter as part of a command or query.

See Also: What is SQL Injection and How to Prevent It?

See Also: What is OS Command Injection and How to Prevent It?

See Also: What is LDAP Injection and How to Prevent It?

See Also: What is XPATH Injection and How to Prevent It?

The data provided by the attacker tricks the interpreter into executing unwanted commands or modifying data and allows the attacker to attack components within the network through the application, initiate attacks such as buffer overflows, or expose both confidential information and server application functionality.

Therefore, the information must be verified before sending to the application. For example, data such as all alpha characters, mixes of alpha and numeric characters should be verified by checking, and only the use of required characters should be allowed.

Injection flaws in software development policies and procedures should be addressed with coding techniques including:

  • Validating user data should not change the meaning of commands and queries.
  • Parameterized queries should be used.

PCI DSS Requirement 6.5.2: Buffer overflows

A buffer overflow occurs when more data is placed in a buffer reserved for data communication. In short, memory overflow is the overflow situation experienced when data over the planned amount is copied into a limited memory area.

In the case of buffer overflow, attackers can be used to do all kinds of operations if appropriate border controls are not applied. When this happens, the attacker will have the ability to add malicious code to the end of the buffer and then push the malicious code into executable memory space by overflowing the buffer. The malicious code is then run and usually allows the attacker remote access to the application or the infected system.

To avoid buffer overflows, encoding techniques including:

  • Appropriate boundary controls should be implemented.
  • Input data must be truncated accordingly.

PCI DSS Requirement 6.5.3: Unsecured cryptographic storage

Applications that do not properly use powerful cryptographic functions to store data are at risk of being exposed and exposing authentication information or cardholder data. If an attacker exploits weak cryptographic processes, they can open encrypted data and gain open access to the data.

Insecure cryptographic storage should be handled with the following coding techniques:

  • Cryptographic flaws must be prevented.
  • Strong cryptographic algorithms and keys should be used.

PCI DSS Requirement 6.5.4: Unsecured communications

When network traffic is not sufficiently encrypted by not using strong cryptography, cardholder data is at risk of exposure. If an attacker exploits weak cryptographic processes, they can take control of an application and gain explicitly unencrypted access to weakly encrypted data.

Unsecured communications need to be handled with coding techniques that properly encrypt all sensitive communications.

PCI DSS Requirement 6.5.5: Inappropriate error handling

Applications may inadvertently leak information about their configurations or internal operations, or reveal privileged information through improper error handling. Attackers can use this information to steal sensitive data or access the system.

If a malicious person creates errors that the application does not handle properly, they can obtain detailed system information, create service interruptions, circumvent security measures, or crash the server.

For example, the “wrong password entered” response indicates that the user ID provided to the attacker is correct and that they should focus their efforts solely on the password. In this case, more general error messages such as “Data could not be verified” should be used.

Improper error handling should be determined in software development policies, and procedures and error messages should be handled with information-proof coding techniques.

PCI DSS Requirement 6.5.6: All “high risk” vulnerabilities identified during the vulnerability identification process must be addressed.

All vulnerabilities identified as “high risk” by an organization’s vulnerability risk rating process, and that could affect the application must be identified and addressed during application development.

Software development policies and procedures need to address “high risk” vulnerabilities that coding techniques may affect the application as defined in PCI DSS Requirement 6.1.

PCI DSS Requirement 6.5.7: Cross-Site Scripting (XSS)

XSS flaws occur when the application receives data provided by the user without validation. XSS allows client-side code to be injected into web pages viewed by other users.

See Also: What is Cross-Site Scripting (XSS) and How to Prevent It?

With XSS, attackers can capture session information on users’ browsers, modify websites, or run malicious scripts.

For cross-site scripting (XSS) vulnerability in software development policies and procedures, coding techniques should be addressed, including:

  • The data should not be accepted without validation.
  • Characters that seem unnecessary should be cut off.

PCI DSS Requirement 6.5.8: Inappropriate access control

A direct object reference occurs when a developer presents a reference to an internal application object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can change these references to access other unauthorized objects.

Access controls must be applied consistently at the application layer and business logic for all URLs. The only way for an application to protect sensitive functionality is to prevent links or URLs from being viewed by unauthorized users.

Attackers can perform unauthorized actions by directly accessing these URLs. An attacker can enumerate and navigate the directory structure of a website so that they can gain access to unauthorized information and learn more about the functioning of the site for later exploitation.

If user interfaces allow access to unauthorized functions, this access can result in unauthorized persons gaining access to privileged credentials or cardholder data. Only authorized users should be allowed to access direct object references to sensitive resources. Limiting access to data sources will help prevent cardholder data from being made available to unauthorized sources.

Unsafe direct object references in software development policies and procedures, inability to restrict URL access or inappropriate access control, such as directory traversal, should be addressed with coding techniques that include:

  • Users must be properly authenticated.
  • Entries should be sanitized.
  • Internal object references should not be disclosed to users.
  • User interfaces that do not allow access to unauthorized functions should be designed.

PCI DSS Requirement 6.5.9: Cross-site request forgery (CSRF)

A CSRF attack forces the browser of a logged-on user to send a pre-authenticated request to a vulnerable web application. This way, the attacker can then realize what the victim is authorized to perform.

For example, the attacker can update the user’s account details, make purchases, and even authenticate the application with the CRSF attack.

Software development policies and procedures should address coding techniques that ensure that applications do not rely on authorization credentials and tokens sent automatically by browsers to prevent cross-site request forgery (CSRF).

PCI DSS Requirement 6.5.10: Broken authentication and session management.

Secure authentication and session management prevents unauthorized persons from compromising legitimate account credentials, keys, or session tokens that would allow them to assume the identity of an authorized user.

In software development policies and procedures, broken authentication and session management should be handled with coding techniques that include:

  • Session tokens (e.g. cookies) should be marked as “secure”.
  • Session identifications should not be exposed in the URL.
  • Controls such as appropriate timeouts and rotation of session IDs should be enforced after successful login.

PCI DSS Requirement 6.6: Constantly address new threats and vulnerabilities for Internet-facing web applications and ensure that these applications are protected from known attacks.

New threats and vulnerabilities must be constantly addressed for web applications open to the Internet, and it must be ensured that these applications are protected against attacks by one of the following methods:

  • Review web-facing web applications through manual or automated application vulnerability assessment tools or methods, at least annually and after any changes. This assessment is not the same as the vulnerability scans performed for PCI DSS Requirement 11.2.
  • Install an automated technical solution which detects and prevents attacks on the Web, such as a web application firewall, in front of public web applications to control all traffic continuously.

Externally visible web applications are primary targets for attackers, and poorly coded web applications provide an easy way for attackers to gain access to sensitive data and systems.

It aims to reduce the number of threats in public web applications due to the need to review applications or install web application firewalls, poor coding or application management practices.

Manual or automated vulnerability assessment tools or methods can be used to examine or test the application for vulnerabilities. Web application firewalls filter and block unnecessary traffic at the application layer.

When used in conjunction with a network-based firewall, a properly configured web application firewall prevents application-layer attacks if applications are incorrectly coded or configured. A combination of technology and process can achieve complete protection.

Process-based solutions should have mechanisms that facilitate the purpose of this requirement and respond to alerts promptly to prevent attacks.

Also, as long as an organization specializing in application security specializes in application security and can demonstrate independence from the development team, such services can be provided by a third-party company or an internal organization.

For public web applications, it is necessary to make sure that one of the following methods is in effect as follows:

  • Vulnerability scanning should be conducted at least annually or after any changes.
  • All identified security gaps must be closed.
  • Findings should be reconfirmed after corrections.
  • An application or device must be located in front of public web applications to detect and prevent web-based attacks.
  • It should work as a device or application and be updated appropriately.
  • Create a device or application audit logs.
  • The device or application must be configured to block web-based attacks or generate an alert to be investigated immediately.

 PCI DSS Requirement 6.7: Ensure security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.

Personnel must be aware of and comply with security policies and operational procedures to ensure that systems and applications are developed securely and are constantly protected from vulnerabilities.

For detailed information, see the PCI DSS Quick Reference Guide from the PCI SSC Documentation library.

To review all of the PCI DSS Requirements, you can review our PCI DSS Requirements and PCI Compliance articles.

Surkay Baykarahttp://www.pcidssguide.com
A passionate Senior Information Security Consultant working at Biznet. Over the past 15+ years my professional career has included several positions beginning as a developer and IT administrator, working my way up to a senior Technical Performance Consultant before joining Biznet back in 2015. I had several different roles at Biznet, including Penetration Tester and PCI DSS QSA. In my job as a QSA, I found my passion and worked closely with the Audit and Compliance team. I've been working inside InfoSec for over 15 years, coming from a highly technical background. I have earned several certifications during my professional career including; CEH, CISA, CISSP, and PCI QSA.

More from author

2 COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Related posts

Latest posts

What You Need to Know About PCI Validated Point-to-Point Encryption (P2PE) Solutions

P2PE, or point-to-point encryption, is a security standard developed by the Payment Card Industry (PCI) to ensure that payment card data is encrypted from the start to the finish of a transaction.

Email Security Best Practices

Most organizations rely heavily on emails for their daily business communication, but email remains one of the most common vectors businesses are attacked. This is why it is essential to implement email security best practices.

What Is Documentation Security and Why It Matters?

Documentation security is the maintenance of all essential documents stored, filed, backed up, processed, delivered, and eventually discarded when they are no longer needed.

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!