On Jan 9, 2004, at 4:11 PM, Andy Cuff [Talisker] wrote:
> Hi Marty
> I've seen the term "target IDS" used for a variety of differing IDS
> solutions, well three to be exact; file integrity checkers, Network
> Node IDS
> and the event contextualization (cool word) that you are speaking of.
> IMHO
> your use of the term is the most fitting.
Thanks. :)
> I'm sure I first came across the
> term in Rebecca Bace's book on IDS published in '99. However I have
> loaned
> it to someone and therefore cannot confirm this. The term is quite
> sexy from
> a marketing sense and therefore open to misuse, a bit like Hybrid IDS
> which
> thankfully seems to have died a death.
Could be, I never noticed it there. I remember the moment I blurted it
forth distinctly, I was in San Francisco by the Embarcadero Center with
the Hiverworld crew (some of which are still on this list) talking
about using scanners to try to preload the data into the NIDS and I
said "it'd be like a target-based IDS or something". :) I'm certainly
not claiming a monopoly over the term, but in the context of this
discussion I believe the term as I defined it is appropriate.
> Whilst I can see the efficiency in what you are saying regarding the
> sensor
> itself understanding the network (NFR and Sourcefire), conducting the
> TIDS
> role at the system that combines the IDS information with the
> vulnerability
> and fingerprinting data (Tenable and ISS) surely provides the analyst
> with
> the same information on the screen at the end of the day, furthermore
> historical raw data will still be in the database regardless of the
> targeting transformation.
This kind of ignores the false negative case and the signal/noise
ratio, if you don't detect squat because the bad guy evaded you then
having the fanciest backend correlator/contextualizer isn't going to be
worth anything.
Improving the quality of the data is what this exercise is all about,
if the data coming out of the sensor is a bunch of junk and you miss
all the true attacks (which is possible in the Ptacek & Newsham
scenarios) then you haven't bought yourself anything. It's not about
efficiency at all, it's about whether your sensor is capable of doing
its basic job. A TIDS (as opposed to a target-based sensor) needs to
have all three of the components I outlined, but if you don't bother to
do the sensor then you've got a net gain of data reduction on
questionable data.
-Marty
>
> take care
> -andy
> PS if whoever I lent the IDS book to, could return it, I'd really
> appreciate
> it ;o) AND if you're the person I borrowed it from, I'll get it back
> to you
> ASAP.
> Talisker Security Tools Directory
> http://www.securitywizardry.com
> ----- Original Message -----
> From: "Martin Roesch" <roesch (at) sourcefire (dot) com [email concealed]>
> To: "Joel Snyder" <Joel.Snyder (at) Opus1 (dot) COM [email concealed]>
> Cc: <focus-ids (at) securityfocus (dot) com [email concealed]>
> Sent: Friday, January 09, 2004 6:48 PM
> Subject: Re: Target based IDS review and discussion in Information
> Security
>
>
>> Just read the article and I have a few comments.
>>
>> First, I find it troubling that the history and full meaning of the
>> term
>> "target-based IDS" (which I coined in 2000) was omitted. That this
>> article didn't review any fully target-based IDS products will almost
>> certainly leave readers with a misunderstanding of what target-based
>> IDS
>> really is.
>>
>> Target-based IDS has two components, a correlation mechanism *and* a
>> target-based IDS sensor, this article only reviews the former.
>>
>> Second, while I recall that you were concerned that the full concept
>> was too
>> complex for people (i.e. Information Security Magazine's readers) to
>> understand, I believe that shielding them from the entire concept is a
>> disservice.
>>
>> For the benefit of the readers in this forum, I'll repeat myself from
>> our
>> exchange in November:
>>
>> "Additionally, since I came up with the term "Target-based IDS" I'd
>> like to define the components of a true TIDS. TIDS is *not*
>> event->vuln correlation, that's event contextualization (or impact
>> assessment). We perform event contextualization so that we can reduce
>> the number of events generated by a NIDS to a manageable amount, but
>> it's only one leg of a full blown TIDS solution.
>>
>> There are three classes of problems in IDS that require us to
>> transition to TIDS:
>> 1) Lack of impact assessment/prioritization
>> 2) Lack of host context (OS identification, service detection)
>> 3) Lack of network context (topology discovery)
>>
>> Problem one stops us from getting use of the data generated by IDSes.
>> The entire value of IDS is in its output, if we can't reduce that
>> output to information that's useful to us as administrators then the
>> usefulness of entire system is limited. Tenable and ISS [mfr: and
>> Cisco] both have solutions to solve problem 1 and Sourcefire is
>> working
>> on one (RNA).
>>
>> Problems 2 and 3 are what Ptacek and Newsham were talking about. If
>> an
>> attacker can know more about the targets he's attacking than the IDS,
>> he can use that knowledge to get around the IDS. If you're going to
>> defeat that then you need to drive the host and network context into
>> the IDS process itself, post-processing won't buy you anything if the
>> IDS sensor isn't as accurate as possible. This is the *heart* of
>> TIDS,
>> you can't have a TIDS if you don't incorporate host/network context
>> directly into the IDS process itself, the accuracy of the system will
>> always be suspect and the 1st part of the triad will not be as useful
>> as it should be."
>>
>> There are two vendors who are working on target-based IDS sensors that
>> I know of, Sourcefire (my company) and NFR (which is shipping a
>> passive
>> fingerprinter with their latest release). I think you probably should
>> have mentioned this in the article, as well as listed the vendors who
>> are working on full target-based IDS implementations (only Sourcefire
>> AFAIK but it wouldn't surprise me if NFR and others were headed this
>> way).
>>
>> -Marty
>>
>> On Jan 7, 2004, at 4:25 PM, Joel Snyder wrote:
>>
>>> There has been a lot of discussion on this list about target-based
>>> IDS
>>> in the last few months. A review of three products I wrote for
>>> Information Security has just popped up and is available on the
>>> magazine's web site. The URL is:
>>>
>>> http://infosecuritymag.techtarget.com/ss/
>>> 0,295796,sid6_iss306_art540,00.html
>>>
>>> Informed commentary and feedback is always welcome.
>>>
>>> jms
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> --
>>> ----
>>> ---------------------------------------------------------------------
>>> --
>>> ----
>>>
>>>
>> --
>> Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
>> Sourcefire: Snort-based Enterprise Intrusion Detection Infrastructure
>> roesch (at) sourcefire (dot) com [email concealed] - http://www.sourcefire.com
>> Snort: Open Source Network IDS - http://www.snort.org
>>
>>
>> ----------------------------------------------------------------------
>> ----
> -
>> ----------------------------------------------------------------------
>> ----
> -
>>
>
>
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Snort-based Enterprise Intrusion Detection Infrastructure
roesch (at) sourcefire (dot) com [email concealed] - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
On Jan 9, 2004, at 4:11 PM, Andy Cuff [Talisker] wrote:
> Hi Marty
> I've seen the term "target IDS" used for a variety of differing IDS
> solutions, well three to be exact; file integrity checkers, Network
> Node IDS
> and the event contextualization (cool word) that you are speaking of.
> IMHO
> your use of the term is the most fitting.
Thanks. :)
> I'm sure I first came across the
> term in Rebecca Bace's book on IDS published in '99. However I have
> loaned
> it to someone and therefore cannot confirm this. The term is quite
> sexy from
> a marketing sense and therefore open to misuse, a bit like Hybrid IDS
> which
> thankfully seems to have died a death.
Could be, I never noticed it there. I remember the moment I blurted it
forth distinctly, I was in San Francisco by the Embarcadero Center with
the Hiverworld crew (some of which are still on this list) talking
about using scanners to try to preload the data into the NIDS and I
said "it'd be like a target-based IDS or something". :) I'm certainly
not claiming a monopoly over the term, but in the context of this
discussion I believe the term as I defined it is appropriate.
> Whilst I can see the efficiency in what you are saying regarding the
> sensor
> itself understanding the network (NFR and Sourcefire), conducting the
> TIDS
> role at the system that combines the IDS information with the
> vulnerability
> and fingerprinting data (Tenable and ISS) surely provides the analyst
> with
> the same information on the screen at the end of the day, furthermore
> historical raw data will still be in the database regardless of the
> targeting transformation.
This kind of ignores the false negative case and the signal/noise
ratio, if you don't detect squat because the bad guy evaded you then
having the fanciest backend correlator/contextualizer isn't going to be
worth anything.
Improving the quality of the data is what this exercise is all about,
if the data coming out of the sensor is a bunch of junk and you miss
all the true attacks (which is possible in the Ptacek & Newsham
scenarios) then you haven't bought yourself anything. It's not about
efficiency at all, it's about whether your sensor is capable of doing
its basic job. A TIDS (as opposed to a target-based sensor) needs to
have all three of the components I outlined, but if you don't bother to
do the sensor then you've got a net gain of data reduction on
questionable data.
-Marty
>
> take care
> -andy
> PS if whoever I lent the IDS book to, could return it, I'd really
> appreciate
> it ;o) AND if you're the person I borrowed it from, I'll get it back
> to you
> ASAP.
> Talisker Security Tools Directory
> http://www.securitywizardry.com
> ----- Original Message -----
> From: "Martin Roesch" <roesch (at) sourcefire (dot) com [email concealed]>
> To: "Joel Snyder" <Joel.Snyder (at) Opus1 (dot) COM [email concealed]>
> Cc: <focus-ids (at) securityfocus (dot) com [email concealed]>
> Sent: Friday, January 09, 2004 6:48 PM
> Subject: Re: Target based IDS review and discussion in Information
> Security
>
>
>> Just read the article and I have a few comments.
>>
>> First, I find it troubling that the history and full meaning of the
>> term
>> "target-based IDS" (which I coined in 2000) was omitted. That this
>> article didn't review any fully target-based IDS products will almost
>> certainly leave readers with a misunderstanding of what target-based
>> IDS
>> really is.
>>
>> Target-based IDS has two components, a correlation mechanism *and* a
>> target-based IDS sensor, this article only reviews the former.
>>
>> Second, while I recall that you were concerned that the full concept
>> was too
>> complex for people (i.e. Information Security Magazine's readers) to
>> understand, I believe that shielding them from the entire concept is a
>> disservice.
>>
>> For the benefit of the readers in this forum, I'll repeat myself from
>> our
>> exchange in November:
>>
>> "Additionally, since I came up with the term "Target-based IDS" I'd
>> like to define the components of a true TIDS. TIDS is *not*
>> event->vuln correlation, that's event contextualization (or impact
>> assessment). We perform event contextualization so that we can reduce
>> the number of events generated by a NIDS to a manageable amount, but
>> it's only one leg of a full blown TIDS solution.
>>
>> There are three classes of problems in IDS that require us to
>> transition to TIDS:
>> 1) Lack of impact assessment/prioritization
>> 2) Lack of host context (OS identification, service detection)
>> 3) Lack of network context (topology discovery)
>>
>> Problem one stops us from getting use of the data generated by IDSes.
>> The entire value of IDS is in its output, if we can't reduce that
>> output to information that's useful to us as administrators then the
>> usefulness of entire system is limited. Tenable and ISS [mfr: and
>> Cisco] both have solutions to solve problem 1 and Sourcefire is
>> working
>> on one (RNA).
>>
>> Problems 2 and 3 are what Ptacek and Newsham were talking about. If
>> an
>> attacker can know more about the targets he's attacking than the IDS,
>> he can use that knowledge to get around the IDS. If you're going to
>> defeat that then you need to drive the host and network context into
>> the IDS process itself, post-processing won't buy you anything if the
>> IDS sensor isn't as accurate as possible. This is the *heart* of
>> TIDS,
>> you can't have a TIDS if you don't incorporate host/network context
>> directly into the IDS process itself, the accuracy of the system will
>> always be suspect and the 1st part of the triad will not be as useful
>> as it should be."
>>
>> There are two vendors who are working on target-based IDS sensors that
>> I know of, Sourcefire (my company) and NFR (which is shipping a
>> passive
>> fingerprinter with their latest release). I think you probably should
>> have mentioned this in the article, as well as listed the vendors who
>> are working on full target-based IDS implementations (only Sourcefire
>> AFAIK but it wouldn't surprise me if NFR and others were headed this
>> way).
>>
>> -Marty
>>
>> On Jan 7, 2004, at 4:25 PM, Joel Snyder wrote:
>>
>>> There has been a lot of discussion on this list about target-based
>>> IDS
>>> in the last few months. A review of three products I wrote for
>>> Information Security has just popped up and is available on the
>>> magazine's web site. The URL is:
>>>
>>> http://infosecuritymag.techtarget.com/ss/
>>> 0,295796,sid6_iss306_art540,00.html
>>>
>>> Informed commentary and feedback is always welcome.
>>>
>>> jms
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> --
>>> ----
>>> ---------------------------------------------------------------------
>>> --
>>> ----
>>>
>>>
>> --
>> Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
>> Sourcefire: Snort-based Enterprise Intrusion Detection Infrastructure
>> roesch (at) sourcefire (dot) com [email concealed] - http://www.sourcefire.com
>> Snort: Open Source Network IDS - http://www.snort.org
>>
>>
>> ----------------------------------------------------------------------
>> ----
> -
>> ----------------------------------------------------------------------
>> ----
> -
>>
>
>
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Snort-based Enterprise Intrusion Detection Infrastructure
roesch (at) sourcefire (dot) com [email concealed] - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
[ reply ]