Intrusion Detection FAQ: How to make the business case for an Intrusion Detection System?

Making the case for, and proving the success of deploying Intrusion Detection Systems (IDSs)

Making the case for IDS

1. In general, why should you deploy an IDS?
2. What is the Return on Investment (ROI) for an IDS? This can be further broken down into three questions:
3. What it will cost to deploy the IDS?
4. 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?

1. Compare to physical security:
   1. (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.
   2. (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.
   3. (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
2. Show the benefits for ease of doing business (Helps availability: uptime/stability):
   1. By implementing intrusion detection, you can better manage risk in your environment without impacting business processes. The following situations are examples of this:
      1. Running systems or applications that are not completely up to date with patches. Two common scenarios where this might occur are:
         1. 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.
         2. 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
      2. 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.
3. Show the benefits for ease of doing business (business need for insecure services or porous perimeters):
   1. 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.
   2. 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.
4. Simple, common sense paranoia:
   1. 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.
   2. 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?

• 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.
• 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)

• 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:

X = average cost of downtime/year.

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 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?

For cost avoidance, you may not have easily accessible numbers that come from your company. Try the following methods:

• 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/

Do not try to claim that you will be able to eliminate all downtime! Studies have been done regarding the average decrease in downtime [3] after implementation of a monitoring toolset. Keep your average decrease below 50% and you will have a greater chance of being believed (and of being right).

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:

<# of employees impacted by a specific server or service
 being unavailable> X  = estimated cost for one non-productive hour.


(<# of administrators or engineers needed to handle a
 downtime> X ) X 
 X
  = Average cost in
 terms of lost revenue due to unexpected downtime per month


 X  = Average cost in terms
 of hours of work lost/month for users

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:

• Major milestones
• Issues that may be potential show-stoppers
• Identification of the resources needed at each phase
• The implementation plan
• Timeframes for each stage

Keep detailed notes, if something doesn’t go as planned, make sure you have a clear statement of why, how it was handled and whether this could have been avoided.

Summary

:
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.

--------------------------------------------------------------------------------

[1] 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”

[2] Findings from a DoD study on penetration testing and the likelihood of being discovered - Krause & Tipton; Information Security Management Handbook 4th Ed. Pg. 682

[3] A Performance Test in Real-Time to recover from an Incident http://www.tripwiresecurity.com

< Previous Question | Back to Intrusion Detection FAQ Home | Next Question >