Combine Products

The benefits of a combined product have been mentioned several times. The previous example in which a system IDS calls a scanner IDS when a file is changed is only one possibility. Some practical issues drive this requirement as well.

Buying a scanner from one vendor, a network sniffer from another, and a system-level monitor from a third is not a good solution. If IDS vendors could support a common set of standards as planned by the CIDF research project, then this would not be so bad. However, configuring different administrator passwords, using different GUIs, and trying to remember how to securely connect sensors and engines is too much extra work. ISS is headed in the right direction because they have scanners, sniffers, and one system-level tool. Today, the ISS system-level tool does not currently support UNIX. Complementary business partnerships are still possible, though.

Support Integration into Other Products

Earlier in the book a recommendation was made for IDS vendors to support modular architectures. The idea is to provide shared libraries or object classes that other vendors could use to invoke IDS routines as part of another system. For example, if a firewall could invoke network IDS routines on incoming packets, then your site will benefit from a more comprehensive solution. These discussions already may be happening, because many IDS vendors work closely with firewall vendors. However, plenty of opportunities exist to extend this idea to operating systems, databases, and other applications. The business benefits for IDS vendors are attractive in this distribution model, too. Attack pattern languages would add to the picture, because many applications have their own notions of subjects, objects, accesses, and security problems.

Support Research

A tremendous amount of fundamental research needs to be done in intrusion detection. This book simply does not have enough space to provide a comprehensive review of current intrusion detection research. Problems under investigation include resilience, fault tolerance, cooperating distributed analysis engines, tracking hackers across multiple systems, and attack-pattern formalisms. Pattern-matching systems have been around for quite some time in computer science and engineering. Ample opportunity is given to learn from the experiences of others in building classification systems that identify attacks against systems. Some IDS vendors already are generous in their support of basic research including IBM, ISS, and Hewlett-Packard.

Self Reference and IDSs

The title of this chapter, which really is the last chapter of the book, is influenced by the delightful work of Hofstatder (Gödel, Escher, and Bach: An Eternal Golden Braid, 1979). Not only is the title a fun little mind teaser, it also is a slight variation on one of the most perplexing problems in mathematics and computer science, patterned after the Epiminedes Paradox, which is a self-referencing sentence such as, “This sentence is false.” which shows the difficulty with assigning meaning to statements.

Kurt Gödel used self-referential statements to rock the foundation of mathematics and logic early in this century (Gödel, 1934). At a very high level, self-referential statements are difficult to interpret or assign a meaning to because they present a paradox. For example, if you believe the Epiminedes sentence to be true, it expresses a falsehood. If you believe it to be false, it then expresses a truth. What fun it is. To grossly paraphrase the importance of Gödel’s work, he embedded the Epiminedes Paradox into formal logic and proved inconsistencies in a universe where everything was supposed to be neatly ordered.

Computer science relies on self reference in a number of areas, such as when defining recursive subroutines. A great deal of interest has been expressed in software that can be self-healing, which means the software must somehow be able to examine itself. What does all of this have to do with intrusion detection? Gödel showed that self reference could twist logic all around itself. The same thing can happen in software that contains self-referential behavior. One question that is often asked of IDS vendors is what happens if the IDS fails. In other words, who’s watching the watchers?

An IDS is software written by people. This means that it will have programming bugs and vendor configuration errors. An IDS also can suffer from configuration errors made by those who administer IDSs. The same vulnerability categories that were identified for traditional products, such as I&A tools or firewalls, apply equally to IDSs.

Knowing whether the IDS is up and running is not a hard problem to solve. This can be done with one of many solutions. One approach would be a network “ping” or checkpoint between the IDS and a process on a physically secure server. When the IDS goes down, the other node sends an alert, restarts the IDS, or takes some other corrective action. Similarly, other types of systems management tools that monitor the availability of arbitrary programs could also monitor if the IDS is up and running. However, the more interesting question is who or what monitors the IDS to make sure it is not the source of security problems? Can an IDS watch itself?!

Imagine that you have an IDS with countermeasures or real-time responses. One of the responses could be to kill an offending process when a hack originates from that process. What happens when the hack originates from the IDS and you have the kill response activated? Oops. Possibly worse, what happens if the vendor prevents you from killing the IDS itself even if the hack originated from the IDS? If a hacker finds a successful buffer overflow attack against an IDS and killing the IDS is not an option, quite a bit of damage can be done before a human responds to a visual alert. This problem is not easy to solve.