Wire data – more flexible than log data?
Is Wire Data More Flexible Then Log Data?
Just after finishing a pretty long road trip around the US, New York, New Jersey, Washington DC, Chicago, Austin and San Francisco. Travelling around the US this time of year can be very ‘challenging’ for sure, some airports can handle the snow and some like Newark do an OK job. Although sitting in an airplane at the gate for over 3 hours in Newark Saturday night, waiting for my flight to Shannon to leave and one of the pilots to arrive was not an act of God. Imagine he was the one guy who got caught in traffic, all the other people on the flight knew bad weather was on the way and adjusted travel plans accordingly!
Anyway, it was a great trip, I met some partners and customers, really enjoyed and appreciate their time and feedback. One interesting term that was mentioned a lot was ‘wire data analytics’. Why? What are the use cases? How does ‘wire data’ add value?
A lot of the use cases seem to be security, data related. Comes down to the detail one can get from looking inside the packets and is not available from flow technologies like NetFlow. Looking inside the packet, deep packet inspection does not always have to be about timings, latency QoE, etc. It can help provide the proof, that final piece of detail to really understand what happened, the domain name and URI for example and amount of data uploaded or downloaded. Critical pieces of information for security forensics.
For example, Ransomware is still very common. One user in a company got hit by cryptolocker, had no backup and were considering paying the ransom. These bad guys are targeting the file shares, creating files with strange file names, like ‘howdecrypt.txt’, encrypting, etc. Boy, do you miss your data when you can’t access it, like when your Windows laptop gets corrupted and will not boot, you will try anything to get your data back.
So, who does wire data help with Ransomware for example ? Well, if you can capture the right level of detail ‘off the wire’, like the file name, the user name, the source IP address, the action (say ‘create file’) and the server IP address. Then one can alert or block the source IP and prevent further infection. Also use the information to see if other hosts or servers have been infected. Comparing wire data and log data in this case is also very interesting.
Log data can also be very useful when troubleshooting, but crucially in this particular use case, if logging is enabled on the Windows file share server, the logged detail does not include the source or client IP address. It includes an awful lot of other detail, sometimes adding huge overhead to the server, but not the source IP, which is usually pretty useful!
But this also demonstrates the flexibility of ‘wire data’, you can of course capture it at any point across the network, SPAN multiple VLANS for example. Also, if you have a SMB dissector available (as in our NetFort LANGuardian) and it is intelligent and fast enough, the dissector can decide which data to identify, extract, and keep.
You do not want to keep every single packet because then you will have a Big Data problem and you will not be able to see anything useful unless you are an expert. In the case above you can decide to extract and store the client IP address, easier than going back to Microsoft and telling to also log this in a future version!
Wire data is not dependent on the format or content of the log and can be a very flexible and independent option.