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

[Adam Montville <[e-mail]>]

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