Managing Audit Thrash

Ages ago, a computer science professor of mine spent several weeks of an operating systems design course talking about virtual memory management and paging strategies. One of the goals of a good paging strategy was to avoid "thrashing"... the undesirable state in which the kernel spends more time swapping pages in and out of physical memory than it spends doing real work.

This "thrash" seems like a pretty good way to describe much of what I see IT shops going through with their various compliance initiatives. PCI. SOX. HIPAA. All of the time they spend responding to security audits leaves them with precious little time to get any real work done. Audit Thrash.

Now don't get me wrong... security audits aren't fundamentally bad. In fact, when done right I've seen them add a lot of value. It's just that we need a strategy for managing the workload they create so we can get back to getting some real work done.

Perhaps the most important first step is to start auditing against your own consolidated controls framework. This controls framework should be the central repository for everything you do for security. It should cover every regulation you're subject to, your organization's security policy, and the controls that your customers and partners require you to implement.

Similar controls should be cross-referenced and consolidated into a single control. The main objective in designing your controls framework is to eliminate as much redundancy and overlap as possible without losing any controls information. The value is in the consolidation and cross-referencing, not in the raw number of controls created.

Every security audit from this point forward should be conducted against that framework, and the results should be documented in a way that makes it easy to cross-reference them to your framework. Subsequent audits will be able to leverage that information, resulting in a lot less net-new audit work each time around.