Subject: Comments on draft-ietf-idwg-requirements-04.txt

From: Glenn Mansfield <[email-masked]>
Date: Fri, 26 Jan 2001 15:22:37 +0900 (JST)

Hi,
  Attached please find my comments on draft-ietf-idwg-requirements-04.txt.
  I have in general limited myself to concerns raised by IESG.
  The First part of the text refers to "High-level issues" raised by Vern 
  Paxon and the remainder of the text refers to 
  "draft-ietf-idwg-requirements-04.txt"
  My comments are preceded by a "==>". 

Cheers

Glenn

                                 Part-1.
                                 ======
1. High level issues:
   - The document presupposes that "activity", i.e., what gets reported
     via IDEF, directy reflects attacks or at least probable attacks.
     But it seems fundamentally more flexible for IDEF to encompass
     may not reflect an attack, but with additional context available
     more generic events, such as "user login", which by themselves
     to the Analyzer, may.
==> This comment has not been fully incorporated.

    - The examples ("Scenario:") are quite often unnecessary 
==> This is still a problem.

    - The MUST/SHOULD/etc keywords are generally only used for ....
==> This still remains

    - There should be explicit discussion of trust models.
==> This is still missing. It needs to be added to the assumptions 
==> section

    - It often isn't clear when requirements are referring to
      specifications or formats; or to products (implementations).
==> I feel that this is still a problem. 
==>
==> I think that we need to get the terminology straightened out.
==> In the text the definitions are unclear and terms [alert/event/
==> attack] are used interchangeably. 
==> My take is :
==>    
==>    Sensors look for Events that may have been caused by Attacks.
==>          [There are well known attacks and enumerations of attacks]
==>    Events are detected by a Sensor and reported to an Analyzer 
==>          [ According to the requirements doc. this is not 
==>             within the scope of IDMEF]
==>    Analyzers send Alerts to Managers.
==>
==>    IDMEF defines the format of the Alert
==>
==>    Corollaries:
==>      o An Alert is not an Event or an Event report 
==>      o An Alert it is not an Attack.     
==>      o IDMEF is not a communication mechanism. It is designed to be
==>        independent of the communication mechanism.
==>    
==>    Addendum:
==>      The IDWG also intends to define a communication mechanism
==>      for exchanging Alerts [IDMEF messages] 
==>
 
                                   Part-II
                                   =======      
            Intrusion Detection Message Exchange Requirements
                 <draft-ietf-idwg-requirements-04.txt>

1. Abstract

     The purpose of the Intrusion Detection Exchange Format is to
     define data formats and exchange procedures for sharing
==>  The "format" will define exchange procedures too ?
     information of interest to intrusion detection and response
     systems, and to the management systems which may need to interact
     with them.  This Internet-Draft describes the high-level
     requirements for such communication, including the rationale for
     those requirements where clarification is needed. Scenarios are
     used to illustrate the requirements.
   
[Deleted]
2. Conventions used in this document
     
==> Perhaps we can do away with this section [ s/MUST/must/ etc]
==> I think that was the intent of Vern's mail.

3.  Introduction

This document defines requirements for the Intrusion Detection Message
Exchange Format (IDMEF), which is the intended work product of the Intrusion
Detection Exchange Format Working Group (IDWG). IDMEF is planned to be
a standard format which automated Intrusion Detection Systems can use
for reporting events which they have deemed to be suspicious or of interest.

==> Note. IDMEF will be used for "reporting events". Compare with
==> diagram below.

 ________                   
|        |                   --------
| Data   |_________ ________|        |  __________
| Source |     Activity     |Sensor  | |          |
|________|         |        |________| | Operator |_______
                   |            |      |__________|       |
                  \|/         Event         A             |
              _____V___         |          /|\            |
             |         |        |            \            |
             | Sensor  |__      |         Notification    |
             |_________| Event  |              \         \|/
                   A      |     V_________       \         V
                  /|\     |    |         |       \     Response
                   |       --->| Analyzer|__      |       A
                   |           |         | Alert  |      /|\
                   |           |_________|  |     |       |
                   |                A       |     |       |
                   |               /|\     \|/    |       |
                   |________________|   ____V___  |       |
                       |               |        |_|       |
                       |               | Manager|_________|
                       |               |________|
                       |                  A
                     Security            /|\
     _______________   |  Policy__________|
    |               |  |
    | Administrator |__|
    |_______________|

==> Note: In the figure an Alert is passed from Analyzer to Manager. 
==> Is "Alert" = "event report" ? Uniform terminology will be helpful.
==> "Event" is reported from Sensor to Analyzer in the figure. 

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 into a single module; some will have multiple instances
of these modules.

==> Perhaps we have strayed here. We are probably concerned only in 
==> the Alert that goes from the Analyzer to the Manager. Do we really 
==> need Administrator, Operator, Security Policy, Notification, 
==> Response ?  We probably do not need those definitions either. 

[Deleted]
3.3  Architectural Assumptions
==> Trust Model needs to be discussed here.
In this document, as defined in the terms above, we assume that an
analyzer determines somehow that a suspicious event has been seen by a
sensor, and sends an alert to a manager. The format of that alert and
the method of communicating it are what IDMEF proposes to standardize.

==> The format AND the method of communicating it will be standardized ?

[Deleted]
3.4  Organization of this document.

Besides this requirements document, the IDWG working group should
produce two other documents. The first should describe a data format or
language for exchanging information about suspicious events.  In this
document, we refer to that as the "data-format specification".  The
second document should identify existing IETF protocols that are best

==> identify "existing" IETF protocols ?  

used for conveying the data so formatted, and explain how to package
this data in those existing formats. We refer to this as the
"communication specification".

[DELETED]
3.5 Document Impact on IDMEF Designs

It is expected that proposed IDMEF designs will, at a minimum, satisfy
the requirements expressed in this document. However, this document will
be used only as one of many criteria in the evaluation of various IDMEF
designs. It is recognized that the working group may use additional
metrics to evaluate competing IDMEF designs.

==> Is 3.5 required?

4.  General Requirements

4.1   The IDMEF SHALL reference and use previously published RFCs where
      possible.

4.1.1 Rationale: The IETF has already completed a great deal of research
      and work into the areas of networks and security. In the interest
      of time, it is smart to use already defined and accepted
      standards.
==> Do we need 4.1.1 ?

4.2   The IDMEF specification MUST take into account that IDMEF should be
      able to operate in environments that contain IPv4 and IPv6
      implementations.

4.2.1 Rationale: Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6 
      environments are expected to exist within the timeframe of IDMEF 
      implementations, the IDMEF specification MUST support IPv6
      and IPv4 environments.
==> Do we need this? 4.2.1 can very well merged with 4.2.

5. Message Format

The IDMEF message format is intended to be independent of the IDMEF
communications mechanism. It should be possible to use a completely
different transport mechanism without changing the IDMEF format. The
goal behind this requirement is to ensure a clean separation between
semantics and communication mechanisms. Obviously the IDMEF communication
mechanism is recommended.
==> Do we need to state the obvious ?

6.  Communications Mechanism Requirements
==> Do we need this section? 
==> The Format is unrelated to the communication mechanism. If our 
==> concern is the Format only then we do not need this section.

6.1   The IDMEF MUST support reliable transmission of messages.
==>   IDMEF communications mechanism MUST support ....

6.1.1 Rationale: IDS managers often rely on receipt of data from IDS
      analyzers to do their jobs effectively. Since IDS managers will
      rely on IDMEF messages for this purpose, it is important that IDMEF
      messages be delivered reliably.

6.2   The IDMEF MUST support transmission of messages between ID 
==>   IDMEF communications mechanism MUST support ....
      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,
      the ability to send IDMEF messages through firewalls is necessary.
==> Do we need the following ? [I am not sure that is correct.] 
      Setting up this communication MUST NOT require changes to the
      intervening firewall(s) that weaken the security of the protected
      network(s). Nor SHOULD this be achieved by conflating IDMEF
      messages with other kinds of traffic (e.g., by overloading the
      HTTP POST method) since that would make it difficult for an
      organization to apply separate policies to IDMEF traffic and other
      kinds of traffic.

6.3   The IDMEF MUST support mutual authentication of the analyzer and
==>   IDMEF communications mechanism MUST support ....
      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 
      of an enterprise network, it is important that the receiver have
      confidence in the identity of the sender and that the sender have
      confidence in the identity of the receiver. This is peer-to-peer 
      authentication of each party to the other. It MUST NOT be 
      based on authentication of the underlying communications 
      mechanism, for example, because of the risk that this 
      authentication process might be subverted or misconfigured.
==> IESG comments not addressed.
     [This appears to rule out use of IPSEC, which is "authentication 
     of the underlying communications mechanism".  That seems ill-advised, 
     so this should be clarified. ]

6.4   The IDMEF MUST support confidentiality of the message content 
==>   IDMEF communications mechanism MUST support ....
      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
      information (such as passwords) and would be of great interest to 
      an intruder. Since it is likely some of these messages will be 
      transmitted across uncontrolled network segments, it is important 
      that the content be shielded. Furthermore, since the legal 
      environment for encryption technologies is extremely varied and 
      changes often, it is important that the design selected be capable 
      of supporting a number of different encryption options and be 
      adaptable by the user to a variety of environments.

6.5   The IDMEF MUST ensure the integrity of the message content. The
==>   IDMEF communications mechanism MUST support ....
      selected design MUST be capable of supporting a variety of 
      integrity mechanisms and MUST be adaptable to a wide variety of 
==> IESG concern "Won't the confidentiality requirement already take 
    care of this?" Is this addressed ?

6.6   The IDMEF communications mechanism SHOULD be able to ensure non-
      repudiation of the origin of IDMEF messages.
==>   "nonrepudiation of IDMEF messages" should do.

6.6.1 Rationale: Given that sensitive security information is being
      exchanged with the IDMEF, it is important that the humans operating
      the system are able to associate messages with the originating
      IDMEF entity.
==> The explanation here is not clear enough. Something like "It is important 
    to prevent someone who sent a message from later claiming that he/she
    didn't" would be better ?

6.8   The IDMEF communications mechanism SHOULD resist malicious 
      duplication of messages.

==> Is this is a "SHOULD" ? Should it be a "MUST"?

7.1    There are many different types of intrusion detection systems,
       such as those based on: signatures, anomalies, correlation,
       network monitoring, host monitoring, or application monitoring.
       The IDMEF design MUST strive to accommodate these diverse
       approaches by concentrating on conveying *what* an IDS has
       detected, rather than *how* it detected it.

7.1.1  Rationale: There are many types of intrusion detection systems 
       that analyze a variety of data sources. Some are profile based
       and operate on log files, attack signatures etc. Others are 
       anomaly based and define normal behavior and detect deviations 
       from the established baseline. Each of these systems report 
       different data that, in part, depends on their intrusion 
       detection methodology. All MUST be supported by this standard.
==> 7.1.1 just repeats 7.1. They are better merged. 

7.2    The content of IDMEF messages MUST contain the identified name of
       the event if it is known. This name MUST be drawn from a 
==>  Do we want to know the name of the event ? 
==>  Perhaps we want to know the name of the attack ? 
       standardized list of events or will be an implementation-specific 
       name if the event identity has not yet been standardized. It is 
       not known how this list will be defined or updated, although 
       requirements on the creation of this list are presented in the 
       next section of this document.

7.2.1  Rationale: Given that this document presents requirements on 
       standardizing ID message formats so that an ID manager is able to
       receive alerts from analyzers from multiple implementations, it 
       is important that the manager understand the semantics of the 
       reported events. There is, therefore, a need to identify known 
       events and store information concerning their methods and 
       possible fixes to these events. Some events are well known and 
       this recognition can help the operator.
==> The above is not very clear. The "semantics" of reported
==> events and the attack name are directly related? 

7.2.2  Scenario: Intruder launches an attack that is detected by two 
       different analyzers from two distinct implementations. Both 
       report the same event identity to the ID manager, even though the 
       algorithms used to detect the attack by each analyzer might have 
       been different.
==> The term "event identity" is confusing. 

7.3    The IDMEF message design MUST include information, which the
       sender should provide, that allows a receiver to locate background
       information on the kind of event that is being reported in the
       alert. 
==> This is unclear. 
==> Are we saying that there will be [1] an (event) attack name 
==> and [2] a pointer to background information about the event ?
==> That does not sound real.

7.3.1  Rationale: This information is used by administrators to report 
       and fix problems.
7.3.2  Scenario: Attacker performs a well-known attack. A reference to a
       URL to background information on the attack is included in the
       IDMEF message. The operator uses this information to initiate
       repairs on the vulnerable system.

7.4    The IDMEF message MUST be able to reference additional detailed 
       data related to this specific underlying event. It is OPTIONAL
       for implementations to use this field. No requirements are placed
       on the format or content of this field. It is expected that this
       will be defined and described by the implementer.
==> If it will be decided by the implementer then interoperability will
==> be broken. Unless sender and receiver are from the same implementer.
==> I think what we want to say is that the additional data field will 
==> have an associated additional data-type field and a few well known
==> data-types [e.g. URLs] will be optionally supported. 

7.4.1  Rationale: Operators might want more information on specifics of 
       an event. This field, if filled in by the analyzer, MAY point
       to additional or more detailed information about the event.
==> It is the Sender who has the information which it thinks will be of 
==> use to the receiver. 

[DELETED]
7.6    The IDMEF message MUST support the representation of different
       types of device addresses.

==> That is a new term that has appeared - "devices". What is a device?
==> a sensor, an analyzer , a manager ? If we need a new term it should 
==> be defined in the terminology section.

7.7    The IDMEF message MUST contain an indication of the possible
       impact of this event on the target. The value of this field MUST 
       be drawn from a standardized list of values.

7.7.1  Rationale: Information concerning the possible impact of the
       event on the target system provides an indication of what the
       intruder is attempting to do and is critical data for the
       operator to perform damage assessment. Not all systems will be 
       able to determine this, but it is important data to transmit for 
       those systems that can.
==> IESG concern on properties of the standardized list of values
==> not addressed.

7.8    The IDMEF message MUST provide information about the automatic
       actions taken by the analyzer in response to the event (if any).
==> Presupposes that there is no (non-automatic) manual action and, if 
==> there is any, those are not of interest!

[DELETED]

7.10   The IDMEF message MUST be able to contain the identity of the 
       implementer and the tool that detected the event.

==> IESG concern regarding properties of the implementer identity are
==> not addressed.
[DELETED]
7.12   The IDMEF message MUST be uniquely identifiable in that it can be
       distinguished from other IDMEF messages.
==> IESG concern regarding properties of the degree of uniqueness is 
==> not addressed. [ Should be fairly straight]
[DELETED]
7.13   The IDMEF MUST support reporting alert creation date and time in 
       each event. The IDMEF MAY support reporting the date and time the
       event began in addition to the date and time the alert was
       created.
==> The IESG concern was about having an "event onset" time. Which has 
==> got included. But "event detection" time has got dropped. Is this
==> intentional? All three [onset, detection, reporting] are significant 
==> IMHO.

7.13.1 Rationale: Time is important from both a reporting and
       correlation point of view. Event detection time might differ from 
       the alert creation time as it might take some time to actually 
       generate the alert message given that an event has been detected. 
       If the sensing element can determine the time the event occurred 
       it is strongly encouraged to place that information in the alert 
       message as well.
==> The reference to "detection time" is not appropriate as that has been
==> dropped in 7.13.

[DELETED]

7.17   The IDMEF message MUST support an extension mechanism used by
       implementers to define implementation-specific data. The use of
       this mechanism by the implementer is OPTIONAL. This data contains 
       implementation-specific information determined by each
       implementer. The implementer MUST indicate how to interpret these 
       extensions, although there are no specific requirements place on
       how implementers describe their implementation-specific
       extensions.
==> This is pretty fuzzy. There is no indication of HOW the implementer 
==> will indicate how the data will be interpreted. 
==> Are we talking of (1) an indication of how the data will be 
==> interpreted and   (2) the data

8. Alert Identifiers and the Alert Identifier Definition Process
==> Troublesome Terminology! This "Alert Identifier" term is VERY 
==> confusing. Are we talking about "Attack Identifier" ? 
     
==> Question: do we need this section for IDMEF ?