Subject: [sacm] Milestones for recharter - FEEDBACK needed ASAP

From: Chris Inacio <[email-masked]>
Date: Wed, 15 Nov 2017 05:47:32 +0000

For everyone in the room (in person or virtual) we discussed milestones that we would present along with our new charter text. This is what I captured during the meeting – admittedly with some significant liberties on my part:

Milestones:
==========

CoSWID - WGLC early 2018. (SWID data) (Collection)
ROLIE SW extension - WGLC early 2018 (SWID data) (Share/Collect)
ECP - mid 2018 (PT-TLS/IETF NEA data) (Collection/)

Terminology - end of 2018
Architecture / data interchange api/concept of operations - end of 2018

Transfer protocol(s) - spring 2019 (PT-TLS/XMPP-Grid/others)

Lang/api for developing guidance - fall 2019 (orchestration)

Please provide feedback ASAP so that the chairs can finish submitting the re-charter information by the end of the week.

Thank you,
Chris & Karen

--
Chris Inacio
[email-masked]<mailto:[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Wed, 15 Nov 2017 14:09:08 +0000

Chris & Karen,

Thanks for sending this out. Here are some thoughts that Bill and I have on
getting milestones built out from our possible work items. I've organized
this note by work item in the order they appear in our draft charter
presently under consideration. Before getting into the per-work-item notes,
I thought it would be good to list the drafts we think could be created in
pursuit of fulfilling our charter.

===========

*Draft Suggestions (without timelines):*
Given all of the above, the following could be milestone items (i.e.
drafts):

   - Endpoint identification and targeting
   - Endpoint element description
   - ECP
   - SWIMA
   - Criteria/evaluation language
   - Datastream over transfer mechanism
   - ECP over transfer mechanism
   - YANG-push over transfer mechanism
   - IPFIX over transfer mechanism
   - CoSWID
   - General purpose OS posture collection best practice
   - Web server posture collection best practice
   - Database server posture collection best practice
   - ROLIE software descriptor
   - ROLIE configuration checklist information type
   - ROLIE configuration descriptor
   - ROLIE vulnerability information descriptor

Other drafts:

   - Terminology
   - Architecture / data interchange api/concept of operations
   - Transfer protocol(s) - spring 2019 (PT-TLS/XMPP-Grid/others)
   - Lang/api for developing guidance - fall 2019 (orchestration)

(These last three may be useful for supporting development of the drafts
previously listed.)

============

*First Possible Work Item:*
"Define a way to provide three types of guidance to the correct SACM
collectors: 1) Which target endpoints to collect from and, 2) what to
collect from these target endpoints, and 3) How quickly after an attribute
change information must be collected."

First, we have the opinion that the third type of guidance presumes a
specific solution and on that basis should be considered for removal (I
know this might be late).

Second, given that this is an item to *provide* three types of guidance to
the correct SACM collectors, we need at least one delivery mechanism. It
seems that ROLIE or XMPP-Grid could fulfill this need. We feel that there
is probably a role for both.

Third, this work item also implies that we have some manner of:

   1. Endpoint identification and targeting
   2. Endpoint element description

*Second Possible Work Item:*
Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to
collect and deliver information about firmware, operating systems, and
software installed on an endpoint.

Here we feel that ECP (PT-TLS), along with SWIMA (software IDs over
PT-TLS), provides the NEA extension.

*Third Possible Work Item:*
Describe a criteria language capable of being evaluated against endpoint
posture information to produce a standardized result.

This is TBD, but Dave and Stephen expressed interest in this item at IETF
99, and we assume that interest persists.

*Fourth Possible Work Item:*
Define a control plane function to enable the discovery and orchestration
between devices that can provide the requisite information sought by
posture collectors, posture evaluators or both.

The more we read this one the more we were confused by it. The intent seems
to mean how information sources flow through the transfer mechanism (i.e.
XMPP-Grid). From this perspective, we may need to define how many
information sources are transferred over the given mechanism (i.e.
XMPP-Grid).

   - Datastream (XCCDF+OVAL, etc.)
   - ECP (which may end up being more than SWIMA)
   - YANG-push
   - IPFIX
   - Etc.

*Fifth Possible Work Item:*
Define a method of expressing software metadata that is suitable for use by
constrained devices including a CBOR-based format derived from the ISO/IEC
19770-2 Software Identification (SWID) tag standard.

This is, to us, clearly CoSWID.

*Sixth Possible Work Item:*
Define best practices for the collection of posture information from
endpoints and its delivery to a collector, from which it can be distributed
using the SACM messaging standards.

For network devices, this has something like Frank and crew have cooked up,
with the network device baselines (we'll reserve our comments on use of the
term baseline for another discussion). But, this also implies that there
are more such things to consider for things like Web servers, database
servers, general purpose operating systems, real-time operating systems,
IoT devices, and so on.

*Seventh Possible Work Item:*
Extend existing standards for information exchange to support the sharing
of software, configuration information, and other forms of imperative
guidance including extensions to the Resource-Oriented Lightweight
Information Exchange (ROLIE).

Obviously, this is leaning toward ROLIE, and we've got some drafts
in-flight for such extensions already. We note, however, that this work
item is not exclusive to ROLIE. Nevertheless, we have discussed software
descriptors, configuration descriptors, checklist information type
descriptor, vulnerability information descriptor, and so on.

However, we also note that this seventh work item is strikingly similar to
the fourth, and suggest that this seventh item be considered as a special
case of the fourth.

=============

Hopefully, this starts to elicit further discussion with respect to our
milestones.

Kind regards,

Adam

PS: Bill, please correct anything that I got wrong or missed from our
discussion.

On Wed, Nov 15, 2017 at 1:47 PM Chris Inacio <[email-masked]> wrote:

> For everyone in the room (in person or virtual) we discussed milestones
> that we would present along with our new charter text. This is what I
> captured during the meeting – admittedly with some significant liberties on
> my part:
> Milestones:
> ==========
>
> Please provide feedback ASAP so that the chairs can finish submitting the
> re-charter information by the end of the week.
>
> Thank you,
> Chris & Karen
>
> --
> Chris Inacio
> [email-masked]
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 16 Nov 2017 04:22:48 +0100

Hi Adam,

comments inline.

Viele Grüße,

Henk

On 11/15/2017 03:09 PM, Adam Montville wrote:
> Chris & Karen,
> 
> Thanks for sending this out. Here are some thoughts that Bill and I have 
> on getting milestones built out from our possible work items. I've 
> organized this note by work item in the order they appear in our draft 
> charter presently under consideration. Before getting into the 
> per-work-item notes, I thought it would be good to list the drafts we 
> think could be created in pursuit of fulfilling our charter.
> 
> ===========
> 
>   * Endpoint identification and targeting
>   * Endpoint element description
>   * ECP
>   * SWIMA
>   * Criteria/evaluation language
>   * Datastream over transfer mechanism
>   * ECP over transfer mechanism
>   * YANG-push over transfer mechanism
>   * IPFIX over transfer mechanism
>   * CoSWID
>   * General purpose OS posture collection best practice
>   * Web server posture collection best practice
>   * Database server posture collection best practice
>   * ROLIE software descriptor
>   * ROLIE configuration checklist information type
>   * ROLIE configuration descriptor
>   * ROLIE vulnerability information descriptor
> 
> Other drafts:
> 
>   * Terminology
>   * Architecture / data interchange api/concept of operations
>   *
>   *
> collect from these target endpoints, and 3) How quickly after an 
> attribute change information must be collected."
> 

"Transfer protocol(s) - spring 2019 (PT-TLS/XMPP-Grid/others)" seem(s) 
to be able to provide these features? Respectively, see 2nd work item 
below: "define extensions".

> 
> Second, given that this is an item to /provide/ three types of guidance 
> to the correct SACM collectors, we need at least one delivery mechanism. 
> It seems that ROLIE or XMPP-Grid could fulfill this need. We feel that 
> there is probably a role for both.
> 
Target Endpoint Characterization?

>  2. Endpoint element description
Target Endpoint Profiles?

Both imply the definition of corresponding repository capabilities, I 
think (maybe because we just created a PoC imperative guidance repo SACM 
component at the Hackathon).

> Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] 
> to collect and deliver information about firmware, operating systems, 
> and software installed on an endpoint.
> 
> This is TBD, but Dave and Stephen expressed interest in this item at 
> IETF 99, and we assume that interest persists.

Might need more specifica about the data at rest? Not sure if in scope, 
though.

> Define a control plane function to enable the discovery and 
> orchestration between devices that can provide the requisite information 
> sought by posture collectors, posture evaluators or both.
> 
> The more we read this one the more we were confused by it. The intent 
> seems to mean how information sources flow through the transfer 
> mechanism (i.e. XMPP-Grid). From this perspective, we may need to define 
> how many information sources are transferred over the given mechanism 
> (i.e. XMPP-Grid).
> 
>   * Datastream (XCCDF+OVAL, etc.)
>   * ECP (which may end up being more than SWIMA)
>   * YANG-push
>   * IPFIX
>   * Etc.

This seems to be a mix of transfer methods and payload definitions? In 
regard to negotiation/selection of the corresponding data plane streams 
there are always (at least) the two options of either an intermediary 
(e.g. a broker) or a direct end-2-end data plane flow (which could also 
be brokered/orchestrated).

> Define a method of expressing software metadata that is suitable for use 
> by constrained devices including a CBOR-based format derived from the 
> ISO/IEC 19770-2 Software Identification (SWID) tag standard.
> 
> endpoints and its delivery to a collector, from which it can be 
> distributed using the SACM messaging standards.
> 
> For network devices, this has something like Frank and crew have cooked 
> up, with the network device baselines (we'll reserve our comments on use 
> of the term baseline for another discussion). But, this also implies 
> that there are more such things to consider for things like Web servers, 
> database servers, general purpose operating systems, real-time operating 
> systems, IoT devices, and so on.

I maybe wouldn't call this bas... oh, nvm, reserved for another 
discussion ;)

> Extend existing standards for information exchange to support the 
> sharing of software, configuration information, and other forms of 
> imperative guidance including extensions to the Resource-Oriented 
> Lightweight Information Exchange (ROLIE).
> 
> However, we also note that this seventh work item is strikingly similar 
> to the fourth, and suggest that this seventh item be considered as a 
> special case of the fourth.
> 
> =============
> 
> On Wed, Nov 15, 2017 at 1:47 PM Chris Inacio <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     For everyone in the room (in person or virtual) we discussed
>     milestones that we would present along with our new charter text.
>     This is what I captured during the meeting – admittedly with some
>     significant liberties on my part:
> 
>     Milestones:
>     ==========
> 
>     Please provide feedback ASAP so that the chairs can finish
>     submitting the re-charter information by the end of the week.
> 
>     Thank you,
>     Chris & Karen
> 
>     -- 
>     Chris Inacio
>     [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Thu, 16 Nov 2017 03:59:31 +0000

Henk, thanks for the comments. They seem reasonable. Interested in what
others think of the list.

Chairs, is this getting us toward relating milestones to specific work
items in the charter?

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 16 Nov 2017 06:13:56 +0000

Chairs, Adam, et al,

For some of Chris's original milestones, it is not clear if the date is for a draft adoption, WGLC, or sent to the IESG. It might be good to add those details to the milestones.

For the CoSWID and ROLIE SW descriptor, early 2018 is good for WGLC. We should also be able to send to the IESG by March 2018.

Overall, it would be useful to see a consolidated list of milestones to be sure I have covered everything related to work I am doing. Would it be possible to send updated milestones around? If not, we can always correct any for which there is confusion.

More comments are inline below marked DAW.

Thanks,
Dave

________________________________
From: sacm <[email-masked]> on behalf of Adam Montville <[email-masked]>
Sent: Thursday, November 16, 2017 11:59 AM
To: Henk Birkholz
Cc: [email-masked]
Subject: Re: [sacm] Milestones for recharter - FEEDBACK needed ASAP

Henk, thanks for the comments. They seem reasonable. Interested in what others think of the list.

Chairs, is this getting us toward relating milestones to specific work items in the charter?

On Thu, Nov 16, 2017 at 11:23 AM Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

comments inline.

Viele Grüße,

Henk

> there is probably a role for both.

[daw: Agreed.]

[daw: Henk, I don't understand how your imperative guidance repo works, so it is hard to form an opinion here. Can you share more information? Is there a draft?]

> Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fietf.org%2Fwg%2Fconcluded%2Fnea.html&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C4e9377cf786a4385283b08d52ca67cb0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636464015950931018&sdata=DOdmwsi%2BCFLLYVZuW175x3IrPQ73DURAe7OucvloahY%3D&reserved=0>]

[daw: We plan to write a draft to share/socialize some thinking on this topic. We can provide a draft for discussion in March ahead of IETF 101.]

> This is, to us, clearly CoSWID.

[daw: yep. We would like to ship this soon. See the top of this email.]

> Lightweight Information Exchange (ROLIE).

[daw: Regarding the ROLIE SW descriptor, we would like to ship this soon. See the top of this email.]

> descriptor, vulnerability information descriptor, and so on.

Willing to help on the ROLIE configuration descriptor draft. We are also interested in writing a vulnerability descriptor draft which we can provide a personal draft ahead of IETF 101.

> special case of the fourth.

I am not so sure these are the same. Not that it should hold up this milestone discussion, but I'd like to understand your thinking more on this.

> On Wed, Nov 15, 2017 at 1:47 PM Chris Inacio <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     https://www.ietf.org/mailman/listinfo/sacm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C4e9377cf786a4385283b08d52ca67cb0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636464015950931018&sdata=SgJmldBXDWZJNnAR%2FOXapUIyq4GYSqQtiX2kiIctCHw%3D&reserved=0>
>
>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C4e9377cf786a4385283b08d52ca67cb0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636464015950931018&sdata=SgJmldBXDWZJNnAR%2FOXapUIyq4GYSqQtiX2kiIctCHw%3D&reserved=0>
>

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C4e9377cf786a4385283b08d52ca67cb0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636464015950931018&sdata=SgJmldBXDWZJNnAR%2FOXapUIyq4GYSqQtiX2kiIctCHw%3D&reserved=0>

---

From: Adam Montville <[email-masked]>
Date: Thu, 16 Nov 2017 06:26:01 +0000

Inline; trimming to focus on Dave's clarifying question.

On Thu, Nov 16, 2017 at 2:13 PM Waltermire, David A. (Fed) <
[email-masked]> wrote:

> I am not so sure these are the same. Not that it should hold up this
> milestone discussion, but I'd like to understand your thinking more on this.
>
>
When Bill and I were discussing this, we viewed the 4th work item as
describing how information gets around in a SACM domain/ecosystem. This 7th
work item is also about how information gets around in a SACM
domain/ecosystem, but is more specific.

Is our view of the 4th item inaccurate?

Adam

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 16 Nov 2017 08:58:56 +0000

Hi Adam and Chris,
Thanks for raising the discussion. The listed possible work items are very complete. I don’t have any more to add. Next step, personal suggestion is to sort them out with priority and assign the timeline for each item~~

For network devices security posture collection and evaluation, we think they can be the straightforward work items in SACM, since the information needed, the collection and transport mechanism (e.g., yang push…) and the alignment to SACM IM are already there and can be combined together. Further, security posture yang model is just part of the work, by fitting into the current SACM architecture, we hope to output is a flexible, automatic and intelligent  solution.

Welcome the comments and feedbacks from the group.
Thanks!

B.R.
Frank

发件人: sacm [mailto:[email-masked]] 代表 Adam Montville
发送时间: 2017年11月15日 22:09
收件人: Chris Inacio <[email-masked]>
抄送: [email-masked]
主题: Re: [sacm] Milestones for recharter - FEEDBACK needed ASAP

Chris & Karen,

Thanks for sending this out. Here are some thoughts that Bill and I have on getting milestones built out from our possible work items. I've organized this note by work item in the order they appear in our draft charter presently under consideration. Before getting into the per-work-item notes, I thought it would be good to list the drafts we think could be created in pursuit of fulfilling our charter.

===========

Draft Suggestions (without timelines):
Given all of the above, the following could be milestone items (i.e. drafts):

  *   Terminology

  *   Transfer protocol(s) - spring 2019 (PT-TLS/XMPP-Grid/others)

  *   Lang/api for developing guidance - fall 2019 (orchestration)
(These last three may be useful for supporting development of the drafts previously listed.)

============

First Possible Work Item:
"Define a way to provide three types of guidance to the correct SACM collectors: 1) Which target endpoints to collect from and, 2) what to collect from these target endpoints, and 3) How quickly after an attribute change information must be collected."

First, we have the opinion that the third type of guidance presumes a specific solution and on that basis should be considered for removal (I know this might be late).

Second, given that this is an item to provide three types of guidance to the correct SACM collectors, we need at least one delivery mechanism. It seems that ROLIE or XMPP-Grid could fulfill this need. We feel that there is probably a role for both.

Second Possible Work Item:
Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to collect and deliver information about firmware, operating systems, and software installed on an endpoint.

Here we feel that ECP (PT-TLS), along with SWIMA (software IDs over PT-TLS), provides the NEA extension.

Third Possible Work Item:
Describe a criteria language capable of being evaluated against endpoint posture information to produce a standardized result.

This is TBD, but Dave and Stephen expressed interest in this item at IETF 99, and we assume that interest persists.

Fourth Possible Work Item:
Define a control plane function to enable the discovery and orchestration between devices that can provide the requisite information sought by posture collectors, posture evaluators or both.

The more we read this one the more we were confused by it. The intent seems to mean how information sources flow through the transfer mechanism (i.e. XMPP-Grid). From this perspective, we may need to define how many information sources are transferred over the given mechanism (i.e. XMPP-Grid).

Fifth Possible Work Item:
Define a method of expressing software metadata that is suitable for use by constrained devices including a CBOR-based format derived from the ISO/IEC 19770-2 Software Identification (SWID) tag standard.

Sixth Possible Work Item:
Define best practices for the collection of posture information from endpoints and its delivery to a collector, from which it can be distributed using the SACM messaging standards.

For network devices, this has something like Frank and crew have cooked up, with the network device baselines (we'll reserve our comments on use of the term baseline for another discussion). But, this also implies that there are more such things to consider for things like Web servers, database servers, general purpose operating systems, real-time operating systems, IoT devices, and so on.

Seventh Possible Work Item:
Extend existing standards for information exchange to support the sharing of software, configuration information, and other forms of imperative guidance including extensions to the Resource-Oriented Lightweight Information Exchange (ROLIE).

Obviously, this is leaning toward ROLIE, and we've got some drafts in-flight for such extensions already. We note, however, that this work item is not exclusive to ROLIE. Nevertheless, we have discussed software descriptors, configuration descriptors, checklist information type descriptor, vulnerability information descriptor, and so on.

However, we also note that this seventh work item is strikingly similar to the fourth, and suggest that this seventh item be considered as a special case of the fourth.

=============

Hopefully, this starts to elicit further discussion with respect to our milestones.

Kind regards,

Adam

PS: Bill, please correct anything that I got wrong or missed from our discussion.

On Wed, Nov 15, 2017 at 1:47 PM Chris Inacio <[email-masked]<mailto:[email-masked]>> wrote:

Thank you,
Chris & Karen