IT Security: Can We Be Compliant and Yet Insecure?

Bill Sieglein on how to go beyond regulatory checklists.

I have conducted more security program assessments than I can remember over the past 15 years. Quite some time ago I conducted some of the first certification and accreditation efforts ever at the CIA. Those were interesting times. We had very little to go on and we tried to assess security controls to the few regulations and controls that existed at that time. By the time I left the federal space and started working almost exclusively in the commercial sector a number of security best practice standards had sprung up. Most recently, in the past 10 years or so, a slew of legislation pertaining to data security and privacy has given us more requirements with which to adhere.

Over that 15 year period my attitude about using checklists to ensure the existence of security controls has shifted as well. Early on we were begging for some standards and checklists to compare against. Later on we realized that using checklists can lead to a sort of 'tunnel vision'. Now that the list of regulatory requirements that most organizations have to comply with is growing unmanageable, I am seeing folks lean back on checklists again just to ensure completeness.

I think this is a dangerous trend unless the "checklist" is all inclusive. That is—the list includes all the required controls for all of the regulations, standards and mandates. If organizations try to meet compliance one regulation at a time they tend to fall back into that tunnel vision I mentioned previously.

One issue that becomes challenging is figuring out what our true security compliance requirements are. Prior to this truckload of legislation, guidelines and standards we typically built our security programs in response to risks. We'd assess weaknesses in our environments, identify threats that were likely to exploit those weaknesses and then mitigate those risks with people, processes and technology.

Our biggest concerns were hackers and malware and spam. We sometimes used FUD to obtain budget so we could implement the best practices we knew we should, but senior management always seemed opposed to. Spending on security controls did not interest executives. It was not associated with growing the business but was seen as a cost of doing business and keeping it small was good.

When a rash of security incidents and corporate scandals rocked the business world in the a host of new laws were enacted. Aimed at ensuring the privacy and integrity of specific kinds of data, these laws attempted to specify better controls. They alluded to the need for implementing best practices and some were specific enough to name the types of controls they were seeking. In other cases they were broad in their goals and recommendations. All-in-all, the laws had many of the same goals—improve security through governance and controls.

These laws have been around now for several years. The information security industry has seen unprecedented growth as a result of efforts to comply with these laws. The information security executives' role has expanded far beyond just implementing security technologies. We are now deeply involved in ensuring our firms pass audits, avoiding negative press and keeping our executives out of jail.

For me and my colleagues these laws were a welcomed impetus because they forced our executives to wake up and begin paying attention to the importance of information security. While that new attention brought with it increased budgets and resources it has had a side effect we might not have anticipated. In their zeal to meet compliance requirements (and stay out of jail), our executives have adopted a compliance checklist mentality. "Just get through the audit" seems to be our executives' mantra.

The negative side effect of a checklist mentality is that we focus on getting boxes checked off rather than making sure we are doing the right thing. I use the analogy that there might be a requirement for a door and so we install a door. Unfortunately the door is pointless without a lock but the requirement did not ask for a lock and so we did not get one. This is what I mean when I ask, "Can we be compliant but still insecure?"

So how do we overcome this challenge? What can we do as security and compliance executives to ensure that we are ensuring compliance and managing traditional information security risk at the same time? With our budgets likely to be shrinking as the economy slows, we better make sure we are doing the most with what we have.

Here are my suggestions. I like to call this the way to make a security and compliance smoothie.

Start with ALL the Ingredients

Make sure that you know all of the things you want to include in your security and compliance requirements mixture. Remember that the ingredients are not just laws and regulations. Make sure you include your industry mandates, international standards, business partner agreements and your own internal policies. Without all of those you don't really have the complete picture.

Blend them Well

One of the problems I have seen in the past with trying to comply with all those things is that folks attempt to map each control in their environment to each requirement. This ends up looking like the cat's cradle thing we used to do with yarn on our fingers in elementary school. That's not the solution and it sure is not useable or scalable. The better solution is to remove the redundancy by combining like requirements and adding specificity where there is ambiguity. This should result in a new, smaller list of all the things you have to comply with.

Measure to Your New List

Now that you have this new list of requirements that has all the redundancy removed and the ambiguity cleared up you have a baseline from which to measure your existing controls. Conduct your gap analysis against this new target list of requirements.

Identify Deficiencies

As with any audit or assessment, the gap analysis against your target list of requirements will likely yield some places where your controls are deficient. Make a list of those deficiencies, and that list becomes your action list for remediation. If you are smart, you will assign resources and costs to those action items to help you budget.

Track Progress

Use that list of deficiencies to track progress on closing the gaps and report the progress so you can show how much more compliant you are than when you started and to show the return on investment for those projects.

That all sounds a little complicated, but believe me when I tell you it's easier than the way we've all been doing it with multi-layered spreadsheets and counting on our fingers and toes. There are some solutions out there that automate this process. Make sure you select one that creates your own unique compliance target and does not force you to adapt to a single, best practice or standard because one size does not fit all.

So, can we be compliant and yet insecure? Yes we can, especially if we try to link each control with a single regulatory requirement, one at a time. We may be able to achieve compliance with a single regulation that way, but we may be leaving the back door wide open.

Bill Sieglein is founder and executive director of the CSO Breakfast Club. His background includes work in the US intelligence community and a stint as CSO of the Public Company Accounting Oversight Board (PCAOB).

Copyright © 2008 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)