Re: a novice question. -large networks -reply

[Mark.Teicher () predictive com (Mark.Teicher () predictive com)]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
So let's go ahead and see if a commercial IDS application can be applied 
and what ruleset should be in place with a network this large.

There are couple of questions one must ask when trying to scale to a 
network this large.

How many sensors (i.e. engines, agents, etc)
How many operator consoles?
Where would the Main Console be located?
What types of alerts should be monitored?

/mark

Jackie Chan <blue0ne () igloo org>
03/26/00 04:07 AM

 
        To:     Mark.Teicher () predictive com
        cc:     CrumrineGL () state gov, ids () uow edu au, raj2569 () yahoo com, 
Valerie.Blanchard () predictive com
        Subject:        Re: IDS: a novice question. -large networks

Agreed.

blue0ne

On Sun, 26 Mar 2000 Mark.Teicher () predictive com wrote:

> OK,
>
> Try monitoring 120 fully saturated Class 'C's, 10 Class 'B's, and 4 
Class
> 'A's plus a population of over 5,000 remote users using various dial-up
> solutions with RADIUS, TACACS+, plus Security Dynamic Tokens, mixed
> operating systems, mixed router/gateway platforms varying from Proteons,
> Gator Boxes, DECBrouters, to Foundry boxes.  The network connectivity
> consisted of 4 OC12s, 16 T-3s, ATM and Frame Relay.  Network protocols
> went from one end of the spectrum to the other, plus some proprietary
> protocols that are way past their prime.
>
> In actuality, the network description above does exist and has been
> working quite well for more than a few years.  Various commercial IDS 
and
> homegrown monitoring tools have been sprinkled across the network over 
the
> years and it is to the point where monitoring of the network only 
requires
> two people to maintain.
>
> The monitoring of an IDS system requires more than just visual actuity,
> but requires some planning before to deployment and understanding what 
and
> IDS system can or cannot do.
>
>
>
>
>
> Jackie Chan <blue0ne () igloo org>
> 03/26/00 01:58 AM
>
>
>         To:     Mark.Teicher () predictive com
>         cc:     CrumrineGL () state gov, ids () uow edu au, raj2569 () yahoo com,
> Valerie.Blanchard () predictive com
>         Subject:        Re: IDS: a novice question. -reply
>
>
> MArk, I agree with all you said except the point that you preseumably
> missed from my last post.  I stated that teh monitoring of IDS should be
> analagoud to a cop walking a beat, not the IDS itself.  The people in
> charge of the IDS should gain such an intimate knowledge about the 
network
> inquestion, that they are aware of the slightest modification. Obviously
> the alrger the network monitored, the harder this is to become reality,
> but speaking from IDS monitoring experience, I have yet to find a 
network
> that can overwhelm me :)
>
> blue0ne
>
> On Sun, 26 Mar 2000 Mark.Teicher () predictive com wrote:
>
> > Yes, but most IDS systems do not have that check in their common
> > vulnerability/attack signature data files.  DG-UX is also another one
> that
> > is not covered by itself, but lumped together with the common Sendmail
> > DEBUG/WIZ attack vulnerability.  HP Sendmail and DG-UX implementation 
of
> > Sendmail have some nuances/vulnerabilities one must manually check 
for.
> > There are not many saavy sys mongers out there that still remember 
those
> > two vendor versions of Sendmail.  Trust issue??  Sendmail does not 
have
> a
> > switch to trust other servers, it appears that the other servers may
> have
> > other problems as well.
> >
> > DG-UX and HP Sendmail versions still exist, the last version I 
observed
> > was in 1997, at a large aircraft company.  The recommendation was for
> > Sendmail to removed from the system.  The server's purpose was not to
> > forward mail but to process large cad/cam drawings.  So the
> recommendation
> > was to remove the SendMail binaries and daemons from the system, 
instead
> > of pointing out to the customer, they should upgrade to the latest and
> > greatest version of Sendmail.
> >
> > This is where skills in working with an organization and understanding
> > each servers purpose and providing real life advice versus what the 
IDS
> or
> > Host Scanner provides.
> >
> > IDS is not analagous to a cop walking a beat, since a cop walking a 
beat
> > has the intelligence to make a real decision based on other factors 
than
> > what an IDS system may chirp about and what it is supposed to do when
> the
> > sysadmin sets a rule set/policy.  It really is an extra set of eyes 
for
> a
> > cop.
> >
> > /m
> >
> > Mark, in the case of HP Sendmail versions, or any sendmail versions 
for
> > that matter, you would be surprised how many of our core industries
> still
> > utilize old platforms that dont even use sendmail, but were part of 
the
> > default installation, and are still vulnerable to this day.  I for one
> > recently found an old version of a DG-UX implementation of Sendmail 
that
> I
> > would have thought didint exist anymore.  The funny thing was, it was
> the
> > last ditch effort, and it made the entire server farm available to me
> due
> > to trust issues.
> >
> >
> > This is where the security admin (if there is such a position) should
> > become intimate with the network in question, constantly scanning to 
see
> > if any new services have poped up on the network, and in an attempt to
> > squash any unused or vulnerable services.  The monitoring of IDS
> > definatley has to be anlagous to a cop walkin a beat.
> >
> > blue0ne