('binary' encoding is not supported, stored as-is)
In-Reply-To: <00d001c39a4b$1fe8a1b0$ecb66540_at_amer.cisco.com>
Craig,
I agree with your sentiments, but having done network- and host-based incident response I don't think host-based forensics are always 100% necessary. I'm so glad you brought your point forward, though.
Answering the "now what?" question is PARAMOUNT but frequently ignored. Even if I have perfect detection of the intrusion, now what happens? What did the intruder do after initial exploitation? Where did he log in using the valid credentials brute-forced from the victim's /etc/shadow file? What data did he steal and where did he copy it? Granted, encryption foils knowing some of this, but traffic analysis of sessions containing encrypted data is better than no analysis at all.
I follow the "network security monitoring" (NSM) approach because it focuses on the "now what" question. We capture as much varied data as possible, in event (classic "IDS"), session (NetFlow/Argus), full content (tcpdump), and statistical (behavioral/graphs/etc.) form.
You never know how you might catch the intruder -- it could be your IDS, or a sys admin, or a user. But once you have a clue where to look, you use your data -- whatever is available and helpful -- to scope the extent and impact of compromise. This a "network traffic audit" (NTA) approach that's absent in most IDS products.
I'm writing now about how I've done this during the past five years, and I'm excited by the number of open source tools available to move these practices out of the Air Force and into resource-constrained environments.
Sincerely,
Richard Bejtlich
http://taosecurity.com
PS: An earlier comment about the IDS as a "system" reminded me of the Protection Profile for the "Intrusion Detection System SYSTEM" -- http://niap.nist.gov/cc-scheme/PP_IDSSYPP_V1.4.html -- composed of IDS "Sensors, Analyzers, and Scanners." Good thinking NSA, although a vulnerability assessment scanner (measuring vulnerabilities) is not in the same class as an IDS (measuring threats)!
>From: "Craig H. Rowland" <crowland_at_cisco.com>
>There is a third method that hasn't been mentioned yet: Automating the
>on-host investigation of the attack.
<snip>
>In the end you're simply going to
>have to look at the system directly to see if the problem exists.
<snip>
>
>An IDS only gets you so far and what you're left with after the
>detection is a *huge* amount of manual work even if you have only a
>small number of alarms a day. Consider that after the attack has been
>seen you have to:
>
>1) Verify the attack
>2) Investigate the attack
>3) Cleanup and isolate the affected host
>4) Etc.
>
>You need to eliminate as much of the remaining manual process as
>possible to be useful. For me this means automating as much of the
>post-attack investigation and evidence collection as you can. Not only
>is the level of expertise required to do this very high even for those
>who do this stuff daily, but having the repeatability and 24/7 response
>is critical to most admins.
>
>-- Craig
---------------------------------------------------------------------------
Network with over 10,000 of the brightest minds in information security
at the largest, most highly-anticipated industry event of the year.
Don't miss RSA Conference 2004! Choose from over 200 class sessions and
see demos from more than 250 industry vendors. If your job touches
security, you need to be here. Learn more or register at
http://www.securityfocus.com/sponsor/RSA_focus-ids_031023
and use priority code SF4.
---------------------------------------------------------------------------
Received on Oct 25 2003
Intro
