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

[Ira McDonald <[e-mail]>]

Hi Danny,

+1

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: [e-mail]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Fri, Jun 24, 2016 at 7:19 AM, Haynes, Dan <[e-mail]> 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.”
>
>
>
> 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:[e-mail]]
> *Sent:* Saturday, June 18, 2016 1:36 PM
> *To:* Ira McDonald <[e-mail]>
> *Cc:* Haynes, Dan <[e-mail]>; Jerome Athias <
> [e-mail]>; [e-mail]
>
> *Subject:* Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
> #5 - Change Detection with an Endpoint Management Capability
>
>
>
> 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 <[e-mail]> wrote:
>
>
>
> 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: [e-mail]
> 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 <
> [e-mail]>
> 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 <[e-mail]> 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.
>
> 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 21
> st.
>
> Thanks,
>
> Danny
>
> [1] https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario-00.txt
>
>
>
> *From:* Jerome Athias [mailto:[e-mail]
> <[e-mail]>
> <[e-mail]>]
> *Sent:* Tuesday, June 07, 2016 12:08 AM
> *To:* Haynes, Dan <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue
> #5 - Change Detection with an Endpoint Management Capability
>
> This rewrite is imho better
> Thanks
>
> On Tuesday, 7 June 2016, Haynes, Dan <[e-mail]> wrote:
>
> 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:[e-mail]
> <[e-mail]>]
> Sent: Saturday, June 04, 2016 2:49 AM
> To: Haynes, Dan <[e-mail]>
> Cc: [e-mail]
> 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"
>
>
>
> 2016-05-18 16:15 GMT+03:00 Haynes, Dan <[e-mail]>:
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>
>
>