December 11, 2005

IPS and Correlation

Category: Security Information Management — Raffael Marty @ 11:36 pm

Sitting in an airplane from San Francisco to New York City, I am reading through some old magazines that piled up on my desk over the past weeks. One article I cannot resist commenting on I found in the ISSA Journal from November 2005. It’s titled: “Holistic IPS: The Convergence of Intrusion Prevention Technologies”. The article talkes about an apparently new way of doing intrusion detection (or intrusion prevention). Well, to give my comment up front already, this approach is far from new. SIMs are doing some of the things mentioned and quite a few more for years! It’s one more of these cases where people could learn from other technologies, but nobody pays attention.

Let’s have a look at some flaws in the article:

  • First, a claim is made that an IPS can come up with a threat level for each attack. This is very interesting. I like it. But here are a few questions: 1. How do you define an attack? What is that? The author does not touch on that. 2. A threat-level needs to take into account how important the targeted asset is to the organization. It is first of all totally impractical for an IPS to know about the assets it protects and second, the author of the article does not mention this at all. We all know that risk = asset X vulnerability X threat. Why is this not mentioned here?
  • The author claims that an attack always starts with probing activity from the attacker. What? Have you heard of networks of scanners that are just there to scan millions of hosts for specific services and vulnerabilities? The attackers will never be the same ones that conducted the reconnaissance. So this logic is somewhat flawed. And even if there were no such scanner networks, why does an attack always have to start with pre-attack reconnaissance? That’s just not true.
  • The pre-attack reconnaissance does per the article not impart a threat. Oh really? Have you ever run a nessus scan against your network and used all the plugins? Did all of you machines survive? Mine did not. But Nessus is just a scanner. So just recon acctivity…
  • The entire idea of this new correlation engines in the IPSs is that the pre-attack recon is correlated against the real exploit traffic. The article fails to outline how the recon activity can be detected. Is it just anormal behavior? Well… I would think there are attackers that can scan your network without being too anomalous. Ever heard of application level attacks? And you claim by just analyzing the traffic, without deep inspection, you will find that scanning activity? So the claim that “… behavior-based intrusion prevention technologies will probably be most effective in detecting them [the recon activity]” is not really true. I argue that there are much better technologies to make that call.
  • What does it mean that an attack has “… a unique (and dynamic) threat level”. I thought unique would rule dynamic out? I don’t quite understand.
  • “The correlation engine proposed in this article…” Well, maybe this technique is new in the IPS world, but there are other technologies that have used this kind (and a few more) of correlation for years.
  • Differentiating probes and intrusions is not really described in the article either. I think I hit on this point already, but a probe is not necessarily detectable with just behavior based models. There are many one-packet probes that a signature-based approach can detect much more efficiently!
  • The author gives an example of how this “new” type of IPS can detect an attack. Nowhere in the entire process is there a mention of the target’s vulenrability and a correlation against it. This is just flawed. You need to know whether a target is vulnerable to determine whether the attack was successful, unless you get evidence from the target itself, be that either from audit logs on the system or network traffic that proofs a vulnerable system is present or the attack was successful.
  • Continuing on the example, I just don’t seem to understand that there have to be a probe and then an intrusion that gets correlated with the probe and then an action (e.g., blocking the source) is executed. Why not looking at the intrusion, determinig that it has a potential to be successul or was successful and then block?
  • Here is something I really like in the article: If there were probes going to multiple machines, the offender is being blocked not just from going to the one target that it was already actively trying to exploit, but also all the other machines that it probed.
  • You decide on this one: “The preventive countermeasures accurately reflect the tangible threat level…”.
  • The article fails almost completely to discuss the topic of false positives in either the detection of probes or the detection of the intrusions (I don’t like this word at all, let’s call it an exploit). Maybe there are none?
  • The argument that this approach “preludes the need for deep-packet inspection)” and that it “… improve IPS performance” by basically not having to look at all the packets due to the classification into two groups is not new. Have you ever tried to deploy an IDS behind a firewall? Same thing? Maybe not quite, but the idea is exactly the same.
  • What I am missing in this whole discussion is also passive network discovery. If so much effort is put into behavioral discovery, why is it not used to model the services and vulnerabilities that the targets are exposing? There are technologies out there that use this very well.

Am I over critical? Did I totally misunderstand what the article tries to say?


  1. Hi, first, great blog. Please don’t think I’m a big jerk here, but you hit my soapbox with a few things.

    “risk = asset X vulnerability X threat.”

    Really? I dare you (or almost anyone else) to clearly define threat, vs. risk, vs. vulnerability.

    I’ve sat in too many “executive risk meetings” where the CFO, CIO, and Security Manager of a bank or credit union just end up using all those terms interchangeably.

    “The Penetration Team found a blank SA pwd, and was able to grab the SAM file and own the network.” What’s the threat here? The Vulnerability? The Risk?

    As an example, in your post above, is Nessus a threat? You refer to it as such…

    “The pre-attack reconnaissance does per the article not impart a threat. Oh really? Have you ever run a nessus scan against your network and used all the plugins? Did all of you machines survive? Mine did not. But Nessus is just a scanner. So just recon acctivity…”

    I did find this one to be a gem:

    “# You decide on this one: “The preventive countermeasures accurately reflect the tangible threat level…”.”

    Well, it’s good that it reflects the tangible threat level, but what about that pesky intangible threat level?

    Love the blog.

    Comment by Alex Hutton — December 17, 2005 @ 9:55 am

  2. Thanks for your comments… I agree with you on all levels. I have not done a good job of defining what the different factors of the formula are. I was just trying to make the point that the person writing the article, did not either. I was only trying to throw out some ideas for thought.
    The second comment about the “tangible threat level” is just strange. Why would one call a threat level tangible? What is that? So you hit it on the spot. Again, the part in quotes is from the article, I was just pointing it out to be something that did not make sense to me.

    Keep the comments coming …

    Comment by Raffy — December 17, 2005 @ 5:22 pm

  3. The article critically looks at application of statistical techniques one like correlation of variables. Here, the relation between system and security can be studied using statistical methods one like correlation.

    You can sit back and monitor the variability in vulunerablity in your system and security once the method is applied carefully and accurately.

    Comment by John — January 17, 2007 @ 1:41 am

RSS feed for comments on this post. | TrackBack URI

Leave a comment

XHTML ( You can use these tags): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> .