See part 1 here, part 2 here.

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)1. Now imagine someone in internal audit 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. I don’t have to make this stuff up, I get paid to listen to it!

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 Council2, 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 list of reasons why you may not want to use them.

I would not be a true security professional if I didn’t have a fun story or two based on my experiences coaching companies or individuals to better security. No names will be used, and I’m going to change enough details to protect those who were most likely being forced to try the old “Push Back on the Auditor” routine. I hope you enjoy reading them as much as I enjoyed listening to them.

Look for Part 4 on Wednesday!

This post originally appeared on BrandenWilliams.com.

  1. While it is not a requirement to segment your network, it does make compliance easier. Usually in this situation, I find a legacy system that cannot be patched or upgraded, but now becomes in scope. Then the conversation about compensating controls starts. []
  2. Remember, the requirements can change between versions of the standard. []