Link to the home page.
Print from PDF version
 

Security Disciplines for Objective 3: Detection and Recovery

3-1. Intrusion Detection System (IDS)

Description

Intrusion detection is the process of monitoring events occurring on a network or in a computer for evidence of intrusions, which can be unusual usage patterns or attempts to bypass security to compromise the integrity, availability, or confidentiality of a network or computer. An Intrusion Detection System (IDS) is just one of the many safeguards required to protect an organization’s information technology resources.

An IDS can be compared to a home alarm security system because they both provide an alert when an abnormal or predefined event occurs. IDS technology has evolved over the past 20 years, and IDSs currently available can identify the type of event that has taken place, when the event occurred, and in some cases, the sources of the intrusion. The more advanced IDSs provide the capability to program automated responses and deterrents to some alerts.

Purpose

IDS technology allows organizations to protect their systems from the ever-escalating threats that come from their growing dependence on information systems and network connectivity. IDS technology is by no means a total security solution. It represents a very necessary component in an organization’s arsenal of security tools.

IDSs are gaining acceptance as a vital addition to most organizations’ security infrastructures. Despite this growing acceptance, IT professionals still must struggle to justify the acquisition of IDS technology. An IDS will allow an organization to:

  • Detect probes or penetrations that are not prevented by other security measures.
  • Prevent problems by increasing the perceived possibility of being discovered, which is most effective with an organization’s employees.
  • Document the existing threat. This feature helps justify the cost of additional security measures.
  • Measure the effectiveness of current security infrastructure.
  • Collect useful information about intrusions that could direct recovery efforts and support civil or criminal legal remedies.

Principles

  • The risk to and value of information resources protected by the IDS deployed should be balanced against the cost of the system and the perceived vulnerabilities.
  • IDSs are designed to monitor and protect networks and host computers. Both capabilities are usually required to provide comprehensive detection.
  • IDSs should not run on the host and target systems they are designed to protect. Any attacker that successfully attacks a host or target system could simply disable the IDS.
  • Increased bandwidth on a network may equate to increased risk. An increase in raw bandwidth by a factor of ten means that an attack that would normally take ten days to accomplish can take place in one day. Intentionally slow attacks that are spread out over ten days can become much harder to detect because they can be imbedded in ten times more data.

Policies

IDSs are designed to detect attacks on network and host computers and to detect violations of internal system’s usage policies that should be documented as part of the security policy. A properly structured security policy is needed to serve as a template for determining how an organization’s IDS will be configured. The policy should explain in detail what the IDS operational staff is to do when a violation is reported and the violator is identified. The security policy should clearly define what system components, if any, can be accessed by the public and determine if there are any restrictions placed on the level of access for each component. The security policy should include any special legal, accreditation, or audit requirements that will impact the configuration of its IDS.

Best Practices

It is generally agreed that a properly configured IDS should include both host computer and network protection and should accomplish the following tasks:

  • Detect/validate and report that the system's resources have been compromised.
  • Determine and report how the system's resources were compromised.
  • Preserve data documenting the compromise of each component.
  • Determine and report any changes to the system as a result of each compromise.
  • Determine and report any data that has been viewed or retrieved as a result of each compromise.
  • Determine and report if the system's resources are being used by foreign executables introduced by a system's compromise.
  • Determine and report the source of each compromise.
  • Assist proactively in halting any compromise detected.
  • Assist in recovery and restoration of all resources altered by a system's compromise.

Many IDSs use signature-based detection and anomaly detection routines to identify an intrusion. Signature-based detection routines are based on recognizing known patterns. They are not effective when a new pattern is introduced and often recognize known patterns only after the target system(s) has been compromised. Anomaly-based detection systems can detect new but unusual exploits earlier in a compromise attempt, but they are highly prone to false-positive alerts. A single IDS, on a busy network, can produce over 1,000 alerts per hour during peak periods. This level of reporting activity often leads to alerts being ignored when anomaly-based detection is producing a high number of false-positive alerts.

Some of the newer IDSs are handling the management of high-alert volumes by providing an enterprise-level security management capability to cross-correlate alerts from multiple IDSs. These devices can develop a global enterprise knowledge that can be used to eliminate many false-positive alerts and standardize reporting from different IDS vendors. When these security management consoles are networked with other security consoles and security management services to create a Distributed Intrusion Detection (DID) system, the alert data from many different sources can be captured to provide a global view of malicious network activities. This information allows detection, analysis, and remedial activities to get under way much earlier. This cooperative process was recently credited with stopping the rapid spread of the worm called “LION” that was implanting software to launch denial-of-service attacks. More information on DID systems can be obtained at http://www.incidents.org/.

References

The highly proprietary nature of vendor-supplied IDSs has slowed the development of industry standards. The Internet Engineering Task Force, Intrusion Detection Working Group (IETF/IDWG) is developing a Detection Exchange Protocol. This standard protocol will allow different IDSs to communicate in a standard format. The IDWG has published the following four documents for review and eventual distribution by the Internet Engineering Steering Group as requests for comments (RFC), located at http://www.ietf.org/ids.by.wg/idwg.html:

  • Intrusion Detection Message Exchange Requirements.
  • Intrusion Detection Message Exchange Format Data Model and XML Document-Type Definition.
  • The TUNNEL Profile.
  • The Intrusion Detection Exchange Protocol (IDXP).

The Defense Advanced Research Program Agency has funded development of the Intruder Detection and Isolation Protocol (IDIP). IDIP is designed to integrate IDSs and automate response components under development at the University of California, Davis. IDIP integrates various IDSs and major components, such as hosted firewalls, routers, and network management components. The result of this integration is the capability to trace and block intrusions that traverse multiple network boundaries. For more information on IDIP, see “Summary of the Intruder Detection and Isolation Protocol Project” at http://seclab.cs.ucdavis.edu/projects/idip.html.