Re: Host based IDS methodology and testing
From: Mark Crosbie (mcrosbie@cup.hp.com)Date: 10/29/01
- Previous message: Kester, Kelly: "RE: Operational Readiness with CJ6510 ?"
- In reply to: Curt Wilson: "Host based IDS methodology and testing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "Curt Wilson" <cwilson@denmac.com> Subject: Re: Host based IDS methodology and testing Date: Mon, 29 Oct 2001 10:45:37 -0500 From: Mark Crosbie <mcrosbie@cup.hp.com> Message-Id: <20011029154542.11FFE190FD@mc72308m.cup.hp.com>
In message <sbd97f4e.087@denmac.com>, "Curt Wilson" writes:
Hi Curt,
>Any production experience with any of the above products, or any host ids prod
>ucts not mentioned, would also be helpful. Please write me at curtw@denmac.com
> or post to the list if appropriate.
{\begin marketing}
If you have any HPUX systems, I might humbly suggest (:-) that you take
a look at HP IDS/9000: http://www.hp.com/security/products/ids
You can download it for free from software.hp.com. Version 2.0 is coming
out in December that has some neat features.
{\end marketing}
From an engineering standpoint I'm interested in how you plan to conduct
the host tests. We examined this problem from a number of angles and
came to some (not very satisfactory) conclusions:
1. Every system has a "unique" configuration of software that makes it
almost impossible to have a consistent test environment.
2. You may see varying system behavior depending on the software patch
levels installed. Often you will find that software generates
intrusion alerts simply because it is poorly desgined (e.g. writing
logs into read-only /opt)
3. No one knows what a "system load" is, but they'll tell you when you
have chosen one that does not match their beliefs.
4. Everyone wants minimum performance impact, but nobody can define
what "performance" means. We chose TPCC benchmarks for high end
servers. Some people choose CPU load, others choose response time.
5. Everyone has a different measure of effectiveness: some want to
know about new attacks launched against their systems, some want to
know about a pre-configured set of attacks. Others just want to see
no attack warnings.
6. Time to respond is critical if you are building reactive
security. Most of the time we could generate an alert in less than a
second, so an automated reaction script made sense. But if the alert
comes 1 minute later, does reacting automatically make sense?
7. If the system is claiming *proactive* security what sort of a
performance hit do you take context switching from kernel to user
land to access check every system call?
8. Time delays in reporting alerts are often very dependent on the
particular system configuration: if you are checking for race
conditions, you'll probably be watching the stat() family of system
calls. If you have an application that does a lot of stat calls (like
top) then you'll quickly fall behind processing the data.
9. Finally, when you do fall behind processing data (and you will),
what controls do you have over how the IDS behaves?
Some thoughts, comments welcome from all...
Mark.
-- Mark Crosbie IDS/9000 Product Architect http://www.hp.com/security/products/ids Hewlett-Packard MS 47 LA mcrosbie@cup.hp.com 19447 Pruneridge Avenue (408) 447-2308 Cupertino, CA 95014 (408) 447-6766 FAX>Thanks > > > >Curt Wilson >Security Engineer >Denmac Systems Inc. >curtw@denmac.com >
- Previous message: Kester, Kelly: "RE: Operational Readiness with CJ6510 ?"
- In reply to: Curt Wilson: "Host based IDS methodology and testing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
