Subject: [mile] 5070-bis scoping discussion #3: cyber incident reporting

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 10 Sep 2013 00:41:46 +0000

Hello!

Per the announcement in [1], this note initiates topic discussion #3 on the 5070bis scope.  Please refer to discussion #1 [2] and #2 [3] in the archive.

Discussion #3 is intended to clarify what additional data elements are required for incident reporting.  The power-point formatted version of this text can be found in slides 8 and 9 of [4].  If you have a feelings on the matter, please provide input by noon of September 23rd.  Opinions to add something or explicitly avoid it are welcome.  In the case of the former, proposals are welcome but not required.

(8) What data elements should be added to Expectation and HistoryItem?
**(a)** Predefined course of actions -- add another class (other than Description) to encode the action when
@action="other"?
**(b)** Add a cost metric to the action?
**(c)** Add the ability to describe the (actual or expected) efficacy the action?

(9) What data elements should be added to System?
**(a)** Add the data element to represent an Asset Number? (or is it not needed if System/AdditionalData/Platform used?)
**(b)** Add a Contact class? (is it needed if EventData/Contact is used?)
**(c)** Add some indication of the type of ownership (e.g., Corporate, Partner, Personally-owned)?
**(d)** What specific location information is needed beyond System/Location?

(10) What data elements should be added to Contact?
**(a)** Add a data element to represent a title (e.g., *Mr.* Smith, *Captain* Johnson)?
**(b)** Should ContactName be split in into a given name and surname? (at the Berlin IETF, Brian Trammell, the working group chair, voiced 
**(c)** Add a data element to represent a Department?
**(d)** Add a data element to represent a network user id (e.g., LOCALNET\john)

(11) What data elements should be added to Assessment?
**(a)** Add a summary of the impact to business/mission (add Incident/Assessment/Description? Or some enumerated values to qualitatively describe the impact?)
**(b)** Add a means to enumerate the intended purpose of attack (e.g., theft-of-IP, degradation of service, fraud)

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/mail-archive/web/mile/current/msg01182.html
[4] 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: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 11 Sep 2013 20:26:49 +0000

Hi Roman,

Answers inline. As a summary, I don't see there are more elements needed except for the Assessment class. 
Search for "PK>".

(8) What data elements should be added to Expectation and HistoryItem?
**(a)** Predefined course of actions -- add another class (other than Description) to encode the action when @action="other"?
**(b)** Add a cost metric to the action?
**(c)** Add the ability to describe the (actual or expected) efficacy the action?
PK> I think the Description can fit all the above. Adding separate fields or classes could help if the iodef consumers could use them to take action or draw conclusions, but I don't think the new field can be used in such a way.

(9) What data elements should be added to System?
**(a)** Add the data element to represent an Asset Number? (or is it not needed if System/AdditionalData/Platform used?)
PK> The latter (not needed).
**(b)** Add a Contact class? (is it needed if EventData/Contact is used?)
PK> IMO, Not needed. System is part of the Flow which is in EventData, which has a contact.
**(c)** Add some indication of the type of ownership (e.g., Corporate, Partner, Personally-owned)?
PK> That could be to describe the asset or target. I could see some use here, but it could be a little subjective. I mean what is a Partner assets for me could be a corporate asset for the partner, so the iodef will not be describing it correctly.
**(d)** What specific location information is needed beyond System/Location?

(10) What data elements should be added to Contact?
**(a)** Add a data element to represent a title (e.g., *Mr.* Smith, *Captain* Johnson)?
**(b)** Should ContactName be split in into a given name and surname? (at the Berlin IETF, Brian Trammell, the working group chair, voiced
**(c)** Add a data element to represent a Department?
PK> I think the ContactName and Description can describe the above. For simplicity I think there is no need for more fields.
**(d)** Add a data element to represent a network user id (e.g., LOCALNET\john)
PK> I don't see where this could be used. 

(11) What data elements should be added to Assessment?
**(a)** Add a summary of the impact to business/mission (add Incident/Assessment/Description? Or some enumerated values to qualitatively describe the impact?)
PK> I think a summary could be useful. Should not be mandatory.
**(b)** Add a means to enumerate the intended purpose of attack (e.g., theft-of-IP, degradation of service, fraud)
PK> Could be useful. Should not be mandatory.

Rgs,
Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, September 09, 2013 8:42 PM
To: [email-masked]
Subject: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

(8) What data elements should be added to Expectation and HistoryItem?
**(a)** Predefined course of actions -- add another class (other than Description) to encode the action when @action="other"?
**(b)** Add a cost metric to the action?
**(c)** Add the ability to describe the (actual or expected) efficacy the action?

Regards,
Roman

---

From: Anton Chuvakin <[email-masked]>
Date: Thu, 12 Sep 2013 10:15:09 -0700

Inline:

On Mon, Sep 9, 2013 at 5:41 PM, Roman D. Danyliw <[email-masked]> wrote:

> Hello!
>
> Per the announcement in [1], this note initiates topic discussion #3 on
> the 5070bis scope.  Please refer to discussion #1 [2] and #2 [3] in the
> archive.
>
> Discussion #3 is intended to clarify what additional data elements are
> required for incident reporting.  The power-point formatted version of this
> text can be found in slides 8 and 9 of [4].  If you have a feelings on the
> matter, please provide input by noon of September 23rd.  Opinions to add
> something or explicitly avoid it are welcome.  In the case of the former,
> proposals are welcome but not required.
>

I'd vote against it since it will simulate addition of bad quality data (=
random numbers for costs).

> **(a)** Add the data element to represent an Asset Number? (or is it not
> needed if System/AdditionalData/Platform used?)
>

Asset tag is not necessarily a NUMBER. Asset tag is  not a bad addition.

> Partner, Personally-owned)?

A good idea indeed!

> **(d)** What specific location information is needed beyond

2 locations: physical ( e.g.  address, alt/long, etc) and administrative
(e.g. located in datacenter 2)

> **(b)** Should ContactName be split in into a given name and surname? (at
> the Berlin IETF, Brian Trammell, the working group chair, voiced
> **(a)** Add a summary of the impact to business/mission (add
> Incident/Assessment/Description? Or some enumerated values to qualitatively
> describe the impact?)
> **(b)** Add a means to enumerate the intended purpose of attack (e.g.,
> theft-of-IP, degradation of service, fraud)
>
> Regards,
> Roman
>

-- 
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 23 Sep 2013 15:14:57 +0000

Hello!

My feedback is inline.  I consolidated Anton Chuvakin's comments in the same post so all feedback is in a single thread.  Comments are annotated as follows:

PK = Panos Kampanakis
AC = Anton Chuvaki
RD = Roman Danyliw

AC> Per (a) and (b), I'd vote against it since it will simulate addition of bad quality data (= random numbers for costs).
RD> +1 on (a)

(9) What data elements should be added to System?
**(a)** Add the data element to represent an Asset Number? (or is it not needed if System/AdditionalData/Platform used?)
PK> The latter (not needed).
AC> Asset tag is not necessarily a NUMBER. Asset tag is  not a bad addition.
RD> +1 to add an asset tag identifier.

**(c)** Add some indication of the type of ownership (e.g., Corporate, Partner, Personally-owned)?
PK> That could be to describe the asset or target. I could see some use here, but it could be a little subjective. I mean what is a Partner assets for me could be a corporate asset for the partner, so the iodef will not be describing it correctly.
AC> Per (b) and (c) A good idea indeed!
RD> +1 on adding (b) and (c)

**(d)** What specific location information is needed beyond System/Location?
AC> 2 locations: physical ( e.g.  address, alt/long, etc) and administrative (e.g. located in datacenter 2)
RD> +1 on Anton's suggestion of two different Locations.  I would like to hear specifically about how the community would like to represent each of these. 

(10) What data elements should be added to Contact?
**(a)** Add a data element to represent a title (e.g., *Mr.* Smith, *Captain* Johnson)?
RD> +1 since this was requested by an implementer

**(b)** Should ContactName be split in into a given name and surname? (at the Berlin IETF, Brian Trammell, the working group chair, voiced
RD> Concur with Brian Trammell as two complicated

**(c)** Add a data element to represent a Department?
PK> I think the ContactName and Description can describe the above. For simplicity I think there is no need for more fields.
RD> As an optional item, it could help.

**(d)** Add a data element to represent a network user id (e.g., LOCALNET\john)
PK> I don't see where this could be used. 
RD> I can use for this as a unique ID for an individual.

RD> +1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, September 09, 2013 8:42 PM
To: [email-masked]
Subject: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

Regards,
Roman

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Sat, 28 Sep 2013 18:58:06 -0400

This poll was closed, but consensus was not clear on all items, so I am adding some feedback and also requesting examples that may help people to chime in with opinions.

Answers are in-line (with chair hat off), beginning with KM>

Thanks to Roman for running the poll and to all who chime in!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, September 23, 2013 11:15 AM
To: 'Panos Kampanakis (pkampana)'; [email-masked]; 'Anton Chuvakin'
Subject: Re: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

PK = Panos Kampanakis
AC = Anton Chuvaki
RD = Roman Danyliw

(8) What data elements should be added to Expectation and HistoryItem?
**(a)** Predefined course of actions -- add another class (other than Description) to encode the action when @action="other"?
**(b)** Add a cost metric to the action?
**(c)** Add the ability to describe the (actual or expected) efficacy the action?
PK> I think the Description can fit all the above. Adding separate fields or classes could help if the iodef consumers could use them to take action or draw conclusions, but I don't think the new field can be used in such a way.
AC> Per (a) and (b), I'd vote against it since it will simulate addition of bad quality data (= random numbers for costs).
RD> +1 on (a)
KM> I think a proposal for 8a would help.  It seems like a good idea, but Panos responded with a question, not a firm response.  If there was a proposal, then you should get more decisive answers.  For 8b, do people use the impact costs now?  If so, it could be helpful, but I have not heard they really use it.
I think Description could work for c, was there any input that was provided to put this question in the list to guide the responders?

KM> An example may be helpful here too.  We have SWID already, how would an asset tag be added and represented (Anton's question).

**(b)** Add a Contact class? (is it needed if EventData/Contact is used?)
PK> IMO, Not needed. System is part of the Flow which is in EventData, which has a contact.
KM> A why would have been helpful here.  Is an instance of System getting pulled out of the Flow class?  If so, is it still in EventData, and is it needed?

KM> I do think this is helpful.

**(d)** What specific location information is needed beyond System/Location?
AC> 2 locations: physical ( e.g.  address, alt/long, etc) and administrative (e.g. located in datacenter 2)
RD> +1 on Anton's suggestion of two different Locations.  I would like to hear specifically about how the community would like to represent each of these. 
KM> Can you offer a proposal or a couple of options?  That will be the easiest way to get feedback.

(10) What data elements should be added to Contact?
**(a)** Add a data element to represent a title (e.g., *Mr.* Smith, *Captain* Johnson)?
RD> +1 since this was requested by an implementer
KM> Good reason, I am fine with that decision

KM> +1  

**(c)** Add a data element to represent a Department?
PK> I think the ContactName and Description can describe the above. For simplicity I think there is no need for more fields.
RD> As an optional item, it could help.
KM> My answer depends.  If department is used for the contact role, then this could be helpful.  I work at a large organization.  Although we have many divisions, you deal with people without naming their specific division as you can look that up elsewhere.  You could tie the application to a directory server to grab that and then have no need to transport it around (search on their email and populate the application).  Is there a reason?  Is this for inter-organization exchanges?

**(d)** Add a data element to represent a network user id (e.g., LOCALNET\john)
PK> I don't see where this could be used. 
RD> I can use for this as a unique ID for an individual.
KM> I think Panos was asking for an example.  Is this for part of the incident information or part of the contact information for those sending or receiving the report?  

KM> +1

KM> +1

Thanks!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, September 09, 2013 8:42 PM
To: [email-masked]
Subject: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

Regards,
Roman

---

From: "Harrington, Christopher" <[email-masked]>
Date: Mon, 30 Sep 2013 09:05:24 -0400

I have a slightly different opinion coming from an operational role. If the
intent of this is to structure and format data for the purposes of sharing
then most of those elements are irrelevant.  I would never share them with
the possible exception of 9c. The rest of the data has no context to anyone
outside the sharing organization and therefore would not be anything that
makes sense to share. How would the receiving party use them? We also run
the risk of Privacy concerns when we talk about person's names, roles, user
ID, etc.

I'm not saying the data is not worth tracking. I completely agree these
should be tracked as part of an Incident within the organization. However as
Indicator data to be shared outside the organization they don't really have
a purpose. 

Thanks,

--Chris

Christopher Harrington
Consulting Security Engineer
GSO - Critical Incident Response Center
EMC
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roman D. Danyliw
Sent: Monday, September 23, 2013 11:15 AM
To: 'Panos Kampanakis (pkampana)'; [email-masked]; 'Anton Chuvakin'
Subject: Re: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

My feedback is inline.  I consolidated Anton Chuvakin's comments in the same
post so all feedback is in a single thread.  Comments are annotated as
follows:

PK = Panos Kampanakis
AC = Anton Chuvaki
RD = Roman Danyliw

(8) What data elements should be added to Expectation and HistoryItem?
**(a)** Predefined course of actions -- add another class (other than
Description) to encode the action when @action="other"?
**(b)** Add a cost metric to the action?
**(c)** Add the ability to describe the (actual or expected) efficacy the
action?
PK> I think the Description can fit all the above. Adding separate fields or
classes could help if the iodef consumers could use them to take action or
draw conclusions, but I don't think the new field can be used in such a way.
AC> Per (a) and (b), I'd vote against it since it will simulate addition of
bad quality data (= random numbers for costs).
RD> +1 on (a)

**(b)** Add a Contact class? (is it needed if EventData/Contact is used?)
PK> IMO, Not needed. System is part of the Flow which is in EventData, which
has a contact.

**(c)** Add some indication of the type of ownership (e.g., Corporate,
Partner, Personally-owned)?
PK> That could be to describe the asset or target. I could see some use
here, but it could be a little subjective. I mean what is a Partner assets
for me could be a corporate asset for the partner, so the iodef will not be
describing it correctly.
AC> Per (b) and (c) A good idea indeed!
RD> +1 on adding (b) and (c)

**(d)** What specific location information is needed beyond System/Location?
AC> 2 locations: physical ( e.g.  address, alt/long, etc) and administrative
(e.g. located in datacenter 2)
RD> +1 on Anton's suggestion of two different Locations.  I would like to
hear specifically about how the community would like to represent each of
these. 

(10) What data elements should be added to Contact?
**(a)** Add a data element to represent a title (e.g., *Mr.* Smith,
*Captain* Johnson)?
RD> +1 since this was requested by an implementer

**(c)** Add a data element to represent a Department?
PK> I think the ContactName and Description can describe the above. For
simplicity I think there is no need for more fields.
RD> As an optional item, it could help.

**(d)** Add a data element to represent a network user id (e.g.,
LOCALNET\john)
PK> I don't see where this could be used. 
RD> I can use for this as a unique ID for an individual.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roman D. Danyliw
Sent: Monday, September 09, 2013 8:42 PM
To: [email-masked]
Subject: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

Per the announcement in [1], this note initiates topic discussion #3 on the
5070bis scope.  Please refer to discussion #1 [2] and #2 [3] in the archive.

(8) What data elements should be added to Expectation and HistoryItem?
**(a)** Predefined course of actions -- add another class (other than
Description) to encode the action when @action="other"?
**(b)** Add a cost metric to the action?
**(c)** Add the ability to describe the (actual or expected) efficacy the
action?

(9) What data elements should be added to System?
**(a)** Add the data element to represent an Asset Number? (or is it not
needed if System/AdditionalData/Platform used?)
**(b)** Add a Contact class? (is it needed if EventData/Contact is used?)
**(c)** Add some indication of the type of ownership (e.g., Corporate,
Partner, Personally-owned)?
**(d)** What specific location information is needed beyond System/Location?

(10) What data elements should be added to Contact?
**(a)** Add a data element to represent a title (e.g., *Mr.* Smith,
*Captain* Johnson)?
**(b)** Should ContactName be split in into a given name and surname? (at
the Berlin IETF, Brian Trammell, the working group chair, voiced
**(c)** Add a data element to represent a Department?
**(d)** Add a data element to represent a network user id (e.g.,
LOCALNET\john)

Regards,
Roman

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 30 Sep 2013 13:32:18 +0000

More comments below in "PK2>".
Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, September 23, 2013 11:15 AM
To: 'Panos Kampanakis (pkampana)'; [email-masked]; 'Anton Chuvakin'
Subject: Re: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

PK = Panos Kampanakis
AC = Anton Chuvaki
RD = Roman Danyliw

PK2> Given that arbitrary confidence numbers haven't helped to much in the past, efficacy and cost metric might not help. The action could be in the description. I am not against having a separate optional field that describes what to do.

PK2> If there is a valid example where the asset would be useful, I think it is worth adding as optional.

**(b)** Add a Contact class? (is it needed if EventData/Contact is used?)
PK> IMO, Not needed. System is part of the Flow which is in EventData, which has a contact.
KM> A why would have been helpful here.  Is an instance of System getting pulled out of the Flow class?  If so, is it still in EventData, and is it needed?
PK2> I still don't see how a new contact field would help here.

PK2> OK, with me also. I suggest the field to be optional.

PK2> If it is valuable to implementers, I don't see why not.

PK2> +1

PK2> I still don't see how a department would help identifying the contact, given that there is alrady a name and email. Departments can often be complicated. I would expect that the field will not be used much. I don't mind if the team wants to use it, but I doubt it will be used.

PK2> I also see privacy concerns here, as Chris pointed out.

Thanks!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, September 09, 2013 8:42 PM
To: [email-masked]
Subject: [mile] 5070-bis scoping discussion #3: cyber incident reporting

Hello!

Regards,
Roman