RE: Network hardware IPS

Responses inline, as usual... ;)

-----Original Message-----
From: Kohlenberg, Toby [mailto:toby.kohlenberg_at_intel.com]
Sent: Thursday, October 09, 2003 12:45 AM
To: Dave Killion; david maynor
Cc: Stefano Zanero; focus-ids_at_securityfocus.com
Subject: RE: Network hardware IPS

> That's a great ideal. When was the last time you tried to implement a
> rule
> that would catch attacks against buffer overflows in HTTP servers when
> the
> NOP sled can change content and size, the content of the attack code can
> change
> content and size and the only likely constant is that it contains
> cmd.exe?

> Rules for specific exploits are easy- that's why worm rules are a
> cakewalk.
> The hard ones are the ones for the actual vulnerability the exploit is
> hitting.
> It is absolutely possible, it is just much harder to do without
> generating the
> occasional false positive.

I agree completely - I never implied I could always catch everything. No,
I don't have an easy job.

>> Anyway, anyone who's crazy enough to put "cmd.exe" in his
>> path deserves
>> all the False Positives he can stomach. And quoting a 5-year
>> old paper on
>> IDS evasion doesn't convince me.

> See above. I'll take it out of the signature base if you explain to me
> how you
> are going to catch novel or semi-novel attacks using very specific rules
> that
> are looking for known patterns.

I don't know what you mean here - one of us is misunderstanding each
other. Stephano implied that there was a case that cmd.exe could be a
valid (non-hostile, i.e False Positive) URL match. This was my response -
if that's valid in your environment, you should have your head examined.
And as for the IDS-evasion paper comment, we've read it too, and done as
much as possible to NOT be evaded. What I want to see is a new paper,
less than 5 years old, that has something *new*. I'll be very interested
in reading that.

>> If I can create signatures to detect the majority of important attacks
>> with a minimum of false positives, to the point where
>> customers will buy
>> the product, then my job is successful.

> Ah, but you see, that's the problem. Most of us aren't _selling_
> IDS/IPS/deep_packet_inspection whatever. We actually have to _implement_
> them and make them work. Which means that they not only have to _not_
> produce more false positives than we can handle, they actually have to
> _catch_ bad things that aren't easily and clearly defined already. Which
> means
> fuzziness, which means false positives. We don't get to focus on the
> "majority"
> of "important" attacks. Which would be the important ones? Exactly what
> percentage is "the majority"?
> Perhaps you didn't mean what you said because it comes across as meaning
> that
> you aren't interested in delivering a complete product, just the bare
> minimum
> necessary to get you in the door.

I don't sell this thing - I make it. And I use it = "eating your own dog
food" as they say. So I *do* _implement_ this device, and I want it to
work as effectively as possible. I'm as demanding of a user as any of my
customers. So no - I'm not going for the bare minimum. I'm going for the
maximum possible - we're always pushing the limits of the product, and
trying to surpass all competition - by providing the most complete product
possible. And we're always looking to reduce false positives, while
maximize detection rates. Which is why I was so frustrated at Stephano
for implying that the two values are inseparable.

As for detecting the "majority" of "important" attacks - do you really
have time to track down every port scan? How important is it when you're
being "attacked" on something you have no vulnerability against (i.e. you
run only Apache, and someone tries to attack you with an IIS-specific
vulnerability)? Do you want to be paged at 3am by your IDS/IDP, only to
find out it wasn't a valid attack?

"Majority" and "Important" are defined by our customers. And if we've
missed something, they tell us. Any valid signature request that comes
from the field is generally in next week's release. And they can make
their own, as well.

I hope this clears things up.

This email contains material that is confidential. The content of this
email is for the sole use of the intended recipient(s). Any review or
distribution by persons other than the intended recipient(s) without the
express permission of NetScreen Technologies, Inc. is strictly prohibited.
If you are not the intended recipient, please contact the sender and
delete/destroy all copies of this email and any related attachments.
NetScreen does not guarantee the accuracy or completeness of third party
materials or information.