In the early years of the PCI DSS, and even one author's experience under the CISP program, the term compensating control was used to describe everything from a legitimate work-around for a security challenge to a shortcut to compliance. If you are considering a compensating control, you must perform a risk analysis and have a legitimate technological or documented business constraint before you even go to the next step. Companies being assessed will present more documented business constraints for review based on the current economic situation. Just remember the word legitimate and the phrase perform a risk analysis before proceeding to the next step. “Bob” being on vacation is not a legitimate constraint, and an armchair review of the gap and potential control is not a risk analysis. QSAs should ask for documentation during a compliance review, and having it ready to go will make sure that you are efficiently using their time. If they do not, you can bet that your assessment is not thorough.

If you think that compensating controls are easy, please read the note below.

An example of a valid control might be using extra logs for the su command in UNIX to track actions executed under a shared root password. In rare cases, a system may not be able to use something like sudo to prevent shared administrator passwords from being used. Keep in mind, this is not a license to use shared passwords everywhere in your environment. Nearly every system has the ability to use something like sudo, or “Run As” which is free or built into your OS, or a commercial variant if your platform requires this.

As stated earlier in this section, before immediately running down the compensating control route, be sure that you have done your research and make sure that you legitimately meet all of the requirements for a compensating control. Five years ago, compensating controls were relied on because most platforms did not have readily available solutions to certain components of the PCI DSS. That's not true today. As a rule of thumb, if the operating system can meet the patching requirements in 6.1, it will probably have everything you need available for it (possibly in later versions) to comply with PCI DSS.

Compensating controls are not specifically defined inside PCI but are instead defined by you (as a self certifying merchant) or your QSA. That's where the trouble starts!

Thankfully, the PCI Council provides an example of a completed compensating control in Appendix C of the PCI DSS, as well as a blank template to fill out. Appendix B provides all the guidance they feel necessary to design a compensating control.

As long as you have met the requirements in Appendix B for a compensating control, you should be able to build that control into your environment and satisfy PCI DSS. Compensating controls are ultimately accepted by acquirers or the card brands themselves (if applicable), so even after putting all of this information together you could face the rejection of your control and a significant amount of expense re-architecting your process to fit the original control. This is where an experienced QSA can really help you to ensure that your control passes the “Sniff Test.” If it smells like a valid control, it probably will pass. If you need examples, look later in this chapter under the section titled “Funny Controls You Didn't Design.”

Compensating controls are not a shortcut to compliance. In reality, most compensating controls are actually harder to do and cost more money in the longrun than actually fixing or addressing the original issue or vulnerability.

Imagine walking into a meeting with a customer who has an open, flat network, with no encryption anywhere to be found (including on their wireless network, which is not segmented either). Keep in mind, network segmentation is not required by PCI, but it does make compliance easier. Usually in this situation, assessors may find a legacy system that cannot be patched or upgraded, but now becomes in-scope. Then the conversation about compensating controls starts. Now imagine someone in internal assessing telling you not to worry because they would just get some compensating controls. Finally, imagine they tell you this in the same voice and tone as if they were going down to the local drug store to pick up a case of compensating controls on aisle five.

Compensating controls were never meant to be a permanent solution for a compliance gap. Encryption requirements on large systems were made unreasonable early in this decade. Not only was there limited availability of commercial off-the-shelf software, but also it was prohibitively expensive to implement. For Requirement 3.4 (Render PAN, at minimum, unreadable anywhere it is stored), card brands (largely Visa at the time) were quick to point out that compensating controls could be implemented for this requirement, one of those being strong access controls on large systems.

For mainframes, assessors would typically do a cursory walk through the controls and continue to recommend an encryption solution at some point for those systems. At one point, compensating controls were deemed to have a lifespan, meaning that the lack of encryption on a mainframe would only be accepted for a certain period of time. After that, companies would need to put encryption strategies in place.

Compensating control life spans are never materialized. Compensating controls can be used for nearly every single requirement in the DSS – the most notable exception being permissible storage of sensitive authentication data after authorization. There are many requirements that commonly show up on compensating control worksheets, Requirement 3.4 being one of them.

Even with no defined life span, compensating controls are not an eternal free pass. Part of the process during every annual assessment is to review all compensating controls to ensure that they meet the four requirements as currently defined by the PCI Security Standards Council, remembering that the requirements can change between versions of the standard, the original business or technological constraint still exists, and it proves to be effective in the current security threat landscape. If certain types of attacks are on the rise and a certain compensating control is not effective in resisting those attacks, it may not be considered OK on your next assessment.

To further cloud the situation, it is up to the QSA performing the assessment to decide to accept the control initially, but the acquiring bank (for merchants) has the final say. Substantial documentation and an open channel of communication to your acquirer is essential to ensure money is not wasted putting together controls that ultimately do not pass muster.

Don't get discouraged, though! Compensating controls are still a viable path to compliance even considering the above caveats and descriptions of why you may not want to use them.

The authors would not be true security professionals if there were not a fun story or two based on experiences coaching companies or individuals to better security. No names will be used, and the details will be altered to protect those who were most likely being forced to try the old “Push Back on the Assessor” routine. We hope you enjoy reading them as much as we enjoyed listening to them.

Some of the most cherished stories and experiences come from customers and vendors that had the right intentions, but never seemed to follow the basic doctrines listed above on how good compensating controls are made. By the way, if you read this and think, “Hey! He is talking about ME!?”, I'm not. Pinky swear.

Before one of the authors was heavily involved in PCI, he or she did some IT assessing for a bank that was owned by his or her employer. He or she knew the drill of responding to assessor findings. They usually start with a meeting, bringing all the key stakeholders together to mull over a spreadsheet listing all the findings. Findings are separated out in the “To Fix” pile, and the “To Push Back” pile, each item being assigned to an expert to push back on the assessors. “We don't need that control because of a control over here,” or “This gap does not apply to our environment,” are the common phrases heard in these meetings. Eventually, a happy (potentially unhappy) medium is established, and the assessment is closed out.

The same process is often applied to PCI, and the compensating control “Cha Cha” commences.

Before we poke fun at the following examples, please understand that we are only illustrating a point. At no time were these suggestions made by people who didn't understand both the requirement and the capabilities of the technology in question. These people were professionals; and based on their credentials and experience, they should have known better.

Encryption has always been a hotly debated topic. Our favorite failed compensating control for Requirement 3.4 comes from a vendor that called an author late one afternoon. They brought in their product team and tried to convince him that RAID-5 was essentially an equivalent to encryption. Their argument stated you could not take any one drive and reconstruct useful data that could be considered compromise worthy; thus, their product should be considered valid to sell to companies as encryption.

If one drive (probably damaged) falls off of a truck during transport, the technology does prevent someone from reconstructing all the data that was on that system. If the system was large enough, chances are that the data on the drive may not provide any use to nefarious individuals either. But that's not really the goal of the requirement, is it? Physical theft prevention is covered in other areas of the standard. The point of the requirement is to render the data unreadable anywhere that it is stored. RAID may render the data unreadable on one physical drive, but it does not render it unreadable in any other circumstance. A simple compromise of one area of the system could lead to the access and theft of massive amounts of unencrypted data.

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, the vendor was 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.

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 (approximately) 53 bits of encryption, thus making it computationally feasible to brute force that key, meaning 50 computers could do it in less than 1 year.

We've spent quite a bit of time setting up this section. We talked about what compensating controls are, what they are not, and some of the best misguided attempts to create them. Before we discuss the examples, please remember that these examples should be used for illustrative purposes only. We 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. See Fig. 12.1 for a simplistic view of the network.

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 to manage the volume of calls that will come in for things like password maintenance.

What do you do? Do you crush the retailer 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, then 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 virtual local area network (VLAN) aware switch at the location that can have access lists (ACLs) tied to it. Why not create a new VLAN for just the point of sale (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. See Fig. 12.2 for an example of what that might look like.

“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.

The first solution aforementioned 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.

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 whoever 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.