How Safe Are Your PCI In-Scope Assets From Nefarious Threat Actors?

Welcome back to the Ultimate Guide To PCI DSS Requirement Frequencies! So far we’ve covered Understanding Your Scope and Getting Control of Unruly Firewall and Router Rules. 

Today we’re moving on to PCI DSS Requirement 2: Do not use vendor supplied defaults for system passwords and other security parameters. Our focus is on the other security parameters since changing vendor supplied defaults is self-explanatory. 

Requirement 2 has eight main requirements and 33 sub-requirements. There no explicit requirement frequencies; however, if your not minding your configuration standards and configuration scanning policies, you could find yourself in a deep dark remediation abyss or worse, you could be the target of a nefarious individual or dark web criminals out to steal your customer credit card data.

There’s one sub-requirement with an implied frequency, 2.2.b:

“Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1.”

Here’s where knowing your PCI DSS requirements comes in handy. Requirement 6.1 is not only connected to Requirement 2.2.b, but also Requirement 11.2.1:

“Perform quarterly internal vulnerability scans. Address vulnerabilities and preform rescans to verify all “high-risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking (per Requirement 6.1).”

While configuration standards don’t change often, they should be reviewed at least quarterly to ensure the standards do not contain “high risk” and “critical” vulnerabilities.

Drift Happens

You know that old saying right? 

One of the biggest challenges for merchants is that systems drift from their original hardening per any of the industry accepted system hardening standards, e.g. National Institute of Standards Technology (NIST). Once any PCI in-scope system drifts from the applied configuration standard, you’re out of compliance and the clock is ticking to get that asset realigned to the configuration standard. 

What’s even worse than drift is when assets are placed into production without being hardened to the approved configuration standard. That right there is an automatic “do not pass go.” 

The founders of Payment Card Assessments know all to well what it’s like to receive a scan report with over 2,000 configuration failures, a standards team that didn’t communicate changes to the scanning team, and an implementation team that had no idea what they were supposed to do to an in-scope asset before it went into production. 

Not only did PCA’s founders step in to resolve the multiple compliance and security failures, but they also established a Configuration Management Program with robust processes to ensure continuous compliance.

Eight Best Practices For Keeping Your In-Scope Assets Safe, Secure, and PCI DSS Compliant

• Establish a build clean process: Configuration standards for in scope PCI DSS assets must be known and adhered to by all teams responsible for PCI assets. There are no exceptions or deviations from the standards.
• Establish a quarterly review process of the standards to ensure the standards do not contain “high risk” and “critical” vulnerabilities.
• Establish a frequency for running configuration standard scans. At PCA, we recommend to all our clients that scanning your PCI assets should be done on a weekly basis.
• Treat configuration drift findings as critical vulnerabilities with a 30 day remediation window. Why? Anytime an in-scope asset drifts from the configuration standard, a door or window is cracked open and the asset is now exposed. It’s an open invitation for a bad actor to hack their way into your network.
• Establish a communication path between the configuration standards team and the configuration scanning team. The scanning policy must mirror the configuration standard at all times.
• Establish a keep clean process: When in-scope assets drift (because they will), a process must be implemented to correct the drift. We recommend auto generated tickets to the responsible teams for remediation or a tool that will automatically bring the asset back into the correct configuration standard. 
• Establish a process to keep your in-scope asset inventory current. Capture all required information about the asset, including OS and version, as well as the system administrator. 
• It’s critical that your organization’s ISA or PCI compliance team has a strong working and professional relationship with your configuration standards, scanning, and vulnerability management teams. It is in your ISA’s best interest to help these teams understand their PCI requirements, roles and responsibilities. 

Don’t miss our next installment on PCI DSS Requirement Frequencies!

Our next article will focus on Requirement Area 3 and 4: Protect stored cardholder data and encrypt transmission of cardholder data across open and public networks.

Hint: If you don’t need to store cardholder data, Don’t Store It.

Never Miss A Post!

Schedule Your Free 30 Minute Consult Today

If you’re struggling with your PCI Compliance and need immediate help, schedule your free 30 minute consult today. Whether you need a gap assessment or desire to establish a continuous PCI DSS Compliance program, Payment Card Assessments is the partner you need.