Other IDS Features to Consider continue...

Monitoring 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 medical application 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 LOpht 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.