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

["Waltermire, David A. (Fed)" <[e-mail]>]

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 <[e-mail]> on behalf of Adam Montville <[e-mail]>
Sent: Thursday, November 16, 2017 11:59 AM
To: Henk Birkholz
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> wrote:

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

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


[daw: Agreed.]


> Third, this work item also implies that we have some manner of:
>
>  1. Endpoint identification and targeting
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).


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


>
> *Second Possible Work Item:*
> 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>]
> 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.

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


[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.]


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

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

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


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


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

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

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


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


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


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.


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


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.


> =============
>
> 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 <[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>> 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:
>     ==========
>
>     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
>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>
>     _______________________________________________
>     sacm mailing list
>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     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
> [e-mail]<mailto:[e-mail]>
> 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
[e-mail]<mailto:[e-mail]>
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>