What is a Compensating Control?

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 business challenge to a shortcut to compliance. If you are considering a compensating control, you must perform a risk analysis on the scenario by which the control would be implemented and have a legitimate technological or documented business constraint before you even go to the next step. The current global economic crisis fuels these discussions as new companies struggle with complying with the standard in an environment where cash is king (i.e. he who has the cash is the king). The best tip we can give you is to 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 a ten-minute discussion of the gap and potential control is not a risk analysis. Your QSA should ask for the documentation from your thorough examination of the issue during a compliance review, and having it ready to go will make sure that you are efficiently using their (and your) time. If they do not, you can bet that your assessment isn’t thorough, accurate, or really worth the paper the attestation came on.

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 back to an individual administrator. 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 broad license to use shared passwords everywhere in your environment. Nearly every system has the ability to use something like sudo, or “Run As” either as a free add-on or as something built into your operating system. In rare cases, you may need to purchase a commercial tool for your platform; but at this point in our information technology history, that should raise red flags about the platforms ability to meet other requirements that are core to PCI DSS. In those instances, you should look for alternative platforms to support your PCI environment as you will most likely have other PCI DSS challenges.

As stated earlier in this section, before immediately running down the compensating control route you should be sure that you have done your research and make sure that you legitimately meet all of the requirements for a compensating control. Seven to 10 years ago, companies relied on compensating controls because most platforms did not have readily available solutions to certain components of the PCI DSS. Today’s security environment is tremendously different. 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 (possibly in later versions) to comply with PCI DSS.

Where are Compensating Controls in 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 at the end of Appendix C of the PCI DSS Security Assessment Procedures, 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 (start with your acquirer), 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” and in the case studies.

What a Compensating Control is Not

Compensating controls are not a shortcut to compliance. In reality, most compensating controls are actually harder to do and cost more money in the long run 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 simply because there is no segmentation in the network. This usually triggers the conversation about compensating controls. Now imagine someone in Internal Audit telling you not to worry about this massive problem with PCI DSS compliance because they would just “go 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.

In their original incarnation, 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 (or you could argue that these same encryption requirements forced innovation and progress on large systems). 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.

In the old days, assessors would typically do a cursory walk through of the mainframe’s 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 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 (Requirement 3.2). 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 and shouldn’t be viewed or sold to executive management that way. Part of the annual assessment process 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 must still exist, and the control 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 acceptable during 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. If you are a service provider, you won’t have that same authoritarian beyond your QSA. This is why selecting a great QSA that understands the underlying technology he is assessing is critically important.

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.

Funny Controls You Didn’t Design

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!! They are talking about ME!,” we’re not. Pinky swear.

Before one of the authors was heavily involved in PCI, he did some IT auditing for a bank that was owned by his employer. He knew the drill of responding to audit findings. They usually start with a meeting, bringing all the key stakeholders together to mull over a comprehensive spreadsheet detailing all of the deficiencies. Findings are separated out in the “To Fix” pile, and the “To Push Back” pile, each individual item being assigned to an expert to either fix the issue or push back on the auditors. “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 uttered in these meetings. Eventually, a happy (potentially unhappy) medium is established, and the audit or assessment is closed out.

The same process is often applied to PCI DSS, and the compensating control dance that 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. He brought in their product team and tried to convince the author 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 RAID cards should be considered valid to sell to companies as an encryption mechanism.

To their point, if one drive (probably damaged) falls off of a truck during transport, the technology does prevent someone from reconstructing all of the data from that system. If the system was large enough, chances are that the data on the drive may not provide any tangible 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 parts of the data unreadable (or un-reconstructable) 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 a disk, in a secured facility, with gates, cameras, and Buck, the not-so-friendly security guard that embodies an ex-bouncer of a dance club—but now with a Taser^®. If cardholder data sat on disk drives installed in the unlocked part of a post office, then any reasonable technologist would see the value of encrypted data while physically on disk. But since we have physically hardened data centers, the solution doesn’t really do anything other than line a sales person’s pocket.

Contrast this concept with whole disk encryption for a laptop. Laptops are frequently lost or stolen, and whole disk encryption (depending on configuration, of course) would absolutely serve the needs of keeping data secure when its physical container is not.

But even after all these fun stories about encryption, it’s 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 that may require additional hardware and software to fully enable.

Now, the vendor in the note did actually have some good intentions. Yes, they were trying to be random and they will end up with a 128-bit key. However, anyone with a basic knowledge of encryption will quickly find the problem with that approach. The problem isn’t that COBOL’s RNG is less than random, but instead you have eliminated a giant section of possible key space! A 128-bit key generated in the manner described above is the equivalent of (approximately) 53 bits of encryption, thus making it computationally feasible to brute force that key. With a basic calculation of today’s computing power (not including some increasingly popular GPU parallel processing), a collection of 50 computers could brute force that key in less than one year. Add to that with leased computer time from a large botnet, and you could be looking at weeks or even days.

How to Create a Good Compensating Control

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 these good examples, please remember they 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. As one author recalls being a former assessor, he hated someone bringing an article about PCI to an interview during an assessment to bully his way through to compliance, so please don’t do that with this chapter. Now let’s walk through a couple of examples of how to create a good compensating control.

Let’s start with a common compensating control that QSAs will define and implement at a customer. A Level 1, brick and mortar retailer with 2500 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 Figure 14.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 resets.

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 Figure 14.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 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 for security and compliance. The second example above 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, probably 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 or ACF2, and managing those controls is now a massive chore for the employees charged with it. Additional effort aside, 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. Some security professionals inside companies love the idea of converting to MAC as it allows them to have more granular control over their systems and 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.

Case Studies

Now that we have explored examples of what some humorous (yet invalid) compensating controls look like and what acceptable ones might be, let’s walk through a couple of case studies to help us further illustrate the process.

Summary

What a pretty mural we have painted throughout this chapter! 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, three solid scenarios from which we created good controls, and two case studies that illustrate the discovery process.

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 reflect a lower total cost and compliance effort to the organization 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 to which you aspire. Compensating controls may help you lower the bar of compliance in the short term, but remember, only you can prevent a security breach.