As the field of intrusion detection systems (IDS) has evolved, the focus of custom, open, and commercial solutions has been on structural, rather than operational, analysis and detection. Structural IDS will be defined as identifying and monitoring unusual actions and objects in the network and computers participating on the network. Some examples of these actions and objects are: failed logins, strange packets, and attempts at access violations by otherwise authenticated users. Operational IDS will be defined as the procedures used to identify intruders using otherwise valid credentials and presenting no other attributes that would normally be caught by the structural IDS in place on the network.
Although structural IDS plays an important role in the continued security of a network installation, it is crude in the sense that it does not offer methods of distinguishing between two people - both logging in at the same physical terminal, using the same valid credentials, at the same time of day, on the same day of the week, and accessing the same information - one of whom is a valid user, the other an intruder. Indeed, setting alerts on failed logins, scanning and analyzing both traffic and content, and watching for deviations in the network ?fingerprint? outside of the thresholds established by the administrators can only go so far. It is clear that sophisticated attackers seeking sensitive information will be using social engineering techniques to gain access, rather than using crude Denial of Service (DOS) attacks and brute forcing login credentials.
This document will explain the differences between structural and operational IDS, will discuss the shortcomings of structural IDS that make it necessary to employ operational IDS, and will offer a few examples of operational IDS in practice.
Structural and Operational IDS
Structural IDS plays an important role in the security of a network installation. Those serious about securing networks will most certainly continue to apply the practices and tools developed in this realm. It is important to realize, however, that structural IDS is reactive, and prone to frequent and rapid obsolescence. Structural IDS looks at network activity and user behavior. It defines a set of unacceptable behavior, and takes action when this unacceptable behavior does take place. Further, structural IDS can be used with thresholds in which no particular disallowed ?object? is discovered, but the statistical activity of the users and networks violates a pre-set (and sometimes automatically evolving) threshold. Finally, some IDS have the ability to react to the discovery of these ?objects? with more than just a simple alert in an attempt to dynamically lock down the breach. Structural IDS is therefore reactive because some pre- determined rule has to be broken in order to activate the system. Most administrators will not consider a crude attempt at DOS by an unsophisticated prankster an intrusion per se, but in the classical sense, the intrusion has already taken place by the time anyone knows about it. Structural IDS is also prone to obsolescence because the rule set becomes outdated the moment that any computer user discovers a new exploit or breach. Although structural IDS holds the promise of ?self-evolving? systems in which the system can reconfigure what it looks for based on new attacks, and further synchronize itself with publicly known databases of exploits, these techniques remain reactive, it cannot evolve until at least one attack has already taken place. There will always be lag time between the discovery of an exploit and its inclusion on public databases.
Both of these shortcomings are unavoidable and do not detract from the usefulness of and necessity for structural IDS. However, operational IDS must be deployed as well so as to detect the sophisticated intrusions that will not show up on the radar screens of the structural IDS.