senior executive who is the sponsor of the team.

The most important section of an incident report is the executive summary. This is where you document why having a crack incident-handling team saved your organization a lot of money.

Summary

We face risks with every user or program we add to our systems and with every service we open on our firewall. Effective response, both automated and manual, is an effective mitigation technique. It enables your organization to move a bit faster and a bit more aggressively in this fast-paced world. Some of the automated responses include throttling to slow down the attack, dropping connections, shunning the attacker if he attempts to reconnect, islanding from the Internet in serious attacks, protocol tricks such as sending SYN/ACKs even if the host or service does not exist, and Reset kills.

Every organization has an incident-handling team; some just haven't formalized one. A formal team following the six-step process of preparation, identification, containment, eradication, recovery, and lessons learned will probably be more effective than an ad hoc response. The intrusion-detection analysts should always be members of the team and often are excellent choices for leading it.

One security model, time-based security, states that the time that we are protected is primarily based on the time it takes us to detect and react to an attack. As we tune our automated and manual responses, we train to react faster and hopefully better, increasing the protection we provide for our respective organizations.

Chapter 19. Business Case for Intrusion Detection

"Where do I start? What is the best ID tool to use?" A student asked this question after he had just completed the most advanced class we teach on the subject of intrusion detection, our hands-on, immersion curriculum. I was more than a little surprised by that question. We had spent the past six days and evenings hands on, learning about covert channels, malformed packets, and TCP fingerprinting within a connection. We had worked and worked to show the students why there is no silver bullet, why every IDS needs to be backed up by a network recorder that captures all the traffic. I decided to answer with a question. To the questioner, I must have sounded like someone from Oz, but what I said was, "If your organization doesn't currently have an intrusion-detection capability, why should they acquire one now? What's changed?" If your organization doesn't currently have an intrusion-detection capability, it will often be an uphill effort to champion one. To paraphrase Newton, an organization at rest tends to remain at rest.

We are coming to the close of this book and before we move to our final chapter, the future of intrusion detection, I would like to consider the business case for intrusion detection. This is an important subject. The chapters that precede this one give the sense that the knowledge

required to be an analyst is very technical, but fun. Also, I am sure you have a sense that the job of the intrusion-detection analyst with new detects and live attacks is exciting and challenging. Everyone that I know in the field is having a great time, but that isn't a good reason to deploy intrusion detection in your organization. If you made it past the first half of the book, you probably have a technical bent; so do I. But that isn't enough. Three of my heroes in intrusion detection, Ron Gula, Marcus Ranum, and Marty Roesch, have all started to say, "As a businessman…." Each of us is in business in some sense. This is still true if we work for the government, a university, or a not-for-profit. If you are even thinking about intrusion detection, your organization probably is fairly well funded. We have taken pains to develop a technical and architectural framework, but also to consider the business issues of risk management. If your ID capability does not fit in your organization's business model, it will be a source of friction. Let's work together to develop the strategies and processes needed to package intrusion detection for an organization.

This chapter was written for security professionals who:

●Don't currently have an intrusion-detection capability and are considering the merits of acquiring one

●Have a rudimentary capability and are considering a follow-on procurement or upgrade

●Have an existing capability and the organization is downsizing or restructuring and is in the process of evaluating this job function

In these cases, you aren't going to succeed by "wowing 'em" with technology. Appeals to duty or alarmist cries, "The hackers are coming, the hackers are coming," will not suffice to keep this project funded for the long haul— although it might well shake loose money for an additional purchase.

This chapter lays out a three-part plan that shows the importance of intrusion detection. The first part of the plan covers management issues, what I call the "fluffy stuff." Part one isn't technical, but it serves as the backdrop to allow management to support the intrusion-detection plan.

Part two of the plan answers the question "Why intrusion detection?" This is where you discuss the threat and the vulnerabilities; this is where you draw heavily on what you have learned about risk.

Part three offers your solutions and tradeoffs. The goal is to create a written report that serves as the project plan and justification. I have tried to lay this out so that it makes a nice presentation as well, because that is how one normally briefs senior management these days. Each item in a bulleted list is a suggestion for a PowerPoint slide. For extra credit, cut and paste the appropriate material from your written report into the notes section of the PowerPoint slides and suggest they be printed with notes pages showing. Few people take the time to do notes pages, so this will show you have it together.

All presentations and reports to management should start with an introduction called an Executive Summary. This is where you sum up the three most important points you are going to make. When you brief senior management, always be prepared to have your time cut short. "Can you do it in five minutes?" is not an unheard of request. In that case, you will show exactly three slides: your Executive Summary, Cost Summary, and Schedule. The Executive Summary is followed by a Problem Statement, in which you define the problem you are trying to solve. You probably want to extract a nice sound bite from the information in part two of the report for this. Your third slide is a roadmap where you define the structure of the presentation.