Server configuration hardening is a basic requirement for compliance with Payment Card Industry Data Security Standard (PCI DSS) v4.0 that was updated in April 2022 from PCI DSS Version 3.2.1. Server hardening is a fundamental process that ensures the security of servers in the network by reducing the servers attack surface through implementation of secure configurations. PCI-DSS has various challenging requirements, but requirement 2 that states 'Apply Secure Configurations to All System Components' poses a basic challenge to IT and security teams that manage large production environments which need to comply with PCI-DSS.
PCI DSS requires IT organizations to address all known security vulnerabilities and remain consistent with industry-accepted system hardening standards. The default configurations of operating systems and applications prioritize ease of server deployment and user-friendliness over security considerations. When utilized in their default state, these servers introduce vulnerabilities into your IT infrastructure, rendering it susceptible to various forms of cyberattacks.
What Security Policies Should be used For Hardening?
Hardening is changing the Operating System (OS) and applications configurations from the default setting to the desired baseline security standard in order to lock down the server. The PCI DSS council recommend to use any of the following benchmarks as a hardening policy:
- Center for Internet Security (CIS)
- National Institute of Standards and Technology (NIST)
- International Organization for Standardization (ISO)
- SysAdmin, Audit, Network, and Security (SANS) Institute
A new reporting option was included to PCI DSS v4.0 document requirements called "In Place with Remediation." The goal of this option was to promote security as a continuous process, by providing a means for organizations to identify areas needing improvement year over year.
The PCI 2.2 requirement as stated in the official standard are shown in the following table:
System hardening must be a recurrent and ingrained practice within IT security, rigorously adhered to each time a new server integrates into the network and sustained throughout the server’s operational life span. This process necessitates the existence of a meticulously documented system functionality and security baseline, with the overarching objective of eliminating superfluous functionalities and meticulously configuring those that are retained in a secure manner. Furthermore, it is imperative to carry out periodic system updates and re-hardening endeavors with every occurrence of an update to revalidate that the system maintains its robust state of hardening.
Changes from PCI DSS Version 3.2.1 to 4.0 Revision 2
The following change types from PCI DSS v3.2.1 to 4.0 are:
PCI DSS changes made specifically for system hardening in Requirement 2: Apply Secure Configurations to All System Components are as follows:
You can find the entire document for the PCI DSS Summary of Changes from v3.2.1 to v4.0 – Dec 2022 here.
Milestones for Prioritizing PCI DSS Compliance Efforts
The Prioritized Approach for PCI DSS compliance includes six milestones. The following table summarizes the high level goals of each milestone.
| General Changes Implemented Throughout PCI DSS Requirements | Change Type |
|---|---|
| Reformatted overview sections and added a summary of the sections to the beginning of each principal requirement. | Structure or format |
| Updated overview sections and added guidance at the start of each requirement section. | Clarification or guidance |
| Added numbered requirement description headings throughout each requirement to organize and describe the requirements that fall under it. | Structure or format |
| Renumbered requirements and testing procedures and reorganized requirements due to the addition of numbered requirement description headings | Structure or format |
| Rephrased directive requirements to be objective. | Evolving requirement |
| Moved examples from requirements or testing procedures into the guidance column. | Structure or format |
| Removed references to sampling from testing procedures. | Clarification or guidance |
| Shortened testing procedures by clarifying testing is to be done “in accordance with all elements specified in this requirement” to minimize redundancy between requirements and testing procedures. | Clarification or guidance |
| Updated language in requirements and/or corresponding testing procedures for alignment and consistency. | Clarification or guidance |
| Enhanced testing procedures to clarify level of validation expected for each requirement. | Clarification or guidance |
| Reformatted requirements and testing procedures and made minor wording changes for readability – for example, content from paragraphs reformatted to bullet points. | Structure or format |
| Combined requirements that support the same intent and separated requirements that support different intents. | Structure or format |
| Separated complex requirements / testing procedures and removed redundant or overlapping testing procedures | Structure or format |
| Moved required elements that were included only in testing procedures to requirements, to clarify the requirement and to facilitate shortening of the testing procedures. | Clarification or guidance |
| Moved and reworded policies and procedures requirements from the end to the beginning of each principal requirement | Structure or format |
| Removed notes about SSSL/Early TLSSL/Early TLS from the guidance columns for requirements that referenced those specific protocols. | Clarification or guidance |
| Changed “cardholder data” to “account data” as needed to align with usage and intent. | Clarification or guidance |
| Changed terminology used to refer to frequency throughout the requirements in accordance with Description of Timeframes Used in PCI DSS Requirements. | Clarification or guidance |
| Added titles and reorganized content of the guidance column to aid understanding and merge similar information. | Structure or format |
Requirement 2.2 System components are configured and managed securely
According to the PCI DSS Guide, Requirement 2.2 is one of the stringent requirements of the PCI DSS. This requirement mandates that the system should be hardened by ensuring that system elements are reinforced as much as possible before joining the network.
To comply with PCI DSS requirement 2.2, merchants must fix all identified vulnerabilities and comply with well-known hardening practices. CalCom Hardening Suite (CHS) platform locks down servers with the CIS security benchmarks in a cost effective way with no disturbance to production. The CHS learning capabilities overcome the need to commit your IT team to long hours of policy testing and putting out fires when outages occur due to hardening. Easily achieve PCI-DSS compliance and reduce IT administration costs for server hardening tasks.
Automated Hardening Benefits:
- Deploy the required security baseline without affecting the production services
- Reduce costs and resources required for implementing and achieving compliance
- Manage the hardening baseline for the entire infrastructure from a single point
- Avoid configuration drifts and repeated hardening processes
In addition to following the recommended baselines PCI-DSS recommends additional server hardening procedures:
- Implement only one primary function per server. PCI Requirement 2.2.1 recommends applying only one primary function per server and not to combine functions. For instance, a database server should not also be a mail server. But for budget constraints, best practice should be to separate primary functions using different servers. The security concern behind requirement 2.2.1 is that each server role will have a proper configuration. In the reality we see servers often get more than one role, this situations requires dedicated hardening policies per server.
- Cover all system components.
- Address all known security vulnerabilities.
- Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
- Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
- Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
