See part 1 here, part 2 here, part 3 here, part 4 here.

How to Create a Good Compensating Control
We’ve spent quite a bit of time setting this section up. We talked about what Compensating Controls are, what they are not, and some of the best mis-guided attempts to create them. Before we discuss the examples, please remember that these examples should be used for illustrative purposes only. I have over simplified the scenarios for brevity, and things are rarely as simple in the corporate world. Ultimately, compensating controls must be approved first by a QSA, or barring that, your Acquiring Bank. I know I don’t like it when someone slaps some random article about PCI on me during an assessment, so please don’t do that with this one. Now let’s walk through a couple of examples of how one might create a good compensating control.

Here’s a common compensating control that my team defines and implements at a customer. A Level 1 brick and mortar retailer with 2,500 stores has some systems in their stores that do not process cardholder data. These systems are a high risk to this customer’s cardholder environment because they may access both the internet through a local firewall and the corporate intranet and webmail system, and users log-in to that machine with the default administrator account. Store managers and retail operations claim that the systems are required for day-to-day business because each store is empowered to customize their operations to better fit the local market. The corporation believes this drives innovation and helps them maintain a competitive edge over their peers.


If the retailer chooses not to segment the network, all of the systems in the store are now in scope, and they must meet all of the applicable requirements of the PCI DSS. Doing this will add significant expense to the IT infrastructure, and will probably force a call center to be staffed up in order to manage the volume of calls that will come in for things like password maintenance.

What do you do? Do you crush the retailers aspirations to innovate by telling them they must deploy active directory to these machines, lock them down Department of Defense tight, and staff a call center? I suppose you could. But, if you made that recommendation you missed something important–understanding the business and limiting the impact that your compliance recommendations make. Instead, consider this compensating control.

Any number of network components could be used to create some segmentation in this environment. Let’s say that we have a VLAN aware switch at the location that can have access lists (ACLs) tied to it. Why not create a new VLAN for just the POS network? Then create some ACLs around it to make it look like it is segmented behind a firewall. Now the threat of the in-store PC is effectively mitigated provided that the ACLs are appropriately secure.


Wait a second, ACLs? Those are not supposed to be used for compliance with PCI! They most certainly can be used for compliance. Requirement 1.3.6 only refers to external connections, not internal connections. Using ACLs internally is perfectly acceptable. If you want an extra boost in security, use a reflexive access list (RACL) which will basically look and feel like a stateful inspection firewall.

“But Branden,” you say, “my store networks are different in every store! I can’t just slap something in there like that and expect it to work globally!” If this is the case, I bet your store support group is overloaded with break-fix calls. Maybe this could be an opportunity to shore this up and get consistent footprints in each store?

Barring that, how about this twist?

Let’s say that you are running a Windows XP variant as the operating system powering your POS. You are already required to put some kind of Anti-Virus and malware removal tools on there. Most of those come with software-based firewalls that could be administered remotely. Deploying firewall capabilities to the POS itself could be viewed as appropriate segmentation depending on the policy attached to that firewall. It is neither a transparent solution, nor is it very pretty, but it works.

The first solution above is really less of a compensating control and more of a way to reduce the scope of PCI. The best thing you can do for your company is reduce the scope of PCI (or any compliance initiative) to the bare minimum required, and then manage that subset of your infrastructure. The second truly is a compensating control. It meets the original intent and rigor of the original PCI requirements and provides a similar level of defense as the original requirements (reduce the vulnerability to payment systems), goes above and beyond the base requirements of PCI (firewalls are not required on devices that do not leave the premises), and it is most definitely commensurate with the additional risk imposed by not meeting the original requirement.

Take a closer look at those two suggestions. The first may be “free” to your company depending on what is already in place! You will need to adjust business process and prepare your IT community to deal with the change, but you may not need to spend any hard dollars rolling this solution out (unless your equipment cannot do this in the first place). The second suggestion, which is actually the compensating control, requires capital outlay for software licensing and training or consulting to build out the environment. Upon rollout, things will break that will result in potential losses to the business. I’ve seen retailers push changes like this to large environments, and every single one results in some kind of error.

Are you starting to get the hang of this thing? How about another example?

A Service Provider has a large mid-tier UNIX installation that runs critical areas of the payment process, including long-term data storage. For various reasons, encrypting the data is not an option on these machines. How do we make this service provider compliant with PCI Requirement 3.4?

This is a real world example that comes up frequently. Encryption implementations have come a long way since early in this decade. The words “my platform does not have a solution for encryption” is no longer valid for platforms that can comply with PCI. When I present the following control to customers, it is shocking how fast they find a way to encrypt their data.

Most mid-tier UNIX operating systems have the ability to switch from Discretionary Access Control (DAC) to Mandatory Access Control (MAC). MAC will cause that mid-tier UNIX machine to act like a mainframe using RACF/ACF2, and managing those controls is now a massive chore for whomever is charged with it. Converting the appropriate systems to MAC, and potentially adding some segmentation could effectively render cardholder data unreadable and meet PCI Requirement 3.4.

Things are never that easy. Security professionals inside companies love the idea of converting to MAC as it allows us to have more granular control over the systems and their data. Practical ones know that converting an existing system requires so much effort that the costs outweigh the benefits. This is a perfect example of how a compensating control might look good on paper (it’s only three words when you use the acronym! ‘Convert to MAC!’), but in reality would be much easier to just meet the implied requirement to encrypt that data.

One more example, and then it’s time for you to get creative!

A medium sized retailer with less than 500 stores is struggling with requirement 10.2.1 to log ‘all individual accesses to cardholder data.’ All of their data is stored in a large DB2 database that runs on a mainframe. They run massive batch processes at regular intervals, and their space constraints prevent logging every single access to a row. Do you tell them to go back to their board for a CapEx request to buy lots and lots of drive space to store logs?

Before we proceed, consider the intent of the requirement. Reliable logs are valuable in investigating a breach quickly. Without them, it may take forensic examiners days, or even weeks, to determine the source of a breach. Once the source has been identified and analyzed, forensic companies must attempt to determine how many card numbers may have been exposed. If there are no logs, the assumption is that everything could be exposed, meaning that fines will add up pretty quickly.

The idea is not necessarily to make a log record that includes every single card number that is accessed, but to be able to identify which cards are accessed through the data contained in the logs. If we were to log the actual query performed against the database during a batch process, with knowledge of the date and time that the query was run and exactly what that query will do, we should then be able to determine, with reasonable certainty, which cards were accessed. Common batch processes run on a daily basis, usually using the data from the previous day to produce its output. If we must determine what could have been exposed from January 1 to January 8, we could look at the data that would have been accessed by that batch process during those days.

Logging the query, and all the other elements required by 10.3 about that action, would generate a reasonably accurate list of records that would use a fraction of the drive space required by creating an entry that has every single record exposed.

Look for the conclusion, part 6, on Wednesday!

This post originally appeared on