Executive Summary
Based on a mix of off-the-shelf and custom-designed processors, the NAI* IntruShield system is a high-performance appliance that offers real-time network intrusion detection and prevention against known, unknown, and Denial of Service attacks for enterprise networks.

The IntruShield system enables network attack detection and prevention at up to 2 Gbps, and is capable of operating in-line, or as a passive IDS, or both at the same time using different ports in the same appliance. The product line includes the IntruShield 4000, the IntruShield 2600, the IntruShield 1200 and the IntruShield Security Management (ISM) system.

Overall, the performance of the I-4000 is very impressive, combining near-perfect security effectiveness with excellent latency under normal traffic loads. With the latest software update, we found the IntruShield handled our demanding extended false positive, false-negative and evasion tests easily, and without blocking any legitimate traffic or succumbing to common evasion techniques.

Management and control of the IntruShield system benefits from the company being a relative newcomer to the IDS/IPS market place and thus having had the chance to learn from the mistakes of others. The admin domains and user roles make it easy to delegate the most fine-grained control across the largest organisation, whilst the rule-based policy definition makes it easy to define complex policies which can then be rolled out to a single sensor or the entire network at the click of a mouse. And once the policies have been applied, the alert handling and forensic analysis capabilities are incredibly powerful and flexible.

One very unique feature at the time of writing is the Virtual IDS capability, which enables the administrator to apply separate policies right down to individual host level if required.

Architecture
The IntruShield System product family includes the following components:

IntruShield 4000 Sensor (I-4000): The I-4000 is suited for deployment at the core of the enterprise or the perimeter of large networks. The I-4000's four Gigabit Ethernet interfaces provide the performance and operational redundancy required to secure a high-availability network infrastructure. NAI* claims real-time detection and prevention at speeds up to 2 Gbps.

IntruShield 2600 Sensor (I-2600): The I-2600 offers a scalable deployment for medium-to-large networks. Six Fast Ethernet and two Gigabit Ethernet interfaces provide protection for multiple network segments. Its Fast-Ethernet ports have built-in network taps, and NAI* claims real-time detection and prevention at speeds up to 600 Mbps.

IntruShield 1200 Sensor (I-1200): The I-1200 offers cost-effective deployment for mid-size or remote branch office networks. Two Fast Ethernet ports with built-in network taps offer 100 Mbps performance.

IntruShield Security Management System (ISM): The ISM is the IDS/IPS management solution for managing IntruShield sensor appliance deployments for large and distributed enterprise networks. ISM offers features to define, distribute, enforce, and audit security policies to protect critical servers, data centres, individual departments, distributed branches, and remote offices of a global business. ISM is available in two versions: IntruShield Global Manager and IntruShield Manager. IntruShield Global Manager is best suited for global IDS/IPS deployments of up to several hundred sensors, while IntruShield Manager can support distributed deployments of up to six sensors. By the time this report is published, the management product line will have been extended to include IntruShield Starter Manager which can manage up to two sensors and which is available at no cost.

Click for larger view

Figure 1 - IntruShield: IntruShield Sensors

IntruShield 1200 Sensor
The IntruShield 1200 sensor is equipped with the following ports:

:: Two Fast Ethernet monitoring ports which can monitor up to 100Mbps of aggregated traffic. These ports can be used to monitor one segment in full-duplex mode (tap or in-line), or two segments in half-duplex mode (monitoring SPAN ports or hubs).

:: One Response port which, when detection ports are operating in tap or SPAN mode, enables the sensor to inject response packets back into the network (via a switch or router).

:: A 10/100 Management port which is used for secure communication with the Manager server. This port is a normal Ethernet network interface with an assigned IP address. Communication between the sensor and the Manager server uses secure channels that provide link privacy using encryption, and also mutual authentication between sensors and the Manager using public key authentication.

:: Two RS-232C Console ports, used to set up and configure the sensor.

Built-in internal taps provide stealth mode monitoring functionality and forgo the need of an external tap or connection to a SPAN port or hub. When the 10/100 ports are configured to monitor a network segment in peer mode, their internal tap allows a network segment to be connected directly to the sensor. It is also possible to change 'on the fly' from internal tap mode to in-line mode. Internal taps fail open, meaning that should the sensor fail physically while running in internal tap mode, the connection is not disrupted and the network traffic will continue to flow unimpeded.

Note that in in-line mode the monitoring ports can be configured to fail open or fail closed.

IntruShield 2600 Sensor
The IntruShield 2600 sensor is equipped with the following ports:

:: Eight Monitoring ports, comprising six Fast Ethernet ports and two GBIC slots which can monitor up to 600Mbps of aggregated traffic. Between them, these ports can be used to monitor up to four segments in full-duplex mode (tap or in-line), eight segments in half-duplex mode (monitoring SPAN ports or hubs), or a combination of full- and half-duplex links. The sensor can monitor in sniffing mode (on full- or half-duplex links) on some of its interfaces while monitoring in in-line mode on others.

:: Three Response ports which, when detection ports are operating in tap or SPAN mode, enable the sensor to inject response packets back into the network (via a switch or router).

:: A 10/100 Management port which is used for secure communication with the Manager server. This port is a normal Ethernet network interface with an assigned IP address. Communication between the sensor and the Manager server uses secure channels that provide link privacy using encryption, and also mutual authentication between sensors and the Manager using public key authentication.

:: Two RS-232C Console ports, used to set up and configure the sensor.

As with the I1200, built-in internal taps are provided on the 10/100 ports, and the same "on the fly" mode switching is supported. Note that in in-line mode the 10/100 ports of the I-2600 can be configured to fail open or fail closed, whereas the GBIC ports fail closed, meaning that if the sensor fails, the connection is disrupted and it will block the data flow. An optional hardware add-on - the Multi-Mode Optical Gigabit Fail Open Kit - provides fail open operation for the Gigabit fibre ports.

IntruShield 4000 Sensor
The device submitted for testing was the IntruShield 4000 sensor. Designed for high-bandwidth links, it is equipped to support two full-duplex Ethernet segments or four SPAN ports transmitting no more than 2Gbps, for up to 2Gbps of aggregated traffic.

The I-4000 is a 2U rack mount unit which contains three redundant fans and can contain two hot-swap power supplies (a second redundant power supply needs to be purchased separately). The I-4000 is equipped with the following ports:

:: Four monitoring GBIC ports, which allow monitoring of four SPAN ports, two full-duplex tapped segments, two segments in-line, or a combination (i.e. one full-duplex segment and two SPAN ports). The monitoring interfaces of the I-4000 work in stealth mode, meaning they have no IP address and are not visible on the monitored segment. Note that the I-4000 running in in-line mode fails closed, meaning that if the sensor fails, it will interrupt/block data flow. An optional hardware add-on - the Multi-Mode Optical Gigabit Fail Open Kit - provides fail open operation.

:: Two Response ports which, when operating in tapped mode, enable the sensor to inject response packets back through a switch or router.

· One 10/100 Management port, which is used for communication with the Manager server.

· Two RS-232C Console ports, used to set up and configure the sensor.

Note that both the I-2600 and I-4000 sensors support active-active failover for High Availability (HA) configurations. The two sensors that make up a failover pair are interconnected using either one (for the I-2600) or two (for the I-4000) Gigabit failover interfaces. Each sensor mirrors all of the traffic on its monitoring interface(s) to the second sensor in the failover pair via the failover interfaces. Should either device fail it will fail closed, and the second device continues to function normally without losing state on any existing connections. High Availability options are well covered by the IntruShield product range.

Monitoring Modes
The IntruShield offers multiple methods of monitoring traffic:

SPAN or Hub Mode - IntruShield sensors can connect to the SPAN port of a switch or to a port on a hub, thus operating in port mirroring mode. The I-4000 can monitor up to four SPAN connections.

Tap Mode - Unlike the other members of the IntruShield product family, the I-4000 has no internal taps. Using external taps, the I-4000 sensor can receive 1Gbps of traffic from each tap port. Up to 2 Gbps of aggregate traffic can be processed by the detection engine.

In-line Mode - When placed directly in the path of a network segment, the I-4000 sensor processes up to 2Gbps of aggregate traffic for security violations in real time. Traffic passes through the detection engine, is checked, and is then sent back to the network. The four-port I-4000 can monitor two full-duplex segments in in-line mode. Two sensors can be configured as a failover pair when operating in In-line Mode, supporting either Active/Standby or Active/Active operation.

Port Clustering - This allows traffic monitored by multiple ports on a single IntruShield system to be "aggregated" into one traffic stream for state and intrusion analysis. This feature is especially useful in environments with asymmetric routing, where request and response packets may traverse separate network paths. A single IntruShield system can monitor multiple links and maintain accurate and complete state information.

Detection Engine
IntruShield sensors analyse and validate the traffic to its basic protocol elements and inspect specific protocol fields to improve accuracy, while maintaining full flow and application state. The sensors perform IP fragment reassembly and TCP stream reassembly, and perform complete protocol analysis all the way up to the Application Layer. In addition to leveraging protocol analysis for buffer overflow detection - an increasingly common form of exploit - protocol parameters are also made available to write powerful and flexible user-defined signatures.

The Signature engine searches in a flow for multiple triggers (that is, sub-signatures) in multiple fields of a protocol using NAI's* embedded signature files to increase the precision by which an attack can be unambiguously detected.

Traffic normalisation - available when the system is operating in in-line mode - removes any traffic protocol ambiguities, meaning that the traffic being interpreted by IntruShield systems and the traffic received at the protected end-system is identical. IntruShield systems remove any protocol anomalies, protecting the end systems by cleaning up potentially harmful traffic in real-time.

Traffic normalisation also thwarts any attempts to evade the Intrusion Detection System while boosting attack detection accuracy. When operating in tap mode IntruShield systems issue alerts when discovering protocol ambiguities.

Click for larger view

Figure 2 - IntruShield: IntruShield Architecture

This feature, also known as "protocol scrubbing", allows IntruShield systems to prevent hackers from "fingerprinting" a host system. Often hackers send abnormal traffic in the hope that the end system responds in a way that allows the hacker to determine what environments and technologies are deployed at a particular site. This makes it easier to launch subsequent attacks against known vulnerabilities in host network hardware or software resources.

Custom hardware is used to capture packets from the wire (commercially-available network cards would be unable to capture packets at the rates achieved by IntruShield), and once a packet has been captured, it is analysed into its corresponding protocol fields and normalised before being passed through its DoS, Signature, and Anomaly Detection engines.

This enables IntruShield to be very efficient in terms of packet processing because the packet is "peeled" only once and then fed to the corresponding detection engines. All these processes are hardware accelerated to provide the required wire-speed performance. The IntruShield 4000 supports over 2300 signatures in the current release.

However, by making use of anomaly detection, IntruShield can detect and protect against unknown as well as variants of known attacks without requiring specific signatures.

The IntruShield architecture employs statistical, protocol and application anomaly detection techniques. Example categories of anomaly/unknown attacks are new worms, intentionally stealthy assaults and variants of existing attacks in new environments. Anomaly detection techniques can also help in thwarting Denial of Service attacks (where changes in service quality can be observed) and distributed DoS attacks, where traffic pattern changes (such as TCP control packet statistics) can be used by the IntruShield system to determine whether a data deluge is on the way.

Other areas that the IntruShield architecture's anomaly detection techniques help guard against are buffer overflow attacks, backdoor malicious attacks installed via a Trojan or by an insider, stealthy scanning attacks that use low frequency, multiple launch points on the network, and insider violation of security policies, such as installing a game server or a music archive on the network.

To help protect against DoS attacks, a combination of threshold-based detection and self-learning profile-based detection techniques are used. With threshold-based detection, administrators can utilise pre-programmed limits on data traffic to ensure servers will not become unavailable due to overload. At the same time, self-learning methodologies enable the IntruShield architecture to study the patterns of network usage and traffic in order to understand the wide variety of lawful, though unusual, usage patterns that may take place during legitimate network operations.

If the detection engines notice something amiss, they pass an alert and corresponding data to the Management process that is running on the sensor. The Management process can then trigger the appropriate response, based on policy, and send alerts to the remote IntruShield Manager platform.

Virtual IDS (VIDS)
The IntruShield architecture allows for the creation of multiple Virtual Intrusion Detection Systems (VIDS).

Up to 1000 Virtual IDS domains can be set up for specific departments, geographic locations or functions within an organisation, and security policies can then be set for each Virtual IDS.

The VIDS functionality can be implemented in three ways:

:: By attributing Virtual Local Area Network (VLAN) tag(s) to a set of network resources

:: By protecting a block of IP addresses utilising Classless Inter-domain Routing (CIDR) blocks

:: By dedicating IntruShield system interfaces to protect the network resources in particular department, geography or organisational function.

CIDR-based VIDS implementation allows granularity down to an individual host level. For example, DoS attacks can be identified and responded to with unique policies for individual hosts.

Hardware Acceleration
The performance of the IntruShield sensors which we saw in our tests is made possible by dedicated, purpose-built, proprietary hardware that provides the performance required to accurately detect and then prevent network intrusions at wire-speed without packet loss.

Click for larger view

Figure 3 - IntruShield: Virtual IDS (VIDS)

Almost every task undertaken by IntruShield systems benefits from hardware acceleration. For example, IntruShield's signature processing capabilities require hardware to accelerate repetitive signature detection tasks, such as string matches. As a result, the IntruShield architecture can theoretically support thousands of attack signatures at multi-gigabit data rates - and at the same time continue to detect and prevent first strike and Denial of Service assaults.

IntruShield Security Management System (ISM)
The IntruShield Security Management (ISM) system consists of the software resources that are used to configure and manage the IntruShield deployment.

There are two versions of the ISM system:

	IntruShield Global Manager - best suited for global IDS/IPS deployments of many sensors. IntruShield Global Manager runs on Windows 2000 with a MySQL database (MySQL is included), or Solaris 8 with an Oracle database (Oracle not included)
	IntruShield Manager - can support distributed deployments of up to six sensors. IntruShield Manager is supported only on Windows 2000 with an embedded MySQL database.

The IntruShield Manager server is a dedicated Windows 2000 or Sun Solaris 8 platform running the Manager software. Depending on the server platform used and the amount of alert and logging activity on the network, the IntruShield Manager server can manage hundreds of sensors. Sensors use the 10/100 Management port to communicate with the Manager server over a secure, encrypted link.

The IntruShield Manager software provides a Web-based user interface for configuring and managing the IntruShield system. IntruShield users connect to the Manager server from their workstations through a Web browser. The browser client needs to be Internet Explorer 5.5 or later.

NAI* Update Server
New signatures and software patches are made available to customers over the Internet via the NAI* Update Server, which provides secure, fully automated, real-time signature updates without requiring any manual intervention.

Click for larger view

Figure 4 - IntruShield: Monitoring system health in ISM

According to a user-configured schedule or via a manual process, the IntruShield Manager polls the NAI* Update Server, and compares the file on the Update Server with what is already available in the Manager server to determine what needs to be downloaded. Once it has received the update, the Manager then determines what signatures need to be pushed out to sensors based on the policy applied to the sensor.
For example, a policy defined for a Windows environment will receive only updated signatures that apply to that environment. The Manager compiles a specific update for each sensor and the update can then be pushed to sensors either manually, in an automated, real-time fashion or via automatic scheduled updates. One nice feature of IntruShield is that it maintains state completely during a signature update, and new signatures are even applied to subsequent packets of existing flows.

Performance
The aim of this section is to verify that the sensor is capable of detecting and blocking exploits when subjected to increasing loads of background traffic up to the maximum bandwidth supported as claimed by the vendor.

For each type of background traffic, we also determine the maximum load the IPS can sustain before it begins to drop packets/miss alerts.

It is worth noting that devices which demonstrate 100 per cent blocking but less than 100 per cent detection in these tests will be prone to blocking legitimate traffic under similar loads.

The IntruShield I-4000 was tested up to 1Gbps (NAI* claims 2Gbps throughput for this device - see Results section) and performance at all levels of our load tests was impeccable, with 100 per cent of all attacks being detected and blocked under all load conditions.

We did note that the Spirent SmartFlow 64 byte packet test (Test 4.1.1 - see Test Results section for further details) indicated that there was a 0.005 per cent packet loss at a 1Gbps load. However, this condition never manifested itself as a failure to detect or block any of our exploits. Under normal network conditions, we would have no hesitation in rating the IntruShield I-4000 as a true 1Gbps device.

Latency figures were exceptional with most normal traffic loads and most packet sizes, ranging from 33.33µs with 250Mbps of 64 byte packets, to 105.99µs with 1Gbps of 1514 byte packets. However, we did note that latency increased significantly once we went above 500Mbps of 64 byte packets, reaching a maximum of 6256.30µs at 1Gbps of 64 byte packets. Hopefully, this extreme behaviour would not be apparent on any normally loaded network.

Latency also increased as we loaded the device with 500Mbps of genuine HTTP traffic. With the device under "half load" of normal traffic, latency on 64 byte packets increased from 33 to 89 microseconds, 440 byte packets increased from 52 to 80 microseconds, and 1514 byte packets increased from 107 to 127 microseconds. It is worth pointing out that the actual latency still fell well within the limits of what we would consider acceptable for a device of this type.

SYN flood protection worked well with the IntruShield. Although the initial part of the SYN Flood is allowed onto the protected network because the I-4000 does not proxy SYNs, once the SYN Flood was underway and identified the subsequent mitigation was complete. The impact on latency through the device of the 100Mbps of SYN Flood attack traffic was fairly significant, however, increasing from 33 to 930µs with 64 byte packets, from 52µs to 433µs with 440 byte packets, and from 107µs to 426µs with 1514 byte packets.

Our rigorous test suites exposed a bug which manifested itself as a rare false-negative problem with the I-4000 under certain extreme cases, whereby it would occasionally allow certain types of exploit traffic through, but only when it was configured to permit mid-flow traffic (the default setting). Network Associates* developers worked closely with us on this issue and produced a software update in less than 24 hours.

Once we had applied the software update, the I-4000 performed reliably throughout our tests. Under eight hours of extended attack (comprising millions of exploits mixed with genuine traffic) it continued to pass legitimate traffic whilst blocking attack traffic in a consistent manner.

Exposing both the sensor and management interfaces to an extended run of ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits throughout and following the ISIC attacks.

High Availability (HA) options are well covered with the IntruShield product range, covering everything from multiple redundant components (such as fans and power supplies) to full-blown HA configurations with multiple IntruShield sensors.

Security Effectiveness
We installed one IntruShield I-4000 sensor with the latest signature pack. We derived a new policy from the "attacks" policy which has all attacks enabled, and audits disabled by default. We then changed all alert responses to "Block" and deployed the policy. No other tuning was necessary.

Signature recognition (with blocking disabled) was excellent out of the box (94 per cent), and was increased to 99 per cent after the application of a signature pack update which was provided to us in less than 48 hours. Blocking performance was identical.

Accuracy was high in terms of the types of alerts raised, although the alert descriptions are sometimes "generic", with several alerts raised for the same exploit. This can necessitate some investigation in order to determine the exact exploit that was detected.

Out of the box, 69 per cent of our false negative (modified) exploits were detected. This was increased to 100 per cent after the application of the signature updates.

A major concern in deploying an IPS is the blocking of legitimate traffic. An initial bug in the SMTP and POP3 protocol decoders was quickly resolved, leaving a clean sheet in our false positive tests.

The IntruShield I-4000 performed extremely well in all of our evasion tests, and was one of the few products to collect a clean sheet across the board in this section of the test plan following the signature pack update which cured the only blemish - an inability to detect one of our Trojan/Backdoor test cases on a non-standard port. Once the signature update had been applied Fragroute, Whisker, ADMmutate and even RPC record fragging all failed to trick IntruShield into ignoring valid attacks.

Note that not only were the fragmented and obfuscated attacks blocked successfully, but every one of them was decoded accurately as well. This is the level of performance to which we would like to see all IDS and IPS products aspire.

The IntruShield I-4000 demonstrated perfect performance in our stateful operation tests out of the box. The device maintained state on 1,000,000 open connections, successfully detecting our half-open exploit as it was completed. It also continued to detect and block new exploits as we maintained 1,000,000 open connections, and no legitimate traffic was blocked throughout these tests.

No tuning was necessary in order to support this level of open connections, enabling the I-4000 to display a perfect set of results out of the box.

The I-4000 was not tricked into alerting on our stateless exploits, indicating that it would be resistant to TCP-based exploits launched via replay tools such as Stick and Snot. Although the default is to permit mid-flow traffic, it was also capable of blocking these mid-flow streams completely with the change of a single parameter.

Usability
This part of the test procedure consists of a subjective evaluation of the features and capabilities of the product, and covers installation, configuration, policy editing, alert handling, and reporting and analysis.
Installation.

The IntruShield 4000 (I-4000), designed for high-bandwidth links, is equipped to support two full-duplex Gigabit Ethernet segments, or four SPAN ports (transmitting no more than 2Gbps in total) for up to 2Gbps of aggregated traffic. Note that the I-4000 does not have internal taps - it must be used with a third party external tap to run in tap mode.

Installation of the IntruShield Sensor and Manager are very straightforward. We installed Manager on a Windows 2000 host (it is not yet supported on XP), and all that was required was to insert the CD and run the set-up program. During installation, the Java Runtime Environment (JRE) is installed on the Manager host if it was not already installed.

On firing up the Console for the first time, it is necessary to add each Sensor to the Resource Tree using the System Configuration Tool. Each Sensor is given a unique name and shared secret to secure the initial public key exchange between Manager and Sensor.

At the Sensor itself, it is then necessary to initiate a CLI session via a PC attached to the serial console port. A few simple CLI commands are all that is required to set the Sensor name, shared secret and the IP configuration of the Management port, at which point the Sensor establishes communication with the Manager, secures the connection, and makes itself available for remote management functions.

By default, the four Gigabit fibre interfaces come up in dedicated SPAN mode, each with the Default policy applied, and thus the IntruShield Sensor is ready to run out of the box as a passive IDS device. The I-4000 is capable of operating in one of three modes:

	SPAN or hub operating mode - the IntruShield Sensor is attached directly to the Switch Port Analyser (SPAN) port of a switch at a key point on the network in order to see all the traffic that is mirrored there
	Tap operating mode - Tap mode works through installation of an external wire tap (for GBIC ports) or built-in internal taps (for 10/100 Monitoring ports). An IntruShield sensor deployed in tap mode monitors or "sniffs" the packet information as it traverses the full-duplex network segment.
	In-line operating mode - In-line mode places a sensor directly in the network traffic path, inspecting all traffic at wire-speed as it passes through the assigned port pair. In-line mode enables the sensor to run in a protection/prevention mode, where packet inspection is performed in real time, and intrusive packets can be dealt with immediately - the sensor can drop malicious packets because it is physically in the path of all network traffic. This enables it to actually prevent an attack from reaching its target.

For our tests, we configured one port pair in In-line Mode.

Extensive, and extremely useful, documentation accompanies the IntruShield Manager and IntruShield sensors, both in hard copy and electronic format. This documentation set consists of:

:: Quick Start Guide
:: Getting Started Guide
:: Sensor Installation and Configuration Guide
:: Manager Installation Guide
:: Manager Administrator's Guide

Configuration
The IntruShield product line has been developed from the ground up with high-speed switched networks and large-scale distributed deployments in mind. The thought that has gone into this is evident both in the hardware and the management software, the latter demonstrating some extremely sophisticated features. One of those which will appeal most to administrators of larger distributed networks is the administrative domain.

Click for larger view

Figure 5 - IntruShield: Port configuration

The admin domain is an organisational tool used specifically to group IntruShield resources so that management of the resources can be delegated to specific IntruShield users.

An admin domain can contain other admin domains, sensors, sensor interfaces, and sensor sub-interfaces. This administrative domain concept enables enterprises to create a central authority that is responsible for the overall IntruShield system, and to allow this central authority to delegate day-to-day operations of IntruShield security resources to appropriate entities - business units, geographic regions, IT departments, individual security personnel, and so on.

Although it is possible to manage an entire set of IntruShield security resources from a single domain, if it is desired to delegate responsibilities for managing those resources among multiple individuals within an organisation then it is necessary to create one or more child domains. The top level admin domain is called the Root Admin Domain, and users with Super User access to the Root Admin Domain have complete control over the entire administrative domain and all resources within it, including any child domains. Initially, Policies are inherited from the parent domains, but they can subsequently be changed at a child domain level.

To delegate responsibilities, user accounts are created and allocated a role that defines how the user can interact with the resources in the child admin domain. The Root Admin Domain can be divided into child domains that are large, from a resource perspective, delegating management of all the IntruShield resources protecting multiple geographic regions. Or the domains can be very small - a few interfaces on a single sensor, or even a VLAN tag or single CIDR address within a segment of traffic transmitting between two hosts in the protected network.

Click for larger view

Figure 6 - IntruShield: Sensor configuration

Child domains can be further broken down into smaller sub-domains in order to provide a very fine degree of management granularity. Administrative domains are graphically represented in the Resource Tree of the ISM Console as a hierarchical tree structure. Resources in the IntruShield system are represented as nodes on the Resource Tree.

When a user logs into the Console, he will be presented with only those nodes that have been delegated to his particular domain or sub-domain. In addition, he will only be able to see alerts that relate directly to the nodes and resources under his administrative control.

The IntruShield Manager Console is a Web-based Java application that can be run from any PC on the same network as the management port of the IntruShield Manager host. The Manager hosts the central alert database (MySQL by default, though Oracle is now supported as well) and performs all the necessary alerting and reporting tasks for the IntruShield system. All the Sensors report back to the Manager host.

When first logging on to the Console, the administrator is presented with an overview "dashboard" screen that provides an at-a-glance indication of the sensor health via a coloured indicator, and an unacknowledged alert summary which shows totals of high, medium and low level alerts that have not yet been acknowledged. A hyperlink below each of these provides instant access to the System Health Status screen and the Alert Viewer, and additional buttons provide access to the Configuration and Reporting utilities.

The System Health Status provides a colour-coded (red, green or yellow) summary of the health of various system components, including the Manager, the Sensor and the database.

Where the status is not green, hyperlinks provide instant access to the events that caused the problem, and in the latest release system faults, like alerts, can be forwarded by severity to either an SNMP or Syslog server, sent to an administrator via e-mail or pager, or processed via a script. Once the events have been investigated and resolved, they can be acknowledged and the status will return to green.

Click for larger view

Figure 7 - IntruShield: Network Console

The System Configuration utility provides a hierarchical Resource Tree down the left of the screen, and one or more tabbed configuration screens on the right. In addition to providing the ability to manage users and domains as mentioned earlier, the System Configuration utility also enables the administrator to configure system notification parameters (e-mail, pager, SNMP syslog or script), perform database backups and restores (these can be on demand or scheduled), acquire software and signature updates from the NAI* Update Server (on demand or scheduled), carry out log file maintenance operations (deleting old log file entries, on demand or scheduled), create custom signatures, and create, edit and deploy security policies.

Note that signature updates can be rolled out to all sensors at the click of a button and applied to each sensor in real time without requiring a reboot (this process can be quite lengthy, making it occasionally frustrating to fine-tune a policy). It is also possible to roll back to a previous signature pack version just as easily. State on existing connections is maintained during a signature update, and new signatures are even applied to subsequent packets of existing flows.

Both sensor and policy configurations can be exported and imported between Managers. This would allow an administrator to operate both staging and production version of the Manager, and easily move configuration information between them.

Policy Management
When working with IntruShield policies, the term attack is used rather than signature. An attack as defined in IntruShield is comprised of one or more signatures, where each signature is a method of detecting an attempt to exploit a particular vulnerability in a system.

These signatures may contain very specific means for identifying a known exploit of the vulnerability, or more generic detection methods that aid in detecting unknown exploits for the vulnerability (such as buffer overflows). Combining several such signatures into a single attack provides for maximum accuracy in attack detection.

Click for larger view

Figure 8 - IntruShield: The Policy Editor

We could not find much in the otherwise excellent documentation covering the creation of custom signatures, and since the User Defined Signature Editor is not the most intuitive we have come across, this process could be tricky for some. NAI* is working on an extensive guide at the time of writing, and this should be available by the time this report is published.

There is tremendous flexibility and power in creating user-defined signatures and attacks, however.

The administrator is able to take advantage of known protocols and packages in order to perform field comparisons (i.e. check if the traffic is HTTP and the source port is 32324) or define new ones from scratch. It is also possible to perform simple packet grep string matches.

Any number of data comparisons can be added to a signature (connected with AND, OR or ANDTHEN conditions ), and any number of signatures can be added to an attack. This allows for some very fine-grained control over user-defined signatures and should hopefully help to reduce false positives providing the signature is defined correctly in the first place.

NAI* supplies a set of pre-configured policies for immediate application in a number of different network environments. As well as including policies specific to particular operating systems (Windows, Solaris, etc.), server functions (Web server, mail server, FTP server, etc.) and physical locations (outside firewall, inside firewall, DMZ, etc.), there are also three catch-all policies: Default, All Inclusive With Audit and All Inclusive Without Audit.

The Default policy includes all attacks that NAI* considers are applicable to an "average" network, whilst the All Inclusive With Audit policy includes every single available signature - exploits and audit/informational alike. The All Inclusive Without Audit policy includes all available attacks, but excludes pure audit signatures.

The built-in policies are available in the Policy Editor, and should be considered as starting points, designed to help get the system up and running quickly.

Click for larger view

Figure 9 - IntruShield: DoS policies

Any of the default scenarios can be applied and used as they stand, or they can be cloned (pre-defined policies cannot be edited directly) and modified in order to apply custom policies. The NAI* Default policy, applied automatically when the first sensor is added, enables the administrator to begin monitoring the network immediately with the most wide-ranging policy, but excluding all the known noisy signatures.

For many people, the Default policy will prove more than adequate to begin with. For our testing we deployed the All Inclusive Without Audit policy, and the sensor performance did not appear to suffer from having all signatures enabled.

Attacks are classified into four general areas:

	Denial of Service (DoS) and Distributed Denial of Service (DDoS): all of the conditions indicative of activities that lead to service disruption, including the slowing down or crashing of applications, servers, or networks.
	Exploit: all malicious activities, other than DoS and Reconnaissance, carried out through specific traffic content. This includes viruses and worms.
	Reconnaissance: all of the conditions indicative of probing, scanning, and OS fingerprinting activities.
	Policy Violation: all activities for which the underlying traffic content may not be malicious by itself, but are explicitly forbidden by the usage policies of the administrative domain. This includes packets that violate fixed field constraints at TCP, UDP, IP, ICMP and Ethernet levels.

Click for larger view

Figure 10 - IntruShield: Applying a rule set to a policy

All IntruShield policies are rule-based - each rule in the set is either an include rule or an exclude rule, and determines what signature or group of signatures will be incorporated into the policy. An include rule usually starts a rule set and consists of a set of parameters that encompass a broad range of well-known attacks for detection. More than one include rule can be applied, of course, if it is required to be specific about the rules included in a policy (specifying the inclusion of only HTTP and FTP rules, for example). One or more exclude rules can then be applied to remove elements from the include rules in order to focus the policy's rule set further.

For example, it would be possible to include all HTTP rules but exclude the Apache-related rules if there are no Apache servers in the organisation.

By this process of broadening (includes) and narrowing (excludes) the policy focus, a policy eventually comes to contain exactly the signature set that is required for a given deployment scenario.

Each attack in the IntruShield system has a wide range of informational parameters associated with it, including:

:: Attack type (DoS, reconnaissance, exploit, etc.)
:: Severity level (low, medium or high)
:: Benign trigger probability (indicating the risk of false positives)
:: Protocol
:: Target OS
:: Target application

The rule set can use any or all of these parameters in order to provide the most highly focussed policy. For example, if a sensor is operating in-line in front of a DMZ with only IIS Web servers, the administrator might include all HTTP signatures, and then exclude all non-IIS signatures and finally exclude all those signatures with a benign trigger probability greater than "Low".

That way, only the relevant signatures are applied, and the administrator can be reasonably sure that false positives will not cause a self-inflicted Denial of Service condition by ensuring that only the most focussed and accurate signatures are applied in in-line mode. A separate interface on the IntruShield could then be used to monitor the same DMZ segment in SPAN mode with a broader policy, just in case something slips through.

Click for larger view

Figure 11 - IntruShield: Policy configuration (alert responses)

Once the rule set has been created and applied to a policy, the Policy Editor displays the number of attacks that have been selected, grouped by protocol. Double clicking on a protocol brings up a list of the individual attacks, from where it is possible to customise certain elements of those attacks, including:

:: Whether the attack is enabled or disabled

:: Attack severity

:: Logging behaviour - the sensor can log the entire packet or a specific number of bytes, and in addition can log 256 bytes of application data prior to the attack.

:: Duration of logging - the sensor can capture the attack packet only, capture a specified number of packets, for a specified length of time, capture the entire flow, or deliver forensic logging where all subsequent communication between attacker and victim can be logged.

:: Sensor actions - send TCP reset (to source, destination or both), send "ICMP Host Not Reachable" packet to source, reconfigure the firewall, drop attack packet and all subsequent packets for that flow (this last option only works when sensor is in in-line mode, of course, whereas the remaining options can be employed when the sensor is operating in SPAN or tap mode).

:: Alert filter - enables the administrator to suppress certain alerts from or to specific IP addresses or a range of addresses.

:: Notifications - e-mail, pager or script notifications from the Manager to the administrator.

A useful bulk-edit capability allows the administrator to select multiple attacks and subsequently apply changes to certain parameters (such as the enable/disable flag, or alert response) to an entire group of attacks in a single operation. Unfortunately there is no search facility within the Policy Editor, so it is not possible, for example, to search for all IIS signatures and have them automatically selected for bulk editing. Selection for bulk editing is thus an entirely manual operation.

Note that it is also impossible to tune the actual built-in signatures in any way. This means that if a built-in signature is misfiring for some reason, it is not possible to alter the regular expression, for example, to ensure that it does not trigger on benign network traffic. Instead, an administrator can employ alert filters or disable the misfiring attack signature, after which he would have to start from scratch in creating his own user-defined signature. In an industry where the trend has shifted sharply towards making signature content more visible, it is a shame that NAI* has chosen to hide its signature properties so completely (though it is not alone in this approach).

A similar, though slightly smaller, set of parameters can be configured for DoS attacks (i.e. there is no need for a "capture entire flow" option for DoS attacks), and the sensor is automatically in learning mode by default. This means that it will monitor the normal network traffic for a period of time so that it is able to determine what constitutes an abnormal flood. Individual DoS profiles can be created per sensor, and these can be uploaded to the Manager from where they can be applied to other sensors if required.

For those administrators who would prefer to have more manual control over the DoS detection process, it is also possible to switch to threshold mode, where he can set the threshold level and interval for individual DoS attacks. Note that both threshold and learning mode can be enabled or disabled on a per-attack basis, and both methods worked extremely well in our tests.

Finally, reconnaissance probes - port scans, host sweeps and brute force password cracking attempts - are configured purely on a per sensor basis and cannot be a part of a global policy.

Each of these are configured using thresholds, and once again the default settings worked well in our tests.

After a policy has been configured using the Policy Editor, it can be applied to a resource - for example, an entire admin domain (or child domain), a sensor, an individual interface, or a sub-interface. Once applied to a resource, the policy is then propagated to the appropriate sensor (or sensors) for enforcement. Separate policies can be applied for inbound and outbound traffic if required.

Click for larger view

Figure 12 - IntruShield: Reconnaissance policy

If a policy is subsequently amended, it would be nice to have the Console automatically determine which sensors are affected by the change and offer to update them immediately with the new policy. Instead it is necessary to navigate to another section of the GUI entirely in order to manually update a sensor with a changed policy.

We found it slow to save a policy to the Manager server even after changing only a single item. We also found it to be fairly slow to deploy a policy to one or more sensors, and whenever new signature updates are downloaded from the Web, the new signatures are added to all policies (within the confines of the applied rule sets) - another very time consuming process.

Most IPS products permit the application of only one security policy for each sensor. However, where there are multiple segments to monitor or a need to monitor aggregated traffic - like on Gigabit uplinks, for example - a multi-port box and more granularity in the inspection process can make for a much more cost effective and efficient solution. IntruShield's Virtual IDS (VIDS) feature achieves this, and is unique amongst all the products we have tested to date, enabling an administrator to configure multiple policies for multiple unique environments all monitored with a single IntruShield sensor.

Different policies can be applied to different interfaces, for example, allowing one pair of interfaces to monitor the DMZ with a predominantly Web-based policy in in-line mode, whilst another interface monitors the internal network in SPAN mode using the Default policy.

A clever feature of IntruShield sensors take port monitoring one step further than the physical interface-level, however. Using sub-interfaces, it is possible to segment the security management and apply policies at a traffic sub-flow level within an interface - in other words, the sensor monitors only a portion of the traffic passing through a physical interface. This sub-interface is also known as a Virtual IDS (VIDS).

A VIDS can be defined based on a block of IP addresses (a CIDR block), or on one or more VLAN tags. IntruShield sensors can process these segments of data and apply multiple traffic policies for the multiple subnets transmitting across a single wire, right down to policies protecting individual hosts.

Other IPS products may allow filtering of addresses to achieve something similar, but they still generally only allow a single policy to be applied to each sensor. The particularly clever feature of IntruShield is the ability to support up to 1000 VIDS per sensor, and a different policy can be applied to every single VIDS. This means that on some networks, it would be possible to have a separate unique detection policy running for every single host on the network, all monitored from a single sensor!

Click for larger view

Figure 13 - IntruShield: Viewing alerts in real time

It is also possible to mix interface modes in a single sensor, and apply different policies to each interface. One scenario we tested, for example, was to use two ports paired in in-line mode running a restrictive policy with intrusion prevention enabled for certain signatures, but with all the signatures with potential for false alarms disabled. We also created a VIDS on the same interface pair which consisted of a single mail server, to which we applied a slightly different in-line policy with more focus on SMTP exploits.

We then used one of the remaining ports in SPAN mode attached to the SPAN port of our switch, and with a much broader policy applied which was set to capture the entire flow. Although the initial VIDS configuration requires some thought, once it has been accomplished, assigning policies to the separate VIDS is extremely simple, and the whole test scenario worked perfectly.

Ports and sub-interfaces are managed via the Resource Tree in the System Configuration utility, where it is possible to create sub-interfaces beneath an interface node, or VIDS nodes within child domains - both of these are different manifestations of the Virtual IDS, and allow the allocation of multiple policies to the same physical interface.

A VIDS within a child domain can be allocated to an administrator who only has rights to that child domain and nothing else. Thus, when that administrator logs in, he will be able to configure and allocate policies to the VIDS under his control without affecting any other interfaces or VIDS in the system.

Alert Handling
Alerts exist in one of three states within the IntruShield system: unacknowledged, acknowledged, and marked for deletion. When an alert is first raised, it appears in the Manager in an unacknowledged state, and remains in that state until the administrator either acknowledges or deletes it.

Click for larger view

Figure 14 - IntruShield: The Alert Viewer

These alerts display in the Unacknowledged Alert Summary section of the Network Console and the Real-time view in the Alert Viewer. Acknowledging alerts dismisses them from these views, after which they display only in the Historical view in the Alert Viewer and in reports. It is not possible to annotate alerts as they are acknowledged, however - a shame, since that would be a useful facility to record the results of an investigation into the alert and why it was eventually regarded as unimportant.

Deleting an alert both marks it for deletion and acknowledges it in the same operation. The alert is not actually deleted until a scheduled File Maintenance operation takes place, however, at which time IntruShield removes all alerts marked for deletion along with any alerts meeting the deletion criteria specified in the scheduler (older than 30 days, for example).

Alerts are backed up to the database and archived in order of occurrence, whereas deleted alerts are removed from the database altogether. Using the Historical view in the Alert Viewer, it is possible to return an acknowledged alert back to an unacknowledged state or un-delete an alert, providing it has not been "cleaned up" by the file maintenance utility.

The IntruShield Alert Viewer is available via a hyperlink on the Manager Network Console display. When it is first opened, the administrator must specify a time frame and a type of view - either Real-time or Historical. The Real-time View sets the alert filter to display information retrieved from an "alert cache" for a configured number of unacknowledged alerts. Once opened, the Real-time View refreshes frequently to display the alerts that are being detected by the sensors, but once closed, the only way to report on those alerts is to re-open the Viewer in Historical mode.

The alert cache stores up to 500,000 of the most recent unacknowledged alerts, and all cached alerts are also listed in the database. Since the cache is a FIFO system, the oldest alerts in the cache are dropped once the cache maximum has been reached with newer incoming alerts that "overflow" the cache. Dropped alerts are simply discarded, since they have also been written to the database and are thus a matter of permanent record. This seems to work quite well.

The Historical View sets the filter to retrieve information for both acknowledged and unacknowledged alerts written to the database within a specified time frame. The archiving of older data is not handled particularly well for such an otherwise powerful system, however. The current alert database is "trimmed" regularly by the file maintenance operations, and the only way to access historical data after that is to restore a database backup and run reports on that - not exactly seamless.

It would be nice to see an auto-archive facility which copies alerts over a certain age to an on-line archive database. The Alert Viewer and Report Generator should then both be able to select from either the current database, or the archive database, or automatically consolidate both. This would keep the current alert database to a manageable size, but would make historical analysis much easier. More extensive alert archival capabilities are currently under development for a future release.

Once alerts have been retrieved either from a particular time period, or in real time, the Alert Viewer interface displays the alerts in four main views:

	Alerts By Time View - the number of alerts in time intervals that have occurred in the last two hours (Real-Time) or a desired time frame (Historical). The Alerts By Time View displays a bar graph with the number of alerts that have occurred in the specified time frame. Each bar contains information related to the number of alerts and a time frame in which the alerts occurred.
	Consolidated View - displays alerts split into five panes (categories) for statistical review.
	Each pane - is a bar graph, and each bar represents several alert instances grouped by a specific parameter. An alert may appear in a bar in more than one pane if that alert has met the statistical parameters of multiple categories. The categories are:
	Alert Result Status - Lists alert totals by result: Successful, Unknown, Failed, Suspicious, or Blocked.
	Severity - Lists alert totals by severity level: High, Medium, or Low.
	Top 10 Attacks - lists the top 10 attacks by number of triggered alerts.
	Top 10 Source IP Addresses - lists the 10 most common source IP addresses by number of triggered alerts.
	Top 10 Destination IP Addresses - li