Rescued from a compliance nightmare

UkobackIf your business wants to accept credit cards, you must demonstrate compliance with the PCI DSS standard. It’s been said Dante reserved a special place in Hell for those who create compliance rules. Rules designed with such devious complexity they ensnare all who pass, and PCI DSS is just such a set of rules.  Queue up ominous background music, mustache twisting and evil laughter.

The truth is someone on the PCI DSS standards committee had pity on those who seek compliance and designed a life preserver called “Compensating Controls”.  Of course the rest of the soulless harpies forced the life preserver to the back of the compliance document and buried it in Append B.

We all know businesses are all about getting things done. And they want to do them as simply and efficiently as possible.  In the case of selling, they want to let customers pay anyway they want with as few barriers as possible.  So while security matters, simple and efficient sales matters equally. Compensating Controls offers a common sense work-around to compliance, when there are legitimate reasons why a business can’t comply otherwise.

Sounds good right? Ok, let’s not get too far ahead of ourselves, there are rules (palm plant on forehead – “of course there are rules”).  For a business to consider Compensating Controls, there are four requirements. The control must:

  • Meet the intent and rigor of the original requirement
  • Provide a similar level of defense as the original requirement
  • Be “above and beyond” other requirements
  • Be commensurate with the additional risk imposed by not adhering to the PCI DCC requirement

Example use of Compensating Controls

Let’s look at a simple example. Say we have a small non-profit running a membership database with credit card processing. Furthermore the membership database is installed on a server and because the organization is small, they have only this single server which they also use for email.

This configuration would violate PCI DSS Requirement 2.2.1:

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server.

The objective of control 2.2.1 is to prevent services being able to elevate themselves to exploit the security context of an adjacent service on the same server.  In our example, our objective is to protect and isolate the credit card data in the Membership Database from the Email services. The organization needs to ensure that a successful exploit of the email server does not give an attacker access to credit card data.

One possible example of a Compensating Control to be used in place of 2.2.1 could be:

  • All credit card data in the Membership Database is encrypted
  • The server running the membership database sits behind a firewall, and is only accessible by employees of the non-profit from within the office.
  • Access to the Membership Database requires unique credentials AND these credentials are different than those used to access email (user’s should not be allowed to re-use their email credentials). This separation of credentials can be used to enforce system access controls (ACLs) to restrict access to membership data from email.
  • Access to the Membership Database requires multi-factor authentication when logging in with the use of smartcard issued to each employee by the organization.

 

The PCI DSS Standard provides a Compensating Controls Worksheet in Appendix C. We’ll complete this as example of how to document the above mention Compensation Controls

 

Some have pointed out that Compensating Controls may not be cheaper or even easier than just implementing the PCI DSS requirement. In the long run, a business may find it easier to just comply and should only consider this path if there’s a good reason why they can’t just comply. But in those cases where there is a legitimate technical or documented business constraint, Compensating Controls can be a life saver.