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

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 2 Jun 2016 02:51:47 +0000

Hello Alissa!

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

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Tuesday, May 31, 2016 7:24 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Roman D. Danyliw <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 2 Jun 2016 03:17:39 +0000

To clarify, a response to the DISCUSS and COMMENTs are in this thread

> From: Roman D. Danyliw [mailto:[email-masked]]
> Sent: Wednesday, June 1, 2016 10:52 PM
> To: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22: (with
> DISCUSS and COMMENT)
> 
> Hello Alissa!
> 
> > Cc: [email-masked]; Roman D. Danyliw
> > <[email-masked]>; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: Alissa Cooper's Discuss on draft-ietf-mile-rfc5070-bis-22:
> > (with DISCUSS and COMMENT)
> >
> > 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>
> 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.
> 
> > (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:
> 
> ** 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

---

From: [email-masked]
Date: Thu, 2 Jun 2016 08:47:57 -0400

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 <[email-masked]> wrote:
> 

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.

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

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

>> reevaluate the use of "cyber intelligence"

Thanks,
Kathleen 

> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 20 Jun 2016 14:56:13 +0000

Hello Alissa,

> Sent: Wednesday, June 01, 2016 10:52 PM

[snip]

[snip]

> 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

> reevaluate the use of "cyber intelligence"

The use of cyber was cleaned up in -23.

> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Jun 2016 15:52:03 -0400

Hi Alissa,

Do the updates address your concerns?

Thank you,
Kathleen

-- 

Best regards,
Kathleen