Raising the PCI DSS Standard

Introduction

As someone that started their professional career with 22 years in the RAF Police, with the final decade of service being within the roles of Counter Intelligence and Computer Security, I have become accustomed to the importance of having a comprehensive suite of documents and receiving extensive training on all these supporting documents I need to know to effectively carry out my specific roles.

This is an area that doesn't appear to be given quite the same importance or care within the corporate environments and especially does not appear to be given the appropriate importance for PCI DSS.

Thankfully, the PCI SSC has started to address this with the latest evolution of the PCI DSS (v4.0).

Now, each requirement commences with a section on reducing the risks associated with the 'Human Factor' threat:

"Processes and mechanisms for installing and maintaining network security controls are defined and understood."

• All security policies and operational procedures that are identified in Requirement ## are: ? Documented. ? Kept up to date. ? In use. ? Known to all affected parties.
• Roles and responsibilities for performing activities in Requirement ## are documented, assigned, and understood.

However, in this article, I will articulate an important addition to the PCI document set, which is often missed or treated as a 'tick box' for compliance and which is as equally important as the:

1. Policies.
2. Processes.
3. Operational Procedures.

To which documents do I refer?

• Configuration Standards (Network Security Control (NSC) devices, Servers, Endpoints, etc.).

What is a Standard?

There are numerous meanings for the term 'Standard' but for PCI DSS, the most appropriate are provided by NIST:

As you can see from these NIST definitions, all allude to these being documents that can be used as a reference for building network devices and systems. The importance of having an effective Configuration management practice is reflected in this having been identified by the Center for Internet Security (CIS) as being their No.4 most Critical Security Control (CSC) and for it being a major contributing factor within the STRIDE-LM Threat Model (only Denial of Service (not a PCI DSS concern) being omitted):

PCI DSS v4.0 Configuration Standards

Within PCI DSS v4.0, the mandated need for a documented configuration standard is essential for aligning with the objectives for:

• Goal 1: Build and Maintain a Secure Network and Systems.

This is achieved through the application of Configuration Standards for all in-scope Network Security Control (NSC) devices (Requirement 1: Install and Maintain Network Security Controls) and systems (Requirement 2: Apply Secure Configurations to All System Components):

• 1.2. Network security controls (NSCs) are configured and maintained.
• 2.2. System components are configured and managed securely.

Implementing & Auditing Configuration Standards for PCI DSS v4.0

Failing to consistently apply a secure build, across all your network and systems, would significantly increase your risks and, consequently, alignment with PCI DSS should not be able to be demonstrated and PCI DSS compliance could not be achieved.

Thus, it is important that the build process applies a standardized approach so that everyone with a supporting role builds the network and systems consistently.

In addition to having a standardized configuration document, it is beneficial to incorporate some automation to the configuration standard (e.g., CIS Build Kits) and to document the standard to which each IT asset (or a group of IT asset types) must be configured (e.g., Target of 90% score against CIS Benchmark, list of acceptable insecure services, enabled ports, etc.).

A failure to correctly apply your configuration standards has negative implications for other PCI DSS requirements, e.g.,

Requirement 1:

1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.

• The configuration standards are integral to this.

1.3 Network access to and from the Cardholder Data Environment (CDE) is restricted.

• Ineffectively configured NSCs may fail to appropriately restrict access in/out of the CDE.

1.4 Network connections between trusted and untrusted networks are controlled.

• ?Ineffectively configured NSCs may fail to appropriately enable the effective control of any connections between trusted and untrusted networks.

Maintaining Secure Configuration Standards

Having documented the acceptable configuration standards that must be applied across the organization, it is important to ensure that these continue to be applied. This is achieved through the examinations of the documented configuration standard and comparing them against the actual network and system settings, to ensure that any changes have not inadvertently comprised any supporting network devices and systems.

This can be further enhanced through automation, using tools such as:

• Titania Nipper.

• CIS CAT Pro Assessor.