PCI-DSS Requirement 2.2: Server Hardening Standards Guide

The Payment Card Industry Data Security Standard (PCI DSS) is a global initiative that provides a consistent, baseline framework of security measures, facilitating their adoption and implementation. PCI DSS Requirement 2.2 states that System components are configured and managed securely. In this guide, we will provide the necessary background and context to understand and comply with Requirement 2.2.

We will review each step and summarize exactly what you need to know to implement it. We will provide you with additional resources to support you. Next, we will examine the challenges involved in complying with, managing, and enforcing PCI DSS system hardening requirements. We will then demonstrate the benefits of using a compliance automation solution, such as CalCom’s Hardening Suite (CHS).

What You Will Learn

• What is PCI-DSS
• Why the PCI-DSS standards matter
• The role of Requirement 2.2 in PCI-DSS compliance
• Understand the challenges involved with planning, implementing, managing, and enforcing Requirement 2.2’s hardening requirements.
• Each sub-requirement in Requirement 2.2, including its objective, approach, and testing procedure
• How CalCom’s Hardening Suite can help you automate PCI-DSS compliance

Requirement 2.2 Hardening Standards: In-Depth Guide

Requirement 2.2 mandates that organizations harden their server hardware, operating systems, and applications against attack. To comply, organizations must enforce and manage server hardening baselines, along with their detailed sub-requirements. Each of these sub-requirements includes detailed testing procedures and guidance that organizations must implement.

Let’s take a deeper look at each of these sub-requirements.

2.2.1 Configure system components securely and consistently

Configuration standards are developed, implemented, and maintained:

• Cover all system components.
• Address all known security vulnerabilities.
• Be consistent with industry-accepted hardening standards or vendor recommendations.
• Updated as new vulnerability issues are identified
• Applied when new systems are configured or when a system component is connected to a production environment.

Testing Procedure

1. Verify that your system configuration standards cover this requirement.
2. As new vulnerabilities are identified, review policies and procedures, and interview personnel to verify that system configuration standards are up to date.
3. Review policies and procedures and conduct interviews with personnel to ensure compliance with system configuration standards:

• When configuring new systems, or
• A component is connected to a production environment

Further Information

For guidance on industry standards, see the Center for Internet Security (CIS), the ISysAdmin Audit Network Security (SANS) Institute, the National Institute of Standards and Technology (NIST), the Cloud Security Alliance (CSA), and vendor documentation.

2.2.2 Default passwords are insecure

All vendor default account passwords must be changed, removed, or disabled

Testing Procedure

1. Review system configuration standards and default vendor accounts to ensure they meet this requirement.
2. Examine vendor documentation and observe system administrator(s) logging on using vendor default accounts
3. Verify that all unused vendor default accounts are removed or disabled.

Further Information

Password Policy Configuration for Safer Security.

2.2.3 Primary function security needs take precedence

Primary functions with lower security needs cannot affect the security of primary functions with higher security needs on the same system component.
Primary functions requiring different security levels are managed as follows:

1. Only one primary function exists on a system component, or
2. Primary functions with differing security levels on the same system component are isolated from each other.

Testing Procedure

1. Verify that system configuration standards for primary function security levels meet this requirement.
2. Review system configurations to verify that primary function security levels are managed as specified in this requirement.
3. For virtualized systems, verify that the system functions with differing security needs:

• Do not co-exist on the same system component
• If they exist on the same system component, are isolated from each other, and are secured to the level of the highest security need.

Further Information

User Rights Assignment

2.2.4 Unnecessary functionality compromises security

Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.

Testing Procedure

1. Review system configuration standards to verify that only necessary services, protocols, daemons, and functions are identified and documented.
2. Examine system configurations to verify:

• Unnecessary functionality is removed or disabled.
• Only functionality, as documented in the configuration standards, is enabled.

Further Information

How to Apply CIS Benchmark Levels to Secure Systems

2.2.5 Insecure services, protocols, or daemons are exploitable

If any insecure services, protocols, or daemons are present:

• Business justification is documented.
• Document and implement additional features that mitigate the risks associated with insecure services, protocols, or daemons.

Testing Procedure

1. Review system configuration standards and interview personnel to verify that the implementation and management of insecure services, protocols, or daemons comply with this requirement.
2. Verify that additional security features are implemented and documented.

Further Information

For guidance, refer to the European Union Agency for Cybersecurity (ENISA), the Open Worldwide Application Security Project (OWASP), and vendor documentation.

2.2.6 Correct configuration increases security

System components cannot be compromised because of incorrect security parameter configuration.

Testing Procedure

1. Review system configuration standards to verify they include system security parameters to prevent misuse.
2. Interview system administrators and/or security managers to verify they know standard security parameter settings for system components.
3. Ensure that system security parameters are set in accordance with the configuration standards.

Further Information

Industry standards and vendor documentation

2.2.7 Administrative authorization must be encrypted

Clear-text administrative authorization factors cannot be read or intercepted from any network transmissions. All non-console administrative access is encrypted using strong cryptography.

Testing Procedure

1. Review system configuration standards to verify that all non-console administrative access uses strong cryptography.
2. Observe an administrator and review system configurations to verify that non-console administrative access management complies with this requirement.
3. Verify that system component authentication and remote login service settings are unavailable for non-console administrative access.
4. Interview personnel and review documentation to verify that strong cryptography is implemented according to industry best practices and/or vendor recommendations.

Further Information

Understanding Cryptographic Mechanisms

Implementing PCI-DSS Requirement 2.2 and Its Challenges

Managing and enforcing Requirement 2.2 is a challenge for any IT and operations team in organizations of any size; however, the scale of the challenge increases proportionally to the organization’s size and its server and networking infrastructure. This poses a fundamental challenge to organizations managing large server environments, as implementing and managing secure baselines is both labor-intensive and error-prone. Enforcing baselines on production servers might create system outages and application malfunctions. 

In this article, we presented the background and context behind PCI-DSS and Requirement 2.2. This was followed by an in-depth examination of the key elements of each sub-requirement, including its key objective, approach, and testing procedure. Using this information, you can understand the size and complexity of the challenge and start planning how to manage your organization’s PCI-DSS compliance.

Key Takeaways

• PCI-DSS compliance is mandatory for any organization participating in the global payments system
• Failure to comply with PCI-DSS can result in penalties and fines
• Requirement 2.2 plays a vital role in PCI-DSS compliance by providing a detailed framework for securing servers.
• The process of implementing, managing, and enforcing the hardening requirements outlined in Requirement 2.2 is highly challenging.
• Requirement 2.2 includes seven sub-requirements that must be implemented and tested.
• CalCom’s Hardening Suite can help you automate PCI-DSS compliance.

How CalCom’s Automated Solution Can Help You

CalCom Hardening Suite (CHS) is a baseline hardening solution designed to address the needs of IT operations and security teams. CHS significantly reduces operational costs and eliminates service downtime by indicating the impact of a security baseline change directly on the production environment. CHS’s automated process simulates the effect of a change in a production environment, thus saving the need for testing changes in a lab environment. CHS enables you to:

• Deploy security baselines without affecting the production services.
• Reduce the costs and resources for implementing compliance.
• Manage hardening baselines for your entire infrastructure from a single point.
• Avoid configuration drifts and repeated hardening processes

Achieve PCI DSS 2.2 Compliance with Secure Server Hardening