PCI DSS compliance is a requirement for any business that stores, processes, or transmits cardholder data. The PCI-DSS standard has various requirements. Requirement 2.2 poses a fundamental challenge to many organizations managing large server environments as it requires enforcement and management of servers hardening baselines.
Default operating systems and applications configurations are not built for purposes of security, but for ease of deploying a system and for ease of use. Such a system, when used as supplied, makes your entire infrastructure vulnerable to attacks. Hardening the servers (OS and applications) is a basic requirement in an enterprise security posture.
The process of hardening servers involves both IT ops. and security teams and require changes to the default configuration according to industry benchmarks.
PCI-DSS requirement 2.2 guide organizations to: “develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with security accepted system hardening standards.” Recommended standards are the common used CIS benchmarks, DISA STIG or other standards such as:
Although finding a baseline and approving it is a relatively easy task, enforcing and managing a baseline such as CIS/DISA STIG is labor-intensive and error-prone for IT teams.
Enforcing baseline configuration changes on production servers might create system outages and application malfunction. Configuration changes must be carefully tested in lab environments before deployed in production, and yet after tested, services will break as the ability to simulate the production dependencies in a lab is impossible. The challenges of managing a hardening process often reflect as IT audit points for lack of configuration hardening and fines from the PCI-DSS council.
Develop configuration standards for all system components. Assure that these standards address all know security vulnerabilities and are consistent with industry-accepted system hardening standards.
Source of industry-accepted system hardening standards may include, but are not limited to:
2.2.a. Examine the organization’s system configuration standards for all types of system components and verify that the system configuration standards are consistent with industry-accepted hardening standards.
2.2.b. Examine policy 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 policy 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 being installed on the network.
2.2.d. Verify that system configuration standards include the following procedures for all types of system components:
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 a source of guidance on configuration standards, 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.
With CHS you’ll be able to:
CHS is a baseline hardening solution designed to address the needs of IT operations and security teams. It significantly reduces operational costs and eliminates service downtime by indicating the impact of a security baseline change directly on the production environment saving the need for testing changes in a lab environment.
