Opinion

IT Security: Can We Be Compliant and Yet Insecure?

Bill Sieglein on how to go beyond regulatory checklists.

By Bill Sieglein

September 22, 2008 — CSO — 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.