Ever Wish You Could Get Inside your QSA’s Head Before Your Next PCI Audit?

A few weeks ago, Adam Gaydosh, a certified QSA with Anitian, and Nimmy Reichenberg, our VP of Strategy here at AlgoSec presented an educational webinar on the top PCI audits pitfalls, and how to avoid them. You can view the full presentation is here, but for those of  you who don’t have the time and want the ‘readers digest’ version here are some of the highlights from the webinar.

First, we kicked off by asking the live audience (225 people) what they fear most about their PCI audit. The results were not unexpected:

• 29% fear not understanding what the auditor is looking for
• Another 29% fear discovering unapproved, undocumented changes
• 21% fear finding undocumented card holder data
• 17% fear discovering evidence of a breach
• The final 4% fear the auditor’s sense of humor (yes, we really did ask that :-))

Less is More: Demystifying the Scope of a PCI Audit

As we saw in the poll, one of the biggest concerns related to an audit is the scope of the audit. As Adam clarified, the scope of a PCI audit includes the people, process and technologies of:

• The Cardholder Data Environment (CDE)
• Systems connected to the CDE
• Other systems that can affect the security of the CDE.

What’s in the CDE: The most obvious are all systems that store, process, or transmit Cardholder Data (CHD) like POS terminals, cardholder databases, payment processing applications, the firewalls, switches, and routers that handle any CHD traffic. Less obvious are all systems that share a network segment with a CDE system, such systems that reside on the same VLAN or subnet as a CDE system.

What else is in scope for the audit: Any system that connects to the CDE, either by making a network connection into the CDE, or that receives an outbound network connection from any CDE system. Those include AD, DNS, FIM and backup servers, AV consoles and web proxies, etc. Also, any other system that can otherwise affect the security of the CDE, such as password repositories, data center physical security systems, and managed security providers.

Map everyone and everything connected to the CDE: When performing an audit your QSA will want to know which people, processes and technologies touch the CHD. So you should first map all the data flows of all CHD to determine them. Then inventory all network segments and systems in the CDE, as well as review access control lists to determine which non-CDE system are connected to CDE systems.

What’s In and What’s Out: Segmenting your Network for Compliance

From the auditor’s perspective, your entire IT environment is, by default, considered to be in-scope. So if you use segmentation to isolate systems that touch CHD, this limits the number of systems that can affect the CDE. Once you’ve scoped out your environment, isolate those systems that touch CDE either by migrating them to dedicated network segments (or by removing the other systems). You should also double check the business need for all remaining CDE connectivity, and eliminate all connections where possible to reduce assessment scope. ACLs are a good way to enforce your segmentation.

Ultimately segmentation should create three types of systems on your network:

• CDE systems, which touch cardholder data, and are isolated in dedicated network segments with ACLs
• In-scope systems, which are not in the CDE and don’t touch CHD, but require access to the CDE via ACLs, or which affects the security of the CDE
• And out-of-scope systems, which don’t interact with the CDE or CHD at all.

This level of segmentation not only enhances compliance but strengthens your entire network security posture.

Best Practices for Configuring the CHD Security Infrastructure

Once you’ve segmented your CHD, make sure to correctly configure the security infrastructure within your CDE. This includes:

• Host hardening
• Antivirus (AV)
• Patch & Vulnerability Management
• Configuration Management
• User and Account Management
• Log Management
• Change Detection

…and avoid these common pitfalls:

• Host hardening standards not consistently deployed
• Security patch deployment not comprehensive or timely
• Configuration changes not always tracked
• Excessive user accounts and rights
• Security event logs not appropriately aggregated and reviewed
• System change detection monitoring coverage not comprehensive or not alerting
• Failure to validate that changes were performed correctly
• “Cowboy” changes to configurations not detected
• Baseline configuration not defined or enforced to ensure compliance

PCI in the Cloud – It’s Not an Oxymoron

The migration of business applications to the cloud is now a given – and sooner rather than later. However what many people don’t always realize is that if these cloud based systems affect the security of the CDE, they are now subject to PCI compliance. We discussed this issue at the end of the webinar.  Here are some of the recommendations:

Do PCI due diligence on cloud-based services. You can be PCI compliant with cloud providers, including MSPs, SaaS and PaaS vendors — but only if you first ensure that the provider is PCI DSS compliant. Require that service providers clearly and specifically define what areas of PCI they cover, and make sure you use those services accordingly. Never assume that you can outsource compliance; you will ultimately have the final responsibility.

Unify your security policy management across every environment. Have a single pane of glass across everything, ranging from physical servers, applications, networks, data centers, and firewalls under your direct control on-premises or in colocation facilities; services hosted in private clouds; and services hosted in the public cloud. Look for automated compliance reports to show you instantly what’s working, and identify problems your compliance team needs to address.

Continuous Compliance is the Goal

Last but not least, as organizations focus on best practices, such as those above, compliance should be simple – and assumed. Forget about having fire drills where you stop what everyone is doing, run your own internal audit, and rush to ensure just-in-time compliance before the QSA shows up. Not only is it wasteful, but the PCI compliance rules aren’t there merely for audits – they are there to protect you, your business, and your customers every day. The best way to be compliant is to stay in compliance all the time.

Adam and Nimmy have lots of tips and suggestions to help your organization improve PCI compliance and prepare for the QSA’s audit. Watch the full webinar on the top PCI pitfalls here.