Very quickly, I'll touch on a couple things. I really don't want to
turn this into a big thread if at all possible.
On Jan 9, 2004, at 5:21 PM, Craig H. Rowland wrote:
[snip]
> For example:
>
> 1) A URL attack is seen by the sensor affecting Windows IIS.
> 2) A check is made if the attacked OS is Windows.
> 3) A *low-impact* external assessment is made if available.
> 4) If Windows, then log onto the host and check for relevant hotfixes,
> patches, etc. for the vulnerability.
> 5) If the system is not patched, retrieve the log files and search for
> successful signs of the attack.
> 6) If the attack traces are found in the log, then escalate the alert.
> 7) Administrator can view the chronological event log we generated of
> each and every step we took to investigate the attack (from IDS
> detection to final resolution and reason why we upgraded/downgraded).
> 8) Administrator can view the actual log files retrieved from the
> impacted host to manually verify if the attack was successful or not.
>
> (The above process happens in a very fast and automated fashion.)
>
[snip]
> So in the definition of target IDS generally given you'd be able to
> only
> accomplish steps 1-3 reliably (step 3 may not be low-impact) and
> perhaps
> step 4 patch checks with certain Windows probes. However steps 5-8 are
> totally out of the question. That's why we don't follow the traditional
> targeted IDS philosophy. I think admins want more concrete data about
> security incidents on their network and deeper automated investigations
> are required to handle this task.
The problem is that if you don't do prediscovery you can't trust the
information you get back after the attack. Once the host is
compromised you can't believe anything it tells you IMHO.
> I think you miss quite a bit of data just watching the wire and not
> connecting to the host and see what is going on directly from within.
How about in the case of welchia? The host gets popped and the vuln is
patched in one shot, step 3 fails and the system is none the wiser. In
the event of a successful overflow or other admin/root granting remote
attacks, the configuration of the host after the attack may be nothing
like what's required to elevate your level of suspicion.
> Targeting IDS data is a good idea and has its uses, but many admins
> don't know what to do with the event even after it's been escalated.
Making the sensor smarter is an end unto itself for the sake of
improving the raw accuracy of the IDS process, providing
contextualization on the back end is also desirable. Training is a
problem that never goes away, luckily there are a lot of good training
orgs these days that can help.
> This is why we are focusing on automated attack investigation and
> response. Doing straight targeted IDS doesn't always provide the
> answers
> people want and isn't capable of directly collecting forensic
> information from the affected host for automated or manual
> investigations.
Automated forensics are useful and a nice step forward but if the
attacker evades the IDS or disables the forensics systems once he's on
the host then you've got a problem. The methodology described also
reveals a lot of information about the security posture of the site
that's being hit (i.e. Cisco CTR is in use) and what countermeasures
are appropriate to reduce the chances of being detected in the future.
In the worst case it could also be used to suggest what the
configuration of the IDS is...
> So perhaps the definition of targeted IDS should expand
> to include actual on-host investigation techniques, or we can create a
> new buzzword to encompass what it is that CTR actually does above
> straight targeted-IDS.
Automated network forensics? I think TIDS has a concise definition
right now, I'm not in favor of extending it.
-Marty
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Intelligent Security Monitoring
roesch (at) sourcefire (dot) com [email concealed] - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
Very quickly, I'll touch on a couple things. I really don't want to
turn this into a big thread if at all possible.
On Jan 9, 2004, at 5:21 PM, Craig H. Rowland wrote:
[snip]
> For example:
>
> 1) A URL attack is seen by the sensor affecting Windows IIS.
> 2) A check is made if the attacked OS is Windows.
> 3) A *low-impact* external assessment is made if available.
> 4) If Windows, then log onto the host and check for relevant hotfixes,
> patches, etc. for the vulnerability.
> 5) If the system is not patched, retrieve the log files and search for
> successful signs of the attack.
> 6) If the attack traces are found in the log, then escalate the alert.
> 7) Administrator can view the chronological event log we generated of
> each and every step we took to investigate the attack (from IDS
> detection to final resolution and reason why we upgraded/downgraded).
> 8) Administrator can view the actual log files retrieved from the
> impacted host to manually verify if the attack was successful or not.
>
> (The above process happens in a very fast and automated fashion.)
>
[snip]
> So in the definition of target IDS generally given you'd be able to
> only
> accomplish steps 1-3 reliably (step 3 may not be low-impact) and
> perhaps
> step 4 patch checks with certain Windows probes. However steps 5-8 are
> totally out of the question. That's why we don't follow the traditional
> targeted IDS philosophy. I think admins want more concrete data about
> security incidents on their network and deeper automated investigations
> are required to handle this task.
The problem is that if you don't do prediscovery you can't trust the
information you get back after the attack. Once the host is
compromised you can't believe anything it tells you IMHO.
> I think you miss quite a bit of data just watching the wire and not
> connecting to the host and see what is going on directly from within.
How about in the case of welchia? The host gets popped and the vuln is
patched in one shot, step 3 fails and the system is none the wiser. In
the event of a successful overflow or other admin/root granting remote
attacks, the configuration of the host after the attack may be nothing
like what's required to elevate your level of suspicion.
> Targeting IDS data is a good idea and has its uses, but many admins
> don't know what to do with the event even after it's been escalated.
Making the sensor smarter is an end unto itself for the sake of
improving the raw accuracy of the IDS process, providing
contextualization on the back end is also desirable. Training is a
problem that never goes away, luckily there are a lot of good training
orgs these days that can help.
> This is why we are focusing on automated attack investigation and
> response. Doing straight targeted IDS doesn't always provide the
> answers
> people want and isn't capable of directly collecting forensic
> information from the affected host for automated or manual
> investigations.
Automated forensics are useful and a nice step forward but if the
attacker evades the IDS or disables the forensics systems once he's on
the host then you've got a problem. The methodology described also
reveals a lot of information about the security posture of the site
that's being hit (i.e. Cisco CTR is in use) and what countermeasures
are appropriate to reduce the chances of being detected in the future.
In the worst case it could also be used to suggest what the
configuration of the IDS is...
> So perhaps the definition of targeted IDS should expand
> to include actual on-host investigation techniques, or we can create a
> new buzzword to encompass what it is that CTR actually does above
> straight targeted-IDS.
Automated network forensics? I think TIDS has a concise definition
right now, I'm not in favor of extending it.
-Marty
--
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Intelligent Security Monitoring
roesch (at) sourcefire (dot) com [email concealed] - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
[ reply ]