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.

An International Language

Recently I had the privilege to travel abroad and do an exchange with cyber security analysts in other countries. The experience was wonderful -- and quite fascinating. What's amazing to me is that although we all come from different backgrounds and different experiences, we all want the same things. We want to be free to be creative and clever in defending and analyzing our networks. We want to safeguard information and intellectual property. We want to keep the attackers out, while not bringing undo hardship on legitimate users. And most of all, we want our respective leadership to "get it". Very interesting.

Aggregation

Aggregation is my friend. When I'm first introduced to a pile of data, be it logs, flow data, PCAP, etc., it can be overwhelming. With a client eagerly awaiting some results, what is an analyst to do? Enter aggregation. Aggregating data over multiple fields can help an analyst very quickly slice through data to get a big picture view and pull out events of interest to analyze further. It's also a great way to create jumping off points (reference an earlier post).

What are some of my favorite fields to aggregate over you may ask? In this post, I'll start with one of my favorites:

Source Port, Destination Port, Number of Bytes

Why do I find this particular aggregation so interesting? Let's go through it. For those that are familiar with Internet Protocol (IP), we know that servers typically communicate on a fixed port. For example, most web servers serve web pages on port 80. For this example, we will equate server port to destination port. In other words, we will assume that we are on the inside of our network looking out (in practice, this is actually a useful vantage point to take). Clients, on the other hand, choose a source (client) port in an incremental fashion. The exact method of picking the source port varies by operating system, but with a large enough sample, we can assume that the distribution of source ports is roughly uniform. In practice, network traffic is so voluminous, that this is a relatively safe assumption.

So, where does that leave us? Well, for starters, we can exploit the roughly uniform distribution of source (client) ports to identify cases in which the source port did not appear to be chosen as expected. In other words, one or more source ports were "favored" for one reason or another. Typically, an automated/machine action will cause one or more source ports to be "favored", whereas a human action would not have this same effect. If we aggregate source port, destination port, and number of bytes, what we're in effect doing is picking out instances where a given byte size is sent repeatedly from the same source port(s). Pretty neat, eh?

As an added benefit, this aggregation is time agnostic. That means that it can catch the low and slow attacks just as well as it can catch the blatantly obvious. Love it.

Ad Hoc

I often see working groups or standing meetings set up explicitly for the purpose of sharing cyber security information. What amazes me is how quickly these devolve into regularly scheduled knowledge droughts. I'm convinced that the most efficient transfers of knowledge happen in an ad hoc manner. When one or more parties seek knowledge and one or more parties have knowledge, the transaction is smooth and effortless. Kind of like water flowing downstream. Working groups, on the other hand, remind me of salmon swimming upstream to spawn....

My colleagues and I routinely share actionable information. It's all built on trust. There are no MOAs, no MOUs, and no working groups.