Intrusion Detection Systems mailing list archives

Sharing Information [Was: BlackICE IDS]


From: jflowers () hiverworld com (John S Flowers)
Date: Mon, 06 Dec 1999 20:29:15 -0800



[Really long stream of consciousness message follows]

In the spirit of testing and cooperation, it would be nice if the
vendors would provide a complementary copy of their technology to their
"competition."  That way, we could all shrug off the facade of guessing
what each vendor product does and actually admire each product in
action.  It would also be nice if we had some standardized traffic that
we could use as test cases for different network conditions.  

I'd be willing to sign an agreement stipulating that Hiverworld "not say
anything negative about any product that was being evaluated."  We're
really trying to meet the needs of the Customer -- first and foremost.
We've even recommended RealSecure, Dragon or NFR (mostly NFR) to some
of our more technically savvy clients as a better solution for their
specific requirements.  I've seen NFR do this as well.

Of course, getting us [IDS/Scanner vendors] to share information with
one another is probably pure fantasy, as I realize that many of the
larger companies are going to take advantage of the hospitality of us
small fellows and use the information gathered as fodder for the
marketing canon against us. [and Ranum thinks he's a cynic ;) ]

But then, this is a technical list, right?  Maybe I should step up first
and offer to give people a sample of our risk management technology for
their network?  If our IDS was finished, I'd probably offer a demo
version of that as well.  But, I guess I have to answer to the board (at
Hiverworld) sometime and I'm sure that they're having heart attacks at
the mere prospect of this. [luckily they don't read the IDS list] I
know that NSW [aka Ron Gula] already provides a downloadable version
of Dragon -- but I don't think that this helps [us] answer the really
tough questions about having the right approach for the Customer.

I should also point out that the packet capture engine is the least
interesting thing about our future products.  We're pretty much in
the space of risk management, which specifically targets a solution
for assigning a vulnerability risk score to the customer network
environment, providing a technology solution road map, helping the
Customer perform policy enforcement for their environment and risk 
reporting capabilities. I'd much rather see us partner with a 
strong player in the IDS space than make the packet capture engine 
a part of our core technology. [we're kind of a think tank that's 
actually managed to produce consumer products]

In an attempt to create the best solution, I've been speaking with
some of our clients about placing a capture program on their network
for a few weeks and using the information gathered as a test case
for what they consider to be 'normal' network traffic.  [Remember, our
IDS (aka ARMOR) isn't officially out yet]  The client response has
been very positive, as most of our clients are very willing to assist
us in putting together a product that will fit their specific needs.
Also, the fact that many of our clients are Class B or greater networks
is very helpful, since most of them have 40-50Mbit sustained traffic
across the more active parts of their network.

At any rate, I do think that it is important for us -- as the producers
of technology and the people that are shaping this industry -- to be
more forthright with one another in sharing real information about how
our products work and what customers can expect from our technology.  I
for one am a little annoyed at the amount of disinformation (aka FUD)
that's spread throughout the industry with regard to security
technology.  I'd also be the first person to stand up and say, "now,
wait a minute" when I thought that someone was misleading a customer --
even if that person were on the Hiverworld sales team.

One thing I'd love to see:  
A standardized Scoring System for vulnerabilities.  That way, we can all
agree on which vulnerabilities are more significant and why.  Or, we
could use this scoring system as a way of allowing the customer to
interact with an established methodology for obtaining vulnerability
risks from a vendor product.

Imagine, an industry standard way of evaluating attacks that had the
approval/endorsement of NFR, NSW, NetworkICE, Hiverworld [et al].  I'd
even be willing to dedicate some of our initial thoughts on the subject.
I feel that having the vendors agree to something, as a group, is a 
much stronger position than having a 3rd party come in and place some
arbitrary standard on us, when the 3rd party probably doesn't under-
stand the security space nearly as well as we do (CVE not mentioned).

P.S. We already have a scoring system in place, as do many vendors.  I
just think that the idea of a unified system for scoring vulnerabilities
is a much stronger way for everyone involved to agree on alerts and
other notification thresholds.  Maybe we should make our "Hiverworld
Scoring System White Paper" a document that we share with people other
than our customers.

"Marcus J. Ranum" wrote:

Greg Shipley writes:

2. I would encourage anyone who is doing testing to get as close to REAL
traffic as possible.

As a vendor, let me comment that Greg's 100% right! We tell our
customers the same thing. You gotta see what'll work in your
live environment because it's going to be different than a lab.
You might install an IDS that does reassembly and state tracking
and discover that it doesn't work right because your internal
routing is messed up (accidentally or deliberately). You might
discover all kinds of weirdnesses that would never appear in a
contrived lab environment - some good, some bad.

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

-- 
John S Flowers                   <jflowers () hiverworld com>
Chief Technology Officer         http://www.hiverworld.com
Hiverworld, Inc.               Enterprise Network Security
Network Forensics, Intrusion Detection and Risk Assessment



Current thread: