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: