PCI and the Art of the Compensating Control

Compensating controls are a standard part of any security posture. But what makes an effective compensating control?

1 2 Page 2
Page 2 of 2

Speaking of encryption, disk only encryption inside data centers is not very useful either, unless additional user credentials are tied to the decryption process. Another favorite was a vendor that offered PCI compliance through an encryption appliance that was completely transparent to the operating system. So basically, you were only protecting the data as it sat on disk, in a secured facility, with gates, cameras, and Buck, the not-so-friendly security guard that looks like a hiring manager gave a night shift and a Taser to the ex-bouncer of a dance club. If applications sat on disk drives housed in the unlocked part of a post office, then anyone could see the value here. Until then, the solution only focuses on the physical media and nothing else.

Encryption is really not the big problem with Requirement 3, key management is. Once companies figure out that encryption technologies are available for their platforms, they realize that key generation and management is a whole different problem.


One vendor, who apparently thought a severe case of weekend-itis had firmly set in, made a case for using the COBOL Random Number Generator (RNG) to spit out sixteen digits (technically 128 bits of data) for use as an encryption key. People can come up with some really creative ideas when the fear of failing an assessment looms.

Yes, they were trying to be random and they will end up with a 128-bit key. Anyone with a basic knowledge of encryption will quickly find the problem with that approach. Not that COBOL's RNG is less than R, but that you have eliminated a giant section of possible key space! A 128-bit key generated in that manner is the equivalent of (approx.) 53 bits of encryption, thus making it computationally feasible to brute force that key, meaning 50 computers could do it in less than one year.

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 this 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 brings an article about PCI to an interview 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 QSAs will define and implement 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? That is one option. 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 (Virtual Local Area Network) 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.

"But my store networks are different in every store," you say. "I can't just slap something in there like that and expect it to work globally!" If this is the case, is your store support group is overloaded with break-fix calls? Maybe this could be an opportunity to shore this up and make each store based on a consistent footprint?

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.

Also on CSOonline: Separation of Duties and IT Security

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.


Without fail, companies that push major changes to large environments often face some kind of error upon the final rollout. Keep in mind, large environments always vary just a little bit among locations. Be sure to have a solid contingency and rollback plan.

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

A Service Provider has a large mid-tier UNIX, like Solaris or AIX, 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 presenting 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 Capital Expenditure (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.


What a pretty mural we have painted over the last several pages! Good compensating controls are the result of a marriage between art and science. We've discussed what compensating controls are, what they are not, some funny examples of how to go wrong, and three solid scenarios from which we created good controls.

Compensating controls are not the golden parachute of compliance initiatives. They require work to build effective ones that will pass the scrutiny of both a QSA and an Acquiring Bank (or card brand). Rarely do they yield lower cost and effort than simply meeting the original requirement. PCI DSS is based on many good (not best) standards of practice for security, and should be viewed as a baseline by which to operate, not a high water mark by which you aspire to be one day. Compensating controls may help you lower the bar of compliance in the short term, but remember, only you can prevent a security breach.


Copyright © 2010 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
The 10 most powerful cybersecurity companies