Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17

[Will Metcalf <william.metcalf () gmail com>]

First off I know my opinion probably doesn't count for much, but I'm
growing very tired of the anti-SF comments that tend to follow my
posts, it doesn't add anything to the conversation and is quite
annoying.  I have a lot of respect for the snort devels past and
present. I mean names like Sturges, Novak, Norton, Roesch.  Do a
little bit of goggling to see who's names are on the majority of
substantial research done in the area of NIDS and I bet at one time or
another they worked for SF.  Also the VRT blog should be required
reading for anyone in this field. Matt Watchinski's presentation
@dojosec this year (http://www.ustream.tv/recorded/2502995) is the
best damn presentation I have seen on how to build an effective
security program ever.  You have to admit SF employs a lot have a lot
of very, very smart people. Agree with their decisions or not, things
would be more pleasant if you would at least show some respect for a
company that has invested millions of dollars into something that you
are now using in your network and/or have built a business around that
you have payed absolutely nothing for.

> My question to you: What IS the tool to do this.    Will it be the
> next round of snort, or does anyone have a better way to DETECT client
> side attacks.  I really think that since these are network based
> attacks, the industry needs to be a lot more effort into detecting
> these with NIDS.

Some of these apply to client-side and some are more general, it is
just my opinion so take it for what it's worth.

1. If your environment permits, don't allow normal users to download
executable content from non-trusted sites (this is harder than it
sounds, most proxies can block based on filename or mime-type very few
actually implement things like mime-sniffing to determine file type)
a lot of malware will use an exploit to gain access to a system only
to turn around and grab the actual executable from the web somewhere.

2. Don't allow your users to have administrative access to their
workstations.  I know all you check that box on your compliance form,
but come on this isn't how it is in the real world is it? ;-)

3. Deploy some sort of HIPS product, sure these can be bypassed as
well but it is a lot harder in most cases. For these to be of any use,
you have to know what applications you want to protect and the normal
behavior they are supposed to exhibit. For example I worked with a
product from vendor X that did a great job of buffer overflow
protection, but you had to tell it what applications you wanted it to
protect as it only came with a very small default list.  Most people
don't do this.

4. I know I said I wasn't going to put these in any particular order,
but this is the most important.  Organizations should probably invest
less in tools and more in people. You need to have a group of very,
very talented people working for your organization that know your
environment inside and out. These people also need to actually
understand what is happening in the security space and what this means
for your environment.  As Watchinski says in the talk above
"Technology Won't Save You... People Will."

5. Listen to people like Richard Bejtlich, and implement technologies
that will allow you to do retrospective analysis when your preventive
measures fail (it will happen, I can almost guarantee it) and your
detective measures give you just enough clues to let you know that
something doesn't look quite right on your net. Tools that will allow
you to do this might include things like full packet capture, flow
logging, centralized logging, an environment to perform host based
forensics, etc, etc.


> Filtering egress traffic: Easily bypassed in most locations by having
> the PDF connect outbound on port 443 or 25.

Hmmm unless you are a college or a boingo hotspot or something you
should not be allowing outbound port 25 access from anything other
than your mail relays.

> ASLR/buffer overflow protection: I personally do not have any
> experience with any of these types of products... You have any names?

Some of these technologies are built into various Windows/Unix OS's
and compilers but in most cases you have to use them for them to be
effective ;-).  There are commercial products as well i.e. Mcafee
HIPS, Cisco Security Agent, etc,  they fit into the HIPS category.

> HIDS/HIPS -- Can certainly help detect certain things that a NIDS will
> miss (encrypted traffic post decryption, right?), but can only detect
> again

Nope, preventive as well.

Regards,

Will

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs