Subject: [sacm] Requirements -02 draft attached

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 3 Feb 2014 04:58:44 +0000

Hi all,

I have been trying to submit this since last Thursday but for some reason I can not seem to get access to https://datatracker.ietf.org/submit/

Until I do, given that we have the interim call on Tuesday, I thought I'd send a text version to the group here in time for you to review and  for us to discuss then; hopefully I'll be able to submit it as the –02 draft before then.

Thanks,
Nancy.

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 3 Feb 2014 21:42:29 +0000

Nancy,

Thanks for your work on this. A few comments/questions on your latest draft:

In section 3.1, I like having a general model that helps to provide some context to the requirements discussion. I know this has been a point of contention in past discussions. I believe that including something abstract here begins to establish some conceptual relationships between the components that are discussed in the charter and use cases (e.g., endpoints, evaluators, collectors, repositories of collection and evaluation data). It helps identify where there are separation of concerns for which we need to have requirements (and eventually data models and protocols). The difficulty here is that we do not want to be too prescriptive too soon. This is a hard balance to create and maintain.

The Simple Architectural Model:
- Asset should be changed to endpoint in the descriptive text to be in sync with the diagram. You may want to change "Asset: is the endpoint of interest that is posture validated." to "Endpoint: The computing device for which posture will be collected for evaluation as part of a posture assessment."
- It is not clear in this model that the concepts of collection and evaluation are separated. In fact, the notion of collection is mostly absent in the model. Without getting into implementation details, we should be able to illustrate this by having separate logical entities for endpoint (posture state), collector (point of posture state observation), and evaluator (point of posture state evaluation).
- Just to clarify, the statement "A in the figure above have already been defined by different mechanisms" and others in the paragraph makes it sound like work around these methods is out of scope for the requirements document. I believe we will have work to do to profile and/or extend existing protocols to carry standardized software inventory and configuration information. We need to be sure to capture requirements that will ensure that existing mechanisms can be used appropriately to do this. More on this later in regards to section 3.3.
- The statement "As the focus of SACM is the information exchange to obtain the posture assessment information, it can be achieved through the interfaces shown as B." is making the assumption that the only point of interaction for a user or application is with an evaluator. Does this account for a scenario where a user or application wishes to ensure that specific posture is collected for future evaluation without performing an immediate evaluation? An example would be to support retroactive analysis of historic endpoint posture.
- In this model it is not clear what the role is of different repositories relative to different kinds of information. We have talked about a few different kinds of data including:
  * Posture attribute lists and other metadata that will be used to drive collection using various collection mechanisms; describing what subset of posture is of interest to collect
  * Set of contextualized posture attribute values that represent the results of posture collection for an endpoint pertaining to specific hardware, and software contexts.
  * Evaluation rules that define expected posture attribute values, and the logical operations (e.g., AND, OR, less than, greater than, equal to, etc) used for evaluation.
  * Assessment results describing the outcome(s) of an evaluation.
- The characterization of interfaces A, B, and C does seem to reflect the chartered item for defining "a standards-track document specifying a protocol and data format for retrieving configuration and policy information for driving data collection and analysis".

Section 3.2:

These seem like a good start at general requirements.

Section 3.3:

These requirements seem to be focused around interactions with a "content repository" and not an endpoint oriented collection mechanism. Is this intended?

I don't see any requirements here around data collection patterns related to UC 2.1.3 Posture Attribute Value Collection. I see two common patterns here: 1) querying directly for posture attribute values and 2) notification of changes to posture attribute values as they occur or when connectivity is sufficient to support it. Also, there is no requirement for an information/data model for communicating posture attribute values/actual state (e.g., software inventory, configuration, privileges). This will drive use of existing protocols in specific ways. For example, client or server originated communication patterns.

REQ-008 - I'm not sure what this requirement is defining.

Please let me know if you need any additional details.

Thanks,
Dave

--
From: sacm [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Sunday, February 02, 2014 11:59 PM
To: [email-masked]
Subject: [sacm] Requirements -02 draft attached

Hi all,

Until I do, given that we have the interim call on Tuesday, I thought I'd send a text version to the group here in time for you to review and  for us to discuss then; hopefully I'll be able to submit it as the -02 draft before then.

Thanks,
Nancy.