Re: Re: NFR vs. RealSecure Recommendation

[mark.teicher () networkice 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
HELP: Having problems... email questions to ids-owner () uow edu au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
-----------------------------------------------------------------------------
At 01:09 PM 9/15/00 -0400, Marcus J. Ranum wrote:

> Nobody who understands security will tell you that
> something can be perfect against every possible
> (no matter how ridiculously contrived) scenario.
> All I'm saying is that I believe the way we designed
> the IDA's operating environment is light-years ahead
> in terms of security _and_ convenience. Other
> systems (including yours, apparently) make the user
> worry about Linux security or NT security or Solaris
> security. Other systems make the user install a
> kernel, partition disks, install patches, etc ad
> nauseam. Other systems, when a hacker breaks into them,
> offers the hacker a comfortable operating environment
> complete with command interpreter, PERL, FTP and ssh.

Light years not really, the appliance concept has been around for many many 
years.. I recall that Digital Equipment actually designed an IDS in the 
late 80's using the same type of architecture that NFR is touting as Light 
Years ahead of it's time, but that is another discussion altogether..



> Aren't you carrying sour grapes a bit far, Elliot?
> Can you explain how your approach is better than ours,
> security-wise or management-wise?
>
> > > our install process. NFR can be installed and
> > > managed by a secretary instead of someone
> > > who makes $80,000/year.
> >
> >Okay, let's seriously think about this.  Installation, sure.
> >But anyone with a decent amount of IDS experience knows
> >that any current system, NFR included, cannot be managed
> >by a mother who has little to no computer experience (not to
> >mention security experience).

Installing NFR IDA was not a trivial task, it required some UNIX and TCP/IP 
knowledge.  It also required an understanding of how to insert a NFR IDA 
into various networks and actually seeing traffic be detected by both the 
detector and the Console.



> Sure, but you've missed the point.
>
> The way our customers deploy NFR, they have an NFR central
> in a secure location, usually a NOC. The people who manage
> the NOC systems and the central are typically security
> savvy administrators. But, with our super-easy way of
> installing an IDA, it's not necessary to send those savvy
> administrators out to install the sensors. Anyone can
> install a sensor and have it talking back to a NOC in
> minutes. So you can use your staff most effectively.


Administrative overhead is actually in designing carefully constructed 
N-Code filters.. :)



> When you configure a central to recognize a new IDA
> one of the things you can do is have it write a configuration
> floppy disk that contains all the settings the IDA will
> need to talk to the central. If the floppy is in the IDA
> when it boots the first time, it'll pull the configuration
> files directly in, without requiring any user intervention
> at all (except for where it asks "are you sure it's OK to
> erase the hard disk and use it for NFR data?") So you
> could conceivably just mail someone the floppy and the
> CDROM, tell them "put these in a machine, plug it in
> and turn it on" and wait for the data to appear at your
> NOC. Now, that, my friends, is slick. ;)

This is different from how NFR 4.0 worked.



> >IDS solutions generate lots of data, and require knowledge
> >of deployment in order to mesh in with existing network
> >hardware configurations.
>
> See above.
>
> >Even with a good attack description/resolution database,
> >knowledge of the network is required to know whether or
> >not certain attacks were successful or merely "door-knocks".
> >I doubt anyone's mother knows if they have the version of
> >IIS that was patched against the .HTR overflow vulnerability
> >installed on their network.  They probably don't even know what
> >IIS is.
>
> You've fallen into the mindset-trap of most first
> generation ID systems. The person who installs a system
> does not have to be the same as the person who manages
> it. Who, in turn, does not have to be the same person
> who consumes its data. We never assume that the people
> processing the data from an NFR are ignorami. We're
> just saying we made our sensors so that ignorami can
> install them, so that your valuable administrators can
> do what they're good at, instead of wasting time running
> around installing NT or Linux or Solaris and locking
> them down and patching them, etc.
>
> ><snip>
> >While this message may sound critical, it's not entirely intended
> >to be as such.  I think NFR has done some interesting work in the
> >intrusion detection field.
>
> It's OK to be critical, Elliot. We welcome these kind of dialogs
> with other practitioners in the field. On the other hand, let
> me hold you to a standard of intellectual honesty. While you're
> trying to poke criticisms at _our_ solution, you're manifestly
> failing to tell anyone how your approach is better. So you come
> off a bit as sour grapes, don't you think?
>
> >However I also believe that there is no current perfect solution,
> >in regard to security of an appliance host OS or management
> >(IE: The "mom" factor).
>
> Nothing's ever perfect; anyone with any integrity will know
> that and admit it. All a security product designer can do is
> build the best stuff they know how to build - that's what
> we do. Bluster aside, I think we've raised the bar for
> manageability and security of intrusion detection systems.
> Y'all will catch up eventually, but by then maybe I'll have
> thought of something better than the IDA. :)

Manageability is still an issue and also how to deploy a Network based IDS 
in a heavily saturated network, without the IDS Console falling over or the 
the IDS detectors running out of disk. :)

/mark



> mjr.
> -----
> Marcus J. Ranum
> Chief Technology Officer, Network Flight Recorder, Inc.
> Work:                  http://www.nfr.net
> Personal:              http://www.ranum.com