From: toby (toby00gmail.com)
Date: Tue Apr 11 2006 - 21:21:47 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I can't tell you the number of times I've had to explain that
"anomalous" != bad.
Even for very well developed/tuned systems where it actually does, the
worst thing I've run into with these products is that they really give
horrible log data.
With a NIDS you can at least get a complete packet trace. I'd love
just once to see a HIDS/HIPS product that gave me something resembling
a complete stack and execution trace along with all the various data
bits (variables, arguments, file names, etc...) I need to properly
figure out what it saw and whether it was right or not.
Oh, they also seem to have a nasty tendency of not actually telling
you what application requested some function from any of the core OS
libraries or services. Which means that a rediculous amount of the
time, you see a log entry that says svchost or explorer or csrss or
rundll32, etc...

<sigh> all you vendors out there, don't pay any attention to this, I
only have a 150,000+ client environment that I have to use solutions
like this for. It's not like there would be any real business ROI for
you to listen and do something about these issues.

t

On 4/11/06, Dave Aitel <daveimmunityinc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The major weakness with HIDS is still the extremely tiny market share
> any of them has managed to get. :>
>
> I would imagine one hard thing with a Determina type solution is any
> kind of code that doesn't lend itself to modification or static
> analysis. Python, PHP, .Net or Java code, for example, would be
> extremely hard to profile looking at basic code blocks. And the
> problem with any anomoly based system is that when something goes
> wrong, you have no real way to describe to the user what went wrong or
> why. So you end up on the signature treadmill again, taking every
> basic block and applying little if statements to the end of them to
> check for particular vulnerabilities - not because you can't protect
> the machine already, but because you need to tell the user exactly
> what is going on. And, of course, checking basic blocks doesn't
> protect you at all from heap overflows or other techniques when used
> to change variables themselves - it just prevents you from changing
> execution path. But execution path and "give me admin" can be two
> different things.
>
> It's potentially the lack of "completeness" and the managability
> issues which are causing the market to say "Let's just wait for MS to
> fix their own stuff".
>
> Just a few thoughts while everyone spends time debugging the thousand
> and one IE bugs. :>
>
> - -dave
>
>
> redsand wrote:
>
> > Black Security is also currently doing some audits on the Determina
> > Software Suite. Nothing has come of it yet but hopefully some
> > positive results will come out of our testing soon. Any
> > information may/hopefully will make it to our blogs or a formal
> > piece of documentation.
> >
> > In the sales meeting, a Determina rep even claimed that ISS had a
> > hack for it but couldn't prove it.
> >
> > On Tue, 2006-04-11 at 17:43 +0200, pageexecfreemail.hu wrote:
> >
> >> On 10 Apr 2006 at 16:13, Knape, Joe wrote:
> >>
> >>> My "group" has also been looking at a "suite" of products that
> >>> includes a "Memory Firewall" and "LiveShield" from a company
> >>> called Determina. They make some bold claims and I've been
> >>> testing it in a lab setup but I'd like to hear if anyone has
> >>> been using it in a real-world environment?
> >>
> >> Determina's product is based on the research done at MIT under
> >> the DynamoRIO project. google for "program shepherding" (and the
> >> mispelled "sheperding" version) to find all you wanted to know.
> >> in my opinion, program shepherding is the only other technology
> >> that measures up to PaX, and for now it does even more in fact
> >> (deterministic ret2libc attack prevention).
> >>
> >> unfortunately source code has never been published, so some
> >> claims of security cannot be verified (e.g., their research paper
> >> mentions then unresolved issues with multithreaded apps).
> >>
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFEO/4HB8JNm+PA+iURAjvEAKDQC4AeDTajGTRvGxG9U6c9YLLtrACfUQjk
> DvcX/LaU2jBdhKfbD0UTmNE=
> =QVro
> -----END PGP SIGNATURE-----
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]