Cooperating Detectors

By -
A malware detector tries to determine whether a program is malicious (examples
of malicious programs are drive-by-downloads, botnets, and keyloggers).
Malware detection is primarily performed at two vantage points: host and
network. This post explains why cooperation between host-based and network-
based detectors is a good thing.

Traditionally, detection has been performed either at the network or host level, but
not both. First, let me examine both approaches separately.

A network-based detector monitors events by examining a session or
network flow and tries to determine whether it is malicious. The
advantage of a network-based detector is ease of deployment -- there
are not that many points of deployment for a network-based detector
(typically they are deployed behind border routers).

Unfortunately, network-based detectors have a limited view of each
network session. In fact, if a session happens to be
encrypted such as is common with VPNs, Skype, and some bots, a
network-based detector is essentially blind. For example, a botmaster
can hide its communication with the bots by simply encrypting the session.

By contrast, host-based detectors have a more comprehensive view of system activities, i.e.,
they have the potential to observe every event at the host, including malicious ones. However, the major drawback of a host-based detector is that it has to be widely deployed. Typically in a managed
network (such as in an enterprise), a host-based detector has to be deployed at
every host.


Cooperation between host-based and network-based detectors can potentially
address the shortcomings of each detector. I've come up with three possible scenarios.

1) Host-based detector helping the network-based detector.
A network-based detector can pull alerts from a host-based
detector and a host-based detector can push alerts to a network-based
detector. This is a simple solution and I suspect the easiest
scenario for cooperation.

2) Queue up suspicious activity on a virtual machine.
If a network-based detector determines that a session is
"suspicious," it can divert the suspicious traffic to a virtual machine
with a host-based detector for more in-depth analysis. The trick here
is figuring out what events are indeed "suspicious" (you do not want
too much traffic to go through the "slow path" corresponding to a
host-based detector). There is already a
startup called Fireeye adapting this solution. I find this line of work quite intriguing.

3) Pushing signatures.
This third scenario has been explored quite thoroughly in academic
literature. It involves the cooperation of host-based and network-based detectors to
push signatures for malware in real-time. For example, if a host-
based detector recognizes an attack, it pushes out a signature to a
network-based detector. The advantage of this
approach is that, by updating a network-based detector, an entire
enterprise can be protected against that particular threat. However, in my
view this is not a good approach in the long run. Hackers are creating malware variants at
an alarming rate and signatures won't be able to keep up.

Comments

Post a Comment

Popular posts from this blog

Malware Trend in 2007

By -
I read the report IBM Internet Security System X-Force 2007 Trend Statistics. This is a report describing trends for various threats in 2007. This team has been tracking trends since 2000. I found the report to be quite interesting. In the rest of this post, I highlight some of the interesting points from the report and what they mean in the context of malware detection. (I) The X-Force team reports continued growth in Web browser exploitation. This clearly shows that the infection vector is changing to the Web. Earlier the primary infection vectors were email and the network. Therefore, for detecting malware, drive-by-downloads (DBD) and other threats targeted at hacking through the Web browser need a lot of attention. (II) X-Force also reports a marked increase in obfuscated exploits, i.e., exploits that use various code obfuscation techiques (such as encryption). Here is a quote, "X-Force estimated that nearly 80 percent of Web exploits used obfuscation and/or self decryption ....
Read more

Web Attacks

By -
This blog post was contributed by Vaibhav Rastogi. The web is one of the most common interfaces between an organization and the outside world and so web attacks, or attacks on web applications, are a fairly frequent attack scenario. They have been studied for decades, projects such as OWASP Top Ten  have been there to create awareness about these attacks, and there are numerous tools, which can be used to detect and mitigate common web application vulnerabilities. Here, we outline some of the common categories of attacks on web applications. Injection attacks Such attacks happen when untrusted data is incorporated into the server-side application logic without proper sanitization. These attacks can use a variety of vectors: for example, unsanitized input can make its way into a SQL query to result in a so-called SQL injection. Similar attacks can result with injection into noSQL database queries, and into server-side scripts (e.g., a PHP script that evaluates some untrusted...
Read more

Model Checking and Security

By -
Model checking is a technique of verifying temporal properties of finite-state systems. One of the attractive features of model checking over other techniques (such as theorem proving) is that if a property is not true, a model checker provides a counter-example which explains why the property is not true. Inventors of model checking, Edmund Clarke, Allen Emerson, and Joseph Sifakis, won the 2008 ACM Turing award (see the announcement here ). I have a personal connection to two of the recipients. Edmund Clarke was my adviser at Carnegie Mellon, and Allen Emerson and I have collaborated on few projects and he has supported me through out my career. In this note I try to summarize various applications of model checking to security. Protocol verification : Protocols in the realm of security (henceforth referred to as security protocols) are very tricky to get correct. For example, flaws in authentication protocols have been discovered several years after they have been published. Techniqu...
Read more