Security compliance: The root of insanity

Security professionals are increasingly drawn into compliance - a phenomenon that can be a blessing and a curse.


There is an ever-increasing pressure for security executives to be a champion of compliance within their respective organisations. Given that there seem to be new or changing compliance requirements emerging on a fairly regular basis, this can be viewed as both a blessing and a curse.

As our government acquires increasing financial interests in some private business sectors, this trend may continue to escalate.

The blessing is that in some instances it gives the security function some additional leverage to drive results and deliver greater overall value. The curse is that the regulatory compliance requirements just add to the already voluminous amount of reactionary items that already exist on the security executive's plate.

The security function is an area of responsibility that already has far too many variables that cause reactionary behavior if permitted. In some organisations this additional set of variables can be the straw that breaks the camel's back.

One of the goals of any sound information security program should be to move from a reactionary posture to a more proactive one with the institution of appropriate programs, process, procedures and controls in place. These are the building blocks of the security function and should be in place to allow the individuals responsible for the various aspects of the security function to be proactive where it is possible to do so, such as consistent processes to move forward with the latest security updates sooner rather than later. Such action is not only proactive, but reduces reactionary behavior in the future.

This is not to imply that a security program can completely reduce the need for being reactive in some instances. By reducing the areas where this reactionary capability is needed, the response to those specific areas can be more efficient and effective, allowing resources to be used for more proactive and strategic pursuits. This equates to less overall impact and a higher overall value contribution to the organization as a whole.

In order to move away from this reactionary mentality it is necessary and helpful to take a step or two back and think about how the end game of your security program needs to look.

A basis for a successful security program typically begins with one of the standard frameworks that are available, such as ISO27002 or COBIT. Some of these frameworks are more complete than others but in general these standard frameworks are not enough by themselves. Currently none of the existing regulatory or industry requirements and standards take into account the entire spectrum of controls that are needed to ensure the overall security of the enterprise.

For example, the ISO27002 specification has a section for "Business Continuity Management." While PCI provides some very prescriptive guidance around areas such as wireless, firewall placement, the use of two-factor authentication, which ISO27002 does not, it does not mention in any great detail disaster recovery and or business continuity.

"Recommended For You"

Open letter to Barack Obama: Securing critical infrastructure - the first 90 days ISACA releases business IT governance framework