The Compliance Sword

Regulatory Compliance – Two simple words that make security practitioners around the world shudder in fear and disdain. Compliance is traditionally the realm of box-checking auditors who seek to undermine the foundation of security, by turning complex architecture decisions into nothing more than a checklist.All too often, we see it as a hurdle that must be overcome, rather than a tool that can help us in our security advocacy.

First, it is important to establish what compliance isn’t. Regardless of how technically granular requirements may become (I’m looking at you, PCI-DSS and NERC-CIP), it will never be a magic bullet. Meeting the bare minimum set forth by these standards will never mean you’re “secure”. Indeed, it is even possible to do very little to secure your environment while still meeting the letter of the law.

Compliance is a system of checks and balances. It is a way to ensure you understand where controls need to be applied in your environment and that you are validating their efficacy. While the act of audit may be a simple box-checking activity, the act of achieving compliance should be seen as validation that you are meeting the minimum bar – not a seal of exemplary performance.

In information security in particular, it can be very difficult to measure success. Long ago, I heard a statement that really sums up metrics in security:

In security, we have three metrics:

1. We haven’t been compromised.

2. … yet.

3. … that we know of.

Since it’s so difficult to measure what we do, it becomes similarly difficult to justify doing more. We are a cost center with very little obvious ROI. It’s very difficult to justify the expense of a major undertaking, like properly segmenting a network or investing in application security testing capabilities. Bring along requirements from PCI-DSS and HIPAA-HITECH, though, and you suddenly have justification to make these improvements – along with repercussions for ignoring them.

Compliance should never be a substitute for “doing it right”. However, if you build a secure environment, it will, by design, be compliant. Once you understand compliance frameworks, it’s easy to see that they all say the same things in different ways. They all require adherence to and evidence of basic security controls. A well-designed secure infrastructure will produce evidence to meet any defined security requirement without impacting overhead.

Time and again, I see organizations do the annual “compliance hustle”. With binders full of discrete (and often contradictory) policies, they spend months scrambling to collect evidence to fulfill each individual audit. It requires several full time resources just to manage each scramble, plus many hours of work on the infrastructure side to fulfill the evidence requests. In the end, remediation activities are identified for controls that are already in place, because they were built for one specific purpose and only deployed to that environment. It’s a redundant and reactionary loop that is difficult to break out of.

Instead, we should focus on letting organizational objectives, such as achieving compliance with one specific regulatory body, carry the initiative of building a singular compliance framework. Through careful mapping of requirements to controls, a one-time architecture effort can easily result in a self-sustaining compliance program which can be maintained and kept updated to the latest requirements through the efforts of a single individual. By using an established organizational initiative to support the financial outlay of the effort once, ROI can be clearly established after subsequent efforts can be maintained with little to no infrastructure resources.