Change:
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)

Discussion:
vulnerable according to the information contained in the vulnerability description information. <del> The task of collecting specific endpoint information from the target endpoint, that is not available from the endpoint management capability, in order to make a determination about that endpoint (vulnerability status, identification, etc.). </del> 3. A number of assumptions must be stated in order to further clarify

software tools can understand and use. The enterprise has a means of identifying enterprise endpoints <del> although assertions about some details of this capability are made. </del> <ins> through the execution of Target Endpoint Discovery Tasks although assertions about some details of this capability are made. </ins> The enterprise has a means of extracting relevant information about enterprise endpoints in a form that is compatible with the

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.

performed in two steps: Endpoint information collected by the endpoint management <del> capability is examined. </del> <ins> capability is examined by the vulnerability management capability through Evaluation Tasks. </ins> If the data possessed by the endpoint management capability is <del> insufficient, then necessary data is collected from the target endpoint. </del> <ins> insufficient, a Collection Task is triggered and the necessary data is collected from the target endpoint. </ins> Vulnerability detection relies on the examination of different endpoint information depending on the nature of a specific

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 <del> be readily available in a Repository and a supplemental collection will be necessary.  Of course, an implementation of an endpoint management capability may prefer to enable operators to perform supplemental 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). Supplemental collection of endpoint information for the purpose of </del> <ins> be readily available in a Repository and a Collection Task will be triggered to collect it from the target endpoint.  Of course, an implementation of an endpoint management capability may prefer to enable operators to perform this 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). The collection of additional endpoint information for the purpose of </ins> vulnerability assessment does not necessarily need to be a pull by <del> 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. </del> <ins> the vulnerability assessment capability.  Over time, some new pieces of information that are needed during common types of assessments might be identified.  An endpoint management capability can be reconfigured to have this information delivered automatically.  This avoids the need to trigger additional Collection Tasks to gather this information during assessments, streamlining the assessment process. Likewise, it might be observed that certain information delivered by an endpoint management capability is rarely used.  In this case, it might be useful to re-configure the endpoint management capability to no longer collect this information to reduce network and processing overhead.  Instead, a new Collection Task can be triggered to gather this data on the rare occasions when it is needed. </ins> See data-attribute-table for information-specific details.