Subject: [mile] comments/review on draft-ietf-mile-iodef-guidance-02.txt

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 9 Dec 2013 11:03:43 -0500

Hello Panos,

Thank you for taking the time to update the IODEF-Guidance document.  I have a few comments and suggestions and encourage others to review and comment so that we can progress the draft.  It looks like several sections need content, if implementers would like to contribute content especially in sections 3 & 4, that could be helpful.  Also, if implementers have worked through use cases and have guidance from lessons learned, that would be very useful to incorporate as well in addition to the use cases Panos has outlined in the draft already.

Section 4.4 Logic for watchlist of indicators

I think adding in examples will be very helpful in this section to clearly depict what is meant by each of the ways to represent the AND/OR logic.

I'm still having trouble reading and understanding this section.  We implemented the predicate logic based on initial discussions in our open source code and follow different rules.  The description we followed is included as you can see it is different from the current draft and provides more consistency across each of the classes as was originally intended:

For Node information, a watchlist of Systems means that the information is ORed with the other information in the Flow section and an AND with rest of the content in the EventData grouping.  As such, we need to replicate this pattern elsewhere, which is easy to do in the current format.  For HashInformation type, a watchlist type was added for each value to accommodate the same pattern.  In the Key class, a type was added with watchlist as an option as well.   If the watchlist is used, the data provided is just that, a watchlist of separate values.  I think the current description that talks about the watchlist-source and watchlist-destination confuse the logic and it could be stated more simply and consistently across the schema in terms of how the watchlist attribute effects the logic.  Instead of the OR being with the full Flow class, the initial intent was for it to be within the watchlist with an AND to the other items unless another watchlist was included leaving you with a mesh of possibilities for the possible combinations one may detect.

In the 5th paragraph, I think this explanations introduces inconsistency in the logic, I'll explain what I expected...

In the Node class, if information is grouped together, it represents the same thing (a single host, but the Node class could include all the information about it - hostname, IP, AS number, etc.).  With this pattern, if you set the type value for HashInformation to file_hash, the list provided are just alternate representations for the same hash (sha256, sha1, md5, etc.).   For the Key information, it's a little different as the grouping without it would just be part of a joined event as opposed to alternate ways to represent the same value.  To keep the pattern consistent, I think it would make sense to have the different Keys provided have the tags at the higher level (WindowsRegistryKeyModified tag included), but have them all represented within the same EventData instance.  The included examples are following this logic pattern if examples are helpful to weigh in on this

Alternatively, we could use separate EventData instances for each value, it just adds a few more tags around each value, but accomplishes the same logic.  

Once we get this adjusted, examples of each usage with an explanation would be really helpful to ensure consistency in implementations.

For the Appendix, the examples are good, but could you add a text description to explain the examples providing guidance as to decisions made in the representation for those use cases to help developers with consistent representation of use cases as it made help reduce coding efforts. 

 If others would like to contribute examples with guidance to increase interoperability between implementations for specific use cases, PLEASE DO!

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 18, 2013 2:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mile] I-D Action: draft-ietf-mile-iodef-guidance-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF.

	Title           : IODEF Usage Guidance
	Author(s)       : Panos Kampanakis
	Filename        : draft-ietf-mile-iodef-guidance-02.txt
	Pages           : 19
	Date            : 2013-10-18

Abstract:
   The Incident Object Description Exchange Format [RFC5070] defines a
   data representation that provides a framework for sharing information
   commonly exchanged by Computer Security Incident Response Teams
   (CSIRTs) about computer security incidents.  Since the IODEF model
   includes a wealth of available options that can be used to describe a
   security incident or issue, it can be challenging for implementers to
   develop tools that can Leverage IODEF for incident sharing.  This
   document provides guidelines for IODEF implementers.  It will also
   address how common security indicators can be represented in IODEF.
   The goal of this document is to make IODEF's adoption by vendors
   easier and encourage faster and wider adoption of the model by
   Computer Security Incident Response Teams (CSIRTs) around the world.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-iodef-guidance-02

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile