Security Manager's Journal: Getting the best from an audit

Computerworld - An independent information security audit can be nerve-wracking, but this time, I actually enjoyed it. I guess it's just a matter of perspective.

It might help that I've been an auditor myself, and so I knew what the auditor was looking for and what he would put into his report. But that isn't the whole story.

A bigger factor was that this time around, I was prepared. And I've come to see the audit not as a reproach to my work but as a quantitative affirmation of all the things I've been saying we need to do to keep our data safe.

Of course, even quantitative results can be misleading, misguided or misconstrued, depending on the expertise of the auditor. And quite often, what most people will look at is the executive summary.

In our case, that was a few pages, backed up by a 700-page technical report. Guess which one of those the higher-ups in state government are going to look at?

The problem is that this executive summary, like most of them, is filled with charts and graphs that grossly overstate our security problems. Not that we don't have problems. We do, and I'm glad to have them out in the open.

In our report, what those charts and graphs showed were the number of high-, medium- and low-risk vulnerabilities and their levels of exploitability. The sheer volume of potential problems could overwhelm the uninitiated.

I need to formulate a response to this, so that as this audit report goes up through the chain of command, those who read only the executive summary will have my comments to refer to. This will be a tough document to craft, because my purpose is to show how the executive summary exaggerates and distorts the actual situation, but I don't want to sound defensive or oblivious to what are real shortcomings.

MEGO Galore

As for that 700-page technical report, even I could only scan it before I came down with a serious case of MEGO (my eyes glaze over). What I got out of it was that all of the high-risk vulnerabilities are related to our application development environment. And many of these high-risk vulnerabilities would require very little skill to cause serious harm.

This wasn't a big shock. I knew that application development was a problem. But the report was an opportunity to do something about it. The basic weakness is that developers and programmers often have unpatched systems or have configured their systems so that the application they are working on will work the way they want it to. They give no thought to security matters, as you might well expect.

My idea was to ask the auditor to help me develop documentation and processes for the agency that would ensure a formalized system-development life cycle. The new process addresses the security concerns raised by the report. As a result, we now have a suitable framework with which we can begin doing things differently. At the same time, we moved the application development team to a separate network segment, off of the production network. That should make it less alarming if the application development systems aren't completely up to date.

There is more work to do in the aftermath of this audit, but we've made big progress. Best of all, the positive outcome is something I wouldn't have thought of without the audit.

So, here's a bit of advice: If you are a security manager, welcome your next audit with open arms. The burdens of playing bad cop all the time and being ignored will be off your shoulders. Let the audit speak for itself in all its quantitative glory.

This week's journal is written by a real security manager, "C.J. Kelly," whose name and employer have been disguised for obvious reasons. Contact her at mscjkelly@yahoo.com.

Join In
To join the discussion about security, go to computerworld.com/blogs/security.

Read more about Security in Computerworld's Security Topic Center.