Finding New Attacks

Companies that build IDSs know the importance of keeping up with new attacks. Companies do this in several ways.

ISS recently has put together a talented team called the X-Force. This group spends a great deal of time uncovering their own exploits, as well as maintaining contacts in the hacker community. Secure Networks, Inc., also has a dedicated team of researchers that look for exploits, as did the WheelGroup (now folded into Cisco). These folks spend a good portion of their day looking for weaknesses in systems and networks. If you subscribe to BUGTRAQ, Best of Security, NT Security, and other security mailing lists, you’ll see the names of some of these folks appear regularly. They also are frequent panel members at conferences such as DEFCON and Usenix Security.

Another group of ethical hackers operates as L0pht Heavy Industries. Once described as “rock stars of computer security,” the L0pht is responsible for discovering well-announced weaknesses in products such as Kerberos V4 and Microsoft NT. The most famous output from the lab is the NT password cracker developed by two of the team’s members. Hacking in a private laboratory because its fun and interesting is perhaps the best motivation for finding security holes in products. That’s really why these exploit hunting teams exist.

Early hackers broke into systems because they were curious and wanted to learn more. Many remote attacks occur for the same reason today. Not everyone is out to damage your systems, although plenty of people enjoy doing so. Staying in touch with hackers is one way that companies know the latest exploits. Don’t be surprised if you find a consultant who has a history of attempted break-in attempts or even a conviction.

Security newsgroups and mailing lists are other avenues for keeping abreast of holes in systems. Most of these groups are moderated. A common rule of thumb is to notify the vendor before posting the flaw. Moderators are generally good about ensuring this happens. Unresponsive software vendors have sometimes been caught in the awkward situation of not knowing about an exploit because the mail from the discoverer was somehow lost in the corporate maze.

General Event Monitoring or Intrusion Detection

One of the consequences of acquisitions and mergers in the security industry is the maturing of security products so that they fit better into enterprise system management solutions. General event monitoring is one of the most useful components of a distributed management framework, such as Tivoli TME, which includes the Event Manager. Site administrators are interested in all sorts of events such as when disk drives crash, when network performance begins to suffer, when the printer is jammed, or when a system halts.

Event management frameworks are designed to manage events notifications and responses across heterogeneous distributed systems. Usually, one or more event consoles can be defined as recipients for events from managed nodes. An operator can be defined to receive all events or a limited subset. Responses to events can be automated or require manual intervention. In other words, quite a bit of generality is inherent in the event management system to handle different systems management policies and event multiple unique data input sources.

Intrusion detection is really a special case of event management. The main difference is that instead of looking for a single event or a threshold of events, an IDS will look for a complex patterns of events, too. Still, building some custom event handlers for frameworks such as Tivoli’s would not be too difficult for the implementation of an IDS. Tivoli’s event framework even ships with a generic log file adapter that can be customized to gather events, in real time, from different data sources. One example provided is a log file adapter for syslog which gathers and parses syslog records and sends them to the event console for processing. Local filtering, to eliminate redundant or unnecessary events, is another advantage of many event management frameworks.

During the next few years, you should expect to see better integration of IDSs into systems management frameworks, especially into the event notification subsystems. IDS vendors actually benefit from this opportunity because the secure framework code, for centrally reporting events, is provided for free by the systems management solution. Unfortunately, “for free” usually means increased support costs for the IDS vendors because not all customers will want the same systems management framework, nor will every customer have a framework. Thus, IDS vendors will need to support their own centralized event reporting subsystems when a systems management framework is not in use at the site.

Using Audit Logs to Find Attacks

The previous sections described two popular system-level intrusion detection products. In the next few sections, you will take a look at how using the audit logs can give you a very good picture of what is happening on your systems. Some of the types of attacks you face are described. For each of these, you will see descriptions of what a system-level IDS might need to catch the attack. No complex attack patterns are discussed because the idea is to give you a feel for the completeness of the audit logs. From these examples, you probably can see how more sophisticated patterns could be constructed by combining them.