Re: Statistical Anomaly Analysis?
From: Derek Walker (derwalke@cisco.com)Date: 03/19/02
- Previous message: Michal Zalewski: "Re: FW: *ICN - A Conspiracy of Inertia?"
- In reply to: Vern Paxson: "Re: Statistical Anomaly Analysis?"
- Next in thread: Stephen P. Berry: "Re: Statistical Anomaly Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 19 Mar 2002 09:59:39 -0800 (PST) From: Derek Walker <derwalke@cisco.com> To: Vern Paxson <vern@icir.org>
I've been reading this quite eagerly in terms of content and I suppose now
it is time for me to wade in a bit.
In terms of anomaly detection by statistical analysis:
If you are looking for anomalies... *true* anomalies, you will not just
see the 'huge' spikes. Negative sigmas are every bit as viable a detection
method as positive ones. Big drop offs should alert you just as much.
Also, say you have a NIDS system set up and we aren't just looking at
traffic flows and types but actual events of some sort firing that have
been through primary analysis already at the host/sensor level. This is
where you can do some really cool stuff with the statistical model.
If you set up your model to account for each event type as a part of the
aggregate whole and say, set up the data samples to have a rolling window
of time that takes into account business cycles, then if you are doing the
calculations based upon each event type, a single shell script will light
up like a flair if it breaks the norms for that event type during the
sampling period. This is looking for norms and deviation based upon
volume of type, not just volume. It adds another dimension to the calc
and a bit of refinement of detail.
Of course this doesn't answer all issues discussed in this thread but...
Anomaly detection is not neccessarily intrusion detection.
For my team there are four parallel and equal areas of effort:
1. Volume aggregation of events
Catch the top offenders by volume.
2. Statistical Deviation
Looking for the outliers past 3 SDs positive *or* negative
3. Uniques
Quick and dirty way of doing SD analysis without the math
4. Profiling of activitites
NIMDA, Network recon, etc... generally match a fingerprint
My main point here is that we use all four of these methods simultaneously
to track down bad guys. And yes we also do manual sifting of data based
upon gut feelings as well.
Relying on any one of these types, or another you use, alone is limiting
your visability into events by default. A concerted mor holistic approach will
yield better results. At least this has been my experience tacticly.
When you go to purchase software or code your own and the feature set of
'top ten attackers/defenders lists' comes up, how many of you think about
*bottom* ten... :)
D.
On Mon, 18 Mar 2002, Vern Paxson wrote:
> (finally have my head [briefly!] above water - interesting thread!)
>
> > >Interesting. I thought that it would be harder for small scale networks.
> > >For large scale networks, the aggregation of traffics should smooth the
> > >variasions and turn it to more statistically expectable distributions.
> >
> > Right! Smoother distributions mean that you're losing detail - the "edge"
> > cases that you're looking for for an IDS capability. Basically, what you're
> > dealing with is a signal processing problem - you're trying to pick a signal
> > out of a lot of other signals (not noise: other signals). So if you start
> > doing standard distributions what you're doing is eliminating the weaker
> > signals (the trojan horse remote control channel) and favoring the stronger
> > signals (HTTP traffic)...
> >
> > I keep waiting for Vern to chime in on this one and tell me I'm an idiot...
> > Vern? ;)
>
> 'Fraid I have to disappoint :-), I agree with you. Traffic does smooth
> out in a statistical sense as it's aggregated - *but*, and this is the
> key, events that were 6-sigma outliers for a small network, and hence
> almost never happened, remain 6-sigma outliers for a large network, but
> now *do* happen, because you have such a high volume of traffic. Here
> I'm referring to statistical "anomalies" that in fact are benign.
>
> One facet of this is discussed in (the journal version of) the Bro paper
> as the problem of "Crud" (section 7.3 of
> http://www.icir.org/vern/papers/bro-CN99.html).
>
> I also experience this every day, through three different Bro systems
> I'm involved in operating. One watches ICSI's network, which has ~150
> hosts that are centrally managed and running just a few different OS's.
> I can imagine being able to develop useful statistical profiles for that
> network; something we may try at some point, though ICSI's cross-section
> for being attacked is pretty low (this is **not** an invitation to anyone
> to increase it!).
>
> Another watches LBL's network, which has ~6,000 hosts that are diversely
> managed. The traffic is *much* more variable and pretty much every day
> we see new-but-benign weird things.
>
> Another watches UC Berkeley's network, which has ~45,000 hosts. That traffic
> likewise has an immense amount of variability; but its bulk statistics
> (total packets or TB per day, traffic mix) are more stable than LBL's, in
> line with the smoothing you discuss above. But I agree with the follow-on
> discussion in this thread - it's not clear you can do much with that sort
> of regularity beyond detecting huge-spike attacks like worms or DDOS (which
> certainly make themselves apparent without anomaly detection anyway).
>
> Vern
>
- Previous message: Michal Zalewski: "Re: FW: *ICN - A Conspiracy of Inertia?"
- In reply to: Vern Paxson: "Re: Statistical Anomaly Analysis?"
- Next in thread: Stephen P. Berry: "Re: Statistical Anomaly Analysis?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
