Do you need a PCI-DSS-compliant hardening policy?

By Roy, on November 30th, 2016

Server configuration hardening is a basic requirement for compliance with PCI-DSS V3.2. 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.2 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 operating systems and applications configurations are not done for purposes of security; they are only for ease of deploying a server for ease of use. Such server, when used as supplied, makes your IT infrastructure vulnerable to attacks.

What Security Policies Should be used For Hardening?

Hardening is changing the 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

The PCI requirements as stated in the official standard are shown in the following table:


System hardening should be an IT security ritual happening every time a new server joins the network and continue along the servers’s life-cycle. There has to be a documented system functionality and security baseline with the goal to remove unnecessary functions and securely configure what remains. There is also the need for regular system update and re-hardening each time an update occurs to reaffirm the system is properly hardened.

A hardening culture requires that following established security standard and processes is sacrosanct and should not be treated with levity. No server comes pre-hardened, it is IT administrators job to do the hardening.

While server hardening is a mandatory requirement for PCI compliance it reflects an ongoing challenge for the IT teams. Deploying hardening benchmarks can prove to be costly, repetitive, and complicated to manage – mainly for two reasons:



While using manual hardening methods or familiar hardening tools, the hardening process may affect the OS or an application’s functionality and cause server downtime. In order to prevent downtime, IT teams spend long hours testing policies in lab environments before deploying them on servers in production environments.

CONFIGURATION DRIFT – The authorization of multiple privileged users in an enterprise environment makes it difficult to ensure that servers remain hardened, thus, requiring IT teams to repeat the hardening process on a regular basis.

CalCom’s server hardening automation platform locks down servers with the CIS security benchmarks in a cost effective and outages free fashion. The CHS learning capabilities overcome the need to commit your IT team to long hours of policy testing and putting down fires when outages occur due to hardening. Easily achieve compliance with PCI-DSS requirement 2.2., Reduce IT administration costs for server hardening tasks and ensure continuous compliance with known hardening standards while avoiding system crashes and outages.



  • Deploy the required security baseline without affecting the production services.
  • Reduce the 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 servers.


  • Check to disable unnecessary services and protocols. Services and protocols not in use need to be disabled. For instance, when configuring a web server that does not require FTP access, then FTP should be disabled so that hackers will not gain entry into the server through the FTP service not configured. Point to note here is reviewing the system configuration to identify services not needed and disable them.


  • Prevent misuse by configuring network security parameters. The servers and all connected devices on your network should be set up to prevent unauthorized access and monitor all authorized access. The configuration should apply least-privilege access to each device and machine to enable authorized persons to do their primary jobs.