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.

A Dangerous Box

My colleagues and I recently discussed how people seem to stop thinking when they are looking at a computer screen. People seem to believe what "the system" says, even when it may be nonsensical (e.g., in the case of an obvious data error). I don't quite understand this behavior. "The system" is only as reliable as the data that are in it. In some cases, the data are flat out wrong. Some people can't grok that I suppose. That's a dangerous box to live inside, don't you think?

Only As Good As Your Logging

I'm helping a client work through an interesting issue this week. It seems that one of their network monitoring devices is not logging as one would expect. You know, the type of network monitoring device everyone buys precisely for the increased network visibility provided by quality logging? I will remain vague on the device here so as not to seem to favor one technology over another. It seems that the documentation on the device's logging ability could be a lot better, and on top of that, what the device logs (and doesn't log) seems to be somewhat arbitrary. How did I stumble upon this issue? I noticed the device making certain DNS queries, but couldn't find any corresponding log entries in the device's logs that would explain said DNS queries. Yikes!

So, herein lies the rub. I had set up several jumping off points that queued off this device's logs. I assumed that the device was logging properly and gave myself a big pat on the back for helping this client defend its network. Not so fast.... I guess one can never assume....

Still working on this one....stay tuned....

Anecdotal Assumption

I had an interesting meeting this past week with some nice folks who run a fairly important network. During the meeting, we spent a fair bit of time discussing some of their concerns relating to the security of the network. I was surprised to find out that one of their biggest concerns is the network being attacked and brought down. Not because it can't happen (it certainly could), but rather because it's a big hypothetical. Compare that to what's probably already happening. I asked those on the other side of the conference room table how they were monitoring their network. Their response? "We aren't." Yikes. I'm not a betting man, but if I were, I'd probably bet that there are already nefarious elements on their network operating as they please (be it for profit or other means). Perhaps these nefarious elements are slowly taking bits and pieces of the network for themselves as it pleases them. Just slowly enough so as not to raise any eyebrows. How can my new friends find out for sure what's on their network? Take a look at it. Let the data tell you what's on the network and what the biggest threats to the network are.

I often hear people mention the whole "bring the network down" fear. Personally, I'm much more concerned with what's already on the network and is a real, tangible threat. Worried about some hypothetical future attack? Call your upstream providers. Make sure you have a good rapport with them, and that they know how to drop packets when packets need to be dropped. Preparations complete. Next threat please.

Jumping Off Points

People often ask me, "How do I find the bad stuff on my network"? Well, the answer to this is relatively straightforward. Knowing what belongs on your network is a great way to know what doesn't belong on your network. Easier said than done for sure. How do you come to know your network, or at least come close to knowing your network? Jumping off points are a key piece to answering this question. What is a jumping off point you ask? It's all about perspective. Most organizations have an incredible amount of network traffic data. It's far too much to dig through with a fork. The trick is to organize the data using a number of different methods. These methods produce different views or perspectives into the data. Often, this results in certain suspicious or malicious activity jumping out at an analyst, which leads to further investigation. The part that the analyst seizes on? That's called a jumping off point.

In my experience, most organizations give their analysts a fork and a giant pile of data and say "dig". Naturally, most of us can't get our heads around the data in this manner (largely because it's so immense). I've found that creating actionable jumping off points for analysts allows them to seize upon anomalous events and investigate them to resolution. In my opinion, a much more efficient way to roll.

The First Post

Here I stand about to enter the blogosphere. I created this blog to share my thoughts about and experience in applying mature analytical techniques to the domain of cyber security. My general philosophy is simple: Know Your Network. Throughout my career, I've observed many instances where individuals make assumptions, and worse yet, decisions about the (in)security of their network based on heresay and anecdotal evidence. In science, factual evidence is required to support a hypothesis. I'd argue the same should be true in the field of cyber security.