I D :
Transcription
I D :
84-10-28 DATA SECURITY MANAGEMENT INTRUSION DETECTION: HOW TO UTILIZE A STILL IMMATURE TECHNOLOGY Eugene Schultz and Eugene Spafford INSIDE What Is Intrusion Detection? Why Use Intrusion Detection? How IDSs Work; Approaches to Intrusion Detection; Advantages and Limitations of Intrusion Detection Technology; Assessing Intrusion Detection Requirements; Developing an Intrusion Detection Architecture INTRODUCTION Defending one’s systems and networks is an arduous task indeed. The explosive growth of the Internet, combined with the ever-expanding nature of networks in and of itself, makes simply keeping track of change nearly an overwhelming challenge. Add the task of implementing proper security-related controls and the problem becomes of far greater magnitude than even the most visionary experts could have predicted 20 years ago. Although victories here and there in the war against cybercriminals occur, reality echos the irrefutable truth that “cyberspace” is simply too big a territory to adequately defend. Worse yet, security-related controls PAYOFF IDEA that work today will in all likelihood If your organization does not currently use intrufail tomorrow as the perpetrator sion detection technology, it is badly behind the community develops new ways to intrusion detection “power curve.” Furthermore, an organization that buys, then rolls out, a new defeat these controls. As well, the IDS product is by no means ready to reap the bencontinuing rush to market software efits immediately. A definite, steep learning curve with more new features is resulting for using intrusion detection technology exists. in poorly designed and poorly tested Even if you start deploying this technology now, it takes time to assimilate the mentality of intrusion software being deployed in critical detection and the technology associated with it situations. Thus, the usual installainto an organization’s culture. It is important, tion is based on poorly designed, therefore, to become familiar with and start using buggy software that is being used in this technology as soon as possible to avoid fallways unanticipated by the original ing behind even further. The alternative is to continue to function as the proverbial ostrich with its designers, and that is under continuhead beneath the sand. ing attack from all over. 10/99 Auerbach Publications © 1999 CRC Press LLC Schultz and Wack1 have argued that InfoSec professionals need to avoid relying on an approach that is overly reliant on security-related controls. Determining from a cost-benefit perspective the controls that most effectively reduce risk, then implementing and maintaining those controls is an essential part of the risk management process. Investing all of one’s resources in controls is, however, not wise because this strategy does not leave resources for detecting and responding to the security-related incidents that invariably occur. The so-called “fortress mentality” (implementing security barrier after security barrier but doing nothing else) in the InfoSec arena does not work any better than did castles in the United Kingdom when Oliver Cromwell’s armies aimed their cannons at them. It is far better to employ a layered, defense-in-depth strategy that includes protection, monitoring, and response.2,3 Merely accepting the viewpoint that it is important to achieve some degree of balance between deploying controls and responding to incidents that occur, unfortunately, does little to improve the effectiveness of an organization’s InfoSec practice. An inherent danger in the incident response arena is the implicit assumption that if no incidents surface, all is well. Superficially, this assumption seems logical. Studies by the U.S. Defense Information Systems Agency (DISA) in 1993 and again in 1997, however, provide statistics that prove it is badly flawed. Van Wyk4 found that of nearly 8800 intrusions into Department of Defense systems by a DISA tiger team, only about one in six was detected. Of the detected intrusions, approximately only 4 percent were reported to someone in the chain of command. This meant that of all successful attacks, less than 1 percent were both noticed and reported. A similar study by the same agency three years later produced nearly identical results. One could perhaps argue that perhaps many Department of Defense personnel do not possess as high a level of technical knowledge as do their counterparts in industry because industry (with its traditionally higher salaries) can attract top technical personnel who might more readily be able to recognize the symptoms of attacks. In industry, therefore, according to this line of reasoning, it would be much more likely that some technical “guru” would notice intrusions that occurred. This reasoning is at best only partially true, however, in that in the DISA studies little attempt was made to cover up the intrusions in the first place. In what might be called “more typical” intrusions, in contrast, attackers typically devote a large portion of their efforts to masquerade the activity they have initiated to avoid being noticed. This is further supported by the latest CSI/FBI survey5 that indicated that many firms are unable to determine the number or nature of intrusions and losses to their enterprise from IT system attacks, but that losses and number of incidents are continuing to increase. The main point here is that effective incident response is important and necessary, but it hardly does any good if people do not notice incidents that occur in the first place. Human efforts to notice incidents, as © 1999 CRC Press LLC 10/99 good as they may be, are in many if not most operational settings inadequate. InfoSec professionals often need something more: an automated capability that enables them to be able to discover incidents that are attempted or actually succeed. The solution is intrusion detection. This article covers the topic of intrusion detection, covering what it is, the types of requirements that apply to intrusion detection systems (ISDs), and ways that intrusion detection systems can be deployed. WHAT IS INTRUSION DETECTION? Intrusion detection refers to the process of discovering unauthorized use of computers and networks through the use of software designed for this purpose. Intrusion detection software in effect serves a vigilance function. An effective intrusion detection system both discovers and reports unauthorized activity, such as log-on attempts by someone who is not the legitimate user or an account, and unauthorized transfer of files to another system. Intrusion detection can also serve a role of helping to document the (attempt at) misuse so as to provide data for strengthening defenses, or for investigation and prosecution after the fact. Intrusion detection is misnamed. As a field, it originally started as a form of misuse detection for mainframe systems. The original idea behind automated intrusion detection systems is often credited to James P. Anderson for his 1980 paper on how to use accounting audit files to detect inappropriate use. Over time, systems have become more connected via networks; attention has shifted to penetration of systems by “outsiders,” thus including detection of “intrusion” as a goal. This discussion will use the common meaning of “intrusion detection” to include detection of both outsider misuse and insider misuse; users of ID systems should likewise keep in mind that insider misuse must also be detected. Why Utilize Intrusion Detection? One possible approach to intrusion detection would be to deploy thousands of specially trained personnel to continuously monitor systems and networks. This approach would in almost every setting be impossible to implement because it would be impractical. Few organizations would be willing to invest the necessary level of resources and the time required to train each “monitor” to obtain the needed level of technical expertise. Running one or more automated programs designed to effectively do the same thing, but without the involvement of thousands of people, is a more logical approach, provided of course that the program yields acceptable results in detecting unauthorized activity. Additionally, although many people with high levels of technical expertise could be deployed in such a monitoring role, it may not be desirable to do so from another perspective. Even the most elite among the experts might miss certain types of unauthorized actions given the typically gargantuan volume of activity that occurs within today’s systems © 1999 CRC Press LLC 10/99 and networks. A suitable intrusion detection program could thus uncover activity that experts miss. Detection per se is not, however, the only purpose of intrusion detection. Another very important reason to use IDSs is that they often provide a reporting capability. Again, the worst-case scenario would be relying on a substantial number of human beings to gather intrusion data when each person uses a different format to record the data in addition to terms and descriptions that are ambiguous to everyone but that person. Trying to combine each observer’s data and descriptions to derive patterns and trends would be virtually impossible; making sense out of any one observer’s data would at a minimum be very challenging. An effective intrusion detection system provides a reporting capability that not only produces human friendly information displays but also interfaces with a central database or other capability that allows efficient storage, retrieval, and analysis of data. How IDSs Work IDSs work in a large variety of ways related to the type of data they capture, as well as the types of analysis they perform. At the most elementary level, a program that runs on one or more machines receives audit log data from that machine. The program combs through each entry in the audit logs for signs of unauthorized activity. This type of program is part of a host or system-based IDS. At the other extreme, an IDS can be distributed in nature.6 Software (normally referred to as agent software) resides in one or more systems connected to a network. Manager software in one particular server receives data from the agents it knows about and analyzes the data.7 This second approach characterizes a network-based IDS (see Exhibit 1). Intrusion Detection Capability for Analysis Note that if the data that each agent sends to the manager has not been tampered with, the level of analysis possible is more powerful than with host or system-based IDSs for several reasons: 1. Although a host-based IDS may not be dependent on audit data (if it has its own data capturing service independent of auditing), audit and other types of data produced within single systems are very subject to tampering or deletion. An attacker who disables auditing or an intrusion data collection service on a given machine effectively disables that IDS that runs on that machine. This is not true, however, in the case of a network-based IDS, which can gather data not only from individual machines but also from passive devices (e.g., protocol analyzers) and other, more difficult to defeat machines such as © 1999 CRC Press LLC 10/99 EXHIBIT 1 — A Depolyment of an IDS in Which Agent Software Running on Hosts Sends Data to a Central Network firewalls. In other words, network-based IDSs are not as dependent on data from individual systems. 2. Network-based IDSs, furthermore, can utilize data that are not available in system-based IDSs.8 Consider, for example, an attacker who logs on to one system as user “BROWN,” then logs on to another system on the same network as “SMITH.” The manager software can assign a net ID to each user, thus enabling it to know that the user who has a log-on shell in both systems is the same user. This IDS can then generate an alarm based on the fact that the user in this example has logged on to different accounts with different names. This level of analysis is not possible if an IDS does not have data from multiple machines on the net. A third form of IDS, currently quite popular, involves one or more systems that observe network traffic (usually at a border location, such as near a firewall), and scan for packet traffic that indicates misbehavior. These “network intrusion detection systems” are easy to deploy to protect an enterprise from attack from the outside, but they have the drawback of missing internal behavior that may also be of interest. APPROACHES TO INTRUSION DETECTION Not only do different implementations of IDSs work using fundamentally different kinds of data and analysis methods, but they also differ in the types of approaches to intrusion detection that have been incorporated © 1999 CRC Press LLC 10/99 into their design. The correct question here is not, “do you want to deploy an intrusion detection system (IDS)?, but rather, “which type of IDS do you want to deploy?” The following are the major types of IDSs. Anomaly Detection Systems Anomaly detection systems are designed to discover anomalous behavior; that is, behavior that is unexpected and abnormal. At the most elementary level, anomaly detection systems look for use of a computer system during a time of the day or night in which the legitimate user hardly if ever uses the computer. Statistical profiles indicating percentiles of measurable behavior and what falls within one standard deviation of the norm, two standard deviations, etc., are often the basis for determining whether or not a given user action is anomalous. At a more sophisticated level, one might profile variables and processes such as types of usage by each specific user. One user, for example, might access a server mostly to read e-mail, another might balance usage time between e-mail and using spreadsheet-based applications, and a third might mostly write and compile programs. If the first user suddenly starts compiling programs, an anomaly detection system should flag this type of activity as suspicious. Misuse Detection Systems The main focus of misuse detection systems is on symptoms of misuse by authorized users. These symptoms include unauthorized log-ons or bad log-on attempts to systems, in addition to abuse of services (e.g., Web-based services, file system mounts, etc.) in which users do not need to authenticate themselves. In the latter case, therefore, good misuse detection systems will identify specific patterns (called signatures) of anomalous actions. If an anonymous FTP user, for example, repeatedly enters cd …, cd …, cd … from a command line, there is a good chance that the user is attempting a “dotdot” attack to reach a higher level directory than FTP access is supposed to allow. It is very unlikely that a legitimate user would repeatedly enter these keystrokes. Target Monitoring Systems Target monitoring systems represent a somewhat radical departure from the previously discussed systems in that target monitoring systems do not attempt to discover anomalies or misuse. Instead, they report whether certain target objects have been changed; if so, an attack may have occurred. In UNIX systems, for example, attackers often change the /sbin/login program (to cause a pseudo-login to occur in which the password of a user attempting to log in is captured and stored in a hidden file) or the /etc/passwd file (which holds names of users, privilege levels, © 1999 CRC Press LLC 10/99 etc.). In Windows NT systems, someone may change .DLL (dynamically linked library) files to alter system behavior. Most target monitoring systems use a cryptographic algorithm to compute a cryptochecksum for each target file. Then, if the cryptochecksum is calculated later in time and the new cryptochecksum is different from the previous one, the IDS will report the change. Although this type of IDS superficially does not seem as sophisticated as the previous ones, it has several advantages over anomaly and misuse detection systems, including: 1. When intruders break into systems, they frequently make changes (sometimes accidentally, sometimes on purpose). Changed files, executables that are replaced with Trojan horse versions, etc., are therefore excellent potential indications that an attack has occurred. 2. Target monitoring systems are not based on statistical norms, signatures, and other indicators that may or may not be valid. These systems are, therefore, not as model dependent — they are instead simple and straightforward. Furthermore, they do not really need to be validated because the logic behind them is so obvious. 3. They do not have to be continuously run to be effective. All one has to do is run a target monitoring program at one point in time, then another. Target monitoring systems thus do not generally result in as much performance overhead as do other types of IDSs. Systems that Perform Wide-Area Correlation of Slow and “Stealth” Probes Not every attack that occurs is an all-out attack. A fairly typical attack pattern is one in which intruders first probe remote systems and network components such as routers for security-related vulnerabilities, and then actually launch attacks later. If attackers were to launch a massive number of probes all at once the likelihood of noticing the activity would increase dramatically. Many times, therefore, attackers probe one system, then another, then another at deliberately slow time interviews. The result is a substantial reduction in the probability that the probes will be noticed. A fourth type of IDS performs wide-area collection of slow and stealth probes to discover the type of attacks mentioned in this section. MAJOR ADVANTAGES AND LIMITATIONS OF INTRUSION DETECTION TECHNOLOGY Advantages Intrusion detection is potentially one of the most powerful capabilities that an InfoSec practice can deploy. Much of attackers’ ability to perpetrate computer crime and misuse depends on their ability to escape being noticed until it is too late. The implications of the DISA statistics cited earlier are potentially terrifying; in the light of these findings, it might therefore be more reasonable to ask how an InfoSec practice that claims to observe the principle of “due dilligence” could avoid using an © 1999 CRC Press LLC 10/99 IDS enterprisewide. It is strongly emphasized that any InfoSec practice that does not utilize IDS technology to at least some degree is not practicing due dilligence because it will necessarily overlook a large percentage of the incidents that occur. Any practice that remains unaware of incidents does not understand the real risk factor; sadly, it only mimics the behavior of an ostrich with its head under the sand. Simply put, an effective IDS can greatly improve the capability to discover and report security-related incidents. Also note that the complexity of configuration of most systems, and the poor quality of most commercial software, effectively guarantees that new flaws will be discovered and widely reported that can be used against most computing environments. Patches and defenses are often not as quickly available as attack tools, and defenses based on monitoring and response are the only way to mitigate such dangers. The failure to use such mechanisms is a failure to adequately provide comprehensive security controls. In addition to increasing an organization’s capability to notice and respond to incidents, ISDs offer several other major benefits. These include: 1. Cost reduction. Automated capabilities over time generally cost less than humans performing the same function. Once an organization has paid the cost of purchasing and installing one or more IDSs, the cost of an intrusion detection capability can be quite reasonable. 2. Increased detection capability. An effective IDS is, as mentioned earlier, able to perform more sophisticated analysis (e.g., by correlating data from a wide range of sources) than are humans. The epidemy of the problem of reading and interpreting data through human inspection is reading systems’ audit logs. These logs typically produce a volume of data that system administrators seldom have time to inspect at all or at least in any detail. Remember, too, that attackers often have the initial goal of disabling auditing once they compromise a system’s defenses. IDSs do not necessarily rely on audit logs. 3. Deterrent value. Attackers who know intrusion detection capabilities are in place are often more reluctant to continue unauthorized computer-related activity. IDSs thus, to some degree, serve to deter unauthorized activity. 4. Reporting. An effective IDS incorporates a reporting capability that utilizes standard, easy-to-read and understand formats and database management capabilities. 5. Forensics. A few IDSs incorporate forensics capabilities. Forensics involves the proper handling of evidence that can be used in court. A major goal of forensics in fact is to collect and preserve evidence about computer crime and misuse that will be admissible in a court of law. © 1999 CRC Press LLC 10/99 6. Failure detection and recovery. Many failures exhibit features similar to misuse or intrusion. Deployment of good IDs can result in advance notice of these symptoms before they result in full failures. Furthermore, some IDs can provide audit data about changes, thus allowing failed components to be restored or verified more quickly. Disadvantages On the other hand, intrusion detection is beset with numerous limitations. Some of the most critical of these drawbacks include: 1. Immaturity. Most (but not all) IDSs available today have significant limitations regarding the quality of functionality they provide. Some are, in reality, little more than prototypes with a sophisticated user interface. Others purport to compare signatures from a signature library to events that occur in systems or networks, but the vendors or developers refuse to allow potential customers to learn how complete and how relevant these libraries are. Equally troubling is the fact that new types of attacks occur all the time; unless someone updates the signature library accordingly, detection efficiency will fall over time. Still other IDSs rely on statistical indicators such as “normal usage patterns” for each user. A clever perpetrator can, however, patiently and continuously engage in activity that does not fall out of the normal range but comes close to doing so. The perpetrator thus can adjust the statistical criteria over time. Someone who normally uses a system between 8 a.m. and 8 p.m. may, for example, want to attack the system at midnight. If the perpetrator were to simply attack the system at midnight, alarms might go off because the IDS may not consider midnight usage within the normal range of usage for that user. But if the perpetrator keeps using the system from, say, 11 a.m. to 11 p.m. every day for one week, usage at midnight might now no longer be considered statistically deviant. 2. False positives. Another serious limitation of today’s IDSs is false positives (Type I errors). A false positive occurs when an IDS signals that an event constitutes a security breach, but that event in reality does not involve such a breach. An example is multiple, failed log-ins by users who have forgotten their passwords. Most of the IDS customer community today is concerned about false alarms because they are often so disruptive and because they sidetrack the people who investigate the false intrusions from other, legitimately important tasks. 3. Performance decrements. Deploying IDSs results in system or network performance hits. The actual amount of decrement depends on the particular IDS; some are very disruptive to performance. Anomaly-based systems are often the most disruptive because of the complexity of matching required. © 1999 CRC Press LLC 10/99 4. Initial cost. The initial cost of deploying IDSs can be prohibitive. When vendors of IDS products market their products, they often mention only the purchase cost. The cost to deploy these systems may require many hours of consultancy support, resulting in a much higher cost than originally anticipated. 5. Vulnerability to attack. IDSs themselves can be attacked to disable the capabilities they deliver. The most obvious case is when a trusted employee turns off every IDS, engages in a series of illegal actions, and then turns every IDS on again. Any attacker can flood a system used by an IDS capability with superfluous events to exceed the disk space allocated for the IDS data, thereby causing legitimate data to be overwritten, system crashes, and a range of other undesirable outcomes. 6. Applicability. IDSs are, by definition, designed to uncover intrusions — unauthorized access to systems; yet a large proportion of the attacks reported recently (at the time this article was written) were either probes (e.g., use of scanning programs to discover vulnerabilities in systems) or denial-of-service attacks. Suppose that an attacker wants to cause as many systems in an organization’s network to crash as possible. Any IDSs in place may not be capable of discovering and reporting many denial-of-service attacks in the first place. Even if they are capable of doing so, knowing that “yes, there was a denial of service attack” hardly does any good if the attacked systems are already down. Additionally, many (if not most) of today’s IDSs do a far better job of discovering externally initiated attacks than ones that originate from inside. This is unfortunate, given that expected loss for insider attacks is far higher than for externally originated attacks. 7. Vulnerability to tampering. IDSs are vulnerable to tampering by unauthorized as well as authorized persons. Many ways to defeat IDSs are widely known, within both the InfoSec and perpetrator communities. In a highly entertaining article, Cohen9 describes 50 of these ways. 8. Changing technology. Depending on a particular technology can result in loss of protection as the overall computing infrastructure changes. For example, network-based intrusion detection is often foiled by switch-based IP networks, ATM-like networks, VPNs, encryption, and alternate routing of messages. All of these technologies are becoming more widely deployed as time goes on. The advantages and disadvantages of intrusion detection technology are summarized in Exhibit 2. ASSESSING INTRUSION DETECTION REQUIREMENTS The relationship of intrusion detection to risk. A large number of organizations go about the process of risk management by periodically performing risk assessments, determining the amount of resources available, © 1999 CRC Press LLC 10/99 Exhibit 2 — Summary of Advantages and Disadvantages of Intrusion Detection Technology • Cost reduction (at least over time) resulting from automation • Increased efficiency in detecting incidents • Can deter unauthorized activity • Built-in reporting, data management, and other functions • Built-in forensics capabilities • Many IDSs do not deliver the functionality that is needed • Unacceptably high false alarm rates • Generally produce performance decrements • Initial cost may be prohibitive • May yield superfluous data • IDSs themselves are vulnerable to attack and then allocating resources according to some method of prioritybased risk mitigation strategy (i.e., introducing one or more controls that counter the risk with the greatest potential for negative impact, then implementing one or more measures that address the risk with the second greatest negative impact, until the resources are spent). Regardless of whether or not one agrees with this mode of operation, it tends to guarantee that intrusion detection needs will be overlooked. In simple terms, intrusion detection does not address any specific risk as directly as measures such as encryption and third-party authentication solutions. Developing Business-Related Requirements Developing specific, business-related requirements concerning intrusion detection is anything but an easy process. The difficulty of doing so is in all likelihood one of the major detractors in organizations’ struggles in dealing with intrusion detection capabilities. Business units, furthermore, may be the most reluctant to utilize intrusion detection technology because of the typical level of resources (personnel and monetary) required and because this technology may superficially seem irrelevant to the needs of fast-paced business units in today’s commercial environments. On the other hand, obtaining buy-in from business units and developing business requirements for intrusion detection at the level of business units is probably not, in most cases, the primary goal anyway. In most organizations, if intrusion detection technology is to be infused successfully, it must be introduced as a central capability. Business requirements and the business rationale for intrusion detection technology are likely to be closely related to the requirements for an organization’s audit function. The ultimate goal of intrusion detection technology in business terms is the need to independently evaluate the impact of system and network usage patterns in terms of the organization’s financial interests. As such, it is often easiest to put intrusion detection technology in the hands of an organization’s audit function. © 1999 CRC Press LLC 10/99 Decision Criteria Suppose that an organization decides to introduce intrusion detection technology. After deriving the business requirements that apply to the organization, the next logical step is to determine whether the organization will build a custom IDS or buy a commercial, off-the-shelf version. The latter is generally a much wiser strategy — building a custom IDS generally requires far more time and resources than one might ever imagine. Additionally, maintenance of custom-built IDSs is generally a stumbling block in terms of long-term operations and cost. The exception to the rule is deploying very simple intrusion detection technology. Setting up and deploying “honey pot” servers, for example, is one such strategy. “Honey pot” servers are, in essence, alarm servers connected to a local network. Normally, nobody uses a “honey pot” server, but this host is assigned an interesting but bogus name (e.g., patents.corp.com). If anyone logs in or even attempts to log in, software in this type of server alerts the administrator, perhaps by having the administrator paged. The major function of “honey pot” servers is to indicate whether an unauthorized user is “loose on the Net,” so that one or more individuals can initiate suitable incident response measures. This strategy is not elegant in terms of the intrusion detection capability that it provides; it is, however, not only simple, but is also very cost-effective. Better yet, an older, reasonably low-ended platform (e.g., a Sparcstation 5) is generally more than sufficient for this type of deployment. Buying a commercial IDS product is easier when one systematically evaluates the functionality and characteristics of each candidate product against meaningful criteria. At a minimum, one should apply the following criteria: 1. Cost. This includes both short- and long-term costs. As mentioned previously, some products may appear to cost little because their purchase price is low; but life-cycle deployment costs may be intolerable. 2. Functionality. The difference between a system- versus a networkbased IDS is very important here. Many intrusion detection experts assert that system-based IDSs are in general better for detecting insider activity, whereas network-based IDSs more often better for detecting externally originated attacks. This consideration is, however, only a beginning point with respect to determining whether or not a product’s functionality is suitable. The presence or absence of functions such as reporting capabilities, data correlation from multiple systems, and near realtime alerting is also important to consider. 3. Scalability. Each candidate tool should scale not only to business requirements but also to the environments in which it is to be deployed. In general, it is best to assume that whatever product one buys will have to scale upward in time, so obtaining a product that © 1999 CRC Press LLC 10/99 4. 5. 6. 7. 8. can scale not only to the current environment, but also later to more complex environments, is frequently a good idea. Degree of automation. The more features of an IDS product that are automated, the less human intervention is necessary. Accuracy. An IDS product should not only identify any bona fide intrusion that occurs but should also minimize the false alarm rate. Interoperability. Effective IDSs can interoperate with each other to make data widely available to the various hosts that perform intrusion detection management and database management. Ease of operation. An IDS that is easy to deploy and maintain is more desirable than one that is not. Impact on ongoing operations. An effective IDS causes little disruption in the environment in which it exists. DEVELOPING AN INTRUSION DETECTION ARCHITECTURE After requirements are in place and the type of IDS to be used is selected, the next logical phase is to develop an architecture for intrusion detection. In the current context, the term “architecture” is defined as a highlevel characterization of how different components within a security practice are organized and how they relate to each focus within that practice. Consider, for example, the following components of an InfoSec practice (see Exhibit 3). To develop an intrusion detection architecture, one should start at the highest level, ensuring that the policies include the appropriate provisions for deploying, managing, and accessing intrusion detection technology. For example, some policy statement should include the provision that no employee or contractor will access or alter in any way any IDS that is deployed. Another policy statement should specify how much intrusion detection data are at a minimum to be captured and how it must be archived. It is also important to ensure that an organization’s EXHIBIT 3 — A Simple Framework for a Security Architecture © 1999 CRC Press LLC 10/99 InfoSec policy clearly demarcates what “unauthorized activity” constitutes if the output of the IDS is to have any real meaning. At the next level down, one might write specific standards appropriate to each type of IDS deployed. For IDSs with signature libraries, for example, it is important to specify how often the libraries should be upgraded. At the lowest level, one might include recommendations such as how much disk space to allocate for each particular IDS installation. It is important to realize that an intrusion detection capability does not work well in isolation; it needs to be part of the inner fabric of an organization’s culture. As such, developing an intrusion detection architecture is a very important step in successfully deploying intrusion detection technology. Note also that developing such an architecture is not as simple as diagrams such as Exhibit 3 might imply; it requires carefully analyzing for each component of the architecture exactly what intrusion detection requires and how to embody the solution for each need within that component. Equally importantly, it requires consensus among organizations that will or might be affected by the rollout of intrusion detection technology in addition to buy-in from senior-level management. CONCLUSION This article examined intrusion detection and its potential role in an InfoSec practice, arguing against the “fortress mentality” that results in implementation of security control measures such as password hackers without realizing that no defense measure is 100 percent effective anyway. It is important, therefore, to devote a reasonable portion of an organization’s resources to detecting incidents that occur and effectively responding to them. This article took a look at its advantages and disadvantages, and then discussed how one can effectively introduce intrusion detection technology into an organization. Finally, considerations related to deploying IDSs were discussed. Intrusion detection in many ways stands at the same crossroads that firewall technology did nearly a decade ago. The early firewalls were really rather crude, and most organizations viewed them as interesting but impractical. Intrusion detection technology was available before the first firewall was ever implemented, but the former has always faced more of an uphill battle. The problem to a large extent can be characterized as due to the mystery and evasiveness that has surrounded IDSs. Firewalls are more straightforward — the simplest firewalls simply block or allow traffic destined for specific hosts. One can be reasonably sure when buying a firewall product how this product will work. The same has not been true in the intrusion detection arena. Yet at the same time, intrusion detection is rapidly gaining acceptance among major organizations around the world. Although the technology surrounding this area is far less than perfect, it is now for the © 1999 CRC Press LLC 10/99 most part sufficiently reliable and sophisticated to warrant its deployment. To ignore and avoid deploying this technology now, in the authors’ judgment, constitutes a failure to adopt the types of measures responsible organizations are now putting in place, which in simple terms is a failure to observe “due care” standards. The good news is that intrusion detection technology is becoming increasingly sophisticated every year. Also encouraging is the fact that performance-related problems associated with IDSs are becoming relatively less important because operating systems and the hardware platforms on which they run are constantly improving with respect to performance characteristics. The research community, additionally, is doing a better job in pioneering the way for the next generation of intrusion detection technology. Some current advances in intrusion detection research include areas such as interoperability of IDSs, automatic reporting, and automated response (in which the IDS takes evasive action when it determines that an attack is in progress). The bad news is that if an organization does not currently use intrusion detection technology, it is badly behind the intrusion detection “power curve.” Consider, furthermore, that an organization that buys, then rolls out a new IDS product is by no means ready to reap the benefits immediately. A definite, steep learning curve for using intrusion detection technology exists. Even if one starts deploying this technology now, it takes time to assimilate the mentality of intrusion detection and the technology associated with it into an organization’s culture. It is important, therefore, to become familiar with and start using this technology as soon as possible to avoid falling behind even further. The alternative is to continue to function as the proverbial ostrich with its head beneath the sand. REFERENCES 1. Schultz, E.E. and Wack, J., Responding to Computer Security Incidents, in M. Krause and H.F. Tipton (Eds.), Handbook of Information Security, Boston: Auerbach, p. 53–68, 1996. 2. Garfinkel, S. and Spafford, G., Practical UNIX and Internet Security, O’Reilly & Associates, Inc., 1996. 3. Garfinkel, S. and Spafford, G., Web Security and Commerce, O’Reilly & Associates, Inc., 1997. 4. Van Wyk, K.R., Threats to DoD Computer Systems, paper presented at 23rd Information Integrity Institute Forum, (cited with author’s permission). 5. Power, Richard, Issues and Trends: 1999 CSI/FBI Computer Crime and Security Survey, Computer Security Journal, XV(2), Spring 1999 6. Mukherjee, B., Heberlein, L.T., and Levitt, K.N., Network Intrusion Detection, IEEE Network, 8(3), 26–41, 1994. 7. Crosbie, M. and Spafford, E.H., Defending a Computer System using Autonomous Agents, Proceedings of 18th National Information Systems Security Conference, p. 549–558, 1995. 8. Herringshaw, C., Detecting Attacks on Networks, IEEE Computer, 30(12), 16–17, 1997. 9. Cohen, F., Managing Network Security. Part 14: 50 Ways to Defeat Your Intrusion Detection System, Network Security, December, p. 11–14, 1997. Eugene Schultz can be contacted through both Global Integrity Corporation and Purdue University. Eugene Spafford can be contacted through Purdue University. © 1999 CRC Press LLC 10/99