Framework № PCI DSS 4.0 от 01.03.2022

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

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. 

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood. 

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. 

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
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. 

Customized Approach Objective:
Automated mechanisms are implemented to prevent systems from becoming an attack vector for malware. 

Defined Approach Testing Procedures:

Purpose:
There is a constant stream of attacks targeting newly discovered vulnerabilities in systems previously regarded as secure. Without an antimalware 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 "zeroday" 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) 

5.2.2
Defined Approach Requirements: 
The deployed anti-malware solution(s):

Customized Approach Objective:
Malware cannot execute or infect other system components. 

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
Any system components that are not at risk for malware are evaluated periodically to include the following:

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. 

Defined Approach Testing Procedures:

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 antimalware 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: 

 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
Defined Approach Requirements: 
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. 

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. 

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
The anti-malware solution(s) is kept current via automatic updates. 

Customized Approach Objective:
Anti-malware mechanisms can detect and address the latest malware threats. 

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
The anti-malware solution(s):

OR

Customized Approach Objective:
Malware cannot complete execution. 

Defined Approach Testing Procedures:

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 ondemand 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
Defined Approach Requirements: 
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. 

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. 

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
For removable electronic media, the antimalware solution(s):

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. 

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1. 

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

Defined Approach Testing Procedures:

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
Defined Approach Requirements: 
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. 

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. 

Defined Approach Testing Procedures:

Purpose:
It is important that defensive mechanisms are always running so that malware is detected in real time. Ad-hoc starting and stopping of antimalware 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 antimalware 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 reenabled. 

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

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 inscope 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. 

Defined Approach Testing Procedures:

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 antiphishing 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 antimalware solutions.

Further Information:
See the following for more information about phishing: