Subject: Re: [mile] 5070-bis scoping discussion #2: Results

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 26 Sep 2013 18:42:33 +0000

Hello!

Below is the outcome of the discussion.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Roman D. Danyliw
> Sent: Monday, August 26, 2013 2:42 PM
> To: [email-masked]
> Subject: [mile] 5070-bis scoping discussion #2: Indicator IDs and
> RelatedActivity
> 
> Hello!
> 
> Per the announcement in [1], this note initiates topic discussion #2 on the
> 5070bis scope.  Discussion #1 can be found in [2].
> 
> Discussion #2 is intended to clarify what construct should be used to
> reference indicators and what information should be added to
> RelatedActivity.  The power-point formatted version of this text can be
> found in slides 6 and 7 of [3].  If you have a feelings on the matter, please
> provide input by noon of September 9th.  Opinions to add something in or
> explicitly avoid it are welcome.  In the case of the former, proposals are
> welcome but not required.
> 
> (6) What is the implementation experience of using @Indicator-UID or
> @Indicator-Set-ID?
> **(a)** How should the @indicator-UID be interpreted when aggregate
> classes are present?  Is the entire collection of data an indicator?  For
> example, consider the following:
> 
> <Service indicator-UID="csirt-2013-9083-3094f" ip_protocol="6">
>   <Port>80</Port>
>   <ProtoField>SYN-FIN</ProtoField>
>   <Application>
>      <URL>http://httpd.apache.org</URL>
>   </Application>
> </Section>
> 
> Is indicator #csirt-2013-9083-3094f: 80/tcp? 80/tcp+SYN-FIN? SYN-FIN? The
> affected classes include: Service, Assessment, HistoryItem, Expectation,
> EmailDetails, and RecordData

ACTION REQUIRED.  When writing the text describing @indicator-uid per the existing issue #15 (http://trac.tools.ietf.org/wg/mile/trac/ticket/15), add text that all aggregated classes are part of the indicator.

> **(b)** Are the attributes defined in all of the right classes?
> Currently in <HistoryItem>, <Expectation>, <Reference>, <Assessment>,
> <Address>, <Service>, <EmailDetails>, <RecordData>,
> <RegistryKeyItem>,<FileName>.
> Should it be added to <DomainData>?  Anything else?

ACTION REQUIRED.  Add the attributes to DomainData.  No other classes were suggested.  This issue is tracked as #30 (http://trac.tools.ietf.org/wg/mile/trac/ticket/30).

> **(c)** Is a data element not an officially sanctioned indicator if it doesn't
> have these attributes?  This speaks to how to write the text describing the
> attribute.

ACTION REQUIRED.  Add appropriate language to the text describing @indicator-uid to state that the absence of the @indicator-uid attribute does not preclude a particular data element from being an indicator.  This issue is already tracked as #15 (http://trac.tools.ietf.org/wg/mile/trac/ticket/15).

> **(d)** If these a desire to provide a means to describe an @indicator-set-id
> in anyway in an IODEF-Document?  Or is it an opaque identified defined out-
> of-band?

ACTION REQUIRED.  Further discussion on the representation of @indicator-id and @indicator-set-id is required.  It will be posted on the list.

> (7) What further information should be included in the RelatedActivity class?
> **(a)** Label describing activity as a campaign (e.g., APT1)
> **(b)** A Confidence class to express certainty in assigning the label in (a) or
> in the IncidentID
> **(c)** A Description class to explain the means or rational for this
> attribution
> **(d)** Anything else?

ACTION REQUIRED.  Related to the response to Question 1.c (action tracked in http://trac.tools.ietf.org/wg/mile/trac/ticket/22), some primitive support for campaign information, a Confidence class, and Description class should be added.  This issue is tracked as #31 (http://trac.tools.ietf.org/wg/mile/trac/ticket/31).

Roman

> Regards,
> Roman
> 
> [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html
> [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html
> [3] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile