Forged Email

Email is probably the most popular application used on the Internet. All people can have an email account, whether or not they have a computer at home. You can sign up for email accounts at several sites, such as Microsoft's Hotmail or Yahoo's email service, and use a computer at your school, at a library, or even at work to access the account.

Email messages, like Trojan horse programs, aren't always what they seem to be. Just because the FROM line contains the name of someone you know doesn't mean that the email actually came from that person. It's a simple matter when configuring an email account to use any name you want. And with the online email services that don't require you to use an email client (these services typically use an HTML interface—a Web browser), it can be difficult to determine where an email actually originated.

There are even programs freely available on the Net that allow you to create bogus email messages that appear perfectly normal in all respects. Although any intelligent person would probably not, in this day and age, open an email attachment from someone they do not know, they most likely would open an attachment from a friend. After all, if you can't trust your friends...

The problem is that email is easily forged and can be used to get a program into your network. As a rule, delete spam and other email from sources you don't recognize.

One of the more insidious things that can be done through email has occurred with alarming frequency in recent years. Worm viruses spread through email can read your address book, replicate themselves by mailing a copy of the virus code to everyone in your address book, and then start wreaking havoc on your system! About the only thing you can do in this situation is to disconnect the computer (or computers) from the network and clean out the mail store with a good virus program. If you have a mail server in your network, disconnect it and do the same. Until you've assured yourself that every computer in your network is free of such worm viruses, don't reconnect to the Internet, or any other part of your corporate network.

Password Protection and SecurlD and Smart Cards

Passwords and usernames have been the traditional method for authenticating a user to a computer operating system. There are much better methods you can use for environments that demand a high degree of security, such as smart cards and SecurlD cards.

Smart card devices are synchronized with software that runs on the host computer. To log on, the user simply consults the password code, which changes at regular intervals, generated by the smart card. Because the application on the host computer is operating to change the account password using the same algorithm as the smart card, a user's account password can be different every time she logs in. As long as the smart card and the application on the computer are kept in sync, it becomes very improbable for someone to "steal" your password. And most smart cards have passwords that can be used only one time. This means that even if someone happens to glance at the current password on your smart card, after you've used the password to log in, it can't be reused and abused.

SecurlD cards are based on digital certificates and require the user to enter a PIN for their use.

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.