choose sub requirement:

Requirement 6.1

Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected.

Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk-assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process, or transmit cardholder data.

Testing Procedure

6.1.a
Examine policies and procedures to verify that processes are defined for the following:

  • To identify new security vulnerabilities
  • To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.
  • To use reputable outside sources for security vulnerability information.

6.1.b
Interview responsible personnel and observe processes to verify that:

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

Guidance

The intent of this requirement is that organizations keep up to date with new vulnerabilities that may impact their environment.

Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing list, or RSS feeds.

Once an organization identifies a vulnerability that could affect their environment, the risk that the vulnerability poses must be evaluated and ranked. The organization must therefore have a method in place to evaluate vulnerabilities on an ongoing basis and assign risk rankings to those vulnerabilities. This is not achieved by an ASV scan or internal vulnerability scan, rather this requires a process to actively monitor industry sources for vulnerability information.

Classifying the risks (for example, as “high,” “medium,” or “low”) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited.

Requirement 6.2

Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

Testing Procedure

6.2.a
Examine policies and procedures related to security-patch installation to verify processes are defined for:

  • Installation of applicable critical vendor-supplied security patches within one month of release.
  • Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months).

6.2.b
For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security-patch list, to verify the following:

  • That applicable critical vendor-supplied security patches are installed within one month of release.
  • All applicable vendor-supplied security patches are installed within an appropriate time frame (for example, within three months).

Guidance

There is a constant stream of attacks using widely published exploits, often called "zero day" (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. If the most recent patches are not implemented on critical systems as soon as possible, a malicious individual can use these exploits to attack or disable a system, or gain access to sensitive data.

Prioritizing patches for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released. Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months.

This requirement applies to applicable patches for all installed software.

Requirement 6.3

Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

  • In accordance with PCI DSS (for example, secure authentication and logging)
  • Based on industry standards and/or best practices.
  • Incorporating information security throughout the software-development life cycle

Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.

Testing Procedure

6.3.a
Examine written software-development processes to verify that the processes are based on industry standards and/or best practices.

6.3.b
Examine written software-development processes to verify that information security is included throughout the life cycle.

6.3.c
Examine written software-development processes to verify that software applications are developed in accordance with PCI DSS.

6.3.d
Interview software developers to verify that written software-development processes are implemented.

Guidance

Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment.

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

Requirement 6.3.1

Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.

Testing Procedure

6.3.1
Examine written software-development procedures and interview responsible personnel to verify that pre-production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into production or is released to customers.

Guidance

Development, test and/or custom application accounts, user IDs, and passwords should be removed from production code before the application becomes active or is released to customers, since these items may give away information about the functioning of the application. Possession of such information could facilitate compromise of the application and related cardholder data.

Requirement 6.3.2

Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:

  • Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.
  • Code reviews ensure code is developed according to secure coding guidelines
  • Appropriate corrections are implemented prior to release
  • Code-review results are reviewed and approved by management prior to release.

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle.

Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

Testing Procedure

6.3.2.a
Examine written software-development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows:

  • Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.
  • Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).
  • Appropriate corrections are implemented prior to release.
  • Code-review results are reviewed and approved by management prior to release.

6.3.2.b
Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.2.a, above.

Guidance

Security vulnerabilities in custom code are commonly exploited by malicious individuals to gain access to a network and compromise cardholder data.

An individual knowledgeable and experienced in code-review techniques should be involved in the review process. Code reviews should be performed by someone other than the developer of the code to allow for an independent, objective review. Automated tools or processes may also be used in lieu of manual reviews, but keep in mind that it may be difficult or even impossible for an automated tool to identify some coding issues.

Correcting coding errors before the code is deployed into a production environment or released to customers prevents the code exposing the environments to potential exploit. Faulty code is also far more difficult and expensive to address after it has been deployed or released into production environments.

Including a formal review and signoff by management prior to release helps to ensure that code is approved and has been developed in accordance with policies and procedures.

Requirement 6.4

Follow change control processes and procedures for all changes to system components. The processes must include the following: See 6.4.1 through 6.4.5)

Testing Procedure

6.4
Examine policies and procedures to verify the following are defined:

  • Development/test environments are separate from production environments with access control in place to enforce separation.
  • A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.
  • Production data (live PANs) are not used for testing or development.
  • Test data and accounts are removed before a production system becomes active.
  • Change control procedures related to implementing security patches and software modifications are documented.

Guidance

Without properly documented and implemented change controls, security features could be inadvertently or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be introduced.

Requirement 6.4.1

Separate development/test environments from production environments, and enforce the separation with access controls.

Testing Procedure

6.4.1.a
Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s).

6.4.1.b
Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s).

Guidance

Due to the constantly changing state of development and test environments, they tend to be less secure than the production environment. Without adequate separation between environments, it may be possible for the production environment, and cardholder data, to be compromised due to less-stringent security configurations and possible vulnerabilities in a test or development environment.

Requirement 6.4.2

Separation of duties between development/test and production environments

Testing Procedure

6.4.2
Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.

Guidance

Reducing the number of personnel with access to the production environment and cardholder data minimizes risk and helps ensure that access is limited to those individuals with a business need to know.

The intent of this requirement is to separate development and test functions from production functions. For example, a developer may 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.

Requirement 6.4.3

Production data (live PANs) are not used for testing or development

Testing Procedure

6.4.3.a
Observe testing processes and interview personnel to verify procedures are in place to ensure production data (live PANs) are not used for testing or development.

6.4.3.b
Examine a sample of test data to verify production data (live PANs) is not used for testing or development.

Guidance

Security controls are usually not as stringent in test or development environments. Use of production data provides malicious individuals with the opportunity to gain unauthorized access to production data (cardholder data).

Requirement 6.4.4

Removal of test data and accounts before production systems become active

Testing Procedure

6.4.4.a
Observe testing processes and interview personnel to verify test data and accounts are removed before a production system becomes active.

6.4.4.b
Examine a sample of data and accounts from production systems recently installed or updated to verify test data and accounts are removed before the system becomes active.

Guidance

Test data and accounts should be removed from production code before the application becomes active, since these items may give away information about the functioning of the application or system. Possession of such information could facilitate compromise of the system and related cardholder data.

Requirement 6.4.5

Change control procedures for the implementation of security patches and software modifications must include the following:

Testing Procedure

6.4.5.a
Examine documented change control procedures related to implementing security patches and software modifications and verify procedures are defined for:

  • Documentation of impact
  • Documented change approval by authorized parties
  • Functionality testing to verify that the change does not adversely impact the security of the system
  • Back-out procedures

6.4.5.b
For a sample of system components, interview responsible personnel to determine recent changes/security patches. Trace those changes back to related change control documentation. For each change examined, perform the following: (See 6.4.5.1 through 6.4.5.4)

Guidance

If not properly managed, the impact of software updates and security patches might not be fully realized and could have unintended consequences.

Requirement 6.4.5.1

Documentation of impact.

Testing Procedure

6.4.5.1
Verify that documentation of impact is included in the change control documentation for each sampled change.

Guidance

The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes.

Requirement 6.4.5.2

Documented change approval by authorized parties.

Testing Procedure

6.4.5.2
Verify that documented approval by authorized parties is present for each sampled change.

Guidance

Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by the organization.

Requirement 6.4.5.3

Functionality testing to verify that the change does not adversely impact the security of the system.

Testing Procedure

6.4.5.3.a
For each sampled change, verify that functionality testing is performed to verify that the change does not adversely impact the security of the system.

6.4.5.3.b
For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production.

Guidance

Thorough testing should be performed to verify that the security of the environment is not reduced by implementing a change. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the environment.

Requirement 6.4.5.4

Back-out procedures.

Testing Procedure

6.4.5.4
Verify that back-out procedures are prepared for each sampled change.

Guidance

For each change, there should be documented back-out procedures in case the change fails or adversely affects the security of an application or system, to allow the system to be restored back to its previous state.

Note: Requirements 6.5.1 through 6.5.6 apply to all applications (internal or external).

Requirement 6.5

Address common coding vulnerabilities in software-development processes as follows:

  • Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.
  • Develop applications based on secure coding guidelines.

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

Testing Procedure

6.5.a
Examine software-development policies and procedures to verify that training in secure coding techniques is required for developers, based on industry best practices and guidance.

6.5.b
Interview a sample of developers to verify that they are knowledgeable in secure coding techniques.

6.5.c
Examine records of training to verify that software developers received training on secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.

6.5.d
Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities: (See 6.5.1 through 6.5.6)

Guidance

The application layer is high-risk and may be targeted by both internal and external threats.

Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding practices as applicable to the particular technology in their environment.

Application developers should be properly trained to identify and resolve issues related to these (and other) common coding vulnerabilities. Having staff knowledgeable of secure coding guidelines should minimize the number of security vulnerabilities introduced through poor coding practices. Training for developers may be provided in-house or by third parties and should be applicable for technology used.

As industry-accepted secure coding practices change, organizational coding practices and developer training should likewise be updated to address new threats—for example, memory scraping attacks.

The vulnerabilities identified in 6.5.1 through 6.5.10 provide a minimum baseline. It is up to the organization to remain up to date with vulnerability trends and incorporate appropriate measures into their secure coding practices.

Note: Requirements 6.5.1 through 6.5.6 apply to all applications (internal or external).

Requirement 6.5.1

Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

Testing Procedure

6.5.1
Examine software-development policies and procedures and interview responsible personnel to verify that injection flaws are addressed by coding techniques that include:

  • Validating input to verify user data cannot modify meaning of commands and queries.
  • Utilizing parameterized queries.

Guidance

Injection flaws, particularly SQL injection, are a commonly used method for compromising applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data, and allows the attacker to attack components inside the network through the application, to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality.

Information should be validated before being sent to the application—for example, by checking for all alpha characters, mix of alpha and numeric characters, etc.

Note: Requirements 6.5.1 through 6.5.6 apply to all applications (internal or external).

Requirement 6.5.2

Buffer overflows

Testing Procedure

6.5.2
Examine software-development policies and procedures and interview responsible personnel to verify that buffer overflows are addressed by coding techniques that include:

  • Validating buffer boundaries.
  • Truncating input strings.

Guidance

Buffer overflows occur when an application does not have appropriate bounds checking on its buffer space. This can cause the information in the buffer to be pushed out of the buffer’s memory space and into executable memory space. When this occurs, the attacker has the ability to insert malicious code at the end of the buffer and then push that malicious code into executable memory space by overflowing the buffer. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system.

Note: Requirements 6.5.1 through 6.5.6 apply to all applications (internal or external).

Requirement 6.5.3

Insecure cryptographic storage

Testing Procedure

6.5.3

Examine software-development policies and procedures and interview responsible personnel to verify that insecure cryptographic storage is addressed by coding techniques that:
  • Prevent cryptographic flaws.
  • Use strong cryptographic algorithms and keys.

Guidance

Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised, and exposing authentication credentials and/or cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain clear-text access to encrypted data.

Note: Requirements 6.5.1 through 6.5.6 apply to all applications (internal or external).

Requirement 6.5.4

Insecure communications

Testing Procedure

6.5.4

Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

Guidance

Applications that fail to adequately encrypt network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain control of an application or even gain clear-text access to encrypted data.

Note: Requirements 6.5.1 through 6.5.6 apply to all applications (internal or external).

Requirement 6.5.5

Improper error handling

Testing Procedure

6.5.5

Examine software-development policies and procedures and interview responsible personnel to verify that improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details).

Guidance

Applications can unintentionally leak information about their configuration or internal workings, or expose privileged information through improper error handling methods. Attackers use this weakness to steal sensitive data or compromise the system altogether. If a malicious individual can create errors that the application does not handle properly, they can gain detailed system information, create denial-of-service interruptions, cause security to fail, or crash the server. For example, the message "incorrect password provided" tells an attacker the user ID provided was accurate and that they should focus their efforts only on the password. Use more generic error messages, like "data could not be verified."

Note: Requirements 6.5.1 through 6.5.6 apply to all applications (internal or external).

Requirement 6.5.6

All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).

Testing Procedure

6.5.6
Examine software-development policies and procedures and interview responsible personnel to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1.

Guidance

All vulnerabilities identified by an organization’s vulnerability risk-ranking process (defined in Requirement 6.1) to be “high risk” and that could affect the application should be identified and addressed during application development.

Note: Requirements 6.5.7 through 6.5.10 apply to web applications and application interfaces (internal or external):

Web applications, both internally and externally (public) facing, have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise.

Requirement 6.5.7

Cross-site scripting (XSS)

Testing Procedure

6.5.7
Examine software-development policies and procedures and interview responsible personnel to verify that cross-site scripting (XSS) is addressed by coding techniques that include

  • Validating all parameters before inclusion
  • Utilizing context-sensitive escaping.

Guidance

XSS flaws occur whenever an application takes user-supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser, which can hijack user sessions, deface web sites, possibly introduce worms, etc.

Note: Requirements 6.5.7 through 6.5.10 apply to web applications and application interfaces (internal or external):

Web applications, both internally and externally (public) facing, have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise.

Requirement 6.5.8

Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).

Testing Procedure

6.5.8
Examine software-development policies and procedures and interview responsible personnel to verify that improper access control—such as insecure direct object references, failure to restrict URL access, and directory traversal—is addressed by coding technique that includes:

  • Proper authentication of users
  • Sanitizing input
  • Not exposing internal object references to users
  • User interfaces that do not permit access to unauthorized functions.

Guidance

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

Consistently enforce access control in presentation layer and business logic for all URLs. Frequently, the only way an application protects sensitive functionality is by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

An attacker may be able to enumerate and navigate the directory structure of a website (directory traversal) thus gaining access to unauthorized information as well as gaining further insight into the workings of the site for later exploitation.

If user interfaces permit access to unauthorized functions, this access could result in unauthorized individuals gaining access to privileged credentials or cardholder data. Only authorized users should be permitted to access direct object references to sensitive resources. Limiting access to data resources will help prevent cardholder data from being presented to unauthorized resources.

Note: Requirements 6.5.7 through 6.5.10 apply to web applications and application interfaces (internal or external):

Web applications, both internally and externally (public) facing, have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise.

Requirement 6.5.9

Cross-site request forgery (CSRF)

Testing Procedure

6.5.9
Examine software development policies and procedures and interview responsible personnel to verify that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

Guidance

A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then enables the attacker to perform any state-changing operations the victim is authorized to perform (such as updating account details, making purchases, or even authenticating to the application).

Note: Requirements 6.5.7 through 6.5.10 apply to web applications and application interfaces (internal or external):

Web applications, both internally and externally (public) facing, have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise.

Requirement 6.5.10

Broken authentication and session management

Testing Procedure

6.5.10
Examine software development policies and procedures and interview responsible personnel to verify that broken authentication and session management are addressed via coding techniques that commonly include:

  • Flagging session tokens (for example cookies) as “secure”
  • Not exposing session IDs in the URL
  • Incorporating appropriate time-outs and rotation of session IDs after a successful login.

Guidance

Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.

Requirement 6.6

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

  • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

  • Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Testing Procedure

6.6

For public-facing web applications, ensure that either one of the following methods is in place as follows:
  • Examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed—using either manual or automated vulnerability security assessment tools or methods—as follows:
    • At least annually
    • After any changes
    • By an organization that specializes in application security
    • That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment
    • That all vulnerabilities are corrected
    • That the application is re-evaluated after the corrections.
  • Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
    • Is situated in front of public-facing web applications to detect and prevent web-based attacks.
    • Is actively running and up to date as applicable.
    • Is generating audit logs.
    • Is configured to either block web-based attacks, or generate an alert that is immediately investigated.

Guidance

Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. The requirement for reviewing applications or installing web-application firewalls is intended to reduce the number of compromises on public-facing web applications due to poor coding or application management practices.

  • Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities
  • Web-application firewalls filter and block non-essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured. This can be achieved through a combination of technology and process. Process-based solutions must have mechanisms that facilitate timely responses to alerts in order to meet the intent of this requirement, which is to prevent attacks.

    • Note: “An organization that specializes in application security” can be either a third-party company or an internal organization, as long as the reviewers specialize in application security and can demonstrate independence from the development team.

Requirement 6.7

Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.

Testing Procedure

6.7
Examine documentation and interview personnel to verify that security policies and operational procedures for developing and maintaining secure systems and applications are:

  • Documented,
  • In use, and
  • Known to all affected parties.

Guidance

Personnel need to be aware of and following security policies and operational procedures to ensure systems and applications are securely developed and protected from vulnerabilities on a continuous basis.

Goal: Maintain a Vulnerability Management Program

Requirement 6.0

Develop and maintain secure systems and applications

Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

Note: 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 in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.