Re: [mile] Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)

["Roman D. Danyliw" <[e-mail]>]

Hello Alissa!

Thanks for the review.  A response to the DISCUSS is inline ...

> -----Original Message-----
> From: Alissa Cooper [mailto:[e-mail]]
> Sent: Tuesday, May 31, 2016 7:24 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Roman D. Danyliw <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22: (with
> DISCUSS and COMMENT)
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-mile-rfc5070-bis-22: Discuss

[snip]

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The Confidence class as defined in 3.12.5 seems underspecified. It does not
> specify a max value, so some implementations might use 1 as the max while
> others might use 100.

Inherited from RFC5070, there are no ranges specified for a valid numeric confidence value.  This was an explicit design choice kept in this draft to preserve flexibility.  Acceptable ranges and how this value should be interpreted are handled out of band.  This approach is consistent with the overall design of the data model.  Consider that almost all of the classes in the data model are optional.  The minimal valid document, shown is Section 7.1, isn't useful.  Profiling between parties in a data sharing consortium will determine which optional-in-the-RFC classes should be mandatory-in-the-consortium.  This thinking extends to the semantics of classes like Confidence.

 
> It's also hard to understand how a single confidence value is supposed to be
> applied to elements with multiple fields, as in 3.12 and 3.29. What do I do if I
> have high confidence in my estimate of SystemImpact but low confidence in
> my estimate of MonetaryImpact?

If the child classes don't have the same Confidence, then each can be expressed in a distinct instance of the parent class.  For the high confidence SystemImpact but low confidence MonetaryImpact do the following (per Section 3.12):

<Incident ...>
...
  <Assessment>
     <SystemImpact>...</SystemImpact>
     <Confidence rating="low" />
  </Assessment>
  <Assessment>
     <MonetaryImpact>...</MonetaryImpact>
     <Confidence rating="high"/>
  </Assessment>
</Incident>

This same approach doesn't apply to the Indicator class (Section 3.29).  There is no way to granularly express a different confidence for different child elements that compose the Indicator.  The value expressed in Indicator/Confidence is a reflection of the confidence in the totality of the information in that Indicator class.

It would be relatively straightforward to add a Confidence class to Observable, IndicatorExpression, AttackPhase, Reference and AttackPhase.  With some redesign, the same could be done for ObservableReference, IndicatorReference, StartTime and EndTime.  

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (1) Section 1: It would be useful to define "cyber," "cyber indicator"
> (somewhere before 3.29), "cyber threat," and "cyber event." I chuckled when
> I wrote that, but I'm serious. The term "cyber" did not appear in RFC 5070. It
> has clearly taken on some (mythical, perhaps) meaning in venues external to
> the IETF. I think if this document is going to use the term, it needs to explain
> what it means. If there are some external definitions to point to or adopt,
> that would be fine.

After a search, it would appear that "cyber" is used in the abstract, Section 1.0 (Introduction), 1.3 (About the IODEF Data Model), 3.12.1 (SystemImpact), 3.12.2 (BusinessImpact), 3.28 (IndicatorData) and 3.29 (Indicator) -- 14 times total.  That can be cleaned up.  Specifically:

** Section 1.0 uses the term "cyber security event" once.  I'm going to assume that isn't controversial.
** Sections 3.12.1 and 3.12.2 use the term "cyber physical system" four times.  I'm going to assume this isn't controversial. 
** s/cyber indicator/indicator/g will address four usages of "cyber"-as-an-adjective in the abstract; and Sections 1.0, 3.28 and 3.29
** s/cyber incident report/cybersecurity incident report/g will address one more usage of "cyber"-as-an-adjective in Section 1.0
** I'll reword "cyber threats" and "cyber event mitigation" in Section 1.0; and reevaluate the use of "cyber intelligence"

> (2) Section 3.19.2: If I want to list the admin contact for a particular domain
> in a Contact element within a DomainContacts element, do I set the role in
> the Contact to "admin" or to "zone"? I think this is not entirely clear from
> how the roles are specified in 3.9 since most of the roles are more generic
> than "zone."

I'd say "admin".  You're right about the lack of symmetry of "zone" relative to the others.  I'll dig through the mailing list to see if I can recollect why we have this value.  At first blush, I'd say delete it.

Roman