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

From: Jerome Athias <[email-masked]>
Date: Sat, 4 Jun 2016 09:48:35 +0300

While the scenario provided by Adam is valid, if your concern is that
"the information beyond that" would be "supplemental endpoint
information":
I don't see a scenario where an endpoint management capability would
have to push -supplemental- information to the vulnerability
assessment capability (what would the vulnerability assessment
capability do with 'unknown' additional information)

So I think the issue is to change "the information beyond that" to
something like "the updated information"

2016-05-18 16:15 GMT+03:00 Haynes, Dan <[email-masked]>:
> 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)
>
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 7 Jun 2016 02:08:25 +0000

Based on the feedback, would the following rewrite of the paragraph help clarify things?

"In many cases, the endpoint information...Under certain deployment scenarios, as
the vulnerability management capability processes vulnerability detection data over
time, the endpoint management capability may learn about additional detection 
information that it was previously not collecting and push that information to the 
vulnerability management capability where it can support future assessments. The 
pushing of this data may potentially be driven by some trigger (e.g., change 
in software inventory, policy, network connectivity status, etc.)."

While this potentially creates a coupling between the vulnerability management capability and the endpoint management capability, as written, I think it will be left to the implementer of those capabilities to decide.  I think the point is just that you could do something like this to improve the vulnerability assessment.  

If we still don't have consensus on this, another approach might be to just remove this text all together as I don't think doing so would preclude an implementer from supporting functionality like this in their product.

Thoughts?

Thanks,

Danny

> -----Original Message-----
> From: Jerome Athias [mailto:[email-masked]]
> Sent: Saturday, June 04, 2016 2:49 AM
> To: Haynes, Dan <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5
> - Change Detection with an Endpoint Management Capability
> 
> While the scenario provided by Adam is valid, if your concern is that "the
> information beyond that" would be "supplemental endpoint
> information":
> I don't see a scenario where an endpoint management capability would have
> to push -supplemental- information to the vulnerability assessment
> capability (what would the vulnerability assessment capability do with
> 'unknown' additional information)
> 
> So I think the issue is to change "the information beyond that" to something
> like "the updated information"
> 
> 
> 
> > 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
> >
> > 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
> >
> > 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?
> >
> >
> >
> > [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: Jerome Athias <[email-masked]>
Date: Tue, 7 Jun 2016 07:07:58 +0300

This rewrite is imho better
Thanks

On Tuesday, 7 June 2016, Haynes, Dan <[email-masked]> wrote:

> While this potentially creates a coupling between the vulnerability
> management capability and the endpoint management capability, as written, I
> think it will be left to the implementer of those capabilities to decide.
> I think the point is just that you could do something like this to improve
> the vulnerability assessment.
>
> If we still don't have consensus on this, another approach might be to
> just remove this text all together as I don't think doing so would preclude
> an implementer from supporting functionality like this in their product.
>
> Thoughts?
>
> Thanks,
>
> Danny
>
> > From: Jerome Athias [mailto:[email-masked] <javascript:;>]
> > To: Haynes, Dan <[email-masked] <javascript:;>>
> > Cc: [email-masked] <javascript:;>
> "the
> > 2016-05-18 16:15 GMT+03:00 Haynes, Dan <[email-masked] <javascript:;>
> >:
> > > [email-masked] <javascript:;>

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 16 Jun 2016 17:15:43 +0000

Off list, I received a suggested update to this text from Charles.  I was hoping to discuss it at yesterday’s virtual interim meeting, however, I ran out of time.  As a result, I would like to propose the updated text as it seemed clearer and more concise than what I had proposed, but, says the same thing.

The new text would read as follows (based on the updated draft posted on 6/8/16 [1]).

"Supplemental collection of endpoint information for the purposes of…Over time, some new pieces of information that are needed during common types of assessments might be identified. Pre-assessment collection can be reconfigured to have this information delivered automatically. This avoids the need for regular supplemental collections to gather this information during assessments, streamlining the assessment process. Likewise, it might be observed that certain information delivered during pre-assessment collection is rarely used. In this case, it might be useful to stop pre-assessment collection of this information to reduce network and processing overhead. Instead, supplemental collection can be used to gather this data on the rare occasions when it is needed."

Please let me know your thoughts on this proposed text by Tuesday July 21st.

Thanks,

Danny

[1] https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario-00.txt

From: Jerome Athias [mailto:[email-masked]]
Sent: Tuesday, June 07, 2016 12:08 AM
To: Haynes, Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

On Tuesday, 7 June 2016, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:
Based on the feedback, would the following rewrite of the paragraph help clarify things?

Thoughts?

Thanks,

Danny

> From: Jerome Athias [mailto:[email-masked]<javascript:;>]
> To: Haynes, Dan <[email-masked]<javascript:;>>
> Cc: [email-masked]<javascript:;>
> 2016-05-18 16:15 GMT+03:00 Haynes, Dan <[email-masked]<javascript:;>>:
> > [email-masked]<javascript:;>

---

From: Adam Montville <[email-masked]>
Date: Fri, 17 Jun 2016 17:14:27 -0500

I really don’t want to be the one to bring this up, but are we forgetting our definition of “assessment”?  We borrow, and expand upon, the term from RFC5209.  Here’s what our terminology draft says:

Assessment: Defined in [RFC5209] as “the process of collecting posture for a set of capabilities on the endpoint (e.g. host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy.”  Within SACM the use of the term is expanded to support other uses of collected posture (e.g. reporting, network enforcement, vulnerability detection, license management).  The phrase “set of capabilities on the endpoint” includes: hardware and software installed on the endpoint.

But, in the text proposed, and in general, we are talking about collection in the context of *pre*-assessment.  So, a collection before “the process of collecting posture…”, which seems off to me.

Do we really mean to say, pre-evaluation?  Or, do we need “pre” anything?  There is data available at the time of evaluation or there is not.  If there is not, we go grab it, or indicate that it needs to be grabbed during the next collection opportunity, and we indicate whether it’s something we need to grab all the time, or just this once.

Thoughts?

Adam

> On Jun 16, 2016, at 12:15 PM, Haynes, Dan <[email-masked]> wrote:
> 
> [1] https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario-00.txt <https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario-00.txt>
> 
> 
> 
> On Tuesday, 7 June 2016, Haynes, Dan <[email-masked] <mailto:[email-masked]>> wrote:
> > From: Jerome Athias [mailto:[email-masked] <>]
> > To: Haynes, Dan <[email-masked] <>>
> > Cc: [email-masked] <>
> > 2016-05-18 16:15 GMT+03:00 Haynes, Dan <[email-masked] <>>:
> > > [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/>
> > > [email-masked] <>
> > > https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> > >

---

From: Jerome Athias <[email-masked]>
Date: Sat, 18 Jun 2016 09:38:16 +0300

IMHO the new text is improved, well done
Meantime, Adam's point needs to be reviewed regarding "pre" something
Moreover I changed a bit my mind thinking about this scenario:
1) unauthenticated assessment (voluntary or because credentials unknown/not
available)
2) add of credentials in the endpoint management (need for push? For
authenticated assessment)
3) updates of the credentials (push or pull to/by endpoint assessment)

Sorry if it's not valid scenario

On Thursday, 16 June 2016, Haynes, Dan <[email-masked]> wrote:

> Off list, I received a suggested update to this text from Charles.  I was
> hoping to discuss it at yesterday’s virtual interim meeting, however, I ran
> out of time.  As a result, I would like to propose the updated text as it
> seemed clearer and more concise than what I had proposed, but, says the
> same thing.
>
>
>
> "Supplemental collection of endpoint information for the purposes of…Over
> time, some new pieces of information that are needed during common types of
> assessments might be identified. Pre-assessment collection can be
> reconfigured to have this information delivered automatically. This avoids
> the need for regular supplemental collections to gather this information
> during assessments, streamlining the assessment process. Likewise, it might
> be observed that certain information delivered during pre-assessment
> collection is rarely used. In this case, it might be useful to stop
> pre-assessment collection of this information to reduce network and
> processing overhead. Instead, supplemental collection can be used to gather
> this data on the rare occasions when it is needed."
>
>
>
> *From:* Jerome Athias [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* Tuesday, June 07, 2016 12:08 AM
> *To:* Haynes, Dan <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
> #5 - Change Detection with an Endpoint Management Capability
>
>
>
> On Tuesday, 7 June 2016, Haynes, Dan <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 18 Jun 2016 13:32:34 +0200

This "pre-collection" could be in overlap with the already defined 
discovery task, which handles the un-targeted detection and re-detection 
of target endpoints, providing a basis for the collection task (in cases 
where the collector does not reside on the target endpoint).

If "pre-collection" is in fact the first targeted collection and the 
following supplemental collections are just further targeted 
collections, then those are all simply collection tasks regarding a 
target endpoint, which are aligned in a specific sequence due to an 
implied workflow - which we should make explicit.

At the moment, the term "collection" is associated with target 
endpoints. Maybe we do not want that? Maybe, a SACM component could 
"collect", for example, "reference values"/"could state" in the form of 
endpoint attributes, such as SWID provided by vendors stored in a 
repository?

It seems to me that we are talking about:

- endpoint attributes from or about a target endpoint (is-state)
- endpoint attributes from a repository (could-state / should-state)
- guidance (e.g. the how to collect, the where to collect from, specific 
sequence of tasks, etc.)

In some cases, all of three of them could be the exactly same content (a 
stale and overused but valid example: an IP-address with subnet 
descriptor), but that information element can be used for all three 
purposes - depending on the context.

It is important, I think, to specify the intended input and output of 
tasks - and by that what SACM components provide and consume in the end 
- while taking into account that three (or maybe there are more) 
contexts of information elements.

Grüße,

Henk

On 06/18/2016 12:14 AM, Adam Montville wrote:
> I really don’t want to be the one to bring this up, but are we
> forgetting our definition of “assessment”?  We borrow, and expand upon,
> the term from RFC5209.  Here’s what our terminology draft says:
>
> Assessment: Defined in [RFC5209] as “the process of collecting posture
> for a set of capabilities on the endpoint (e.g. host-based firewall)
> such that the appropriate validators may evaluate the posture against
> compliance policy.”  Within SACM the use of the term is expanded to
> support other uses of collected posture (e.g. reporting, network
> enforcement, vulnerability detection, license management).  The phrase
> “set of capabilities on the endpoint” includes: hardware and software
> installed on the endpoint.
>
> But, in the text proposed, and in general, we are talking about
> collection in the context of *pre*-assessment.  So, a collection before
> “the process of collecting posture…”, which seems off to me.
>
> Do we really mean to say, pre-evaluation?  Or, do we need “pre”
> anything?  There is data available at the time of evaluation or there is
> not.  If there is not, we go grab it, or indicate that it needs to be
> grabbed during the next collection opportunity, and we indicate whether
> it’s something we need to grab all the time, or just this once.
>
> Thoughts?
>
> Adam
>
>
>
>> On Jun 16, 2016, at 12:15 PM, Haynes, Dan <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Off list, I received a suggested update to this text from Charles.  I
>> was hoping to discuss it at yesterday’s virtual interim meeting,
>> however, I ran out of time.  As a result, I would like to propose the
>> updated text as it seemed clearer and more concise than what I had
>> proposed, but, says the same thing.
>> "Supplemental collection of endpoint information for the purposes
>> of…Over time, some new pieces of information that are needed during
>> common types of assessments might be identified. Pre-assessment
>> collection can be reconfigured to have this information delivered
>> automatically. This avoids the need for regular supplemental
>> collections to gather this information during assessments,
>> streamlining the assessment process. Likewise, it might be observed
>> that certain information delivered during pre-assessment collection is
>> rarely used. In this case, it might be useful to stop pre-assessment
>> collection of this information to reduce network and processing
>> overhead. Instead, supplemental collection can be used to gather this
>> data on the rare occasions when it is needed."
>> Please let me know your thoughts on this proposed text by Tuesday July
>> 21^st .
>> Thanks,
>>
>> Danny
>> [1]https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario-00.txt
>> *From:*Jerome Athias [mailto:[email-masked]]
>> *Sent:*Tuesday, June 07, 2016 12:08 AM
>> *To:*Haynes, Dan <[email-masked] <mailto:[email-masked]>>
>> *Cc:[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario
>> Issue #5 - Change Detection with an Endpoint Management Capability
>> <mailto:[email-masked]>> wrote:
>>
>>     While this potentially creates a coupling between the
>>     vulnerability management capability and the endpoint management
>>     capability, as written, I think it will be left to the implementer
>>     of those capabilities to decide.  I think the point is just that
>>     you could do something like this to improve the vulnerability
>>     assessment.
>>
>>     If we still don't have consensus on this, another approach might
>>     be to just remove this text all together as I don't think doing so
>>     would preclude an implementer from supporting functionality like
>>     this in their product.
>>
>>     Thoughts?
>>
>>     Thanks,
>>
>>     Danny
>>
>>     > Cc:[email-masked]
>>     > > If you have any thoughts on this issue, please provide
>>     feedback by May
>>     > 31st.
>>     [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/
>> [email-masked] <mailto:[email-masked]>

---

From: Ira McDonald <[email-masked]>
Date: Sat, 18 Jun 2016 09:41:33 -0400

Hi,

I share Adam's distaste for "pre-" anything.

Perhaps "external collection" - defined as simply using any non-SACM
protocol to forward endpoint posture to a SACM Collector (in this case,
e.g., a NEA Server)?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Jun 17, 2016 at 6:14 PM, Adam Montville <[email-masked]>
wrote:

> I really don’t want to be the one to bring this up, but are we forgetting
> our definition of “assessment”?  We borrow, and expand upon, the term from
> RFC5209.  Here’s what our terminology draft says:
>
> Assessment: Defined in [RFC5209] as “the process of collecting posture for
> a set of capabilities on the endpoint (e.g. host-based firewall) such that
> the appropriate validators may evaluate the posture against compliance
> policy.”  Within SACM the use of the term is expanded to support other uses
> of collected posture (e.g. reporting, network enforcement, vulnerability
> detection, license management).  The phrase “set of capabilities on the
> endpoint” includes: hardware and software installed on the endpoint.
>
> But, in the text proposed, and in general, we are talking about collection
> in the context of *pre*-assessment.  So, a collection before “the process
> of collecting posture…”, which seems off to me.
>
> Do we really mean to say, pre-evaluation?  Or, do we need “pre” anything?
> There is data available at the time of evaluation or there is not.  If
> there is not, we go grab it, or indicate that it needs to be grabbed during
> the next collection opportunity, and we indicate whether it’s something we
> need to grab all the time, or just this once.
>
> Thoughts?
>
> Adam
>
>
>
> <[email-masked]>]
> *To:* Haynes, Dan <[email-masked]>
> *Cc:* [email-masked]

---

From: Adam Montville <[email-masked]>
Date: Sat, 18 Jun 2016 12:35:42 -0500

My concern does not stem from using the prefix “pre”, as much as it is about the definition of the term assessment and how we’re using pre-assessment often, which turns into “collecting before the process of collecting”, which is confusing at best.

The situation we are looking at feels very much like a cache miss.  We look for some information in one place and don’t find it, so we have to go fetch it from somewhere else.

> On Jun 18, 2016, at 8:41 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Fri, Jun 17, 2016 at 6:14 PM, Adam Montville <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>> <[email-masked] <mailto:[email-masked]>>]

---

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 24 Jun 2016 11:19:49 +0000

I just reviewed the latest version of the I-D and found only one occurrence of “pre-assessment” in Appendix I.3 which says:

“Within the SACM Architecture, the assessment task would be handled by the Evaluator component.  If pre-assessment data is used, this would be stored on and obtained from a Data Store component.”

I think this could easily be re-written to remove “pre-assessment” and say:

“Within the SACM Architecture, the assessment task would be handled by the Evaluator component. If previously collected data is used, it would be obtained from a Data Store component.”

I think we could also rewrite the latest revision of the text (from my Jun 16th message) to read as follows (which also makes use of SACM tasks which was suggested at the last virtual interim meeting).

"The collection of additional endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by 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."
Let me know what you think of these changes.  If they seem reasonable, I can integrate them into the next revision of the I-D and we can close out this issue.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Saturday, June 18, 2016 1:36 PM
To: Ira McDonald <[email-masked]>
Cc: Haynes, Dan <[email-masked]>; Jerome Athias <[email-masked]>; [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability

On Jun 18, 2016, at 8:41 AM, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

On Fri, Jun 17, 2016 at 6:14 PM, Adam Montville <[email-masked]<mailto:[email-masked]>>
wrote:

Thoughts?

Adam

On Jun 16, 2016, at 12:15 PM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:

The new text would read as follows (based on the updated draft posted on
6/8/16 [1]).

Please let me know your thoughts on this proposed text by Tuesday July 21
st.

Thanks,

Danny

*From:* Jerome Athias [mailto:[email-masked]
<[email-masked]<mailto:[email-masked]>>]
*Sent:* Tuesday, June 07, 2016 12:08 AM
*To:* Haynes, Dan <[email-masked]<mailto:[email-masked]>>
*Cc:* [email-masked]<mailto:[email-masked]>
*Subject:* Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
#5 - Change Detection with an Endpoint Management Capability

Based on the feedback, would the following rewrite of the paragraph help
clarify things?

"In many cases, the endpoint information...Under certain deployment
scenarios, as
the vulnerability management capability processes vulnerability detection
data over
time, the endpoint management capability may learn about additional
detection
information that it was previously not collecting and push that
information to the
vulnerability management capability where it can support future
assessments. The
pushing of this data may potentially be driven by some trigger (e.g.,
change
in software inventory, policy, network connectivity status, etc.)."

Thoughts?

Thanks,

Danny

-----Original Message-----
From: Jerome Athias [mailto:[email-masked]]
Sent: Saturday, June 04, 2016 2:49 AM
To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
#5

something

2016-05-18 16:15 GMT+03:00 Haynes, Dan <[email-masked]<mailto:[email-masked]>>:

following text from the Vulnerability Assessment Scenario
(specifically the

last sentence).

changes.”

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

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

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

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

---

From: Jerome Athias <[email-masked]>
Date: Fri, 24 Jun 2016 15:01:22 +0300

Sounds good for me
Thank you for your engagement

On Friday, 24 June 2016, Haynes, Dan <[email-masked]> wrote:

> I just reviewed the latest version of the I-D and found only one
> occurrence of “pre-assessment” in Appendix I.3 which says:
>
>
>
> “Within the SACM Architecture, the assessment task would be handled by the
> Evaluator component.  If pre-assessment data is used, this would be stored
> on and obtained from a Data Store component.”
>
>
>
> “Within the SACM Architecture, the assessment task would be handled by the
> Evaluator component. If previously collected data is used, it would be
> obtained from a Data Store component.”
>
>
>
> I think we could also rewrite the latest revision of the text (from my
> Jun 16th message) to read as follows (which also makes use of SACM tasks
> which was suggested at the last virtual interim meeting).
>
>
>
> "The collection of additional endpoint information for the purpose of
> vulnerability assessment does not necessarily need to be a pull by 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."
>
> Let me know what you think of these changes.  If they seem reasonable, I
> can integrate them into the next revision of the I-D and we can close out
> this issue.
>
>
>
> Thanks,
>
> Danny
>
>
>
> *From:* Adam Montville [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* Saturday, June 18, 2016 1:36 PM
> *To:* Ira McDonald <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* Haynes, Dan <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Jerome Athias <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> My concern does not stem from using the prefix “pre”, as much as it is
> about the definition of the term assessment and how we’re using
> pre-assessment often, which turns into “collecting before the process of
> collecting”, which is confusing at best.
>
>
>
> The situation we are looking at feels very much like a cache miss.  We
> look for some information in one place and don’t find it, so we have to go
> fetch it from somewhere else.
>
>
>
>
>
>
>
> On Jun 18, 2016, at 8:41 AM, Ira McDonald <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> Hi,
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> On Fri, Jun 17, 2016 at 6:14 PM, Adam Montville <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>]
> From: Jerome Athias [mailto:[email-masked]
> To: Haynes, Dan <[email-masked]
> Cc: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> 2016-05-18 16:15 GMT+03:00 Haynes, Dan <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 24 Jun 2016 08:43:07 -0400

Hi Danny,

+1

Cheers,
- Ira

On Fri, Jun 24, 2016 at 7:19 AM, Haynes, Dan <[email-masked]> wrote:

> *From:* Adam Montville [mailto:[email-masked]]
> *To:* Ira McDonald <[email-masked]>
> *Cc:* Haynes, Dan <[email-masked]>; Jerome Athias <
> [email-masked]>; [email-masked]
>
> [email-masked]>
> wrote:
>
>
> <[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Mon, 27 Jun 2016 15:31:58 -0500

+1 (contributor)

> On Jun 24, 2016, at 7:43 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Danny,
> 
> +1
> 
> Cheers,
> - Ira
> 
> 
> On Fri, Jun 24, 2016 at 7:19 AM, Haynes, Dan <[email-masked] <mailto:[email-masked]>> wrote:
> From: Adam Montville [mailto:[email-masked] <mailto:[email-masked]>]
> To: Ira McDonald <[email-masked] <mailto:[email-masked]>>
> Cc: Haynes, Dan <[email-masked] <mailto:[email-masked]>>; Jerome Athias <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 
> On Jun 18, 2016, at 8:41 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> Hi,
> 
> Winter  579 Park Place  Saline, MI  48176  734-944-0094 <tel:734-944-0094>
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434 <tel:906-494-2434>
> 
> 
> On Jun 16, 2016, at 12:15 PM, Haynes, Dan <[email-masked] <mailto:[email-masked]>> wrote:
> 
> *From:* Jerome Athias [mailto:[email-masked] <mailto:[email-masked]>
> *To:* Haynes, Dan <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> From: Jerome Athias [mailto:[email-masked] <mailto:[email-masked]>]
> To: Haynes, Dan <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> 2016-05-18 16:15 GMT+03:00 Haynes, Dan <[email-masked] <mailto:[email-masked]>>:
> 
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 28 Jun 2016 12:05:55 +0000

Thanks for the feedback Jerome, Ira, and Adam!

If anyone else has thoughts on this change, please let me know.  Otherwise, based on the feedback so far, I am planning to pull in the changes at the end of the week.

Thanks,

Danny

Sent: Monday, June 27, 2016 4:32 PM

+1 (contributor)

On Jun 24, 2016, at 7:43 AM, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:

Hi Danny,

+1
Cheers,
- Ira

On Fri, Jun 24, 2016 at 7:19 AM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:
I just reviewed the latest version of the I-D and found only one occurrence of “pre-assessment” in Appendix I.3 which says:

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, June 18, 2016 1:36 PM
To: Ira McDonald <[email-masked]<mailto:[email-masked]>>
Cc: Haynes, Dan <[email-masked]<mailto:[email-masked]>>; Jerome Athias <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi,

Cheers,
- Ira

Winter  579 Park Place  Saline, MI  48176  734-944-0094<tel:734-944-0094>
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<tel:906-494-2434>

Thoughts?

Adam

Thanks,

Danny

Thoughts?

Thanks,

Danny

-----Original Message-----
From: Jerome Athias [mailto:[email-masked]]
Sent: Saturday, June 04, 2016 2:49 AM
To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
#5

changes.”

Thanks,

Danny