This guide to compensating controls is excerpted from chapter 12 of PCI Compliance by Dr. Anton Chuvakin and Branden Williams (Syngress, 2009). For a full sample chapter, see http://www.pcicompliancebook.info/
Information in this chapter:
- What is a Compensating Control?
- Where are Compensating Controls in PCI DSS?
- What a Compensating Control Is Not
- Funny Controls You Didn't Design
- How to Create a Good Compensating Control
Few payment security professionals can find a hotter PCI DSS topic than compensating controls. They always look like this mythical accelerator to compliance used to push PCI Compliance initiatives through completion at a minimal cost to your company with little or no effort.
Compensating controls are challenging. They often require a risk-based approach that can vary greatly from one Qualified Security Assessor (QSA) to another. There is no guarantee a compensating control that works today will work one year from now, and the evolution of the standard itself could render a previous control invalid.
The goal of this chapter is to paint a compensating control mural. After reading this chapter, you should know how to create a compensating control, what situations may or may not be appropriate for compensating controls, and what land mines you must avoid as you lean on these controls to achieve compliance with the Payment Card Industry Data Security Standard (PCI DSS).
What is a Compensating Control?
In the early years of the Payment Card Industry Data Security Standard (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. Qualified Security Assessors (QSAs) should ask for documentation during a compliance review, and having it ready to go will make sure you are efficiently using their time. If they do not, you can bet that your assessment is not thorough.
Every compensating control must meet four criteria before it can be considered for validity. The four items that every compensating control must do are: meet the intent and rigor of the original PCI DSS requirement, provide a similar level of defense as the original PCI DSS requirement, be "above and beyond" other PCI DSS requirements, and be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement. If you think compensating controls are easy, please re-read the above statement.
The compensating control polygon has four specific points that must be met. For a compensating control to be valid, it must:
1. Meet the intent and rigor of the original PCI DSS requirement;
2. Provide a similar level of defense as the original PCI DSS requirement;
3. Be "above and beyond" other PCI DSS requirements (not simply in compliance with other PCI DSS requirements); and
4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
For an example of a completed compensating control, review Appendix C of the PCI Security Assessment Procedures.
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 likely have everything you need available for it (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 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 in order to design a compensating control.
Pay close attention to sub-bullets A-C under list item 3. In our experience, this is where most companies go wrong.
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 ensure 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."
What a Compensating Control Is Not
Compensating controls are not a short cut 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 that 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 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 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.
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! He is talking about ME!?", I'm not. Pinky swear.
Before one of the authors was heavily involved in PCI, he did some IT assessing for a bank that was owned by his employer. He 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 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 from the early "Just Do It" message that was pounded into our heads, to the cooler-headed "Slow down, it's a mainframe" axiom that companies live by today. 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.