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

Adam Montville <adam.w.montville@gmail.com> Mon, 27 June 2016 20:32 UTC

Return-Path: <adam.w.montville@gmail.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76CE12D8B5 for <sacm@ietfa.amsl.com>; Mon, 27 Jun 2016 13:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYAWwZzimERI for <sacm@ietfa.amsl.com>; Mon, 27 Jun 2016 13:32:03 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C429112D8B4 for <sacm@ietf.org>; Mon, 27 Jun 2016 13:32:02 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id f189so216830214oig.3 for <sacm@ietf.org>; Mon, 27 Jun 2016 13:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=PCuwI6Kxkck5+mACpCZ5/6h32Iqp9df/65eYlpQrxqI=; b=GqpZJc1u2cNwwxe6H4XsL32yQsG4JgaqxrFl8pGsIv5d3zEJoR5NR1g6ImV7W37/qr 91HaM0hNxrQ1BBD7J8uD50dVh+GlseRQ8rin9PM7flY2mIk1pZ/kqnBps9FOyL6HPxIp NRuixSagDVhikEeO3O/RQ1GTkUM7mdDYoz1rFRW6SjeXj9Y/gErlNdNJOWTMH+WIUOvh /c8jvsvZg+y3PQHl/Y4dj2g2S4uVRuSrO0mx9cYIn06gN46SV480jScr1IK+InVJ8SO/ TfEfu04IKUHLg+oXb7RDoUtBL3PMtbW0mloEJa9GKgsq1RRIfXg7aWfgOJsenM8SRCxN 2ocA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=PCuwI6Kxkck5+mACpCZ5/6h32Iqp9df/65eYlpQrxqI=; b=IPPSo/6ZVv01/vsFo7e1rfTtR+Iyr2DO52YAMq09fhJr+Wi3fF3x3GWN7sbpzqqr0y is7apbjQ9pX+zGpGkDj4RJrQy8T3UdizienPcqu+0kNY4Pk7diiCH58TgB2DKVkTJQjX QNjU9mj8RFVuoPzQHTyDFEvBdnkVhxyiimEBcjtE7jCzkoUN7wNMrXMY3l6qQ4dFZ1ot +BWDHlik+1J7gy+lhfkn3Fs+ocggCKY4RA0nIxH71Is1skEL8NOxmUMXYn/zN2+bcVNm /rPp7yjmKt5WONSC7BTAvSa0UbLAsjhQ0sJWzeZaInxWa2q+2gGho+5Y51BE2IzOfiyO oAEQ==
X-Gm-Message-State: ALyK8tLPgVixZR9hIuKJ0/pTDnOpGq1s7mQpatn02GgTkdyAGhaR3oYi6sWhHFw5mp+P9w==
X-Received: by 10.157.46.240 with SMTP id w103mr2094916ota.2.1467059522022; Mon, 27 Jun 2016 13:32:02 -0700 (PDT)
Received: from adams-mbp.attlocal.net (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by smtp.gmail.com with ESMTPSA id t17sm9601174ota.14.2016.06.27.13.31.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Jun 2016 13:32:00 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_29FBB12A-5A87-4B8F-9225-B2E274C0A8EF"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Adam Montville <adam.w.montville@gmail.com>
In-Reply-To: <CAN40gSu9zngd0FSRUZwyNyY+x1P6YwZQEO4fReOunanWi66mjQ@mail.gmail.com>
Date: Mon, 27 Jun 2016 15:31:58 -0500
Message-Id: <F7FFDC3F-537F-4FBE-B379-79C56676AC64@gmail.com>
References: <BY2PR09MB107855437DBFE3B22987B6A0A5490@BY2PR09MB1078.namprd09.prod.outlook.com> <CAA=AuEe8VpnAKZ7u5NMpK5O4qU8JWnoJsqTRhP9KjbC8bgACpQ@mail.gmail.com> <BY2PR09MB107834DEC2DE93DC7495740CA55D0@BY2PR09MB1078.namprd09.prod.outlook.com> <CAA=AuEfUJeUfmQ00pC1x1Pdtbog=qkfk=Lzyp6DpR4OKW4NPAA@mail.gmail.com> <BY2PR09MB1078CAB1881C9EF7E1106407A5560@BY2PR09MB1078.namprd09.prod.outlook.com> <69E56E0A-36E1-4529-B192-EDE4AE58E4DD@gmail.com> <CAN40gSuZ1+6-psCOEcbq-iDrOz2iReKLxmRv5QAkYNLx2FtwEw@mail.gmail.com> <F7FF0658-85D0-4FF6-B477-9C988E2912FA@gmail.com> <BY2PR09MB107887CC0CC80F1687967863A52E0@BY2PR09MB1078.namprd09.prod.outlook.com> <CAN40gSu9zngd0FSRUZwyNyY+x1P6YwZQEO4fReOunanWi66mjQ@mail.gmail.com>
To: Ira McDonald <blueroofmusic@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/DqaNDFv13fXQlB62egB_w1X9NzY>
Cc: Jerome Athias <athiasjerome@gmail.com>, "Haynes, Dan" <dhaynes@mitre.org>, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 20:32:07 -0000

+1 (contributor)

> On Jun 24, 2016, at 7:43 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:
> 
> 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/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>
> 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 <dhaynes@mitre.org <mailto:dhaynes@mitre.org>> 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:adam.w.montville@gmail.com <mailto:adam.w.montville@gmail.com>]
> Sent: Saturday, June 18, 2016 1:36 PM
> To: Ira McDonald <blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>>
> Cc: Haynes, Dan <dhaynes@mitre.org <mailto:dhaynes@mitre.org>>; Jerome Athias <athiasjerome@gmail.com <mailto:athiasjerome@gmail.com>>; sacm@ietf.org <mailto:sacm@ietf.org>
> 
> 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 <blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>> 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/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>
> 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 Fri, Jun 17, 2016 at 6:14 PM, Adam Montville <adam.w.montville@gmail.com <mailto:adam.w.montville@gmail.com>>
> 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 <dhaynes@mitre.org <mailto:dhaynes@mitre.org>> 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 <https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario-00.txt>
> 
> 
> 
> *From:* Jerome Athias [mailto:athiasjerome@gmail.com <mailto:athiasjerome@gmail.com>
> <athiasjerome@gmail.com <mailto:athiasjerome@gmail.com>>]
> *Sent:* Tuesday, June 07, 2016 12:08 AM
> *To:* Haynes, Dan <dhaynes@mitre.org <mailto:dhaynes@mitre.org>>
> *Cc:* sacm@ietf.org <mailto:sacm@ietf.org>
> *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 <dhaynes@mitre.org <mailto:dhaynes@mitre.org>> 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:athiasjerome@gmail.com <mailto:athiasjerome@gmail.com>]
> Sent: Saturday, June 04, 2016 2:49 AM
> To: Haynes, Dan <dhaynes@mitre.org <mailto:dhaynes@mitre.org>>
> Cc: sacm@ietf.org <mailto:sacm@ietf.org>
> 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 <dhaynes@mitre.org <mailto:dhaynes@mitre.org>>:
> 
> 
> 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/ <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
> sacm@ietf.org <mailto:sacm@ietf.org>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> _______________________________________________
> sacm mailing list
> sacm@ietf.org <mailto:sacm@ietf.org>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> 
> _______________________________________________
> sacm mailing list
> sacm@ietf.org <mailto:sacm@ietf.org>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
>