RE: Statistical Anomaly Analysis? (fwd)

From: Derek Walker (derwalke@cisco.com)
Date: 03/20/02 

Date: Tue, 19 Mar 2002 17:36:33 -0800 (PST)
From: Derek Walker <derwalke@cisco.com>
To: Oliver Friedrichs <of@securityfocus.com>

On Tue, 19 Mar 2002, Oliver Friedrichs wrote:

>
> > 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.
>
> What is the benefit of alerting on anomalous events that have dropped by 3
> standard deviations? At that point, they are diminishing events, and not
> something of value - I'm not saying that they are not interesting, they
> certainly are, I argue the fact that they should be alerted on with the same
> priority as events that are rising. If you are talking specifically about
> the prioritization of administrative resources, there is some value in
> alerting on diminishing attacks - but only if you had previously alerted on
> the event while it was increasing in the first place, so that those
> resources can be reassigned.

The negative dips can be of value in several ways. It depends upon your
security model for the enterprise though.

If you are the type of corporation that does not filter or tune out any
regular traffic then the negatives can alert you to several things:

1. One of your boxes dropping off the air.

        If you had a box that was a generally noisy 'false positive' and
        this goes away, then you have some issues. Was it rooted and
        patched? Has it beeen DOS'd? At the very least your network
        topology might have changed on you and you need to investigate.

2. An event type dropping down below known and learned thresholds.

        Are all the college kids at home and you can rest easy until
        spring break is over? Have they shifted to another method of
        intrusion based upon information gathered while 'baselining' your
        network? And again, with enterprise networks... has you local LAN
           team cut you off without telling you?

        I know the infrastructure pieces aren't really about the analysis
          of traffic, but if you stop seeing events, how well can you watch for
        intrusions?

        My team does filter and tune, so most of our negative sigmas are
          more administrative for us, but as you can see there may yet be some
        good information in those alerts as well.

>
> > 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.
>
> This looks very familiar ;) Some insight on a global perspective (from
> ARIS) - If you are running these stats on a single enterprise, then you
> would likely generate an alarm here. But, when you are running these stats
> looking for wider reaching, global activities, such as a worm, or increased
> use of specific tools or events you would also look for more than a single
> sensor entering an anomalous state. This is because you don't want to alarm
> when a single mis-configured IDS, a bad signature, or other network problems
> occur. On the enterprise level you would want to look at these events on a
> case-by-case basis.

I *am* looking at this from a global perspective. :) Trust me.
Everything I have discussed herein, we do.

That's why I made the statement about letting IDSs do their primary
analysis first. To be clear, I am a consumer of technology and not a
developer so keep that in mind. Although I do have a fair amount of input
to your analysis level one as stated below as.

>
> There are really 3 levels of analysis here:
>
> 1. Signature / Anomaly Based IDS at a network level
> 2. Anomaly Detection / analysis at the console / reporting level
> 3. Anomaly Detection / analysis at the global level
>
> Obviously, you need to do #2 to do #3.
>
> > 3. Uniques
> >
> > Quick and dirty way of doing SD analysis without the math
>
> Can you elaborate on this a little more?

This is now biggie. But does lead into some other discussions. I'll try
to keep it brief.

In a large scale network of any type there will be false positives. We
know this. Nothing is perfect. But given a large enough data sample
(read: big assed network) the likelyhood of a *single* event occuring with
no prior references or following occurances is next to nill. False
positives occur because of a 'condition'. In a big network this
'condition' will statisticly happen more than *once*.

On some of the reports we churn we look for those before we do the math.
Out of ten bazzillion events a day, having *one* event be unique bears
looking into. At least to my security mindset.

>
> > 4. Profiling of activitites
> >
> > NIMDA, Network recon, etc... generally match a fingerprint
>
> Eventually you will probably want to apply the same statistical methods to
> these profiles as well. i.e. You normally have 1000 portscans a day (for
> which you've correlated hundreds or thousands of events to create a
> portscan) - so the fact that you are seeing portscans alone is not that
> useful, you want to perform analysis on the number of portscans to watch for
> an anomaly. This is a good example of the multiple levels of analysis that
> really needs to be done.

Agreed.

D.

> Oliver Friedrichs
> Director of Engineering - ARIS
> (650) 655-6331
>

Relevant Pages

  • Re: Stop message
    ... Event Source: E100B ... "This typically shows up when the network cable is unplugged from an Intel ... > Event Type: Warning ... > Computer: HERMIONE ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Network shares and printing
    ... Event Type: Error ... network. ... see Help and Support Center at ... Event Source: AutoEnrollment ...
    (microsoft.public.windowsxp.network_web)
  • Re: Network shares and printing
    ... Event Type: Error ... network. ... see Help and Support Center at ... Event Source: AutoEnrollment ...
    (microsoft.public.windowsxp.network_web)
  • Re: Blue Screen
    ... You need to identify which network card is causing the problem. ... Event Type: Information ... Event Source: Save Dump ... see Help and Support Center at ...
    (microsoft.public.windowsxp.general)
  • Re: Statistical Anomaly Analysis?
    ... If you set up your model to account for each event type as a part of the ... the aggregation of traffics should smooth the ... > key, events that were 6-sigma outliers for a small network, and hence ... > likewise has an immense amount of variability; but its bulk statistics ...
    (Focus-IDS)