Hello "Led", This is the conundrum we all struggle with so I'm certain you will get a lot of responses - if not sympathy.
I suppose a person could reflect back on the axioms of goal setting. Specifically, that a goal must have underlying objectives and the objectives must be 'measurable'. So a goal might be to have a good security program and a supporting objective might be to reduce the number of incidents. Well, 'incidents' can fall into two broad categories: 1)those that can be prevented in your environment and 2)those that can't. For a measure of 'success', you'll want to focus on showing how you were able to reduce the number of incidents that fall into category #1. If you take Nimda as an example, we know how to prevent it. So a measure of success would be to calculate how many of the systems you were allowed to protect fell victim to Nimda. The number you want, of course, is zero. If it's not zero, then there's area for improvement in the strategy. Now, what about all of those systems you weren't empowered to protect? Maybe there isn't a patch yet available, maybe it's a new virus or maybe management told you 'thanks for the advice, but we'll accept the risk.' You should make the same calculation, but not as a measure of failure or success. Rather, as a means to persuade management to alter their 'time is money' stance. As the number of incidents in category #2 increases, you'll be able to use that as logic to convince management to expand your ability to move incidents into the realm of 'those that can be prevented'. Even if there isn't yet a patch or virus protection available, there are usually best practices that can be adopted to minimize exposure (e.g. disable unneeded services, plug holes in the firewall, reduce open shares, etc.) Still, you should be prepared for the possibility that management won't alter their stance. Look at the numbers. If you estimate that you spent $500 in time and/or equipment recovering from an incident, then maybe management is correct in accepting the risk. Of course, if you spent $50,000 that's a bit of a different picture but it might still be worth the risk to management. Only they will know. The bottom line is that you will make yourself crazy if your goals and objectives don't reflect the constraints management wants to operate within. Perhaps the saner route to take is to ask them how they define success and failure for your program. Rich -----Original Message----- From: Led Slinger [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 9:04 AM To: [EMAIL PROTECTED] Subject: Security Program Targets I wanted to throw this question out to a broad range of security professionals because I have been struggling with this for quite some time. The question is simple, but the answers elude me. How does one measure the success of a security program? I find it relatively simple to identify a risk and mitigate it using technology, but when corporate culture and business 'needs' butt heads with security requirements, I find myself losing more often than not. Simple things such as DMZ environments versus punch throughs to forcing patches on developers. They are quite simple to understand and to implement, and the cost is not a factor, it's plain and simple 'Time is money'. But rarely does the 'Time is Money' come into play when rebuilding a box due to NIMDA or some other tragedy du jour. OK, that's mostly bitchin about life, but where I'm trying to go with this is; If you develop a sound security program, implement it both tactically and strategically, how do you really measure its success? The number of incidents may go down, but even with a solid plan, the sheer number of new exploits and the fast rate of virus propagation may make the incident numbers go up. This really isn't a measure of success or failure in my book. Any suggestions, recommendation or generally information would be tremendously helpful! Cheers, Leds! -- There's nothing wrong with Windows until you install it........
