Framework № PCI DSS 4.0 от 01.03.2022

2.2.1 
Defined Approach Requirements: 
Configuration standards are developed, implemented, and maintained to:

Customized Approach Objective:
All system components are configured securely and consistently and in accordance with industryaccepted hardening standards or vendor recommendations. 

Defined Approach Testing Procedures:

Purpose:
There are known weaknesses with many operating systems, databases, network devices, software, applications, container images, and other devices used by an entity or within an entity’s environment. There are also known ways to configure these system components to fix security vulnerabilities. Fixing security vulnerabilities reduces the opportunities available to an attacker. 
By developing standards, entities ensure their system components will be configured consistently and securely, and address the protection of devices for which full hardening may be more difficult. 

Good Practice:
Keeping up to date with current industry guidance will help the entity maintain secure configurations. 
The specific controls to be applied to a system will vary and should be appropriate for the type and function of the system. 
Numerous security organizations have established system-hardening guidelines and recommendations, which advise how to correct common, known weaknesses. 

Further:
Information Sources for guidance on configuration standards include but are not limited to: Center for Internet Security (CIS), International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST), Cloud Security Alliance, and product vendors. 

2.2.2 
Defined Approach Requirements: 
Vendor default accounts are managed as follows:

Customized Approach Objective:
System components cannot be accessed using default passwords. 

Applicability Notes:
This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults. 
This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription service. 

Defined Approach Testing Procedures:

Purpose:
Malicious individuals often use vendor default account names and passwords to compromise operating systems, applications, and the systems on which they are installed. 
Because these default settings are often published and are well known, changing these settings will make systems less vulnerable to attack. 

Good Practice:
All vendor default accounts should be identified, and their purpose and use understood. It is important to establish controls for application and system accounts, including those used to deploy and maintain cloud services so that they do not use default passwords and are not usable by unauthorized individuals. 
Where a default account is not intended to be used, changing the default password to a unique password that meets PCI DSS Requirement 8.3.6, removing any access to the default account, and then disabling the account, will prevent a malicious individual from re-enabling the account and gaining access with the default password. 
Using an isolated staging network to install and configure new systems is recommended and can also be used to confirm that default credentials have not been introduced into production environments. 

Examples:
Defaults to be considered include user IDs, passwords, and other authentication credentials commonly used by vendors in their products. 

2.2.3 
Defined Approach Requirements: 
Primary functions requiring different security levels are managed as follows:

OR

OR

Customized Approach Objective:
Primary functions with lower security needs cannot affect the security of primary functions with higher security needs on the same system component. 
Defined Approach Testing Procedures:

Purpose:
Systems containing a combination of services, protocols, and daemons for their primary function will have a security profile appropriate to allow that function to operate effectively. For example, systems that need to be directly connected to the Internet would have a particular profile, like a DNS server, web server, or an e-commerce server. Conversely, other system components may operate a primary function comprising a different set of services, protocols, and daemons that performs functions that an entity does not want exposed to the Internet. This requirement aims to ensure that different functions do not impact the security profiles of other services in a way which may cause them to operate at a higher or lower security level. 

Good Practice:
Ideally, each function should be placed on different system components. This can be achieved by implementing only one primary function on each system component. Another option is to isolate primary functions on the same system component that have different security levels, for example, isolating web servers (which need to be directly connected to the Internet) from application and database servers. 
If a system component contains primary functions that need different security levels, a third option is to implement additional controls to ensure that the resultant security level of the primary function(s) with higher security needs is not reduced by the presence of the lower security primary functions. Additionally, the functions with a lower security level should be isolated and/or secured to ensure they cannot access or affect the resources of another system function, and do not introduce security weaknesses to other functions on the same server. 
Functions of differing security levels may be isolated by either physical or logical controls. For example, a database system should not also be hosting web services unless using controls like virtualization technologies to isolate and contain the functions into separate sub-systems. Another example is using virtual instances or providing dedicated memory access by system function. Where virtualization technologies are used, the security levels should be identified and managed for each virtual component. Examples of considerations for virtualized environments include:

2.2.4
Defined Approach Requirements: 
Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled. 

Customized Approach Objective:
System components cannot be compromised by exploiting unnecessary functionality present in the system component. 

Defined Approach Testing Procedures:

Purpose:
Unnecessary services and functions can provide additional opportunities for malicious individuals to gain access to a system. By removing or disabling all unnecessary services, protocols, daemons, and functions, organizations can focus on securing the functions that are required and reduce the risk that unknown or unnecessary functions will be exploited. 

Good Practice:
There are many protocols that could be enabled by default that are commonly used by malicious individuals to compromise a network. Disabling or removing all services, functions, and protocols that are not used minimizes the potential attack surface—for example, by removing or disabling an unused FTP or web server. 

Examples:
Unnecessary functionality may include, but is not limited to scripts, drivers, features, subsystems, file systems, interfaces (USB and Bluetooth), and unnecessary web servers. 

2.2.5
Defined Approach Requirements: 
If any insecure services, protocols, or daemons are present: 

Customized Approach Objective:
 System components cannot be compromised by exploiting insecure services, protocols, or daemons. 

Defined Approach Testing Procedures:

Purpose:
Ensuring that all insecure services, protocols, and daemons are adequately secured with appropriate security features makes it more difficult for malicious individuals to exploit common points of compromise within a network. 

Good Practice:
Enabling security features before new system components are deployed will prevent insecure configurations from being introduced into the environment. Some vendor solutions may provide additional security functions to assist with securing an insecure process. 

Further Information:
For guidance on services, protocols, or daemons considered to be insecure, refer to industry standards and guidance (for example, as published by NIST, ENISA, and OWASP). 

2.2.6
Defined Approach Requirements: 
System security parameters are configured to prevent misuse. 

Customized Approach Objective:
System components cannot be compromised because of incorrect security parameter configuration. 

Defined Approach Testing Procedures:

Purpose:
Correctly configuring security parameters provided in system components takes advantage of the capabilities of the system component to defeat malicious attacks. 

Good Practice:
System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use. 
For systems to be configured securely, personnel responsible for configuration and/or administering systems should be knowledgeable in the specific security parameters and settings that apply to the system. Considerations should also include secure settings for parameters used to access cloud portals. 

Further Information: 
Refer to vendor documentation and industry references noted in Requirement 2.2.1 for information about applicable security parameters for each type of system. 

2.2.7 
Defined Approach Requirements: 
All non-console administrative access is encrypted using strong cryptography. 

Customized Approach Objective:
Cleartext administrative authorization factors cannot be read or intercepted from any network transmissions. 

Applicability Notes:
This includes administrative access via browserbased interfaces and application programming interfaces (APIs). 

Defined Approach Testing Procedures:

rpose:
If non-console (including remote) administration does not use encrypted communications, administrative authorization factors (such as IDs and passwords) can be revealed to an eavesdropper. A malicious individual could use this information to access the network, become administrator, and steal data. 

Good Practice:
Whichever security protocol is used, it should be configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates, supporting only strong encryption, and not supporting fallback to weaker, insecure protocols or methods. 

Examples:
Cleartext protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information. Non-console access may be facilitated by technologies that provide alternative access to systems, including but not limited to, out-of-band (OOB), lights-out management (LOM), Intelligent Platform Management Interface (IPMI), and keyboard, video, mouse (KVM) switches with remote capabilities. These and other non-console access technologies and methods must be secured with strong cryptography 

Further Information:
Refer to industry standards and best practices such as NIST SP 800-52 and SP 800-57.