{"id":253,"date":"2020-04-07T16:39:06","date_gmt":"2020-04-07T16:39:06","guid":{"rendered":"http:\/\/www.pcidssguide.com\/?p=253"},"modified":"2023-10-09T07:46:45","modified_gmt":"2023-10-09T07:46:45","slug":"pci-dss-requirement-6","status":"publish","type":"post","link":"https:\/\/pcidssguide.com\/pci-dss-requirement-6\/","title":{"rendered":"PCI DSS Requirement 6 Explained"},"content":{"rendered":"\n\n\n\n\n
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.<\/p>\n\n\n\n
See Also: PCI Web Application Security Requirements<\/a><\/strong><\/p>\n\n\n\n All systems must have all appropriate software patches to protect against misuse and compromise of cardholder data by malicious individuals and malicious software.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Let\u2019s take a look at all the sub-requirements found in PCI DSS requirement 6.<\/p>\n\n\n\n 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\u2019s websites, industry newsgroups, mailing lists, or RSS feeds.<\/p>\n\n\n\n See Also: Patching for Complying with PCI DSS Requirement 6<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Classifying risks as \u201chigh\u201d, \u201cmedium\u201d or \u201clow\u201d 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Methods for assessing vulnerabilities and assigning risk ratings can vary depending on an organization\u2019s environment and risk assessment strategy. The risk ranking should at least describe all vulnerabilities that are considered \u201chigh risk\u201d to the environment.<\/p>\n\n\n\n In addition to the risk rating, vulnerabilities can be considered \u201ccritical\u201d if they pose a high threat to the environment, affect critical systems, or cause a potential compromise if not addressed.<\/p>\n\n\n\n Examples of critical systems may include security systems, public devices and systems, databases, and other systems that store, process or transmit cardholder data.<\/p>\n\n\n\n The process to identify vulnerabilities and assign risk rankings to vulnerabilities should include the following items:<\/p>\n\n\n\n There is a constant stream of attacks against otherwise secured systems that exploit widely published vulnerabilities, often referred to as a \u201czero-day\u201d or an attack that exploits a previously unknown vulnerability.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Prioritizing patches for critical infrastructures ensures that high priority systems and devices are protected from vulnerabilities as soon as a patch is released.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n This requirement applies to patches that apply to all installed software, including payment applications.<\/p>\n\n\n\n Critical security patches should be identified by the risk ranking process defined in PCI DSS Requirement 6.1.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: What Does PCI Compliant Software Development Mean for Developers<\/a><\/strong> <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Internal and external software applications should be developed securely, and the following items should be addressed in secure software development procedures:<\/p>\n\n\n\n It should be noted that this requirement applies to all software developed internally as well as to custom software developed by third parties.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Vulnerabilities in private code are commonly used by malicious actors to gain access to a network and compromise cardholder data.<\/p>\n\n\n\n See Also: How to Perform Code Reviews for PCI Requirements<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Code reviews should include the following items:<\/p>\n\n\n\n Without properly documented and enforced change controls, security features can be deliberately or unintentionally neglected or rendered inoperable, transactional irregularities, or malicious code.<\/p>\n\n\n\n See Also: Change Control Management for PCI DSS<\/a><\/strong><\/p>\n\n\n\n Change control processes and procedures should include the following:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: What is the Separation of Duties Principle and How Is It Implemented?<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n Payment card brands and many buyers can often provide appropriate account numbers for this purpose if realistic PANs are needed to test system functionality.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Therefore, documented change control procedures should be established and include the following items:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: What Are the Impact Analysis Requirements for PCI DSS Compliance<\/a><\/strong><\/p>\n\n\n\n The approval given by the authorized parties indicates that the change is legitimate and approved by the organization.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The change management process should include supporting evidence that PCI DSS requirements are implemented or maintained through the iterative process.<\/p>\n\n\n\n Examples of PCI DSS requirements that may be affected include the following:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: Best Practices and Recommendations for API Security<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Be aware of vulnerability trends and include appropriate safeguards in secure coding practices.<\/p>\n\n\n\n Common coding vulnerabilities in software development processes should be addressed as follows:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: What is SQL Injection and How to Prevent It?<\/a><\/strong><\/p>\n\n\n\n See Also: What is OS Command Injection and How to Prevent It?<\/a><\/strong><\/p>\n\n\n\n See Also: What is LDAP Injection and How to Prevent It?<\/a><\/strong><\/p>\n\n\n\n See Also: What is XPATH Injection and How to Prevent It?<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Injection flaws in software development policies and procedures should be addressed with coding techniques including:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n To avoid buffer overflows, encoding techniques including:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Insecure cryptographic storage should be handled with the following coding techniques:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Unsecured communications need to be handled with coding techniques that properly encrypt all sensitive communications.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n For example, the \u201cwrong password entered\u201d 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 \u201cData could not be verified\u201d should be used.<\/p>\n\n\n\n Improper error handling should be determined in software development policies, and procedures and error messages should be handled with information-proof coding techniques.<\/p>\n\n\n\n All vulnerabilities identified as \u201chigh risk\u201d by an organization\u2019s vulnerability risk rating process, and that could affect the application must be identified and addressed during application development.<\/p>\n\n\n\n Software development policies and procedures need to address \u201chigh risk\u201d vulnerabilities that coding techniques may affect the application as defined in PCI DSS Requirement 6.1.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: What is Cross-Site Scripting (XSS) and How to Prevent It?<\/a><\/strong><\/p>\n\n\n\n With XSS, attackers can capture session information on users\u2019 browsers, modify websites, or run malicious scripts.<\/p>\n\n\n\n For cross-site scripting (XSS) vulnerability in software development policies and procedures, coding techniques should be addressed, including:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n For example, the attacker can update the user\u2019s account details, make purchases, and even authenticate the application with the CRSF attack.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n In software development policies and procedures, broken authentication and session management should be handled with coding techniques that include:<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Process-based solutions should have mechanisms that facilitate the purpose of this requirement and respond to alerts promptly to prevent attacks.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n For public web applications, it is necessary to make sure that one of the following methods is in effect as follows:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n For detailed information, see the PCI DSS Quick Reference Guide<\/a><\/strong> from the PCI SSC Documentation library.<\/p>\n\n\n\n To review all of the PCI DSS Requirements, you can review our PCI DSS Requirements<\/a><\/strong> and PCI Compliance<\/a><\/strong> articles.<\/p>\n","protected":false},"excerpt":{"rendered":" Unscrupulous people are exploiting bugs to gain privileged access to programs. Many of these bugs are addressed by the manufacturer’s security patches, which must be implemented by the device-running organizations.<\/p>\n","protected":false},"author":1,"featured_media":355,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[19,28,20],"tags":[54,62,56],"yoast_head":"\nPCI DSS Requirement 6.1: Establish a process to identify vulnerabilities using reputable outside sources and assign a risk ranking to newly discovered vulnerabilities.<\/strong><\/h2>\n\n\n\n
\n
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.<\/strong><\/h2>\n\n\n\n
PCI DSS Requirement 6.3: Develop internal and external software applications securely.<\/strong><\/h2>\n\n\n\n
\n
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.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.3.2: Perform code reviews before applications are become active or released to customers to identify possible coding vulnerabilities.<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.4: Follow change control processes and procedures for all changes to system components.<\/strong><\/h2>\n\n\n\n
\n
PCI DSS Requirement 6.4.1: Separate development and test environments from live environments and implement separation with access controls.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.4.2: Separation of duties between development, testing and live environments is required.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.4.3: Production data (live PANs) are not used for testing or development.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.4.4: Test data and accounts must be removed from system components before the system is enabled before going live.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.4.5: Change control procedures should include the following:<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.4.5.1: Document the impact of the change.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.4.5.2: Changes require documented change approval by authorized parties.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.4.5.3: Perform functionality test to verify that the change does not adversely affect the security of the system.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.4.5.4: Establish back-out procedures for changes.<\/strong><\/h3>\n\n\n\n
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.<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.5: Address common coding vulnerabilities in software development processes.<\/strong><\/h2>\n\n\n\n
\n
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.<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.5.2: Buffer overflows<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.5.3: Unsecured cryptographic storage<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.5.4: Unsecured communications<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.5.5: Inappropriate error handling<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.5.6: All \u201chigh risk\u201d vulnerabilities identified during the vulnerability identification process must be addressed.<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.5.7: Cross-Site Scripting (XSS)<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.5.8: Inappropriate access control<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 6.5.9: Cross-site request forgery (CSRF)<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 6.5.10: Broken authentication and session management.<\/strong><\/h3>\n\n\n\n
\n
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.<\/strong><\/h2>\n\n\n\n
\n
\n
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.<\/strong><\/h2>\n\n\n\n