Re: NFR vs. RealSecure Recommendation

["Marcus J. Ranum" <mjr () nfr net>]

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
-----------------------------------------------------------------------------
Elliot Turner wrote:
> NFR utilizes 'n-code', which is considered configuration data, an
> attacker
> could subsequently disable all detection activities on the IDS host by
> simply
> changing or removing the 'n-code' files on the appliance hard disk.

That's conceivably possible, but it's a hell of a lot harder
than messing with a system that's got a full-blown operating
system on it. Since there are no file manipulation utilities
on an IDA you'd have to find something you could buffer overrun
and use raw system calls to rewrite config files. With the way
we configure things, if you just deleted the config files, you'd
actually generate a load of reported errors.

Anyhow, I sense a bit of sour grapes, Elliot. What does Mimestar
do? You run on Linux, right? So your users have to secure
Linux and then install your product? I can see why you'd want
to try to find flaws with our approach... :)

> 2). An attacker could modify system CMOS settings to bypass the CD-ROM
> entirely, booting from the hard disk.

When we lay out the hard disk, we don't even put a boot sector
on it. So you'd have to repartition it and make it bootable.
At that point, why bother? It'd clearly not look like an NFR
anymore. Also, you'd have to get a new boot block onto the
machine - kind of a trick without any executables or command
interpreters to work with.

> They could then install a
> trojaned kernel
> and file-system directly on the hard disk, thus skipping the NFR CD-ROM
> and completely compromising the machine.

They could also send paratroopers in to seize the computer
room at gunpoint and shoot holes in the hard disk. Which
would be every bit as obvious as replacing our kernel
with someone else's. Our kernel doesn't look or act like
a normal UNIX kernel. So you'd have to build your own
custom NFR kernel.

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.

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).

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.

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. ;)

> 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. :)

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