PCI DSS Compensating Controls — Rescued from a compliance nightmare
If 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.
| Information Required | Explanation | |
|---|---|---|
| 1. Constraints | List constraints precluding compliance with the original requirement. | Organization XYZ employs a custom membership database used to store and process credit cards. The application is run from the organization’s only server. The organization is a small non-profit and also uses the server for email. The constraint is limited financial resources and limited space for additional servers. |
| 2. Objective | Define the objective of the original control; identify the objective met by the compensating control. | The objective of the 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. |
| 3. Identified Risk | Identify any additional risk posed by the lack of the original control. | Additional risk is introduced of unauthorized access to credit card data from any successful compromise of adjacent email services on the same server. |
| 4. Definition of Compensating Controls | Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any. |
|
| 5. Validating of Compensating Controls | Define how the compensating controls were validated and tested. | The organization provides architectural documentation that details the specifics of the server configuration. |
| 6. Maintenance | Define process and controls in place to maintain compensating controls. | The organization regularly reviews the list of accounts and employee mappings for both the membership database and email systems to confirm the separation of user credentials. |
PCI DSS compensating 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.