Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability
Jerome Athias <athiasjerome@gmail.com> Fri, 24 June 2016 12:01 UTC
Return-Path: <athiasjerome@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 2BA0A12B004 for <sacm@ietfa.amsl.com>; Fri, 24 Jun 2016 05:01:28 -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 thB9HvzwRUCd for <sacm@ietfa.amsl.com>; Fri, 24 Jun 2016 05:01:24 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 F388412B016 for <sacm@ietf.org>; Fri, 24 Jun 2016 05:01:23 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id j2so146954141vkg.2 for <sacm@ietf.org>; Fri, 24 Jun 2016 05:01:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oBYYAWxRU6y9soZBbHC+fyBtq8QGLRNB7r6UE0Rs3IU=; b=XCgwJMVV9tmzTCWTGZVrI0rkFO8TPZZrCskYBm7KIM/tHwcPdeWb8JsYiK3JYAf+a9 TMgL+rsRkjTx3fQE5AWfTbp7oO0hklBTP5Z89uVS5FNP451AFGxL2pzV7YSwCb1AI4Zc WKjakEuBP/Re22CZkhsFScGvJaocIWyFzzewS0CdaSqQM/AJoWBQ2yeSdE8N5z6EQEoX PhtxSv0+PV6jEyC2pdKM2t60xNA521jNVAaZr+WQOUlBf2zH2WyNYbNBNlp5WrMVfB3a IhTz3XzIp+rxkJWIdJh3bimLuOXyQIO9vkLq3aag1DQK2ZeykwdOhc3/ZoiMRFKoHwEr hFXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oBYYAWxRU6y9soZBbHC+fyBtq8QGLRNB7r6UE0Rs3IU=; b=S9QFOh0S7CWmiI2dopvGEpmOrF7GYUNrz3TaVxvysgW9wB8vBzopiydc717bdbEB/f HR3RrZ/p6sAUUUR/jMzgSDMMSc9S55uvfq/EznFabhRvtaQ9LWcYc+VChYL6P2n4/qG+ Bu9ieZlv+aLOBvxV7HLgCDi1M+YWvJIipkmVjE36shP3wureZhVRjkyVn8v9329yl25B fPWdl7geX3c73ZPloIbNpN5LrYNPnm00JUfSRjCr692jvt+Ot7szLHJpCfvQ5BQhNMie AJoeDMUBshsIhbtW5mZ0ZIVOe6uYOVAAiVZD0etkH2uhQEftSTDqztYfovICMDLT+iB4 fOmA==
X-Gm-Message-State: ALyK8tLCGUgVsUImLYSaL637U+8qx6Z+kMyBwmeKerXKw8gzL5oNVsOeOW/Dnpv14rVRv5/WyM01EM5Tpkf5cQ==
MIME-Version: 1.0
X-Received: by 10.31.14.145 with SMTP id 139mr1941182vko.137.1466769682934; Fri, 24 Jun 2016 05:01:22 -0700 (PDT)
Received: by 10.31.13.20 with HTTP; Fri, 24 Jun 2016 05:01:22 -0700 (PDT)
In-Reply-To: <BY2PR09MB107887CC0CC80F1687967863A52E0@BY2PR09MB1078.namprd09.prod.outlook.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>
Date: Fri, 24 Jun 2016 15:01:22 +0300
Message-ID: <CAA=AuEdTiBChe8o0YddUsmMHZ1Ne8t8sSTnhvZ9O0YTJi7vnVQ@mail.gmail.com>
From: Jerome Athias <athiasjerome@gmail.com>
To: "Haynes, Dan" <dhaynes@mitre.org>
Content-Type: multipart/alternative; boundary="001a11457312eb348e053604ed77"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/o1mUaZPhqGK6WrDx6lIopRWWnL4>
Cc: Ira McDonald <blueroofmusic@gmail.com>, Adam Montville <adam.w.montville@gmail.com>, "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: Fri, 24 Jun 2016 12:01:28 -0000
Sounds good for me Thank you for your engagement On Friday, 24 June 2016, Haynes, Dan <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 > <javascript:_e(%7B%7D,'cvml','adam.w.montville@gmail.com');>] > *Sent:* Saturday, June 18, 2016 1:36 PM > *To:* Ira McDonald <blueroofmusic@gmail.com > <javascript:_e(%7B%7D,'cvml','blueroofmusic@gmail.com');>> > *Cc:* Haynes, Dan <dhaynes@mitre.org > <javascript:_e(%7B%7D,'cvml','dhaynes@mitre.org');>>; Jerome Athias < > athiasjerome@gmail.com > <javascript:_e(%7B%7D,'cvml','athiasjerome@gmail.com');>>; sacm@ietf.org > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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/highnorthinc > mailto: blueroofmusic@gmail.com > <javascript:_e(%7B%7D,'cvml','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 17, 2016 at 6:14 PM, Adam Montville < > adam.w.montville@gmail.com > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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 > > > > *From:* Jerome Athias [mailto:athiasjerome@gmail.com > <javascript:_e(%7B%7D,'cvml','athiasjerome@gmail.com');> > <athiasjerome@gmail.com > <javascript:_e(%7B%7D,'cvml','athiasjerome@gmail.com');>>] > *Sent:* Tuesday, June 07, 2016 12:08 AM > *To:* Haynes, Dan <dhaynes@mitre.org > <javascript:_e(%7B%7D,'cvml','dhaynes@mitre.org');>> > *Cc:* sacm@ietf.org <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','athiasjerome@gmail.com');>] > Sent: Saturday, June 04, 2016 2:49 AM > To: Haynes, Dan <dhaynes@mitre.org > <javascript:_e(%7B%7D,'cvml','dhaynes@mitre.org');>> > Cc: sacm@ietf.org <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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/ > > [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 > sacm@ietf.org <javascript:_e(%7B%7D,'cvml','sacm@ietf.org');> > https://www.ietf.org/mailman/listinfo/sacm > > > _______________________________________________ > sacm mailing list > sacm@ietf.org <javascript:_e(%7B%7D,'cvml','sacm@ietf.org');> > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org <javascript:_e(%7B%7D,'cvml','sacm@ietf.org');> > https://www.ietf.org/mailman/listinfo/sacm > > >
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Haynes, Dan
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Haynes, Dan
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Adam Montville
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Jerome Athias
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Ira McDonald
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Haynes, Dan
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Adam Montville
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Ira McDonald
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Henk Birkholz
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Jerome Athias
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Adam Montville
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Haynes, Dan
- [sacm] FOR REVIEW: Vulnerability Assessment Scena… Haynes, Dan
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Adam Montville
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Wallace Sann
- Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulne… Wolfkiel, Joseph L CIV DISA ID (US)
- Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulne… Wallace Sann
- Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulne… Wolfkiel, Joseph L CIV DISA ID (US)
- Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulne… Schmidt, Charles M.
- Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulne… Waltermire, David A. (Fed)
- Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulne… Schmidt, Charles M.
- Re: [sacm] [Non-DoD Source] Re: FOR REVIEW: Vulne… Adam Montville
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Jerome Athias
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Haynes, Dan
- Re: [sacm] FOR REVIEW: Vulnerability Assessment S… Jerome Athias