4.2.1 Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

• Only trusted keys and certificates are accepted.
• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until its effective date; refer to applicability notes below for details.
• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
• The encryption strength is appropriate for the encryption methodology in use.

Defined Approach Testing Procedures

Customized Approach Objective

Cleartext PAN cannot be read or intercepted from any transmissions over open, public networks.

Applicability Notes

There could be occurrences where an entity receives cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of receiving sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or implement measures to prevent the channel from being used for cardholder data.

A self-signed certificate may also be acceptable if the certificate is issued by an internal CA within the organization, the certificate’s author is confirmed, and the certificate is verified—for example, via hash or signature—and has not expired. Note that self- signed certificates where the Distinguished Name (DN) field in the “issued by” and “issued to” field is the same are not acceptable.

The bullet above (for confirming that certificates used to safeguard PAN during transmission over open, public networks are valid and are not expired or revoked) is a best practice until 31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be fully considered during a PCI DSS assessment.

Purpose

Sensitive information must be encrypted during transmission over public networks because it is easy and common for a malicious individual to intercept and/or divert data while in transit.

Good Practice

The network and data-flow diagrams defined in Requirement 1 are useful resources for identifying all connection points where account data is transmitted or received over open, public networks.

While not required, it is considered a good practice for entities to also encrypt PAN over their internal networks, and for entities to establish any new network implementations with encrypted communications.

PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both. While it is not required that strong cryptography be applied at both the data level and the session level, it is strongly recommended. If encrypted at the data level, the cryptographic keys used for protecting the data can be managed in accordance with Requirements 3.6 and 3.7. If the data is encrypted at the session level, designated key custodians should be assigned responsibility for managing transmission keys and certificates.

Some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain access to the cleartext data. It is critical that entities maintain awareness of industry-defined deprecation dates for the cipher suites they are using and are prepared to migrate to newer versions or protocols when older ones are no longer deemed secure.

Verifying that certificates are trusted helps ensure the integrity of the secure connection. To be considered trusted, a certificate should be issued from a trusted source, such as a trusted certificate authority (CA), and not be expired. Up-to-date Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) can be used to validate certificates.

Techniques to validate certificates may include certificate and public key pinning, where the trusted certificate or a public key is pinned either during development or upon its first use. Entities can also confirm with developers or review source code to ensure that clients and servers reject connections if the certificate is bad.

For browser-based TLS certificates, certificate trust can often be verified by clicking on the lock icon that appears next to the address bar.

Examples

Open, public networks include, but are not limited to:

• The Internet and
• Wireless technologies, including Wi-Fi, Bluetooth, cellular technologies, and satellite communications.

Further Information

Vendor recommendations and industry best practices can be consulted for information about the proper encryption strength specific to the encryption methodology in use.

For more information about strong cryptography and secure protocols, see industry standards and best practices such as NIST SP 800-52 and SP 800-57.

For more information about trusted keys and certificates, see NIST Cybersecurity Practice Guide Special Publication 1800-16, Securing Web Transactions: Transport Layer Security (TLS) Server Certificate Management.

4.2.1.1 An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.

Defined Approach Testing Procedures

Customized Approach Objective

All keys and certificates used to protect PAN during transmission are identified and confirmed as trusted.

Applicability Notes

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Purpose

The inventory of trusted keys helps the entity keep track of the algorithms, protocols, key strength, key custodians, and key expiry dates. This enables the entity to respond quickly to vulnerabilities discovered in encryption software, certificates, and cryptographic algorithms.

Good Practice

For certificates, the inventory should include the issuing CA and certification expiration date.

4.2.1.2 Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission.

Defined Approach Testing Procedures

Customized Approach Objective

Cleartext PAN cannot be read or intercepted from wireless network transmissions.

Purpose

Since wireless networks do not require physical media to connect, it is important to establish controls limiting who can connect and what transmission protocols will be used. Malicious users use free and widely available tools to eavesdrop on wireless communications. Use of strong cryptography can help limit disclosure of sensitive information across wireless networks.

Wireless networks present unique risks to an organization; therefore, they must be identified and protected according to industry requirements. Strong cryptography for authentication and transmission of PAN is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data.

Good Practice

Wireless networks should not permit fallback or downgrade to an insecure protocol or lower encryption strength that does not meet the intent of strong cryptography.

Further Information

Review the vendor’s specific documentation for more details on the choice of protocols, configurations, and settings related to cryptography.

4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.

Defined Approach Testing Procedures

Customized Approach Objective

Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging technologies.

Applicability Notes

This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies.

There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or delete the cardholder data and implement measures to prevent the channel from being used for cardholder data.

Purpose

End-user messaging technologies typically can be easily intercepted by packet-sniffing during delivery across internal and public networks.

Good Practice

The use of end-user messaging technology to send PAN should only be considered where there is a defined business need.

Examples

E-mail, instant messaging, SMS, and chat are examples of the type of end-user messaging technology that this requirement refers to.

5.1.1 All security policies and operational procedures that are identified in Requirement 5 are:

• Documented.
• Kept up to date.
• In use.
• Known to all affected parties.

Defined Approach Testing Procedures

Customized Approach Objective

Expectations, controls, and oversight for meeting activities within Requirement 5 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent.

Purpose

Requirement 5.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 5. While it is important to define the specific policies or procedures called out in Requirement 5, it is equally important to ensure they are properly documented, maintained, and disseminated.

Good Practice

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

Definitions

Security policies define the entity’s security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives.

5.1.2 Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood.

Defined Approach Testing Procedures

Customized Approach Objective

Day-to-day responsibilities for performing all the activities in Requirement 5 are allocated. Personnel are accountable for successful, continuous operation of these requirements.

Purpose

If roles and responsibilities are not formally assigned, networks and systems may not be properly protected from malware.

Good Practice

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

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

Examples

A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix).

5.2.1 An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware.

Defined Approach Testing Procedures

Customized Approach Objective

Automated mechanisms are implemented to prevent systems from becoming an attack vector for malware.

Purpose

There is a constant stream of attacks targeting newly discovered vulnerabilities in systems previously regarded as secure. Without an anti- malware solution that is updated regularly, new forms of malware can be used to attack systems, disable a network, or compromise data.

Good Practice

It is beneficial for entities to be aware of "zero- day" attacks (those that exploit a previously unknown vulnerability) and consider solutions that focus on behavioral characteristics and will alert and react to unexpected behavior.

Definitions

System components known to be affected by malware have active malware exploits available in the real world (not only theoretical exploits).

The deployed anti-malware solution(s):

• Detects all known types of malware
• Removes, blocks, or contains all known types of malware.

Defined Approach Testing Procedures

Customized Approach Objective

Malware cannot execute or infect other system components.

Purpose

It is important to protect against all types and forms of malware to prevent unauthorized access.

Good Practice

Anti-malware solutions may include a combination of network-based controls, host-based controls, and endpoint security solutions. In addition to signature-based tools, capabilities used by modern anti-malware solutions include sandboxing, privilege escalation controls, and machine learning.

Solution techniques include preventing malware from getting into the network and removing or containing malware that does get into the network.

Examples

Types of malware include, but are not limited to, viruses, Trojans, worms, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links.

5.2.3 Any system components that are not at risk for malware are evaluated periodically to include the following:

• A documented list of all system components not at risk for malware.
• Identification and evaluation of evolving malware threats for those system components.
• Confirmation whether such system components continue to not require anti-malware protection.

Defined Approach Testing Procedures

Customized Approach Objective

The entity maintains awareness of evolving malware threats to ensure that any systems not protected from malware are not at risk of infection.

Applicability Notes

System components covered by this requirement are those for which there is no anti-malware solution deployed per Requirement 5.2.1.

Purpose

Certain systems, at a given point in time, may not currently be commonly targeted or affected by malware. However, industry trends for malware can change quickly, so it is important for organizations to be aware of new malware that might affect their systems—for example, by monitoring vendor security notices and anti- malware forums to determine whether its systems might be coming under threat from new and evolving malware.

Good Practice

If an entity determines that a particular system is not susceptible to any malware, the determination should be supported by industry evidence, vendor resources, and best practices.

The following steps can help entities during their periodic evaluations:

• Identification of all system types previously determined to not require malware protection.
• Review of industry vulnerability alerts and notices to determine if new threats exist for any identified system.
• A documented conclusion about whether the system types remain not susceptible to malware.
• A strategy to add malware protection for any system types for which malware protection has become necessary.

Trends in malware should be included in the identification of new security vulnerabilities at Requirement 6.3.1, and methods to address new trends should be incorporated into the entity’s configuration standards and protection mechanisms as needed.

5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

Defined Approach Testing Procedures

Customized Approach Objective

Systems not known to be at risk from malware are re-evaluated at a frequency that addresses the entity’s risk.

Applicability Notes

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Purpose

Entities determine the optimum period to undertake the evaluation based on criteria such as the complexity of each entity’s environment and the number of types of systems that are required to be evaluated.

5.3.1 The anti-malware solution(s) is kept current via automatic updates.

Defined Approach Testing Procedures

Customized Approach Objective

Anti-malware mechanisms can detect and address the latest malware threats.

Purpose

For an anti-malware solution to remain effective, it needs to have the latest security updates, signatures, threat analysis engines, and any other malware protections on which the solution relies.

Having an automated update process avoids burdening end users with responsibility for manually installing updates and provides greater assurance that anti-malware protection mechanisms are updated as quickly as possible after an update is released.

Good Practice

Anti-malware mechanisms should be updated via a trusted source as soon as possible after an update is available. Using a trusted common source to distribute updates to end-user systems helps ensure the integrity and consistency of the solution architecture.

Updates may be automatically downloaded to a central location—for example, to allow for testing—prior to being deployed to individual system components.

5.3.2 The anti-malware solution(s):

• Performs periodic scans and active or real-time scans.

OR

• Performs continuous behavioral analysis of systems or processes.

Defined Approach Testing Procedures

Customized Approach Objective

Malware cannot complete execution.

Purpose

Periodic scans can identify malware that is present, but currently inactive, within the environment. Some malware, such as zero-day malware, can enter an environment before the scan solution is capable of detecting it. Performing regular periodic scans or continuous behavioral analysis of systems or processes helps ensure that previously undetectable malware can be identified, removed, and investigated to determine how it gained access to the environment.

Good Practice

Using a combination of periodic scans (scheduled and on-demand) and active, real-time (on-access) scanning helps ensure that malware residing in both static and dynamic elements of the CDE is addressed. Users should also be able to run on- demand scans on their systems if suspicious activity is detected – this can be useful in the early detection of malware.

Scans should include the entire file system, including all disks, memory, and start-up files and boot records (at system restart) to detect all malware upon file execution, including any software that may be resident on a system but not currently active. Scan scope should include all systems and software in the CDE, including those that are often overlooked such as email servers, web browsers, and instant messaging software.

Definitions

Active, or real-time, scanning checks files for malware upon any attempt to open, close, rename, or otherwise interact with a file, preventing the malware from being activated.

5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

Defined Approach Testing Procedures

Customized Approach Objective

Scans by the malware solution are performed at a frequency that addresses the entity’s risk.

Applicability Notes

This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2.

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Purpose

Entities can determine the optimum period to undertake periodic scans based on their own assessment of the risks posed to their environments.

5.3.3 For removable electronic media, the anti- malware solution(s):

• Performs automatic scans of when the media is inserted, connected, or logically mounted,

OR

• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.

Defined Approach Testing Procedures

Customized Approach Objective

Malware cannot be introduced to system components via external removable media.

Applicability Notes

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Purpose

Portable media devices are often overlooked as an entry method for malware. Attackers will often pre-load malware onto portable devices such as USB and flash drives; connecting an infected device to a computer then triggers the malware, introducing new threats within the environment.

5.3.4 Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1.

Defined Approach Testing Procedures

Customized Approach Objective

Historical records of anti-malware actions are immediately available and retained for at least 12 months.

Purpose

It is important to track the effectiveness of the anti-malware mechanisms—for example, by confirming that updates and scans are being performed as expected, and that malware is identified and addressed. Audit logs also allow an entity to determine how malware entered the environment and track its activity when inside the entity’s network.

5.3.5 Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period.

Defined Approach Testing Procedures

Customized Approach Objective

Anti-malware mechanisms cannot be modified by unauthorized personnel.

Applicability Notes

Anti-malware solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-malware protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which anti-malware protection is not active.

Purpose

It is important that defensive mechanisms are always running so that malware is detected in real time. Ad-hoc starting and stopping of anti- malware solutions could allow malware to propagate unchecked and undetected.

Good Practice

Where there is a legitimate need to temporarily disable a system’s anti-malware protection—for example, to support a specific maintenance activity or investigation of a technical problem— the reason for taking such action should be understood and approved by an appropriate management representative. Any disabling or altering of anti-malware mechanisms, including on administrators’ own devices, should be performed by authorized personnel. It is recognized that administrators have privileges that may allow them to disable anti-malware on their own computers, but there should be alerting mechanisms in place when such software is disabled and then follow up that occurs to ensure correct processes were followed.

Examples

Additional security measures that may need to be implemented for the period during which anti- malware protection is not active include disconnecting the unprotected system from the Internet while the anti-malware protection is disabled and running a full scan once it is re- enabled.

5.4.1 Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.

Defined Approach Testing Procedures

Customized Approach Objective

Mechanisms are in place to protect against and mitigate risk posed by phishing attacks.

Applicability Notes

This requirement applies to the automated mechanism. It is not intended that the systems and services providing such automated mechanisms (such as email servers) are brought into scope for PCI DSS.

The focus of this requirement is on protecting personnel with access to system components in- scope for PCI DSS.

Meeting this requirement for technical and automated controls to detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for security awareness training. Meeting this requirement does not also meet the requirement for providing personnel with security awareness training, and vice versa.

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Purpose

Technical controls can limit the number of occasions personnel have to evaluate the veracity of a communication and can also limit the effects of individual responses to phishing.

Good Practice

When developing anti-phishing controls, entities are encouraged to consider a combination of approaches. For example, using anti-spoofing controls such as Domain-based Message Authentication, Reporting & Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) will help stop phishers from spoofing the entity’s domain and impersonating personnel.

The deployment of technologies for blocking phishing emails and malware before they reach personnel, such as link scrubbers and server-side anti-malware, can reduce incidents and decrease the time required by personnel to check and report phishing attacks. Additionally, training personnel to recognize and report phishing emails can allow similar emails to be identified and permit them to be removed before being opened.

It is recommended (but not required) that anti-phishing controls are applied across an entity’s entire organization.

Definitions

Phishing is a form of social engineering and describes the different methods used by attackers to trick personnel into disclosing sensitive information, such as user account names and passwords, and account data. Attackers will typically disguise themselves and attempt to appear as a genuine or trusted source, directing personnel to send an email response, click on a web link, or enter data into a compromised website. Mechanisms that can detect and prevent phishing attempts are often included in anti- malware solutions.

Further Information

See the following for more information about phishing:

National Cyber Security Centre - Phishing Attacks: Defending your Organization.

US Cybersecurity & Infrastructure Security Agency - Report Phishing Sites.

10.5.1 Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.

Defined Approach Testing Procedures

Customized Approach Objective

Historical records of activity are available immediately to support incident response and are retained for at least 12 months.

Good Practice

Retaining historical audit logs for at least 12 months is necessary because compromises often go unnoticed for significant lengths of time. Having centrally stored log history allows investigators to better determine the length of time a potential breach was occurring, and the possible system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach.

Examples

Methods that allow logs to be immediately available include storing logs online, archiving logs, or restoring logs quickly from backups.