Compliance as Security: The Root of Insanity

There is an ever-increasing pressure for security executives to be a champion of compliance within their respective organizations. 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 organizations 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.

In fact from one point of view to have a viable disaster recovery program can be viewed as a disadvantage from a PCI perspective. Having backup data with card holder information increases the overall scope of organizations PCI compliance unless that card holder data is rendered unreadable. At least one breach of an organization that had achieved PCI compliance was due to having certain repositories of backup data not included within the scope of the card holder data environment.

Sarbanes-Oxley Section 404 mentions very little in the areas of wireless or firewalls, but at least makes the implication around disaster recovery and business continuance capabilities by specifying some high level requirements for “Data Management.” Overall, Sarbanes-Oxley Section 404 is not very prescriptive in regard to what to do or how to do it.

One thing that nearly all of the standard frameworks and the most prevalent regulatory requirements have in common is the requirement to have a security policy in place. The downside is that there is very little synergy between these frameworks and regulations regarding the content of those policies.

Approaching this from the direction of building specific solutions or groups of solutions to answer each compliance requirement will ultimatley lead to an overall security posture that is lacking basic elements and is inherently insecure. Such an approach may create a security function that is more reactionary than it was prior to having the regulatory compliance variable factored into the mix. This leads us to the undeniable realization that while a byproduct of security is compliance, the reverse couldn’t be further from the truth. Given that realization, hopefully we can all be somewhat in agreement that compliance is a poor excuse for security!

Unfortunately, there are many organizations’ that have only realized this after a breach has occurred. Recently an individual from Heartland payment systems was quoted as stating that “While PCI is a great beginning. It is not in and of itself enough to make you secure.”

This is a positive sign that the mainstream is becoming aware of this phenomenon that compliance does not equal security.

To achieve a comprehensive security program that allows the security function to move toward and maintain status as a strategic function it must do the following with regard to compliance:

• Develop a long term plan or “road map” for information security within your organization and include provisions for the known compliance requirements;
• Work closely with your senior business executives as you create this “road map”, so that they can understand where you are going, how it will affect their part of the operation, and it will give those business leaders an opportunity to provide you with better information to build it right the first time;
• Share the vision of your “road map” with your entire security organization and empower them as evangelists of that vision;
• To the extent that your are able, plan for potential future compliance requirements in your road map;
• Think of these potential new requirements as you build the various security capabilities within your organization. Try to build in the ability to adapt to new or more stringent compliance requirements without major upheavals to current processes, procedures and controls in place;

Once the ‘road map” is institutionalized and you are progressing toward the defined end game the security team will become less reactionary and more proactive. Once this state is achieved and is sustainable, your security program will be providing demonstrable value to its enterprise and can truly be a strategic partner to the business.

Hopefully over time more and more organizations will come to the realization that regulatory compliance is a beginning and not an end to the ongoing process of securing the enterprise.

Jason Stradley is a senior security consultant for BT providing executive-level strategic security and business consulting to Fortune 500 clients. Reach him at jason.stradley@bt.com or by phone at (630) 525-1834.