and then it can be used to capture the communication stream. Most of the sniffers deployed by hackers to collect user IDs and passwords are pull-based systems. They collect data until the collected data is retrieved.

Figure 16.5. Push or pull?

Analyst Console

So, you have determined where to place your sensors and have selected between push, pull, or both paradigms to acquire the EOI information. Now you can finally get to work. The intrusiondetection analyst does her work at the analyst console. If an election was won with the mantra, "It's the economy, stupid," someone better tell the intrusion-detection vendors that, "It's the console, stupid." An organization typically looks for the following factors when shopping for an IDS:

●Real-time

●Automated response capability

●Detects everything (no false negatives)

●Runs on Windows XP/UNIX/Commodore 64 (whatever the organization uses)

That gets the box in the door, but will it stay turned on? I have visited several sites that deployed commercial intrusion-detection systems very early in the game, and although they are still connected to the network, the console has a thin layer of dust on its keyboard. After the organization has been using the system for several months, the feature set tends to be as follows:

●Faster console

●Better false positive management

●Display filters

●Mark events that have already been analyzed

●Drill down

●Correlation

●Better reporting

Most major commercial IDS system consoles were so bad that the Department of Defense funded a number of alternate designs. Several of these are now hitting the market as products in the Enterprise Security Console market. Most organizations can't afford to develop alternative interfaces; so if you are in the market for an IDS, this list might help you select one you can

actually use. The following sections explore the console factors in greater detail.

Faster Console

The human mind is a tragic thing to waste, but that is exactly what happens when we put trained intrusion analysts' minds in a wait state. Here is what happens: The analyst has a detect, he starts to gather more information, he waits for the window to come up, he waits some more, and suddenly can't remember what he was doing.

I was working with the sales engineer of an IDS company recently and tried to point out that the interface was very slow. His answer of course was to buy a faster computer. (This was a twin 1.2Ghz Pentium IV with a gigabyte of RAM, which was still fairly current for January 2002.) One simple technique for improving the console performance is for the system to always query the information for any high-priority attack and have it canned and ready for the moment the analyst clicks on it. This way, the computer can wait for the analyst, rather than the other way

around.

False Positive Management

False positives happen. Sometimes we can't filter them out without incurring false negatives, so we must ask: What we can do to manage them?

The Code Red web attacks serve as a good example. If we write a filter that dampens probes to port 80 (and most of us did), we stand the risk of a massive false negative. If we don't use such a filter, we will cause a large number of false positives (false positive in the sense that if we are not running a vulnerable version of IIS, we don't need to be concerned with Code Red). Because Code Red is a Windows problem, we could get part of the way towards handling this problem with a better filter. If our filter language supports it, we could put in basic passive fingerprinting information for Windows into our filter. For instance, a Windows system defaults to a TTL of 128 and TCP window sizes between 5,000 and 9,000 for Windows NT and between 17,000 and 19,000 for Windows 2000; so if we see a TTL of greater than 128 and a window size that is not within spec, perhaps we could afford not to display the detect. We still collect it, but we do not bother the analyst with it. When the analyst selects any event in the potential false positive class, the console should display the regular normal information that it always does, but also the additional data to enable the analyst to make the determination.

Responsibility for False Positive

IDS vendors' feet need to be held to the fire for better false positive management. The Snort ruleset is getting better and better about providing information in the help file that tells an analyst whether there are possible false positives and what they are. But this is not good enough. Vendors must be diligent in reducing them, because false positives are the biggest hurdle to successful incident management. Vendors should fix filters that cause too many false positives, make sure that filters vulnerable to them are tunable, and delete filters that are useless and cause too many false positives. If nothing else, they must carefully document exactly the traffic pattern triggering the filters to report false positives.

Display Filters

The false positive management technique just discussed is used on some commercial IDS systems and should be considered a minimum acceptable capability. To reach a goal of detecting as many events of interest as possible, you have to accept some false positives. Display filters are one way to manage these. This is not a new idea; network analysis tools,

such as NAI's Sniffer, have always had both collection and display filters.

Mark as Analyzed

Unless you are a second-level (supervisor, trainer, or regional) intrusion analyst, life is too short to inspect events that have already been manually analyzed. After an analyst has inspected an

event, it should be marked as done. This is not rocket science. After all, the web browsers we all use mark the URLs we have already visited. Ideally, this would be more like the editing functions on modern word processors such as Microsoft Word—the event gets a tag with the date and time it was analyzed and the username of the analyst, and whether it was rejected as

a false positive or accepted and reported.

Drill Down

We certainly wouldn't want to provide users an interface that intimidates them! When an organization first starts performing intrusion detection, it might be quite happy with the system displaying a GUI interface with a picture, the name of the attack, date, time, and source and destination IPs. The happiness often ends when the organization finds out that it has reported a false positive. At this point, the analyst starts to desire to see the whole enchilada and it should be available with one mouse click. Drill down is a very powerful approach. Analysts get to work with big-picture data, and then as soon as they want more detail, they just click. The analyst should not have to leave the interface he is using—that discourages research. Analysts certainly should not have to enter a separate program to get to the data—that is inexcusable.

Drill down is not possible unless the data is collected (and it certainly ought to include the

packet headers). No analyst should have to report a detect he can't verify!

Correlation

Every analyst has seen a detect and scratched his head saying, "Haven't I seen that IP before?" Intrusion analysts at hot sites (sites attacked fairly often) frequently detect and report between 15 and 60 events per day. After a couple of weeks, that is a lot of IP addresses to keep track of manually. It also is not hard for the analysis console to keep a list of sites that have been

reported and color those IP addresses appropriately.

Better Reporting

Two kinds of reports make up the bread and butter of the intrusion analyst: event-detection reports and summary reports. Event reports provide low-level detailed information about detects. Summary reports help the analyst to see the trends of attacks over time and the manager to understand where the money is going.

Event-Detection Reports

Event-detection reports are either done event by event or as a daily summary report. They are usually sent by electronic mail. The IDS should support flexibility in addressing and offer PGP encryption of the report. The reports might be sent to groups that specialize in collecting and analyzing this information such as Incidents.org or SecurityFocus or the organization's CIRT or FIRST team, the organization's security staff. If you are shunning the attacker or plan to take action, another powerful technique is to file the report as a memo to record. For every detect displayed on the console, the analyst should have the opportunity to report with a single mouse selection accepting the detect. The system should then construct a report, which the analyst reviews and annotates before sending.

If you are shopping for an intrusion-detection system or Enterprise Security Console, sit down at the console and see how long it takes you to collect the information needed to report an event and to send it via email (or other format such as XML) to a CIRT or FIRST team. If you can't access raw or supporting data, take your hands off the keyboard and walk away from the system. If it takes more than five to seven minutes and your organization intends to report events, keep shopping. If you can collect the information including raw or supporting data and send it in within two minutes, please send me email telling me about the product so I can get one too.

Weekly/Monthly Summary Reports

Management often wants to stay abreast of intrusion detects directed against the sites for which they are responsible. Event-by-event or even daily reporting might prove too time consuming, however, and doesn't help them see the big picture. Weekly or monthly reports are a solution to this problem. In general, the higher level the manager, the less frequently she should be sent reports.

Hostor Network-Based Intrusion Detection

The more information we can provide the analyst, the better chance she has of solving the difficult problems in intrusion detection. What is the best source of this information, host based or network based? If you read the literature on host-based intrusion-detection products, you might conclude that host based is a better approach. And, of course, if you read the literature of companies that are primarily network based, theirs is the preferred approach. Obviously, you want both capabilities, preferably integrated, for your organization. Perhaps the best way to consider the strengths of the two approaches is to describe the minimum reasonable intrusiondetection capability for a moderately sized organization connected to the Internet, such as

shown in Figure 16.6.

Figure 16.6. A common architecture for a moderately sized organization.

The sensor outside the firewall is positioned to detect attacks that originate from the Internet. DNS, email, and web servers are the target for about a third of all attacks directed against a site. These systems have to be able to interact with Internet systems and can only be partially screened. Because they face high overall risk, they should have host-based intrusion-detection software that reports to the analyst console as well. This shows the need for both capabilities, host and network based, even for smaller organizations. As the size and value of the organization increases, the importance of additional countermeasures increases as well.

This minimum capability does not address the insider threat. Much of the literature for (primarily) host-based solutions stresses the insider attack problem. I keep seeing studies and statistics that state the majority of intrusions are caused by insiders. This is beginning to change and most experts agree that the majority of attacks come from the Internet. Malicious