NetWitness Minidecoder in Action

Many TaoSecurity Blog readers are undoubtedly familiar with NetWitness. Several weeks ago I met with their CEO and CTO to discuss their products and services. They were kind enough to later provide me with a device that they ship to their engineers to provide testing and experimentation with their product. Here I call it a "Minidecoder," but you can think of it as "NetWitness in an EeeBox PC" (specifically the EeeBox PC EB1012).

As you can see in the diagram, it only has one onboard NIC, and that is used for management. To access traffic, NetWitness provided a Trendnet TU2-ET100 USB to 10/100Mbps Adapter. To try the Minidecoder, I paired it with the DualComm device mentioned in my last post. I basically tapped the Minidecoder's own management port and then generated some basic traffic from the Minidecoder's Linux shell. The sensor also saw its own management traffic, as well as broadcast traffic passed by the wireless bridge to which it was connected.

Setup was pretty painless. I booted the Minidecoder, logged into the Linux OS, connected the network cables, and configured the management port.

To administer the device and access the data, I installed the NetWitness Administrator and Investigator applications on a Windows XP SP3 laptop.

In the screen capture at left, you see part of the Administrator interface. It was easy to add and connect the Minidecoder after I obtained a license from NetWitness. I didn't need to run anything on Windows with Administrator privileges, other than the installation process.

I'm not a big fan of dashboards, but I wouldn't expect to spend much time in this view anyway. The action is in Investigator, which I also installed.

As you can see in the figure at right, NetWitness breaks down the traffic using a variety of means. I'm only showing what would fit on the screen.

One of my favorite aspects of the NetWitness metadata approach is the way it extracts meaningful content automatically, like the system names from within DHCP traffic (independent of DNS names, for example). This is why I've added metadata as the seventh form of NSM data (after full content, session, statistical, alert, transaction, and extracted content). NetWitness is good at depicting "data about data," i.e., details about traffic, derived from the traffic.

I also like the way NetWitness classifies a variety of traffic into "Action Events" like "Get". Here I will select the sessions associated with the Get Action Event to produce the screen shot that follows.

In this screen capture you can see sessions which NetWitness classified as Get events. I chose part of a Lynx session where I browsed to www.bejtlich.net. The large sessions with the "Click to Create" boxes are sessions where I retrieved packages for installing Lynx on the Linux OS of the Minidecoder itself. (Remember this traffic is to and from the Minidecoder, just for the sake of the test.)

I think this is a cool way to get more familiar with NetWitness in a low-impact way. I wouldn't try to stress test this device since neither the hardware nor the NICs are intended for intense use. Rather, you could deploy a device like this in your environment to get a better idea of how NetWitness would process your environment's traffic, or at least a subset of it, if you had to throttle what was sent to the sensor.

Feel free to contact NetWitness for more information, and thanks to Amit and Tim for the demo gear!

Tweet