Change:
An endpoint management capability is assumed to be in place within the enterprise, and is expected to collect a minimum set of <del> attributes from the endpoints under management, and to establish an endpoint's identity within the scope of that domain.  Endpoint identity can be established by collecting certain attributes (as part of the minimum set of attributes) that allow for unique and persistent tracking of endpoints on the enterprise network.  Examples include, but are not limited to, IP address, MAC address, Fully Qualified Domain Names (FQDNs), pre-provisioned identifiers such as Globally Unique Identifiers (GUIDs) or copies of serial numbers, certificates, hardware identity values, or similar attributes.  All of the information collected by the endpoint management capability is </del> <ins> attributes from the endpoints under management via Collection Tasks and to establish an endpoint's identity within the scope of that domain.  Endpoint identity can be established by collecting certain identifying attributes, collectively known as the Target Endpoint Identifier, that allow for unique and persistent tracking of endpoints on the enterprise network.  Examples include, but are not limited to, IP address, MAC address, Fully Qualified Domain Names (FQDNs), pre-provisioned identifiers such as Globally Unique Identifiers (GUIDs) or copies of serial numbers, certificates, hardware identity values, or similar attributes.  To simplify the identification of an endpoint, a Target Endpoint Label may be created and assigned to refer to the Target Endpoint Identifier.  All of the information collected by the endpoint management capability is </ins> stored, with appropriate metadata (i.e. timestamp), in a central <del> location.  The endpoint management capability is expected to be performed on an ongoing basis, resulting in routine, or even event- driven, collection of basic endpoint information. </del> <ins> location and used to build up a Target Endpoint Characterization Record and Target Endpoint Profile via a Target Endpoint Characterization Task.  The endpoint management capability is expected to be performed on an ongoing basis, resulting in routine, or even event-driven, collection of basic endpoint information. </ins> See data-attribute-table for information-specific details.

Discussion:
We should examine the vulnerability assessment process outlined in the draft and determine the alignment with SACM tasks and update as necessary.
URL
Addressed in URL During yesterday's virtual interim meeting, we discussed various open issues with respect to the Vulnerability Assessment Scenario [1] as a result of feedback that we received on the draft which you can see here [2][3]. The slide's from the meeting can be found here [4]. One issue that we didn't have a chance to discuss because we ran out of time was whether or not an endpoint management capability has the ability to push supplemental endpoint information to the vulnerability assessment capability. This question came out of a review of the following text from the Vulnerability Assessment Scenario (specifically the last sentence). "In many cases, the endpoint information needed to determine an endpoint's vulnerability status will have been previously collected by the Endpoint Management Capability and available in a Repository. However, in other cases, the necessary endpoint information will not be readily available in a Repository and a targeted collection will be necessary. Of course, an implementation of an endpoint management capability may prefer to enable operators to perform targeted collection under certain circumstances, even when sufficient information can be provided by the endpoint management capability (e.g. there may be freshness requirements for information). Targeted collection of endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by the vulnerability assessment capability. Under certain deployment scenarios, once the necessary detection information is known, the information beyond that which is available in the endpoint management capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes." Our main question is whether or not pushing information from the endpoint management capability to the vulnerability assessment capability is actually possible because it would not necessarily know what information it needs to push prior to the server requesting it (in which case it is probably considered a pull)? Is there a situation where the endpoint would know, in advance, what additional information is needed for an assessment without a server requesting it? If you have any thoughts on this issue, please provide feedback by May 31st. We are planning to have an updated version of the scenario for June 8th. Thanks, Danny [1] URL [2] URL [3] URL [4] URL (looks like the slides are not available just yet, but, I suspect they should be soon)