IDS mailing list archives
Re: Target based IDS review and discussion in Information Security
From: Martin Roesch <roesch () sourcefire com>
Date: Mon, 12 Jan 2004 23:02:22 -0500
Hi Craig,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 perhapsstep 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 andresponse. Doing straight targeted IDS doesn't always provide the answerspeople 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 () sourcefire com - http://www.sourcefire.com Snort: Open Source Network IDS - http://www.snort.org --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- Target based IDS review and discussion in Information Security Joel Snyder (Jan 08)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 09)
- Re: Target based IDS review and discussion in Information Security Joel Snyder (Jan 09)
- Re: Target based IDS review and discussion in Information Security Jeff Nathan (Jan 12)
- RE: Target based IDS review and discussion in Information Security Craig H. Rowland (Jan 12)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 13)
- RE: Target based IDS review and discussion in Information Security Craig H. Rowland (Jan 13)
- Re: Target based IDS review and discussion in Information Security Ron Gula (Jan 13)
- Re: Target based IDS review and discussion in Information Security Joel Snyder (Jan 09)
- Re: Target based IDS review and discussion in Information Security Andy Cuff [Talisker] (Jan 12)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 12)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 09)
- <Possible follow-ups>
- Re: Target based IDS review and discussion in Information Security Richard Bejtlich (Jan 13)
- RE: Target based IDS review and discussion in Information Security Teicher, Mark (Mark) (Jan 13)