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:
- In general, why should you deploy an IDS?
- What is the Return on Investment (ROI) for an IDS? This can be further broken down into three questions:
- What it will cost to deploy the IDS?
- 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?)?
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:
- Compare to physical security:
- (How do you know someone hasnāt gone around the lock on the door/window if you arenāt looking at it) When you lock up your offices and homes, you still use video cameras, guards and burglar alarms to watch the entrances just in case.
- (You have to fix every hole, the attacker only has to find one) When you put locks on all your doors and windows, if you miss one (or a window or door gets added after you put the locks on) all your work is for nothing.
- (Time is on the attackerās side) There is no such thing as an unbreakable lock. The Underwriterās Laboratory sets ratings for locks and safes that are based on how long they can withstand an attack. To the best of my knowledge, they donāt actually offer a rating of āunbreakableā. The point isnāt to have a safe (or in our case, a computer or network) that can never be broken into, the point is to have a safe that can withstand attack for long enough to allow human security to arrive and prevent the attack from succeeding. If you arenāt watching to see who is trying to open the safe, it will be cracked eventually. The same holds true for your computing environment
- Show the benefits for ease of doing business (Helps availability: uptime/stability):
- By implementing intrusion detection, you can better manage risk in your environment without impacting business processes. The following situations are examples of this:
- Running systems or applications that are not completely up to date with patches. Two common scenarios where this might occur are:
- Delays due to a need to test the patch before deployment. Managing the security risk means more time can be spent testing each patch (managing the availability risk) to ensure it wonāt damage the system or application in question. This improves uptime and availability, which, in turn enables business.
- Business requirement for an application that will not run on a system that has had the patch in question applied. Managing the risk allows continuity of business without introducing unacceptable vulnerabilities into the environment
- Environments where high availability is essential. In some environments it may not even be an option to install a security patch without extensive scheduling and planning. By implementing intrusion detection, it is possible to manage the risk that exists during the time between discovery of a vulnerability and deployment of a patch.
- Running systems or applications that are not completely up to date with patches. Two common scenarios where this might occur are:
- By implementing intrusion detection, you can better manage risk in your environment without impacting business processes. The following situations are examples of this:
- Show the benefits for ease of doing business (business need for insecure services or porous perimeters):
- IDSs and monitoring can be used to manage risk in environments where insecure services (NFS, telnet, rsh/rlogin/rexec/etc.) are necessary to allow business to continue.
- IDSs allow increased flexibility in security controls and provide an additional layer of security when [1] other security controls fail unexpectedly. This provides the defense in depth needed to mitigate vulnerability.
- Simple, common sense paranoia:
- It is an axiom of programming that software will continue to be flawed until the developers themselves are flawless. This makes the existence of undiscovered vulnerabilities a certainty, not a probability. The only way to defend against as yet unknown vulnerabilities is to look for activities that suggest an attack is either under way or going to happen soon. IDSs can be tuned to provide the sort of trend data and statistical data necessary to look for unknown events.
- Security is becoming a requirement for doing business in many industries, more and more frequently, the owners of compromised systems are being held responsible for the results of those compromises. It is only a question of time until we start seeing lawsuits on behalf of customers who didnāt get a service they paid for, shareholders who lost money because the company didnāt take adequate security measures to protect their Intellectual Property (IP) or systems, customers whose personal data was made public due to poor security in a companyās network. There is not likely to be much sympathy for companies who have to admit āyes we knew that our security was not as strong as it could have been or should have been for the sort of data we have but we decided the risk was worth itā
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.
- General description of the project
- Definition of scope- what work are you doing, what work arenāt you doing? E.g. it is probably in scope to install the systems, configure the applications and monitor the resulting alerts. It is less likely that your scope includes the development of a complete custom IDS engine and application. This definition should also contain a discussion of how large a deployment you are planning. The whole network? Just your DMZ? Beware scope creep!
- Ways to measure the success of the project- this information is useful here but not essential:
- The obvious items to include are the quantifiable parts of your argument-
- Length of downtimes before and after.
- Average time spent investigating compromises
- This is the place to strengthen the arguments you are making based on ācommon senseā and paranoia-
- Number of attacks per day- this can and should be split out by different kinds of attacks. Be sure to at least do initial validation of the attacks before including them in your numbers. Itās better to have slightly lower numbers and be confident that they are all likely threats.
- The obvious items to include are the quantifiable parts of your argument-
- Cost estimates- as discussed in the rest of this section.
- Basic cost per sensor. This can be (but doesnāt have to be) broken out by:
- Hardware
- Software
- Hours of work required to deploy
- Infrastructure cost- what is going to have to be done to your network to make this work?
- Does this mean new switches somewhere?
- If you are setting up remote logging for the IDS can your current network handle the additional traffic?
- Associated costs- these are things like:
- The cost of a server to be your central monitoring and management server
- Any license costs for your central monitoring software (If your vendor includes this software it may be free as part of licensing the sensor software but it may not be. Be sure to check)
- The components needed to pump up one of your current servers so that they can handle acting as the central monitoring server as well. Remember; IDSs are noisy even when tuned well. You will need and want plenty of disk space as well as RAM (analysis is likely to require pulling data into active memory, using swap will definitely slow you down here).
- Ongoing costs:
- Estimated hardware upgrades (More than one introduction to IDS paper has suggested that these costs can be mitigated by purchasing high-end systems for use for IDS and then reusing them as for other purposes once they are no longer sufficient as IDS systems.)
- Work hours required on an ongoing basis. These should be broken down into at least the following areas:
- Time spent analyzing events
- Time spent responding to events
- Time spent tuning the IDS
- Time spent administering (cleaning the disks, running backups, patching software, non-IDS specific activities)
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:
- The burden rate your company uses. This is a number used by human resource departments and managers when they need to do budgeting. It includes all benefits, employee taxes etc. There is likely to be both a general number and then more specific ones for different kinds of employees. System administrators cost more these days than administrative assistants do. Lead visionaries cost more than either of the above. Keep track of which kind of people are going to be impacted and use the right numbers accordingly.
- The cost of downtime for the different servers you are looking at protecting. The cost of downtime is separate from the cost of incident response. Depending on the servers you are looking at, this should include things like:
- Loss of revenue per minute of downtime. This can be a significant amount and is likely something that your sales force can help you find.
- Loss of business opportunity. While your systems are down, a competitor is getting further ahead in their development cycle or getting the product questions that you couldnāt answer.
- Talk to sales people and find out how they estimate lost business when your products are late or there are not enough of them to meet demand. That will help define loss of revenue and opportunity.
- Loss of productivity due to downtime. How many people are being paid to do nothing while a server is down? Among other numbers, you need the burden rate to generate this one.
- Talk to team or project leads and low-level managers in your company and find out what it would cost them if an unexpected downtime occurred. This is likely to mean finding out how many subordinates they have who would be unable to function without the systems in question and then multiplying that number of people by their burden rate. That will give you cost per (hour/minute/week/month whatever you have a burden rate for)
- Then take a look through your logs and notes for the past year, how much down time have you had? Even the best environments have some, if you have more than one yearās worth of data, note that and use an average. You now have:
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.
Cost Savings
Donāt pass over any area when looking for cost savings:
- How much time do you (and other administrators in your company) spend reading logs on a daily basis? Will the product you are selecting help with that (it should if it is doing its job)? Estimate how much time might be saved and then multiply that by the burden rate your company uses. This will give you an estimated cost savings.
- How much disk space is used for holding all the raw logs until someone can look at them? This may not be much of an argument these days with 100GB hard drives as cheap as they are.
- When looking at downtime, see if you can find out how much time was spent on each phase. If most of your time is spent waiting for a new power supply, then you need to get other parts of your plan in order before worrying about IDS. If you spend most of the time in discovering there is a problem and then identifying what the problem is then IDS is likely to be able to significantly help you.
- How long does it normally take you to discover that something is wrong? This is probably something your system administrators can tell you about. What sort of monitoring are they doing already? What would happen if they didnāt do that monitoring? Use the difference in discovery to help develop estimates of how much of an improvement IDS could offer you.
- How much time did you spend trying to figure out whatās wrong? You canāt try to fix a problem till you know what the general problem is (server? Network? Some random moth fried to a motherboard?)
- How much time did you spend trying to figure out what needed to be fixed? This is different from whatās wrong- Once you know your server is down, you now need to figure out what happened to cause the problem so you can fix it.
- How many hours are spent doing incident response currently? Again, look at this for all the people involved in incident response and multiply by your companyās burden rate to get a dollar savings estimate. Decreasing the length of time spent on any of the following phases will decrease the overall length of a downtime.
- Discovery that there is a problem. Are servers down for an hour before someone notices?
- Identification of the type and details of the problem. Do you know the state of your systems well enough to be able to identify exactly what changed? How up to date are your configuration records?
- Solving the problem. How quickly can problems be solved once they are identified? This may be the least impacted by IDS since it really depends on your other business continuity plans.
Cost Avoidance
The following areas may allow for cost avoidance:
- How many incidents you company experienced last year? If not your company, companies in the same industry.
- What does an incident cost your company?
- Time of the people cleaning it up
- Time of the people who canāt work during the incident
- Revenue lost because necessary services are down
- If you donāt have data on your company look for average incident costs for your industry.
- What does an incident cost your company?
- What was the average cost of a lawsuit against companies who were compromised and were either used to execute further attacks or lost money or data because their security measures were inadequate?
- Get statistics from the government on the number of successful compromises and their estimated costs. [2] This data may come from surveys or actual penetration test results among other places.
- Look in the press. Many of these sources will be worthless, lacking enough substantiated data to be useable. However, some magazines and news sources are believed to be trustworthy by managers, if you know which ones your management trusts, look in those. The last year has produced mountains of statistics and everyone is eager to quote them. Some possible places to start looking are:
- www.google.com- search for security, statistics, cost, and other similar phrases
- Computer Security Institute/FBI Computer Intrusion Squad; http://www.gocsi.com/prelea_000321.htm
- US Department of Energy Information Security website: http://doe-is.llnl.gov/
- ICSA Labs, Carlisle, Pa.; ICSA LABS 6th Annual Computer Virus Prevalence Survey 2000 http://www.icsa.com/
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:
Direct revenue loss/minute of downtime for server X
Business opportunity revenue lost/minute of downtime
Average scheduled downtime/month (or day or year, your choice)
Average unscheduled downtime/month
Cost per hour for average employees
Cost per hour for specific types of employees that are likely to be impacted by downtime or incidents
Expected percent decrease in variable X when your product of choice is implemented
Example calculations:X = estimated cost for one non-productive hour.
( X ) X
