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

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

Hi Adam,

More comments inline.


Thanks,

Danny


________________________________
From: Adam Montville <[e-mail]>
Sent: Wednesday, September 5, 2018 1:25 PM
To: Haynes Jr., Dan
Cc: <[e-mail]>
Subject: Re: [sacm] Review on draft-ietf-sacm-ecp-02

Danny, thanks for going through all my comments, and for addressing those that you did. Please see in line for my responses.

Kind regards,

Adam

On Aug 28, 2018, at 2:13 PM, Haynes Jr., Dan <[e-mail]<mailto:[e-mail]>> wrote:

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?

No, I just missed it.

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

Seems sane to me.


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

Yes.

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

That seems like an inference :-) To me, it's better to explain that, but mine is just one opinion.

[Danny]: I think it would be covered in the "provisioning" section in EPCP Transactions. In -03, I updated the "NOTE: TO BE EXPANDED" to say the following.

"An endpoint is provisioned with one or more attributes that will serve as its unique identifier on the network as well as the components necessary to interact with the posture manager. Examples of such identifiers include MAC addresses, serial numbers, hardware certificates compliant with [IEEE-802-1ar], and
the identities of hardware cryptographic modules among others. Furthermore, in some cases, an endpoint may need to be provisioned with instantiations of data models if the posture collection engine is expecting posture information in that format. Once provisioning is complete, the endpoint is deployed on the network."

Does this help make it clearer? Or, if not, is there any text that you would like to see?


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

Seems that way.

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

Ok. Is it worthwhile to also state NETCONF/RESTCONF?

[Danny]: Section 6.2 contains normative references to NETCONF/RESTCONF. Are you looking for something more?

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

No. The API is enabling query, but no proactive tasks. How are policies managed? Seems that the API should enable that as well.

[Danny]: I think I am confused. Doesn't the API already support managing the policy  in section 6.3 (i.e., establish and update the policy)?

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

Seems reasonable.


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

Cool.


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

Thumbs up.

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

Sure. Give me a few days??

[Danny]: Sounds good to me.

  *   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]<mailto:[e-mail]>> <[e-mail]<mailto:[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