Using policies to control packet storage for NSM

Making raw network packets available during  Incident Detection or Response (IDR) is a key goal of Trisul.   I encourage you to read the Tao Security blog  on the importance of keeping everything around.

If you look at investigations like GhostNet or Shadows in the Cloud,  it would be immediately apparent how easy and comprehensive it could have been if everything (packets, flows, statistics) were  available to the investigating team.

Lets take a look at two of the issues with storing raw packets.

• Volume :  “Are you crazy ? We cant possibly store everything” Many organizations consider the very proposition of storing packets insane. To a certain extent it is true.  If you monitoring their WAN links, you could probably store everything.  But if you are monitoring their high traffic internal switches – you would quickly run out of disk. 
  
• Privacy : Storing raw pcaps in the clear of your entire organizations traffic on a set of disks is a major security hole.  You need to protect the NSM tool with a much higher level of security than you protect your main assets. You also have issues of failed disks, re-purposing disks, sharing NAS storage with other applications, etc.

Lets look at the approach Trisul has taken to address the above two concerns.

Volume

Here is an interesting anecdote. We installed Trisul at a medium size company with 1000+ employees in Bangalore. It was monitoring an internal switch by port mirroring packets into the Trisul box.  They had a 500GB disk dedicated to Trisul, but we found that at best we could hold 2 days worth of data.  This was intriguing because we never found the users to be that busy online or even internally.  After digging through, we found that two things were filling up Trisuls raw packet storage :

• A daily Anti Virus  push to all machines
• A daily full offsite backup of their code and data

These two activities were from trusted end points.  The truly paranoid would not even trust these machines, but the sysadmins vouched for their trustworthiness.  We needed a way to prune this traffic out of the raw packet storage.

With Trisul, you can specify rules to

• exclude traffic based on various criteria : exclude subnets, hosts, applications, even MACs
• cap traffic per flow : say only store 10M of each flow

Read our product documentation for more on this.

Privacy

This is a major concern especially in small or medium companies which may not have very well defined separation of monitoring and production networks.

Trisul deals with this by,

• Encrypting all packets stored by the stream cipher AES-256 CTR
• The disk subsystem never sees clear text packets
• The encryption key can be protected by the same methods you use to protect Apache or Nginx keys

While this is not 100% fool proof, it addresses most of the concerns. An intruder cannot just pick up a disk volume and do a ‘dd’ on it.

Interface

Being able to script this task of digging through data is critical. Simply because you are human.  Trisul provides a programmatic remote scripting interface called Trisul Remote Protocol.  Your script runs on your local machine but requests data processing on the Trisul server.  Check out our getting started tutorial with Ruby and TRP.

I encourage everyone who is into security incident response to give Trisul a try.   If you want to monitor a rolling 3-day window, Trisul is completely free.