Thanks for the note & the comments. I am also not ecstatic that the
sidebar on "what is Target-based IDS" was omitted from the printed
version. I asked the editor, and he said that they will be running it
in an on-line form later with some tie-in to the topic.
I agree 100% with what you said and even tried to get that documentation
in! For the benefit of the readers of this list, I'll include my
sidebars as well, which restate what you've said and include the
comments from Ron Gula and Robert Graham who participated in the discussion.
I know that the editors of Information Security follow this list, but
I'll also cc: them with your note & mine to understand the issues and
your concerns. One of the problems with the magazine world is that
space is at a very tight premium and in order to include all of the
product comparison, some of the background information is omitted. This
is not because we think that the readers cannot handle it, but because
there is only so much room for text on a page. If push comes to shove,
the "new information" (i.e., the results of our testing) will generally
shove out "background information" (i.e., things which people can learn
about via other avenues).
Thanks for the feedback, and thanks for all the help during the review!!!
jms
------
What is Target-based Intrusion Detection?
As a new term, ?target-based IDS? may not mean the same thing to all
vendors. However, Marty Roesch, an IDS researcher and one of the
authors of Snort, defines target-based IDS as having three components.
The idea behind target-based IDS is to bring additional information
about the systems being probed, attacked or abused to the IDS. First,
and easiest to understand, is prioritization of IDS alerts using
information about the systems. Roesch?s company, Sourcefire, is working
on a target-based IDS product but has not yet released their full
implementation.
?Raw intelligence? is how IDS author Ron Gula, of Tenable Security,
describes alerts as they pop out of IDS consoles. They represent
information, but they don?t necessarily have much value. To turn them
into ?well-qualified intelligence?---the kind a President uses to
justify a war---requires an analyst. The problem is that analysts are
expensive and slow. Automating the process of qualifying alerts is what
target-based intrusion detection is all about. Give a computer rules
for promoting and demoting alerts and you can turn 130,000 events (the
average daily number we saw in our testing) into a half-dozen that
really need looking at.
Roesch names two other components as integral to target based NIDS: host
context and network context. By giving the NIDS more information about
the network it is sitting on and the hosts it is protecting, the NIDS
sensors themselves can be more accurate and reduce the irrelevant alerts
before they reach the console.
Many commercial IDS vendors have incorporated parts of Roesch?s
framework into their products, although generally in a very limited way.
For example, NFR Security chose not to participate in this article,
but did say that they are beginning to include some operating-system
detection code in their sensors which they think will help to reduce the
total level of noise in their products.
The most activity in the NIDS market, though, is in the first aspect of
target-based IDS: post-processing of alerts to assess their impact and
the likely threat. In this article, we focus on NIDS consoles which
filter and qualify alerts. This aspect of target-based IDS combines a
normal IDS engine with post-processing tools to convert alerts from
?raw? to ?well-qualified.? All three products we tested worked in a
very similar manner. Alerts flow into the console from the NIDS engine
in all their verbose glory. However, before the console displays the
alerts to the security analyst, they are promoted, demoted, or otherwise
qualified to help separate them into two piles: vulnerable, and not
vulnerable.
Target-based IDS does promotion or demotion using vulnerability
information. It?s not a complicated thing to know what TCP and UDP
ports is a system listening on, what applications are running on those
ports; what versions of the applications are running, and what patches
are applied. The thinking which goes along with this is also simple: an
attack on a system that cannot succeed should be demoted. An attack
against a vulnerable system, or (even worse) a successful attack, should
be promoted.
It?s important to understand that the world of NIDS moves very slowly
with very small steps. Target-based IDS in today?s products only does
one thing: determine whether or not a system is vulnerable to an attack
identified in a particular signature. Where NIDS is being used to alert
on attacks against vulnerable systems, this can reduce an impossibly
large pile of alerts to a very reasonable action list. Where NIDS is
used for other reasons, such as policy enforcement or monitoring the
general level of background radiation, target-based technology doesn?t
help.
How Did We Get Here?
Most commercial network intrusion detection systems depend on attack
signatures to identify malicious or out-of-policy activity. The one
exception is Lancope?s StealthWatch, which is a statistical intrusion
detection system based on an entirely different design, looking for
deviations in traffic volume and pattern. Signature-based NIDS is a
very CPU-intensive technology. Before comparing packets against the
NIDS database of a thousand or more signatures, the sensors also have to
perform a variety of compute-intensive operations such as HTTP
normalization, converting URLs in HTTP data streams to a canonical
format so that they can be compared against a list of known bad traffic.
To keep from losing packets, NIDS signature writers generally only
match against the minimum amount of data needed to validate an attack.
Until now, the thinking has been that it is better to catch both
suspicious and harmless activity than it is to miss something by being
too strict on the signature.
Once you start down this path, IDS engineers start to get very picky
about terminology. The term ?false positive? is reserved for places
where the IDS actually made an error---where the IDS claimed that an
attack attempt occurred, but no such attack really happened.
An example from Snort, the popular open-source IDS, is useful. In
Snort?s signature database, an exploit for the Sendmail SMTP MTA version
8.6.10 is trapped by a signature looking for a particularly strange
string: ?Croot? followed by 7 tabs, followed by ?|Mprog,P=/bin?. This
is meant to appear at the start of an SMTP dialog, but the way the
signature is written, Snort will complain anywhere it appears in the
message. This signature shows the balance between performance and
coverage. Because the string is very unlikely to appear in an email
message, it?s unlikely to be a true false positive. However, if you
send an email through a mail server protected by Snort with that string
in it, bells will ring and sirens will sound. Unless you were actually
attacking Sendmail, you would have a true false positive.
False positives, though, are not the same as ?noise:? false alarms,
false alerts, glare, or what some are calling ?noncontextuals? or
?nontextuals,? positive detection of attacks which are contextually
irrelevant. The same example can help us understand IDS noise. The
example signature is for an attack against a specific SMTP MTA at a
specific version. If you run the proper attack tool at the proper time
against any SMTP MTA, the IDS will generate an alert. But if the attack
is against some other MTA, or the wrong version of Sendmail, the alert
is a false one, pure noise---no compromise is possible. Since the NIDS
sees all traffic, it would be possible for the signature to be expanded
so that it only triggers if it sees the Sendmail banner earlier on in
the message. Or, perhaps even only the Sendmail banner with a
vulnerable version. But Snort signatures aren?t written that way, and
neither are other IDSes. Performance is the reason: start looking at
traffic at that level of detail, and you run out of CPU speed very quickly.
Some IDS vendors are working on making their signature and detection
engines smarter, but others are taking a different path: target-based
IDS. The area is still a new one and the products are not entirely
fully baked, but the idea is simple. Take additional information about
systems and use it to alter the alarming and alerting functions of the
IDS console. Change the signal-to-noise ratio to increase the signal,
and decrease the noise. Using our example, you?d still get an alert for
the Sendmail attack. But if the attack were simply noise, the alert
would be given a low priority; if it were against a vulnerable server,
the alert would get a high priority.
Security managers interested in the background radiation level of the
Internet can spend all day looking at low priority alerts. Those
looking specifically for threats which need immediate remediation can
turn their attention to the short-list of high priority alerts. At
least that?s the theory. And that?s where our story begins.
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX)
jms (at) Opus1 (dot) COM [email concealed] http://www.opus1.com/jms Opus One
Thanks for the note & the comments. I am also not ecstatic that the
sidebar on "what is Target-based IDS" was omitted from the printed
version. I asked the editor, and he said that they will be running it
in an on-line form later with some tie-in to the topic.
I agree 100% with what you said and even tried to get that documentation
in! For the benefit of the readers of this list, I'll include my
sidebars as well, which restate what you've said and include the
comments from Ron Gula and Robert Graham who participated in the discussion.
I know that the editors of Information Security follow this list, but
I'll also cc: them with your note & mine to understand the issues and
your concerns. One of the problems with the magazine world is that
space is at a very tight premium and in order to include all of the
product comparison, some of the background information is omitted. This
is not because we think that the readers cannot handle it, but because
there is only so much room for text on a page. If push comes to shove,
the "new information" (i.e., the results of our testing) will generally
shove out "background information" (i.e., things which people can learn
about via other avenues).
Thanks for the feedback, and thanks for all the help during the review!!!
jms
------
What is Target-based Intrusion Detection?
As a new term, ?target-based IDS? may not mean the same thing to all
vendors. However, Marty Roesch, an IDS researcher and one of the
authors of Snort, defines target-based IDS as having three components.
The idea behind target-based IDS is to bring additional information
about the systems being probed, attacked or abused to the IDS. First,
and easiest to understand, is prioritization of IDS alerts using
information about the systems. Roesch?s company, Sourcefire, is working
on a target-based IDS product but has not yet released their full
implementation.
?Raw intelligence? is how IDS author Ron Gula, of Tenable Security,
describes alerts as they pop out of IDS consoles. They represent
information, but they don?t necessarily have much value. To turn them
into ?well-qualified intelligence?---the kind a President uses to
justify a war---requires an analyst. The problem is that analysts are
expensive and slow. Automating the process of qualifying alerts is what
target-based intrusion detection is all about. Give a computer rules
for promoting and demoting alerts and you can turn 130,000 events (the
average daily number we saw in our testing) into a half-dozen that
really need looking at.
Roesch names two other components as integral to target based NIDS: host
context and network context. By giving the NIDS more information about
the network it is sitting on and the hosts it is protecting, the NIDS
sensors themselves can be more accurate and reduce the irrelevant alerts
before they reach the console.
Many commercial IDS vendors have incorporated parts of Roesch?s
framework into their products, although generally in a very limited way.
For example, NFR Security chose not to participate in this article,
but did say that they are beginning to include some operating-system
detection code in their sensors which they think will help to reduce the
total level of noise in their products.
The most activity in the NIDS market, though, is in the first aspect of
target-based IDS: post-processing of alerts to assess their impact and
the likely threat. In this article, we focus on NIDS consoles which
filter and qualify alerts. This aspect of target-based IDS combines a
normal IDS engine with post-processing tools to convert alerts from
?raw? to ?well-qualified.? All three products we tested worked in a
very similar manner. Alerts flow into the console from the NIDS engine
in all their verbose glory. However, before the console displays the
alerts to the security analyst, they are promoted, demoted, or otherwise
qualified to help separate them into two piles: vulnerable, and not
vulnerable.
Target-based IDS does promotion or demotion using vulnerability
information. It?s not a complicated thing to know what TCP and UDP
ports is a system listening on, what applications are running on those
ports; what versions of the applications are running, and what patches
are applied. The thinking which goes along with this is also simple: an
attack on a system that cannot succeed should be demoted. An attack
against a vulnerable system, or (even worse) a successful attack, should
be promoted.
It?s important to understand that the world of NIDS moves very slowly
with very small steps. Target-based IDS in today?s products only does
one thing: determine whether or not a system is vulnerable to an attack
identified in a particular signature. Where NIDS is being used to alert
on attacks against vulnerable systems, this can reduce an impossibly
large pile of alerts to a very reasonable action list. Where NIDS is
used for other reasons, such as policy enforcement or monitoring the
general level of background radiation, target-based technology doesn?t
help.
How Did We Get Here?
Most commercial network intrusion detection systems depend on attack
signatures to identify malicious or out-of-policy activity. The one
exception is Lancope?s StealthWatch, which is a statistical intrusion
detection system based on an entirely different design, looking for
deviations in traffic volume and pattern. Signature-based NIDS is a
very CPU-intensive technology. Before comparing packets against the
NIDS database of a thousand or more signatures, the sensors also have to
perform a variety of compute-intensive operations such as HTTP
normalization, converting URLs in HTTP data streams to a canonical
format so that they can be compared against a list of known bad traffic.
To keep from losing packets, NIDS signature writers generally only
match against the minimum amount of data needed to validate an attack.
Until now, the thinking has been that it is better to catch both
suspicious and harmless activity than it is to miss something by being
too strict on the signature.
Once you start down this path, IDS engineers start to get very picky
about terminology. The term ?false positive? is reserved for places
where the IDS actually made an error---where the IDS claimed that an
attack attempt occurred, but no such attack really happened.
An example from Snort, the popular open-source IDS, is useful. In
Snort?s signature database, an exploit for the Sendmail SMTP MTA version
8.6.10 is trapped by a signature looking for a particularly strange
string: ?Croot? followed by 7 tabs, followed by ?|Mprog,P=/bin?. This
is meant to appear at the start of an SMTP dialog, but the way the
signature is written, Snort will complain anywhere it appears in the
message. This signature shows the balance between performance and
coverage. Because the string is very unlikely to appear in an email
message, it?s unlikely to be a true false positive. However, if you
send an email through a mail server protected by Snort with that string
in it, bells will ring and sirens will sound. Unless you were actually
attacking Sendmail, you would have a true false positive.
False positives, though, are not the same as ?noise:? false alarms,
false alerts, glare, or what some are calling ?noncontextuals? or
?nontextuals,? positive detection of attacks which are contextually
irrelevant. The same example can help us understand IDS noise. The
example signature is for an attack against a specific SMTP MTA at a
specific version. If you run the proper attack tool at the proper time
against any SMTP MTA, the IDS will generate an alert. But if the attack
is against some other MTA, or the wrong version of Sendmail, the alert
is a false one, pure noise---no compromise is possible. Since the NIDS
sees all traffic, it would be possible for the signature to be expanded
so that it only triggers if it sees the Sendmail banner earlier on in
the message. Or, perhaps even only the Sendmail banner with a
vulnerable version. But Snort signatures aren?t written that way, and
neither are other IDSes. Performance is the reason: start looking at
traffic at that level of detail, and you run out of CPU speed very quickly.
Some IDS vendors are working on making their signature and detection
engines smarter, but others are taking a different path: target-based
IDS. The area is still a new one and the products are not entirely
fully baked, but the idea is simple. Take additional information about
systems and use it to alter the alarming and alerting functions of the
IDS console. Change the signal-to-noise ratio to increase the signal,
and decrease the noise. Using our example, you?d still get an alert for
the Sendmail attack. But if the attack were simply noise, the alert
would be given a low priority; if it were against a vulnerable server,
the alert would get a high priority.
Security managers interested in the background radiation level of the
Internet can spend all day looking at low priority alerts. Those
looking specifically for threats which need immediate remediation can
turn their attention to the short-list of high priority alerts. At
least that?s the theory. And that?s where our story begins.
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX)
jms (at) Opus1 (dot) COM [email concealed] http://www.opus1.com/jms Opus One
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
[ reply ]