If you’ve been keeping up with the Payment Card Industry Data Security Standard (PCI DSS), you’ll know it has a new specification that revolves around network security controls. Let’s dig into the details.

A Little Back Story

It helps to level-set for anyone who might be coming into this from a non-technical role. We all know PCI DSS (v4.0) is the payment card industry’s compliance standard for protecting our sensitive cardholder data (from names and credit card numbers to addresses and SSNs).

Part of protecting this information (as opposed to the swaths of other data major card companies collect) has to do with separating it into a Cardholder Data Environment (CDE). Generally speaking, that’s what Requirement 1 (out of 12) is all about.  Once you’ve built out your CDE, it forms the foundation and the focal point around which the other 11 PCI DSS Requirements revolve.

What is PCI DSS 4.0 Requirement 1?

Requirement 1 is to “Install and Maintain Network Security Controls.” It includes five subsets:

• Requirement 1.1: Processes and mechanisms for installing and maintaining network security controls (firewalls) are defined and understood.
• Requirement 1.2: Network security controls (NSCs) are configured and maintained.
• Requirement 1.3: Network access to and from the cardholder data environment is restricted.

And these two are new to PCI DSS v4.0:

• Requirement 1.4: Implement segmentation to isolate the CDE from other parts of the network.
• Requirement 1.5: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

We will be focusing on Requirement 1.2.

What is Requirement 1.2?

PCI DSS 4.0 Requirement 1.2 codifies the business of properly configuring and maintaining network security controls (NCSs). We’re going to zero in on Requirement 1.2.2 for the purpose of this blog and its three parts because this requirement can be tricky to implement properly and Fortra’s Tripwire can make complying with this requirement much easier.

Defined Approach Requirement 1.2.2

Its Defined Approach Requirement 1.2.2 states that Requirement 6.5.1 change control procedures hold sway over all NCS configurations and network connections.

Requirement 6.5.1: Changes to all system components in the production environment are made according to established procedures that include:

• Reason for and description of the change.
• Documentation of security impact.
• Documented change approval by authorized parties.
• Testing to verify that the change does not adversely impact system security.
• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.
• Procedures to address failures and return to a secure state. 

Defined Approach Testing Procedures

For the sake of clarity, the requirements will be paraphrased to bring out the most essential quality. You can reference the screenshot above for full details.

• 1.2.2.a: Make sure documented NCS change processes (for network connections and configurations) match 6.5.1. 
  This is an obvious and perfunctory first step to avoid confusion in governance.  
• 1.2.2.b: Examine NCS network connection changes yourself, interview those involved, and double-check that they comply with 6.5.1.
  Make sure changes to NCS network connections are free of injection flaws, as specified in 6.5.1.   
• 1.2.2.b: Examine NCS configuration changes yourself, interview those involved, and double-check that they comply with 6.5.1.
  Make sure any alterations to the system components in the production environment are made according to established procedures such as: stating the reason for the change, testing to make sure the adjustment does not negatively impact other components, and implementing procedures in case of failure.

You know what they say: If you want something done right, [review] it yourself. Thankfully, Tripwire has some tools to make this process easier.

Tripwire and PCI 1.2

Tripwire State Analyzer (TSA) helps you centrally manage policies like these and comply with Requirement 1.2 by allowing you to:

1. Find records in centralized Allowlist configurations that contain approved configuration items.
2. Automatically validate detected system configurations against your Allowlist configurations.
3. Create detailed system configuration reports of both authorized and unauthorized configurations.
4. Documenting the security impacts of the ports in question is automated.
5. Tripwire Enterprise’s integration to ticketing systems can help automate change approval processes.

TSA also collects and reconciles the following, consistent with 1.2 requirements:

• Network Ports              
• Local Users    
• Local Groups
• Services            
• Installed Software     
• Local Shares 
• Persistent Routes

Adhering to new PCI 1.2 specifications might require additional effort, but Tripwire’s solutions for vetting network security control changes alleviate a lot of that burden.  The energy utilities have had this compliance requirements for years now as part of NERC CIP compliance standards and PCI has recognized the risk reduction impact of these requirements.  Tripwire can do for PCI what we’ve been doing for NERC CIP for years.

To learn more about how Tripwire can help you comply with PCI DSS 4.0, click here.