Subject: Comments on Your Comments

From: Mike Erlinger <[email-masked]>
Date: Tue, 20 Feb 2001 07:10:19 -0800

Michael

Thanks for your comments.  I believe all, but one them, are incorporated
in a new version which i will officially post to the ID repository today.

The one i have trouble with concerns the reference to communication
across a TCP/IP.  I believe that for IDWG, the communication of the
manager and analyzer occur across TCP/IP.  The analyzer may get its
input in some other way via some other protocol, but for us the manager
and analyzer communicate over tcp/ip.  if you disagree, please continue
to comment....

thanks again.

mike

I have used #### to delineate each comment and my response follows
Comment:

####
The original author's name and company remain the same,
 although the address and telephone number have changed.

Comment: Made the changes you suggested.

####
Opinions: This document delivers an adequate requirements message.
          It isn't perfect, and that's OK.
Comment:  Agree...

          Efforts spent completing the other documents
             should be the focus of this working group.
Comment:  Agree...

          What concerns me most is the apparent lack of developing
             consistent names for Events and Alerts.          
Comment:  Agree. It is a lot clearer in the new document.  I believe
          things are consistent in terms of 'Events' and 'Alerts'.
          But of course if anyone sees inconsistencies, please let
          me know.

A. #####

Section 3.1, Item 4  Starts the sentence with a vague phrase.

Please change : "We feel that, in addition ..."
           to : "In addition ..."

Comment:  Removed the starting phrase, which I had changed in an earlier
         version.

B. ##### Are there only TCP/IP networks  ?

Under "Architectural Assumptions", I believe specifying a TCP/IP
network for communication is wrong, for reasons identified in
Section 7.6.

Please change : "across a TCP/IP network."
           to : "across a communications mechanism."

Comment:  IDWG is specifying 2 things a format and a protocol.  While
7.6 allows different address types, the communication mechanism (protocol)
is limited to tcp/ip.  Thus, no change.  This still allows section 7.6,
sensors watching 'things' that are not necessarily network hosts/nodes
as we know them. IDMEF must then be able to handle such addresses

C. ##### IDMEF is not a transport

Four of the statements that begin "The IDMEF MUST" in section 6,
"Communication Mechanism Requirements", do not clarify this.

One can add the missing text, which would force minor reformatting.
The new statements would begin :
6.1   The IDMEF communications mechanism MUST ...
6.2   The IDMEF communications mechanism MUST ...
6.3   The IDMEF communications mechanism MUST ...
6.4   The IDMEF communications mechanism MUST ...

Comment:
This has been reworded to talk about IDP, IDMEF Communications Protocol.
I believe that the new version is correct in that all its former references
to IDMEF communications mechanism now refer to IDP.

D. ##### Tool == Analyzer

The word "tool" appears only in Section 7.10.  As it is not defined,
it introduces confusion in this document. If you substitute "tool"
with "analyzer", the intent is clear.

Comment:
Agree.  Change made.

##### 
 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.

Comment:
Fixed, ID system is now IDS, while ID systems is now IDSs

##### 
 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.

Comment:
See above.

##### 
 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.
 
Comment:  Done

##### 
 6.  Communications Mechanism Requirements
 
-6.1   The IDMEF MUST support reliable transmission of messages.
 
-6.2   The IDMEF MUST support transmission of messages between ID 
-      components across firewall boundaries without compromising 
-      security.
 
-6.3   The IDMEF MUST support mutual authentication of the analyzer and
-      the manager to each other.
 
-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 

Comment:
 I believe all these are now changed.

##### 
-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

Comment:  For the longest time, i missed this...see if you can see the
       change.  i have now made it.....:-)

##### 
 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.

Comment:  Tool changed to Analyer...

##### 
 
 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.

Comment:  Done.

##### 
      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]
Comment:  Done.

-- 
mike erlinger, professor computer science
www:      http://www.cs.hmc.edu/~mike
email:    [email-masked]
smail:    computer science dept harvey mudd college,
          301 E. 12th Street, Claremont, CA, 91711 
909-621-8912,   FAX: 909-621-8465

---

From: "Michael J. Slifcak" <[email-masked]>
Date: Tue, 20 Feb 2001 10:23:52 -0500

Mike, It's a pleasure to be of some service.
I have no further comment on the IDWG requirements document.
Regards,
-Michael Slifcak, Internet Security Systems, Inc.

> and analyzer communicate over tcp/ip.  if you disagree, please continue
[SNIP]