Premonition

Analysis junkies like me get an intuitive feeling about particular ways to slice and dice network traffic data that are likely to produce interesting results. I had never heard this referred to formally until a meeting I was in this past week. My counterpart used the word "premonition". I like it. It's now in my digerati vocabulary.

Uncommon Protocols

IANA assigns 256 registered Internet Protocol numbers (0-255). The protocols assigned to each number vary widely in capability, purpose, and function. What protocols do you route on your network? For sure TCP, UDP, and ICMP. Perhaps a few others as well for one reason or another. Are you sure that you only route the protocols you think you do? Looking at the data is the only way to find out for sure.

A colleague of mine was looking at a client network and discovered that the client was routing some pretty unusual protocols. The client was not aware of this and became quite concerned. Just another reason we should all be vigilant in monitoring our networks and studying what the data are telling us.

Logging Update

I have good news regarding the logging issues I described in previous posts. I sat down with the client and the vendor, and we had a productive meeting together. We all agreed that logging of DNS queries ought to be part of the product. In fact, the vendor couldn't understand why it was ever overlooked/omitted by them in the first place. The vendor agreed to include this feature in the next release of the product (date of release still undetermined).

The good news here is that analyzing the data on the network revealed a shortcoming in a vendor solution that many organizations use (including yours perhaps). Most people probably rely on the logging of this product without having any reason to question it. My hope here is that the issue I identified will allow this vendor's entire customer base to better protect and defend their networks.

Today is a good day. The entire cyber security community will benefit because of this. Now that's cool.

Looking Outward

The Internet is a noisy and scary place. When analyzing their network traffic, how can an organization effectively and efficiently sift through all the noise? One method to help with this is to look outward. What do I mean by this? By looking outward, I mean focusing on traffic leaving your enterprise (headed to IP addresses that are external to your network). This works primarily for one reason: Although there may be a great deal of noise on the Internet and a great deal of noise internally, there shouldn't be a cross pollination between those two noisy realms. That cross pollination would be indicative of something anomalous leaving your network (other than the routine/obvious types of outbound traffic that we would expect).

There are some ways to further reduce the noise contained within outbound traffic, and I will blog about those in a future post. The bottom line is that if you can create a jumping off point with very little noise, it's going to be an efficient analytical technique.

Acquisition

On June 15th, NetflowData LLC was acquired by 21st Century Technologies, Inc. The acquisition creates an awesome combo, and I'll tell you why I think so. NetflowData LLC specialized in an analytical approach to information security. We took an objective look at network traffic data and used analytical techniques to ferret out odd and unusual traffic. 21st Century Technologies is a software company with a product solution named LYNXeon. LYNXeon specializes in deep graph analytics over large data sets. It's the perfect platform for us to marry our analytical skills to. Here's to the future. Cheers.

Inspiration

Inspiration can be found all around us. Sometimes it's just a matter of taking a moment to realize the treasures found around us. One example I often give is the relation of cars on a highway to network traffic analysis. When you drive down the highway, you expect to see many different types of cars around you. If you saw all the same type of car, you'd find it quite strange. Network traffic is the same. It should appear quite random/all the packets should be different from one another. If we start seeing a bunch of traffic that correlates strongly with a bunch of other traffic (in other words, it looks the same), then that is anomalous. An interesting application of a principle from the analog world to the digital world.

Logging (Non-)Resolution

So, after a few weeks of going back and forth with the vendor on the logging issues I described in a previous post, we came to the conclusion that the product does not support logging of DNS requests. There are no plans to include this feature at this time, and there is no way to work around/override. So, where does that leave this client? Flying somewhat blind, unfortunately.

There is a valuable lesson here. We're only as good as our logging, and we can't assume that a device is logging properly. We have to use a scientific approach and look at what the data tell us before we can know what is actually going on. It's a painful lesson, but an important one in the quest to "Know Your Network".

Lesson learned.