Subject: Re: [IDWG] 'ident' ambiguities & inconsistencies

From: Paul Sangree <[email-masked]>
Date: Fri, 02 Feb 2001 13:50:57 -0600

>> Maybe a 64-bit number composed of the concatenation of the ip
>> address and a random number?
>
>In something else I looked at, I thought IP address concatenated with the
>timestamp at which I had that IP address. I.e., lots of machines can have
>the same IP address ... but not all at once. Of course, you'll want IPv6
>support too.

How about using the MAC address to determine the default analyzer ident?  I'ts
(pretty much) guaranteed to be unique and should rarely change.  The ident
value should be assigned when the analyzer is initially configured, and should
never be changed under normal circumstances.
Paul

---------------------------------------------------------------
Paul Sangree <mailto:[email-masked]>
Active Audit Engineering
Cisco Systems, Inc.
12515 Research Blvd, AST03/B2-6
Austin, TX, USA 78759
voice: 512-378-1518
fax:    512-378-1250

---

From: "Sam Gorton" <[email-masked]>
Date: Mon, 5 Feb 2001 12:21:18 -0500

I see some problems, but I don't have a better solution.

IP address plus timestamp is a good idea if the system has a unique IP
address and knows the correct time.  Time skew probably won't be a problem
with DHCP, but it could cause problems eventually.  Some future IDS may use
non-IP methods to communicate, and it's also not clear to me how well this
will translate to IPv6.  (Disclamer:  I know jack about IPv6.)

The IP and/or MAC address wouldn't differentiate between multiple host-based
IDS installed on the same host.  There's also the problem of swapping
network cards and having to deal with a 'new' analyzer or analyzers.

I think the system should attempt to create globally unique analyzer
identifiers, in order to make it easier to track intrusions across multiple
sites and to share analyzer information with global repositories such as
CERT.  I think that the focus should be on identifying the analyzer itself,
instead of the host that it's running on or information about that host.
That way, post-processing can be written with the analyzer's role in mind,
rather than the physical system in that location.

--Sam Gorton
[email-masked]
([email-masked])

---

From: "Jimi Thompson" <[email-masked]>
Date: Mon, 05 Feb 2001 12:03:17 -0600

Am I the only one who sees disposable NIC's in our future???  With NIC's
dropping as low as $5 each anything dealing with the MAC address is obsolete.
Just toss it and buy a new one.

--
Jimi Thompson
Web Master
Link.com

"It's the same thing we do every night, Pinky."

---

From: Bill Dowling <[email-masked]>
Date: Mon, 05 Feb 2001 13:48:47 -0500

Would X.509 certificates provide a suitable means of differentiating
between analyzers, even when running on the same host?  This technique
could also be extended to ID monitors so that the source(s) of event
data could be verified as well.

--Bill Dowling

-- 
==================================================================
William A. Dowling                      E-Mail:    [email-masked]
Principal Information Systems Engineer  Voice:     (781) 271-7083
The MITRE Corporation                   
202 Burlington Road                     Fax:       (781) 271-2128
Bedford, Massachusetts 01730-1420           
==================================================================

---

From: Paul Sangree <[email-masked]>
Date: Mon, 05 Feb 2001 17:11:20 -0600

>Just toss it and buy a new one.

Changing the MAC address of an analyzer (e.g. due to replacing a NIC) shouldn't
present a problem.  The analyzer id is permanently assigned when the analyzer
is installed.  Changing the MAC address wouldn't cause the analyzer id to
change, even though the analyzer id was originally chosen based on the MAC
address at the time of installation.