Re: Re: comparison of NFR vs RealSecure

[mjr () nfr net (Marcus J. Ranum)]

I'd like to use Carric's email as a vehicle to clear up some
misconceptions about our products. ;) Because of the research
version we used to make available, a lot of users don't quite
understand NFR's products and/or technology strategy. Hopefully
this will help!

Carric Dooley wrote:
> NFR has a "roll your own" approach.  Once you learn the scripting language, you can react as soon as you know about 
> the exploit without waiting for an update.  You can also get your initial package of signatures from L0pht Heavy 
> Industries.

When you buy a copy of the Intrusion Detection Appliance(tm) it
comes with a complete set of IDS filters on the CDROM. The filters
were developed by L0pht under contract, and are much much much
more complete than the "freebie" ones on their web site. It's hard
to count the number of "signatures" in the IDA's filter set because
it looks not only for the usual static signatures, it also looks
for protocol errors - stuff like unusually long file names in FTP
command streams, etc. Those errors may indicate an attack in progress
and may detect previously unknown attacks through their second order
effects. In total, the 4.11 IDA includes checks for about 600-800
(depending on how you choose to count) various errors and attacks.

So, you don't have to roll your own filters unless you like to.

This is an important point. Unlike other products, you can write
your own logic, or modify ours. It's also nice because with the
flexibility of a true programming language you can respond very
quickly to new stuff. We released a detector for Trin00/tfn within
about 8 hours of the CERT alert. The other guys will have to release
a new version of their software in a couple months - not fast enough.

Lastly, the flexibility of a programming language means you can
get way "outside the box" with the NFR. One of our customers uses
an IDA to generate web site statistics, to look for the number of
404 messages (and URLS that generated them) as well as to generate
statistics about which cgi-bin scripts took longest to respond to
the client request. They parse out the URL from the request, see
if it's to a cgi-bin, start a timer, stop the timer when they
see a response from the server, and graph the latency. Oh, yeah,
and they _also_ look for attacks against the site while they're
at it.

> I am not sure if NFR ties into FW-1...

At present we don't interface to firewalls or routers. We've got
some stuff coming that does a bit better than that, but we decided
to remain a passive monitor until we knew how to do it "right"
in a way that wouldn't let a bad guy spoof us into becoming a
denial of service mechanism.

> You can set this up distributed as well.. it requires either a Solaris or Linux management server and then a windows 
> client to access and manage the system as well as view the logging and alerts (the engines are essentially a PC that 
> you boot off their CD and configure with a public and mgt. interface).  I am not particularly fond of the interface 
> and it requires a steeper learning curve than NFR.

NFR was built from the ground up to be a client/server system.
We didn't include any of that in the "research" version to help
further distinguish our commercial offering from the research
codebase. Briefly, here's how it works:
         - The backend databases of the IDA are automatically replicated
         to a central server at selectable intervals. The replication
         is performed over a bidirectionally challenge/response
         authenticated encrypted link.
         - Part of the replication process includes a time sync
         operating, in which the IDA adjusts its time based on the
         central's time. (NTP was overkill, relies on too many
         external systems, and our approach ensures that the NFRs
         all keep time with eachother)
         - Configuration files, including filters and backend
         parameters are mirrored from the central NFR to the IDAs.
         This is done over the same encrypted/authenticated link.
         So, if you want to install a filter and have it automatically
         "take" on all the remotes you need to only update one place.
         No DLLs to swap, no installshield wizards, no file moving,
         it's all automatic, integrity checked, and encrypted.
         - If central and remote fall out of communication long
         enough (settable) it begins generating alerts. When the
         communication is re-established, the data is forwarded
         normally.
         - Alerts are just another form of data record (albeit
         high priority) that just get forwarded to the central.
         - You can query off the remote, or the central. The central
         lets you browse its data from multiple remotes.

> > - available API (integrating own type of alerts, actions, ...)
> You can write custom progs kicked off by keyed events.. i.e.
>
> if this event happens, execute "myprog.exe"

When NFR went to the appliance architecture, we decided to go
beyond "hardening the operating system" (as many vendors do) and
built our own embedded configuration of an operating system. It
happens to be a version of UNIX, but basically all we use are
the bootstrap loader, the kernel/file system, packet capture
interface, and process scheduler. All the code in user space,
from init up (with the exception of fsck) is NFR-developed. So
unlike a "hardening" process, in which stuff is stripped, we
did a "build" process in which we started from zero and added
what we wanted. There's no password file. There's no shell. No
perl. No mailer (except our micro smtp deliverator). No inetd.conf.
No inetd. No telnetd. Nothing to manage. No NT. No NT security
holes. No mandatory service packs. It's a brick that only knows
how to run NFR.

So, if you want to execute mprog.exe - you can't. It's not allowed. ;)
The O/S is burned into plastic...

You can, however, do integration at the central. If you want to
have alerts queued to your own thing, you can. If you want to
bulk export/import into a database, the data is all there at
the central.

> NFR is much cheaper (I want to say something like $3500/engine), but I could be totally wrong.. I know Mr. Ranum is on 
> this list and I am sure he would be happy to discuss price with you. 

We are raising our prices somewhat because some people insist on
believing that if they pay more for an IDS, they must be getting
more for their money. Obviously, that's wrong, but we've nudged
our prices up a bit. We used to be twice the IDS at half the
price. Now we're a bit more than half the price. ;)

>  It is also EXTREMELY easy to deploy and manage.  Like I said, you can write your own sigs with the custom scripting 
> language, and all you need to have a few decent PC's with a fairly standard config for your engines (PII, 128MB, 4G 
> HDD, 3C905, etc.).  It boots right off the CD and within minutes you are up and running.

My mother installed an NFR IDA in 13 minutes. I did have to
explain to her what an IP address was, and why she should enter
one, but all in all it was pretty painless for her. She's a very
smart lady, of course, but she's not exactly a networking expert.
(She's a musicologist, in case anyone cares - the world's foremost
expert on certain French court musicians in pre-revolutionary
France)  I don't think she'd be able to install Solaris or NT
without expert guidance. Consider this, when you decide on your
IDS. The total cost of ownership of NT and Solaris-based IDS
is much, much, much higher than our approach.

We didn't have her install our 4.1.1 upgrade when that came out.
That was too easy to bother her with. All you do is eject the
CDROM, put the new one in, and reboot. :)

> In all, I have to say I like them both, but they suit different sets of needs.  If you are smaller .com company that 
> is $$ conscious, and you have a couple "coder/hacker linux head" types on staff, NFR is a good fit.  If you are 
> Nations Bank or Pepsi, I think ISS is the logical choice.

Obviously, I've got to disagree, here. If you're Nations Bank or
Pepsi you've presumably got better things to have your network
admins doing than burping and feeding a bunch of dedicated
machines running NT. Not only does it take hours to install
them, but you've got to run around installing service packs
whenever a new Windows vulnerability crops up.

We designed NFR to operate in a "lights out" environment, with
zero skill required to install the remotes and manage them. I know
that organizations like Nations Bank and Pepsi have CIOs that
understand total cost of ownership, cost of management, and
roll-out and lifecycle costs. If you add the hidden costs of
competing products (NT: $?, extra ram for NT: $?, 1 hour/platform
of systems analyst at $100,000/year salary, maintenance, etc)
you'll realize we're a whole lot cheaper in addition to being
a whole lot easier.

I think you've got the impression that NFR requires a lot of
coding expertise - that's not true unless you _want_ to stretch
past the normal limits of an IDS. 

All I can say is give the IDA a try! All you've got to lose is
your preconceptions. IDS doesn't need to be rocket science,
unless, of course, you _enjoy_ pain.

mjr.
--
Marcus J. Ranum
Chief Technology Officer, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr