Blended malware defence

Anti-malware vendors talk a lot about ‘blended threats’ and their solution is always ‘defence in depth’, which besides being a great way of selling more products is basically the right direction. For many reasons, our systems still contain vulnerabilities and are likely always to do so until the economics of system design and implementation change dramatically.

Now that operating system level vulnerabilities are better under control, more and more vulnerabilities are being found in the application level. Our best defence against the exploitation of these vulnerabilities is to use reactive technology such as anti-virus, anti-spyware, intrusion detection and prevention systems (IDS and IPS), firewalls, etc., but the delay these incur in detecting the attacks is unacceptable.

The problem should be well known by now: the time required to get the sample to the vendor, then through analysis and finally to distribute the detection updates to the clients, is still much longer than it takes potentially for the malware itself to spread. Although malware detection technologies typically use tunable heuristics, the problem of false positives makes it difficult to bring proactive detection to market, despite the number of startups trying to play in this field. It would be an advantage to have a more systematic and immediate way of creating these signatures and then be able to deploy them to where they are needed most as quickly as possible. The cure must spread faster than the disease, as we used to say when working on the IBM Digital Immune System.

In this article, we see how the convergence of various security technologies can help us accomplish this goal. This is achieved by utilizing the strengths of various sensors and being able to generate semantically relevant signals from them. This is a ‘blended response’ to a ‘blended threat’.

We are seeking a model for dealing with a complex and multi-level threat. Because of its powerful metaphor, the biological immune system has inspired many defence systems, not least in the field of intrusion detection and virus detection. In particular, the Self/Non-Self (SNS) detection mechanism used by the mammalian immune system is a highly compelling model.

Unfortunately, in practice, the mammalian immune system analogy – in particular SNS – has not worked particularly well when applied to computer security. The SNS model relies heavily on the ability to differentiate between self and foreign proteins and the ability to establish a memory of past infections. However, biology has many orders of magnitude more diversity and complexity than computer systems, which tend to obviate many of the problems such a system may have including the occasional false positive or false negative (which may have catastrophic effects on one individual, but not on the entire species). The false positive rate of such a system is much higher than is acceptable in the computer world.

An alternative model, called the Danger model, has been proposed by Dr Polly Matzinger (see http://www.ncbi.nlm.nih.gov/pubmed/8011301) and it departs in one significant way from classical immunology in that it does not rely on SNS to find the foreign body. Instead, it relies on danger signals from injured cells in order for the antigen-presenting cells (APC) to activate the T-cells and thereby the appropriate B-cells that eliminate the antigen. This model is not accepted in the medical community yet, and it may never be, but we don’t necessarily need the model to be validated in the medical field to find it useful in ours.

For us, the real lesson of the Danger model is that co-stimulation through a signal that identifies the threat as dangerous is required to confirm an attack. We want to combine a well-defined danger signal with some other well-defined signal, such as an SNS signal, and possibly others, before issuing an alert. The resulting composite alert will then be used to stimulate other components of the defence network.

We can also contemplate diluting this model slightly, simply by requiring two or more independent signals – so long as both signals indicate an attack – rather than strictly requiring evidence of clear and present danger in one of the signals.

Because the Danger model gives us a higher confidence level in our observation of the attack, we can now derive signatures automatically from the running system. Analogously to the cloning of the appropriate T-cells, the signatures are then spread from the originator to neighbouring systems, thus spreading the detection out from the origin.

The sensors that use these signatures can dismiss unused ones over time. This can happen, for example, because the type of sensor in question never sees that sort of traffic. Keeping old signatures around too long may degrade sensor performance or cause false positives. Collectively, however, the entire network must be able to maintain a complete set. This is close to the biological model, where fewer and fewer T-cells are available to detect a long gone threat, but always remain in minute quantities and quickly replicate if stimulated by a recurrence of that threat. This is all very nice in theory, but how could an implementation look?

It would be foolish to throw out existing technologies and all the intelligence that went into them, but some things need to change to build an approximation of this architecture.

First of all, despite the trend towards security suite products, internally these are comprised of separate components, each of which is expert at doing a certain thing well in a certain context. There are also many products that should factor into a complete malware security solution but which are perhaps not yet mainstream, such as the Firefox extension NoScript.

On my Mac, I use a personal firewall product for monitoring incoming and outgoing connections, an anti-virus product to determine if a file is infected, and a script monitor for my Firefox browser. I feel this is less than ideal, but it has worked for me so far. Of course, these products don’t talk to each other to build the bigger picture of a potential attack or even instigate countermeasures automatically.

However, using an anti-virus solution designed for detecting Windows malware on a Mac doesn’t make that much sense and may result in false positives (to its credit, the one I’m using hasn’t produced a false positive so far). The problem is that taking any tool out of the context it was designed for is just not a good idea. Trying to detect DOS/Windows malware on a Mac may incur false positives merely because there are fewer Mac files in a vendor’s false positive set or because the instruction set of the G4 processor produces unexpected code characteristics. An IDS system like SNORT may detect suspected attacks against a database where there is no database on the subnet.

On the other hand, a real instance of Windows malware on a Mac system or a database exploit on a subnet without a database, is still suspicious and needs to be reported. However, the report should indicate the futility of the attack because in our model this influences how we react to it. Furthermore, modern anti-virus products are using heuristics for malware detection, which is not the same as signature-based detection. To avoid false positives, the heuristics are tuned to be extremely conservative, but in our danger model early warning heuristics can be useful, so long as the type of detection is made explicit. The context is important.

Behaviour-based (BB) security tools, in particular in the anti-malware field, have been on the rise recently because they promise to remedy the problem of detection lag time long associated with knowledge-based (KB) tools. However, they are very different in nature and in our model we treat them as complementary to KB tools.

BB monitors are capable, at least theoretically, of producing signatures that KB scanners can consume in our danger theory model. But before they can be allowed to do that, we need to address the problem of false positives. The unfortunate fact is that BB monitors are intrinsically prone to false positives, so the goal is to reduce the number of false positives to nearly negligible levels.

In the past, attempts have been made to use event correlation on the data from intrusion detection sensors to produce a signal of higher quality through aggregation. Despite incremental improvements, no one would trust the output of correlation to be false positive free. The trouble is that inputs to these systems are not independent of each other and correlating the events cannot produce a better signal if the input signals are effectively reporting the same thing. This is where the missing context comes back to bite us.

Furthermore, the information in the signal is usually imprecise in that the event is reported using a vendor-specific code or text, and while correlation can adapt to the format of the input signal, it is much harder to attach a precise meaning to some arbitrary text or code.

What is needed is more formalism in event reporting. The output of sensors, be they IDS, AV, honeypots, etc., needs to be expressed in a way that is formally comparable to other signals. Note that there is no need for all vendors to agree on a single language, but in whatever form they decide to express their signals, the output must not only be parsable, but also comparable.

Over the last couple of years a model for expressing ideas in a comparable form has matured in the form of OWL-DL (a subset of OWL-Full), which is an ontology language for description logics. Both the event itself and its context can be captured this way, elevating what could have been a piece of data with semi-well-known characteristics to a true piece of information that can be used in a reasoning system. Once more than one signal has been found from truly and provably independent sources, the correlator can determine if there is sufficient merit to raise an alert. With greater confidence in the quality of the resulting signal, automatic response in the form of signature capture and dissemination can be achieved.

Lastly, no single vendor is capable of creating a turn-key system based on these guidelines. It is not feasible to cover all available platforms, neither is it really necessary for one vendor to do so. The key is to make the architecture open, but secure. The modes of communication must be documented and freely available for any willing vendor to participate, though the system must still be kept secure from subversion. That is certainly a tough problem but not an insurmountable one as there are various successful models one can emulate.

Now that the anti-malware industry has matured, the feeling is that it has lost sight of its mission of protecting the community. I sorely miss the big picture when looking at the offerings of the various vendors. Certainly, the start-ups with their (sometimes) new ideas can only focus on their individual solutions. The smaller vendors provide us often with very focused products, which is good, but only if they interoperate. The large vendors are the ones who talk loudest of ‘blended threats’ and ‘defence in depth’, but cannot (or in one case will not) cover enough of the IT infrastructure to deliver on their own.

It would be of great benefit to the IT community at large if a more complete solution could emerge soon, as my feeling for the last year or so is that we are finally losing the war against malware.

Morton Swimmer will present an extended version of this paper at VB2008 in Ottawa this October. VB2008 takes place 1–3 October 2008 in Ottawa, Canada. The full programme, with abstracts for each paper, as well as online registration, can be found at http://www.virusbtn.com/conference/vb2008/programme/.