Compensating Controls: What You Need to Know

 

PCI DSS compliance comes with over 100 pages of requirements. However, the Appendices offer ways to think about how you can limit your risks. Limiting risk includes being able to limit your scope as well. Compensating controls help you be compliant with PCI DSS requirements when you do not have the architecture to meet a requirement.

That sounds confusing because it is. Getting started with PCI DSS compliance seems overwhelming because although it is prescriptive, meeting the specifications of the requirements is not as straightforward as it seems.

What Is the Definition of Compensating Controls?

First, the definition of compensating controls feels circular. Appendix B of the PCI FAQ document states:

Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.

Each PCI DSS requirement must be met. However, sometimes the method approved by the standard can initially burden an organization. The standard desires to create consistency in methods of information protection. Consistency is a means to an end; PCI DSS seeks to protect people’s information. If you are finding ways to protect information that meet the intent of the PCI DSS requirement while being more secure than the method in PCI DSS, then you can claim a compensating control.

That sounds really difficult, and it is. In other words, PCI DSS doesn’t intend compensating controls to be cheaper methodologies. It intends to provide an organization with an alternative for meeting the fundamental purpose of the standard. Compensating controls hold organizations that use non-requirement-approved solutions to higher standards of care.

How to Meet the Intent and Rigor of the original PCI DSS Requirement

Compensating controls are intended to fix gaps in compliance. They are not intended to be a permanent solution. This means that the first step—creating a complex overlap of controls—is going to be difficult.

For example, PCI DSS Requirement 1 is “Install and maintain a firewall configuration to protect cardholder data.” If you don’t have a firewall, then you need to get one. In the meantime, you need to have a system of controls that meets the intent and rigor of the PCI DSS requirement. PCI’s resources explain that the purpose of a firewall is to protect cardholder data from outside intruders and unauthorized internet access. While waiting to get your firewall up and running, you need to have something in place that not only protects the information, but does it as well if not better than a firewall does.

How to Provide a Similar Level of Defense as the Original PCI DSS Requirement, such that the Compensating Control Sufficiently Offsets the Risk that the Original PCI DSS Requirement was Designed to Defend Against

Does this sound a little redundant? It should. Because what PCI is telling you is: “if you don’t have the thing, you really need to have the thing. And by the way, until you get the thing? You’d better be overcompensating for not having the thing.”

A compensating control needs to protect information. Imagine going into a cabin in the woods for a week. The cabin has no door. You’re informed there are bears. How do you protect yourself from bears trying to get the food? Maybe you move a dresser in front of the doorway and hope it’s heavy enough. Simply putting a curtain in the empty doorway isn’t going to work. This is how you need to approach a compensating control. Is the risk of the bear coming into the cabin still higher with the dresser than it would be with a door? Then that compensating control fails in its compliance.

How to Be “Above and Beyond” Other PCI DSS Requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)

PCI clearly wants you to have the controls they specify. Moreover, they want to make it really really hard to have a compensating control that fulfills the requirement. If you’re going be a maverick, they want you to pay for it in time and effort.

Let’s break down three examples. First,

Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review. For example, passwords for non-console administrative access must be sent encrypted to mitigate the risk of intercepting clear-text administrative passwords. An entity cannot use other PCI DSS password requirements (intruder lockout, complex passwords, etc.) to compensate for a lack of encrypted passwords, since those other password requirements do not mitigate the risk of interception of clear-text passwords. Also, the other password controls are already PCI DSS requirements for the item under review (passwords).

PCI doesn’t want you to double dip your protection and call it a “compensating control.” They don’t want you to say, “by fulfilling this requirement over here, I have also taken care of a gap in my requirement here.” That’s kind of like being in a restaurant and taking the salt from the table next to yours. Sure, now you have salt, but there’s still a table somewhere missing a condiment. In infosec speak, this means there would still be an existing vulnerability.

Moving on to the second example PCI provides,

Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review. For example, two-factor authentication is a PCI DSS requirement for remote access. Two-factor authentication from within the internal network can also be considered as a compensating control for non-console administrative access when transmission of encrypted passwords cannot be supported. Two-factor authentication may be an acceptable compensating control if; (1) it meets the intent of the original requirement by addressing the risk of intercepting clear-text administrative passwords; and (2) it is set up properly and in a secure environment.

This one sounds almost like it contradicts the previous example. The difference, however, is that this argues that if something is stronger and required for another requirement, it can be used here. Staying with the condiment analogy, imagine those trays at restaurants that have ketchup, mustard, and hot sauce. Sometimes, they’ll have regular hot sauce as well as the extra spicy stuff. At your table, you notice that you have the extra spicy, but not the regular. The other tables have both. Since the extra spicy is stronger, this one can count as a compensating control because it doesn’t leave you vulnerable to bland food.

Two-factor authentication works the same way, so the explanation is the same. Two-factor authentication acts as a higher level of security. It keeps out intruders that you assume to be malicious. Because it is extra spicy, it can be used as a compensating control to protect against internal intruders as well because the requirements hold internal security to a lower standard.

The third example addresses how controls can be combined to be worthy compensations for something missing.

Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company is unable to render cardholder data unreadable per requirement 3.4 (for example, by encryption), a compensating control could consist of a device or combination of devices, applications, and controls that address all of the following: (1) internal network segmentation; (2) IP address or MAC address filtering; and (3) two-factor authentication from within the internal network.

Pursuing the condiment metaphor, think about the traditional Thousand Island Style special sauce. You’ve ordered a burger, but there’s no special sauce. However, the condiment tray has mayonnaise, ketchup, and relish. You decide to improvise. In the end, this turns out to taste pretty much like the special sauce you love so much.

This example of a PCI DSS compensating control is doing the same thing. Even if you can’t use encryption, you can build a series of components that addresses each of the “ingredients” the requirement tries to put into effect. By meeting the intent and creating a system of controls that effectively addresses the underlying purpose of the requirement, you have put together a compensating control.

How to Be Commensurate with the Additional Risk Imposed by not Adhering to the PCI DSS Requirement.

Everything related to compliance is risk-based. Everything. This means that if you’re coming up with your own way to meet a PCI DSS requirement, you need to assess the risk of the original asset. Then look at your compensating control, and assess the risk of your control compared to the risk of the control PCI DSS prescribed. If your attempted control leads to a greater risk than the prescribed PCI control, you probably want to re-evaluate the compensating control. Remember, example 3 says you have to be “above and beyond” the PCI requirement. If your compensating control comes with a greater risk than the PCI requirement, then you’re not going above and beyond.

The PCI DSS attempts to standardize an industry by creating a level of consistency for customers as well as businesses. In reality, the PCI DSS definition of compensating controls intends to make things more difficult. PCI wants you to follow their rules to keep things consistent. They have undertaken the process of finding the industry best practices to protect cardholder data. They really don’t want you to stand in front of them saying, “Well, I know better so I’m going to do this my way.”

To read about how scoping your PCI DSS compliance can help you better manage your compliance needs, download our ebook, PCI-DSS: Steps to Successful Scoping.