A complete nuts-and-bolts guide to improving network security using today's best intrusion detection products
Firewalls cannot catch all of the hacks coming into your network. To properly safeguard your valuable information resources against attack, you need a full-time watchdog, ever on the alert, to sniff out suspicious behavior on your network. This book gives you the additional ammo you need. Terry Escamilla shows you how to combine and properly deploy today's best intrusion detection products in order to arm your network with a virtually impenetrable line of defense. He provides:
• Assessments of commercially available intrusion detection products: what each can and cannot do to fill the gaps in your network security
• Recommendations for dramatically improving network security using the right combination of intrusion detection products
• The lowdown on identification and authentication, firewalls, and access control
• Detailed comparisons between today's leading intrusion detection product categories
• A practical perspective on how different security products fit together to provide protection for your network
The companion Web site at www.wiley.com/compbooks/escamilla features: White papers
• Industry news
• Product information
|Product dimensions:||7.50(w) x 9.29(h) x 0.80(d)|
About the Author
TERRY ESCAMILLA, PhD, is a Senior Software Architect for IBM Corporation in Boulder, Colorado. He previously worked for Haystack Labs, now part of Network Associates, a leading vendor of intrusion detection products including the Stalker family of products. A well-respected specialist in computer security and software engineering, Dr. Escamilla spent six years with IBM before joining Haystack in 1996. After Haystack was acquired by Trusted Information Systems and then by Network Associates, Dr. Escamilla rejoined IBM to work on e-business solutions.
Read an Excerpt
Chapter 8: UNIX System-Level IDSsMonitoring and Privacy
Keystroke monitoring has not been a fruitful approach to intrusion detection. As with many other computer science endeavors, context-sensitive analysis of data is one of the most difficult reasoning challenges for a program. Therefore, no commercial IDSs rely on keystrokes for determining misuses or intrusions. If such a tool were to exist, how would you handle privacy issues?
Most companies own the intellectual property of employees and also legally restrict computer activities to only those approved by management. A common practice is to present this warning to all computers users as part of the normal login message. This does not mean that all managers in a company own all of the correspondence of all of the employees. Especially unclear is how to handle the conflict that arises between privacy and monitoring. For example, if your IDS does monitor keystrokes, then someone is capable of reading the e-mail of employees. Sure, the company owns the content of these messages anyway. But, what if the message is from an employee to a superior complaining about harassment on the job. Is this something from which an IDS might generate alerts or message excerpts?
Unfortunately, you should be worried about privacy and IDSs even though they do not perform keystroke analysis. What if someone is filling out a medical form online and enters words such as "attack," "weakness," and "confidential?" Many network sniffers would look for these as part of a standard set of watch words. Ideally, you could configure the sniffer to ignore these words when the user was in the context of a medicalapplication online, but it's unlikely the tool supports this because it is a difficult algorithm to generalize.
System monitoring tools also require caution. Audit trail reports contain the full command and its parameters in most cases. Knowing that an employee is suddenly sending several mail messages to someone in personnel could be confidential. This situation particularly becomes a problem if the manager is receiving IDS usage reports (to look for misuse problems), and the employee is documenting improper behavior by that manager. In this particular case, the best advice is to document the problem on a home computer rather than risk discovery by unauthorized sniffers being used at your site.
By the way, these privacy problems are not limited to intrusion detection. In plenty of cases, developers use network sniffers to capture packets that are needed to debug a problem. Separating confidential information from test environments is the right approach for solving this dilemma. An interesting legend has gone around about how some user IDs and passwords from a reputable company found their way into one distribution of Crack when the software was tested in a production environment.
If you run a scanner and configure it to mail reports, verify your configuration so that you are not mailing the list of easily guessed passwords to everyone at your site, or even worse to your favorite newsgroup on the Internet. In some instances, someone mailed the output of a scan to a personal account outside the company, and the mail message flowed in the clear across the Internet. Remember, without encryption the Internet is like one big party line that many people share.
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 LOpht 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...
Table of Contents
BEFORE INTRUSION DETECTION: TRADITIONAL COMPUTER SECURITY.
Intrusion Detection and the Classic Security Model.
The Role of Identification and Authentication in Your Environment.
The Role of Access Control in Your Environment.
Traditional Network Security Approaches.
INTRUSION DETECTION: BEYOND TRADITIONAL SECURITY.
Intrusion Detection and Why You Need It.
Detecting Intruders on Your System Is Fun and Easy.
UNIX System-Level IDSs.
Sniffing for Intruders.
Intrusion Detection for NT.
ROUNDING OUT YOUR ENVIRONMENT.
You've Been Hit!
Intrusion Detection: Not the Last Chapter When It Comes To Security.