19.4 The Future of IDSs

 <  Day Day Up  >  

The field of intrusion detection is still in its infancy. As hackers evolve , IDSs must attempt to keep pace. Table 19-1 lists future trends that pose threats to IDSs, and potential solutions.

Table 19-1. Potential solutions to future difficulties in IDS

Problem

Solution

Encrypted traffic (IPSec)

Embed IDS throughout host stack

Increasing speed and complexity of attacks

Strict anomaly detection, heavily optimized NIDS engines, and intelligent pattern matching

Switched networks

Monitor each host individually; embed NIDSs in switches

Increasing burden of data to interpret

Visual display of data, automated alert suppression and correlation

New evasion techniques

New traffic normalization techniques and deeper target host awareness

New kernel-based attack techniques

New kernel security mechanisms

The following sections examine each of these growing problems and propose potential solutions.

19.4.1 Embedded IDS

IPSec (short for IP Security) is becoming a popular standard for securing data over a network. IPSec is a set of security standards designed by the Internet Engineering Task Force (IETF) to provide end-to-end protection of private data. Implementing this standard allows an enterprise to transport data across an untrustworthy network such as the Internet while preventing hackers from corrupting, stealing, or spoofing private communication.

By securing packets at the network layer, IPSec provides application-transparent encryption services for IP network traffic, as well as other access protections for secure networking. For example, IPSec can provide for end-to-end security for client-to-server, server-to-server, and client-to-client configurations.

Unfortunately , IPSec is a double-edged sword for IDSs. On the one hand, IPSec allows users to securely log into their corporate networks from home using a VPN. On the other hand, IPSec encrypts traffic, thus rendering promiscuous-mode sniffing network IDSs less effective. If a hacker compromises a remote user 's machine, he will have a secure tunnel through which to hack the corporate network! In order to correct for IPSec, future IDSs need to be embedded throughout each level of a host's TCP/IP stack. This will allow the IDS to watch data as it is unencapsulated and processed through each layer of the stack and analyze the decrypted payload at higher levels.

19.4.2 Strict Anomaly Detection

As the speed and complexity of attacks continue to increase, IDSs are less able to keep pace. One answer to this dilemma is strict anomaly detection : every abnormality, no matter how minor, is considered a true positive alarm. Such a method requires that the IDSs move onto individual hosts , rather than the network as a whole. An individual host should have a more predictable traffic pattern than the entire network. Each critical host would have an IDS that detects every anomaly. Then the administrator can make rules (exceptions) for acceptable variations in behavior. In this way, IDSs monitor behavior in much the same way that firewalls monitor traffic.

How would we design an IDS that performs host-based, strict anonmaly detection? We are dealing with individual hosts that are somewhat isolated by firewalls and routers, so we can customize our IDS for each unique host. Since we are dealing with the host only, we know that any packets received are destined for that specific host. We can then set our sensitivity very high to look for any abnormality.

For example, at the packet level, our host-based anomaly detector would scan packets as they are processed up the stack. We ask the IDS to monitor any of the following:

  • Unexpected signatures

  • TCP/IP violations

  • Packets of unusual size

  • Low TTL values

  • Invalid checksums

  • Other protocol violations

Similarly, at the application level, we can ask our anomaly detector to scan for unusual fluctuations in the following system characteristics:

  • CPU utilization

  • Disk activity

  • User logins

  • File activity

  • Number of running services

  • Number of running applications

  • Number of open ports

  • Logfile size

Once an abnormality is detected , an alert is sent to the central console. This method has a high sensitivity, but unfortunately it generates a great deal of data. We deal with this problem below.

19.4.3 Host- Versus Network-Based IDSs

The increasing use of switched networks hinders an IDSs that monitors the network using promiscuous-mode, passive protocol analysis. It is becoming more difficult to monitor multiple hosts simultaneously due to increased bandwidth, virtual networks. and other complications. In addition, the growing use of encrypted traffic foils passive analysis off the wire. Thus, IDSs are moving toward host-based monitoring.

19.4.4 Visual Display of Data

As bandwidth and attack complexity increase, it is becoming more difficult to generate meaningful alerts. The amount of alert data generated by an IDS can quickly overwhelm its human operators. Unfortunately, excessive filtering of data for human use severely limits its effectiveness.

One solution to this problem involves advanced visualization techniques, also called geometric display of data . Humans understand geometric shapes intuitively, so this kind of display is often the easiest way to present massive amounts of data. When an operator senses an anomaly in the graphical display, she can later drill down manually to investigate the problem. For example, for its own internal use, Airscanner Corporation coded a flexible ActiveX control that mimics a real-time human electrocardiogram (EKG). The rate and rhythm (and color or sound) of the "heartbeat" fluctuates on screen in response to network changes. Just as a hospital nurse monitors a cardiac telemetry floor, the Airscanner network administrator can easily monitor her LAN by keeping an eye on this display.

 <  Day Day Up  >  


Security Warrior
Security Warrior
ISBN: 0596005458
EAN: 2147483647
Year: 2004
Pages: 211

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net