RE: comparison of NFR vs RealSecure - auto update -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
OK,

Let's go back one step, an IDS system should be well-architected that it 
is integrated into an existing ticketing system, sends traps, events and 
other such bells and whistles to a central network monitoring system, plus 
generate a ticket with possible escalation troubleshooting procedures for 
the monitor monkeys.

An IDS system should be part of an overall security architecture or 
integrated into an overall security architecture that is well-designed to 
that particular organization's needs.

/mark

"C.M. Wong" <wongcm () ep com my>
03/23/00 05:13 PM

 
        To:     <Mark.Teicher () predictive com>
        cc:     <ids () uow edu au>, <owner-ids () uow edu au>
        Subject:        RE: IDS: comparison of NFR vs RealSecure - auto update

My comments below... btw Mark, I got to scrutinize for your comments... ;)

 Guy Bruneau <bruneau () ottawa com>
> Sent by: root () cr717898-a rchrd1 on wave home com
> 03/23/00 04:10 AM

<snip>

> A way of avoiding the detection of the sensor(s) and monitoring
> station(s)
> would be to download the file to a workstation or server that is not
> related to the sensors(s) and perform the auto update internally. This
> could be accomplished in a similar fashion as the virus vendors
> (push-pull
> model) are presently doing. The new dat file is pushed to the customers'
> server and the users pull the new dat file. This could be incorporated 
in
> the IDS as an option for those who don't want their IDS to connect
> anywhere on the Internet.

> Push/Pull mechanisms have other problems as well.  Especially in the 
case
> of C/A Innoculan's virus updates.. Has anyone traced back the 
originating
> IP address of their update server.  One hint, it is not located in the
> United States, and the hostname does not appear to a C/A owned 
division..
> Hmm.. :)

I don't about you guys, but I'll never, never, let anything "push" into my
network unless PKI is involved with strong encryption. But even then you
have to trust the other party's security setup less their priv key gets
stolen etc.

> Guy
> Another thing Mark, in most org, there are a lot of lamers security
> conscious admins people. Even if the new vulnerabilities arrives in CDs,
> they're not gonna study the exploit in detail... but maybe study what 
are
> the consequences if deployed on their network (like generating huge 
false
> alarms or paging you in the morning etc). But even than, coming into the
> office at 9 am  to find out you have a full log of false alarms is 
better
> than getting one of your servers compromised and which you have no idea
> off
> (And let's just stick to network IDS, not host IDS or tripwire etc).
>
> If you have lamer security admin type people implementing your IDS, then
> there is something else that needs to be addressed instead of addressing
> the functionality of an IDS system. Architecting and Implementing an IDS
> system requires some system admin skills, maybe a little higher skill 
set
> than turning on the light in the computer room..

Again, Mark in my previous remark, I never implied lamer security admin 
are
implementing the iDS. In most cases the lamers are the are ones "taught" 
to
monitor and maintain the IDS. The experts are the one deploying, and
occasionally called in to "fix" matters. To me, the initial deployment and
configuration stage is important, just like firewalls. If you screwed-up 
at
this stage, there would be hell to pay as we all know. That's why I
sometimes like to deploy honeypots for "lamers" to see... or if they're
willing borrow the "hacking exposed" to them. :)

Rgrds,
Wong.