Subject: Re: [mile] Call for WG Reviews of RFC5070-bis

From: Jerome Athias <[email-masked]>
Date: Sat, 4 Jan 2014 14:58:58 +0400

Hi,
Happy New Year
comments in line [JA]

2013/12/20 Roman D. Danyliw <[email-masked]>:
> Hi Jerome,
>
> Thanks for the thorough review!  Comments inline ...
>
>> -----Original Message-----
>> From: mile [mailto:[email-masked]] On Behalf Of Jerome Athias
>> Sent: Monday, December 16, 2013 11:13 AM
>> To: Moriarty, Kathleen
>> Cc: [email-masked]
>> Subject: Re: [mile] Call for WG Reviews of RFC5070-bis
>>
>> Hi,
>>
>> after a quick review, here are some notes:
>>
>> Nice work!
>>
>>
>> The attributes are sometimes missing into the figures.
>> Examples:
>> 3.11.1.
>> and in many cases the (new) indicator-uid and indicator-set-id (3.12., 3.15.,
>> 3.18.2., 3.19., 3.21.1., ...)
>
> Concur.  Good catch.  This will be fixed.
>
>> Sometimes the sentence "The X class has no attributes." is missing, i.e.: 3.18.
>
> Concur.  This will be fixed.
>
>> In 3.4, should
>> "activity described the IODEF document"
>> be
>> "activity described in the IODEF document"
>> ?
>
> Concur.  Your text "activity described in the IODEF document" is the better language to use
>
>> In 3.9.1 should
>> "A means by which"
>> be
>> "A mean by which" (or meaning)
>> ?
>
> Disagree.  The "A means by which" is the standard language used by all of the ext-* attribute write-ups.
[JA] Sorry for my bad english

>
>> Is the word "STRING" missing in 3.22.1. for KeyName and Value?
>
> Concur.  STRING is missing.
>
>> Is Value a full path? (if so, maybe it should be clarified) (I will review later the
>> registry action default enumeration)
>
> Did you mean is KeyName a full path?  I'm not sure what a full path is for a registry value (i.e., the Value class).
[JA] For a Hive, I could list the root folder, the Registry Path (as
opposed to the File Path), keys, subkeys, values (without speaking
about Cells)
Here I think that it is the Registry Path

>
>> I would review the relationships between FileName and FileSize in 3.23.
>> HashInformation Class
>
> Concur.  This came up as an issue and is tracked in Ticket #20 (http://trac.tools.ietf.org/wg/mile/trac/ticket/20).  While identified, it is not yet resolved.
>
>> (I would prefer to have ProtoCode and ProtoType to be ProtocolCode and
>> ProtocolType)
>
> I see how this change would be cleaner.  Balanced against the backward compatibility of IODEF-v1, do you think it's worth the change?
[JA] Probably not, backward compatibility is important

>
>> Maybe the virtual enumeration (3.17. System Class) could have also
>> "unknown"
>
> Concur.  "unknown" will be added.
>
>> I would double-check the description of duration in 3.18.1.
>
> Could you please be a little more specific? Is the text clumsy, not clear in some way, or both?
[JA] I should come back with more details

>
>> Could we discuss the possibility to extend the Application (and so
>> OperatingSystem) Class?, with:
>> name
>> lang
>> or/and an extension mechanism
>
> Do you have a specific proposal in mind, or is the list above data you'd like to see represented?
[JA] I should come back with more details

>
> How does this list match against the Platform class in draft-ietf-mile-sci-12?
>
>> Contact Class
>> It should be difficult to use a RACI matrix (if needed) with the actual roles
>> enumeration
>
> Could you provide an example of where the current approach would break?
[JA] Use case: use of a RACI matrix for notification/alert (who is
Notified?), prioritization

>
>> Cardinality of 0..1 between Incident and AlternativeID (I would have to
>> investigate further, but it could lead to some issues while consolidating
>> information for the same incident described by 2+
>> parties)
>
> Could you provide an example of where the current cardinality wouldn't be adequate?  While an Incident can only have 0..1 AlternativeIDs, an AlternativeID has many IncidentIDs potentially from many organizations.
[JA] I need to double-check my implementation

>
>> I like to use a ConfidenceReason when describing/exchanging a Confidence
>> NB: It also helps for making automated choices at a parser level And also for
>> automation,
>
> Can you clarify (or provide an example of) of your thinking about "ConfidenceReason"?  Is there a need to document why a particular confidence value was chosen?
[JA] Examples: verified manually, or captured by 3 different sensors,
or same result with 5 different tools

 >
>> "asset" or "system" could be useful in the type enumeration of
>> 3.9. Contact class
>
> Can you clarify (or provide an example of) what it would mean to have a Contact@type="system"?  Is it to convey contact information at the asset level?  If so, a System and Contact class can already be represented grouped together with an EventData class.
[JA] I need to double-check. Example scenario: Contact a virtual patch
system to create and apply a WAF rule

>
>>
>> I will try to review the XML part (is everything documented?
>> EMailDetails (should maybe be EmailDetails), DomainData,
>> HashSigDetails...)
>>
>> I will think about the user-agent
>> (and maybe come with some thoughts about predictability next year)
>>
>>
>> My 2c for now
>>
>> Best regards
>> /JA
>
> We're very appreciative for this feedback Jerome!
>
> Roman
>
>> 2013/12/13 Moriarty, Kathleen <[email-masked]>:
>> > Hello,
>> >
>> > RFC5070-bis will move to working group last call as scheduled in January.
>> Reviews prior to last call are extremely important to ensure the WG has
>> addressed any major concerns in the draft.  Please take the time to review
>> the draft that will result in an IODEF v2.0.  Reviews and discussion of reviews
>> should all be posted to [email-masked].  If something is more sensitive, please
>> send it to the editors and copy Brian and myself so that we see the activity
>> and interest.
>> >
>> > This will be the easiest time to get your requested changes in as we can
>> allow for detailed discussions that may be necessary.  Reviews will be
>> encouraged during last call as well within a 2 week period in January.
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis
>> >
>> > Thank you!
>> > Kathleen
>> >
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]] On Behalf
>> > Of Roman D. Danyliw
>> > Sent: Saturday, October 19, 2013 9:11 PM
>> > To: [email-masked]
>> > Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-02.txt
>> >
>> > Hello!
>> >
>> > A new version of 5070bis has been published as -02.  The following is a list
>> of the changes:
>> >
>> > ** (schema) Added Contact/ContactTitle to describe the title of the
>> > contact (Issue #35)
>> > ** (schema) Added System/AssetId to represent an opaque asset
>> > identifier (Issue #33)
>> > ** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence,
>> > Description, AdditionalData} (Issue #31 and partial #22)
>> > ** (schema) Changed cardinality of Incident/RelatedActivity to be
>> > 0..many in Incident (needed for Issue #31)
>> > ** (schema) Added System@virtual to convey whether a device is
>> > physical or virtual (Issue #16)
>> > ** (schema) Added Incident@purpose={watch} (Issue #17)
>> > ** (schema) Added System@ownership to describe asset ownership
>> (Issue
>> > #34)
>> > ** (schema) Various fixes to schema to make it valid
>> > ** (editorial) Minor spelling fixes
>> >
>> > Roman
>> >
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]] On Behalf
>> > Of [email-masked]
>> > Sent: Saturday, October 19, 2013 9:09 PM
>> > To: [email-masked]
>> > Cc: [email-masked]
>> > Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-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           : The Incident Object Description Exchange Format v2
>> >         Author(s)       : Roman Danyliw
>> >                           Paul Stoecker
>> >         Filename        : draft-ietf-mile-rfc5070-bis-02.txt
>> >         Pages           : 112
>> >         Date            : 2013-10-19
>> >
>> > Abstract:
>> >    The Incident Object Description Exchange Format (IODEF) defines a
>> >    data representation that provides a framework for sharing information
>> >    commonly exchanged by Computer Security Incident Response Teams
>> >    (CSIRTs) about computer security incidents.  This document describes
>> >    the information model for the IODEF and provides an associated data
>> >    model specified with XML Schema.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rfc5070-bis-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
>> > _______________________________________________
>> > mile mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/mile
>> >
>> > _______________________________________________
>> > mile mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/mile
>> _______________________________________________
>> mile mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mile