choose sub requirement:

Requirement 2.1

Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

This applies to ALL default 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, Simple Network Management Protocol (SNMP) community strings, etc.).

Testing Procedure

2.1.a
Choose a sample of system components, and attempt to log on (with system administrator help) to the devices and applications using default vendor-supplied accounts and passwords, to verify that ALL default passwords (including those on operating systems, software that provides security services, application and system accounts, POS terminals, and Simple Network Management Protocol (SNMP) community strings) have been changed. (Use vendor manuals and sources on the Internet to find vendor-supplied accounts/passwords.)

2.1.b
For the sample of system components, verify that all unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled.

2.1.c
Interview personnel and examine supporting documentation to verify that:

  • All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.
  • Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled before a system is installed on the network.

Guidance

Malicious individuals (external and internal to an organization) often use vendor default settings, account names, and passwords to compromise operating system software, applications, and the systems on which they are installed. Because these default settings are often published and are well known in hacker communities, changing these settings will leave systems less vulnerable to attack.

Even if a default account is not intended to be used, changing the default password to a strong unique password and then disabling the account will prevent a malicious individual from re-enabling the account and gaining access with the default password.

Requirement 2.1.1

For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.

Testing Procedure

2.1.1.a
Interview responsible personnel and examine supporting documentation to verify that:

  • Encryption keys were changed from default at installation
  • Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions.

2.1.1.b
Interview personnel and examine policies and procedures to verify:

  • Default SNMP community strings are required to be changed upon installation.
  • Default passwords/phrases on access points are required to be changed upon installation.

2.1.1.c
Examine vendor documentation and login to wireless devices, with system administrator help, to verify:

  • Default SNMP community strings are not used.
  • Default passwords/passphrases on access points are not used.

2.1.1.d
Examine vendor documentation and observe wireless configuration settings to verify firmware on wireless devices is updated to support strong encryption for:

  • Authentication over wireless networks
  • Transmission over wireless networks.

2.1.1.e
Examine vendor documentation and observe wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.

Guidance

If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network.

In addition, the key-exchange protocol for older versions of 802.11x encryption (Wired Equivalent Privacy, or WEP) has been broken and can render the encryption useless. Firmware for devices should be updated to support more secure protocols.

Requirement 2.2

Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Sources of industry-accepted system hardening standards may include, but are not limited to:

  • Center for Internet Security (CIS)
  • International Organization for Standardization (ISO)
  • SysAdmin Audit Network Security (SANS) Institute
  • National Institute of Standards Technology (NIST).

Testing Procedure

2.2.a
Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards.

2.2.b
Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1.

2.2.c
Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.

2.2.d
Verify that system configuration standards include the following procedures for all types of system components:

  • Changing of all vendor-supplied defaults and elimination of unnecessary default accounts
  • Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server
  • Enabling only necessary services, protocols, daemons, etc., as required for the function of the system
  • Implementing additional security features for any required services, protocols or daemons that are considered to be insecure
  • Configuring system security parameters to prevent misuse
  • Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Guidance

There are known weaknesses with many operating systems, databases, and enterprise applications, and there are also known ways to configure these systems to fix security vulnerabilities. To help those that are not security experts, a number of security organizations have established system-hardening guidelines and recommendations, which advise how to correct these weaknesses.

Examples of sources for guidance on configuration standards include, but are not limited to: www.nist.gov, www.sans.org, and www.cisecurity.org, www.iso.org, and product vendors.

System configuration standards must be kept up to date to ensure that newly identified weaknesses are corrected prior to a system being installed on the network.

Requirement 2.2.1

Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

(Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.)

Testing Procedure

2.2.1.a
Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server.

2.2.1.b
If virtualization technologies are used, inspect the system configurations to verify that only one primary function is implemented per virtual system component or device.

Guidance

If server functions that need different security levels are located on the same server, the security level of the functions with higher security needs would be reduced due to the presence of the lower-security functions. Additionally, the server functions with a lower security level may introduce security weaknesses to other functions on the same server. By considering the security needs of different server functions as part of the system configuration standards and related processes, organizations can ensure that functions requiring different security levels don’t co-exist on the same server.

Requirement 2.2.2

Enable only necessary services, protocols, daemons, etc., as required for the function of the system.

Testing Procedure

2.2.2.a
Select a sample of system components and inspect enabled system services, daemons, and protocols to verify that only necessary services or protocols are enabled.

2.2.2.b
Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards.

Guidance

As stated in Requirement 1.1.6, there are many protocols that a business may need (or have enabled by default) that are commonly used by malicious individuals to compromise a network. Including this requirement as part of an organization's configuration standards and related processes ensures that only the necessary services and protocols are enabled.

Requirement 2.2.3

Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

(Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.)

Testing Procedure

2.2.3.a
Inspect configuration settings to verify that security features are documented and implemented for all insecure services, daemons, or protocols.

2.2.3.b
For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols:

Confirm the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.

2.2.3.c
For all other environments using SSL and/or early TLS:

Review the documented Risk Mitigation and Migration Plan to verify it includes:

  • Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment;
  • Risk-assessment results and risk-reduction controls in place;
  • Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;
  • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;
  • Overview of migration project plan including target migration completion date no later than June 30, 2016.

Guidance

Enabling security features before new servers are deployed will prevent servers being installed into the environment with insecure configurations.

Ensuring that all insecure services, protocols, and daemons are adequately secured with appropriate security features makes it more difficult for malicious individuals to take advantage of commonly used points of compromise within a network.

Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.).

Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where they don’t already exist. At the time of publication, the known vulnerabilities are difficult to exploit in POS POI payment environments. However, new vulnerabilities could emerge at any time, and it is up to the organization to remain up-to-date with vulnerability trends and determine whether or not they are susceptible to any known exploits.

Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.

Requirement 2.2.4

Configure system security parameters to prevent misuse.

Testing Procedure

2.2.4.a
Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.

2.2.4.b
Examine the system configuration standards to verify that common security parameter settings are included.

2.2.4.c
Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards.

Guidance

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.

In order for systems to be configured securely, personnel responsible for configuration and/or administering systems must be knowledgeable in the specific security parameters and settings that apply to the system.

Requirement 2.2.5

Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Testing Procedure

2.2.5.a
Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.

2.2.5.b
Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration.

2.2.5.c
Examine the documentation and security parameters to verify that only documented functionality is present on the sampled system components.

Guidance

Unnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. By removing unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited.

Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example, by removing/disabling FTP or the web server if the server will not be performing those functions).

Requirement 2.3

Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access.

Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.

Testing Procedure

2.3
Select a sample of system components and verify that non-console administrative access is encrypted by performing the following:

2.3.a
Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested.

2.3.b
Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.

2.3.c
Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography.

2.3.d
Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

2.3.e
For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols:

Confirm the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.

2.3.f
For all other environments using SSL and/or early TLS:

Review the documented Risk Mitigation and Migration Plan to verify it includes:

  • Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment;
  • Risk-assessment results and risk-reduction controls in place;
  • Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;
  • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;
  • Overview of migration project plan including target migration completion date no later than June 30, 2016.

Guidance

If non-console (including remote) administration does not use secure authentication and encrypted communications, sensitive administrative or operational level information (like administrator’s 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.

Clear-text protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information.

To be considered “strong cryptography,” industry-recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. (Refer to "strong cryptography” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, and industry standards and best practices such as NIST SP 800-52 and SP 800-57, OWASP, etc.)

Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where they don’t already exist. At the time of publication, the known vulnerabilities are difficult to exploit in POS POI payment environments. However, new vulnerabilities could emerge at any time, and it is up to the organization to remain up-to-date with vulnerability trends and determine whether or not they are susceptible to any known exploits.

Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.

Requirement 2.4

Maintain an inventory of system components that are in scope for PCI DSS.

Testing Procedure

2.4.a
Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each.

2.4.b
Interview personnel to verify the documented inventory is kept current.

Guidance

Maintaining a current list of all system components will enable an organization to accurately and efficiently define the scope of their environment for implementing PCI DSS controls. Without an inventory, some system components could be forgotten, and be inadvertently excluded from the organization’s configuration standards.

Requirement 2.5

Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.

Testing Procedure

2.5
Examine documentation and interview personnel to verify that security policies and operational procedures for managing vendor defaults and other security parameters are:

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

Guidance

Personnel need to be aware of and following security policies and daily operational procedures to ensure vendor defaults and other security parameters are continuously managed to prevent insecure configurations.

Requirement 2.6

Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.

Testing Procedure

2.6
Perform testing procedures A.1.1 through A.1.4 detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers, to verify that shared hosting providers protect their entities’ (merchants and service providers) hosted environment and data.

Guidance

This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client's data and thereby gain access to all other clients' data. See Appendix A for details of requirements.

Goal: Build and Maintain a Secure Network and Systems

Requirement 2.0

Do not use vendor-supplied defaults for system passwords and other security parameters

Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.