Re: R: IDS evaluation
From: greg.jensen@attbi.comDate: 08/26/02
- Previous message: Mike Lyman: "RE: How to measure 'status' of IDS Deployment"
- Maybe in reply to: Gianpiero Porchia: "R: IDS evaluation"
- Next in thread: David W. Goodrum: "Re: R: IDS evaluation: NFR Security"
- Reply: David W. Goodrum: "Re: R: IDS evaluation: NFR Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: greg.jensen@attbi.com To: "Gianpiero Porchia" <gianpiero.porchia@atsweb.it> Date: Mon, 26 Aug 2002 17:38:07 +0000
I think those of you who know Marcus Ranum (NFR
Founder/creator) know his background. He was a driving
force behind the creation of the Gauntlet Firewall and
FWTK, however, in the world of firewalls, the old
Gauntlets had one major problem, that NFR suffers with
today.
That is...they are highly sophisticated, capable,
strong, but the running joke (even internally on the
old Gauntlet dev teams) was, you had to ship an
engineer in the box. NFR is no different. Good
solution for shops that have the additional staff, and
the extra bandwidth (time/money/people) to put towards
that project. If you are looking for an "out of box"
solution, and one that you can show managment an ROI,
one that has great reporting, ease of use, and
simplicity to manage...NFR is not strong here.
To sum up...it is for the "binary-type" who want to dig
into the nuts and bolts. Most security folks are
working under limited budgets, strapped-for-employee
staffs, and don't have the luxery to use such a
product, as apposed to the dozens of other products
that are a bit closer (though not perfect) to the "out
of box" concept.
-GJ
> Hi,
>
> In my company, we are using the NFR NID. I can briefly show you some basic
> features of this system:
>
> - the whole system is a 3-tier architecture:
> 1) Network sensor
> 2) Distribuited Data Broker (DDB), DBMS
> 3) System Administration Console, Data Analysis Tool
>
> 1) Network sensor: analyze the network traffic, using both stateful pattern
> matching and protocol anomaly detection. You can modify the detection
> algorithms, or you can write your own, using N-code, an event-based language
> (a cross between C and PERL). The sensor send every alert to DDB, or spool
> them if the DDBs are unavailable.
> There are 4 flavours of network sensors:
> a) 320D: two giga (for HA), and a 100 interfaces, for sniffing + 100 for
> management
> b) 320S: one giga and a 100 interfaces + 100 f.m.
> c) 315: two 100 interfaces + 100 f.m.
> d) 310: one 100 interface + 100 f.m.
> Every sensor is selled as an appliance, based on a dual CPU architecture.
> The OS is an hardned FreeBSD, running on a CD (tamper-proof). Only the 310
> is available as software only.
>
> 2) DDB: collect the datas coming from the sensors, and send the
> configuration changes back to them. It stores the data in its own DB, and
> can send them to other DBMS (using ODBC).
> It runs on Solaris or Linux boxes.
>
> 3) System Administration and Data Analysis Tool: you can manage the whole
> DIDS from one or more of this stations. You can create user groups and grant
> them to analyze only the alerts, the manage the system, to modify the
> detection alghoritms etc. Using the Data Analysis tool, you can allow your
> forensics team, to study the data collected, using complex correlation
> methods, and to split them, example showing only the datas for Web
> Forensics, or for System Forensics.
> This tools run on Windows box.
>
> More on www.nfr.com
>
> Personal Opinions
> ------------------
>
> I think that the strenghts of the system are:
> a) Good performance with heavy weight traffic (up to 800MB), tested in our
> labs
> a.1) Low ratio of false positives
> b) Simple to deploy and to manage in a wide enviroment
> c) Highly Customizable, you can modify or write your own detection
> algorithms (example I've writed some network testing backend)
> d) Simple to tune, you need to modify only some enviroment variables
>
> The weaknesses:
> i) The reporting system, is more technical oriented than management
> oriented, ie actually you don't have shining reports, but you have all the
> data that you need for forensics and for incident handling.
> ii) The management interface, sometimes is hard to handle.
>
> If you need other informations, you can contact me.
>
>
> Ing. Gianpiero Porchia
> Security Engineer
> ATS - Advanced Telecom Systems
> Designing, Testing, Managing Network Quality
>
> Via Salgari, 17 - 41100 Modena - ITALY
> Tel +39 059 821332
> Fax +39 059 821492
> E-mail: gianpiero.porchia@atsweb.it
> Web site: http://www.atsweb.it
>
>
> -----Messaggio originale-----
> Da: Elijah Savage [mailto:esavage3@csc.com]
> Inviato: mercoledi 21 agosto 2002 22.04
> A: focus-ids@securityfocus.com
> Oggetto: IDS evaluation
>
>
> I am coming to you experts for a little help. It has come time to renew our
> maintenance contract with cisco we have the old netranger product. Well my
> company wants me to do a review of 3 products of my choice to see what
> other products may provide us a better solution that what we currently
> have. We have 12 IDS sensors currently. Can you all recommend 3 products
> that will be worth my time to take a look at?
>
> I would greatly appreciate any answers.
>
- Previous message: Mike Lyman: "RE: How to measure 'status' of IDS Deployment"
- Maybe in reply to: Gianpiero Porchia: "R: IDS evaluation"
- Next in thread: David W. Goodrum: "Re: R: IDS evaluation: NFR Security"
- Reply: David W. Goodrum: "Re: R: IDS evaluation: NFR Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|