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

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 4 Oct 2013 19:14:05 +0000

Hello!

A few comments inline ...

> -----Original Message-----
> From: Moriarty, Kathleen [mailto:[email-masked]]
> Sent: Saturday, September 28, 2013 6:58 PM
> To: Roman D. Danyliw; 'Panos Kampanakis (pkampana)'; [email-masked];
> 'Anton Chuvakin'
> Subject: RE: 5070-bis scoping discussion #3: cyber incident reporting
> 
> 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!
> 
> 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)
> 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.  

I'll speak for (8.a).  This attribute is supposed to classify the action being requested.  The details of this request are in Expectation/Description, a field that as currently described is free-form not necessarily lending itself to automated processing.  The question was do we want to support pre-defined courses of action.  One way to currently support this representation is by using Expectation@action="other", but that might not be the only way.

Suppose that two organizations (Organization #1 and #2) regularly share information to the degree that they worked out distinct, multi-steps procedures for handling specific events.  For simplicity, assume Procedure-A and Procedure-B was negotiated for instances where one organization tells another about an Expectation@action="watch-and-warning" type event.  In this example, Procedure-A and Procedure-B are predefined courses of action.  Also assume that when Organization #1 tells #2 to run "Procedure-A" that Organization #2 can pull up this procedures out-of-band and proceed with execution.  

There are at least 5 different approaches to encoding a given predefined procedure per the example above:

Option #1
========
<Expectation action="other">
   <Description>Procedure-A</Description>

Option #2
========
<Expectation action="watch-and-warning">
  <Description>Procedure-A</Description>

Option #3
========
<Expectation action="ext-value" ext-action="watch-and-warning-procedure-A">

Option #4
========
<Expectation action="watch-and-warning">
   <PredefinedCOA>Procedure-A</PredefinedCOA>

Option #5
=======
<Expectation action="other">
   <PredefinedCOA>Procedure-A</PredefinedCOA>

Without changes, Option #1 - #3 would be the way to implement this work-flow.  The fact that there are multiple ways might be undesirable.  Also, if multiple Expectation/Description classes are used this might cause implementation confusion.  Option #4 and #5 explicitly introduce a new class to describe this predefined action.  To restate the (8.a) question again:

** Do we want to support the standardized exchange of this kind of predefined courses of action information?
** If so, do we want to provide implementers guidance on how to do that given the current data-model (i.e., choose between Options #1 - 3)?
** If Option #1 - 3 are not desirable, do we want to introduce another element (e.g., <PredefinedCOA>) to explicitly encode this information?

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

The argument against using the Description class would be that it would difficult to know that this information is being passed without sophisticated natural language processing.  Thinking out loud, if some refactoring of the Confidence class was used, the semantics of the information would be more immediately clear.
 
> (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.
> KM> An example may be helpful here too.  We have SWID already, how
> would an asset tag be added and represented (Anton's question).

I'd propose that the asset tag number be an opaque identifier assigned by the entity owning the asset.  In my organization, that would be what the IT department scans for inventory purposes.  My read of Application@swid is that it's a unique identifier for a given application.

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

To correct the error in the question, it should read "System/Node/Location".  Location is currently an ML_STRING.  

It appears that there are at least three different expressions of location:

** coordinates (e.g., 40.4417 N, 80.0000 W)
** postal address (e.g., Data Center Building, Carnegie Mellon University, 5000 Forbes Ave, Pittsburgh, PA, 15213, USA)
** administrative (e.g., Slot 3 - 6, Rack 6, Row 9, Datacenter 2)

Is that correct?

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

I'm having difficulty finding the note from the implementer who had this request.  As I remember it, the network uid would be a substitute for Contact/ContactName.

> (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.
> RD> +1
> KM> +1
> 
> **(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.
> 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!
> 
> 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
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile