identification.

An analyst gets better results from an intrusion-detection system if he understands what he is searching for and tunes the IDS to find it, as opposed to letting the IDS tell the analyst what to look for.

If you have only one sensor, place it outside your firewall.

When you have evidence that your site is under a targeted attack, and that the attacker knows the type of operating systems you have and is targeting them accurately, take additional countermeasures swiftly.

If possible, implement a balanced intrusion-detection capability with both networkand hostbased solutions.

Chapter 17. Organizational Issues

What does risk management have to do with intrusion detection? Every organization either consciously or subconsciously makes decisions about risk. Obviously, we decide how much risk we are willing to accept ourselves. The distributed denial-of-service attacks that became widely known in February 2000 and Code Red attacks in 2001 demonstrate clearly that we also decide how much risk we are willing to accept on others' behalf. The security of my site depends, at least in part, on the security of your site. This chapter lays the groundwork that will enable you to present a cogent argument to your management that intrusion detection is one tool for managing risk, or part of an overall security architecture. The highest and best purpose of a network intrusion-detection system is to identify the attacks being directed against our perimeter defenses so that we can ensure our systems are hardened to withstand these attacks. In other words, intrusion detection must serve as instrumentation that enables us to define the metrics we need to manage risk intelligently. This chapter also ties risk-management techniques and concepts directly to intrusion detection.

Organizational Security Model

To manage risk, we need a model, a way of describing the problem and what needs to be done from a process standpoint so that we can get our arms around the problem. A simple example of a model is the Top Twenty list. You can find one at www.sans.org/top20.htm. It lists the top twenty vulnerabilities that attackers exploit and how to fix them. Every major vulnerability scanner looks for evidence of these. This is a simple model, listing the twenty vulnerabilities most often exploited. Make sure there are tools to find these vulnerabilities, and describe the fixes so that all users can repair their systems. If a significant number of people do this, attackers will have a much harder time compromising systems, and everyone's risk is reduced. Alan Paller, a good friend of mine, created this model. Alan Paller is the Director of Research for the System

Administration, Networking, and Security (SANS) Institute, and he developed another more complex model while on an international flight with some of the top security minds in the world. During the long flight to Australia, he continued to interview and question these individuals to develop a comprehensive security model.

While working with this model, I have been impressed with the results it gives after you take the time to implement it. As I reflect on the efforts and challenges of directing the startup effort that created the Global Information Assurance Certification (GIAC) certification and SANS Immersion training tracks, I am deeply thankful to have had a model like this to use. After twenty years of government service, adjusting to the speed we have to move at makes it hard to remember which way is up some days.

What to do? When I worked for the Ballistic Missile Defense Organization (BMDO), I used this security model to help me sort out the many contradictory priorities. In the government, everything is so ponderous that you need a roadmap to remember what you are trying to do. With SANS and the GIAC, everything is "practice what you preach." If we teach it, we do it. So, I am trying to implement the same model in a startup world where everything changes everyday. I did not develop this model; Alan Paller, Gene Schultz, Matt Bishop, and Hal Pomeranz did, but I have used it in the past and it has worked for me. I offer it to you in the hope that it helps you as well. As I describe it here, I will put an ID slant on the model, but you certainly can apply it in a more general way. Listing 17.1 shows the results of their work (courtesy of Matt, Alan, Hal, and Gene). Let's take a look at it. Instead of three steps (determine the top twenty vulnerabilities, scan or test for these vulnerabilities on your systems, and fix these vulnerabilities if they are present), this model has seven steps.

Listing 17.1 The Seven Most Important Things to Do If Security Matters

1.Write the security policy (with business input).

2.Analyze risks or identify industry practice for due care; analyze vulnerabilities.

3.Set up a security infrastructure.

4.Design controls and write standards for each technology.

5.Decide which resources are available, prioritize countermeasures, and implement the top priority countermeasures you can afford.

6.Conduct periodic reviews and possibly tests.

7.Implement intrusion detection and incident response.

Security Policy

Wait! Please don't close this book just because I wrote the words security policy. From my experience training analysts and teaching classes on intrusion detection, I know that the last thing an intrusion-detection analyst wants to do is write a security policy. When I teach, if I say "policy," I can see the eyes glaze over instantly. But applying filters to an IDS is kind of neat, right?

Consider that the filter rule set you upload to a sensor is called a policy. This is true for most

other commercial systems, and it is well named because these filter sets are a security policy. A firewall is just an engine that enforces network policy. So let's recalibrate ourselves not to think of security policy as a pile of paper that took weeks to write and now sits gathering dust. For an intrusion-detection analyst, a security policy is a permission slip, the organization's approval to install dynamic and active policy in security engines, such as firewall and intrusion-detection systems. That's right, policy can serve as permission to do the right thing! At its heart, an IDS is a monitoring device and you should never monitor people without authorization. Policy is the umbrella that covers us when we execute the steps to actually use an IDS effectively.

Industry Practice for Due Care

Both risk and vulnerabilities are discussed further, so for right now, let's focus on due care, or best practice. Actually, I abhor the term best practice, perhaps we can use pretty good practice instead. Although every organization has pockets of expertise, no one group has all the answers. As you know, the technology rate of change is so high that none of us can keep up across all the subject areas. The best solution to this problem is to learn what people are doing and what is working for them. One of the greatest joys for me in being affiliated with the SANS Institute has been the consensus projects. Many of them are called Step by Steps, such as Securing Windows 2000—Step by Step. These are not the work of a single person, but many committed professionals who come together on a project to share their knowledge with others.

Security Infrastructure

Robert Peavy, the Director for Security and Counter-Intelligence for the BMDO, prepared a talk for the Federal Computer Security Conference titled, "Security as a Profit Center—How to Sell Protection to Your Leadership."

As much as anyone I have ever met, Robert Peavy understood that security, good security, requires people. This is at least as true in the intrusion-detection field as any other security domain. Intrusion-detection analysts are front-line troops. They often feel personally responsible for any attacks that penetrate an organization's defenses and compromise systems. They get burned out and there are some turnover issues, especially if they are double-hatted with incident response as well. They need training to remain aware of the latest attacks, but there is limited high-quality training available for them. What does all this mean? It means the wise organization has some depth for the role of intrusion-detection analyst and that takes a security infrastructure to accomplish.

Implementing Priority Countermeasures

As I am writing tonight, I have a great fear. I have run vulnerability scanners at a number of organizations that have both UNIX and now an increasing number of Windows 2000/XP computers. I am shocked by the number of systems that still have well known vulnerabilities as well as the number of systems that still have SNMP; and it has been two weeks since the CERT advisory on SNMP and the PROTOS test kit was released that searched for thousands of problems. Will this be the next rstatd?

Since 1997, an ever-growing number of Sun Solaris UNIX systems continue to be compromised using a buffer exploit against the rstat daemon. Several buffer-overflow exploits are available for DNS, so it certainly could happen. Last week, I scanned a UNIX system being placed outside a firewall. It had the Echo, Chargen, portmap, and r-utilities open. It reminded me of elementary school when we used to put those signs on our classmates saying, "Kick Me."

How do you know whether something is a priority countermeasure in a world where everything is the number-one priority? If an attacker can exploit a vulnerability from the Internet as easily as a hot knife slicing through butter, you have to decide whether you want to fix the problem before or after the system is compromised. I continue to be astounded by the number of organizations that do not have time to do it right, but they do have time to do it over.

Periodic Reviews

Wake up! If you are an intrusion-detection analyst, do not miss this! It is imperative that you review your filter set from time to time. When I worked on the Shadow intrusion-detection project, one of the things I forced myself to do every couple of months was to run the complement of our filter set against a week's worth of data and manually parse through the results looking for anomalies. We must strive to continue to enhance our filter sets to reduce false negatives. If this month's set of filters is picking up exactly the same attacks as three months ago, this is a bad sign.

So, besides setting filters to trap the things one normally ignores, how do we improve our filters? The bugtraq mailing list has proven to be an excellent source of information about new attacks, each of which might need new filters. Once again, if you can find another group doing intrusion detection and striving to do it well, and you can exchange information, as this is another excellent way to stay current.

Conducting periodic reviews is a more general security principle than just watching our filter set, of course. The intrusion-detection analyst also profits by examining the firewall filter set on a fairly regular basis.You might find what I call firewall creep. When the firewall was first installed, it had a fairly tight and orderly ruleset. As time goes on, however, this business interest and that new service become a set of exceptions, or modifiers, to the ruleset. As the rules grow, it becomes harder and harder to validate them. Also, from time to time, the firewall administrator might add in a special rule "just for testing" and forget that it is there. As an analyst you think, "No problem, we are blocking UDP port umpty clutch," when in fact you aren't. The real difficulty is tracking these changes; they happen when you least expect them and over a long period of time, a bit like a low and slow scan. I am starting to think that external scanning services with databases, so you can track what has changed, are a must. If you have never considered one of these, you might want to visit www.qualys.com.

Implementing Incident Handling

An exhaustive discussion of incident handing is beyond the scope of this book, but I want to touch on it as it relates to the model. Have you ever been certified to administer CPR? How confident would you feel if you had to administer CPR 3, 6, 12 months after your training? I call these "gulp" moments. I know I am qualified as an incident handler in some sense, but if I haven't handled an incident in a couple of months, I really feel the rust.

What does incident handling have to do with intrusion detection? A lot! The analyst is likely to be the one to raise the alarm. In organizations with structured incident-handling capabilities, the analyst might be assigned to provide network information to the handlers. In organizations without these structured incident-handling capabilities, the handlers are likely to be you and a system administrator or two. In the "Manual Response" section of Chapter 18, "Automated and Manual Response," read carefully and make notes concerning the things you know you need to do before you have to handle a serious incident. If you do this, it will really help when the gulp moment comes.