OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: RE: IDS: Re: comparison of NFR vs RealSecure -reply
From: Mark.Teicherpredictive.com
Date: Tue Mar 21 2000 - 15:44:45 CST

FAQ: See http://www.ticm.com/kb/faq/idsfaq.html IDS: See http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html HELP: Having problems... email questions to ids-owneruow.edu.au NOTE: Remove this section from reply msgs otherwise the msg will bounce. SPAM: DO NOT send unsolicted mail to this list. USUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au --------------------------------------------------------------------------- ---

One more time, if one has deployed ISS RealSecure, there is a check called REAL_SECURE_KILL,  this check basically detects if another organization has misconfigured their own ISS RealSecure IDS system, it basically looks for REAL SECURE connections.  Hmm, very interesting, in that packet there is whole bunch of information that provides the other organization details regarding their customer id and version number of ISS RealSecure.  So if auto-update were to be deployed, guess what, an administrator who is watching ISS RealSecure events, see a Real_SECURE_KILL fly by the wire, guess what, you know have the customer id, the version number and the patch that ISS just sent.  OK, you might not able to see into packet since it is encrypted via SSL, so what,.  You know have the ISS external IP address and the External Interface to the organization running an IDS system.  That is more than enough information a would be kiddie scripter needs to draw up a nice little crayola crayon map, and start thinking about an approach in attacking the particular systems identified.  Better yet, the would be attacked might pick up a copy of "Hacking Exposed" read a few chapters about defeating IDS systems and go all out.

 

So stating that Auto-Update is nice feature to have, but certainly not a feature one is willing to implement if it could compromise an organization's security.

 

If a security architecture is designed and implemented correctly, a site will have proper procedures documented to deal with the onslaught of DDOS attacks out there, an organization should be ok until the new vulnerabilities are received from the vendor.  If an auto-update feature was added, think about the latency and possible amount of time, your IDS system can be vulnerable when it is performing it's update.  Scheduling the auto-update may avoid the previously mentioned issue, but not knowing what is really in the update worries me a lot.  

 

Having physical media, I can check out, play frisbee with, provides me with a lot more fuzzies than using InstallShield's ISV auto-updater.  

 

/m


Sent by: owner-idsuow.edu.au
03/20/2000 06:34 PM ZE8

To: <Mark.Teicherpredictive.com>, "Marcus J. Ranum" <mjrnfr.net>
cc: <idsuow.edu.au>, <owner-idsuow.edu.au>
bcc:
Subject: RE: IDS: Re: comparison of NFR vs RealSecure -reply


FAQ: See http://www.ticm.com/kb/faq/idsfaq.html
IDS: See http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owneruow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
USUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
---------------------------------------------------------------------------
---

> Ok,
>
> I agree with Marcus, the auto-update is not the greatest way of
> performing
> vulernability/attack updates for an IDS system.. The purpose of an IDS
> system is to monitor an organization's network in stealth mode.  If a
> would-be attacker/lurker is sniffing organization's networks, it would be
> entirely possible if you see a connection from ISS or NFR to a certain
> organization, that most likely that organization has an IDS system in
> place.  Kind of defeats the purpose of stealth mode.

I kinda of disagree here. I think auto-update is necessary. Still in stealth
mode, but the management console is automatically initiating a connection to
a NFR web site via SSL to download the patches. So it's just like any
internal users surfing the web. It would be a lot quicker than waiting for
the disc (or vendor patches) and in some org (mine for ex.) where a lot do
not understand what is a buffer overflow, I think auto-update is great. We
can still have stealth mode with auto-update if the agent/console deployment
is design correctly. The sniffing scenario would still not able to detect
deployed IDS... that is unless NFR gets hacked and the cracker gets to see
who is connected. ;)

> There is way to architect an auto-download method that it does not come
> across the wire directly into an IDS system.  Actually using PGP-MAIL or
> PGP-FTP works very well to an air-sealed/air-vacuumed, etc designated
> hardened host machine that is used exclusively for updates only.
>
> Then after scrubbing the update with all kinds of checksums and virus
> scanners, some sort of mechanism will unpack the update compare the
> signatures against the ones that are running, update the signatures that
> are outdated, add to the signatures that have been enhanced and discard
> the signatures that are rarely used based on the policy that has been
> customized for that particular organization, update the IDS system and
> voila.

Now the above is a method which I think is great.
.
<snip>
>
> NFR IDA will someday be hardware dependent and depending on the speed of
> the network (10mb, 100mb, FDDI), it will be able to capture the traffic
> with no problem.  On the other hand, capturing traffic that fast may burn
> through a few good NFR System jockeys attempting to correlate the events
> together, but that is an exercise for the organization.  As
> Marcus stated,
> there are plenty of Value Add Resellers of NFR that make the NFR IDS
> system a complete system


;). Yep, someday, guys. And thx for you earlier comments Marcus.

Rgrds,
Wong.