Subject: REPOST: Comments on draft 4 requirements

From: "Michael J. Slifcak" <[email-masked]>
Date: Mon, 19 Feb 2001 10:27:23 -0500

Sorry for the direct post to you.

Still have problems with idwg-public mail list
Message was sent to [email-masked] 16 Feb about 4 PM EST
Has not appeared in archive.
Have not seen e-mail from idwg-public.

Suggested edits in "patch" form.

 -Mike Slifcak

I had sent comments to idwg-public Friday afternoon.
They have not appeared in e-mail to me, nor have I
seen any traffic on the idwg-public list.

Here again are my suggested edits, with the essential
points explained.

1. Minor spelling and phrasing changes.

2. IDMEF is a format, not a transport.

3. IDMEF requirement should not restrict to only TCP/IP network.

4. Change tool to analyzer to clarify meaning.

5. Update original author's address/phone number
   (Place of employment remains the same).

Best Regards,
-Mike Slifcak, Internet Security Systems, Inc.

--- ../draft-ietf-idwg-requirements-04.txt	Tue Jan 30 18:04:18 2001
+++ draft-ietf-idwg-requirements-04.txt	Fri Feb 16 12:42:15 2001
@@ -128,10 +128,10 @@
    different ID systems to be integrated more readily. ID research
    should migrate into commercial products more easily.
 
-4) We feel that, in addition to enabling communication from an ID
-   analyzer to an ID manager, the IDMEF notification system may also
-   enable communication between a variety of IDS components. However,
-   for the remainder of this document, we refer to the communication as
+4) In addition to enabling communication from an ID analyzer to an
+   ID manager, the IDMEF notification system may also enable
+   communication between a variety of IDS components. However, for the
+   remainder of this document, we refer to the communication as
    going from an analyzer to a manager.
 
 All of these reasons suggest that a common format for reporting
@@ -306,7 +306,7 @@
 
 The diagram above illustrates the terms above and their relationships.
 Not every intrusion detection system will have all of these separate
-components exactly as shown. Some ID sytems will combine these
+components exactly as shown. Some ID systems will combine these
 components into a single module; some will have multiple instances
 of these modules.
 
@@ -339,7 +339,7 @@
 
 For the purposes of this document, we assume that the analyzer and
 manager are separate components, and that they are communicating 
-pairwise across a TCP/IP network.  No other form of communication 
+pairwise across a communications mechanism.  No other form of communication 
 between these entities is contemplated in this document, and no other 
 use of IDMEF alerts is considered.
 
@@ -426,7 +426,7 @@
       implementations.
 
 4.2.1 Rationale: Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6 
-      environments are expected to exist within the timeframe of IDMEF 
+      environments are expected to exist within the time frame of IDMEF 
       implementations, the IDMEF specification MUST support IPv6
       and IPv4 environments.
 
@@ -481,7 +481,8 @@
 
 6.  Communications Mechanism Requirements
 
-6.1   The IDMEF MUST support reliable transmission of messages.
+6.1   The IDMEF communications mechanism MUST support reliable transmission
+      of messages.
 
 6.1.1 Rationale: IDS managers often rely on receipt of data from IDS
       analyzers to do their jobs effectively. Since IDS managers will
@@ -489,9 +490,9 @@
       messages be delivered reliably.

-6.2   The IDMEF MUST support transmission of messages between ID 
-      components across firewall boundaries without compromising 
-      security.
+6.2   The IDMEF communications mechanism MUST support transmission of
+      messages between ID components across firewall boundaries without
+      compromising security.
 
 6.2.1 Rationale: Since it is expected that firewalls will often be
       deployed between IDMEF analyzers and their corresponding managers,
@@ -527,8 +528,8 @@
       in manager and analyzer deployment.

-6.3   The IDMEF MUST support mutual authentication of the analyzer and
-      the manager to each other.
+6.3   The IDMEF communications mechanism MUST support mutual authentication
+      of the analyzer and the manager to each other.
 
 6.3.1 Rationale: Since the alert messages are used by a manager to
       direct responses or further investigation related to the security 
@@ -541,9 +542,9 @@
       authentication process might be subverted or misconfigured.

-6.4   The IDMEF MUST support confidentiality of the message content 
-      during message exchange. The selected design MUST be capable of 
-      supporting a variety of encryption algorithms and MUST be 
+6.4   The IDMEF communications mechanism MUST support confidentiality of
+      the message content during message exchange. The selected design MUST
+      be capable of supporting a variety of encryption algorithms and MUST be 
       adaptable to a wide variety of environments.
 
 6.4.1 Rationale: IDMEF messages potentially contain extremely sensitive
@@ -612,7 +613,7 @@
       attempt to confuse the receiver. It is desirable that the IDMEF
       communications mechanism resist such message duplication.
 
-6.8.2 Scenario: At attacker penetrates a network being defended by an
+6.8.2 Scenario: An attacker penetrates a network being defended by an
       IDS. The attacker suspects that an IDS is present and quickly
       identifies the encrypted traffic flowing between system components
       as being a possible threat. Even though she cannot read this
@@ -779,17 +780,17 @@

 7.10   The IDMEF message MUST be able to contain the identity of the 
-       implementer and the tool that detected the event.
+       implementer and the analyzer that detected the event.
 
 7.10.1 Rationale: Users might run multiple intrusion detection systems
        to protect their enterprise. This data will help the systems
-       administrator determine which implementer and tool detected the 
+       administrator determine which implementer and analyzer detected the 
        event.
 
-7.10.2 Scenario: Tool X from implementer Y detects a potential
+7.10.2 Scenario: Analyzer X from implementer Y detects a potential
        intrusion. A message is sent reporting that it found a potential 
        break-in with X and Y specified. The operator is therefore able 
-       to include the known capabilities or weaknesses of tool X in his 
+       to include the known capabilities or weaknesses of analyzer X in his 
        decision regarding further action.

@@ -901,7 +902,7 @@
 
 7.16.1 Rationale: The IDMEF cannot assume a certain clock granularity on 
        sensing elements, and so cannot impose any requirements on the 
-       granularity of the event timestamps. Nor can the IDEF assume that
+       granularity of the event timestamps. Nor can the IDMEF assume that
        the clocks being used to timestamp the events have a specified 
        accuracy.
 
@@ -1015,10 +1016,9 @@
 
      Mark Wood
      Internet Security Systems, Inc.
-     6600 Peachtree-Dunwoody Road
-     300 Embassy Row
+     6303 Barfield Road
      Atlanta, GA 30328
-     Phone: +1 (678) 443-6147
+     Phone: +1 (404) 236-2600
      E-mail: [email-masked]