Re: Question on resources needed to manage IDSes

[Terence Runge <terencerunge () sbcglobal net>]

My two very unscientific cents on the subject.

Analyst to employee ratio 1:3000
Analyst to sensor ratio 1:30
Analyst to bad guy ratio 1:1 ymmv

Those are some loose numbers that have stayed fairly
consistent in my experience as an analyst with both
public and private sectors.

Some of the key missing factors here include
analyst:server, analyst:class, and
analyst:environment. As an example, more time is spent
"researching" the anomolous activities of 7000+
employees running windows than the 100,000+ servers
running *nix.

Other factors are attrition and culture. This is more
along the lines of behavior analysis, but it keeps an
analyst busy. Most new employees who are going to
involve themselves in some sort of nefarious activity
will, in my experience, typically do so over a three
month time sequence. Again, the bad guy ratio, which
may be 1:1 but can take months of your time.

Three things which will cut down on the amount of time
an analyst spends staring at the ids are clear policy,
well written rules, and knowledge.

Terence

> -----Original Message-----
> From: Jack Whitsitt (jofny)
> [mailto:seclists () violating us]
> Sent: Monday, December 01, 2003 7:14 PM
> To: kgeorgiades () toplayer com
> Cc: focus-ids () securityfocus com
> Subject: Re: Question on resources needed to manage
> IDSes
>
>
> The idea that IDS's are black boxes which can be
> dropped in...and that there
> is some rule of
> thumb for their behavior...is one of the biggest
> driving factors in
> generating huge volumes of
> logs and false alarms.
>
> An IDS's job is to report when a defined security
> policy has been violated.
> How well has that
> policy been defined? How well have the sensors been
> configured to be aware
> of the policy and
> detect violations?
>
> The number of resources which need to be dedicated
> on a per-sensor basis is
> a direct function
> of the security policy that you've created ahead of
> time and how much effort
> you've put in to
> mapping your tools to it.
>
> In addition to the background information, you need
> to keep in mind that not
> all IDS's are
> created equal. One choice is *not* as good as
> another.  If my tool breaks
> down or doesn't
> provide me with information that I need, it's going
> to negatively impact my
> turnaround time.
>
> There might be guidelines which could be developed
> regarding analyst-sensor
> ratios, but not
> without a lot of surrounding context.  The tools and
> techniques are not yet
> standardized and
> operationalized well enough to provide easy (if any)
> statistics.  There is
> no evil bit that
> gets set in network traffic...
>
> I know you were probably looking for even generally
> applicable stats, but
> IDS management isn't
> as far along in it's business lifecycle as, say, a
> technical support call
> center or a desktop
> support environment...(IMO)
>
>
> -Jack Whitsitt
>
>
> > Everyone seems to be talking about the large
> volume of alarms and logs
> produced by IDSes.
> > Managing IDSes and dealing with false alarms seems
> to be an issue that all
> IDS vendor are
> > trying to address.
> >
> > Has any one of you seen any data on how many
> analysts (resources) are
> needed to manage IDSes
> > in enterprises?
> >
> > I am looking for a rule of thumb, something like
> this:
> > 1-5 IDS sensors - 1 Analyst
> > 5-15 IDS sensors -2 Analysts
> > 15-50 IDS sensors- 3 Analysts
> > 1 Analyst for every 30 additional IDS sensors.
> >
> > I will appreciate any feedback that I can get.
> >
> > Thanks,
> >
> > Kyriacos (Ken) Georgiades
> > Senior Director, Product Line Management
> > Top Layer Networks, Inc
> > Tel: 508 870 1300 x 231
> > Cell: 508 783 5988
> > Fax: 508 870 9797
> > Email: kgeorgiades () toplayer com
> > www.toplayer.com
---------------------------------------------------------------------------
> >
---------------------------------------------------------------------------
>
---------------------------------------------------------------------------
> ---------------------------------------------------------------------------

---------------------------------------------------------------------------
---------------------------------------------------------------------------