Re: Important Comments re: INtrusion Detection

[Craig Brozefsky <craig () onshore com>]

On Sat, 14 Feb 1998 tqbf () secnet com wrote:

> Believe it or not, the proxy solution actually solves quite a number of
> problems. I spent about 40 minutes yesterday trying to explain to Kurt
> Ziegler at AbirNet (who steadfastly believes that there's no difference
> between a sniffer and a proxy [after all, they see the same packets!]) why
> this was; hopefully, he reads Firewall-Wizards and will see this message,
> because I don't want to type it in again. =)

Yes, it solves quite a few problems, because it is a TCP endpoint, as you 
point out below.  But I don't think it solves the issue of providing a 
context for the evaluation of anomolies and attacks.  That problem is 
something that I think is going to require alot more work, and 
formalization, and I think can be considered seperate from wether the IDS 
is a proxy or a sniffer.

When I say context, I am talking about the information neccesarry to
distinguish between maybe a routine stream of data crossing a security
boundary(http request,cvs update, whatever) and a stream of data crossing
that boundary outside the normal operating parameters(maybe different time
slot, source port, destination, or encapsulating another protocol ala ssh
via http).   I must admit that my thoughts on this topic are just brewing 
and are certainly not finished.

> One other big win that Darren Reed identified at Usenix was that a proxy
> IDS can't drop packets. You can't overload it and sneak packets past that
> way. If the IDS can't read the packet, it doesn't get proxied. 

This is a big win, and one I hadn't thought of before.

> There are still problems that need to be solved here. The most obvious is
> that the IDS is no longer "unobtrusive", and it can actually bottleneck
> the network, unlike ID systems (which, when bogged down, simply fail to
> work reliably). There are also subtle problems at the protocol level, such
> as end-to-end acknowledgement. However, the firewall community has made
> this work; I'd be surprised if the IDS community couldn't too.

And also the problem of context within which to evaluate anomolies and 
possible attacks.  Part of this is configuration of the IDS, which often 
have inadequate control and query structures in their configuration 
languages.  Another part of it is the lack of strong formalizations for 
describing protocol and traffic behavior on several different levels.  
The old standby firewall gives us the formalization of TCP endpoints 
(host,port<->host,port), but this is only part of the information we need 
to identify security problems.  How about time series analysis of request 
response cycles, or statistical analysis of larger traffic patterns?  


Craig Brozefsky              craig () onshore com
onShore Inc.                 http://www.onshore.com/~craig
Programmer                   loitering on the edge