PCI DSS Requirement 2: Securely Configure All System Components

Attackers often use default passwords and other vendor default settings to compromise systems. These passwords and settings are both well known and easily accessible publicly for anyone to find. That is why it is imperative for merchants to update and secure system credentials.

Applying secure configurations to system components reduces the means available to an attacker to compromise the system. Changing default passwords; removing unnecessary software, functions, and accounts; and disabling or removing unnecessary services all help reduce the potential of an attack.

PCI DSS Requirement 2 outlines the specifics of how to keep systems secure and how to reduce the risk of an attacker gaining access to sensitive information. For additional details and specifics of Requirement 2, read on.

For additional details on all 12 of the Requirements, read our PCI DSS Requirements overview.

Requirement 2 Details and Sections

PCI DSS Requirement 2 has three total sections that detail specifics on securely configuring your system components.

The requirement sections are:

• Requirement 2.1: Processes and mechanisms for applying secure configurations to all system components are both defined and understood.
• Requirement 2.2: System components are configured and managed securely.
• Requirement 2.3: Wireless environments are configured and managed securely. 

Requirement 2.1: Processes and mechanisms for applying secure configurations to all system components are defined and understood.

This requirement focuses on managing and maintaining the various policies and procedures specified throughout PCI DSS requirement 2. It is required that these policies are both outlined clearly and properly documented, maintained, and shared with everyone involved so that the critical system components are implemented.

• Requirement 2.1.1: All security policies and operational procedures identified in Requirement 2 are documented, kept up-to-date, in use, and known to all impacted parties.
• Requirement 2.1.2: Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood by all parties.

Requirement 2.2: System components are configured and managed securely.

This section focuses on configuring system components to keep attacks to a minimum. Many operating systems, databases, network devices, software, and applications have known weaknesses that, when configured to reduce security vulnerabilities, minimize the attack vectors available. 

Because attackers try vendor default account names and passwords - which are often published and well known - to compromise systems, one such change is to update vendor accounts from the default names and passwords.

Likewise, by removing or disabling all unnecessary services and functions, organizations can secure the functions that are required and reduce the risk that unknown or unnecessary functions will be exploited. 

• Requirement 2.2.1: Configuration standards are implemented and maintained to cover all systems; they address all known security vulnerabilities; and are updated as new vulnerabilities arise.
• Requirement 2.2.2: If vendor default accounts are used, the default passwords are changed; otherwise, the default accounts are removed.
• Requirement 2.2.3: Primary functions requiring different security levels are managed such that only one primary function exists on a system component, any primary functions existing in the same system with dissimilar security levels are isolated from each other, or primary functions in the same system with dissimilar security levels are all secured to the level with the highest security need.
• Requirement 2.2.4: Only necessary services, protocols, and functions are enabled, and all unnecessary functionality is removed. 
• Requirement 2.2.5: If any insecure services or protocols are present, the business justification is documented, as well as any additional security features.
• Requirement 2.2.6: System security parameters are configured to prevent misuse.
• Requirement 2.2.7: All non-console administrative access is encrypted using strong cryptography. 

Requirement 2.3: Wireless environments are configured and managed securely. 

This requirement focuses on the security of wireless environments, which are often the target of attacks.

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

Whenever someone with knowledge of encryption keys has changed roles or left the organization, or a key is suspected of having been compromised, the encryption keys should also be changed to protect the underlying data.

• Requirement 2.3.1: Any wireless environment connected to the cardholder data environment (CDE) or transmitting account data should have all vendor defaults changed at installation or confirmed to be secure.
• Requirement 2.3.2: Any wireless environment connected to the CDE or transmitting account data should have wireless encryption keys changed whenever anyone with knowledge of the key leaves the company, or whenever a key is suspected to be compromised.

How Basis Theory can help you Satisfy PCI DSS Requirement 2

Securing cardholder data in a CDE satisfies many PCI DSS requirements and provides companies greater control and flexibility over their payment stack. However, building and maintaining the necessary infrastructure and programs can require hundreds of thousands of dollars and months to implement and assess. Basis Theory provides the platform, infrastructure, and tools to secure cardholder data in minutes and without these costs and distractions.

As a PCI Level 1 compliant service provider, Basis Theory extends an independently assessed and approved CDE to customers. Combined with a suite of configurable tools, services, and tokens, companies can collect, secure, and share credit cards without bringing their systems into scope. This approach allows companies to avoid the costs and distractions associated with 95% of the requirements in the Payment Card Industry Data Security Standard (PCI DSS) while retaining complete control over their cardholder data.

*PCI DSS Requirement information contained in this post is for educational purposes only and references material from the guide "Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0" published by the PCI SSC in March 2022. Please refer to the PCI Security Standards Council website for the complete, up-to-date, accurate requirements.