I have spent a good deal of time over the past year attempting to quantify the cost of implementing intrusion detection systems vs. the cost of not implementing them as well as the savings that can be realized by implementing them. Because many security professionals intuitively understand why intrusion detection is important, a disconnect can arise between them and their management, who may not understand and will want to see the measurable benefits. I hope that that this information will be useful to other members of the community and hope that others will find it easier to make a clear, convincing case for intrusion detection using some of the examples and suggestions I offer:
Making the case for, and proving the success of deploying Intrusion Detection Systems (IDSs)(Or, How to improve your chances of successfully making the case to deploy IDS and being able to prove it was successfully deployed when you are done):
As noted in the description above, this problem is really two separate issues:
First, there is the issue of how to convince your management to approve the dollars and resources needed to deploy IDS.
Second, there is the issue of how to show that it was worth doing once it has been deployed.
Iíll discuss them in order.
Making the case for IDS:
There are different issues that you must be prepared to discuss when making a case for deploying an intrusion detection system:
Why should you deploy an IDS?
These are general arguments for implementing intrusion detection. Take a look at them, balance what you know about your management with which ones you agree with most (donít try to argue a case you donít support) and then use the arguments that fit that information as suggestions in building your own general case:
What is the ROI for IDS?
Return on Investment is usually determined by using a formula like: (Money saved AND/OR costs avoided by implementation) Ė (Cost of implementation + ongoing costs) = ROI. The ongoing costs are not always included but you will want to be prepared to talk about those costs if asked. If this is a positive number, there is a clear justification for implementation. If the result is a negative number, then you need to take this into account before you attempt your implementation.
When we discuss Return on Investment (ROI) it is important to understand that this should be an actual number (e.g. ďROI is positive and is estimated at $XĒ not ďThere is a positive ROI and it should be pretty big.Ē). It doesnít have to be absolutely accurate, but it must be defendable and your methods of determining it must make sense to those you are presenting to. With that in mind, I will break down the individual pieces that should be included in determining your ROI.
What it will cost to deploy the IDS?
It is crucial, when talking to management that you be able to provide actual, reasonably accurate estimates for the cost of deploying IDS. These cost estimates should actually be part of your implementation plan, which may not be complete when you attempt to get approval for the project. However, you must have at least initial estimates or else you are likely to get shot down out of hand.
I want to take a moment and talk about the implementation plan since it is likely to play a critical part in both getting approval and then getting credit for your success. You should already have at least an initial implementation plan when you first go to talk to your management about IDS. A good implementation plan will contain the following information. I have put and asterisk next to the items that must be included in even your initial plan.
Obviously these areas are rather general and can be combined or split out into additionally fine distinct groups. The point is to be able to show where the money is going and make it clear to the person who has to approve the expense that this has been carefully thought out.
Beware! The flip side of providing these details is that you may be asked to explain why one item or another is so expensive or why a specific cost cannot be cut. During the process of identifying the costs, you should think about these questions and be prepared to explain why each cost is necessary.
What cost savings/avoidance will be made possible by deploying the IDS (Where might you save money that is being spent today/prevent money from having to be spent?)?
This is where you may have to make your entire case if you have been unsuccessful in convincingly making the basic arguments for intrusion detection. These numbers are likely to be somewhat fuzzy, donít worry about it. Acknowledge that they are estimates, but base them on as many facts as possible-
As you look for the areas where cost savings are possible, you will need to gather some numbers to allow you to calculate the final ROI:
I list these different variables at the end of this section so that you have a clearer picture of what data you need to find and use.
Cost Savings Vs. Cost Avoidance
There is a fine but distinct difference between Cost Savings and Cost Avoidance.
--Cost Savings come from places where you are going to spend no matter what, but perhaps you can do so more efficiently. Time spent reading logs must happen, but maybe you can minimize it. You are always going to have downtimes but if you have extra time to test the patches you are going to install, maybe you can make the downtime shorter. Time spent doing incident response must happen, but if you have the right information you can be much more efficient about it.
--Cost Avoidance comes from places where you are spending money today and you might not have to. If you notice someone scanning your external systems for vulnerabilities, you can block their IP address (or addresses) and give yourself a better chance of avoiding an incident. If you keep your servers from being compromised and used to attack other companies, you can avoid the cost of defending you lack of security in court.
Donít pass over any area when looking for cost savings:
The following areas may allow for cost avoidance:
NOTE: This is one place where vendors are likely to be your friend! This is exactly the sort of thing they should be able to tell you if they are competent- How bad is the world today? How much time or money does their product save people who use it? Call your sales rep! Ask for this info, thatís what they are there for! (They generally arenít there to provide detailed technical information)
Once you have this data collected, it is essential that it be put into a simple and clean format. Include all of the details, but provide them as appendices not as part of the main body of the argument. Put together the summary of the data, then summarize that and figure that will be about the right level of detail to start people off with. Many companies have ROI spreadsheets that are customized to their environments, ask your finance department (or person) if they can help you create on if they donít already have one. It may take a little fiddling but if you can adjust it to fit the data types you have, you will be able to present the information to management in a format they are already very familiar with.
Basic cost variables:These are only a few examples but they should provide you with an idea of what you need to be able to develop to make your case.
Proving that deploying IDS was a good thing:
Although this is being discussed as a distinct issue, it is very closely tied to the actual process of deploying the IDS. All during that process you must keep in mind how your actions will look in review as well as how you can show in a quantitative fashion, (remember, managers love numbers) that deploying IDS has been necessary, useful and cost-effective among other things. Without the need, it doesnít matter if IDS is useful. If your deployment isnít useful, you havenít fulfilled the need. If you arenít being cost-effective, no matter how well the IDS is doing its job, it may be one of the first things to go when the company needs to cut costs.
Is it necessary:
You should be able to generate statistics on the number of attacks you get each day/week/month/year. If you have deployed inside your network (instead of just at the perimeter) you may actually be able to show that your own network isnít the nice safe friendly place users think it is.
Is it useful:
To show that IDS is useful, you need to be able to show how IDS impacted any of the areas that you discussed in the deployment proposal:
Have downtimes decreased? How much?
Are your administrators more effective now that they donít have to spend as much time reading logs and attacks are caught more quickly?
Is your average cost per security incident lower than before deploying IDS?
Is it cost-effective:
All the estimates you generated during your project and the actual costs must now be added and then compared to the cost savings discovered above. This may not turn out to be a positive number. Donít worry too much about it! It may take more time than you have given so far for the project to show a return. Explain this to your management, they may not want to wait, but point out that all new businesses take time to become profitable and this project is just the same.
Was the project well managed?
This is the question that will be most likely to impact your next performance review. To answer this one, you need to have your project plan well-written and kept up to date. It needs to include details such as:
When you go to talk to your management about deploying IDS, try to have all the answers before they ask for them. The more well thought-out the project appears to be, the better your chances. Topics to include in your proposal are:
Basic statement of what you want to do
Start small! It is easier to justify spending a little money than a lot of money.Your general reasons for wanting to do this
Look at the arguments section I provided and adopt them to fit your organization and management.Detailed justification and analysis of why your organization must/should do this
There is a difference between must and should! Be sure to use the right term and remember that you must have numbers to back you up. Additional references to the infosec pundits wonít hurt either, but the numbers are key.
BEWARE: This is not really a paper about how to justify IDS. It is more of a paper on how to determine if you have a real need for IDS. You may find yourself in the uncomfortable situation of discovering that IDS is not needed for your environment. If this happens, donít fake the numbers! This should be obvious to everyone, but just in case Iíve said it anyway. If you still believe IDS is necessary, go back and look at the problems you are looking to solve with it and see if they are the right problems. Sometimes the answer to why something needs to be done is just ďbecause it makes good senseĒ, but that is a very hard case to make so avoid relying on it if at all possible.
 It must be assumed that all applications that are created by human programmers will fail at one time or another. Hence the use of the word ďwhenĒ and not ďifĒ
 Findings from a DoD study on penetration testing and the likelihood of being discovered - Krause & Tipton; Information Security Management Handbook 4th Ed. Pg. 682
 A Performance Test in Real-Time to recover from an Incident http://www.tripwiresecurity.com