This excerpt is from Chapter 17, The Future of Intrusion Detection and Prevention from the book Intrusion Detection & Prevention written by Carl Endorf, Eugene Schultz, Ph.D., and Jim Mellander, and published by McGraw-Hill. You can download the entire chapter here for free.
Protocol Analysis
Protocol analysis means analyzing the behavior of protocols to determine whether one host is communicating normally with another. For example, the TCP handshake (discussed in Chapter 2) is initiated by sending a TCP SYN packet to another host. The other host responds with a SYN ACK packet, to which the originating host responds with an ACK packet. Suppose that a host sends nothing but SYN packets to another host—an indication of a "SYN flood" attack designed to deplete memory and other resources in the receiving host. In another kind of protocol attack, a host might send malformed IP packets, perhaps IP packets in which one or more values in the IP header is out of range. In still another, a malicious code may send malformed "chunks," parcels in which data are transferred from a browser to a web server to provide an orderly way for the web server to encode the input.
Although these are simple examples, protocol analysis is by no means any kind of "lightweight" way of performing intrusion detection. A wide range of attacks (particularly DoS attacks) can be detected in terms of anomalous protocol behavior. Identifiable signatures may exist for many of the same attacks, but identifying these attacks at a lower level of networking (such as the network or transport layer by looking at the behavior of protocols such as IP, TCP, UDP, and ICMP) is more efficient than having to go to a higher layer. The rules of normal protocol behavior are well defined in RFCs (see www.ietf.com/rfc.html), so deviation is usually (but by no means always, given that a certain percentage of network traffic does not behave in accordance with any RFC) rather straightforward to determine. Additionally, many attacks that would require literally scores of signatures to detect can often be identified in terms of only a very few protocol behavior irregularities. Many of today's IDSs perform protocol analysis; IDSs of the future are likely to do more and also do it better.
Target Detection
We're also likely to see more widespread use of target detection in the future. As mentioned previously, target detection has proven to be one of the most robust and reliable methods of intrusion detection. Attackers almost invariably make changes in systems, often to create back doors, but sometimes (especially in the case of novice attackers) changes occur simply by accident. Attackers may be able to evade signature-based IDSs, and they may also be able to delete system logs to hide evidence of their activity, but they are less likely to escape the notice of a target detection tool that uses a variety of strong cryptographic algorithms and requires strong authentication for access to the target detection functions.
Although commercial target detection tools such as Tripwire (http://www.tripwiresecurity.com/) and Intruder Alert (http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=171) are widely used within Fortune 500 companies, the price of deploying these tools on many systems often serves as a deterrent to their use in smaller organizations. Freeware versions of Tripwire (http://ftp.cerias.purdue.edu/pub/tools/unix/ids/ tripwire/) and Windows-based integrity checking tools such as ForixNT (http://www.incident-response.org/forix-nt.htm) are available, but hurdles such as worries over software support have at least to some degree inhibited their widespread use.
Commercial target detection tools have established themselves in the marketplace; they will not disappear any time in the near future. What is likely to happen, however, is that operating system and application vendors will build powerful integrity checking capabilities into their products. To at least some degree, vendors already do this. Unix vendors, for example, have for a long time included the sum command for computing simple cryptochecksums and the diff command for detecting changes in file contents. Microsoft also includes the System File Checker and Windows File Protection in many of its operating system products. But these capabilities are relatively crude compared to the capabilities of many commercial tools.
Vendors are likely in time to expand the scope of integrity checking programs to include more than simply device driver or system file checking capabilities and also to provide real-time alerting capabilities. It would not be surprising, for example, to learn sometime in the near future that one or more vendors had incorporated the commercial Tripwire tool into an operating system. Doing this would make target detection easier to manage and possibly also more secure, given that operating system defenses could also be used to protect target detection executables and data files.
Download the entireChapter 17, The Future of Intrusion Detection and Prevention here for free.
Read other chapter excerpts and book reviews.
