First Impressions of Lancope StealthWatch

Sometimes vendors send me gear to try in my lab. I was fortunate to receive a StealthWatch appliance from Lancope, which I tried for a few weeks on a production T-3 link. Lancope calls StealthWatch a "Network Behavior Anomaly Detection (NBAD)" system. It is a signature-free product that analyzes network traffic and reports what it considers odd and potentially problematic events.

The following is my impressions of the system, based on three assumptions. First, I did not try to stress-test or attack the system to gauge its performance under load. I placed it on a production network as any other client might. Second, I did not validate its findings independently. In other words, I did not collect information on another system to test if a StealthWatch "high traffic" alarm truly corresponded to a "high traffic" event. Third, I did not fully configure the system as one might as a Lancope customer. Full utilization of this or any security product usually demands a fair amount of local customization and tuning. Given these assumptions, here is what I thought about the StealthWatch.

StealthWatch provided me a great deal of information with an out-of-the-box configuration. The only real changes I made when I deployed the system was defining which hosts were part of the "inside" network. If I had disabled an unused sniffing interface as recommended by the StealthWatch sales engineers, I would not have seen the "traffic lost" alerts that appeared in the introductory screen. I did not need to make any special adjustments for my deployment using a Net Optics tap. I simply plugged the two TX lines coming out of the tap into two free sniffing interfaces on the StealthWatch. This means I deployed the system in a passive mode; it did not block traffic based on its findings. After performing some simple configuration on the local console, I remotely accessed the device using a HTTPS-enabled Web server.

Introductory Screen

The introductory screen summarizes concern indices for inside and outside traffic, and provides links to alarms. The left hand size of the interface allows easy access to a variety of reporting and configuration options.

Alarms Screen

The alarms screen allows the user to view events StealthWatch considers odd or problematic. The screen shown above lists all priorities together, but the user can filter to just show Critical alarms, Major alarms, and so on. These alarms are not based on sigatures for malicious events. Rather, you are more likely to see entries for unusually long traffic flows, unrecognized operating systems, and other network features not corresponding to StealthWatch's profile for normal activity. For demonstration purposes I investigated an outside (external) IP address that StealthWatch believed was sending a high amount of traffic.

Host Summary

I saw that the host in question was responsible for a number of high total traffic alarms. At this point I wanted to know more about the characteristics of these suspicious flows. Luckily I was able to use the StealthWatch to perform two types of deeper analysis.

Flow Analysis

I was able to perform flow analysis on data that StealthWatch already collected. The partial screen capture above shows that port 500 UDP is involved. This means the traffic is probably IPSec key exchange. To find out for sure, I moved to the second additional form of analysis -- packet analysis.

Packet Analysis

StealthWatch does not log full content data by default, but users can configure it to do so. I set up a packet capture filter to log traffic associated with the IP of interest in my investigation. Although users can collect data in a text-format, packet-by-packet manner, I specified collecting full content data in libpcap format. After several minutes I stopped the capture process, copied the data via the Web GUI to my local workstation, and opened it with Ethereal. I do not show a screen capture of this here, but there are many options for recording full content data available in the Web GUI.

Service Profiles

One of the most powerful aspects of systems like StealthWatch is its ability to build profiles of normal network activity. Deviations from these profiles are reported as anomalies. These alarms can be viewed from the network security monitoring standpoint as indications of suspicious or malicious activity. The screen shot above shows the service profile built for hosts on the monitored network. These can and should be tuned for each system, allowing the security and network staff to spot the appearance of new and potentially unauthorized services.

Traffic Profiles

In addition to profiling services on hosts, StealthWatch offers a number of ways to profile traffic to and from those hosts. I have selected one profile showing bandwidth usage, but many more options exist.

Because I promised not to expose the entire StealthWatch interface on this blog, I will end this discussion by mentioning other features I found useful. StealthWatch reports on new hosts and inactive hosts, helping networking staff keep an inventory of their systems. The interface and recorded data allows a fairly thorough analysis of hosts and their activity. Because this data is not based on signatures, you are likely to acquire evidence of activity you wouldn't find using other means.

My main complaint, based on experimenting with the product, is not unique to StealthWatch. A common criticism of anomaly-based systems is their potential inability to explain why they consider an event to be problematic. I did not find StealthWatch to be difficult in this respect, since an alarm for a "long flow" is unambiguous.

Getting to a deeper level of analysis can be a challenge for certain events. In the previous example, I was able to use flow analysis to identify IPSec key exchange. Getting down to the nitty-gritty via packet analysis required setting up a new packet capture process, however. In this respect, StealthWatch resembles intrusion detection systems that do not provide at least a sample packet from the unusual activity. I understand that giving the user a packet can be difficult when the event in question is a "long flow" or "multiple operating systems." I think such data is useful, even if not all alarms provide it. Giving the analyst one or more sample packets with a "long flow" alarm would enhance his investigative arsenal and reduce the likelihood of ignoring "false alarms."

Overall I found the StealthWatch to be a powerful appliance. I could see engineers deploying this system to provide indications and warnings on networks already monitored by traditional IDSs. I think the utility of the system increases as the owner spends time tuning and configuring it, but the StealthWatch provides plenty of interesting data straight away. From the network security monitoring perspective, StealthWatch provides alert data via its alarms, session data via flow analysis, statistical data via profiling, and full content data via packet collection. I welcome this sort of functionality in commercial systems!

Thank you to Jason Anderson at Lancope for shipping me this demo appliance. Feel free to contact Lancope for more information. You might also want to attend one of their Webinars or see them at an upcoming event.

Update: Jason Anderson adds the following good news:

"In our upcoming release, we will now include ~100 bytes of packet data with every flow. It will include the initiating packet header and 40 bytes of payload data from the first packet in each direction."

This helps address my earlier point about giving analysts the information necessary to investigate and validate events.