Subject: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 18 May 2016 13:15:02 +0000

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] https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/
[2] https://github.com/sacmwg/vulnerability-scenario/pull/3
[3] https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html
[4] https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/ (looks like the slides are not available just yet, but, I suspect they should be soon)

---

From: Adam Montville <[email-masked]>
Date: Thu, 19 May 2016 19:18:57 -0500

There may be cases when an endpoint management capability would (presumably) be able to push information to the vulnerability assessment capability.  Consider software upgrades, or software load changes on a given endpoint.  The endpoint management capability would (presumably) have insight into those changes and be able to push that information over to the vulnerability assessment capability for an initial assessment.  The information it pushes might be as simple as SWID information, and may end up requiring a supplemental assessment...

Seems reasonable anyway.

> On May 18, 2016, at 8:15 AM, Haynes, Dan <[email-masked]> wrote:
> 
> 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
> changes.”
> [1] https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ <https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/>
> [2] https://github.com/sacmwg/vulnerability-scenario/pull/3 <https://github.com/sacmwg/vulnerability-scenario/pull/3>
> [3] https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html <https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html>
> [4] https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/ <https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/> (looks like the slides are not available just yet, but, I suspect they should be soon)
> 
> _______________________________________________
> sacm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: Wallace Sann <[email-masked]>
Date: Fri, 20 May 2016 08:56:21 +0000

I guess the first question would be…”why” would there by a delta between the endpoint management capability information wrt vulnerability and the vulnerability assessment capability?  The obvious answer would be due to a recent change that took place on the endpoint that fell outside of the time-based assessment conducted by the vulnerability assessment capability.  To Adam’s point, software upgrades etc, but one could also introduce addition variables such as time of day, offline more than X days, network admission (upon connection), network location (conference room vs. data center, VPN etc) or any other switch attribute (port, VLAN etc).  Since vulnerability assessment capabilities are not typically network aware (integrate with the switch fabric), pushing switch attributes to the vulnerability assessment capability for the purpose of understanding a broader sense of conditions could allow for a supplemental assessment.

From: Adam Montville [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 8:19 PM
To: Haynes, Dan
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

Seems reasonable anyway.

On May 18, 2016, at 8:15 AM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Danny

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

WARNING - CONFIDENTIAL INFORMATION:
________________________________
The information contained in the e-mail may contain confidential and privileged information and is intended solely for the use of the intended recipient(s). Access for any review, re-transmission, dissemination or other use of, or taking of any action in regard and reliance upon this e-mail by persons or entities other than the intended recipient(s) is unauthorized and prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 20 May 2016 12:40:47 +0000

We spend a lot of time worrying about whether we have successfully accounted for all the devices and all the vulnerabilities on each of our endpoints.  In our current draft "Vulnerability Management", our end state is to be able to compare patching system status to vulnerability assessment system status to ensure they match within a reasonable tolerance.

To do that in an automated fashion implies that the two tools/systems are able to communicate with each other to identify discrepancies.  I propose that the implied requirement is that the systems be able to share, in an interoperable fashion, device inventories, software inventories, and patch inventories.  The second order implied requirement is that there is a common identification method for devices, software, and patches--which is where SWID would figure in.

I'm not sure that there's widespread agreement that a primary purpose of a vulnerability scanner is to validate the effectiveness of the patching process, so maybe that's worth discussion.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Fort Meade DISA Acquisiton Bldg Cube A4A58E
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Wallace Sann
Sent: Friday, May 20, 2016 4:56 AM
To: Adam Montville; Haynes, Dan
Cc: [email-masked]
Subject: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 

 

From: Adam Montville [Caution-mailto:[email-masked]]
Sent: Thursday, May 19, 2016 8:19 PM
To: Haynes, Dan
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

Seems reasonable anyway.

	On May 18, 2016, at 8:15 AM, Haynes, Dan <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	changes.”

	Thanks,
	
	Danny

	[1] Caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ < Caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ > 

	[2] Caution-https://github.com/sacmwg/vulnerability-scenario/pull/3 < Caution-https://github.com/sacmwg/vulnerability-scenario/pull/3 > 

	[3] Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html > 

	[4] Caution-https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/ < Caution-https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/ >  (looks like the slides are not available just yet, but, I suspect they should be soon)

	_______________________________________________
	sacm mailing list
	[email-masked] < Caution-mailto:[email-masked] > 
	Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >

---

From: Wallace Sann <[email-masked]>
Date: Fri, 20 May 2016 13:13:05 +0000

I don't necessarily believe that the two systems should or need to communicate directly with each other to make this determination since patching and vulnerability assessment are just two factors in a SCM construct.  Case in point (and to your point Joe), neither of the two controls are really good at determining "accountability of ALL devices".  Fundamentally, an intermediate platform that allows for communication of both: patching and vulnerability assessment tools to provide oversight and understand discrepancies coupled with a comprehensive view of ALL devices solves for this.  This approach adds a third variable to the construct so that while patching, vulnerability assessment for known/managed devices/software can be validated against a repository of all devices/software.  

Known devices assessed for vulnerabilities?
Known devices patched properly?
Unknown devices?

Wallace R. Sann 

-----Original Message-----
From: Wolfkiel, Joseph L CIV DISA ID (US) [mailto:[email-masked]] 
Sent: Friday, May 20, 2016 8:41 AM
To: Wallace Sann; Adam Montville; Haynes, Dan
Cc: [email-masked]
Subject: RE: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Wallace Sann
Sent: Friday, May 20, 2016 4:56 AM
To: Adam Montville; Haynes, Dan
Cc: [email-masked]
Subject: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

 

Seems reasonable anyway.

	changes.”

	Thanks,
	
	Danny

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 20 May 2016 13:25:23 +0000

Yes.  That's also an alternative, to put data from multiple systems into a third system and compare the there.  Or to have the 3rd system try to identify discrepancies between two systems without making copies of the relevant data.  Even with the 3rd system methodology, there needs to be a way to get access to the required data and to be able to directly compare it.  I'm not sure that the requirements for data exposure and interoperability really change that much. 

I didn't address "unknown" devices since I suspect they're somewhat outside of the SACM Vulnerability Assessment construct.  I'd argue that if you can't get enough data about a device to establish a unique, persistent identity for it, that trying to collect vulnerability data about it isn't really your biggest problem.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Wallace Sann [mailto:[email-masked]] 
Sent: Friday, May 20, 2016 9:13 AM
To: Wolfkiel, Joseph L CIV DISA ID (US); Adam Montville; Haynes, Dan
Cc: [email-masked]
Subject: RE: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

Wallace R. Sann 

-----Original Message-----
From: Wolfkiel, Joseph L CIV DISA ID (US) [mailto:[email-masked]] 
Sent: Friday, May 20, 2016 8:41 AM
To: Wallace Sann; Adam Montville; Haynes, Dan
Cc: [email-masked]
Subject: RE: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Wallace Sann
Sent: Friday, May 20, 2016 4:56 AM
To: Adam Montville; Haynes, Dan
Cc: [email-masked]
Subject: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

 

Seems reasonable anyway.

	changes.”

	Thanks,
	
	Danny

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 27 May 2016 19:15:17 +0000

Hi all,

Weighing in here late, but as the person who raised the original concern to which Danny alluded, I wanted to clarify my comment.

First, I want to emphasize that I believe that that both push and pull collection of data makes sense. My concern was with regard to pushing *supplemental data*, because I don't think that is physically possible. The reason stems from my understanding of what "supplemental data" is vs. "pre-assessment data":

- pre-assessment data - this is data that the endpoint collects because there is a reason to believe that it will be useful in future assessments by some consumer. An example could be software inventory information. This could be tuned (per the examples provided below) when an enterprise knows that it wants to monitor certain information on an ongoing basis. The point, however, is that one is collecting against a possible, future need for the data. I.e., it is proactive data collection

- supplemental data - A data consumer is attempting to use pre-collected data to answer some question about the endpoint and it realizes that it does not have enough information to reach a conclusion. In this case, the consume goes out and collects supplemental data to fill in the gaps in its understanding relative to a specific question it is attempting to answer. The point of calling out supplemental data collection in the Vulnerability Assessment Scenario in the first place was to emphasize that data consumers are not limited to pre-assessment data, and that there is support for reaching back to the endpoint to fill in holes in one's knowledge. I.e., it is reactive data collection.

My problem with the wording that Danny cited in the Vulnerability Assessment Scenario draft is that it talks about the endpoint pushing supplemental data - data that no one knew was needed until the consumer found a gap in its knowledge (at least if we are using my definitions of the terms). The endpoint would have no way of knowing what supplemental data was needed without a request from this consumer (or an intermediary), in which case we have a pull situation.

At the end of the day, the real issue is probably less about the text in question and more about the definition of "supplemental data". If others' understanding of "supplemental data" differs from mine in ways that make push delivery reasonable, the definition (whatever it ends up being) should probably be clarified in the Vulnerability Assessment Scenario document.

Thanks,
Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel, Joseph L
> CIV DISA ID (US)
> Sent: Friday, May 20, 2016 8:25 AM
> To: Wallace Sann <[email-masked]>; Adam Montville
> <[email-masked]>; Haynes, Dan <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulnerability
> Assessment Scenario Issue #5 - Change Detection with an Endpoint
> Management Capability
> 
> Yes.  That's also an alternative, to put data from multiple systems into a third
> system and compare the there.  Or to have the 3rd system try to identify
> discrepancies between two systems without making copies of the relevant
> data.  Even with the 3rd system methodology, there needs to be a way to get
> access to the required data and to be able to directly compare it.  I'm not sure
> that the requirements for data exposure and interoperability really change
> that much.
> 
> I didn't address "unknown" devices since I suspect they're somewhat outside
> of the SACM Vulnerability Assessment construct.  I'd argue that if you can't
> get enough data about a device to establish a unique, persistent identity for
> it, that trying to collect vulnerability data about it isn't really your biggest
> problem.
> 
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> Subject: RE: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability
> Assessment Scenario Issue #5 - Change Detection with an Endpoint
> Management Capability
> 
> I don't necessarily believe that the two systems should or need to
> communicate directly with each other to make this determination since
> patching and vulnerability assessment are just two factors in a SCM
> construct.  Case in point (and to your point Joe), neither of the two controls
> are really good at determining "accountability of ALL devices".
> Fundamentally, an intermediate platform that allows for communication of
> both: patching and vulnerability assessment tools to provide oversight and
> understand discrepancies coupled with a comprehensive view of ALL devices
> solves for this.  This approach adds a third variable to the construct so that
> while patching, vulnerability assessment for known/managed
> devices/software can be validated against a repository of all
> devices/software.
> 
> Subject: RE: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability
> Assessment Scenario Issue #5 - Change Detection with an Endpoint
> Management Capability
> 
> We spend a lot of time worrying about whether we have successfully
> accounted for all the devices and all the vulnerabilities on each of our
> endpoints.  In our current draft "Vulnerability Management", our end state is
> to be able to compare patching system status to vulnerability assessment
> system status to ensure they match within a reasonable tolerance.
> 
> To do that in an automated fashion implies that the two tools/systems are
> able to communicate with each other to identify discrepancies.  I propose
> that the implied requirement is that the systems be able to share, in an
> interoperable fashion, device inventories, software inventories, and patch
> inventories.  The second order implied requirement is that there is a
> common identification method for devices, software, and patches--which is
> where SWID would figure in.
> 
> I'm not sure that there's widespread agreement that a primary purpose of a
> vulnerability scanner is to validate the effectiveness of the patching process,
> so maybe that's worth discussion.
> 
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> Subject: [Non-DoD Source] Re: [sacm] FOR REVIEW: Vulnerability
> Assessment Scenario Issue #5 - Change Detection with an Endpoint
> Management Capability
> 
> All active links contained in this email were disabled. Please verify the
> identity of the sender, and confirm the authenticity of all links contained
> within the message prior to copying and pasting the address to a Web
> browser.
> 
> 
> I guess the first question would be…”why” would there by a delta between
> the endpoint management capability information wrt vulnerability and the
> vulnerability assessment capability?  The obvious answer would be due to a
> recent change that took place on the endpoint that fell outside of the time-
> based assessment conducted by the vulnerability assessment capability.  To
> Adam’s point, software upgrades etc, but one could also introduce addition
> variables such as time of day, offline more than X days, network admission
> (upon connection), network location (conference room vs. data center, VPN
> etc) or any other switch attribute (port, VLAN etc).  Since vulnerability
> assessment capabilities are not typically network aware (integrate with the
> switch fabric), pushing switch attributes to the vulnerability assessment
> capability for the purpose of understanding a broader sense of conditions
> could allow for a supplemental assessment.
> 
> 
> 
> 
> 
> Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5
> - Change Detection with an Endpoint Management Capability
> 
> 
> 
> There may be cases when an endpoint management capability would
> (presumably) be able to push information to the vulnerability assessment
> capability.  Consider software upgrades, or software load changes on a given
> endpoint.  The endpoint management capability would (presumably) have
> insight into those changes and be able to push that information over to the
> vulnerability assessment capability for an initial assessment.  The information
> it pushes might be as simple as SWID information, and may end up requiring
> a supplemental assessment...
> 
> 
> 
> Seems reasonable anyway.
> 
> 
> 
> 
> 
> 	On May 18, 2016, at 8:15 AM, Haynes, Dan <[email-masked] <
> Caution-mailto:[email-masked] > > wrote:
> 
> 
> 
> 	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] Caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-
> scenario/ < Caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-
> scenario/ >
> 
> 	[2] Caution-https://github.com/sacmwg/vulnerability-scenario/pull/3
> < Caution-https://github.com/sacmwg/vulnerability-scenario/pull/3 >
> 
> 	[3] Caution-https://www.ietf.org/mail-
> archive/web/sacm/current/msg03958.html < Caution-
> https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html >
> 
> 	[4] Caution-https://datatracker.ietf.org/doc/slides-interim-2016-
> sacm-3-1/ < Caution-https://datatracker.ietf.org/doc/slides-interim-2016-
> sacm-3-1/ >  (looks like the slides are not available just yet, but, I suspect
> they should be soon)
> 
> 
> 
> 	Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-
> https://www.ietf.org/mailman/listinfo/sacm >
> 
> 
> 
> The information contained in the e-mail may contain confidential and
> privileged information and is intended solely for the use of the intended
> recipient(s). Access for any review, re-transmission, dissemination or other
> use of, or taking of any action in regard and reliance upon this e-mail by
> persons or entities other than the intended recipient(s) is unauthorized and
> prohibited. If you are not the intended recipient, please contact the sender
> by reply e-mail and destroy all copies of the original message and any
> attachments.

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 27 May 2016 19:52:55 +0000

Are you essentially saying that pushed data is always "pre-assessment data"?

Regards,
Dave

> From: sacm [mailto:[email-masked]] On Behalf Of Schmidt, Charles
> M.
> Sent: Friday, May 27, 2016 3:15 PM
> To: Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]>;
> Wallace Sann <[email-masked]>; Adam Montville
> Weighing in here late, but as the person who raised the original concern to
> which Danny alluded, I wanted to clarify my comment.
> 
> First, I want to emphasize that I believe that that both push and pull
> collection of data makes sense. My concern was with regard to pushing
> *supplemental data*, because I don't think that is physically possible. The
> reason stems from my understanding of what "supplemental data" is vs.
> "pre-assessment data":
> 
> - pre-assessment data - this is data that the endpoint collects because there
> is a reason to believe that it will be useful in future assessments by some
> consumer. An example could be software inventory information. This could
> be tuned (per the examples provided below) when an enterprise knows that
> it wants to monitor certain information on an ongoing basis. The point,
> however, is that one is collecting against a possible, future need for the data.
> I.e., it is proactive data collection
> 
> - supplemental data - A data consumer is attempting to use pre-collected
> data to answer some question about the endpoint and it realizes that it does
> not have enough information to reach a conclusion. In this case, the consume
> goes out and collects supplemental data to fill in the gaps in its understanding
> relative to a specific question it is attempting to answer. The point of calling
> out supplemental data collection in the Vulnerability Assessment Scenario in
> the first place was to emphasize that data consumers are not limited to pre-
> assessment data, and that there is support for reaching back to the endpoint
> to fill in holes in one's knowledge. I.e., it is reactive data collection.
> 
> My problem with the wording that Danny cited in the Vulnerability
> Assessment Scenario draft is that it talks about the endpoint pushing
> supplemental data - data that no one knew was needed until the consumer
> found a gap in its knowledge (at least if we are using my definitions of the
> terms). The endpoint would have no way of knowing what supplemental
> data was needed without a request from this consumer (or an intermediary),
> in which case we have a pull situation.
> 
> At the end of the day, the real issue is probably less about the text in
> question and more about the definition of "supplemental data". If others'
> understanding of "supplemental data" differs from mine in ways that make
> push delivery reasonable, the definition (whatever it ends up being) should
> probably be clarified in the Vulnerability Assessment Scenario document.
> 
> Thanks,
> Charles
> 
> > From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel,
> > Joseph L CIV DISA ID (US)
> > Yes.  That's also an alternative, to put data from multiple systems
> > into a third system and compare the there.  Or to have the 3rd system
> > try to identify discrepancies between two systems without making
> > copies of the relevant data.  Even with the 3rd system methodology,
> > there needs to be a way to get access to the required data and to be
> > able to directly compare it.  I'm not sure that the requirements for
> > data exposure and interoperability really change that much.
> >
> > I didn't address "unknown" devices since I suspect they're somewhat
> > outside of the SACM Vulnerability Assessment construct.  I'd argue
> > that if you can't get enough data about a device to establish a
> > unique, persistent identity for it, that trying to collect
> > vulnerability data about it isn't really your biggest problem.
> >
> > Joseph L. Wolfkiel
> > SCM Engineering Lead
> > DISA ID52
> > construct.  Case in point (and to your point Joe), neither of the two
> > controls are really good at determining "accountability of ALL devices".
> > both: patching and vulnerability assessment tools to provide oversight
> > and understand discrepancies coupled with a comprehensive view of ALL
> > devices solves for this.  This approach adds a third variable to the
> > construct so that while patching, vulnerability assessment for
> > known/managed devices/software can be validated against a repository
> > of all devices/software.
> >
> > accounted for all the devices and all the vulnerabilities on each of
> > our endpoints.  In our current draft "Vulnerability Management", our
> > end state is to be able to compare patching system status to
> > vulnerability assessment system status to ensure they match within a
> reasonable tolerance.
> >
> > To do that in an automated fashion implies that the two tools/systems
> > are able to communicate with each other to identify discrepancies.  I
> > propose that the implied requirement is that the systems be able to
> > share, in an interoperable fashion, device inventories, software
> > inventories, and patch inventories.  The second order implied
> > requirement is that there is a common identification method for
> > devices, software, and patches--which is where SWID would figure in.
> >
> > I'm not sure that there's widespread agreement that a primary purpose
> > of a vulnerability scanner is to validate the effectiveness of the
> > patching process, so maybe that's worth discussion.
> >
> > Joseph L. Wolfkiel
> > SCM Engineering Lead
> > DISA ID52
> > All active links contained in this email were disabled. Please verify
> > the identity of the sender, and confirm the authenticity of all links
> > contained within the message prior to copying and pasting the address
> > to a Web browser.
> >
> >
> > I guess the first question would be…”why” would there by a delta
> > between the endpoint management capability information wrt
> > vulnerability and the vulnerability assessment capability?  The
> > obvious answer would be due to a recent change that took place on the
> > endpoint that fell outside of the time- based assessment conducted by
> > the vulnerability assessment capability.  To Adam’s point, software
> > upgrades etc, but one could also introduce addition variables such as
> > time of day, offline more than X days, network admission (upon
> > connection), network location (conference room vs. data center, VPN
> > etc) or any other switch attribute (port, VLAN etc).  Since
> > vulnerability assessment capabilities are not typically network aware
> > (integrate with the switch fabric), pushing switch attributes to the
> > vulnerability assessment capability for the purpose of understanding a
> > broader sense of conditions could allow for a supplemental assessment.
> >
> >
> >
> >
> >
> > (presumably) be able to push information to the vulnerability
> > assessment capability.  Consider software upgrades, or software load
> > changes on a given endpoint.  The endpoint management capability would
> > (presumably) have insight into those changes and be able to push that
> > information over to the vulnerability assessment capability for an
> > initial assessment.  The information it pushes might be as simple as
> > SWID information, and may end up requiring a supplemental assessment...
> >
> >
> >
> > Seems reasonable anyway.
> >
> >
> >
> >
> >
> 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].
> >
> >
> >
> out
> > of time was whether or not an endpoint management capability has the
> > assessment capability.  This question came out of a review of the
> > following text from the Vulnerability Assessment Scenario
> > (specifically the last sentence).
> >
> >
> >
> > 	endpoint information will not be readily available in a Repository
> > and a targeted collection will be necessary.  Of course,
> >
> prefer to
> > enable operators to perform targeted collection under
> >
> assessment
> > capability by the endpoint whenever that information
> >
> > 	changes.”
> >
> >
> >
> > 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?
> >
> >
> >
> > May 31st.  We are planning to have an updated version of the scenario
> > for June 8th.
> >
> >
> >
> > 	Thanks,
> >
> > 	Danny
> >
> >
> >
> > scenario/ <
> > Caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-
> > scenario/ >
> >
> > sacm-3-1/ <
> > Caution-https://datatracker.ietf.org/doc/slides-interim-2016-
> > sacm-3-1/ >  (looks like the slides are not available just yet, but, I
> > suspect they should be soon)
> >
> >
> >
> > privileged information and is intended solely for the use of the
> > intended recipient(s). Access for any review, re-transmission,
> > dissemination or other use of, or taking of any action in regard and
> > reliance upon this e-mail by persons or entities other than the
> > intended recipient(s) is unauthorized and prohibited. If you are not
> > the intended recipient, please contact the sender by reply e-mail and
> > destroy all copies of the original message and any attachments.

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 31 May 2016 03:45:56 +0000

> Are you essentially saying that pushed data is always "pre-assessment data"?

Yes. Because data that is collected because of an unmet need *during* an assessment (i.e., supplemental data) could only be pulled.

If others have a different definition of pre-assessment vs. supplemental data, that's fine - mostly I wanted to explain the origin of my comment and make sure that we have a common set of definitions going forward.

Charles

> From: Waltermire, David A. (Fed) [mailto:[email-masked]]
> Sent: Friday, May 27, 2016 2:53 PM
> To: Schmidt, Charles M. <[email-masked]>; Wolfkiel, Joseph L CIV DISA
> ID (US) <[email-masked]>; Wallace Sann
> <[email-masked]>; Adam Montville
> Subject: RE: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulnerability

---

From: Adam Montville <[email-masked]>
Date: Tue, 31 May 2016 12:12:27 -0500

Interesting.  I wouldn’t say that pushed data is always pre-assessment data.  At some point the collector will learn what is important and may be instructed to monitor that data for change.

That data may have started out as supplemental data, but becomes plain old assessment data, or possibly pre-assessment data.

> On May 30, 2016, at 10:45 PM, Schmidt, Charles M. <[email-masked]> wrote:
> 
>> From: Waltermire, David A. (Fed) [mailto:[email-masked] <mailto:[email-masked]>]
>> To: Schmidt, Charles M. <[email-masked] <mailto:[email-masked]>>; Wolfkiel, Joseph L CIV DISA
>> ID (US) <[email-masked] <mailto:[email-masked]>>; Wallace Sann
>> <[email-masked] <mailto:[email-masked]>>; Adam Montville
>> <[email-masked] <mailto:[email-masked]>>; Haynes, Dan <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>>>> From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Wolfkiel,
>>>> To: Wallace Sann <[email-masked] <mailto:[email-masked]>>; Adam Montville
>>>> <[email-masked] <mailto:[email-masked]>>; Haynes, Dan <[email-masked] <mailto:[email-masked]>>
>>>> Cc: [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>>> 
>>>> 
>>>> 
>>>> From: Wallace Sann [mailto:[email-masked] <mailto:[email-masked]>]
>>>> Cc: [email-masked] <mailto:[email-masked]>
>>>> From: Wolfkiel, Joseph L CIV DISA ID (US)
>>>> [mailto:[email-masked] <mailto:[email-masked]>]
>>>> Cc: [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>>> 
>>>> 
>>>> From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Wallace Sann
>>>> Cc: [email-masked] <mailto:[email-masked]>
>>>> From: Adam Montville [Caution-mailto:[email-masked] <mailto:[email-masked]>]
>>>> Cc: [email-masked] <mailto:[email-masked]>
>>>> 	On May 18, 2016, at 8:15 AM, Haynes, Dan <[email-masked] <mailto:[email-masked]> <
>>>> Caution-mailto:[email-masked] <mailto:[email-masked]> > > wrote:
>>>> 
>>>> 
>>>> 
>>>> 	[1] Caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln- <caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln->
>>>> scenario/ <
>>>> Caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln- <caution-https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln->
>>>> scenario/ >
>>>> 
>>>> 	[2] Caution-https://github.com/sacmwg/vulnerability-scenario/pull/3 <caution-https://github.com/sacmwg/vulnerability-scenario/pull/3>
>>>> < Caution-https://github.com/sacmwg/vulnerability-scenario/pull/3 <caution-https://github.com/sacmwg/vulnerability-scenario/pull/3> >
>>>> 
>>>> 	[3] Caution-https://www.ietf.org/mail- <caution-https://www.ietf.org/mail->
>>>> https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html <https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html> >
>>>> 
>>>> 	[4] Caution-https://datatracker.ietf.org/doc/slides-interim-2016- <caution-https://datatracker.ietf.org/doc/slides-interim-2016->
>>>> sacm-3-1/ <
>>>> Caution-https://datatracker.ietf.org/doc/slides-interim-2016- <caution-https://datatracker.ietf.org/doc/slides-interim-2016->
>>>> 	[email-masked] <mailto:[email-masked]> < Caution-mailto:[email-masked] <mailto:[email-masked]> >
>>>> 	Caution-https://www.ietf.org/mailman/listinfo/sacm <caution-https://www.ietf.org/mailman/listinfo/sacm> < Caution-
>>>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm> >
>>>> 
>>>> 
>>>>