Subject: Re: [mile] 5070-bis scoping discussion #2: Indicator IDs and RelatedActivity

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 9 Sep 2013 00:30:31 +0000

Hello!

A few responses inline.

> -----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
> 
> **(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?
> 
> **(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.
>
> **(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?

I would recommend keeping the definition of the @indicator-set-id out of 5070bis -- either handle it out-of-band or through an extension.

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

I would support (a) - (c).  We likely also want to think through how we should provide extensibility to this class of information.

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

---

From: "Harrington, Christopher" <[email-masked]>
Date: Sun, 8 Sep 2013 20:44:00 -0400

One point of clarification. APT1 is not considered a campaign, it is a Threat Actor / Group. There were many campaigns that the Threat Actor behind APT1 carried out. 

We track campaigns and threat actors separately. 

Chris.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 11 Sep 2013 20:03:59 +0000

Hi Roman,

Answers below.

> **(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:
Yes. I don't the ID changes the meaning of the service described in your example.  

> **(b)** Are the attributes defined in all of the right classes?
I don't see any other places/

> **(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.
IMO, No. The IDs serve the purpose of tying indicators together. But if a class doesn't have an id doesn't mean it is not an indicator. 

**(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?
I think the description of what is an indicator-set-id and the indicator-uid should be in the bis doc. But there is no need to say how it is defined or formatted. That should not be part of the iodef-bis doc.

> (7) What further information should be included in the RelatedActivity class?
I think the RelatedActivity class was in IODEF in order to provide a reference to an incident that is related. I think its meaning is not related to the indicator-uid and indicator-set-id.

Panos

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

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

**(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?

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

**(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?

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

Regards,
Roman