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

[Henk Birkholz <[e-mail]>]

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

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

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

> 
> 
> *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.
> 
> *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).
> 
> 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 <[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]>
> 
>     _______________________________________________
>     sacm mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sacm
> 
> 
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>