Network-intrusion detection systems

Lancope’s intrusion-detection system is an anomaly in more ways than one. The Stealthwatch M250 Version 4.2 we tested – which veers from popular signature-based IDS products with a behavior-based approach to spotting intruders called anomaly detection – can indeed spot attacks, but its overall package could use a bit more polish.

Archive of Network World tests

Subscribe to the Network Product Test Results newsletter

The anomaly detection engine noticed unexpected network behavior very well in our tests. For almost every attack we threw at it, the Stealthwatch box did note that something was askew with our network activity (see ). Unfortunately, in most cases, the information the appliance presented comprised extremely low-level network details, which were difficult to correlate to an exact attack. We also found some security implementation issues that could leave the box open to attack.

Any IDS based on anomaly detection monitors network traffic on an ongoing basis and looks for patterns. Patterns that are normal do not generate events. If the IDS detects abnormal traffic – such as attempts to access disallowed ports, or traffic flowing in a direction that is not expected – then it generates an event. Other products that offer anomaly detection include Enterasys Networks’ Dragon and Symantec’s Manhunt.

The Stealthwatch 4.2 appliance is based on a Dell PowerEdge 1650 1U, rack-mountable PC with four Gigabit Ethernet interfaces, one of which is left open for management via a Transport Layer Security-based Web interface. The device connects to a variety of infrastructure services: Syslog, Network Time Protocol, Whois (host information lookup) and DNS, used to gather event information and time stamps.

Lancope offers a central management server to control multiple Stealthwatch devices, which we did not test. Lancope says the interface is different, but event-processing capabilities are the same as found in the appliance.

Stealthwatch uses behavioral monitoring to directly generate alerts and to calculate one of three indices – concern index, threat index and file-sharing index – which evaluate whether the traffic is normal or abnormal. These indexes, which are only vaguely documented in the manual, provide some level of indication for when a severe threat is present using the concern index, when a host is being targeted by an attack using the threat index or when machines within a monitored zone appear to be performing inappropriate file sharing through some peer-to-peer tool using the file-sharing index.

You have to configure the Stealthwatch appliance to be aware of your network policy. You set it up with the usual address information, such as IP address, subnet mask and services addresses the GUI uses. You then configure it to detect attacks based on your security policy, such as “only Port 80 (HTTP, Web) and Port 22 (Secure Shell) traffic are allowed inbound to this server” or “only traffic to syslog are allowed outbound from this server.” Lancope also offers the concept of a “zone” – indicating a group of hosts inside or outside your monitoring perimeter – to which you can apply a policy.

In addition to conventional traffic-based policy configuration, you can run it in tuning mode where it detects your normal traffic patterns and adjusts its detection thresholds based on that data.

Interpreting the signal

When an attack occurs, the Lancope device flags events because of policy violations in the network traffic. It also signals events when one of the three indices goes above a prescribed level.

Event data is stored in a local log that can be accessed by selecting daily, weekly or archival reports from the management GUI. While the device generates a significant amount of log data internally, only a limited number of message types are forwarded to an external syslog server. Because much of the detail in the local log is never sent to the external server, Lancope’s manual describes techniques to periodically retrieve and process the local log. This dual-log scheme requires extra log analysis.

While the GUI provides alerts and reports on network problems, the device by definition is unaware of any specific attacks by name. Therefore, events tend to have a lot of low-level detail that is difficult to interpret.

For example, in our NMAP TCP scan from an outside host, Stealthwatch sent an alarm for port scanning that showed a lot of bad traffic but offered no clear explanation of what actually was happening. Likewise, a Nessus scan of a host was detected in our tests, but the events produced were described as “high concern” with alert details including “App_flake”, “HI_CI”, and “Excess_Clients” – data that would be difficult to interpret in a real attack situation.

Like any other device in an enterprise network, the IDS should be secured to a level that conforms to your security policy. Stealthwatch has glitches in its own physical security.

For example, the management interface uses a self-signed certificate, which could be vulnerable to man-in-the-middle attacks. Another security concern related to the fact that the log messages sent out externally comprise a very limited subset of the actual log messages generated. A glaring example is the “the system has just been started” message is never sent to the outside world; it’s only reported internally.

Additionally, the documentation recommends placing the administrator password in a shell script to use for log file retrieval. No mention of the security implication of this is made – storing administrator passwords in clear text in an operator’s desktop machines is unsafe because a compromise to the desktop could compromise the IDS.

Finally, the tuning mode is documented as providing dynamic changes to the thresholds for the three indexes. This implies an extremely low-frequency attack might get by because instead of triggering an event, it might just tickle the automatic tuning adjustment mechanism to keep increasing its thresholds.

While the overall packaging could be improved, Stealthwatch does implement anomaly detection successfully. With appropriate safeguards in place and when used by skilled personnel, this would be valuable component of an enterprise network’s defenses.