[Dshield] IDS Analysts
Albert Gonzalez
albertg at cerveau.us
Fri Feb 1 17:51:29 GMT 2008
Pete,
There is no value in having an Analyst that can just read alert
messages. I have received one too many calls when 5 mins of
investigation would've provided the answer. You say that with that skill
set they can "deconflict false-positives" which is the number 1 issue
when deploying IDS/IPS technology. Granted you don't need to understand
what it means to compare a capture to what a signature is looking for,
but man will your life be easier (e.g Snort + content). Having my SEIM
solution tell me it correlated events from X Y and Z system to determine
"Un-authorized attempt" still merits investigation at multiple levels
even if the correlation rules were written perfectly.
The other use you said was "signature creation" which is a MUST
(assuming your vendor of choice lets you see/edit/create them) IMHO. Not
always for malicious activity but for any number of things. I have
written signatures to check for certain activity on the network that is
not malicious but against company policy. Hell I have a signature that
tells me which of my users is actually using 443 for tunneling, an IDS
is not meant for that but I can leverage it. I don't approach analysis
strictly from a security perspective but a "what can I learn"
perspective.
I am not against using tools like Wireshark, I use it daily but at the
same time you should be able to interpret what you are seeing when these
utilities are not available (and you can't dump the pcap anywhere :)).
Prime example of the problem they cause is with GUIS for IPtables.
Various scripts/front-ends exist for it and plenty of people use them.
When something goes wrong, they have no clue beyond that GUI on where to
go from there (some not all). I am sorry but I am just a geek I guess. I
am truly tired of "System X is down, lets call support" urgh! Why?!?!
Investigate a bit, do some due diligence. It's fun under the hood!
- Albert
--
Success comes to the person who does today what you are thinking of doing tomorrow.
GPG KeyID = 4914A9D4
On Fri, 2008-02-01 at 08:33 -0800, Pete Cap wrote:
> ----- Original Message ----
> From: JiPi DiNi <jipidini at gmail.com>
> To: General DShield Discussion List <list at lists.dshield.org>
> Sent: Tuesday, January 29, 2008 11:13:40 PM
> Subject: Re: [Dshield] IDS Analysts
>
> Packets analysis should be mandatory.
>
> An analyst should be able to tell you what is contained in the IP, TCP, UDP
> & ICMP header.
> ie (this packets is an IP packet that is missing fragment. It's going to dst
> dst.port and comming from...)
>
> Also, very good skills for all the applications & OS that are behind the IDS
> so that they know what they are protecting or looking at... (ie events
> generated for cat /etc/shadow... and the analyst goes: What is /etc/shadow?
> I remember reading about /etc/shadow but what is it ?)
>
> Reverse engineering of binaries and exploit analysis is a must too!
> -----/ Original Message ----
>
> Hold on a second.
>
> We started this conversation by lamenting the lack of analysts who are proficient with perl or bash scripting to handle a large IDS deployment; being able to use these timesavers is great, right?
>
> So why are we now saying analysts need to be able to read packet headers when we (the community) developed tools (wireshark) specifically to avoid having to do that?
>
> Now there are SIM solutions (Symantec has one and there's Arcsight, and everyone who hasn't got one is developing one) that will draw correlations among your IPS events, netflow records, windows event logs, and so forth looking for trouble. We build these tools also because doing correlation can be a PITA.
>
> Now, I have to ask, is having the skills for deep packet analysis really something we need for analysts? It's nice to have for guys doing "discovery" for novel exploits (e.g. the guy analyzing honeypot hits looking for 0-days) or developing signatures. What is an IDS tech going to do with that skill set? Maybe deconflict false positives. Beyond that, what? Why is this skill something we want for an IDS guy?
>
> In addition, even with all these tools, we still have incident handlers and so forth who don't "do" security very well. Being able to dig into payloads won't help them. I believe there is another factor at work that makes you "good" at security; people who have these skill sets (packet analysis, reversing, facility with scripting and databases, correlation) probably already have that X-factor, we need to figure out what it is first.
>
> Put another way, the skills are a symptom of "being good," but "being good" doesn't consist solely of those skills.
>
> thoughts?
>
> Best regards,
> Pete
>
>
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
> _________________________________________
> SANS Security 2008 in New Orleans!! January 11-19 2008. Why freeze up north if you can be in New Orleans. http://www.sans.org/info/15826
>
More information about the list
mailing list