IDS mailing list archives
Re: IDS thoughts
From: "Bill Royds" <Bill () royds net>
Date: Tue, 20 May 2003 19:12:04 -0400
I like you term "model driven" becuase it really better describes the space, But it also is both the solution and the problem. If we could properly model the data flows within an enterprise, then we could notice those flows that don't fit the model. But modelling the data flows within an enterprise is the classic problem of micro-economics. People have won Nobel prizes for showing the difficulties but no one can really do it. Sometimes it is possible if you can enforce your model à la Bell-LaPadula and lattice models of information flow, But like the Oange book and Rainbow series certification that stemmed from these models, real-like starts to have too many deviations from the models to easily apply them. The various approaches that are often labeled "anomaly-detection", such as protocol verification, statistical models etc. are really attempts to get a handle on the valid data flows within the enterprise to be able to detect the anomalies. Perhaps an approach that might fly is to combine a higher level threat-risk analysis methodology like Carnegie-Mellon's OCTAVE or COBIT to design the network so that one can model data flows between hosts and segments in a way understood by the business. If this is proeprly captured, then one can develop systems that have an allowed data flow rule set (a firewall) integrated with a monitor that examines unallowed flows to help determine what is happening. The problem at the moment is that the tools that should be enforcing data flow policies (security policy), firewalls, are seen as only enforcing IP stack conformance, not security policy conformance, and then only at the perimeter. A good security design within an enterprise would see every router/switch between logical segments being able to enforce the allowed traffic between thos segments, every host stack enforcing the allowed traffic to and from that host and every kernel enforcing flow of data between processes on that host (TCB). But that requuires actully knowing what you computers are supposed to be doing. And as the people who tried to apply the rainbow series of certifcation found out, it is very difficult to actuall enumerate what computers are used for in a business. ----- Original Message ----- From: "Thomas H.Ptacek" <tqbf () pobox com> To: "Mike Frantzen" <frantzen () nfr net> Cc: <focus-ids () securityfocus com> Sent: Tuesday, May 20, 2003 5:04 PM Subject: Re: IDS thoughts : > I haven't seen any sound theory on dynamically learning the "norm" of a : > network that learns more than connection/flow patterns. I would : > dispute : > the utility of an IDS that couldn't tell me that the CEO's laptop was : [ ... elided unfairly ] : : "Anomaly detection" isn't an architecture or implementation. It's no : more "rate over time, cross host cross protocol" than it is "validate : against RFCs". Anomaly detection is the philosophy of design that says : that we can find interesting events by looking for deviations from the : norm. We need to be careful about pigeonholing the entire philosophy : --- which is going to be fertile ground for research and development in : the coming years --- into the box that sits on your DMZ and tries to : spit out alerts about hacker attacks. : : I'm trying to coin the term "model-driven" as a replacement for : "anomaly-based" when discussing this stuff. "Model-driven" connotes the : fact that there are different threat models, and therefore different : logical models, involved in addressing the total network security : challenge. In this context, it matters much less that a given approach : is "anomaly-driven", and much more _which model_ is being used. : This is a question I think people should ask of anyone trying to sell : an "anomaly detection" system. : : There seems to be a low-intensity, largely specious argument occurring : over whether "anomaly detection" is the answer to the "problems" of : signature detection. I try not to involve myself in this. I see : signature detection systems as a coherent response to the scripted : attack threat that Internet perimeters face. The basic nature of a flow : modeling system lends itself towards a certain set of threats: they : aren't grepping payloads for strings. The basic nature of a signature : system lends itself towards a different set of threats: it's hard to : write the signature that says "web consultants shouldn't talk to the : payroll server". : : The real fallacy here (and I'm not saying it's in your argument) is the : idea that one system is going to address the whole network security : policy --- at least, any time soon. This attitude has some : organizations trying to solve internal security problems by monitoring : for RPC vulnerabilities, while ignoring the innocuous-looking : transactions occurring between a secretary and the CVS server. It also : has highly simplistic statistical systems trying to sub for detailed : signatures at the network perimeter. Let's agree that this is not : optimal. : : Since you bring it up, let's quickly address the point that "anomaly : detection vendors are correlating signature alerts with their own : alerts". Independent of whether implementation, model, and approach are : calibrated with the threat they're deployed against, correlation is : something that is going to happen. It's less a function of how : interesting the combination of the two alert streams are, and more a : function of the combination of the signature alert stream and the : underlying anomaly _model_. Models mine interesting things out of : networks. That's just what models do. This is less an issue of : "hybridization" and more a recognition that computer science has value : across the board in solving security issues. : : --- : Thomas H. Ptacek // Product Manager @ Arbor Networks : (734) 821-1432 : : : -------------------------------------------------------------------------- ----- : INTRUSION PREVENTION: READY FOR PRIME TIME? : : IntruShield now offers unprecedented Intrusion IntelligenceTM capabilities : - including intrusion identification, relevancy, direction, impact and analysis : - enabling a path to prevention. : : Download the latest white paper "Intrusion Prevention: Myths, Challenges, and Requirements" at: : http://www.securityfocus.com/IntruVert-focus-ids2 : -------------------------------------------------------------------------- ----- : ------------------------------------------------------------------------------- INTRUSION PREVENTION: READY FOR PRIME TIME? IntruShield now offers unprecedented Intrusion IntelligenceTM capabilities - including intrusion identification, relevancy, direction, impact and analysis - enabling a path to prevention. Download the latest white paper "Intrusion Prevention: Myths, Challenges, and Requirements" at: http://www.securityfocus.com/IntruVert-focus-ids2 -------------------------------------------------------------------------------
Current thread:
- IDS thoughts Randy Taylor (May 13)
- Re: IDS thoughts Stephen P. Berry (May 14)
- Re: IDS thoughts Stefano Zanero (May 20)
- Re: IDS thoughts Mike Frantzen (May 20)
- Re: IDS thoughts Thomas H . Ptacek (May 20)
- Re: IDS thoughts Mike Frantzen (May 20)
- Re: IDS thoughts Thomas H . Ptacek (May 20)
- Re: IDS thoughts Ramani Yellapragada (May 20)
- Re: IDS thoughts Lance Spitzner (May 21)
- Re: IDS thoughts Stefano Zanero (May 27)
- Re: IDS thoughts Bill Royds (May 21)
- Re: IDS thoughts Mike Frantzen (May 20)
- Re: IDS thoughts Roger A. Grimes (May 21)
- Re: IDS thoughts Raistlin (May 27)
- Random IDS Thoughts [WAS: Re: IDS thoughts] Greg Shipley (May 29)
- Message not available
- Re: Random IDS Thoughts [WAS: Re: IDS thoughts] SecurIT Informatique Inc. (May 30)
- <Possible follow-ups>
- Re: IDS thoughts Andrew Plato (May 20)