Intrusion detection rules of thumb

There are a couple simple rules you should keep in mind as you go about planning for your intrusion-detection system. This tip, excerpted from Intrusion Detection, by Rebecca Gurley Bace, published by New Riders, details the basics.

Does security engineering sound even more hopeless to you than managing the all too chaotic world of system security? Some of the work of exploring security engineering was done originally to explore problems in cryptographic protocols. Fortunately, some of the findings are also helpful to those dealing with network security products.

Two approaches are helpful in dealing with the black art of designing robust security systems. Formal methods can be helpful in identifying problems early on and can help structure sanity checks of systems in a fashion that allows you to spot trouble early and correct it. However, many systems and functions are simply too complex for current formal methods to characterize. In this case, rules of thumb that provide guidance toward good practice are helpful in that they help us tune our intuitions. The key concept is explicitness. As intrusion detection system designers, we should be explicit about our starting assumptions and goals, as well as those vulnerabilities that can be used in an attack on our systems. In records and profiles, we should be explicit about subjects and objects, shooting for unique identifiers for each. (For instance, information sources should include full pathnames for files and should use a user identification scheme that binds a userID to the system on which the userID resides.)

Another critical rule of thumb is redundancy. In other words, if information sources are key to monitoring a critical system, we should have multiple monitoring points with a good bit of overlap. This practice addresses the risk of an attacker disabling the information sources as a first step of an attack. Similarly, because temporal order and binding to audit records in important in the information source, measures should be taken to protect the clock from which the audit event time stamps are derived.