Subject: [sacm] Comments on version 01 of Use Cases Draft

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 25 Sep 2013 09:26:05 +0000

I've read the updated version of the Use Cases draft and have general comments with some nits:

General comments

I think version -00 had a more appropriate grouping of categorization vs. this new structure.

Listing Functional Capabilities is more appropriate to include in the requirements document than in the use cases.  The Use Cases have been at a high level been suggested in the charter to include:

- vulnerability management

- asset management/change

- asset configuration

With the focus bound to endpoint posture assessment.  So, I'd expected the refinement to be more in these categories for how the use of endpoint posture assessment gets leveraged to affect asset configuration changes, vulnerability management etc.  My comments on the version -00 was that the uses cases, while outlined appropriately, were still too broad and needed to be scoped to our charter (e.g. the need for endpoint posture assessment to aid the endpoint config manager, vulnerability assessor, etc).

The requirements document imho is the one to list out the needed capabilities to support those use cases inclusive of a data model and need for common dictionary and protocols to ensure standards based interoperability and mapping to the use cases.

Nits

- The title seems to infer that SACM is only focused on the access control based on security posture.  I believe our charter is more to expose the endpoint posture information for various purposes (that we define in the use cases), one of the being to help affect access control.

Section 3

This section really outlines the focus of SACM as it is very generic and applies to all the use cases (imho).

- 4th paragraph

    * for "following is a typical success scenario"….I think we're trying to depict a workflow so suggest reword to "following is a sample workflow scenario for assessing endpoint posture"

     * item #2, it is the set of attributes that we need to collect on the target to establish a posture.  I'm not sure that policy is to be applied yet

     * item #3: how is identifying different than defining the target endpoint?

     * item #4: seems very similar to #2, unless #2 is the configured set of attributes vs. the actual action of collecting attribute results

     * item #5: should there be a trigger (either a priori or on demand) that drives this?

- Section 3.1

    * My response to question: this section is for general endpoints so yes, should be generalized for "endpoints" to cover the spread of different endpoint types

    * 1st para:  type on 2nd sentence, beginning "The" should be "They"

* I'm not sure the use case should enumerate expected capabilities, but rather the rationale for why those capabilities may be needed.  That is, this use case is delineating

The structure of this document following these sections are more prescriptive of what's needed versus the actual application itself. Perhaps they can be reverted to provide the rationale or expectation for how the posture assessment is leveraged?

For instance:  Section 4.1 the Asset manager and configuration apps need to have a common understanding/dictionary for an "asset" identifier.  But the use case is more about,managing an asset based on a set of properties.  These properties can be extracted from the endpoint posture assessment to improve the management of assets.

Something similar would be construed for a vulnerability manager, in that the information from a posture assessment can be used for further analysis and improved reporting of vulnerabilities.

Hopefully that makes sense?

   Nancy.

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 25 Sep 2013 23:15:53 +0000

Nancy, Thank you for your comments.  They are very much appreciated.

Please find my thoughts below marked [daw].

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Wednesday, September 25, 2013 5:26 AM
To: [email-masked]
Subject: [sacm] Comments on version 01 of Use Cases Draft

General comments

- asset configuration

[daw: a few points on this:

Grouping by category/IT domain:

The charter does call out a handful of domains /categories for this work. Our use cases should be bound by these domains and the general scope around endpoint posture assessment. The challenge is that endpoint posture assessment constrains these domains to a subset of uses. We spent a couple weeks debating if SACM was focused on asset management as a whole or a subset. There was concern expressed by multiple people that grouping use cases by domain improperly characterizes the SACM work in a broader scope.

I reviewed a few use case documents from other IETF efforts and saw a common pattern of fairly flat organizational structures for these types of sections.  Based on this observation and to avoid further philosophical debate, which was not getting us closer to defining use cases, I eliminated the groupings by flattening the functional characteristics section. No use cases or functional characteristics were lost as a result of doing this. If you would like these groupings restored, I'd be happy to make the changes, but it would be helpful to understand how this would improve the document.

Functional capabilities:

The previous revision of the use cases document, draft-waltermire-sacm-use-cases-05<http://datatracker.ietf.org/doc/draft-waltermire-sacm-use-cases/>, had a section on "Functional Capabilities and Requirements". I renamed this section in the -00 draft to "Use Cases". The response to this was that most of the content in this section was describing a list of requirements. Based on this feedback I changed the title back and started to focus on expanding the use cases in section 3 and deriving functional capabilities based on the use cases.

I think it is a good idea to move this section to the requirements document, but we may want to wait on this until I work the whole way through the material. A few folks have suggested this before. My only concern is that we document the traceability from use cases to requirements. More on this later in this email.

Use cases:

Most of what was in the previous revisions was not much in the area of use cases. There was more discussion of functional capabilities. The updates to section 3 represent extracting the use case material from the old section 4 content and mailing list discussions.

Do you have concerns that any of the section 3 use cases are out of scope? If so, which ones? Do you have any suggested text changes?]

[daw: If there are no objections, I'm happy to contribute section 4 to the requirements document. As mentioned before, I'd like to complete working through section 4 first.]

Nits

[daw: Good catch. It looks like this was changed in draft-waltermire-sacm-use-cases-05. Previously it was "Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases". Are there any objections to changing it back? Any suggestions for a better title?]

Section 3

[daw: Is this a good or bad thing?]

- 4th paragraph

    * for "following is a typical success scenario"....I think we're trying to depict a workflow so suggest reword to "following is a sample workflow scenario for assessing endpoint posture"

[daw: I'll make this change in the next revision.]

[daw: The term "policy" is a word that is overloaded in meaning. I believe #2 is identifying what attributes need to be collected to support policy evaluation. We should reword this to be more precise.]

[daw: I believe that #3 is about locating/establishing communication with the endpoint for collection or finding historic data that has been previously collected.]

[daw: #4 is the actual action of collecting attribute data from the endpoint.]

[daw: Yes. Much of this depends on if you are polling the endpoint for data (trigger: request) or if you have previously set some expectation that the endpoint will provide it (triggers: schedule or based on an event).

Can you provide some suggested edits to this list?]

- Section 3.1

[daw: I will generalize this in the next revision.]

[daw: Thanks.]

[daw: Can you suggest some wording as an example? On another note, if we move the functional capabilities to the requirements doc, we will likely want to manage this traceability from the requirements, pointing back to the use cases.]

[daw: Are you referring to the content in section 4 here? I am not sure I follow. Can you elaborate?]

[daw: When you say "But the use case is more about", what use case are you referencing here?]

[daw: I need some help understanding these last few points.]

   Nancy.