Esphion

The business worm

In my previous blog entry, I talked about the new liabilities faced by organizations whose data security may have been compromised by worms. To summarize: Having a worm outbreak on the internal network in certain industries may violate various regulations, and thus cause legal consequences for affected organizations. I argued that anomaly detection systems, which can alert operators to the presence of a worm in the network and aid in the rapid mitigation of the outbreak, have become part of best-practices and thus should be mandatory for all organizations.

Today then, as if to make the point, Red Herring published this article, in which they talk about the arrival of the business worm. It describes how hard big financial organizations have been hit by the Zotob worm, and how smaller, more targeted worms can be used to extract business information. It also elaborates on the fact that the Zotob worm was mostly confined to corporate environments, where an explosive outbreak occurred behind the heavily defended perimeter of the network. This, of course, supports the point I made repeatedly in this blog: You need anomaly detection within your network to be alerted to a worm outbreak. Defending the perimeter is close to useless in preventing these events, as Zotob has shown.

The article concludes with these fitting remarks:

With the time between the discovery of a vulnerability and a virus outbreak shortened significantly, enterprise users will have to institute new protocols to deal with worms and viruses of the future...

In short, they will have to become more proactive ... To do this, they will need to take care of security problems before they reach users ...

This is of course exactly what we talked about in the article about the shrinking patch-window, and also in several prior blog entries, in which I mentioned things like self-defending networks.

Juergen

New liabilities - Or: Why anomaly detection has to be part of best-practices security

In an opinionated, but insightful article on The Inquirer web-site, an author mentions the case of a large financial organization, whose network was compromised by the recent Zotob worm. The article then goes on to discuss the liabilities that financial and health organizations may face when it is discovered that they had such a security breach.

Worm outbreaks as security events
Firstly, it is important to recognize that a worm infection in any corporate network is indeed a security breach: You cannot guarantee which backdoors or trojans are or were running on an infected machine. Thus, any data on that machine may have been accessed by some unauthorized outside party.

This means then that organizations in certain industries, in which regulations apply such as the Sarbanes-Oxley act, may face severe penalties for any such security incident. At the same time, these organizations are burdened with an IT infrastructure, which is prone to be buggy and with exploitable vulnerabilities popping up with either no or only very short advance notice. As we know, the patch-window is shrinking, which gives organizations less and less time to react, and may even be entirely absent in the case of a true zero-day exploit.

Claiming best-practices as defense
One of the key defenses that an organization has against any legal charges is to claim that whichever procedures and systems they had in place are commonly accepted as best-practice in the industry. For example, for the longest time, having firewalls was best-practice, and not much more was agreed upon for network security. These days, we know that firewalls alone are not sufficient, and defense in-depth is needed. For any large corporation, best-practice includes also timely patching and internal firewalls, just to name a few items.

All of these defense mechanisms, however, have a serious drawback: They are based on prior-knowledge. On rules and signatures, which have to be configured or loaded and kept up-to-date. Defending against the unknown, such as a zero-day worm, or a worm which takes advantage of a very recent exploit, is not readily possible with those traditional means of security.

Organizations need to improve their security architectures
I think it is only a matter of time before the various regulatory agencies realize that many organizations in critical industries and sectors are just not doing enough. For example, behavioral based anomaly detection has been around for a while. With truly intelligent solutions, such as those based on neural networks, these systems can rapidly detect outbreaks even of zero-day worms. With the right solution, mitigation signatures can be extracted in real-time, without having to rely on any prior knowledge. With that in place, networks can protect themselves rapidly. See here for more detail on how this can be done.

Anomaly detection is already part of the best-practices
Therefore, anomaly detection is a readily available tool, which is ready for main-stream deployment. The regulatory agencies will soon realize that there is no reason not to have those solutions as part of a best-practices security architecture.

So when will organizations learn that they need to significantly improve their security approach? The article says:

Here is when they'll learn, when someone notices that getting infected violates a whole bunch of laws, and that brings down the legal hammers on them.

It is not necessary to let it come that far. Organizations today already have cost effective and very powerful solutions available in the form of intelligent, neural-network powered behavioral anomaly detection systems. Deploying those in your network will lend a lot of credibility to any claim of following best-practices.

Juergen

 

What Zotob is teaching us - Or: The shrinking patch-window

InformationWeek today is running an article, in which they discuss how the currently active Zotob worm illustrates one key emerging fact about computer and network security: The so-called patch-window is rapidly disappearing.

The patch-window, of course, is the time between announcement of a vulnerability and the arrival of the first malware which tries to exploit that vulnerability. In that time period a vulnerable machine was therefore not likely to be exploited, and thus, this was the time period that the network or system administrators had to apply the necessary security patches.

Often, the authors of this malware actually derive the exploit code from reverse-engineering the patches, which are issued by the vendors. In the past, the patch-window was measured in weeks or even months. These days, as was the case with the Zotob worm, it just took a few days. Apparently, the authors of the malware are becoming more adept and efficient in constructing working exploit code and releasing it into the wild.

One could claim that even a patch window of a few days should be sufficient, since modern operating systems tend to provide convenient and easy-to-use patch mechanisms. However, that is simply not the case: Everyone trying to upgrade all the computers in a sufficiently large enterprise network will be able to attest to that.

And if the ever shrinking patch-window is not enough of a concern, there is always the looming threat of a true zero-day worm, a worm that takes advantage of a previously completely unknown exploit, or an exploit for which no patch at all is available. This Witty worm was a great example of how real this threat is.

Johannes Ullrich, chief research officer at the SANS Internet Storm Center, is quoted in the InformationWeek article as saying: "Defense in depth is your only chance to survive the early release of malware." Defense in depths means that one does not simply rely on perimeter defenses, such as firewalls, but instead has security systems in place throughout the network.

It is our position that ideally, since signatures of an exploit are not available for zero-day threats, these security systems should not rely on signatures, or on any prior knowledge. Instead, behavioral anomaly detection can be used to great effect in those situations. For more details, may I also point out what I wrote here about where to deploy anomaly detection. Also see here about how those systems allow for the construction of a self-healing and adaptive network infrastructure, which can deal with those issues, no matter what happens to the patch window.

Juergen

Distributed computing for anomaly detection

Today I want to talk a little bit about some of the underlying technologies we use in netDeFlect, Esphion's network anomaly detection solution. There are some core technologies, such as neural networks, which enable us to detect network anomalies by means of a highly-trained, specialized artificial intelligence, which is present in each netDeFlect installation. Other core technologies include components for high-speed packet processing, sophisticated data structures for fast lookups of information and advanced visualization and reporting capabilities.

To provide a complete, powerful and flexible solution, a lot of different technologies had to be combined in an innovative way. One of the things I find very attractive, but which normally takes place entirely hidden 'behind the curtains' is our use of load-balancing for the CPU intensive task of analyzing network packets and the extraction of zero-day signatures.

Before joining Esphion, I worked in a company, which specialized in server load-balancing solutions. I was an early employee there, and developed much of their core technology. Some of the largest web-sites in the world used our load-balancing systems to keep their business running, and manage massive amounts of hits on their servers. Therefore, I am excited that at Esphion we were able to put load-balancing again to good use.

Extraction of fine-grained signatures
After netDeFlect's neural networks detect an anomaly, the system then aims to provide signatures of this anomaly to the network operators. This has to happen fully automatic, and within seconds of the onset of the anomaly. Having those signatures then allows the creation of filter instructions for various network devices. I talked here about how our solution, in combination with already existing network infrastructure, can result in a network security architecture, which is surprisingly resilient even against zero-day attacks.

It is important to note that we are talking about true zero-day signatures, which in no way rely on prior knowledge or a signature database. Using several sophisticated algorithms, we can rapidly extract those signatures out of life packet samples, thereby enabling network operators to instantly get a handle on such anomalies, and to instantly proceed with the mitigation of the anomaly.

The signatures we provide need to be fine-grained to the extent that it must be possible to filter out the bad traffic with only minimal or no impact on the legitimate traffic (see here for more information on this requirement). Since anomalous traffic may at first look exactly like ordinary traffic, this is not a simple task: The algorithms to perform this analysis are quite CPU intensive.

Balancing the signature extraction work-load
When our solution is installed in a customer's network, there is usually a centralized controller, as well as a number of agents (sensors, in effect), which are distributed across the network.

After an anomaly has been detected, and after all the necessary data and packet samples have been correlated, it would be easiest to simply run the signature-extraction algorithms on the central controller. However, such a design would not be scalable.

Esphion always has had a focus on innovation, which should be reflected in the practicality and usefulness, but also elegance of our solutions. Therefore, in order to accommodate the often CPU intensive extraction of anomaly signatures, our engineering team has implemented an underlying load-balancing mechanism. So, when there are traffic samples that need to be analyzed for signatures, the controller will properly distribute the work among the installed agents in the network. Thus, the overall work-load is split among the agents, who all collaborate under the supervision of the controller to arrive at the required fine-grained signatures.

As a result, our solution has a built-in scalability, since it grows with the network in which it is installed. I think we have a powerful, elegant and intelligent architecture, which benefits the network operators, because they always get zero-day signatures within just seconds of the onset of an anomaly, no matter how big their network is. This scalability allows us to analyze anomalies faster and in much greater detail, thereby discovering information about anomalies that otherwise would remain hidden.

Juergen

Worm detection - You need to do it yourself

Recently, as outlined in this CNET article, several research teams have published papers in which they explain that intelligent worms can avoid being detected by the large worm-detection and early warning networks. Those networks are run by various security organizations, such as SANS, but also by some commercial security companies.

The details are explained in that article. In essence, those networks use honeypots and the monitoring of activity on unused IP addresses to detect worm activity or capture worm samples. Both approaches can be detected with different techniques.

So, as a consequence, it should be possible to write a worm, which escapes detection of those networks long enough, to make sure that no signatures for that worm can be produced and published before it has already reached critical mass. This is yet another example of why signature-based systems are leaving an organization vulnerable for too long, in the face of potential zero day threats.

Worse yet: A fast spreading worm, such as SQL/Slammer, for example, does not even need to bother with avoiding the worm detection networks, since it will have reached all possible targets faster than any signature can be published anyway.

This just goes to show that for proper worm protection, one cannot rely on third parties to publish signatures in time. If you want to keep your network safe, you need to deploy your own worm protection, right into the middle of it. An intelligent system, such as Esphion's netDeFlect, will be able to detect a worm outbreak immediately, and provide signatures and filter instructions, even for zero day worms, that can be used to stop the worm before it gains momentum in your network.

Juergen

Don't assume - Or: Why intelligent anomaly detection is needed

The Worm Blog recently pointed to an interesting paper, in which the detection and incidence handling of an SQL/Slammer outbreak in an enterprise is discussed. Remarkably, the enterprise actually had a reasonably secure setup. They knew about the new worm, thought they had a handle on it, and still were compromised.

This real-life incidence report represents a great example of why prior assumptions can lead to massive security failure. Note that all signature based systems rely on prior assumptions (the signatures). Also note that many security architectures are built on prior assumptions. When you read the paper, you can see that the assumptions made by the security staff are actually quite reasonable. Yet, these assumptions eventually led to failure, which just goes to show that additional intelligence in the network is needed.

The paper contains a lot of background information about the Slammer worm, as well as the network setup of that enterprise. If you don't want to read the whole thing, I would like to point you to the chapter 'Identification' which starts on page 19 and ends on page 21. If you just read those three pages, you can take away some very important points:

1. Perimeter-based security is insufficient.  A worm outbreak can happen from any point, even from within the network, as in this case.
2. Assumptions about the direction of the attack (from the outside to the inside) meant that IDSs were deployed only for one-way monitoring, missing the scans from within the network. Assumptions are bad.
3. Most importantly: Intelligence is needed when analyzing the network traffic. After long, fruitless debugging and trouble shooting sessions, one of their engineers finally noted that the network traffic profile looked different. An intelligent anomaly detection solution would have had this information instantaneously.

All in all, it took the business some four hours to conclude with certainty that they had been compromised and were fighting a worm outbreak. Four hours, in which servers were slow to respond, had to be rebooted frequently, and during which their tech-support had to field numerous calls by customers, complaining that the services were slow.

Contrast this with the situation as it would have presented itself with an intelligent anomaly detection system in place:

1. An infected machine emerges somewhere within the network.
2. The intelligent anomaly detection solution recognizes this immediately  (note that Esphion's netDeFlect can even detect slow-scanning worms in seconds).
3. Alerts are sent to the administrators, packet samples are presented and ACLs are suggested, automatically, and within seconds of the onset of the attack.

Only seconds have elapsed from outbreak to detection, analysis and start of containment. Is this fast enough? It is, as I had discussed here.

So, in conclusion, the paper presents an excellent case why any organization, which really wants to protect their uptime and assets, should consider the deployment of an intelligent anomaly detection solution, right in the middle of their network.

Juergen