Let's face it compliance is a good thing. For what ever reason, people left to their own devices will make risky decisions, to lower cost, reduce effort, return a higher profit, or simply make a quick buck. It seems that people will often take the path of least resistance unless they fear it will cause themselves personal pain in the process. Rules are needed to compel people to do what is right or reasonable. A lack of regulation incubates an environment for abuse. If the state of the current economy does not fully illustrate this point then nothing will.
In the information security realm, compliance does have its downside. We end up with people trying to simply check a box by any means necessary. More often than not, the compliance attitude again reflects human nature to reduce cost and personal effort. The detractors for security regulations and compliance activities are quick to point to the mountains of paperwork and systems that abound with weak security as a contrary argument. But, the reality is that once again people will choose a path of least resistance. It's easier for management to "accept risk" than build security into the system or devote resources to a security program. Many pundits call for "real security", but it is amazing that they typically offer no solid solutions. In fact, it is not clear what this "real security" constitutes.
Maybe our way forward can be found through security metrics. We need a method that allows a comparison from one system to another by way of a common baseline. The goal of metrics is to provide a means to quantify the security of a system. The quantification should only include those aspects of the system which can be measured. Beginning with a common baseline, such as NIST 800-53, we can establish a mathematical approach to measure the implementation of each security control within a system. The following is proposed as one method to achieve this capability:
Frequency: Establish the number of periods within a cycle of how often the control is implemented, measured, and/or evaluated. For example a control might be measured once a week over a period of a year.
Instances: A control can be implemented in many different areas within a system. This measure is the total number of all instances where the control should exist within a system.
Confirmations: Performance is measured by counting the number of times the control was confirmed to be implemented on a per instance basis within the system.
Deviations: Non-compliance items deviate from the baseline and are used to reduce our performance measure.
With these measurable attributes we can affirm:
"Real Security" = (Confirmations - Deviations) / (Frequency * Instances)