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

Hi,

Thanks Alissa for the detailed review and Roman for addressing the issues raised.  Inline.

Sent from my iPhone

> On Jun 1, 2016, at 11:17 PM, Roman D. Danyliw <rdd@cert.org> wrote:
> 
> To clarify, a response to the DISCUSS and COMMENTs are in this thread
> 
>> -----Original Message-----
>> From: Roman D. Danyliw [mailto:rdd@cert.org]
>> Sent: Wednesday, June 1, 2016 10:52 PM
>> To: Alissa Cooper <alissa@cooperw.in>; The IESG <iesg@ietf.org>
>> Cc: draft-ietf-mile-rfc5070-bis@ietf.org; mile-chairs@tools.ietf.org;
>> mile@ietf.org; mile-chairs@ietf.org; takeshi_takahashi@nict.go.jp
>> Subject: RE: Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22: (with
>> DISCUSS and COMMENT)
>> 
>> Hello Alissa!
>> 
>> Thanks for the review.  A response to the DISCUSS is inline ...
>> 
>>> -----Original Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>> Sent: Tuesday, May 31, 2016 7:24 PM
>>> To: The IESG <iesg@ietf.org>
>>> Cc: draft-ietf-mile-rfc5070-bis@ietf.org; Roman D. Danyliw
>>> <rdd@cert.org>; mile-chairs@tools.ietf.org; mile@ietf.org;
>>> mile-chairs@ietf.org; takeshi_takahashi@nict.go.jp; mile@ietf.org
>>> 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.

Computer security event or network computer security event might be a better way to phrase this to get rid of the term cyber and have a term that is more easily understood.

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

I'd agree this is okay as its used frequently in the energy sector for their various devices (IoT, etc).

>> ** 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'm with Stephen and Alissa on this, I don't think cyber adds anything.  What about security incident report or network computer security incident report?

>> ** I'll reword "cyber threats" and "cyber event mitigation" in Section 1.0; and
>> reevaluate the use of "cyber intelligence"
>> 

Thanks,
Kathleen 

>>> (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
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile