RE: Experience security-information-management
mhellman_at_taxandfinance.com
Date: 11/17/05
- Previous message: José Luis Jerez: "RE: Experience security-information-management"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 16 Nov 2005 17:26:38 -0600 (CST) To: focus-ids@securityfocus.com
> -----Original Message-----
> From: klaus.dombrofsky@degussa.com [mailto:klaus.dombrofsky@degussa.com]
Sent: Monday, November 14, 2005 3:18 AM
> To: focus-ids@securityfocus.com
> Subject: Experience security-information-management
>
> Hi folks,
>
> Has anyone already experiences with a security-information-tool like
ArcSight/Open Service or similar ?
> We plan to evaluate systems, which are able to read different logfiles
(
> ids, firewall, ..... ) to extract possible relations to find possible
intrusion-trials.
> At the moment i see tons of logfiles, which can not be checked anymore
and
> i cannot imagine that a tool is able to check these files AND is able to
find
> valuable informations and relations.
> Maybe someone of you already has positive or negative experiences. Or
there are important points, which should be checked in an evaluation.
b
There are lots of solutions that do this now...or at least claim to;-).
I've taken a cursory look at a number of them, and I've used NetForensics
(without the add-on correlation product) and CSMARS (formally Protego
MARS) in a small to medium-sized production environment.
The three things the really bug me most about the current state of SEM
products:
1) licensing
2) software flaws
3) update cyle
First of all, the way most of these products are licensed is ridiculous
IMHO. Many of the vendors want you to pay per device license fees,
sometimes more than $1500 a pop list. At least one of the vendors uses
some combination of events per second (EPS) and number of devices, which
results in an even more restrictive license than a simple per device
license. Look for a product (CSMARS is one...hopefully there are others)
that is licensed based on the number of events per second processed.
Secondly, in addition to the outright purchase dollars, you better be
prepared to throw some serious manpower at these solutions. They're
complicated and they're brittle IMHO. You must carefully validate the
results they provide, because they often don't do the right thing or even
break entirely. I'll give you a couple examples, and I have many more like
this. At one time, the Netforensics agent for Cisco IDS 4.x was doubling
the event count as received by the sensor and storing it in the database.
CSMARS had [possibly still has] an issue where the Cisco IPS 5.x event
collection process restarts when it receives specific events (for example,
the recent MS plug-an-play overflow). Cisco says it's fixed, but they
said that 2 patches ago. Hell, just this morning I found an issue with
CSMARS where data from an entirely different event is being written into
another event.
And lastly, consider carefully your expectations/needs regarding updates.
These solutions usually support lots of devices, but some of it is little
more than marketing fluff IMHO, because the components are rarely updated.
At one point, Netforensics was literally months behind the Cisco IDS
signatures and their Unix agent failed to properly parse many security
relevant Solaris 9 messages (this was years after Solaris 9 was released).
I believe they've fixed this now, but you get the point. CSMARS, as of the
latest update, is currently 8 signature levels behind the Cisco IPS 5.x
signature levels. You can't expect a SEM to do a good job of
analyzing/correlating events for which it has no understanding of.
IMHO, correlation isn't really all that complicated--at least
conceptually. The key is to put incoming events into normalized
event-type buckets (which you can't do if you don't understand the
event...see update issue above). Then you can create general rules that
say "if you see normalized event-type a and normalized event-type b, with
the same target within n seconds...". An example of this might be a
buffer-overflow event received from a NIDS sensor and a "user added" event
from a Windows machine or a Unix machine. The same correlation rule can be
applied in either case because "user added" is a generic event type.
Forgetting for a moment the brokeness of some critical components, CSMARS
seems to do a pretty good job of correlation. It also attempts to
sessionize events so that traffic that crosses a NAT boundry is properly
treated. The licensing is based on EPS only, which is great. Because they
don't have the breadth of device support, if you're primarily a Cisco shop
it might be a good choice...but ONLY if they manage to make it more robust
over the next few months. The last month has shown that instead Cisco
might be taking it in the opposite direction;( Today they released a
critical patch to fix the last patch (you know, the kind that says "DON'T
APPLY THAT LAST PATCH" in the release notes. Lovely.
Goodluck,
Matt
------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------
- Previous message: José Luis Jerez: "RE: Experience security-information-management"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
