Esphion

Anomaly detection is not the same as baselining

Sometimes, when we discuss our anomaly detection solutions with potential customers or analysts, we notice that there is still a lack of knowledge out there about the power and nature of intelligent anomaly detection. Often we are asked: "Is anomaly detection not just a fancy name for baselining?" Of course it is not, but it is understandable why many people would think that. After all, the first systems which claimed to be able to detect anomalies on the network were indeed based on baselines, or worse, on manually specified rules. And even today there are still systems out there, which try to utilize baselining to detect network anomalies.

We believe that this technique is very much flawed, and that an intelligent approach to anomaly detection is needed. This is why we employ artificial intelligence, by using specialized neural networks in netDeFlect, Esphion's anomaly detection solution.

But let me outline this issue in more detail.

Baselining: What is it and what are the problems?
The idea of baselining is simple: Observe the network and record certain statistics about the network. Then find averages, minima and maxima for those statistics. After that is done, continue to observe and raise an alarm if the observed statistic deviates out of the established range.

For example: Let's say you observe the packet rate on your network for a week. You find that during that week you see a maximum rate of X pps. You can then monitor to see if the packet rate ever exceeds X, which might be indicative of a DDoS attack. If X is exceeded, you can sound an alarm. In effect, X has become the baseline, on which you base continuous anomaly detection.

This is a very simple example, but illustrates an important point about all baselining techniques: They rely on historical data. In other words, the network has been observed, and something that was typical about the network during the observation period has been retained and is used from now on.

The problem then is obvious: If the behavior of your network changes for legitimate reasons, then such a baselined system will not be able to differentiate between an anomaly that needs to be investigated and a normal, legitimate increase in network activity. An additional disadvantage is that anomalies can only be detected for the baselines which have been established.

There are many variations and advanced techniques which have been developed over time, in order to make baselining more suitable to deal with a real and changing world. However, the core problem always remains: Reliance on historical data, which inevitably leads to false positives, or missed anomalies.

Using intelligence, rather than historical data
While there is always a place for baselining as a supportive technology, the core detection of anomalies has to be much more intelligent than that. We are using specialized neural networks with great success. Neural networks, as you know, mimic the way in which the human brain works. This is the level of intelligence that is needed to be good in the field.

These neural networks look at the traffic in an entirely different way. Rather than comparing current data with historical data they look at how the traffic interacts, and how different types of traffic relate to each other. The neural networks allow us to look into the network at this very moment, without any concern for what it was like in the past. They enable us to examine how things are changing not just if they are different from something that was observed a while back.

This intelligence allows the neural networks to produce accurate results, even if the overall network usage profile has changed, for example when new applications have been enabled, or the user base has increased. A baselining system has graet difficulties with a situation like this. A truly intelligent system, just like an experienced network engineer, does not.

Juergen

More problems with flows

A few weeks ago, I wrote about the need and advantages of being able to generate fine-grained signatures of network anomalies. In that article, I also mentioned that those anomaly detection solutions, which are based on flows (for example Cisco's Netflow) are quite powerless when it comes to the generation of signatures, since they do not get any insight into the actual packet payload or even headers. I concluded that for effective signature generation, one needs to have a packet-based solution, which can see all the data all the time, not just some meta-summary of the network traffic.

However, there are additional significant disadvantages of a flow-based approach to anomaly detection, which I would like to elaborate on today.

Firstly, where do those flows come from? They are generated by third-party network devices, such as routers or switches. This has several interesting consequences:

1. The routers and switches need to perform CPU intensive calculations for every packet they see, in order to properly accumulate the flow-information.
2. Routers and switches need to set aside a significant amount of RAM, in order to store the flow table.
3. Routers and switches may suffer heavily under certain attacks. What does that mean for flow generation?
4. Exported flows are send over the network to some collector. How much traffic is that?

You observe, you change
In quantum mechanics, there is something called the uncertainty principle, which (in drastically simplifying words) states that you cannot observe something without changing it. The mere presence of an observer or test equipment changes what we observe.

Back in the world of network anomaly detection, we know that it is a non-trivial task for a switch or router to generate flow records. By consuming significant CPU cycles and memory, enabling flow-generation changes the behavior of the switch or router, usually by making it less responsive and pushing it somewhat closer to the edge of its capabilities.

For an anomaly detection solution, which is based on flows, the flow-generation needs to be enabled on the routers or switches. Just like stated in the uncertainty principle, our attempt to observe the network has itself a significant impact on how the network performs and behaves. The mere fact that we are observing is changing what we hope to see.

Not overloaded, yet?
The third point made above states that many anomalies or attacks, such as DDoS or worm outbreaks, can have a significant impact on network infrastructure elements, such as routers or switches. By having the resource intensive flow-generation enabled, those elements are even further taxed, thereby making them more likely to break under times of increased stress.

Of course, if the source of the flow-records disappears into the tar pit of CPU overload or the sunset of frequent reboot cycles, where does a flow-based anomaly detection solution get the flow-records from, that it needs to have any kind of visibility? As it turns out, flow-generation taxes the most heavily used resource on your network even further. To add insult to injury, its eventual failure then leaves the anomaly detection solution entirely blinded.

In general it is not a good idea to rely on the availability of network infrastructure, if one wishes to monitor possible attacks on that very infrastructure.

Increasing the severity of the anomaly
The fourth point made earlier refers to the mechanism by which a flow-based anomaly detection solution gets the flow-records: Over the network. This is usually not the high-capacity 'public' network, but instead an internal management network. Unfortunately, this network, or the management interfaces of the router or switch, may be maxed out by the additional load.

Consider that a typical flow record is a few dozen bytes in length (depending on Netflow version). Consider further that a DDoS attack may generate packets that are just 20 to 40 bytes in size, and that they can be crafted to each represent a new flow. Thus, the amount of flow record data is almost as big as the attack traffic itself. And all of this gets unloaded over the management interface of the router. Clearly, this is not practical, since here again, a resource is taxed more heavily when we are already under attack.

Sampling as a solution? Not really...
In short: With flow-generation enabled the effect of a network anomaly on the network infrastructure is multiplied, making the job easier for an attacker.

Some vendors of flow-generating devices offer sampling to eliviate this problem. In the case of sampling, only every nth packet is considered for the generation of flows. Clearly, this reduces CPU load and the number of flows that are exported. However, this also dramatically reduces accuracy. For example, if only every 100th packet is sampled, then flows that are a few dozen packets in length are likely to appear as only one packet. This makes them indistinguishable from flows that really consist of only a single packet. Average flow-length, however, is an important indicator in the state of the network. With sampling this data is lost. Besides, entire conversations between hosts may slip through the cracks, if sampling is enabled.

Clearly, sampling is only a stop-gap measure, which does not truly address or even fix the fundamental weakness of flows: A tradefoff between accuracy on one hand and massive resource impact on the network infrastructure on the other hand.

Packet-based anomaly detection
How does packet-based anomaly detection address those problems? For the most part, the problems simply do not occur at all.

For starters, a packet-based anomaly detection solution, such as Esphion's netDeFlect, can happily feed raw packets off a fiber tap. While the uncertainty principle still applies, of course, it does so on a much lower level: The signal in the fiber is slightly changed, but only to a degree that the interface hardware can easily deal with and compensate for. There is literally zero impact on the router or switch itself. No additional CPU cycles, no additional memory. In fact, the router or switch is entirely unaware that the traffic is listened to via a fiber tap.

A popular deployment alternative for a packet-based solution is to utilize a mirror or spanning port on the router or switch. This does have some impact on the device. However, mirroring or spanning is performed on the data plane (ASICs), rather than the control plane  (CPU) of the device. Therefore, the impact is typically negligable, compared to the generation of flow-records, and does normally not involve the CPU of the router or switch at all.

Finally, no data needs to be exported across the control network from the infrastructure device to the anomaly detection solution. This means that the magnitude of the anomaly or attack is not inadvertently multiplied by the export of an excessive number of flow records.

Conslusion
A packet-based solution continues to see all packets, no matter how overloaded the network infrastructure devices are. As long as there are packets on the wire, they can be seen, counted, analyzed and reported on. Therefore, the accuracy of the packet-based approach is not only much higher, but is also accomplished with a greatly reduced overhead and impact on the network.

Juergen

Using existing infrastructure to fight the vanishing perimeter

Recently, I wrote about Network self-vaccination, the idea to model network defense after the biological immune system. I argued that even the existing network infrastructure elements can be used for a dynamic security defense, if used in conjunction with intelligent anomaly detection solutions that are properly deployed and equipped with certain advanced analysis features.

Today now, Ellen Messmer writes in the Network World magazine's own blog about the vanishing perimeter, and how an organization called The Jericho Forum thinks that the perimeter is gone, and that firewalls are obsolete and posibly a bad idea anyway.

I think that modern security architectures are needed in responses to modern threads. But I also have to agree with Ellen Messmer and think that it is way too early to declare firewalls outdated.

We at Esphion have always maintained: A secure network needs more than just firewalls. But that does not mean that the firewalls should be thrown out. Our position is that with the arrival of intelligent anomaly detection solutions, such as Esphion's netDeFlect, it is possible to extend the useful life of firewalls, routers and switches, and make them part of an adaptive, dynamic overall security approach.

Juergen