CHAPTER 27

INTRUSION DETECTION AND INTRUSION PREVENTION DEVICES

Rebecca Gurley Bace

27.1 SECURITY BEHIND THE FIREWALL

27.1.1 What Is Intrusion Detection?

27.1.2 What Is Intrusion Prevention?

27.1.3 Where Do Intrusion Detection and Intrusion Prevention Fit in Security Management?

27.1.4 Brief History of Intrusion Detection

27.2 MAIN CONCEPTS

27.2.1 Process Structure

27.2.2 Monitoring Approach

27.2.3 Intrusion Detection Architecture

27.2.4 Monitoring Frequency

27.2.5 Analysis Strategy

27.3 INTRUSION PREVENTION

27.3.1 Intrusion Prevention System Architecture

27.3.2 Intrusion Prevention Analysis Strategy

27.4 INFORMATION SOURCES

27.4.1 Network Monitoring

27.4.2 Operating System Monitoring

27.4.3 Application Monitoring

27.4.4 Other Types of Monitoring

27.4.5 Issues in Information Sources

27.5 ANALYSIS SCHEMES

27.5.1 Misuse Detection

27.5.2 Anomaly Detection

27.5.3 Hybrid Approaches

27.5.4 Issues in Analysis

27.6 RESPONSE

27.6.1 Passive Responses

27.6.2 Active Responses: Man-in-the-Loop and Autonomous

27.6.3 Automated Response Goals

27.6.4 Investigative Support

27.6.5 Issues in Responses

27.7 NEEDS ASSESSMENT AND PRODUCT SELECTION

27.7.1 Matching Needs to Features

27.7.2 Specific Scenarios

27.7.3 Integrating IDS Products with Your Security Infrastructure

27.7.4 Deployment of IDS Products

27.8 CONCLUSION

27.9 FURTHER READING

27.10 NOTES

27.1 SECURITY BEHIND THE FIREWALL.

Even today, when asked how they would go about securing a computer or computer network, most people mention firewalls, the first widely accepted network security devices. As network security has become a nonoptional facet of system management, firewall mechanisms of various sorts have become a standard fixture in many networks.

As in any complex protection function, firewalls are necessary but not sufficient to completely protect enterprises from security breaches. Expecting firewalls to provide complete protection is tantamount to expecting guards at the gates of corporate campuses to prevent destructive behavior on the part of those operating vehicles within the facility. A lot can happen as traffic flows between hosts on internal networks; even items that appear benign to gatekeepers can be subverted to carry destructive payloads. Thus, most modern network security architectures include intrusion detection and intrusion prevention systems.

Intrusion detection systems (IDSs) are software or hardware systems that automate the monitoring of events occurring within a computer system or network. IDSs not only collect and synchronize records of these events; they also analyze them for signs of security violations. In strictest terms, vulnerability assessment systems (VASs) are a special class of IDSs in which the system relies on static inspection and attack reenactment to gauge a target system's exposure to specific security vulnerabilities. Intrusion prevention systems (IPSs) are another special class of IDSs in which the system is designed to react to certain detected attacks in a prespecified way.

In recent years, the realm of intrusion detection has broadened and deepened, driven by a number of factors. Security personnel, architectural and operational alike, have gained more experience with IDS technologies, working with commercial product providers to expand product capabilities and management schemes to fit current needs. As operational personnel have become more comfortable in using these systems, they have moved certain IDS capabilities to core network management venues. Finally, threats have evolved, driving needs that IDSs are uniquely qualified to address.

The evolution of IDS has resulted in some changes in nomenclature and tradecraft associated with it. One of these changes is that vulnerability assessment is considered a stand-alone discipline, driven by market needs that are often different from those influencing IDS. Another is that intrusion prevention has evolved as a stand-alone product category, offering the ability to respond automatically to certain classes of attacks. Thus, vulnerability assessment is treated as a separate topic in this Handbook (covered in Chapter 46), while both IDS and IPS are discussed in this chapter.

27.1.1 What Is Intrusion Detection?

Intrusion detection is the process of collecting information about events occurring in a computer system or network and analyzing them for signs of intrusions. Intrusions are defined as violations of security policy, usually characterized as attempts to affect the confidentiality, integrity, or availability of a computer or network. These violations can come from attackers accessing systems from the Internet or from authorized users of the systems who attempt to overstep their legitimate authorization levels or who use their legitimate access to the system to conduct unauthorized activity.

Intrusion detection systems are software or hardware products that automate this monitoring and analysis process.

27.1.2 What Is Intrusion Prevention?

Intrusion prevention is the process of coupling intrusion detection (as defined) with specified responses to certain detected intrusion scenarios. The triggering events can be viewed as a special subset of intrusions, and are often characterized in richer quantitative and qualitative terms than more generic IDS triggers. For example, a specific IPS might focus on monitoring certain types of network traffic. When the rate of a particular traffic type exceeds the anticipated threshold, the IPS would react in a prespecified way (e.g., limiting the rate of subsequent traffic of that type).

27.1.3 Where Do Intrusion Detection and Intrusion Prevention Fit in Security Management?

Intrusion detection is a necessary function in most system security strategies. It (and its offshoot, vulnerability assessment) is the primary security technology that supports the goal of auditability. “Auditability” is defined as the ability to independently review and examine system records and activities to:

  • Determine the adequacy of system controls
  • Ensure compliance with established security policy and operational procedures
  • Detect breaches in security
  • Recommend any indicated changes1

The presence of a strong audit function, in turn, enables and supports several vital security management functions, such as incident handling and system recovery. Intrusion detection also allows security managers a flexible means to accommodate user needs while retaining the ability to protect systems from certain types of threats.

There is some debate over whether IPS will displace IDS in the security management lineup. This displacement is unlikely for the time being, because of the binding between IDS and audit. As security operations become more tightly integrated with traditional system administration and operations, audit functions are necessary to support root cause analysis in diagnosing and addressing system failure. Badly tuned security devices can create problems in operations; it is important to be able to identify and correct such issues quickly and appropriately. Audit functions are also necessary to measure the effectiveness of security measures in mitigating security threats. Although it may appear that transparently detecting and blocking attacks is the optimal security process, such transparency—that is, lack of an audit trail—interferes with demonstrating effectiveness of security measures against real threats. In other words, in order for security management to justify a budget for security measures, it must be able to document and quantify the suitability and effectiveness of such measures. Therefore, regardless of the effectiveness of IPS in blocking attacks, IDS will likely always be necessary to support these audit functions. IDS provides the baseline information on the attack profiles and frequencies that allow managers to demonstrate the effectiveness and return on investment of preventive mechanisms. Without hard evidence of attack frequencies, security managers are left in the position of the man waving a dead chicken around his head while standing on a street corner. Asked why he is doing that, he answers, “To keep the flying elephants away.” “But there are no flying elephants,” protest the observers. “See? It works!” replies the lunatic. For more information on auditing, see Chapter 54 in this Handbook.

Although intrusion detection and intrusion prevention systems are necessary as system security functions, they are not sufficient to protect systems from all security threats. IDS and IPS must be a part of a more comprehensive security strategy that includes vulnerability assessment, security policy and procedural controls, network firewalls, strong identification and authentication mechanisms, access control mechanisms, file and link encryption, file integrity checking, physical security measures, and security training.

27.1.4 Brief History of Intrusion Detection

Intrusion detection is the automation of manual processes that originated in the earliest days of data processing. Joseph Wassermann of the Bell Telephone Company documented the origin of system and security audit as early as the mid-1950s, when the first computerized business system was being designed and implemented.2

Auditability was a key security feature from the earliest days of computer security, as proposed in J. P. Anderson's 1973 research study chartered by the U.S. Air Force.3 Anderson proposed a scheme for automating the review of security audit trails in 1980, in a research report considered by many to be the seminal work in intrusion detection.4 Dorothy Denning and Peter Neumann led a study of intrusion detection, conducted from 1984 to 1986, producing another seminal work in intrusion detection in 1986, in which Denning proposed a model for intrusion detection.5

An instantiation of Denning's intrusion detection model was prototyped as the Intrusion Detection Expert System (IDES) by a team at SRI International. IDES was a hybrid system that constructed statistical profiles of user behaviors as derived from operating system kernel audit logs and other system data sources. IDES also provided a rules-based expert system that allowed users to specify patterns of events to be flagged as intrusions.6 IDES and the Next Generation IDES (NIDES) system that followed it marked an era in which numerous intrusion detection research projects and prototype systems were developed, including Haystack (Haystack Labs and U.S. Air Force), NADIR (Los Alamos National Laboratory), Wisdom and Sense (Los Alamos National Laboratory and Oak Ridge National Laboratory), ISOA (PRC, Inc), TIM (Digital Equipment Corporation), ComputerWatch (AT&T), and Discovery (TRW, Inc).7

In the late 1980s, researchers at the University of California, Davis, designed the first network-based intrusion detection system (initially called the Network Security Monitor, but later renamed NID), which functioned much the same as many current commercial network-based intrusion detection products.8 A subsequent U.S. Air Force-funded research product, called the Distributed Intrusion Detection System (DIDS), explored coordinating network-based and host-based intrusion detection systems. DIDS was prototyped by teams at the University of California, Davis, Haystack Laboratories, and Lawrence Livermore National Laboratory.9

Intrusion prevention was proposed as a logical next step to intrusion detection almost from the start of intrusion detection research. Support for certain models of intrusion prevention grew when concerns regarding attacks on the TCP/IP network infrastructure (e.g., packet flooding and malformed packet attacks) grew in the mid- to late 1990s. Other types of IPS were proposed to deal with kernel-level hacks and information leakage issues.

27.2 MAIN CONCEPTS.

Several strategies used in performing intrusion detection serve to describe and distinguish specific intrusion detection systems. These affect the threats addressed by each system and often prescribe the environments in which specific systems should be used. As noted, intrusion prevention relies first on intrusion detection strategies; thus the differentiators will be highlighted as appropriate.

27.2.1 Process Structure.

Intrusion detection is defined as a monitoring and alarm generation process, and, as such, it can be described using a simple process model. This model is outlined here and will be used to illustrate the fundamental concepts of intrusion detection.

27.2.1.1 Information Sources.

The first stage of the intrusion detection process comprises one or more information sources, also known as event generators. Information sources for intrusion detection may be categorized by location: network, host, or application.

27.2.1.2 Analysis Engine.

Once event information is collected, it is passed to the next stage of the intrusion detection process, in which it is analyzed for symptoms of attack or other security problems.

27.2.1.3 Response.

When the analysis engine diagnoses attacks or security problems, information about these results is revealed via the response stage of the intrusion detection process. Responses span a wide spectrum of possibilities, ranging from simple reports or logs to automated responses that disrupt attacks in progress. The presence of these automated responses defines an intrusion prevention system.

27.2.2 Monitoring Approach.

The first major classifier used to distinguish intrusion detection systems is the monitoring approach of the system. Monitoring is the action of collecting event data from an information source and then conveying that data to the analysis engine.

The monitoring approach describes the perspective from which intrusion detection monitoring is performed. The primary monitoring approaches found in intrusion detection systems today are network based, host based, and application based.

27.2.3 Intrusion Detection Architecture.

Even in the early days of manual security audit, researchers noted that in order for audit information to be trusted, it should be stored and processed in an environment separate from the one monitored. This requirement has evolved to include most intrusion detection approaches, for three reasons:

  1. To keep an intruder from blocking or nullifying the intrusion detection system by deleting information sources
  2. To keep an intruder from corrupting the operation of the intrusion detector in order to mask the presence of the intruder
  3. To manage the performance and storage load that might result from running intrusion detection tasks on an operational system

In this architecture, the system running the intrusion detection system is called the host. The system or network being monitored is called the target.

27.2.4 Monitoring Frequency.

Another common descriptor for intrusion detection approaches is the timing of the collection and analysis of event data. This is usually divided between batch-mode (also known as interval-based) and continuous (also known as real-time) approaches.

In batch-mode analysis, the event data from the information source are conveyed to the analysis engine in a file or other block form. As the name suggests, the events corresponding to a particular interval of time are processed (and results provided to the user) after the intrusion has taken place. This model was the most common for early intrusion detection because system resources did not allow real-time monitoring or analysis.

In real-time analysis, event data from the information source are conveyed to the analysis engine as the information is gathered. The information is analyzed immediately, providing the user with the opportunity to respond to detected problems quickly enough to affect the outcome of the intrusion.

27.2.5 Analysis Strategy.

In intrusion detection, there are two prevalent analysis strategies, misuse detection and anomaly detection.

In misuse detection, the analysis engine filters event streams, matching patterns of activity that characterize a known attack or security violation. In anomaly detection, the analysis engine uses statistical or other analytical techniques to spot patterns corresponding to abnormal system use. Anomaly detection is based on the premise that intrusions significantly differ from normal system activity. In general, intrusion detection systems rely more heavily on anomaly detection and quantitative measures to detect and block attacks.

27.3 INTRUSION PREVENTION.

As discussed, IPSs are often considered a special case of IDS in which automated responses are specified. However, with the adoption of the first generation of network IPS products, additional specifications for IPSs have evolved in addition to those assigned to IDS.

27.3.1 Intrusion Prevention System Architecture.

As in intrusion detection, most IPSs separate the monitoring and analysis platform from the target platform being monitored. Additional differentiations are drawn between those IPSs that separate the monitoring and analysis platform from the response platform (these are labeled “stand-alone” IPSs) and those that integrate all the functions in a single unit, usually a firewall, network switch, or router (these are labeled “integrated” IPSs.)

27.3.2 Intrusion Prevention Analysis Strategy.

IPSs generally use the same structural approach to data analysis as IDS, but the nomenclature for the analysis strategies differs. IPS analysis schemes fall into two general categories, rate based and content based.

Rate-based IPS analysis makes the decision to block network traffic based on indicators of network load, as measured by statistics such as connect rates and connection counts. This category of analysis is especially useful for detecting packet flood distributed denial-of-service (DDoS) attacks.

Content-based IPS analysis makes the decision to block network traffic based on indicators of anomalous packets and specific content (often represented as IDS signatures.) This approach is useful for detecting malformed packet DDoS and other types of attacks not readily spotted by quantitative measures.10

27.4 INFORMATION SOURCES.

Information sources represent the first stage of the intrusion detection process. They provide event information from monitored systems upon which the intrusion detection process bases its decisions. Information sources encompass both raw event data (e.g., data collected directly from system audit and logging mechanisms) as well as data output by system management utilities (e.g., file integrity checkers, vulnerability assessment tools, network management systems, and even other intrusion detection systems). In this section, information sources for intrusion detection are classified by location: network, host, or application.

27.4.1 Network Monitoring.

The most common monitoring approach utilized in intrusion detection systems is network based. In this approach, information is gathered in the form of network packets, often using network interface devices set to promiscuous mode. (Such a device operating in promiscuous mode captures all network traffic accessible to it—usually on the same network segment—not just traffic addressed to it.) Other approaches for performing network-based monitoring include the use of spanning ports (specialized monitoring ports that allow capture of network traffic from all ports on a switch) on network switches or specialized Ethernet network taps (e.g., sniffers) to capture network traffic.

27.4.2 Operating System Monitoring.

Some monitors collect data from sources internal to a computer. These differ from network-based monitoring in the level of abstraction at which the data is collected. Host-based monitoring collects information from the operating system (OS) level of a computer. The most common sources of operating system–level data are operating system audit trails, which are usually generated within the OS kernel, and system logs, which are generated by OS utilities.

27.4.3 Application Monitoring.

Application-based monitoring collects information from running software applications. Information sources utilized in application-based approaches include application event logs and application configuration information.

Application-based information sources are steadily increasing in importance as systems complexity increases. The advent of object-oriented programming techniques introduces data object naming conventions that nullify much of an analyst's ability to make sense of file access logs. In this situation, the application level is the only place in the system in which one can “see” the data accesses at an appropriate level of abstraction likely to reveal security violations.

One special case of application-based monitoring comprises an entire product category in security. This type of system (sometimes called extrusion detection) monitors data transfers, looking for anomalies associated with data movement across policy boundaries. Such data monitoring is very popular as a compliance mechanism for enterprises dealing with consumer, financial, or other regulated data.

27.4.4 Other Types of Monitoring.

As noted, intrusion detection information sources are not limited to raw event data. In fact, allowing intrusion detection systems to operate on results from other systems often optimizes the quality of the intrusion detection system's results. When the data are provided by other parts of the system security infrastructure (e.g., network firewalls, file integrity checkers, virus scanners, or other intrusion detection systems), the sensitivity and reliability of the intrusion detection system's results can increase significantly.

27.4.5 Issues in Information Sources.

There are several issues involving information sources for intrusion detection. The major ones that have persisted over the history of intrusion detection include:

  • In host-based systems, there must be a balance between collecting enough information to accurately portray security violations and collecting so much information that the collection process cripples the monitored system.
  • The fidelity of the intrusion detection process is dependent not only on collecting the appropriate information but on collecting it from appropriate vantage points within the monitored system or network.
  • If the IDS is expected to produce event records that will be used to support legal processes, the system must collect and handle event information in a way that complies with legal rules of evidence.
  • The information collected by IDSs often includes information of a sensitive nature. This information must be secured and handled in a way that complies with legal and ethical standards.

27.5 ANALYSIS SCHEMES.

Once information sources and sensors are defined and placed, the information so gathered must be analyzed for signs of attack. The analysis engine serves this purpose in intrusion detection, accepting event data from the information source and examining it for symptoms of security problems. As mentioned earlier, intrusion detection systems typically provide analysis features that fall into two categories, misuse detection and anomaly detection.

27.5.1 Misuse Detection.

Misuse detection is the filtering of event streams for patterns of activity that reflect known attacks or other violations of security policy. Misuse detectors use various pattern-matching algorithms, operating on large databases of attack patterns or signatures. Most current commercial intrusion detection systems support misuse detection.

Misuse detection presumes that there is a clear understanding of the security policy for the system, which can be expressed in patterns corresponding to desirable activity and undesirable activity. Therefore, signatures can be described in terms of “this should never happen” as well as “only this should ever happen.” Signatures also can range from simplistic atomic (one-part) checks to rather complex composite (multipart) checks. An example of an atomic check is a buffer overflow signature, in which one looks for a particular command, followed by a string exceeding a particular length. An example of a composite check is a race condition signature, in which a series of carefully timed commands occur. Signatures are gathered and structured in some way to optimize the filtering of event data against them.

The next requirement for misuse detection is that the event data collected from information sources be encoded in a way that allows it to be matched against the signature data. There are various ways of doing this, ranging from regular expression matching (sometimes called “dirty word” matching) to complex coding schemes involving state diagrams and Colored Petri Nets. State diagrams are a graphical scheme for modeling intrusions. They express intrusions in terms of states, represented by nodes or circles, and transitions, represented by lines or arcs. Colored Petri Nets are an extension of the state diagram technique that add colored tokens, which occupy state nodes, and whose color expresses information about the context of the state.

In some IDSs and content-based IPSs, significant resources are devoted to identifying malformed network packets, especially those in which the format of the content of the packet does not match the format of the service (e.g., SMTP) or of the associated port number of the packet. This malformed packet scheme represents one of the major categories of DDoS attacks, which seek to deny network access to legitimate users.

27.5.2 Anomaly Detection.

Anomaly detection is the analysis of system event streams, characterizing them using statistical and other classification techniques in order to find patterns of activity that appear to deviate from normal system operation. This approach is based on the premise that attacks, and other security policy violations, are a subset of abnormal system events.

Several common techniques are used in anomaly detection:

  • Quantitative analysis. Most modern systems that use anomaly detection provide quantitative analysis, in which rules and attributes are expressed in numeric form. The most common forms of quantitative analysis are triggers and thresholds, in which system attributes are expressed as counts occurring during some time interval, with some level defined as permissible. Triggers and thresholds can be simple, in which the permissible level is constant, or heuristic, in which the permissible level is adapted to observed levels. Network intrusion prevention systems targeting DDoS attacks often use heuristic triggers and thresholds to characterize the normal bandwidth loads, connect rates, and connection counts in network traffic.
  • Statistical analysis. Most early anomaly detection systems used statistical techniques to identify abnormal data. In statistical analysis, profiles are built for each user and system resource, and statistics are calculated for a variety of user and resource attributes for a particular interval of time (usually a “session,” defined as the time elapsed between login and logout).
  • Learning techniques. There has been a great deal of research interest in using various learning techniques, such as neural networks and fuzzy logic, in performing anomaly detection. Despite encouraging results, there remain many practical impediments to using these techniques in production environments. The practical impediments arise due to the mismatch between those attributes that are suitable for characterization by neural networks and fuzzy logics and those attributes that are actionable by operational personnel and systems. The value of using neural networks (most of them utilizing fuzzy logic) is that they can characterize and recognize very subtle signs of trouble in systems. This is of value in situations where the problems being detected are not subtle. However, in security breaches, the difference between normal behavior and security attack is often influenced by the system context; in these scenarios, few, if any, neural networks can provide insights regarding how they reached their decisions regarding the suspicious events on which they trigger. A security person in an operational context usually requires this sort of insight in order to devise an appropriate reaction to the detected intrusion.
  • Advanced techniques. Anomaly detection as applied to intrusion detection remains an active research area. Recent research efforts include the application of such advanced analytic techniques as genetic algorithms, data mining, autonomous agents, and immune system approaches to the problem of recognizing new attacks and security violations. Again, these techniques have not yet been widely fielded in commercial IDSs, although they have appeared in special purpose products.

27.5.3 Hybrid Approaches.

There are significant issues associated with both misuse detection and anomaly detection approaches to event analysis for intrusion detection; however, combining both approaches provides considerable benefit. The anomaly detection engine can allow the IDS to detect new or unknown attacks or policy violations. This is especially valuable when the target system protected by the IDS is highly visible on the Internet or other high-risk network. In IPS, anomaly detection applied to network traffic attributes allows one of the only means to deal with packet-flood DDoS attacks, a growing concern in today's networks.

The misuse detection engine, in turn, protects the integrity of some anomaly detection engines by assuring that a patient adversary cannot gradually change behavior patterns over time in order to retrain the anomaly detector to accept attack behavior as normal. Thus the misuse detector mitigates a significant deficiency of anomaly detection for security purposes.

27.5.4 Issues in Analysis.

Here are a few of the many issues in intrusion detection analysis:

  • Misuse detection systems, although very effective at detecting those scenarios for which detection signatures have been defined, cannot detect new attacks.
  • Anomaly detection systems are capable of detecting new attacks but usually have false positive rates so high that users often ignore the alarms they generate.
  • Anomaly detection systems that rely on artificial intelligence (AI) techniques often suffer from a lack of adequate training data. (Data are used to define the detector's logic for distinguishing “normal” from “abnormal” events.)
  • Malefactors with access privileges to the system, while anomaly-detection systems are being trained, can covertly teach the system to accept specific patterns of unauthorized activities as normal. Later, the anomaly-detection systems will ignore the actual misuse.

27.6 RESPONSE.

The final stage of intrusion detection, response, consists of the actions taken in response to the security violations detected by the IDS. Responses are divided into passive and active options. The difference between passive and active responses is whether the user of the IDS, or the system itself, is responsible for reacting to the detected violations. As discussed, the former option is associated with classic IDS; the latter is associated with IPS.

27.6.1 Passive Responses.

When passive responses are selected, the IDS simply provides the results of the detection process to the user, who must then act on these results, independent of the IDS. In this option, the user has total control over the response to the detected problem. In some IDSs, the information provided to the user regarding detection results can be divided into alarms and reports.

27.6.1.1 Alarms.

Alarms are messages that are communicated immediately to users. Commercial IDSs use a variety of channels for conveying these alarms to security personnel. The most common is a message screen or icon written to the IDS control console. Other alarm channels include pagers, e-mail, wireless messaging, and network management system traps.

27.6.1.2 Reports.

Reports are messages or groups of messages that are generated on a periodic basis. They typically document events that have happened in the past and often include aggregate figures and trends information. Many commercial IDS products support extensive reporting features, allowing a user to set up automatic report generation with several versions, each targeting a different level of management.

27.6.2 Active Responses: Man-in-the-Loop and Autonomous.

When an IDS provides active response options, these usually fall into two categories. The first requires the IDS to take action, but with the active involvement of an interactive user. This option is sometimes called a man-in-the-loop mechanism. This option is preferred for critical systems, as it allows an operator to track an attacker or intervene in a sensitive situation in a flexible, exacting way.

The other active response option, which usually defines an IPS, provides for preprogrammed actions taken automatically by the system with no human involvement. The automated response option is required when dealing with certain sorts of automated attack tools (viruses or worms) or DDoS attacks. These attacks proceed at machine speed and therefore are outside the reach of a human-controlled manual intervention. As automated and DDoS attacks are the tool of choice for online extortionists, the number of IPSs fielded in commercial networks has grown rapidly over the past few years.

27.6.3 Automated Response Goals.

Automated responses support three categories of response goals:

  1. Collecting more information about the intrusion or intruder
  2. Amending the environment (e.g., changing a switch or router setting to deny access to an intruder)
  3. Taking action against the intruder

Although the last of these groups, sometimes labeled strike back or hack back, occasionally is discussed in security circles, the other options are far more productive in most situations. At this time, taking action against the intruder is considered inappropriate in almost all situations, and should be undertaken only with the advice and counsel of a legal authority.

Amending the environment and collecting more information can occur in either stand-alone or integrated fashions.

27.6.3.1 Stand-alone Responses.

Some automated responses are designed to use features that fall entirely within the intrusion detection system. For instance, an intrusion detection system may have special detection rules, more sensitive or detailed than those provided in normal modes of operation. In a stand-alone adaptive response, the IDS would use the more sensitive rules when evidence of the preamble of an attack is detected. This allows the IDS to turn sensitivity levels up only when the additional detection capabilities are needed, so that false alarm rates are reduced.

27.6.3.2 Integrated Responses.

The response option often considered the most productive is that of using integrated measures that change the system settings to block the attacker's actions. Such responses can affect the configuration of the target system, the IDS/IPS host, or the network on which both reside. In the first case, the IDS/IPS might change the settings of the logging mechanisms on the target host to increase the amount or type of information collected. The IDS also might change its analysis engine so that more subtle signs of attack are recognized. In another response option reflected in commercial products, the IDS responds to an observed attack signature by querying the target system to determine whether it is vulnerable to that specific attack. Should the vulnerability be present, the IDS directs the target system to correct that vulnerability. In effect, this process provides the target system with an immune function and permits it to “heal” itself, either blocking an attack outright or else interactively repairing any damage done in the course of the attack. Finally, some systems may use special-purpose decoy systems, called honey pots or padded cells, as diversions for attackers. When these systems are provided, the IDS may be configured to divert attackers into the decoy environments.

In a special case of integrated response seen in many commercial IPS offerings, the IPS is integrated with a switch or router. When an attack is detected, the switch or router is reconfigured on the fly to block the source of the attack. Other IPS offerings that are designed to deal with DDoS attacks use multiple IDS/IPSs to detect the attacks, then manipulate the switching fabric11 to divert the attacks from the targeted systems. Over time, such IPS features will likely be integrated with network infrastructure devices, as many firewall features already have done.

27.6.4 Investigative Support.

Although the primary design objective of intrusion detection systems is detecting attacks and other possibly problematic system events, information collected and archived by IDSs also can support those charged with investigating security incidents. This functional requirement may levy additional technical requirements on IDSs. For instance, if investigators plan to use IDS monitoring features to perform a targeted surveillance of an attack in progress, it is critical that the information sources be “silent,” so that adversaries are not aware that they are being monitored. Furthermore, the IDS monitors must be able to convey information to the investigators through a trustworthy, secure channel. Finally, the IDS itself must be under the control of the investigators or other trusted parties; otherwise, the adversaries may mask their activities by selectively spoofing information sources. Perhaps the most important thing for investigators to remember about IDSs is that the information provided should be corroborated by other information sources (e.g., network infrastructure device logs), not necessarily accepted at face value.

27.6.5 Issues in Responses.

As in information sources and analysis strategies, certain issues associated with IDS response features have endured over the history of intrusion detection. The principal issues are:

  • Users' needs for IDS response capabilities are as varied as the users themselves. In some systems environments, the IDS response messages are monitored around the clock, with real-time action taken by system administrators based on IDS alarms. In other environments, users may use IDS responses, in the form of reports, as a metric to indicate the threat environment in which a particular system resides. It is important to consider the specific needs of the user when selecting an IDS.
  • Given false-positive error rates for IDSs, response options must be tunable by users. Otherwise, users will simply tune out the IDS responses. This nullifies the value of the IDS.
  • When the IDS provides automated responses to detected problems, there is a risk of the IDS itself launching an effective denial-of-service attack against the system it is protecting. For instance, suppose an IDS is configured with rules that tell it “upon detecting an attack from a given IP address, direct the firewall to block subsequent access from that IP address.” An attacker, knowing this IDS is so configured, can launch an attack with a forged IP source address that appears to come from a major customer or partner of the organization. The IDS will recognize the attack and then block access from that organization for some period of time, effecting a denial of service.

27.7 NEEDS ASSESSMENT AND PRODUCT SELECTION.

The value of intrusion detection products within an organization's security strategy is optimized by a thorough needs assessment. These needs and security goals can be used to guide the selection of products that will enhance the security stance of the organization.

27.7.1 Matching Needs to Features.

The needs most often addressed by intrusion detection and intrusion prevention systems include:

  • Prevention of problem behaviors by increasing the risk of discovery and punishment for system attackers.
  • Detection of security violations not prevented (or even, in some cases, not preventable) by other security measures.
  • Documentation of the existing level of threat to an organization's computer systems and networks.
  • Detection and, where possible, mitigation of attack preambles. (These include activities such as network probes, port scans, and other such “doorknob rattling.”)
  • Diagnosis of problems in other elements of the security infrastructure (i.e., malfunctions or faulty configurations).
  • Granting system security personnel the ability to test the security effects of maintenance and upgrade activities on the organizational networks.
  • Providing information about those violations that do take place, enabling investigators to determine and correct the root causes.
  • Providing evidence of compliance with a given regulatory requirement for information protection. This represents a significant need for members of various regulated industries, such as banking and health care.

Regardless of which of these specific needs are relevant to the user, it is important to consider the ability of the intrusion detection system to satisfy the needs of the specific environment in which it is installed. A critical part of this determination is considering whether the intrusion detection system has the ability to monitor the specific information sources available in the target environment. What is even more important is whether the organizational security policy translates into a monitoring and detection policy that can be used to configure the IDS (or in the case of an IPS, a monitoring, detection, and response policy.) The structure of the security policy is especially critical to the success of an IPS.

27.7.2 Specific Scenarios.

There is no universally applicable description for computer networks or the IDSs that protect them. There are, however, some common scenarios, given current trends in networking and system usage.

A popular justification for using IDSs early in an organization's security life cycle is to establish the threat level for a given network enclave. Network-based IDSs often are used for this purpose, with monitors placed outside the organizational firewall. Those who are responsible for winning management support for security efforts often find this use of IDSs to be quite helpful.

Many organizations use IDSs to protect Web servers. In this case, the nature of the interactions that the Web server has with users will affect the selection and configuration of the IDS. Most Web servers serve two types of functions: (1) informational (e.g., Web servers that support simple HTTP and FTP queries from users) and (2) transactional (e.g., Web servers that allow user interaction beyond simple HTTP or FTP traffic). Transactional Web servers are usually more difficult to monitor than informational servers, as the range of interactions between users and servers is wider. For critical transactional Web servers, security managers may wish to consider multiple IDSs, monitoring the servers at multiple levels of abstraction (i.e., application, host, and network).

The third scenario involves organizations that wish to use IDSs as additional protection for specific portions of their networked systems. An example of this is the medical organization that wishes to protect the patient record database systems from privacy breaches. In this situation, as in the Web server example just given, it may be advisable to use multiple IDSs, monitoring interactions at multiple levels of abstraction. The output of these multiple systems can be synchronized and inconsistencies noted for a reliable indication of threat levels. Another example that is increasingly common is the organization that is concerned about wireless connectivity. In this case, WiFi monitoring products are commercially available, with information collection and monitoring features that are similar to those of classic IDSs.

In recent years, the expanding use of wireless local area networks (WLANs) in buildings and campuses has stimulated the development of wireless intrusion detection and prevention systems (WIDPSs). The basic principles are the same as for other IDSs and IPSs, with the addition of an interesting wrinkle: The WIDPSs are often used to discover unauthorized access points installed on an organization's WLANs by rogue employees or by intruders. Karen Scarfone and Peter Mell, in their February 2007 edition of NIST SP 800-94, point out that WIDPS sensors should be placed in areas where there should be no wireless network activity. Some security managers walk through and drive around their facilities with WIDPS tools on their laptop computers to identify unauthorized access points. However, completely passive eavesdropping on WLAN traffic cannot be detected.12

In extensive networks, should the security architect decide to layer multiple IDSs and IPSs, a security event monitor/security information manager (SIM/SEM) may be required. Such a system would be necessary to consolidate and integrate the results of each IDS/IPS into a coherent set of conclusions.

27.7.3 Integrating IDS Products with Your Security Infrastructure.

As mentioned, an IDS is not a substitute for a firewall, virtual private network, identification and authentication package, or any other security point product. However, an IDS can improve the quality of protection afforded by the other point products by monitoring their operation, noting signs of malfunction or circumvention. Furthermore, an IPS can interact in concert with the rest of the point products to help block an attack in progress.

27.7.4 Deployment of IDS Products.

The first generations of IDS installations have yielded some insights associated with deployment of IDSs. The key points include the location of sensors, scheduling the integration of IDSs, adjusting alarm settings, and outsourcing IDS/IPS services.

27.7.4.1 Location of Sensors.

There are four general locations for IDS sensors:

  1. Outside the main organizational firewall
  2. In the network DMZ (inside the main firewall, but outside the internal firewalls)
  3. Behind internal firewalls
  4. In critical subnets, where critical systems and data reside

As mentioned, IDS sensors placed outside the main organizational firewall are useful for establishing the level of threat for a given network. Sensors placed within the DMZ13 can monitor for penetration attempts targeting Web servers. IDSs monitors for internal attacks are placed on internal network segments, behind internal firewalls. And for critical subnets, IDS sensors usually are placed at the choke points at which the subnets are connected to the rest of the corporate network. In the case of wireless networking, specialized IPS devices serve to discover and report unauthorized access to networks via WLAN access points or open software access points, through misconfigured WLAN interfaces on laptops and other WLAN devices. These IPS devices are usually placed behind firewalls and distributed across the physical space occupied by the organization and its users.

27.7.4.2 IDS Integration Scheduling.

Early generations of intrusion detection products proved that integration processes must not be rushed. IDSs still rely on operator interactions to screen out false alarms and to act on legitimate alarms. Hence it is critical that the processes provide adequate time for operational personnel to learn the behavior of the IDS on target systems, developing a sense of how the IDS interoperates with particular system components in different situations. This wisdom applies even more to IPS installation, where a miscue in specifying a response can have disastrous effects on the function of critical networks.

27.7.4.3 Alarm Settings.

IDSs have significant false alarm rates, with false positive rates as high as 80 percent in some situations. Many knowledgeable IDS integrators advise that alarms be suspended for a period of weeks, even months, as operators gain familiarity with the IDS and target systems. It is especially wise to delay activation of automated responses to attacks until operators and system administrators are familiar with the IDS and have tuned it to the target environment.

27.7.4.4 Outsourcing of IDS/IPS.

Any discussion of IDS and IPS strategies would be incomplete without mention of outsourcing these security services. There are significant advantages associated with this approach, especially in enterprises too small to afford an extensive security staff. As in other areas of IT outsourcing, one must have an extremely clear idea of the specific security and operational goals desired in order for this approach to be effective. A clearly worded security policy that reflects current concerns is essential. The advantages of outsourcing are many: Managed security service providers usually have considerable experience in dealing with IDS and IPS equipment, their staffs are often well trained and experienced in the use of the equipment, monitoring personnel are usually in attendance around the clock, and contract terms often include specific levels of service agreements.

In the words of a wise CISO, “outsourcing isn't offloading.” That means that out-sourcing security functions does not relieve you of the responsibility for system security. It also means that you must exercise due diligence in selecting the service provider, tasking and managing it, and monitoring it to ensure that your policy goals are being well served by the provider.

27.8 CONCLUSION.

Intrusion detection and intrusion prevention are valuable additions to system security suites, allowing security managers to spot, and sometimes block, those security violations that inevitably occur despite the placement of preventive security measures. Although current commercial products are imperfect, they serve to recognize many common intrusion types, in many cases quickly enough to allow security personnel and IPSs to block damage to systems and data. Furthermore, as research and development in intrusion detection and prevention continues, the quality and capabilities of available IDSs and IPSs will steadily improve.

27.9 FURTHER READING

Crosbie, M., and E. H. Spafford. “Defending a Computer System Using Autonomous Agents.” Proceedings of the 18th National Information Systems Security Conference. Baltimore, MD, October 1995.

Jackson, K. A., D. DuBois, and C. Stallings. “An Expert System Application for Network Intrusion Detection.” Proceedings of the 14th National Computer Security Conference. Washington, DC, October 1991.

Flegel, U. Privacy-Respecting Intrusion Detection. New York: Springer, 2007.

Hämmerli, B., and R. Sommer, eds. Detection of Intrusions and Malware, and Vulnerability Assessment: 4th International Conference, DIMVA 2007 Lucerne, Switzerland, July 12-13, 2007 Proceedings. New York: Springer, 2007.

Kumar, Sandeep, and E. Spafford. “A Pattern Matching Model for Misuse Intrusion Detection.” Proceedings of the 17th National Computer Security Conference. Baltimore, MD, October 1994.

Lunt, T., et al. “A Real-Time Intrusion Detection Expert System (IDES).” Computer Science Lab, SRI International, Menlo Park, CA, May 1990.

Mukherjee, B., L. T. Heberlein, and K. N. Levitt. “Network Intrusion Detection,” IEEE Network 8, No. 3 (May–June 1994).

Paxson, V. “Bro: A System for Detecting Network Intruders inReal Time.” 7th USENIX Security Symposium, San Antonio, TX, January 1998.

Porras, P., and P. Neumann. “EMERALD: Event Monitoring Enabling Responses to Anomalous Live Disturbances.” Proceedings of 20th National Information System Security Conference. Baltimore, MD, October 1997.

Scarfone, K. and P. Mell. Guide to Intrusion Detection and Prevention Systems (IDPS). NIST Special Publication 800-94. Gaithersburg, MD: National Institute of Standards and Technology, February 2007. Available: http://csrc.nist.gov/publications/nistpubs/800-94/SP800-94.pdf.

Schaefer, M., et al. “Auditing: A Relevant Contribution to Trusted Database Management Systems.” Proceedings of the 5th Annual Computer Security Applications Conference. Tucson, AZ, December 1989.

Shostack, A., and S. Blake. “Towards a Taxonomy of Network Security Assessment Techniques.” Proceedings of 1999 Black Hat Briefings. Las Vegas, NV, July 1999.

27.10 NOTES

1. See the Telecom Glossary 2000 from the American National Standards Institute, Inc., www.its.bldrdoc.gov/projects/telecomglossary2000.

2. J. J. Wassermann, “The Vanishing Trail,” Bell Telephone Magazine 47, No. 4 (July/August 1968).

3. J. P. Anderson, “Computer Security Technology Planning Study Volume II,” ESD-TR-73-51, Electronic Systems Division, Air Force Systems Command, Hanscom Field, Bedford, MA 01730 (October 1972).

4. J. P. Anderson, Computer Security Threat Monitoring and Surveillance (Fort Washington, PA: James P. Anderson Co. April 1980).

5. D. Denning, “An Intrusion Detection Model,” Proceedings of the 1986 IEEE Symposium on Security and Privacy (Washington, DC: IEEE Computer Society Press, 1986).

6. T. Lunt et al., “A Real-Time Intrusion Detection Expert System (IDES),” Computer Science Lab, SRI International, May 1990.

7. B. Mukherjee, L. T. Heberlein, and K. N. Levitt, “Network Intrusion Detection,” IEEE Network 8, No. 3 (May–June 1994).

8. L. T. Heberlein, K. N. Levitt, and B. Mukherjee, “A Network Security Monitor,” Proceedings of the 1990 IEEE Symposium on Research in Security and Privacy, Oakland, CA, May 1990.

9. S. Snapp et al., “DIDS (Distributed Intrusion Detection System) Motivation, Architecture, and an Early Prototype,” Proceedings of the 14th National Computer Security Conference, Washington, DC, October 1991.

10. “IPS Quadrant,” Information Security Magazine (July 2004); http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss426_art880,00.html.

11. A. Freedman, Computer Desktop Encyclopedia, v21.1, 2008 (www.computerlanguage.com) provides this definition: “Switch fabric—(1) The inter-connect architecture used by a switching device, which redirects the data coming in on one of its ports out to another of its ports. The word ‘fabric’ comes from the resulting criss-crossed lines when all the inputs on a switch with hundreds of ports are connected to all possible outputs. (2) The combination of interconnected switches used throughout a campus or large geographic area, which collectively provide a routing infrastructure.”

12. K. Scarfone and P. Mell, Guide to Intrusion Detection and Prevention Systems (IDPS). NIST Special Publication 800-94 (Gaithersburg, MD: National Institute of Standards and Technology, February 2007); http://csrc.nist.gov/publications/nistpubs/800-94/SP800-94.pdf, pp. 5–12 to 5–13.

13. The DMZ is a reserved area in some network architectures, in which Web servers are often placed, separated from the Internet by one firewall system and separated from the internal corporate network by another firewall.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.116.12.230