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

[Kathleen Moriarty <[e-mail]>]

Hi Alissa,

Do the updates address your concerns?

Thank you,
Kathleen

On Mon, Jun 20, 2016 at 10:56 AM, Roman D. Danyliw <[e-mail]> wrote:
> Hello Alissa,
>
>> -----Original Message-----
>> From: Roman D. Danyliw [mailto:[e-mail]]
>> Sent: Wednesday, June 01, 2016 10:52 PM
>> To: Alissa Cooper <[e-mail]>; The IESG <[e-mail]>
>
> [snip]
>
>> > -----Original Message-----
>> > From: Alissa Cooper [mailto:[e-mail]]
>> > Sent: Tuesday, May 31, 2016 7:24 PM
>> > To: The IESG <[e-mail]>
>
> [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.
>
> The following text was added to the Security considerations in -23 to reiterate the need to negotiate certain values out of band.
>
> 9.1.  Security
> [snip]
>    Certain classes may require out-of-band coordination to agree upon
>    their semantics (e.g., Confidence@rating="low" or DefinedCOA).  This
>    coordination MUST occur prior to operational data exchange to prevent
>    the incorrect interpretation of these select data elements.  When
>    parsing these data elements, implementations should validate, when
>    possible, that they conform to the agreed upon semantics.  These
>    semantics may need to be periodically reevaluated.
>
> The Confidence class was added to IndicatorExpression in the -23 draft that will allow confidence to be set for Observable, IndicatorExpression, ObservableReference and IndicatorReference.
>
> The following figure was added to Section 3.29.5 to clarify its use:
>
>     1                          :    <IndicatorExpression operator="or">
>     2                          :      <IndicatorExpression>
>     3 [O1 with low confidence] :        <Observable>..</Observable>
>     4                          :        <Confidence rating="low" />
>     5                          :      </IndicatorExpression>
>     6                          :      <IndicatorExpression>
>     7 [O2 with high confidence]:        <Observable>..</Observable>
>     8                          :        <Confidence rating="high" />
>     9                          :      </IndicatorExpression>
>    10                          :    </IndicatorExpression>
>
>    Equivalent expression: ((O1) OR (O2))
>
>           Figure 70: Varying confidence on particular Observables
>
>> > ----------------------------------------------------------------------
>> > 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"
>
> The use of cyber was cleaned up in -23.
>
>> > (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.
>
> The "zone" value was deleted in -23 to eliminate confusion.
>
> Thanks for the detailed review.
>
> Roman



-- 

Best regards,
Kathleen