Re: Changes in IDS Companies?

[Frank Knobbe <fknobbe () knobbeits com>]

On Thu, 2002-10-17 at 00:52, roy lo wrote:
> I think you have just point out an interesting point here. Is the "IPS" 
> part really usable??
>
> A few month ago we had a discussion here regarding if man power can be 
> waver by having advance IDS (or something along that line) [correct me 
> if I'm wrong]
> I think the conclusion we came to was that until the "AI" of that IDS is 
> advance enough, man power couldn't/can't be waver.
>
> And "IPS" seems to be a good example of it. Like you(Chris) have point 
> out here, the IPS function will be turn off due to the fact that
> false alarms will be too high for it to be consider "safe" to use.
>
> So here is my questions to those of you, who works for those IDS vendors:
> "What kinda of effort is spend on refining(or develop) the logic (AI) 
> part of the (IPS)IDS?"
> "And how much of the hardware resource will be allocating to supporting 
> it? (An individual PU chip? or??)


Excellent points in this thread. I'd like to add some thoughts.

First off, I fully agree on the AI part. Firewalls don't need it. They
are like 'masks' that filter traffic and only allow things you would
like to come through. Not much AI needed there.

A standalone IDS system only has one 'decision kernel' -- is this
traffic worth alerting or not. AI would be nice, but is not required as
human operators can deal with the false positives.

However, once IDS start to interact with firewalls, or perform
firewall-like functions (Inline IDS), you don't have the luxury of the
human operator making the final decision. Here is where AI of the IDS is
critical.

I think that AI should be in the form of a second 'decision kernel' (for
lack of a better word). The IDS AI says 'hey, this seems to be bad
traffic as it matches a signature, I'd like to block this'. The second
decision kernel should work against it to scrutinize that decision, run
sanity checks and approve/deny the request.

I'm not aware of such balanced decision approaches in Inline IDS (I hate
to use the term Intrusion Prevention). From what I understand the
products, there is only one decision kernel -- traffic matches signature
and gets blocked, or not.

When I wrote SnortSam (which let's Snort block on FW-1, PIX and Cisco
routers), I tried to add a second decision kernel. Since I'm just a
hobbyist and not as smart as some of you academic folks, it was just a
simple decision -- do I think the blocking mechanism gets abused or not.
SnortSam has thresholds that, when a certain rate of blocking requests
is exceeded, will unblock the last requests and then just stay passive
for a while until the assumed attack subsides.

So, we have Snort saying 'hey, this tripped a signature and you wanted
me to block this', and SnortSam says either 'alright, I'll do it' or
'sorry, I think the active response mechanism is getting abused, I don't
want to block right now'.

I believe that we need to add more AI to active response IDS' or Inline
IDS' before we can allow the IDS to take an active part in the decision
process.



Second, I do believe active response (or IPS as you call it) is usable.
I've been running Snort and SnortSam for over three years now and
haven't shot myself in the foot yet. The reason may be this. I'm not
blocking on signatures (I tried that, but the false positive rate was
too high). Instead I'm using a rule set that serves as an anomaly
detector (in other words, I'm not using the spade plugin). These rules
allow me to *safely* detect traffic that could be considered hostile.
This is traffic is mostly scans, but this is exactly what I was aiming
for. If a scanner sweeps the network, the IDS recognizes that, and the
firewall will block him for a certain time. That has the effect that the
scanner is blinded and does not come back to probe for more.

Why am I telling you this? I think this is good example of how active
response is currently deployed (certain firewalls will close
automatically upon scans). It is interaction between detection and
firewall policy enforcement, and it does work. We just need to get the
false positives down and start adding -- selectively -- signatures that
can prevent traffic (either through firewall block, or inline discard).
At the same time we need to increase the second decision kernel to ...
uhm.... better scrutinize the desires of the first kernel. SnortSam only
has a threshold mechanism, which can hardly be described as AI, but it
is still a decision process working against the first one to achieve a
balanced and sane overall response. It could be made smarted such as
'You just asked me to block for this signature, now for this, but that
pattern doesn't normally occur or represents abuse, so we should not
enforce your IDS decision', but lack of my smarts hinder that
development :)


In conclusion, I believe AI needs to be added to active response and
inline IDS', but in a way that achieves balance and acts as a watch-dog
for the IDS decision. We also need products that are way more flexible
than some if the current products (I've seen IDS' that can only be
'tuned' but turning rules off or on. No flexibility in rule
modification). Vendors need to realize that flexibility is key to IDS',
especially if inline/blocking features are added. 

I think we need to produce decent IDS' first before we can start
thinking about allowing these IDS to control traffic flow....


Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part