Subject: list of IESG Comments & Responses

From: Mike Erlinger <[email-masked]>
Date: Tue, 30 Jan 2001 07:55:15 -0800

IDWG:

My summary of the comments made on the WG mail list starting last March
and the changes made occur in Caps.  This is the list that I thought went
out late December.  Not sure where it did go!!!  

There are still a couple of issues, e.g., 7.10 and  7.12  which could
be expanded on.  There are a  couple of options presented.

This list does NOT include Glenn's comments made around 1/26.  I will
respond to those in a subsequent mail message.

mike

"IESG discussions of draft-ietf-idwg-requirements-03.txt raised a number of
issues.  Here are the points we feel need to be addressed prior to publishing
the document.

		Vern

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
	  more generic events, such as "user login", which by themselves
	  may not reflect an attack, but with additional context available
	  to the Analyzer, may.

PERIODIC CHANGES MADE THROUGHOUT DOCUMENT, SUCH AS "DEEMED TO BE SUSPICIOUS
OR OF INTEREST.
WHETHER THIS HANDLES VERN'S CONCERN ABOUT KEEPING THE SCOPE TIGHT AND
BEING ABLE TO HANDLE DIFFERENT APPROACHES TO IDS REMAINS TO BE SEEN.
THE IDMEF SPECIFICAITON SEEMS TO CAPTURE THE TYPES OF ATOMIC ELEMENTS
VERN ENVISIONS AND THE GLUE TO HOLD THEM TOGETHER. 

---------------------------------------------------------------------
	- The examples ("Scenario:") are quite often unnecessary, and
	  clutter the document, which could be significantly shorter
	  without all but the most ones clearly needed for clarification.

THEY HAVE BEEN REMOVED EXCEPT WHERE WE THOUGHT THEM NECESSARY FOR
CLARIFICATION
---------------------------------------------------------------------

	- The MUST/SHOULD/etc keywords are generally only used for
	  standards-track documents, to indicate notions of compliance.
	  They don't really fit for a requirements document.

WE HAVE ADDED COMMENTS THAT MUST/SHOULD ETC., FOLLOW OUR DEFINITION
NOT STANDARDS-TRACK DOCUMENT STANDARDS, NOT RFC 2119.  THIS IS THE APPROACH
SUGGESTED BY  IESG MEMBERS.

---------------------------------------------------------------------
        - There should be explicit discussion of trust models.

NO CHANGES MADE, STILL MIGHT BE DONE. THE WG NEVER DEALT WITH THIS AS A
REQUIREMENT, SEEMED TO LEAVE IT OPEN TO THE IMPLEMENTATIONS.  ALSO, NO
SUBSEQUENT WG DISCUSSION TOUCHED ON WHAT MIGHT BE SATISFY THIS.

---------------------------------------------------------------------
	- It often isn't clear when requirements are referring to
	  specifications or formats; or to products (implementations).
	  In general, it should be the former, and it's worth adding brief
	  wording to make this clear (see the discussion below of IPv4 / IPv6
	  for an example).

MANY SMALL CHANGES MADE.

-------------------------------------------------------------------

	- Localtime and time zone offset (section 7.14) will prove to
	  be an immense headache.  Times should be in UTC.

NOT EXPLICIT, BECAUSE VIEWED AS A SOLUTION.  RATHER ADD THAT THE
REPRESENTATION OF TIME MUST PERMIT THE REPORTING OF EVENTS FROM 
MULTIPLE ANALYZERS IN DIFFERENT TIME ZONES AND THAT THE LOCAL TIME
AT THE ANALYZER CAN BE INFERRED.

-------------------------------------------------------------------
>    domains. Having reports from all sites in a common format would 
>    facilitate this task

add period

DONE

---------------------------------------------------------------------

> 3.2.1 Activity:
> 
> Instantiations of the data source that are identified by the sensor or
> analyzer as being of interest to the operator. Examples of this include

It's not clear what "Instantiations" means here.  It sounds like particular
instances of a data source, and that doesn't have much to do with "Activity"
per se.

WORDING MODIFIED TO BE MORE CLEAR.

--------------------------------------------------------------------- 

> (but are not limited to) network sessions, user activity, and
> application events.

It would help to have more concrete examples, to convey the spectrum.

CONCRETE EXAMPLES ADDED
--------------------------------------------------------------------- 

> Activity can range from extremely serious occurrences (such as an
> unequivocally malicious attack) to less serious occurrences (such as
> unusual user activity that's worth a further look).

Seems the definition should also include "neutral" activity, for use
by a Big Picture analyzer, as discussed above.

ADDED AN EXAMPLE OF A NEUTRAL EVENT (USER LOGIN)

--------------------------------------------------------------------- 
> 3.2.6 Event:
> 
> The occurrence in the data source that is detected by the analyzer and
> which may result in an IDEF alert being transmitted. For example, three
> failed logins in 10 seconds might indicate a brute-force login attack.

The example here makes it sound like events will be very specific.
Wouldn't it make sense for the event to instead be N failures within
T second, where the IDS can pick what combination of these constitute
an event?

DONE

--------------------------------------------------------------------- 

> 3.2.14 Security Policy:
> 
> The predefined, formally documented statement which defines what
> services are allowed to be transported across the monitored segment of
> the network to support the organization's requirements.

Defining this in terms of "services" is a fairly restricted definition.
More generally, it's what sort of activities are allowed.  Some services
might be allowed for particular types of use but not others, for example.

Also, "transported across the monitored segment" isn't the right term
for Host IDS.

CHANGED TO BE MORE GENERALLY RELEVANT TO THE DIFFERENT TYPES OF IDS.
SEE NEW VERSION

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

What is the meaning of the dotted region in the diagram?

Also, it would help for the diagram to show a second Sensor feeding
the Analyzer, so it's clear from the diagram that there can be more than
one Sensor per Analyzer.

ELIMINATED THE DOTTED LINE.  ADDED A SECOND SENSOR TO THE PICTURE;
ADDED TEXT SAYING THAT SOME ID SYSTEMS WILL HAVE MULTIPLE INSTANCES
OF ONE OR MORE OF THESE COMPONENTS AND THAT SOME ID SYSTEMS WILL
COMBINE THESE COMPONENTS INTO A SINGLE MODULE.

--------------------------------------------------------------------- 

> 4.2   The IDEF MUST be able to operate in environments that contain IPv4
>       and IPv6 implementations.

If this is a statement about the IDEF format itself, fine.  If it's a
statement about IDEF implementations (telling somewhat what they must
build), then that's too much.

INTENT WAS THAT IDEF SPECIFICATIONS SHOULD NOT BE EXCLUSIVE TO IPV4
OR IPV6, BUT SHOULD BE CAPABLE OF BEING IMPLEMENTED AND DEPLOYED IN
ENVIRONMENTS THAT HAVE EITHER OR BOTH.  WORDING WAS MODIFIED TO
(HOPEFULLY) MAKE THIS MORE CLEAR.

--------------------------------------------------------------------- 

> The IDEF message format is intended to be independent of the IDEF
> communications mechanism.  Although use of the IDEF communications
> mechanism whenever possible is RECOMMENDED, other mechanisms MAY be
> used when necessary.

This is somewhat confusing - clearly, other mechanisms can be used when
necessary, but why bother mentioning it?  Naturally, from this document's
perspective, use of the IDEF mechanism is recommended.

CHANGES AS PER STUART AND VERN

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

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.

CHANGED "based on" TO "limited to" 

--------------------------------------------------------------------

> 6.4.2 Scenario: The IDEF system might offer two different encryption
>       modules, one using 168-bit keys and another using 56-bit keys.

Best not to mention 56-bit keys, even in an example.

DELETED THE SCENARIO

--------------------------------------------------------------------

> 6.5.2 Scenario: An integrity hash, such as the MD5 algorithm, might be
>       part of the IDEF design.

Won't the confidentiality requirement already take care of this?

DELETED THE SCENARIO.  IT IS PROBABLY TRUE THAT IN GENERAL SECURE
COMMUNICATION SYSTEMS REQUIRE ENCRYPTION (CONFIDENTIALITY) AND
CHECKSUMS (INTEGRITY).  IF NEEDED, WE CAN ADD ADDITIONAL EXPLANATORY
TEXT ABOUT WHY INTEGRITY AND CONFIDENTIALITY ARE REQUIRED.

--------------------------------------------------------------------

> 6.6   The IDEF communications mechanism SHOULD be able to ensure non-
>       repudiation of the origin of IDEF messages.
> 
> 6.6.1 Rationale: Given that sensitive security information is being
>       exchanged with the IDEF, it is important that the humans operating
>       the system are able to associate messages with the originating
>       IDEF entity.
> 
> 6.6.2 Scenario: If it cannot later be satisfactorily proven that the
>       apparent source of an IDEF alert and its actual source are the
>       same, then the IDEF alert might have less evidentiary value.

This sounds like authentication, not non-repudiation, which is the inverse
problem: preventing someone who sent a message from later claiming they
didn't.

WORKING GROUP DEBATED THE WORDING HOTLY.  THE SCENARIO HAS BEEN DELETED
AS IT SEEMED TO CONFUSE RATHER THAN CLARITY.  IS IT STILL A PROBLEM?

--------------------------------------------------------------------

> 7.1    The IDEF message MUST encompass all types of intrusion detection
>        mechanisms currently available as well as those expected to be 
>        available in the future. These include, but are not limited to:
> 
>          Signature-based detection systems
>          Anomaly-based detection systems
>          Correlation-based detection systems
>          Network-based detection systems
>          Host-based detection systems
>          Application-based detection systems

If these "are not limited to" the list, then how can we know when we have
a sufficiently flexible message design?

What does it mean to support all of these?

REQUIREMENT AS ORIGINALLY WORDED WAS UNTESTABLE.  CHANGED AS VERN
AND STUART SUGGESTED.

--------------------------------------------------------------------

> 7.3    The IDEF message MUST be such that any security advisories
>        associated with the event contained therein can be inferred.

"any" is too strong here - the sender might be unaware of some.

MODIFIED THE TEXT AS DISCUSSED BY STUART AND VERN

--------------------------------------------------------------------
> 7.3.2  Scenario: Attacker performs a well-known attack. A reference to 
>        the appropriate CERT advisory is included in IDEF message since 
>        the implementer has access to a list of CERT advisory numbers. 
>        Operator uses this information to initiate repairs on the 
>        vulnerable system.

Surely this wouldn't actually be done, but instead a standardize name
would perhaps be put in the IDEF message; so the example should be fixed
accordingly.

MODIFIED THE TEXT PER VERN AND STUART

--------------------------------------------------------------------
> 7.4    The IDEF message MUST be able to reference additional detailed 
>        data related to this specific underlying event. It is OPTIONAL
>        for implementations to use this field.

Who defines the format of the additional data?  Is it somehow standardized/
coordinated?

INTENT HERE WAS THAT THE FORMAT AND CONTENT OF THIS FIELD ARE LEFT TO
THE IMPLEMENTER.  ADDED TEXT TO THAT EFFECT    

********************************************************************

> 7.7    The IDEF 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.

How is this list of values maintained?

STILL TO BE DETERMINED...
TALKING TO A COUPLE OF VENDORS, THEY EACH HAVE THEIR OWN REPRESENTATION.
AN IMPLEMENTATION MAY FIND THIS FIELD VENDOR SPECIFIC, I.E., THE MESSAGE
WOULD BE INTERPRETED BASED ON KNOWLEDGE OF THE VENDOR LIST.  ALSO,
POLICY (WHICH WE ARE NOT DOING) MAY COME INTO PLAY HERE, I.E., THE USER
MAY BE ABLE TO INDICATE TO THE SENSOR THE IMPACT OF CERTAIN EVENTS.

MAYBE WE SHOULD REMOVE THE 'MUST' PHRASE AND LET IT BE INFORMATION
PROVIDED BY THE SENSOR WITH MEANING SENSOR SPECIFIC.

********************************************************************

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

How would this be encoded?

WE ARE NOT GOING TO MAINTAIN A REGISTRY, BUT RATHER THIS WILL BE 
TEXTUAL INFORMATION THAT MAY OR MAY NOT HAVE MUCH MEANING OUTSIDE
OF A SPECIFIC IMPLEMENTATION - MUCH LIKE SOME OF THE SYSTEM INFO
IN A MIB.

WE COULD ADD TEXT INDICATING THAT THIS IS SENSOR SPECIFIC INFO.

********************************************************************

> 7.12   The IDEF message MUST be uniquely identifiable in that it can be
>        distinguished from other IDEF messages.

How strong does this have to be?  Absolutely unique?  Unique over a certain
amount of time?

NO CHANGES MADE, FOLLOW-ON COMMENTS RELATED TO REQUIREMENTS ON AN
IMPLEMENTATION AND NOT A SPECIFICATION. SUGGESTIONS FOR TEXT THAT
WILL ENSURE CREATION OF A SPECIFICATION THAT DEMANDS AS MUCH
UNIQUENESS AS POSSIBLE? 

MAYBE
"DISTINGUISHED BY TIMESTAMPS AND A MONOTONICALLY INCREASING COUNTER
WHICH IS RESET UPON REBOOT"
 
********************************************************************

> 7.13   The IDEF MUST support reporting alert creation date and time in 
>        each event. The IDEF MAY support reporting the event detection 
>        date and time in addition to the alert creation date and time.

What is the difference between alert creation and event detection?

BASED ON DISCUSSIONS, CLARIFIED WHAT IS MEANT BY 'EVENT DETECTION"
AND EXTENDED THE SCENARIO TO INCLUDE STUART'S EXAMPLE.

--------------------------------------------------------------------
> 7.16   Time granularity in event messages SHALL NOT be specified by the 
>        IDEF.

Does this also hold for time accuracy?  (How far a timestamp is from
true time.)

BELIEVE THAT THIS WAS THE INTENT.  HAVE MODIFIED THE REQUIREMENT TO
REFLECT THIS.
  
--------------------------------------------------------------------

> 7.17   The IDEF 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.

How does the implementer indicate the interpretation?

ADDED TEXT SAYING THAT THE MECHANISM BY WHICH THE IMPLEMENTER DESCRIBES
HIS EXTENSIONS IS LEFT TO THE IMPLEMENTER.

--------------------------------------------------------------------
> 8.3   The standard list of alert identifiers MUST be extensible by
>       implementers and administrators.
> 
> 8.3.1 Rationale: The IDEF will specify the basic information for each 
>       intrusion. To distinguish their offerings, different implementers 
>       desire the ability to provide additional information beyond that 
>       required for IDEF. Additionally, specific implementations might
>       want to use the IDEF for non-standard events.

The first part of the Rationale ("provide additional information") is
orthogonal to extending the list of alert identifiers.

GOT RID OF THE 2ND SENTENCE IN THE RATIONALE

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