Re: [sacm] Review on draft-ietf-sacm-ecp-02

["Haynes Jr., Dan" <[e-mail]>]

Thanks Adam! I pulled your comments out and have addressed them in-line.

  *   Abstract: Add reference for ECP 1.0.
[Danny]: Addressed.

  *   Section 1.1: Change control "4" to "3" and ". [CIS]" to "[CIS]."
[Danny]: Addressed.

  *   Section 1.1: EPCP not previously defined.
[Danny]: EPCP is expanded in the first sentence of Section 1. Were you looking for something more?

  *   Section 4.2: Does it filter? That's partial evaluation.
[Danny]: The only filtering occurs in the Posture Broker Server component of the Posture Collection Manager which receives a batch of attributes from the Posture Collection Engine and routes the attributes to the appropriate Posture Validator. With that said, I noticed we have text that says the Posture Collection Manager does not do any evaluation (4.2) as well as text that says the SWID Posture Validator can do evaluation (6.1.5.3.2). We need to update the SWID Posture Validator section to just say it can do some sanity checking and processing of data before storing it in the repository to make it consistent.

  *   Section 4.4: Normative MAY? There MAY be other instances of these :).
[Danny]: In this particular instance, it is non-normative because it's just discussing the different components and what they can do at a high-level if that makes sense. It might be difficult to make this text normative because for the Posture Collection Engine and Posture Collection Manager components they won't likely support the same capabilities given the technologies (i.e., data models, protocols, and interfaces) used across endpoint types (e.g., traditional vs. IoT). With that said, there is room to provide normative text for components in the EPCP Implementations section. Given all that, do you think it is okay to leave this text non-normative?

  *   Section 5: When is the target endpoint told what attributes matter and their tolerance ranges?
[Danny]: Wouldn't it be determined by the data models that are called out in the EPCP Implementations section?

  *   Section 5.1: NOTE: TO BE EXPANDED before WGLC?
[Danny]: Yes, we will update this in the next draft.

  *   Section 5.6: It feels odd to allow authorized repo access w/o specifying an interface. That said...may have a good idea for such a draft down the road a place.
[Danny]: Given that we don't actually have a protocol or interface for this, I think it's more of a note of what we want when we develop one. So, I think we are in agreement here?

  *   Section 6.2.4: Why not support fetch/polling via NETCONF and RESTCONF now?

[Danny]: This should be supported through NETCONF and RESTCONF now. This text is just trying to say that we also want to support the self-reporting capabilities provided by Yang Push once it's an RFC.

  *   Section 6.3: Change "Update the policy..." to "Establish and update the policy..."

[Danny]: Addressed.

  *   Section 6.3: Why shouldn't the API offer commands and policy interaction?

[Danny]: Are you asking why the API shouldn't offer endpoints the ability to issue commands and policy interactions?

  *   Section 7.2/7.3: Aren't vulnerability searches part of vulnerability management?

[Danny]: I don't see any reason why these two sections can't be combined.

  *   Section 13: First paragraph in Security Considerations feels superfluous.

[Danny]: Seems reasonable to remove the first paragraph.

  *   Section 13.1: Do we need to discuss benefits? Feels introductory.
  *   Section 13.1: Says "A second security consideration...". Unclear what the first was.

[Danny]: Seems reasonable to just remove this section. If there is anything we really feel we need, let's just succinctly work it into the Introduction section.

  *   Section 13.2: This is where I usually expect Security Considerations to start.
[Danny]: Agree. RFC 3552 states the purpose of the Security Considerations section is "...to encourage document authors to consider security in their designs and to inform the reader of relevant security issues...".

  *   Section 13.2.1: "....a certain percentage of endpoints will always get compromised...". This could be clarified. There will always be a certain percentage compromised.
[Danny]: Addressed. Reworded to "While the EPCP provides substantial improvements in endpoint security as described in Section 13.1, endpoints can still be compromised. For this reason, all parties must regard data coming from endpoints as potentially unreliable or even malicious...".

  *   Section 13.3: A lot of the countermeasures read like CIS Controls. Could get some love for CIS as a reference even Benchmarks. Really like the idea of referencing CIS Controls and NIST 800-53 controls.
[Danny]: Great idea! Would you be will to include the references? We will gladly give you authorship credits for it :).

  *   Section 14: Not sure how Privacy Considerations will be received, but, it is the sane to me.
[Danny]: Great.

  *   All: Various editorial changes (add/remove words, commas, etc.)
[Danny]: Addressed.
Thanks,

Danny



From: sacm [mailto:[e-mail]] On Behalf Of Adam Montville
Sent: Thursday, August 23, 2018 11:25 AM
To: <[e-mail]> <[e-mail]>
Subject: [sacm] Review on draft-ietf-sacm-ecp-02

All:

Over the past few weeks I've been reviewing this draft and providing comments along the way to the draft authors. Now that I'm through the entire draft, I'm posting it here for the entire group to see. I apologize in advance if you have difficulty reading my annotations in the PDF.

Kind regards,

Adam
_______________________________________________
sacm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sacm