NIST SP 800-94 日本語訳

Special Publication 800-94

Karen Scarfone Peter Mell

NIST Special Publication 800-94

Recommendations of the National Institute of Standards and Technology

Karen Scarfone Peter Mell

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

February 2007

U.S. Department of Commerce

Carlos M. Gutierrez, Secretary

Technology Administration

Robert C. Cresanti, Under Secretary of Commerce for Technology

National Institute of Standards and Technology

William Jeffrey, Director

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-94 Natl. Inst. Stand. Technol. Spec. Publ. 800-94, 127 pages (February 2007)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

Acknowledgements

The authors, Karen Scarfone and Peter Mell of the National Institute of Standards and Technology (NIST), wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content. The authors would like to acknowledge John Connor, Tim Grance, Anoop Singhal, and Murugiah Souppaya of NIST; Michael Gerdes, Ralph Martins, Angela Orebaugh, and Mike Zeberlein of Booz Allen Hamilton; and Steve Sharma of Project Performance Corporation for their keen and insightful assistance throughout the development of the document. The authors particularly want to thank Rebecca Bace of KSR for her careful review of the publication and for her work on the predecessor publication, NIST Special Publication 800-31, Intrusion Detection Systems. The authors would also like to express their thanks to security experts Andrew Balinsky (Cisco Systems), Anton Chuvakin (LogLogic), Jay Ennis (Network Chemistry), John Jerrim (Lancope), and Kerry Long (Center for Intrusion Monitoring and Protection, Army Research Laboratory), as well as representatives from the Department of State and Gartner, for their particularly valuable comments and suggestions. Additional acknowledgements will be added to the final version of the publication.

Trademarks

All product names are registered trademarks or trademarks of their respective companies.

Executive Summary

Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents, which are violations or imminent threats of violation of computer security policies, acceptable use policies, or standard security practices. Intrusion prevention is the process of performing intrusion detection and attempting to stop detected possible incidents. Intrusion detection and prevention systems (IDPS)¹ are primarily focused on identifying possible incidents, logging information about them, attempting to stop them, and reporting them to security administrators. In addition, organizations use IDPSs for other purposes, such as identifying problems with security policies, documenting existing threats, and deterring individuals from violating security policies. IDPSs have become a necessary addition to the security infrastructure of nearly every organization.

IDPSs typically record information related to observed events, notify security administrators of important observed events, and produce reports. Many IDPSs can also respond to a detected threat by attempting to prevent it from succeeding. They use several response techniques, which involve the IDPS stopping the attack itself, changing the security environment (e.g., reconfiguring a firewall), or changing the attack’s content.

This publication describes the characteristics of IDPS technologies and provides recommendations for designing, implementing, configuring, securing, monitoring, and maintaining them. The types of IDPS technologies are differentiated primarily by the types of events that they monitor and the ways in which they are deployed. This publication discusses the following four types of IDPS technologies:

Implementing the following recommendations should facilitate more efficient and effective intrusion detection and prevention system use for Federal departments and agencies.

Organizations should ensure that all IDPS components are secured appropriately.

Securing IDPS components is very important because IDPSs are often targeted by attackers who want to prevent the IDPSs from detecting attacks or want to gain access to sensitive information in the IDPSs, such as host configurations and known vulnerabilities. IDPSs are composed of several types of components, including sensors or agents, management servers, database servers, user and administrator consoles, and management networks. All components’ operating systems and applications should be kept fully up-to-date, and all software-based IDPS components should be hardened against threats. Specific protective actions of particular importance include creating separate accounts for each IDPS user and administrator, restricting network access to IDPS components, and ensuring that IDPS management communications are protected appropriately, such as encrypting them or transmitting them over a physically or logically separate network. Administrators should maintain the security of the IDPS components on an ongoing basis, including verifying that the components are functioning as desired, monitoring the components for security issues, performing regular vulnerability assessments, responding appropriately to vulnerabilities in the IDPS components, and testing and deploying IDPS updates. Administrators should also back up configuration settings periodically and before applying updates to ensure that existing settings are not inadvertently lost.

Organizations should consider using multiple types of IDPS technologies to achieve more comprehensive and accurate detection and prevention of malicious activity.

The four primary types of IDPS technologies—network-based, wireless, NBA, and host-based—each offer fundamentally different information gathering, logging, detection, and prevention capabilities. Each technology type offers benefits over the others, such as detecting some events that the others cannot and detecting some events with significantly greater accuracy than the other technologies. In many environments, a robust IDPS solution cannot be achieved without using multiple types of IDPS technologies. For most environments, a combination of network-based and host-based IDPS technologies is needed for an effective IDPS solution. Wireless IDPS technologies may also be needed if the organization determines that its wireless networks need additional monitoring or if the organization wants to ensure that rogue wireless networks are not in use in the organization’s facilities. NBA technologies can also be deployed if organizations desire additional detection capabilities for denial of service attacks, worms, and other threats that NBAs are particularly well-suited to detecting. Organizations should consider the different capabilities of each technology type along with other cost-benefit information when selecting IDPS technologies.

Organizations planning to use multiple types of IDPS technologies or multiple products of the same IDPS technology type should consider whether or not the IDPSs should be integrated.

Direct IDPS integration most often occurs when an organization uses multiple IDPS products from a single vendor, by having a single console that can be used to manage and monitor the multiple products. Some products can also mutually share data, which can speed the analysis process and help users to better prioritize threats. A more limited form of direct IDPS integration is having one IDPS product provide data for another IDPS product (but no data sharing in the opposite direction). Indirect IDPS integration is usually performed with security information and event management (SIEM) software, which is designed to import information from various security-related logs and correlate events among them. SIEM software complements IDPS technologies in several ways, including correlating events logged by different technologies, displaying data from many event sources, and providing supporting information from other sources to help users verify the accuracy of IDPS alerts.

Before evaluating IDPS products, organizations should define the requirements that the products should meet.

Evaluators need to understand the characteristics of the organization’s system and network environments, so that a compatible IDPS can be selected that can monitor the events of interest on the systems and/or networks. Evaluators should articulate the goals and objectives they wish to attain by using an IDPS, such as stopping common attacks, identifying misconfigured wireless network devices, and detecting misuse of the organization’s system and network resources. Evaluators should also review their existing security policies, which serve as a specification for many of the features that the IDPS products need to provide. In addition, evaluators should understand whether or not the organization is subject to oversight or review by another organization. If so, they should determine if that oversight authority requires IDPSs or other specific system security resources. Resource constraints should also be taken into consideration by evaluators. Evaluators also need to define specialized sets of requirements for the following:

When evaluating IDPS products, organizations should consider using a combination of several sources of data on the products’ characteristics and capabilities.

Common product data sources include test lab or real-world product testing, vendor-provided information, third-party product reviews, and previous IDPS experience from individuals within the organization and trusted individuals at other organizations. When using data from other parties, organizations should consider the fidelity of the data because it is often presented without an explanation of how it was generated. There are several major challenges in performing in-depth hands-on IDPS testing, such as the considerable resources needed and the lack of a standard test methodology and test suites, which often make it infeasible. However, limited IDPS testing is helpful for evaluating security requirements, performance, and operation and maintenance capabilities.

This page has been left blank intentionally.

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

This publication seeks to assist organizations in understanding intrusion detection system (IDS) and intrusion prevention system (IPS) technologies and in designing, implementing, configuring, securing, monitoring, and maintaining intrusion detection and prevention systems (IDPS). It provides practical, real-world guidance for each of four classes of IDPS products: network-based, wireless, network behavior analysis, and host-based. The publication also provides an overview of complementary technologies that can detect intrusions, such as security information and event management software and network forensic analysis tools. It focuses on enterprise IDPS solutions, but most of the information in the publication is also applicable to standalone and small-scale IDPS deployments. This publication replaces NIST Special Publication 800-31, Intrusion Detection Systems.

This document has been created for computer security staff and program managers, computer security incident response teams (CSIRT), and system and network administrators who are responsible for managing or monitoring IDPS technologies. This document does not assume that the reader has previous experience with any IDPS technologies, but it does assume that the reader has experience with information security.

The remainder of this document is organized into the following nine major sections:

The document also contains appendices with supporting material. Appendices A and B contain a glossary and acronym list, respectively. Appendix C lists print resources and online tools and resources that may be useful references for gaining a better understanding of IDPSs. Appendix D contains an index for the publication.

Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents, which are violations or imminent threats of violation of computer security policies, acceptable use policies, or standard security practices. Incidents have many causes, such as malware (e.g., worms, spyware), attackers gaining unauthorized access to systems from the Internet, and authorized users of systems who misuse their privileges or attempt to gain additional privileges for which they are not authorized. Although many incidents are malicious in nature, many others are not; for example, a person might mistype the address of a computer and accidentally attempt to connect to a different system without authorization.

An intrusion detection system (IDS) is software that automates the intrusion detection process. An intrusion prevention system (IPS) is software that has all the capabilities of an intrusion detection system and can also attempt to stop possible incidents. This section provides an overview of IDS and IPS technologies as a foundation for the rest of the publication. It first explains how IDS and IPS technologies can be used. Next, it describes the key functions that IDS and IPS technologies perform and the detection methodologies that they use. Finally, it provides an overview of the major classes of IDS and IPS technologies.

IDS and IPS technologies offer many of the same capabilities, and administrators can usually disable prevention features in IPS products, causing them to function as IDSs. Accordingly, for brevity the term intrusion detection and prevention systems (IDPS) is used throughout the rest of this guide to refer to both IDS and IPS technologies.² Any exceptions are specifically noted.

IDPSs are primarily focused on identifying possible incidents. For example, an IDPS could detect when an attacker has successfully compromised a system by exploiting a vulnerability in the system. The IDPS could then report the incident to security administrators, who could quickly initiate incident response actions to minimize the damage caused by the incident.³ The IDPS could also log information that could be used by the incident handlers.⁴ Many IDPSs can also be configured to recognize violations of security policies. For example, some IDPSs can be configured with firewall ruleset-like settings, allowing them to identify network traffic that violates the organization’s security or acceptable use policies. Also, some IDPSs can monitor file transfers and identify ones that might be suspicious, such as copying a large database onto a user’s laptop.

Many IDPSs can also identify reconnaissance activity, which may indicate that an attack is imminent. For example, some attack tools and forms of malware, particularly worms, perform reconnaissance activities such as host and port scans to identify targets for subsequent attacks. An IDPS might be able to block reconnaissance and notify security administrators, who can take actions if needed to alter other security controls to prevent related incidents. Because reconnaissance activity is so frequent on the Internet, reconnaissance detection is often performed primarily on protected internal networks.

In addition to identifying incidents and supporting incident response efforts, organizations have found other uses for IDPSs, including the following:

Because of the increasing dependence on information systems and the prevalence and potential impact of intrusions against those systems, IDPSs have become a necessary addition to the security infrastructure of nearly every organization.

There are many types of IDPS technologies, which are differentiated primarily by the types of events that they can recognize and the methodologies that they use to identify incidents. In addition to monitoring and analyzing events to identify undesirable activity, all types of IDPS technologies typically perform the following functions:

Some IDPSs are also able to change their security profile when a new threat is detected. For example, an IDPS might be able to collect more detailed information for a particular session after malicious activity is detected within that session. An IDPS might also alter the settings for when certain alerts are triggered or what priority should be assigned to subsequent alerts after a particular threat is detected.

IPS technologies are differentiated from IDS technologies by one characteristic: IPS technologies can respond to a detected threat by attempting to prevent it from succeeding. They use several response techniques, which can be divided into the following groups:

Another common attribute of IDPS technologies is that they cannot provide completely accurate detection. When an IDPS incorrectly identifies benign activity as being malicious, a false positive has occurred. When an IDPS fails to identify malicious activity, a false negative has occurred. It is not possible to eliminate all false positives and negatives; in most cases, reducing the occurrences of one increases the occurrences of the other. Many organizations choose to decrease false negatives at the cost of increasing false positives, which means that more malicious events are detected but more analysis resources are needed to differentiate false positives from true malicious events. Altering the configuration of an IDPS to improve its detection accuracy is known as tuning.

Most IDPS technologies also offer features that compensate for the use of common evasion techniques. Evasion is modifying the format or timing of malicious activity so that its appearance changes but its effect is the same. Attackers use evasion techniques to try to prevent IDPS technologies from detecting their attacks. For example, an attacker could encode text characters in a particular way, knowing that the target understands the encoding and hoping that any monitoring IDPSs do not. Most IDPS technologies can overcome common evasion techniques by duplicating special processing performed by the targets. If the IDPS can “see” the activity in the same way that the target would, then evasion techniques will generally be unsuccessful at hiding attacks.

IDPS technologies use many methodologies to detect incidents. Sections 2.3.1 through 2.3.3 discuss the primary classes of detection methodologies: signature-based, anomaly-based, and stateful protocol analysis, respectively. Most IDPS technologies use multiple detection methodologies, either separately or integrated, to provide more broad and accurate detection.

A signature is a pattern that corresponds to a known threat. Signature-based detection is the process of comparing signatures against observed events to identify possible incidents.⁵ Examples of signatures are as follows:

Signature-based detection is very effective at detecting known threats but largely ineffective at detecting previously unknown threats, threats disguised by the use of evasion techniques, and many variants of known threats. For example, if an attacker modified the malware in the previous example to use a filename of “freepics2.exe”, a signature looking for “freepics.exe” would not match it.

Signature-based detection is the simplest detection method because it just compares the current unit of activity, such as a packet or a log entry, to a list of signatures using string comparison operations. Signature-based detection technologies have little understanding of many network or application protocols and cannot track and understand the state of complex communications. For example, they cannot pair a request with the corresponding response, such as knowing that a request to a Web server for a particular page generated a response status code of 403, meaning that the server refused to fill the request. They also lack the ability to remember previous requests when processing the current request. This limitation prevents signature-based detection methods from detecting attacks that comprise multiple events if none of the events contains a clear indication of an attack.

Anomaly-based detection is the process of comparing definitions of what activity is considered normal against observed events to identify significant deviations. An IDPS using anomaly-based detection has profiles that represent the normal behavior of such things as users, hosts, network connections, or applications. The profiles are developed by monitoring the characteristics of typical activity over a period of time. For example, a profile for a network might show that Web activity comprises an average of 13% of network bandwidth at the Internet border during typical workday hours. The IDPS then uses statistical methods to compare the characteristics of current activity to thresholds related to the profile, such as detecting when Web activity comprises significantly more bandwidth than expected and alerting an administrator of the anomaly. Profiles can be developed for many behavioral attributes, such as the number of e-mails sent by a user, the number of failed login attempts for a host, and the level of processor usage for a host in a given period of time.

The major benefit of anomaly-based detection methods is that they can be very effective at detecting previously unknown threats. For example, suppose that a computer becomes infected with a new type of malware. The malware could consume the computer’s processing resources, send large numbers of e-mails, initiate large numbers of network connections, and perform other behavior that would be significantly different from the established profiles for the computer.

An initial profile is generated over a period of time (typically days, sometimes weeks) sometimes called a training period. Profiles for anomaly-based detection can either be static or dynamic. Once generated, a static profile is unchanged unless the IDPS is specifically directed to generate a new profile. A dynamic profile is adjusted constantly as additional events are observed. Because systems and networks change over time, the corresponding measures of normal behavior also change; a static profile will eventually become inaccurate, so it needs to be regenerated periodically. Dynamic profiles do not have this problem, but they are susceptible to evasion attempts from attackers. For example, an attacker can perform small amounts of malicious activity occasionally, then slowly increase the frequency and quantity of activity. If the rate of change is sufficiently slow, the IDPS might think the malicious activity is normal behavior and include it in its profile. Malicious activity might also be observed by an IDPS while it builds its initial profiles.

Inadvertently including malicious activity as part of a profile is a common problem with anomaly-based IDPS products. (In some cases, administrators can modify the profile to exclude activity in the profile that is known to be malicious.) Another problem with building profiles is that it can be very challenging in some cases to make them accurate, because computing activity can be so complex. For example, if a particular maintenance activity that performs large file transfers occurs only once a month, it might not be observed during the training period; when the maintenance occurs, it is likely to be considered a significant deviation from the profile and trigger an alert. Anomaly-based IDPS products often produce many false positives because of benign activity that deviates significantly from profiles, especially in more diverse or dynamic environments. Another noteworthy problem with the use of anomaly-based detection techniques is that it is often difficult for analysts to determine why a particular alert was generated and to validate that an alert is accurate and not a false positive, because of the complexity of events and number of events that may have caused the alert to be generated.

Stateful protocol analysis is the process of comparing predetermined profiles of generally accepted definitions of benign protocol activity for each protocol state against observed events to identify deviations.⁶ Unlike anomaly-based detection, which uses host or network-specific profiles, stateful protocol analysis relies on vendor-developed universal profiles that specify how particular protocols should and should not be used. The “stateful” in stateful protocol analysis means that the IDPS is capable of understanding and tracking the state of network, transport, and application protocols that have a notion of state. For example, when a user starts a File Transfer Protocol (FTP) session, the session is initially in the unauthenticated state. Unauthenticated users should only perform a few commands in this state, such as viewing help information or providing usernames and passwords. An important part of understanding state is pairing requests with responses, so when an FTP authentication attempt occurs, the IDPS can determine if it was successful by finding the status code in the corresponding response. Once the user has authenticated successfully, the session is in the authenticated state, and users are expected to perform any of several dozen commands. Performing most of these commands while in the unauthenticated state would be considered suspicious, but in the authenticated state performing most of them is considered benign.

Stateful protocol analysis can identify unexpected sequences of commands, such as issuing the same command repeatedly or issuing a command without first issuing a command upon which it is dependent. Another state tracking feature of stateful protocol analysis is that for protocols that perform authentication, the IDPS can keep track of the authenticator used for each session, and record the authenticator used for suspicious activity. This is helpful when investigating an incident. Some IDPSs can also use the authenticator information to define acceptable activity differently for multiple classes of users or specific users.

The “protocol analysis” performed by stateful protocol analysis methods usually includes reasonableness checks for individual commands, such as minimum and maximum lengths for arguments. If a command typically has a username argument, and usernames have a maximum length of 20 characters, then an argument with a length of 1000 characters is suspicious. If the large argument contains binary data, then it is even more suspicious.

Stateful protocol analysis methods use protocol models, which are typically based primarily on protocol standards from software vendors and standards bodies (e.g., Internet Engineering Task Force [IETF] Request for Comments [RFC]). The protocol models also typically take into account variances in each protocol’s implementation. Many standards are not exhaustively complete in explaining the details of the protocol, which causes variations among implementations. Also, many vendors either violate standards or add proprietary features, some of which may replace features from the standards. For proprietary protocols, complete details about the protocols are often not available, making it difficult for IDPS technologies to perform comprehensive, accurate analysis. As protocols are revised and vendors alter their protocol implementations, IDPS protocol models need to be updated to reflect those changes.

The primary drawback to stateful protocol analysis methods is that they are very resource-intensive because of the complexity of the analysis and the overhead involved in performing state tracking for many simultaneous sessions. Another serious problem is that stateful protocol analysis methods cannot detect attacks that do not violate the characteristics of generally acceptable protocol behavior, such as performing many benign actions in a short period of time to cause a denial of service. Yet another problem is that the protocol model used by an IDPS might conflict with the way the protocol is implemented in particular versions of specific applications and operating systems, or how different client and server implementations of the protocol interact.

There are many types of IDPS technologies. For the purposes of this document, they are divided into the following four groups based on the type of events that they monitor and the ways in which they are deployed:

Some forms of IDPS are more mature than others because they have been in use much longer. Network-based IDPS and some forms of host-based IDPS have been commercially available for over ten years. Network behavior analysis software is a somewhat newer form of IDPS that evolved in part from products created primarily to detect DDoS attacks, and in part from products developed to monitor traffic flows on internal networks. Wireless technologies are a relatively new type of IDPS, developed in response to the popularity of wireless local area networks (WLAN) and the growing threats against WLANs and WLAN clients.

Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents, which are violations or imminent threats of violation of computer security policies, acceptable use policies, or standard security practices. Intrusion prevention is the process of performing intrusion detection and attempting to stop detected possible incidents. Intrusion detection and prevention systems (IDPS) are primarily focused on identifying possible incidents, logging information about them, attempting to stop them, and reporting them to security administrators. In addition, organizations use IDPSs for other purposes, such as identifying problems with security policies, documenting existing threats, and deterring individuals from violating security policies. IDPSs have become a necessary addition to the security infrastructure of nearly every organization.

There are many types of IDPS technologies, which are differentiated primarily by the types of events that they can recognize and the methodologies that they use to identify possible incidents. This publication discusses the following four types of IDPS technologies:

IDPSs typically record information related to observed events, notify security administrators of important observed events, and produce reports. Many IDPSs can also respond to a detected threat by attempting to prevent it from succeeding. They use several response techniques, which involve the IDPS stopping the attack itself, changing the security environment (e.g., reconfiguring a firewall), or changing the attack’s content.

IDPSs cannot provide completely accurate detection; they all generate false positives (incorrectly identifying benign activity as malicious) and false negatives (failing to identify malicious activity). Many organizations choose to tune IDPSs so that false negatives are decreased and false positives increased, which necessitates additional analysis resources to differentiate false positives from true malicious events. Most IDPSs also offer features that compensate for the use of common evasion techniques, which modify the format or timing of malicious activity to alter its appearance but not its effect, to attempt to avoid detection by IDPSs.

Most IDPSs use multiple detection methodologies, either separately or integrated, to provide more broad and accurate detection. The primary classes of detection methodologies are as follows:

This section provides an overview of IDPS technologies. The information presented in this section applies to all types of IDPS products; additional information specific to each product type is presented in Sections 4 through 7. This section first covers the major components of IDPS technologies and explains the architectures typically used for deploying the components. It also provides a high-level description of the security capabilities of the technologies, including the methodologies they use to identify suspicious activity. The rest of the section discusses the management capabilities of the technologies, including detailed recommendations for implementation and operation.

This section describes the major components of IDPS solutions and illustrates the most common network architectures for these components.

The typical components in an IDPS solution are as follows:

IDPS components can be connected to each other through an organization’s standard networks or through a separate network strictly designed for security software management known as a management network. If a management network is used, each sensor or agent host has an additional network interface known as a management interface that connects to the management network. Also, each sensor or agent host is unable to pass any traffic between its management interface and any of its other network interfaces. The management servers, database servers, and consoles are attached to the management network only. This architecture effectively isolates the management network from the production networks. The benefits of doing this are to conceal the existence and identity of the IDPS from attackers; to protect the IDPS from attack; and to ensure that the IDPS has adequate bandwidth to function under adverse conditions (e.g., worm attack or distributed denial of service [DDoS] on the monitored networks). Disadvantages of using a management network include the additional costs in networking equipment and other hardware (e.g., PCs for the consoles) and the inconvenience for IDPS users and administrators of using separate computers for IDPS management and monitoring.

If an IDPS is deployed without a separate management network, another way of improving IDPS security is to create a virtual management network using a virtual local area network (VLAN) within the standard networks. Using a VLAN provides protection for IDPS communications, but not as much protection as a separate management network. For example, misconfiguration of the VLAN could lead to the exposure of IDPS data. Another concern is that under adverse conditions, such as DDoS attacks or major malware incidents, the network devices shared by the organization’s primary networks and VLAN might become completely saturated, negatively impacting the availability and performance of the IDPS.

Most IDPS technologies can provide a wide variety of security capabilities. Sections 3.2.1 through 3.2.4 describe common security capabilities, divided into four categories: information gathering, logging, detection, and prevention, respectively.

Some IDPS technologies offer information gathering capabilities, such as collecting information on hosts or networks from observed activity. Examples include identifying hosts and the operating systems and applications that they use, and identifying general characteristics of the network.

IDPSs typically perform extensive logging of data related to detected events. This data can be used to confirm the validity of alerts, investigate incidents, and correlate events between the IDPS and other logging sources. Data fields commonly used by IDPSs include event date and time, event type, importance rating (e.g., priority, severity, impact, confidence), and prevention action performed (if any). Specific types of IDPSs log additional data fields, such as network-based IDPSs performing packet captures and host-based IDPSs recording user IDs. IDPS technologies typically permit administrators to store logs locally and send copies of logs to centralized logging servers (e.g., syslog, security information and event management software). Generally, logs should be stored both locally and centrally to support the integrity and availability of the data (e.g., a compromise of the IDPS could allow attackers to alter or destroy its logs).⁸ Also, IDPSs should have their clocks synchronized using the Network Time Protocol (NTP) or through frequent manual adjustments so that their log entries have accurate timestamps.⁹

IDPS technologies typically offer extensive, broad detection capabilities. Most products use a combination of detection techniques, which generally supports more accurate detection and more flexibility in tuning and customization. The types of events detected and the typical accuracy of detection vary greatly depending on the type of IDPS technology. Most IDPSs require at least some tuning and customization to improve their detection accuracy, usability, and effectiveness, such as setting the prevention actions to be performed for particular alerts. Technologies vary widely in their tuning and customization capabilities. Typically, the more powerful a product’s tuning and customization capabilities are, the more its detection accuracy can be improved from the default configuration. Organizations should carefully consider the tuning and customization capabilities of IDPS technologies when evaluating products. Examples of such capabilities are as follows:

Some products also suppress alerts if an attacker generates many alerts in a short period of time, and may also temporarily ignore all future traffic from the attacker. This is to prevent the IDPS from being overwhelmed by alerts.

Viewing the code can help analysts to determine why particular alerts were generated, helping to validate alerts and identify false positives. The ability to edit all detection-related code and write new code (e.g., new signatures) is necessary to fully customize certain types of detection capabilities. For example, a particular alert might be generated by a complex series of events involving several code modules; customizing the IDPS to understand organization-specific characteristics might not be possible without editing the code directly. Editing the code requires programming and intrusion detection skills; also, some IDPSs use proprietary programming languages, which would necessitate the programmer learning a new language. Bugs introduced into the code during the customization process could cause the IDPS to function incorrectly or fail altogether, so administrators should treat code customization as they would any other alteration of production systems’ code.

Administrators should review tuning and customizations periodically to ensure that they are still accurate. For example, whitelists and blacklists should be checked regularly and all entries validated to ensure that they are still accurate and necessary. Thresholds and alert settings might need to be adjusted periodically to compensate for changes in the environment and in threats. Edits to detection code might need to be replicated whenever the product is updated (e.g., patched, upgraded). Administrators should also ensure that any products collecting baselines for anomaly-based detection have their baselines rebuilt periodically as needed to support accurate detection.

Most IDPSs offer multiple prevention capabilities; the specific capabilities vary by IDPS technology type. IDPSs usually allow administrators to specify the prevention capability configuration for each type of alert. This usually includes enabling or disabling prevention, as well as specifying which type of prevention capability should be used. Some IDPS sensors have a learning or simulation mode that suppresses all prevention actions and instead indicates when a prevention action would have been performed. This allows administrators to monitor and fine-tune the configuration of the prevention capabilities before enabling prevention actions, which reduces the risk of inadvertently blocking benign activity.

Most IDPS products offer similar management capabilities. This section discusses major aspects of management—implementation, operation, and maintenance—and provides recommendations for performing them effectively and efficiently. It also briefly discusses the skills needed for IDPS management and provides recommendations for gaining these skills.

Once an IDPS product has been selected, the administrators need to design an architecture, perform IDPS component testing, and deploy and secure the IDPS components. Sections 3.3.1.1 through 3.3.1.3 provide more information on these actions.

The first step in IDPS implementation is designing an architecture. Architectural considerations include the following:

Organizations should consider implementing the components in a test environment first, instead of a production environment, to reduce the likelihood of implementation problems disrupting the production networks. When the components are being deployed to production networks, organizations should initially activate only a few IDPS sensors or agents, with their prevention capabilities disabled. Because a new deployment is likely to generate a large number of false positives until fully tuned and customized, activating many sensors or agents at once might overwhelm the management servers and consoles, making it difficult for administrators to perform tuning and customization. Many false positives are likely to be the same across sensors or agents, so it is helpful to identify such false positives either during the testing process or when deploying the first few sensors or agents, so that those false positives can be addressed before widespread deployment. A phased deployment of sensors or agents is also helpful in identifying potential problems with scalability.

Implementing an IDPS can necessitate brief network or system outages for component installation. As mentioned above, performing a deployment in a test environment can be very helpful in identifying likely implementation problems, so that they can be mitigated appropriately when the production deployment occurs.

Appliance-based IDPS components are typically simple to deploy. Administrators might need to perform software updates or signature updates to ensure the IDPS software is current. Otherwise, administrators usually just need to provide power and connect network cables, boot the appliance, and perform some basic configuration (e.g., enter a product license key, assign a name to the sensor).

Software-based IDPS components usually take more time to deploy than appliance-based components. The organization first needs to acquire the appropriate hardware, which might include purchasing high-bandwidth network cards and otherwise ensuring that the hardware is robust enough for the IDPS. Next, administrators need to install an operating system (OS) that is compatible with the IDPS software, and then harden the host as much as possible. Hardening should include updating the OS, services, and applications, including the IDPS software. Administrators also need to perform basic configuration of the IDPS software, just as is done for appliance-based IDPS components.

After deploying either appliance-based or software-based IDPS components, considerable effort may be needed to configure the products’ detection and prevention capabilities, depending on the type of IDPS being deployed. Without performing this configuration work, some IDPSs might be capable of detecting only a small number of older, easily identified attacks.

Securing IDPS components is very important because IDPSs are often targeted by attackers. If an attacker can compromise an IDPS, it can be rendered useless in detecting subsequent attacks against other hosts. Also, IDPSs often contain sensitive information such as host configurations and known vulnerabilities that could be helpful in planning additional attacks. In addition to hardening software-based IDPS components and ensuring that all IDPS components are fully up-to-date, administrators should perform additional actions to ensure that the IDPS components themselves are secured appropriately. Specific security recommendations are as follows:

Some organizations also require the use of strong authentication for remote access to IDPS components, such as two-factor authentication. This provides an additional layer of security.

Nearly all IDPS products are designed to be operated and maintained through a graphical user interface (GUI), also known as the console. The console typically permits administrators to configure and update the sensors and management servers, as well as monitor their status (e.g., agent failure, packet dropping). Administrators can also manage user accounts, customize reports, and perform many other functions using the console. IDPS users can also perform many functions through the console, including monitoring and analyzing the IDPS data and generating reports. Most IDPSs permit administrators to set up individual user accounts for each administrator and user, and to grant each account only the privileges necessary for each person’s role. The console often reflects this by showing different menus and options based on the currently authenticated account’s designated role. Some products also provide finer-grained access control, such as specifying for which sensors or agents particular users can monitor or analyze data or generate reports or particular administrators can alter configurations. This allows a large IDPS deployment to be divided into logical units for operational purposes.

Some IDPS products also offer command-line interfaces (CLI). Unlike GUI consoles, which are typically used for remote management of sensors or agents and management servers, CLIs are typically used for local management of those components. Sometimes a CLI can be reached remotely through an encrypted connection established through secure shell (SSH) or other means. Consoles are typically much easier to use than CLIs, and CLIs often provide only some of the functionality that consoles provide.

The rest of this section provides additional information on the operation and maintenance of IDPSs. Section 3.3.2.1 describes how users can make effective use of consoles in their daily IDPS tasks. Section 3.3.2.2 provides more information on ongoing maintenance of the technologies, with Section 3.3.2.3 focusing specifically on acquiring and applying updates.

Most IDPS consoles offer many features to assist users in their daily tasks. For example, most consoles offer drill-down capabilities, which means that when a user examines an alert, more details and information are available in layers.¹² This allows users to see basic information on many alerts at once, and to show additional information on particular events of interest as needed. Some products allow users to see extensive supporting information, such as packet captures (both raw and parsed with a protocol analyzer) and related alerts (e.g., other alerts for the same source or destination), as well as documentation on the alert itself. Generally, the more data that the IDPS records, the easier it is for analysts to determine what has happened. Some consoles also offer incident response features, such as turning an alert into an incident case and providing workflow mechanisms that allow users to document additional information on the alert and route the alert to particular users or groups of users for further review.

Most consoles also offer various reporting functions. For example, administrators or users might be able to use the console to have certain reports run at set times and to e-mail or transfer the reports to the appropriate users or hosts. Many consoles also allow users to generate reports as needed (including reports for specific incidents) and to customize reports as needed. If an IDPS product stores its logs in a database or in an easily parsed file format (e.g., comma-separated values in a text file), database queries or scripts can also be used to generate custom reports, particularly if the console does not offer sufficiently flexible report customization.

Administrators should maintain IDPSs on an ongoing basis. This should include the following:

There are two types of IDPS updates: software updates and signature updates. Software updates fix bugs in the IDPS software or add new functionality, while signature updates add new detection capabilities or refine existing detection capabilities (e.g., reducing false positives). For many IDPSs, signature updates cause program code to be altered or replaced, so they are really a specialized form of software update. For other IDPSs, signatures are not written in code, so a signature update is a change to the configuration data for the IDPS.

Software updates can include any or all IDPS components, including sensors, agents, management servers, and consoles. Software updates for sensors and management servers, particularly appliance-based devices, are often applied by replacing an existing IDPS CD with a new one and rebooting the device. Many IDPSs run the software directly from the CD, so that no software installation is required. Other components, such as agents, require an administrator to install software or apply patches, either manually on each host or automatically through IDPS management software. Some vendors make software and signature updates available for download from their Web sites or other servers; often, the administrator interfaces for IDPSs have features for downloading and installing such updates.

Administrators should verify the integrity of updates before applying them, because updates could have been inadvertently or intentionally altered or replaced. The recommended verification method depends on the update’s format, as follows:

IDPSs are typically designed so that applying software and signature updates has no effect on existing tuning and customization settings. The primary exception is code customization, which often has to be repeated when code updates from the vendor are installed. For any IDPS, administrators should back up configuration settings periodically and before applying software or signature updates to ensure that existing settings are not inadvertently lost.

Administrators should test software and signature updates before applying them except for emergency situations (e.g., a signature identifies a new, active threat that is damaging the organization and cannot otherwise be detected or blocked). It is beneficial to have at least one sensor or agent host (one for each type of agent) that is used strictly for testing updates. New detection capabilities can often cause large numbers of alerts to be triggered, so testing signature updates on a single sensor or agent host, even briefly (e.g., loading the update and observing how the IDPS functions when monitoring typical activity), can help to identify signatures that are likely to be problematic and should possibly be disabled. In non-emergency situations, software and signature updates should be tested and deployed using the same practices that would be used for updating any other major security controls, such as firewalls and antivirus software. When updates are deployed into production, administrators should be ready to disable particular signatures or perform other minor reconfigurations as needed.

Various skills are needed for IDPS implementation, operation, and maintenance, including the following:

Skills in IDPS principles can be built and maintained through many methods, including training, technical conferences, books and other technical references, and mentoring programs. Knowledge of specific IDPS products can also be gained through several methods, including the following:

The typical components in an IDPS solution are sensors or agents, management servers, database servers, and consoles. Sensors and agents monitor and analyze activity; sensors are used to monitor networks and agents to monitor hosts. Management servers receive information from sensors or agents and manage them. Database servers are repositories for event information recorded by the sensors or agents and management servers. Consoles are programs that provide interfaces for IDPS users and administrators. These components can be connected to each other through an organization’s standard networks or through a separate network strictly designed for security software management known as a management network. A management network helps to protect the IDPS from attack and to ensure it has adequate bandwidth under adverse conditions. A virtual management network can be created using a virtual local area network (VLAN); this provides protection for IDPS communications, but not as much protection as a management network would provide.

Most IDPSs can provide a wide variety of security capabilities. Some products offer information gathering capabilities, such as collecting information on hosts or networks from observed activity. IDPSs also typically perform extensive logging of data related to detected events. This data can be used to confirm the validity of alerts, investigate incidents, and correlate events between the IDPS and other logging sources. Generally, logs should be stored both locally and centrally to support the integrity and availability of the data.

IDPSs typically offer extensive, broad detection capabilities. The types of events detected and the typical accuracy of detection vary greatly depending on the type of IDPS technology. Most IDPSs require at least some tuning and customization to improve their detection accuracy, usability, and effectiveness. Typically, the more powerful a product’s tuning and customization capabilities are, the more its detection accuracy can be improved from the default configuration. Examples of these capabilities are thresholds, blacklists and whitelists, alert settings, and code editing. Organizations should carefully consider the tuning and customization capabilities of IDPSs when evaluating products. Administrators should review tuning and customizations periodically to ensure that they are still accurate. Administrators should also ensure that any products collecting baselines for anomaly-based detection have those baselines rebuilt periodically as needed to support accurate detection.

Most IDPSs offer multiple prevention capabilities; the specific capabilities vary by IDPS technology type. IDPSs usually allow administrators to specify the prevention capability configuration for each type of alert. This includes enabling or disabling prevention, as well as specifying which type of prevention capability should be used.

Once an IDPS product has been selected, the administrators need to design an architecture, perform IDPS component testing, and deploy and secure the IDPS components. There are many architectural considerations, including component placement, solution reliability, interoperability with other systems, management network architecture, and necessary changes to other security controls. Before performing a production implementation, organizations should consider implementing the components in a test environment first to reduce the likelihood of implementation problems disrupting production. When the components are being deployed to production networks, organizations should initially activate only a few IDPS sensors or agents. Because a new deployment is likely to generate a large number of false positives until fully tuned and customized, activating many sensors or agents at once might overwhelm the management servers and consoles, making it difficult for administrators to perform tuning and customization.

In addition to hardening software-based IDPS components and ensuring that all IDPS components are fully up-to-date, administrators should perform additional actions to ensure that the IDPS components themselves are secured appropriately. Examples include creating separate accounts for each IDPS user and administrator, restricting network access to IDPS components, and ensuring that IDPS management communications are protected appropriately. All encryption used for protection should be performed using FIPS-approved encryption algorithms.

Administrators should maintain IDPSs on an ongoing basis. This should include monitoring the IDPS components for operational and security issues, performing regular vulnerability assessments, responding appropriately to vulnerabilities in the IDPS components, and testing and deploying IDPS software and signature updates. Administrators should verify the integrity of updates before applying them, because updates could have been inadvertently or intentionally altered or replaced. Administrators should test software and signature updates before applying them, except for emergency situations. Administrators should also back up configuration settings periodically and before applying software or signature updates to ensure that existing settings are not inadvertently lost.

This page has been left blank intentionally.

A network-based IDPS monitors network traffic for particular network segments or devices and analyzes network, transport, and application protocols to identify suspicious activity. This section provides a detailed discussion of network-based IDPS technologies. First, it contains a brief overview of TCP/IP, which is background material for understanding the rest of Section 4. Next, it covers the major components of network-based IDPSs and explains the architectures typically used for deploying the components. It also examines the security capabilities of the technologies in depth, including the methodologies they use to identify suspicious activity. The rest of the section discusses the management capabilities of the technologies and provides recommendations for implementation and operation.

TCP/IP is widely used throughout the world to provide network communications. TCP/IP communications are composed of four layers that work together. When a user wants to transfer data across networks, the data is passed from the highest layer through intermediate layers to the lowest layer, with each layer adding more information. The lowest layer sends the accumulated data through the physical network; the data is then passed up through the layers to its destination. Essentially, the data produced by a layer is encapsulated in a larger container by the layer below it. The four TCP/IP layers, from highest to lowest, are shown in Figure 4-1.

Figure 4-1. TCP/IP Layers

The four TCP/IP layers work together to transfer data between hosts. Network-based IDPSs typically perform most of their analysis at the application layer. They also analyze activity at the transport and network layers both to identify attacks at those layers and to facilitate the analysis of the application layer activity (e.g., a TCP port number may indicate which application is being used). Some network-based IDPSs also perform limited analysis at the hardware layer. Sections 4.1.1 through 4.1.4 describe each layer in greater detail.

The application layer enables applications to transfer data between an application server and client. An example of an application layer protocol is Hypertext Transfer Protocol (HTTP), which transfers data between a Web server and a Web browser. Other common application layer protocols include Domain Name System (DNS), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), and Simple Network Management Protocol (SNMP). There are hundreds of unique application layer protocols in common use, and many more that are not so common. Regardless of the protocol in use, application data is generated and then passed to the transport layer for further processing.

The transport layer is responsible for packaging data so that it can be transmitted between hosts. Most applications that communicate over networks rely on the transport layer to ensure reliable delivery of data. Generally, this is accomplished by using TCP. When loss of some application data is not a concern (e.g., streaming audio, video), or the application itself ensures reliable delivery of data, UDP is typically used. UDP is connectionless; one host simply sends data to another host without any preliminary negotiations. Each TCP or UDP packet has a source port number and a destination port number. One of the ports is associated with a server application on one system; the other port is associated with a corresponding client application on the other system. Client systems typically select any available port number for application use, whereas server systems usually have a static port number dedicated to each application. Although UDP and TCP ports are very similar, they are distinct from each other and are not interchangeable.

The network layer, also known as the IP layer, is responsible for handling the addressing and routing of data that it receives from the transport layer. After the network layer has encapsulated the transport layer data, the resulting logical units are referred to as packets. Each packet contains a header, which is composed of various fields that specify characteristics of the transport protocol in use; optionally, packets may also contain a payload, which holds the application data. The IP header contains a field called IP Version, which indicates which version of IP is in use. Typically this is set to 4 for IPv4; but the use of IPv6 is increasing, so this field may be set to 6 instead.¹⁴ Other significant IP header fields are as follows:

The network layer is also responsible for providing error and status information involving the addressing and routing of data; it does this with ICMP. ICMP is a connectionless protocol that makes no attempt to guarantee that its error and status messages are delivered. Because it is designed to transfer limited information, not application data, ICMP does not have ports; instead, it has message types, which indicate the purpose of each ICMP message.¹⁷ Some message types also have message codes, which can be thought of as subtypes. For example, the ICMP message type Destination Unreachable has several possible message codes that indicate what is unreachable (e.g., network, host, protocol). Most ICMP message types are not intended to elicit a response.¹⁸

As the name implies, the hardware layer, also called the data link layer, involves the physical components of the network, including cables, routers, switches, and network interface cards (NIC). The hardware layer also includes various hardware layer protocols, with Ethernet being the most widely used. Ethernet relies on the concept of a media access control (MAC) address, which is a unique six-byte value (such as 00-02-B4-DA-92-2C) that is permanently assigned to a particular NIC.¹⁹ Each frame, the logical unit at the hardware layer, contains two MAC addresses, which indicate the MAC address of the NIC that just routed the frame and the MAC address of the next NIC to which the frame is being sent. As a frame passes through networking equipment (such as routers and firewalls) on its way between the original source host and the final destination host, the MAC addresses are updated to refer to the local source and destination. Several separate hardware layer transmissions may be linked together within a single network layer transmission.

In addition to the MAC addresses, each frame also contains an EtherType value, which indicates the protocol that the frame’s payload contains (typically IP or Address Resolution Protocol [ARP]).²⁰ When IP is used, each IP address maps to a particular MAC address. (Because multiple IP addresses can map to a single MAC address, a MAC address does not necessarily uniquely identify an IP address.)

This section describes the major components of typical network-based IDPSs and illustrates the most common network architectures for these components. It also provides recommendations for the placement of network-based IDPS sensors.

A typical network-based IDPS is composed of sensors, one or more management servers, multiple consoles, and optionally one or more database servers (if the network-based IDPS supports their use). All of these components are similar to other types of IDPS technologies, except for the sensors. A network-based IDPS sensor monitors and analyzes network activity on one or more network segments. The network interface cards that will be performing monitoring are placed into promiscuous mode, which means that they will accept all incoming packets that they see, regardless of their intended destinations. Most IDPS deployments use multiple sensors, with large deployments having hundreds of sensors. Sensors are available in two formats:

Appliances often use a customized, hardened operating system (OS) that administrators are not intended to access directly.

Organizations should consider using management networks for their network-based IDPS deployments whenever feasible. If an IDPS is deployed without a separate management network, organizations should consider whether or not a VLAN is needed to protect the IDPS communications.

In addition to choosing the appropriate network for the components, administrators also need to decide where the IDPS sensors should be located. Sensors can be deployed in one of two modes:

Figure 4-2. Inline Network-Based IDPS Sensor Architecture Example

Splitting traffic among multiple IDPS sensors can cause a reduction in detection accuracy if related events or portions of a single event are seen by different sensors. For example, suppose that two sensors each see different steps of an attack; if each step is considered benign on its own but the two steps in sequence are malicious, then the attack might not be recognized.

Figure 4-3 shows examples of passive sensors connected to the monitored network using IDS load balancers, network taps, and spanning ports.

As explained in Section 4.3.4, most techniques for having a sensor prevent intrusions require that the sensor be deployed in inline mode, not passive. Because passive techniques monitor a copy of the traffic, they typically provide no reliable way for a sensor to stop the traffic from reaching its destination. In some cases, a passive sensor can place packets onto a network to attempt to disrupt a connection, but such methods are generally less effective than inline methods. Generally, organizations should deploy sensors inline if prevention methods will be used and passive if they will not.

Figure 4-3. Passive Network-Based IDPS Sensor Architecture Example

Network-based IDPS products provide a wide variety of security capabilities. Sections 4.3.1 through 4.3.4 describe common security capabilities, divided into four categories: information gathering, logging, detection, and prevention, respectively. Some network-based IDPS products also provide some security information and event management (SIEM) capabilities; see Section 8.2.2 for information on SIEM.

Some network-based IDPSs offer limited information gathering capabilities, which means that they can collect information on hosts and the network activity involving those hosts. Examples of information gathering capabilities are as follows:

Network-based IDPSs typically perform extensive logging of data related to detected events. This data can be used to confirm the validity of alerts, to investigate incidents, and to correlate events between the IDPS and other logging sources. Data fields commonly logged by network-based IDPSs include the following:

Most network-based IDPSs can also perform packet captures. Typically this is done once an alert has occurred, either to record subsequent activity in the connection or to record the entire connection if the IDPS has been temporarily storing the previous packets.

Network-based IDPSs typically offer extensive and broad detection capabilities. Most products use a combination of signature-based detection, anomaly-based detection, and stateful protocol analysis techniques to perform in-depth analysis of common protocols; organizations should use network-based IDPS products that use such a combination of techniques. The detection methods are usually tightly interwoven; for example, a stateful protocol analysis engine might parse activity into requests and responses, each of which is examined for anomalies and compared to signatures of known bad activity. Some products also use the same techniques and provide the same functionality as network behavior analysis (NBA) software; see Section 6 for additional information.

This section discusses the following aspects of detection capabilities:

The types of events most commonly detected by network-based IDPS sensors include the following:

Some IDPSs can also monitor the initial negotiation conducted when establishing encrypted communications to identify client or server software that has known vulnerabilities or is misconfigured. This can include application layer protocols such as secure shell (SSH) and Secure Sockets Layer (SSL), and network layer virtual private networking protocols such as IP Security (IPsec).

Network-based IDPS sensors can often determine if an attack is likely to succeed. For example, as described in Section 4.3.3.3, sensors might know which Web server software versions are running on each of the organization’s Web servers. If an attacker launches an attack against a Web server that is not vulnerable to the attack, then the sensor might produce a low-priority alert; if the server is thought to be vulnerable, then the sensor might produce a high-priority alert. IDPS sensors are typically configured to stop attacks whether or not they are likely to succeed, but an IDPS might still log the activity with different priority levels depending on what its outcome probably would have been if not blocked.

Historically, network-based IDPSs have been associated with high rates of false positives and false negatives. Most of the early technologies relied primarily on signature-based detection, which by itself is accurate only for detecting relatively simple well-known threats. Newer technologies use a combination of detection methods to increase accuracy and the breadth of detection, and generally the rates of false positives and false negatives have declined. Another common problem with network-based IDPSs’ accuracy is that they typically require considerable tuning and customization to take into account the characteristics of the monitored environment.

False positives and false negatives for network-based IDPS sensors can only be reduced somewhat because of the complexity of the activities being monitored. A single sensor is often monitoring traffic involving hundreds or thousands of internal and external hosts. The number and variety of OSs and applications in use over the monitored network can be immense; also, OSs and applications are constantly being changed. This makes it impossible for a sensor to understand everything it sees.

Even worse, sensors have to monitor activity for many different combinations of servers and clients. For example, an organization could use 10 different types and versions of Web servers, which users could access with 50 different types and versions of Web browsers. Each combination of browser and server could have unique communication characteristics (e.g., sequence of commands, response codes) that could impact the accuracy of analysis. Also, different configurations and customizations could be applied to the browsers and servers. Security controls between the servers and clients that alter network activity, such as firewalls and proxy servers, could cause additional difficulties for sensors.

Ideally, network-based IDPSs would be able to interpret all network activity just as the endpoints do. For example, different types of Web servers can interpret the same Web request in different ways. Stateful protocol analysis techniques often attempt to do this by replicating the processing performed by common types of clients and servers. This allows the sensors to improve their detection accuracy slightly. Many attackers employ client and server-specific processing characteristics, such as handling character encodings, in their attacks as evasion techniques. Organizations should use network-based IDPSs that can compensate for the use of common evasion techniques.

As mentioned in Section 4.3.3.2, network-based IDPSs usually require extensive tuning and customization to improve their detection accuracy. Examples of tuning and customization capabilities are thresholds for port scans and application authentication attempts, blacklists and whitelists for host IP addresses and usernames, and alert settings. Some products also provide code editing features, which is usually limited to signatures but in some cases may allow access to additional code, such as programs used to perform stateful protocol analysis.

Some network-based IDPSs can use information regarding the organization’s hosts to improve detection accuracy. For example, an IDPS might allow administrators to specify the IP addresses used by the organization’s Web servers, mail servers, and other common types of hosts, and also specify the types of services provided by each host (e.g., the Web server application type and version run by each Web server). This allows the IDPS to better prioritize alerts; for example, an alert for an Apache attack directed at an Apache Web server would have a higher priority than the same attack directed at a different type of Web server. Some network-based IDPSs can also import the results of vulnerability scans and use them to determine which attacks would likely be successful if not blocked. This allows the IDPS to make better decisions on prevention actions and prioritize alerts more accurately.

Although network-based IDPSs offer extensive detection capabilities, they do have some significant limitations. Three of the most important are analyzing encrypted network traffic, handling high traffic loads, and withstanding attacks against the IDPSs themselves. These limitations are discussed below.

Network-based IDPSs cannot detect attacks within encrypted network traffic, including virtual private network (VPN) connections, HTTP over SSL (HTTPS), and SSH sessions. As previously mentioned, some network-based IDPSs can do some analysis of the setup of encrypted connections, which can identify that the client or server software has known vulnerabilities or is misconfigured. To ensure that sufficient analysis is performed on payloads within encrypted network traffic, organizations should use IDPSs that can analyze the payloads before they are encrypted or after they are decrypted. Examples include placing network-based IDPS sensors to monitor unencrypted traffic (e.g., traffic that entered an organization through a VPN gateway and has since been decrypted) and using host-based IDPS software to monitor activity within the source or destination host.

Network-based IDPSs may be unable to perform full analysis under high loads. Passive IDPS sensors might drop some packets, which could cause some incidents to go undetected, especially if stateful protocol analysis methods are in use. For inline IDPS sensors, dropping packets under high loads causes disruptions in network availability; also, delays in processing packets could cause unacceptably high latency. To avoid this, organizations using inline IDPS sensors should select ones that can recognize high load conditions and either pass certain types of network traffic through the sensor without performing full analysis (i.e., partial or no analysis) or drop low-priority traffic to reduce load. Many vendors attempt to optimize their sensors to provide better performance under high loads by taking measures such as using specialized hardware (e.g., high-bandwidth network cards) and recompiling components of their software to incorporate settings and other customizations made by administrators. Although vendors typically rate their sensors by maximum bandwidth capability, the actual capacity of any product depends on several factors, including the following:

IDPS sensors are susceptible to various types of attacks. Attackers can generate unusually large volumes of traffic, such as distributed denial of service (DDoS) attacks, and anomalous activity (e.g., unusually fragmented packets) to attempt to exhaust a sensor’s resources or cause it to crash. Another attack technique, known as blinding, generates network traffic that is likely to trigger many IDPS alerts in a short period of time; typically, the network traffic is specially crafted to take advantage of typical configurations of IDPS sensors. In many cases, the blinding traffic is not intended to actually attack any targets. An attacker runs the “real” attack separately at the same time as the blinding traffic. The attacker’s goal is that the blinding traffic will either cause the IDPS to fail in some way or generate so many alerts that the alerts for the real attack will go unnoticed. Many IDPS sensors can recognize the use of common DDoS and blinding tools and techniques; the sensors can alert administrators to the attack and then ignore the rest of the activity, reducing the load on the sensors. Organizations should select products that offer features that make them resistant to failure due to attack.

Network-based IDPS sensors offer various prevention capabilities, including the following (grouped by sensor type):

Most IDPS sensors allow administrators to specify the prevention capability configuration for each type of alert. This usually includes enabling or disabling prevention, as well as specifying which prevention capability should be used. Some IDPS sensors have a learning or simulation mode that suppresses all prevention actions, and instead indicates when a prevention action would have been performed. This allows administrators to monitor and fine-tune the prevention capabilities’ configuration before enabling them, which reduces the risk of inadvertently blocking benign activity.

Most network-based IDPS products offer similar management capabilities. This section discusses major aspects of management—implementation, operation, and maintenance—and provides recommendations for performing them effectively and efficiently.

Once a network-based IDPS product has been selected, the administrators need to design an architecture, perform IDPS component testing, secure the IDPS components, and then deploy them. The following items list additions to the material presented in Section 3.3.1:

The operation and maintenance of network-based IDPSs is performed in the same manner as that documented in the general information provided in Section 3.3.2.

A network-based IDPS monitors network traffic for particular network segments or devices and analyzes network, transport, and application protocols to identify suspicious activity. Network-based IDPS components are similar to other types of IDPS technologies, except for the sensors. A network-based IDPS sensor monitors and analyzes network activity on one or more network segments. Sensors are available in two formats: appliance-based sensors, which are comprised of specialized hardware and software optimized for IDPS sensor use, and software-only sensors, which can be installed onto hosts that meet certain specifications.

Organizations should consider using management networks for their network-based IDPS deployments whenever feasible. If an IDPS is deployed without a separate management network, organizations should consider whether or not a VLAN is needed to protect the IDPS communications. In addition to choosing the appropriate network for the components, administrators also need to decide where the IDPS sensors should be located. Sensors can be deployed in one of two modes: inline sensors are deployed so that the network traffic they monitor must pass through them, while passive sensors are deployed so that they monitor copies of the actual network traffic. Generally, organizations should deploy inline sensors if prevention methods will be used and passive sensors if they will not.

Network-based IDPSs provide a wide variety of security capabilities. Some products can collect information on hosts such as which OSs they use and which application versions they use that communicate over networks. Network-based IDPSs can also perform extensive logging of data related to detected events; most can also perform packet captures. Network-based IDPSs usually offer extensive and broad detection capabilities. Most products use a combination of signature-based detection, anomaly-based detection, and stateful protocol analysis to perform in-depth analysis of common protocols; organizations should use network-based IDPS products that provide such a combination of detection features, because the combination increases detection accuracy. Organizations should also use network-based IDPSs that can compensate for the use of common evasion techniques, which further improves detection accuracy.

Network-based IDPSs have some significant limitations. They cannot detect attacks within encrypted network traffic; accordingly, either they should be deployed where they can monitor traffic before encryption or after decryption, or host-based IDPSs should be used on endpoints to monitor unencrypted activity. Network-based IDPSs are often unable to perform full analysis under high loads; organizations using inline sensors should select those that can recognize high load conditions and either pass certain types of traffic without performing full analysis or drop low-priority traffic to reduce load. Another limitation of network-based IDPSs is that they are susceptible to various types of attacks, most involving large volumes of traffic. Organizations should select products that offer features designed to make them resistant to failure due to attack. Organizations should also ensure that IP addresses are not assigned to the network interfaces of passive or inline sensors used to monitor network traffic, except for network interfaces used for both traffic monitoring and IDPS management.

Network-based IDPS sensors offer various prevention capabilities. Many passive sensors can attempt to end TCP sessions by resetting them, but this technique often does not work in time, and it is not applicable to non-TCP sessions, such as UDP and ICMP. Inline sensor-specific techniques include performing inline firewalling, throttling bandwidth usage, and altering malicious content, all of which are helpful for certain circumstances. Both passive and inline sensors can reconfigure other network security devices; they can also run third-party programs or scripts to initiate additional prevention actions.

This page has been left blank intentionally.

A wireless IDPS monitors wireless network traffic and analyzes its wireless networking protocols to identify suspicious activity involving the protocols themselves. This section provides a detailed discussion of wireless IDPS technologies. First, it contains a brief overview of wireless networking, which is background material for understanding the rest of the section. Next, it covers the major components of wireless IDPSs and explains the architectures typically used for deploying the components. It also examines the security capabilities of the technologies in depth, including the methodologies they use to identify and stop suspicious activity. The rest of the section discusses the management capabilities of the technologies, including recommendations for implementation and operation.

Wireless networking enables devices with wireless capabilities to use computing resources without being physically connected to a network. The devices simply need to be within a certain distance (known as the range) of the wireless network infrastructure. A wireless local area network (WLAN) is a group of wireless networking nodes within a limited geographic area that is capable of exchanging data through radio communications. WLANs are typically used by devices within a fairly limited range, such as an office building or corporate campus, and are implemented as extensions to existing wired local area networks (LAN) to provide enhanced user mobility.

This section provides a brief introduction to wireless networking. Section 5.1.1 provides an overview of the most commonly used WLAN standards. Section 5.1.2 discusses the fundamental components of WLANs. Finally, Section 5.1.3 briefly examines the major threats against WLANs. This material is intended only to provide a high-level overview of wireless networking as background information for the wireless IDPS material in the rest of the section.²⁵

Most WLANs use the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of WLAN standards.²⁶ The most commonly used WLAN radio transmission standards are IEEE 802.11b and IEEE 802.11g, which use the 2.4 gigahertz (GHz) band, and IEEE 802.11a, which uses the 5 GHz band. IEEE 802.11a, b, and g include security features known collectively as Wired Equivalent Privacy (WEP). Unfortunately, WEP has several well-documented security problems. To overcome these, IEEE 802.11i was created; it specifies security components that work in conjunction with IEEE 802.11a, b, and g.

Another set of WLAN standards has been created by a non-profit industry consortium of WLAN equipment and software vendors called the Wi-Fi Alliance.²⁷ While IEEE was working on finalizing the 802.11i standard, the Alliance created an interim solution called Wi-Fi Protected Access (WPA). Published in October 2002, WPA is essentially a subset of the draft IEEE 802.11i requirements available at that time. WPA provides stronger security for WLAN communications than WEP. In conjunction with the ratification of the IEEE 802.11i amendment, the Wi-Fi Alliance introduced WPA2, its term for interoperable equipment that is capable of supporting IEEE 802.11i requirements. WPA2 offers stronger security controls than either WPA or WEP.

IEEE 802.11 WLANs have two fundamental architectural components:

Figure 5-1. Wireless LAN Architecture Example

Some WLANs also use wireless switches. A wireless switch is a device that acts as an intermediary between APs and the DS. The purpose of the switch is to assist administrators in managing the WLAN infrastructure. In WLANs without wireless switches, the APs connect directly to the DS.

The IEEE 802.11 standard also defines the following two WLAN architectures:

Each AP and STA on a WLAN can be identified by its media access control (MAC) address, which is a unique 48-bit value that is assigned to a wireless network interface card. Part of the MAC address can be used to identify the card’s vendor; the rest of the address acts as a serial number from the vendor. Ideally, MAC addresses could be used to uniquely identify every wireless device; however, it is relatively trivial to spoof a MAC address.

Nearly all organization WLANs use infrastructure mode. Each AP in a WLAN has a name assigned to it called a service set identifier (SSID). The SSID allows STAs to distinguish one WLAN from another. SSIDs are broadcast in plaintext by APs, so any listening wireless device can easily learn the SSID for each WLAN in its range.²⁹ Organizations may have no WLANs, one WLAN, or multiple WLANs. Also, many organizations have facilities that are within range of other organizations’ WLANs.

Although wireless and wired networks face the same general types of threats, the relative risk of some threats varies significantly. For example, wireless attacks typically require the attacker or a device placed by the attacker to be within close physical proximity to the wireless network; many attacks on wired networks can be performed remotely from any location. However, many WLANs are configured so that they do not require any authentication or require only weak forms of authentication; this makes it much easier for local attackers to perform several types of attacks, such as a man-in-the-middle attack.

Most WLAN threats involve an attacker with access to the radio link between a STA and an AP (or between two STAs, in ad hoc mode). Many attacks rely on an attacker’s ability to intercept network communications or inject additional messages into them. This highlights the most significant difference between protecting wireless and wired LANs: the relative ease of accessing and altering network communications. In a wired LAN, an attacker would have to gain physical access to the LAN or remotely compromise systems on the LAN; in a wireless LAN, an attacker simply needs to be within range of the WLAN infrastructure.³⁰

This section describes the major components of typical wireless IDPS solutions and illustrates the most common network architectures for these components. It also provides recommendations for the placement of certain components.

The typical components in a wireless IDPS are the same as a network-based IDPS: consoles, database servers (optional), management servers, and sensors. All of the components except sensors have essentially the same functionality for both types of IDPSs. Wireless sensors perform the same basic role as network-based IDPS sensors, but they function very differently because of the complexities of monitoring wireless communications.

Unlike a network-based IDPS, which can see all packets on the networks it monitors, a wireless IDPS works by sampling traffic. There are two frequency bands to monitor (2.4 GHz and 5 GHz), and each band is separated into channels.³¹ It is not currently possible for a sensor to monitor all traffic on a band simultaneously; a sensor has to monitor a single channel at a time. When the sensor is ready to monitor a different channel, the sensor must shut its radio off, change the channel, then turn its radio on. The longer a single channel is monitored, the more likely it is that the sensor will miss malicious activity occurring on other channels. To avoid this, sensors typically change channels frequently, which is known as channel scanning, so that they can monitor each channel a few times per second. To reduce or eliminate channel scanning, specialized sensors are available that use several radios and high-power antennas, with each radio/antenna pair monitoring a different channel. Because of their higher sensitivities, the high-power antennas also have a larger monitoring range than regular antennas. Some implementations coordinate scanning patterns among sensors with overlapping ranges so that each sensor needs to monitor fewer channels.³²

Wireless sensors are available in multiple forms:

Because dedicated sensors can focus on detection and do not need to carry wireless traffic, they typically offer stronger detection capabilities than wireless sensors bundled with APs or wireless switches. However, dedicated sensors are often more expensive to acquire, install, and maintain than bundled sensors because bundled sensors can be installed on existing hardware, whereas dedicated sensors involve additional hardware and software. Organizations should consider both security and cost when selecting wireless IDPS sensors.

Some vendors also have host-based wireless IDPS sensor software that can be installed on STAs, such as laptops. The sensor software detects attacks within range of the STAs, as well as misconfigurations of the STAs, and reports this information to management servers. The sensor software may also be able to enforce security policies on the STAs, such as limiting access to wireless interfaces. More information on host-based IDPS products is presented in Section 7.

Wireless IDPS components are typically connected to each other through a wired network, as shown in Figure 5-2. As with a network-based IDPS, a separate management network or the organization’s standard networks can be used for wireless IDPS component communications. Because there should already be a strictly controlled separation between the wireless and wired networks, using either a management network or a standard network should be acceptable for wireless IDPS components. Also, some wireless IDPS sensors (particularly mobile ones) are used standalone and do not need wired network connectivity.

Figure 5-2. Wireless IDPS Architecture

Choosing sensor locations for a wireless IDPS deployment is a fundamentally different problem than choosing locations for any other type of IDPS sensor. If the organization uses WLANs, wireless sensors should be deployed so that they monitor the RF range of the organization’s WLANs (both APs and STAs), which often includes mobile components such as laptops and PDAs. Many organizations also want to deploy sensors to monitor physical regions of their facilities where there should be no WLAN activity, as well as channels and bands that the organization’s WLANs should not use, as a way of detecting rogue APs and ad hoc WLANs. Other considerations for selecting wireless sensor locations include the following:

Wireless IDPSs provide several types of security capabilities. Because wireless IDPS is a relatively new form of IDPS, capabilities currently vary widely among products; over time, product capabilities should become more consistent. Sections 5.3.1 through 5.3.4 describe common security capabilities, divided into four categories: information gathering, logging, detection, and prevention, respectively.

Most wireless IDPSs can collect information on wireless devices. Examples of these information gathering capabilities are as follows:

Wireless IDPSs typically perform extensive logging of data related to detected events. This data can be used to confirm the validity of alerts, to investigate incidents, and to correlate events between the IDPS and other logging sources. Data fields commonly logged by wireless IDPSs include the following:

Wireless IDPSs can detect attacks, misconfigurations, and policy violations at the WLAN protocol level, primarily examining IEEE 802.11a, b, g, and i protocol communication. Wireless IDPSs do not examine communications at higher levels (e.g., IP addresses, application payloads). Some products perform only simple signature-based detection, while others use a combination of signature-based detection, anomaly-based detection, and stateful protocol analysis techniques; organizations should use wireless IDPS products that use such a combination of techniques, to achieve broader and more accurate detection. This section discusses the following aspects of detection capabilities:

The types of events most commonly detected by wireless IDPS sensors include the following:

802.11i. The majority of types of events that can be detected by wireless IDPSs fall into this detection category.

Most wireless IDPS sensors can identify the physical location of a detected threat by using triangulation—estimating the threat’s approximate distance from multiple sensors by the strength of the threat’s signal received by each sensor, then calculating the physical location at which the threat would be the estimated distance from each sensor. This allows an organization to send physical security staff to the location to address the threat. Wireless IDPS products that can use building floor plans can also determine if the threat is inside or outside a building, or if it is in a public area or secured area. This information is helpful not only in finding and stopping the threat, but also in prioritizing the response to the threat. Wireless IDPS sensors can set the priority of alerts based in part on the location of each threat. Handheld IDPS sensors can also be used to pinpoint a threat’s location, particularly if fixed sensors do not offer triangulation capabilities or if the threat is moving.

Compared to other forms of IDPS, wireless IDPS is generally more accurate; this is largely due to its limited scope (analyzing wireless networking protocols). False positives are most likely to be caused by anomaly-based detection methods, especially if threshold values are not properly maintained. Although many alerts might occur based on benign activity, such as another organization’s WLAN being within range of the organization’s WLANs, these alerts are not truly false positives because they are accurately detecting an unknown WLAN within the organization’s facilities.

Wireless IDPS technologies usually require some tuning and customization to improve their detection accuracy. The main effort is in specifying which WLANs, APs, and STAs are authorized, and in entering the policy characteristics into the wireless IDPS software. Because wireless IDPSs are only examining wireless network protocols, not higher level protocols (e.g., application), there are generally not a large number of alert types, and consequently not many customizations or tunings available. Some wireless IDPSs offer industry-specific templates that can be helpful in establishing base policies.

Wireless IDPSs offer some customization features. Most have thresholds that can be used for anomaly-based detection. Blacklists and whitelists are used to hold lists of known malicious and benign WLAN devices, respectively. The lists can also be used to record authorized or unauthorized WLAN NIC vendors; alerts can be generated when any NICs not on the authorized list are used for APs or STAs. Individual alerts can be customized, just as they can for network-based IDPSs. Code editing is not available for most products, although some vendors allow administrators to enter complex logical expressions to tune certain detection capabilities.

Besides reviewing tuning and customizations periodically to ensure that they are still accurate, administrators should also ensure that changes to building plans are incorporated occasionally. This is needed for accurate identification of the physical location of threats and accurate planning of sensor deployments.

Although wireless IDPSs offer robust detection capabilities, they do have some significant limitations. Three of the most important are being unable to detect certain wireless protocol attacks, being susceptible to evasion techniques, and being unable to withstand attacks against the IDPSs themselves. These limitations are discussed in detail below.

Wireless IDPSs cannot detect certain types of attacks against wireless networks. An attacker can passively monitor wireless traffic, which is not detectable by wireless IDPSs. If weak security methods are being used (e.g., WEP), the attacker can then perform offline processing of that collected traffic to find the encryption key used to provide security for the wireless traffic. With this key, the attacker can decrypt the traffic that was already collected, as well as any other traffic that is collected from the same WLAN. Wireless IDPSs cannot fully compensate for the use of insecure wireless networking protocols.

Another problem with some wireless IDPS sensors is the use of evasion techniques. Attackers can identify the wireless IDPS product in use by various means, including a physical survey of the area in which the sensors are deployed, and the use of fingerprinting techniques that can identify the product in use by the characteristics of its prevention actions (see Section 5.3.4 for information on prevention). Once an attacker has identified the product, evasion techniques can be used that take advantage of the product’s channel scanning scheme. One example is performing attacks in very short bursts on channels that are not currently being monitored. An attacker could also launch attacks on two channels at the same time. If the wireless IDPS sensor detects the first attack, it cannot detect the second attack unless it scans away from the channel of the first attack. Another drawback of channel scanning is the impact it could have on network forensics. Since each sensor sees only a fraction of the activity on each channel, the forensic data is quite incomplete, making it considerably more difficult to analyze.

Wireless IDPS sensors are also susceptible to attack. The same denial of service attacks (both logical and physical) that attempt to disrupt WLANs can also disrupt sensor functions. Sensors are also often particularly susceptible to physical attack because they are usually located in hallways, conference rooms, and other open areas. Some sensors have anti-tamper features, such as being designed to look like fire alarms or regular APs, that can reduce the likelihood that they will be attacked. All sensors are susceptible to physical attacks such as jamming that disrupt RF; there is no defense against such attacks other than to establish a physical perimeter around the facility so that attackers cannot get close enough to the WLAN to jam it.

Wireless IDPS sensors offer two types of intrusion prevention capabilities:

Most IDPS sensors allow administrators to specify the prevention capability configuration for each type of alert. This usually includes enabling or disabling prevention, as well as specifying which type of prevention capability should be used. Some IDPS sensors have a learning or simulation mode that suppresses all prevention actions, and instead indicates when a prevention action would have been performed. This allows administrators to monitor and fine-tune the prevention capabilities’ configuration before enabling prevention, which reduces the risk of performing prevention actions on benign activity.

An important consideration is the effect that prevention actions can have on sensor monitoring. For example, if a sensor is transmitting signals to terminate connections, it may not be able to perform channel scanning to monitor other communications until it has completed the prevention action. To mitigate this, some sensors have two radios—one for monitoring and detection, and another for performing prevention actions. When selecting sensors, organizations should consider what prevention actions may need to be performed and how the sensor’s detection capabilities could be affected by performing prevention actions.

Most wireless IDPS products offer similar management capabilities. This section discusses major aspects of management—implementation, operation, and maintenance—and provides recommendations for performing them effectively and efficiently.

Once a wireless IDPS product has been selected, the administrators need to design an architecture, perform IDPS component testing, secure the IDPS components, and then deploy them. The only addition to the material presented in Section 3.3.1 involves component testing and deployment. Implementing a wireless IDPS can necessitate brief wireless network outages if existing APs or wireless switches need to be upgraded or have IDPS software installed. Generally, the deployment of dedicated sensors causes no network outages.

The operation and maintenance of a wireless IDPS solution is nearly identical to that of a network-based IDPS solution. Wireless IDPS consoles offer similar management, monitoring, analysis, and reporting capabilities. One significant difference is that wireless IDPS consoles can display the physical location of threats. A minor difference is that because wireless IDPS sensors detect a relatively small variety of events, compared to other types of IDPSs, they tend to have signature updates less frequently.

A wireless IDPS monitors wireless network traffic and analyzes its wireless networking protocols to identify suspicious activity. The typical components in a wireless IDPS are the same as a network-based IDPS: consoles, database servers (optional), management servers, and sensors. However, unlike a network-based IDPS sensor, which can see all packets on the networks it monitors, a wireless IDPS sensor works by sampling traffic because it can only monitor a single channel at a time. The longer a single channel is monitored, the more likely it is that the sensor will miss malicious activity occurring on other channels. To avoid this, sensors typically change channels frequently, so that they can monitor each channel a few times per second.

Wireless sensors are available in multiple forms. A dedicated sensor is a fixed or mobile device that performs wireless IDPS functions but does not pass network traffic from source to destination. The other wireless sensor forms are bundled with access points (AP) or wireless switches. Because dedicated sensors can focus on detection and do not need to carry wireless traffic, they typically offer stronger detection capabilities than wireless sensors bundled with access points or wireless switches. However, dedicated sensors are often more expensive to acquire, install, and maintain than bundled sensors because bundled sensors can be installed on existing hardware, whereas dedicated sensors involve additional hardware and software. Organizations should consider both security and cost when selecting wireless IDPS sensors.

Wireless IDPS components are typically connected to each other through a wired network. Because there should already be a strictly controlled separation between the wireless and wired networks, using either a management network or a standard network should be acceptable for wireless IDPS components. Choosing sensor locations for a wireless IDPS deployment is a fundamentally different problem than choosing locations for any other type of IDPS sensor. If the organization uses wireless local area networks (WLAN), wireless sensors should be deployed so that they monitor the range of the WLANs. Many organizations also want to deploy sensors to monitor parts of their facilities where there should be no WLAN activity, as well as channels and bands that the organization’s WLANs should not use. Other considerations for selecting sensor locations include physical security, sensor range, wired network connection availability, cost, and AP and wireless switch locations.

Wireless IDPSs provide several types of security capabilities. Most can collect information on observed wireless devices and WLANs and perform extensive logging of event data. Wireless IDPSs can detect attacks, misconfigurations, and policy violations at the WLAN protocol level. Organizations should use wireless IDPS products that use a combination of detection techniques to achieve broader and more accurate detection. Examples of events detected by wireless IDPSs are unauthorized WLANs and WLAN devices, poorly secured WLAN devices, unusual usage patterns, the use of active wireless network scanners, denial of service attacks, and impersonation and man-in-the-middle attacks. Most wireless IDPS sensors can also identify the physical location of a detected threat by using triangulation.

Compared to other forms of IDPS, wireless IDPS is generally more accurate; this is largely due to its limited scope (analyzing wireless networking protocols). Wireless IDPSs usually require some tuning and customization to improve their detection accuracy. The main effort is in specifying which WLANs, APs, and STAs are authorized, and in entering the policy characteristics into the wireless IDPS software. Besides reviewing tuning and customizations periodically to ensure that they are still accurate, administrators should also ensure that changes to building plans are incorporated occasionally. This is needed for accurate identification of the physical location of threats and accurate planning of sensor deployments.

Although wireless IDPSs offer robust detection capabilities, they do have some significant limitations. Wireless IDPSs cannot detect certain types of attacks against wireless networks, such as attacks involving passive monitoring and offline processing of wireless traffic. Wireless IDPSs are also susceptible to evasion techniques, especially those involving knowledge of a product’s channel scanning scheme. Channel scanning can also impact network forensics because each sensor sees only a fraction of the activity on each channel. Wireless IDPS sensors are also susceptible to denial of service attacks and physical attacks.

Wireless IDPS sensors can offer intrusion prevention capabilities. Some sensors can instruct endpoints to terminate a session and prevent a new session from being established. Some sensors can instruct a switch on the wired network to block network activity for a particular wireless endpoint; however, this method can only block wired network communications and will not stop an endpoint from continuing to perform malicious actions through wireless protocols. Most IDPS sensors allow administrators to specify the prevention capability configuration for each type of alert. Prevention actions can affect sensor monitoring; for example, if a sensor is transmitting signals to terminate connections, it may not be able to perform channel scanning to monitor other communications until it has completed the prevention action. To mitigate this, some sensors have two radios—one for monitoring and detection, and another for performing prevention actions. When selecting sensors, organizations should consider what prevention actions may need to be performed and how the sensor’s detection capabilities could be affected by performing prevention actions.

This page has been left blank intentionally.

A network behavior analysis (NBA) system examines network traffic or statistics on network traffic to identify unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain forms of malware (e.g., worms, backdoors), and policy violations (e.g., a client system providing network services to other systems).³⁹ This section provides a detailed discussion of NBA technologies. First, it covers the major components of the NBA technologies and explains the architectures typically used for deploying the components. It also examines the security capabilities of the technologies in depth, including the methodologies they use to identify suspicious activity. The rest of the section discusses the management capabilities of the technologies, including recommendations for implementation and operation.

This section describes the major components of typical NBA solutions and illustrates the most common network architectures for these components. It also provides recommendations for the placement of certain components.

NBA solutions usually have sensors and consoles, with some products also offering management servers (which are sometimes called analyzers). NBA sensors are usually available only as appliances. Some sensors are similar to network-based IDPS sensors in that they sniff packets to monitor network activity on one or a few network segments. Other NBA sensors do not monitor the networks directly, but instead rely on network flow information provided by routers and other networking devices. Flow refers to a particular communication session occurring between hosts. There are many standards for flow data formats, including NetFlow⁴⁰ and sFlow.⁴¹ Typical flow data particularly relevant to intrusion detection and prevention includes the following:

As with a network-based IDPS, a separate management network or the organization’s standard networks can be used for NBA component communications. If sensors that collect network flow data from other devices are used, the entire NBA solution can be logically separated from the standard networks. Figure 6-1 shows an example of an NBA network architecture.

Figure 6-1. NBA Sensor Architecture Example

In addition to choosing the appropriate network for the components, administrators also need to decide where the sensors should be located. Most NBA sensors can be deployed in passive mode only, using the same connection methods (e.g., network tap, switch spanning port) as network-based IDPSs. Passive sensors that are performing direct network monitoring should be placed so that they can monitor key network locations, such as the divisions between networks, and key network segments, such as demilitarized zone (DMZ) subnets. Inline sensors are typically intended for network perimeter use, so they would be deployed in close proximity to the perimeter firewalls, often between the firewall and the Internet border router to limit incoming attacks that could overwhelm the firewall.

NBA products provide a variety of security capabilities. Sections 6.2.1 through 6.2.4 describe common security capabilities, divided into four categories: information gathering, logging, detection, and prevention, respectively. Some NBA products also provide security information and event management (SIEM) capabilities; see Section 8.2.2 for information on SIEM.

NBA technologies offer extensive information gathering capabilities, because knowledge of the characteristics of the organization’s hosts is needed for most of the NBA product’s detection techniques. NBA sensors can automatically create and maintain lists of hosts communicating on the organization’s monitored networks. They can monitor port usage, perform passive fingerprinting, and use other techniques to gather detailed information on the hosts. (As described in Section 6.2.3.1, most products also allow administrators to specify detailed firewall ruleset-like policies for host-to-host communications, including permitted or forbidden port numbers.) Information typically collected for each host includes the following:

NBA sensors constantly monitor network activity for changes to this information. Additional information on each host’s flows is also collected on an ongoing basis; this is discussed in Section 6.2.3.

NBA technologies typically perform extensive logging of data related to detected events. This data can be used to confirm the validity of alerts, to investigate incidents, and to correlate events between the NBA solution and other logging sources. Data fields commonly logged by NBA software include the following:

Some NBA sensors that directly monitor network traffic are able to log limited payload information from packets, such as authenticated user identifiers. This allows actions to be traced to specific user accounts.

NBA technologies typically have the capability to detect several types of malicious activity. Most products use primarily anomaly-based detection, along with some stateful protocol analysis techniques, to analyze network flows. Most NBA technologies offer no signature-based detection capability, other than allowing administrators to manually set up custom filters that are essentially signatures to detect or stop specific threats. This section discusses the following aspects of NBA software detection capabilities:

The types of events most commonly detected by NBA sensors include the following:

Most NBA sensors can reconstruct a series of observed events to determine the origin of a threat. For example, if worms infect a network, NBA sensors can analyze the worm’s flows and find the host on the organization’s network that first transmitted the worm to other hosts.

Because NBA sensors work primarily by detecting significant deviations from normal behavior, they are most accurate at detecting attacks that generate large amounts of network activity in a short period of time (e.g., DDoS attacks) and attacks that have unusual flow patterns (e.g., worms spreading among hosts). NBA sensors are less accurate at detecting small-scale attacks, particularly if they are conducted slowly and if they do not violate the administrator-set policies (e.g., the attack uses common ports and protocols).

Detection accuracy also varies over time. Because NBA technologies use primarily anomaly-based detection methods, they cannot detect many attacks until they reach a point where their activity is significantly different from what is expected. If a DoS attack starts slowly and increases in volume over time, it is likely to be detected by NBA sensors, but the point during the attack at which the NBA software detects it may vary considerably among NBA products. By configuring sensors to be more sensitive to anomalous activity, alerts will be generated more quickly when attacks occur, but more false positives are also likely to be triggered. Conversely, if sensors are configured to be less sensitive to anomalous activity, there will be fewer false positives, but alerts will be generated more slowly, allowing attacks to occur for longer periods of time.

False positives can also be caused by benign changes in the environment. For example, if a new service is added to a host and a few hosts start using it, an NBA sensor is likely to detect this as anomalous. However, typically this would be a low-priority alert, and not reported as an attack, so it is debatable whether this can truly be considered a false positive. If a major service is moved from one host to another and a thousand hosts start using it one day, that might inadvertently trigger an alert.

NBA technologies rely primarily on observing network traffic and developing baselines of expected flows and inventories of host characteristics. NBA products automatically update their baselines on an ongoing basis. As a result, typically there is not much tuning or customization to be done, other than updating firewall ruleset-like policies that are offered by most products. Also, administrators might adjust thresholds periodically (e.g., how much additional bandwidth usage should trigger an alert) to take into account changes to the environment. Thresholds can often be set on a per-host basis or for administrator-defined groups of hosts. Most NBA products also offer whitelist and blacklist capabilities for hosts and services. Another common feature of NBA products is customization of each alert (e.g., specifying which prevention option it should trigger). Unlike network-based IDPSs, code editing features are generally not applicable to NBA products.

A few NBA products offer limited signature-based detection capabilities. The supported signatures tend to be very simple, and primarily look for particular values in certain IP, TCP, UDP, or ICMP header fields. This capability is most helpful for inline NBA sensors because they can use the signatures to find and block attacks that a firewall or router might not be capable of blocking. For example, suppose that there is a DDoS attack that uses a flood of specially crafted HTTP traffic against a Web server. A firewall or router might not be able to block the attack without blocking all HTTP activity to the Web server, but an inline NBA sensor could be configured with a customized signature to block just the attack activity if it has a unique set of characteristics. On the other hand, an inline NBA sensor might be able to block the attack anyway because of its flow patterns.

Besides reviewing tuning and customizations periodically to ensure that they are still accurate, administrators should also ensure that significant changes to hosts, such as new hosts and new services, are reflected in NBA settings. Although it might not feasible to automatically link NBA systems with change management systems, administrators could review change management records regularly and adjust host inventory information in the NBA to prevent false positives.

NBA technologies offer strong detection capabilities for certain types of threats, but they also have significant limitations. Some of these limitations are described in Section 6.2.3.2. An important limitation is the delay in detecting attacks. Some delay is inherent in anomaly detection methods that are based on deviations from a baseline, such as increased bandwidth usage or additional connection attempts. However, NBA technologies often have additional delay caused by their data sources, especially when they rely on flow data from routers and other network devices. This data is often transferred to the NBA system in batches; depending on the product’s capabilities, network capacity, and administrator preferences, this could occur relatively frequently (e.g., every minute, every two minutes) or relatively infrequently (e.g., every 15 minutes, every 30 minutes). Because of this delay, attacks that occur quickly, such as malware infestations and DoS attacks, may not be detected until they have already disrupted or damaged systems.

This delay can be avoided by using sensors that do their own packet captures and analysis instead of relying on flow data from other devices. However, performing packet captures and analysis is much more resource-intensive than analyzing flow data. A single sensor can analyze flow data from many networks, or perform direct monitoring (packet captures) itself generally for a few networks at most. Therefore, to do direct monitoring instead of using flow data, organizations might have to purchase more powerful sensors and/or more sensors.

NBA sensors offer various intrusion prevention capabilities, including the following (grouped by sensor type):

Most NBA sensors allow administrators to specify the prevention capability configuration for each type of alert. This usually includes enabling or disabling prevention, as well as specifying which type of prevention capability should be used. Most NBA system implementations use prevention capabilities in a limited fashion or not at all because of false positives; blocking a single false positive could cause major disruptions in network communications. Prevention capabilities are most often used for NBA sensors when blocking a specific known threat, such as a new worm.

Most NBA products offer similar management capabilities. This section discusses major aspects of management—implementation, operation, and maintenance—and provides recommendations for performing them effectively and efficiently.

Once an NBA product has been selected, the administrators need to design an architecture, perform NBA component testing, secure the NBA components, and then deploy them. The only addition to the material presented in Section 3.3.1 involves component testing and deployment. When NBA components are being deployed to production networks, organizations should typically install the sensors in a relatively short period of time, so that they can all build their inventories and generate their initial baselines at the same time. Detection accuracy is likely to be decreased during implementation and initial usage because the sensors will have substantially incomplete information about their environment until they have monitored it for days or weeks. Other than that, deployment of NBA sensors and consoles is essentially the same as it is for network-based IDPS sensors and consoles.

NBA products are designed to be operated and maintained through consoles, which typically have very similar capabilities to the consoles for network-based IDPSs. A key difference is that NBA consoles usually offer visualization tools that can display the flow of attacks through an organization’s networks. These tools can show a user which hosts were affected by an attack, the sequence of hosts that an attack passed through, and the first host to be involved in the attack. Some NBA products also offer command-line interfaces.

Ongoing maintenance of NBA products is also very similar to that for network-based IDPSs. The primary exception is the application of updates. Because most NBA products do not use signatures, administrators only need to test and apply updates to the NBA software itself. Because NBA sensors are appliance-based, updating them usually involves replacing an existing CD and either rebooting the sensor or installing software from the CD. For NBA products that do have signature capabilities, administrators should also acquire, test, and apply signature updates in the same way that network-based IDPS signature updates are performed.

A network behavior analysis (NBA) system examines network traffic or statistics on network traffic to identify unusual traffic flows. NBA solutions usually have sensors and consoles, with some products also offering management servers. Some sensors are similar to network-based IDPS sensors in that they sniff packets to monitor network activity on one or a few network segments. Other NBA sensors do not monitor the networks directly, but instead rely on network flow information provided by routers and other networking devices.

Most NBA sensors can be deployed in passive mode only, using the same connection methods (e.g., network tap, switch spanning port) as network-based IDPSs. Passive sensors that are performing direct network monitoring should be placed so that they can monitor key network locations, such as the divisions between networks, and key network segments, such as DMZ subnets. Inline sensors are typically intended for network perimeter use, so they would be deployed in close proximity to the perimeter firewalls, often in front to limit incoming attacks that could overwhelm the firewalls.

NBA products provide a variety of security capabilities. They offer extensive information gathering capabilities, collecting detailed information on each observed host and constantly monitoring network activity for changes to this information. NBA technologies typically perform extensive logging of data related to detected events. They also typically have the capability to detect several types of malicious activity, including DoS attacks, scanning, worms, unexpected application services, and policy violations, such as a client system providing network services to other systems. Because NBA sensors work primarily by detecting significant deviations from normal behavior, they are most accurate at detecting attacks that generate large amounts of network activity in a short period of time and attacks that have unusual flow patterns. Most NBA sensors can also reconstruct a series of observed events to determine the origin of a threat.

NBA products automatically update their baselines on an ongoing basis. As a result, typically there is not much tuning or customization to be done, other than updating firewall ruleset-like policies that most products support. A few NBA products offer limited signature customization capabilities; these are most helpful for inline sensors because they can use the signatures to find and block attacks that a firewall or router might not be capable of blocking. Besides reviewing tuning and customizations periodically to ensure that they are still accurate, administrators should also ensure that significant changes to hosts are incorporated, such as new hosts and new services. Generally it is not feasible to automatically link NBA systems with change management systems, but administrators could review change management records regularly and adjust host inventory information in the NBA to prevent false positives.

NBA technologies have some significant limitations. They are delayed in detecting attacks because of their data sources, especially when they rely on flow data from routers and other network devices. This data is often transferred to the NBA in batches from every minute to a few times an hour. Attacks that occur quickly may not be detected until they have already disrupted or damaged systems. This delay can be avoided by using sensors that do their own packet captures and analysis; however, this is much more resource-intensive than analyzing flow data. Also, a single sensor can analyze flow data from many networks, while a single sensor can generally directly monitor only a few networks at once. Therefore, to do direct monitoring instead of using flow data, organizations might have to purchase more powerful sensors and/or more sensors.

A host-based IDPS monitors the characteristics of a single host and the events occurring within that host for suspicious activity. Examples of the types of characteristics a host-based IDPS might monitor are wired and wireless network traffic (only for that host), system logs, running processes, file access and modification, and system and application configuration changes. This section provides a detailed discussion of host-based IDPS technologies. First, it covers the major components of the technologies and explains the architectures typically used for deploying the components. It also examines the security capabilities of the technologies in depth, including the methodologies they use to identify suspicious activity. The rest of the section discusses the management capabilities of the technologies, including recommendations for implementation and operation.

This section describes the major components of typical host-based IDPSs and illustrates the most common network architectures for these components. It also provides recommendations for selecting which hosts should use host-based IDPSs. This section also describes how host-based IDPSs can affect a host’s internal architecture, such as intercepting process calls.

Most host-based IDPSs have detection software known as agents installed on the hosts of interest. Each agent monitors activity on a single host and if IDPS capabilities are enabled, also performs prevention actions. Section 7.2.2 discusses the types of activity monitored by host-based IDPSs. The agents transmit data to management servers, which may optionally use database servers for storage.⁴² Consoles are used for management and monitoring.

Some host-based IDPS products use dedicated appliances running agent software instead of installing agent software on individual hosts. Each appliance is positioned to monitor the network traffic going to and from a particular host. Technically, these appliances could be considered network-based IDPSs, because they are deployed inline to monitor network traffic. However, they usually monitor activity for only one specific type of application, such as a Web server or database server, so they are more specialized than a standard network-based IDPS. Also, the software running on the appliance often has the same or similar functionality as the host-based agents. Therefore, host-based IDPS products using appliance-based agents are included in this section.

Each agent is typically designed to protect one of the following:

Most products do not have agents for other types of hosts, such as network devices (e.g., firewalls, routers, switches).

The network architecture for host-based IDPS deployments is typically very simple. Because the agents are deployed to existing hosts on the organization’s networks, the components usually communicate over those networks instead of using a separate management network. Most products encrypt their communications, preventing eavesdroppers from accessing sensitive information. Appliance-based agents are typically deployed inline immediately in front of the hosts that they are protecting. Figure 7-1 shows an example of a host-based IDPS deployment architecture.

Figure 7-1. Host-Based IDPS Agent Deployment Architecture Example

Host-based IDPS agents are most commonly deployed to critical hosts such as publicly accessible servers and servers containing sensitive information. However, because agents are available for various server and desktop/laptop operating systems, as well as specific server applications, organizations could potentially deploy agents to most of their servers and desktops/laptops. Some organizations use host-based IDPS agents primarily to analyze activity that cannot be monitored by other security controls. For example, network-based IDPS sensors cannot analyze the activity within encrypted network communications, but host-based IDPS agents installed on endpoints can see the unencrypted activity. Organizations should consider the following additional criteria when selecting agent locations:

To provide intrusion prevention capabilities, most IDPS agents alter the internal architecture of the hosts on which they are installed. This is typically done through a shim, which is a layer of code placed between existing layers of code. A shim intercepts data at a point where it would normally be passed from one piece of code to another. The shim can then analyze the data and determine whether or not it should be allowed or denied. Host-based IDPS agents may use shims for several types of resources, including network traffic, filesystem activity, system calls, Windows registry activity, and common applications (e.g., e-mail, Web).

Some host-based IDPS agents do not alter the host architecture. Instead, they monitor activity without shims, or they analyze the artifacts of activity, such as log entries and file modifications. Although less intrusive to the host, reducing the possibility of the IDPS interfering with the host’s normal operations, these methods are also generally less effective at detecting threats and often cannot perform any prevention actions.

One of the important decisions in selecting a host-based IDPS solution is whether to install agents on hosts or use agent-based appliances. From a detection and prevention perspective, installing agents on hosts is generally preferable because the agents have direct access to the hosts’ characteristics, often allowing them to perform more comprehensive and accurate detection and prevention. However, agents often support only a few common OSs; if a host does not use a supported OS, an appliance can be deployed instead. Another reason to use an appliance instead of installing an agent on a host is performance; if an agent would negatively impact the performance of the monitored host too much, it might be necessary to offload the agent’s functions to an appliance.

Host-based IDPSs provide a variety of security capabilities. Sections 7.2.1 through 7.2.4 describe common security capabilities, divided into four categories: logging, detection, prevention, and other, respectively.

Host-based IDPSs typically perform extensive logging of data related to detected events. This data can be used to confirm the validity of alerts, to investigate incidents, and to correlate events between the host-based IDPS and other logging sources. Data fields commonly logged by host-based IDPSs include the following:

Most host-based IDPSs have the capability to detect several types of malicious activity. They often use a combination of signature-based detection techniques to identify known attacks, and anomaly-based detection techniques with policies or rulesets to identify previously unknown attacks. This section discusses the following aspects of host-based IDPS detection capabilities:

The types of events detected by host-based IDPSs vary considerably based primarily on the detection techniques that they use. Some host-based IDPS products offer several of these detection techniques, while others focus on a few or one. For example, several products only analyze network traffic, and other products only check the integrity of a host’s critical files. Specific techniques commonly used in host-based IDPSs include the following:

Organizations should determine which aspects of hosts need to be monitored and select IDPS products that provide adequate monitoring and analysis for them.

Because host-based IDPSs often have extensive knowledge of hosts’ characteristics and configurations, a host-based IDPS agent can often determine whether or not an attack against a host would succeed if not stopped. Agents can use this knowledge to select prevention actions and to assign appropriate priorities to alerts.

Like any other IDPS technology, host-based IDPSs often cause false positives and false negatives. However, the accuracy of detection is more challenging for host-based IDPSs because several of the possible detection techniques, such as log analysis and filesystem monitoring, do not have knowledge of the context under which detected events occurred. For example, a host may be rebooted, a new application installed, or a system file replaced. These actions could be done by malicious activity, or they could be part of normal host operation and maintenance. The events themselves are detected accurately, but their benign or malicious nature cannot always be determined without additional context. Some products, particularly those intended for desktop/laptop use, prompt users to provide context, such as whether or not the user is currently upgrading a particular application. If a user does not respond to the prompt in a set period of time (typically a few minutes), the agent chooses a default action (allow or deny).

Host-based IDPSs that use combinations of several detection techniques should generally be capable of achieving more accurate detection than products that use one or a few techniques. Because each technique can monitor different aspects of a host, using more techniques allows agents to collect more information on the activities occurring. This provides a more complete picture of the events, and may also provide additional context that can be helpful in assessing the intent of certain events.

Host-based IDPSs usually require considerable tuning and customization. For example, many rely on observing host activity and developing baselines or profiles of expected behavior. Others need to be configured with detailed policies that define exactly how each application on a host should behave. As the host environment changes, administrators should ensure that host-based IDPS policies are updated to take those changes into account. Generally it is not feasible to automatically link host-based IDPSs with change management systems, but administrators could review change management records regularly and adjust host configuration and policy information in the host-based IDPS to prevent false positives.

Policies can often be set on a per-host basis or for groups of hosts, which provides flexibility. Some products also permit multiple policies to be configured on a host for multiple environments; this is most helpful for hosts that function in multiple environments, such as a laptop used both within an organization and from external locations. Host-based IDPSs also offer whitelist and blacklist capabilities for hosts (e.g., IP addresses of other hosts with which a host might communicate), applications, ports, filenames, and other host characteristics. In fact, some products automatically update agents with the latest whitelist and blacklist information, based on reports from other agents of newly detected malicious activity. Another common feature of host-based IDPSs is customizing each alert, such as specifying which response option should be performed for an alert.

The sophistication of signature capabilities for host-based IDPSs varies widely depending on the detection techniques used by each product.

Host-based IDPSs have some significant limitations. Some of these limitations are described in Section 7.2.2.2. Other important limitations include the following:

Host-based IDPS agents offer various intrusion prevention capabilities. Because the capabilities vary based on the detection techniques used by each product, the following items describe the capabilities by detection technique.

Other host-based IDPS detection techniques, such as log analysis, network configuration monitoring, and file integrity and attribute checking, generally do not support prevention actions because they identify events well after they have occurred.

Some host-based IDPSs offer non-IDPS capabilities such as antivirus software, spam filtering, and Web or e-mail content filtering. It is outside the scope of this guide to discuss these capabilities, which are often provided by bundling separate products with the IDPS software. This section focuses on those additional product capabilities that are more closely tied to host-based IDPS functionality. Examples of these capabilities are as follows:

Most host-based IDPSs offer similar management capabilities. This section discusses major aspects of management—implementation, operation, and maintenance—and provides recommendations for performing them effectively and efficiently.

Once a host-based IDPS product has been selected, the administrators need to design an architecture, perform IDPS component testing, secure the IDPS components, and then deploy them. The following items list additions to the material presented in Section 3.3.1:

Host-based IDPSs should be operated according to the recommendations presented in Section 3.3.2. The only exception is in updating the agents. Some agents can periodically check the management server for updates and automatically retrieve and install or apply those updates. Other agents cannot do this, requiring an administrator to manually check for, transfer, and install or apply updates. In many cases, an agent’s update capability is related to the type of operating system on which it is deployed.

Host-based IDPSs monitors the characteristics of a single host and the events occurring within that host for suspicious activity. Examples of the types of characteristics a host-based IDPS might monitor are wired and wireless network traffic, system logs, running processes, file access and modification, and system and application configuration changes. Most host-based IDPSs have detection software known as agents installed on the hosts of interest. Each agent monitors activity on a single host and if prevention capabilities are enabled, also performs prevention actions. The agents transmit data to management servers. Each agent is typically designed to protect a server, a desktop or laptop, or an application service.

The network architecture for host-based IDPS deployments is typically very simple. Because the agents are deployed to existing hosts on the organization’s networks, the components usually communicate over those networks instead of using a management network. Host-based IDPS agents are most commonly deployed to critical hosts such as publicly accessible servers and servers containing sensitive information. However, because agents are available for various server and desktop/laptop operating systems, as well as specific server applications, organizations could potentially deploy agents to most of their servers and desktops/laptops. Organizations should consider several criteria when selecting agent locations, including the need to analyze activity that cannot be monitored by other security controls; the cost of the agents’ deployment, maintenance, and monitoring; the OSs and applications supported by the agents; the importance of each host’s data or services; and the ability of the network infrastructure to support the agents’ communications.

Most IDPS agents alter the internal architecture of the hosts on which they are installed through shims, which are layers of code placed between existing layers of code. Although it is less intrusive to the host to perform monitoring without shims, which reduces the possibility of the IDPS interfering with the host’s normal operations, monitoring without shims is also generally less accurate at detecting threats and often precludes the performance of effective prevention actions.

Host-based IDPSs provide a variety of security capabilities. They typically perform extensive logging of data related to detected events and can detect several types of malicious activity. Detection techniques used include code analysis, network traffic analysis, network traffic filtering, filesystem monitoring, log analysis, and network configuration monitoring. Host-based IDPSs that use combinations of several detection techniques should generally be capable of achieving more accurate detection than products that use one or a few techniques, because each technique can monitor different characteristics of hosts. Organizations should determine which characteristics need to be monitored and select IDPS products that provide adequate monitoring and analysis of those characteristics.

Host-based IDPSs usually require considerable tuning and customization. For example, many rely on observing host activity and developing baselines or profiles of expected behavior. Others need to be configured with detailed policies that define exactly how each application on a host should behave. As the host environment changes, administrators should ensure that host-based IDPS policies are updated to take those changes into account.

Host-based IDPSs have some significant limitations. Some detection techniques are performed only periodically, such as hourly or a few times a day, to identify events that have already happened, causing significant delay in identifying certain events. Also, many host-based IDPSs forward their alert data to the management servers in batches a few times an hour, which can cause delays in initiating response actions. Because host-based IDPSs run agents on the hosts being monitored, they can impact host performance because of the resources the agents consume. Installing an agent can also cause conflicts with existing host security controls, such as personal firewalls and VPN clients. Agent upgrades and some configuration changes can also necessitate rebooting the monitored hosts.

Host-based IDPSs offer various intrusion prevention capabilities; these vary based on the detection techniques used by each product. Code analysis techniques can prevent code from being executed; this can be very effective at stopping both known and previously unknown attacks. Network traffic analysis can stop incoming and outgoing network traffic containing network, transport, or application layer attacks, wireless networking protocol attacks, and the use of unauthorized applications and protocols. Network traffic filtering works as a host-based firewall and stops unauthorized access and acceptable use policy violations. Filesystem monitoring can prevent files from being accessed, modified, replaced, or deleted, which can stop malware installation and other attacks involving inappropriate file access. Other host-based IDPS detection techniques generally do not support prevention actions because they identify events well after they have occurred.

Some host-based IDPSs offer additional capabilities related to intrusion detection and prevention, such as enforcing restrictions on the use of removable media, detecting the activation or use of audiovisual devices, automatically hardening hosts on an ongoing basis, monitoring the status of running processes and restarting failed ones, and performing network traffic sanitization.

This page has been left blank intentionally.

As Sections 4 through 7 have explained, the four primary types of IDPS technologies—network-based, wireless, network behavior analysis (NBA), and host-based—each offer fundamentally different information gathering, logging, detection, and prevention capabilities. Each technology type offers benefits over the other, such as detecting some events that the others cannot, detecting some events with significantly greater accuracy than the other technologies, and performing in-depth analysis without significantly impacting the performance of the protected hosts. Accordingly, organizations should consider using multiple types of IDPS technologies to achieve more comprehensive and accurate detection and prevention of malicious activity, with lower rates of false positives and false negatives. This section provides guidance on using multiple IDPS technologies to create a broader IDPS solution and discusses the advantages and disadvantages of using multiple technologies.

Organizations that are planning to use multiple types of IDPS technologies, or even multiple products within a single IDPS technology class, should consider whether or not the IDPS products should be integrated in some way, either working together directly or feeding their data into a centralized logging system or security information and event management system. This section explains how different IDPS products can be integrated, and the benefits and limitations of the integration methods. It also provides overviews of other technologies that complement IDPS technologies and discusses how they can be included in an IDPS solution to further improve detection and prevention.

In many environments, a robust IDPS solution cannot be achieved without using multiple types of IDPS technologies. For example, network-based IDPSs cannot monitor wireless protocols, and wireless IDPSs cannot monitor application protocol activity. Table 8-1 provides a high-level comparison of the four primary IDPS technology types. The strengths listed in the table indicate the roles or situations in which each technology type is generally superior to the others. A particular technology type may have additional benefits over others, such as logging additional data that would be useful for validating alerts recorded by other IDPSs, or preventing intrusions that other IDPSs cannot because of technology capabilities or placement (e.g., on the host instead of on the network).

Table 8-1. Comparison of IDPS Technology Types

For most environments, a combination of network-based and host-based IDPSs is needed for an effective IDPS solution. Wireless IDPSs may also be needed if the organization determines that its wireless networks need additional monitoring or if the organization wants to ensure that rogue wireless networks are not in use in the organization’s facilities. NBA products can also be deployed if organizations desire additional detection capabilities for denial of service (DoS) attacks, worms, and other threats as discussed in Section 6.

In addition to using multiple types of IDPS technologies, some organizations also use multiple products of the same IDPS technology type. This is often done to improve detection capabilities. Because each product uses somewhat different detection methodologies and detects some events that another product cannot, using multiple products can allow for more comprehensive detection of possible incidents. Also, having multiple products in use, particularly to monitor the same activity, makes it easier for analysts to confirm the validity of alerts and identify false positives, and also provides redundancy, should one product fail for any reason.

Many organizations use multiple IDPS products, usually from different vendors (most vendors make products in only one IDPS technology type). By default, these products function completely independently of each other. This has some notable benefits, such as minimizing the impact that a failure or compromise of one IDPS product has on other IDPS products. However, if the products are not integrated in any way, the effectiveness of the entire IDPS implementation may be somewhat limited. Data cannot be shared by the products, and IDPS users and administrators may have to expend extra effort to monitor and manage multiple sets of products. IDPS products can be directly integrated, such as one product feeding alert data to another product, or they can be indirectly integrated, such as all the IDPS products feeding alert data into a security information and event management system. Sections 8.2.1 and 8.2.2 discuss the benefits and limitations of direct and indirect integration, respectively.

Direct IDPS integration is most often performed when an organization uses multiple IDPS products from a single vendor. For example, some vendors offer both network-based and host-based products. These vendors frequently offer a single console that can be used to manage and monitor both types of products. This can provide significant time savings to administrators and users because it streamlines their work. Some products also share data; for example, a product might use host-based IDPS data to determine if an attack detected by network-based IDPS sensors was successful, or if an attack stopped by network-based IDPS data would have been successful if allowed to pass. This information can speed the analysis process and help users to better prioritize threats. The primary disadvantage of using a fully integrated solution is that a failure or compromise could endanger all the IDPS technologies that are part of the integrated solution.

A more limited form of direct IDPS integration is having one IDPS product provide data for another IDPS product. As mentioned previously, two products from the same vendor often share data with each other for correlation purposes. Data can also be shared among products from different vendors, although typically this simply involves one product providing data as input to the second product. For example, a network-based IDPS could potentially provide network flow information to an NBA sensor. A host-based IDPS could provide system configuration information to NBA or network-based IDPS sensors. This data can be used for event correlation and better prioritization of alerts.

Indirect IDPS integration is usually performed with security information and event management (SIEM) software.⁴⁵ SIEM software is designed to import information from various security-related logs and correlate events among them.⁴⁶ Log types commonly supported by SIEM software include IDPSs, firewalls, antivirus software, and other security software; OSs (e.g., audit logs); application servers (e.g., Web servers, e-mail servers); and even physical security devices such as badge readers. SIEM software generally works by receiving copies of the logs from the logging hosts over secure network channels, converting the log data into standard fields and values (known as normalization), then identifying related events by matching IP addresses, timestamps, usernames, and other characteristics.⁴⁷ SIEM products can identify malicious activity such as attacks and malware infections, as well as misuse and inappropriate usage of systems and networks. Some SIEM software can also initiate prevention responses for designated events. SIEM products usually do not generate original event data; instead, they generate meta-events based on their analysis of the imported event data.

Ways in which SIEM software complements IDPSs include the following:

Limitations of SIEM software in the context of IDPS include the following:

An alternative to using SIEM software for centralized logging is to use a solution based primarily on the syslog protocol.⁴⁸ Syslog provides a simple framework for log generation, storage, and transfer that any IDPS could use if designed to do so. Some IDPSs offer features that allow their log formats to be converted to syslog format. Syslog is very flexible for log sources, because each syslog entry contains a content field into which logging sources can place information in any format. However, this flexibility makes analysis of the log data challenging. Each IDPS may use many different formats for its log messages, so a robust analysis program would need to be familiar with each format and be able to extract the meaning of the data within the fields of each format. It might not be feasible to understand the meaning of all log messages, so analysis might be limited to keyword and pattern searches. Generally, the use of syslog for centralized collection and analysis of IDPS logs does not provide sufficiently strong analysis capabilities to support incident identification and handling.

In addition to dedicated IDPS technologies, organizations typically have several other types of technologies that offer some IDPS capabilities and complement the primary IDPSs. This section discusses common types of complementary technologies: network forensic analysis tools, anti-malware technologies (antivirus software and antispyware software), firewalls and routers, and honeypots.⁴⁹ For each, a brief overview of the technology is provided, and its use in intrusion detection and prevention and its relationship to IDPSs are explained. Recommendations are also made as applicable for how the complementary technologies should be used alongside of IDPSs.

Network forensic analysis tools (NFAT) focus primarily on collecting and analyzing wired network traffic. Unlike a network-based IDPS, which performs in-depth analysis and stores only the necessary network traffic, an NFAT typically stores most or all of the traffic that it sees, and then performs analysis on that stored traffic. In addition to its forensic capabilities, NFAT software also offers features that facilitate network traffic analysis, such as the following:

This makes it more valuable for network forensics and less valuable for intrusion detection and prevention than a typical network-based IDPS.

Ways in which NFAT software complements IDPSs include the following:

Limitations of NFAT software in the context of IDPS include the following:

The most commonly used technical control for malware threat mitigation is antivirus software. Types of malware that it can detect include viruses, worms, Trojan horses, malicious mobile code, and blended threats, as well as attacker tools such as keystroke loggers and backdoors. Antivirus software typically monitors critical OS components, filesystems, and application activity for signs of malware, and attempts to disinfect or quarantine files that contain malware. Most organizations deploy antivirus software both centrally (e.g., e-mail servers, firewalls) and locally (e.g., file servers, desktops, laptops) so that all major malware entry vectors can be monitored.

Another commonly used control for malware threat mitigation is spyware detection and removal utilities, also known as antispyware software. They are similar to antivirus software, but they focus on detecting both malware and non-malware forms of spyware, such as malicious mobile code and tracking cookies, and spyware installation techniques such as unauthorized Web browser plug-in installations, popup ads, and Web browser hijacking.

Both antivirus and antispyware products detect threats primarily through signature-based analysis. To identify previously unknown threats, they also use heuristic techniques that examine activity for certain suspicious characteristics. The product vendors create and release additional signatures when new threats emerge, so that the products can detect them.

Ways in which antivirus and antispyware software complements IDPSs include the following:

Limitations of antivirus and antispyware software in the context of IDPS include the following:

Firewalls (network-based and host-based) and routers filter network traffic based on TCP/IP characteristics such as the source and destination IP addresses, the transport layer protocol (e.g., TCP, UDP, ICMP), and basic protocol information (e.g., TCP or UDP port numbers, ICMP type and code). Most firewalls and routers log which connections or connection attempts they block; the blocked activity is often generated by unauthorized access attempts from automated attack tools, port scanning, and malware. Some network-based firewalls also act as proxies. When a proxy is used, each successful connection attempt actually results in the creation of two separate connections: one between the client and the proxy server, and another between the proxy server and the true destination. Many proxies are application-specific, and some actually perform some analysis and validation of common application protocols, such as HTTP. The proxy may reject client requests that appear to be invalid (which could include some forms of attacks) and log information regarding these requests.

Ways in which firewalls and routers complement IDPSs include the following:⁵⁰

Limitations of firewalls and routers in the context of IDPS include the following:

Some organizations are sufficiently concerned with detecting the earliest signs of widespread incidents, such as major new worms, that they deploy deceptive measures such as honeypots so that they can collect better data on these threats. Honeypots are hosts that have no authorized users other than the honeypot administrators because they serve no business function; all activity directed at them is considered suspicious. Attackers will scan and attack honeypots, giving administrators data on new trends and attack tools, particularly malware. However, honeypots are a supplement to, not a replacement for, other security controls such as intrusion detection and prevention systems. If honeypots are to be used by an organization, qualified incident handlers and intrusion detection analysts should manage them. The legality of honeypots has not been clearly established; therefore, organizations should carefully study the legal ramifications before planning any honeypot deployments.

The four primary types of IDPS technologies—network-based, wireless, NBA, and host-based—each offer fundamentally different information gathering, logging, detection, and prevention capabilities. Each technology type offers benefits over the other, such as detecting some events that the others cannot and detecting some events with significantly greater accuracy than the other technologies. Accordingly, organizations should consider using multiple types of IDPS technologies to achieve more comprehensive and accurate detection and prevention of malicious activity. In many environments, a robust IDPS solution cannot be achieved without using multiple types of IDPS technologies. For most environments, a combination of network-based and host-based IDPSs is needed for an effective IDPS solution. Wireless IDPSs may also be needed if the organization determines that its wireless networks need additional monitoring or if the organization wants to ensure that rogue wireless networks are not in use in the organization’s facilities. NBA technologies can also be deployed if organizations desire additional detection capabilities for DoS attacks, worms, and other threats that NBAs are particularly good at detecting.

Organizations that are planning to use multiple types of IDPS technologies, or even multiple products within a single IDPS technology class, should consider whether or not the IDPS products should be integrated in some way. Direct IDPS integration is most often performed when an organization uses multiple IDPS products from a single vendor, by having a single console that can be used to manage and monitor the multiple products. Some products can also share data, which can speed the analysis process and help users to better prioritize threats. A more limited form of direct IDPS integration is having one IDPS product provide data for another IDPS product, such as a network-based IDPS providing network flow information to an NBA sensor.

Indirect IDPS integration is usually performed with security information and event management (SIEM) software, which is designed to import information from various security-related logs and correlate events among them. SIEM software complements IDPSs in several ways, including correlating events logged by different technologies, displaying data from many event sources, and providing supporting information from other sources to help users verify the accuracy of IDPS alerts. An alternative to using SIEM software for centralized logging is the syslog protocol, which provides a simple standard framework for log generation, storage, and transfer that any IDPS can use if designed to do so. Syslog is very flexible for log sources, because each syslog entry contains a content field into which logging sources can place information in any format. However, this flexibility makes analysis of the log data challenging. Each IDPS may use many different formats for its log message content, so a robust analysis program would need to be familiar with each format and be able to extract the meaning of the data within the fields of each format. Generally, the use of syslog for centralized collection and analysis of IDPS logs does not provide sufficiently strong analysis capabilities to support incident identification and handling.

In addition to dedicated IDPSs, organizations typically have several other types of technologies that offer some IDPS capabilities and complement, but do not replace, the primary IDPSs. These include network forensic analysis tools, anti-malware technologies (antivirus software and antispyware software), and firewalls and routers.

This section provides guidance on selecting IDPS products. It first discusses the identification of general requirements that the IDPS products should meet. Next, it provides sets of criteria that can be used to evaluate four aspects of IDPS technologies: security capabilities, performance, management, and life cycle cost. Finally, the section concludes with a brief discussion of performing hands-on and paper evaluations of products, and when each evaluation technique is most appropriate. This section assumes that an organization has already determined that a particular type of IDPS technology—network-based, wireless, network behavior analysis (NBA), or host-based—is needed. A comparison of the technology types, which can be helpful for selecting the one most appropriate for a particular need, is provided in Section 8.

Organizations should use risk management techniques to identify the security controls necessary to mitigate risk to an acceptable level. Although it may be tempting to simply choose a product, using a risk management process to choose the most effective blend of controls enhances an organization’s security posture. An explanation of the risk management process is outside the scope of this document; NIST SP 800-30, Risk Management Guide for Information Technology Systems, contains additional information on it.

Before evaluating IDPS products, organizations should first define the general requirements that the IDPS solution and products should meet. The features provided by IDPS products and the methodologies that they use vary considerably, so a product that best meets one organization’s requirements might not be suitable for meeting another organization’s requirements. Also, a single IDPS product might not be able to meet all of an organization’s requirements for a particular type of IDPS technology (e.g., network-based), necessitating the use of multiple IDPS products of the same technology type. This is most common for large environments and for environments in which IDPS technologies serve multiple operational purposes.

Evaluators first need to understand the characteristics of the organization’s system and network environments, so that an IDPS can be selected that will be compatible with them and able to monitor the events of interest on the systems and/or networks. This knowledge is also needed to design the IDPS solution and determine how many components (e.g., sensors, agents) will be needed and where they will be deployed (e.g., which systems will run IDPS agents, which network segments will be monitored). Characteristics to consider include the following: