Of course, you always can put your Web server into the trusted network, but all this placement does is move the target of the attack closer to the heart of the company. Any weak CGI script will still result in a compromise of some sort. You might seriously lock down the Web server with techniques such as read-only access, no logins except from a directly attached terminal, a hardened OS, and new Web pages installed only by a trustworthy individual. Unfortunately, none of these excellent ideas prevented the IIS attack noted previously. If a weak CGI is on your system, or a flaw is in a program called by a perfectly safe CGI, eventually someone will discover this opening. For some reason, there always seems to be a slot through which an attacker can slither.

By now you must have guessed that similar arguments apply to cryptography in network security. As distinguished and rich as the history of cryptography is, one lesson learned is that algorithms can be broken. Even if the cryptographic techniques are not weak, often secret keys are stored in encrypted form on local disk, and the key for the encryption is a user-chosen password. Secret-key cryptography is only as safe as the secrecy of the key. If someone can discover the key, the game is over (unless one-time keys are used). Even the secret-key component of a public-key pair is protected in local disk storage with a password. If people choose weak passwords, the benefits of cryptography will be lessened. Storing cryptographic keys in tamper-evident hardware devices is an alternative to keeping them on disk.

Look at the diagram in Figure 5.5. Both ends of the corporate network are protected by an IP tunnel that encrypts, signs, and authenticates all of the IP traffic between the sites. Threats to traffic as it passes through the untrusted network are neutralized, assuming that the keys are safe, and the cryptographic protocols are unbroken. What happens if an employee, visitor, or contract worker violates trust on either side of the IP tunnel? In this case, the tunnel functions properly except that it is being used to securely carry out improper behavior between sites.

Figure 5.5  Encrypted tunnels can carry attacks.

If your Web site contains a weak CGI program that can be exploited like the test.cgi script, cryptography will not prevent the attack. When a customer connects to your Web site using a digital certificate or SSL, and your site contains a weak CGI, cryptography dutifully fulfills its role. Cryptography guarantees that the attack string flows with privacy and integrity, and that the string indeed came from the individual claiming to send it. What you get is an encrypted and authenticated hack that is guaranteed not to have been modified in transit by any intermediaries.

As you have seen with Kerberos attacks and random number cracking, it is the cryptosystem itself that becomes the focus of the attack. Once again, the solution is to monitor these network security products, which you certainly need to deploy, in order to detect problems as soon as possible. System or network level IDSs will catch problems that network security products and even cryptographic solutions miss.

If you want, you can substitute other firewall architectures for Figure 5.2. Custom proxies and SOCKS enabled proxies also are candidates for poor programming practices or improper configurations. Again, one notable feature of the TIS Gauntlet proxies is that the source is available for inspection. The proxies also are written with a minimalist view that limits the opportunities for mistakes.

Most firewall vendors today—including TIS, IBM, Checkpoint, and Axent-Raptor—all recognize the need for prevention, detection, and response. Though not a standard feature at the time this book was written, some type of IDS will be incorporated into firewalls as the need for product differentiation grows. Today, for example, IBM bundles the Network Services Auditor (NS Auditor) with its firewall offering.

Firewall packet filtering rules and application proxy access controls also are complicated to configure. Not every company can afford to hire experienced, well-paid network security specialists to perform these tasks. The dynamic nature of businesses adds to the complexity. Employees come and go, new applications are written to communicate across the firewall boundary, and revenue almost always takes precedence over security. Often, if the tradeoff is between more revenue and better security, it’s not unusual to see people alter their definition of acceptable risk.

The general category of tools that are needed to further round out your security solution is collectively called intrusion detection even though different types of IDSs exist. Two different views of what an IDS is are offered: First are products that appear in the marketplace today. Some of these originated as research projects sponsored by the government during the last decade. Others were developed recently by individuals. For the research purist, though, an IDS is one of the currently active research projects at Stanford Research Institute (SRI) International or one of the handful of universities throughout the world focusing on intrusion detection. These projects usually have much loftier goals than commercial products. In this chapter and the next few, the focus is on commercial tools. See the References and Recommended Readings section at the end of the book for pointers to intrusion detection research papers.

Intrusion Detection: Concepts and Definitions

A distinction is often made between misuse detection and intrusion detection. If the focus of analysis is on detecting problems from inside the trusted network by watching the activities of authorized users, the phrase misuse detection is more appropriate. When the interest turns to looking for attacks from outsiders or intruders, the latter applies. One difference is that misuse detection assumes that the perpetrator has at least one valid account on one of the systems in your network. An intruder (hopefully) has no legitimate account on your systems. Also, the distinctions between intrusion and misuse detection are fuzzy when an insider originates an attack from an inside node by hopping through an external node and coming back into the trusted network. In this chapter, the term intrusion detection is used to mean any misuse, intrusion, or misfeasance that is unwanted.

Distinguishing features of an IDS are the type of engine that makes decisions about intrusions, whether analysis occurs in real time as the events are received, and the source of data for events.