Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability
"Haynes, Dan" <dhaynes@mitre.org> Tue, 28 June 2016 12:06 UTC
Return-Path: <dhaynes@mitre.org>
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 461D312DE48 for <sacm@ietfa.amsl.com>; Tue, 28 Jun 2016 05:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.625
X-Spam-Level:
X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.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 OrezAkN1gpc4 for <sacm@ietfa.amsl.com>; Tue, 28 Jun 2016 05:06:04 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id C87D412DE16 for <sacm@ietf.org>; Tue, 28 Jun 2016 05:06:03 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5F94E6C03AE; Tue, 28 Jun 2016 08:06:03 -0400 (EDT)
Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 3D4BB6C043C; Tue, 28 Jun 2016 08:06:03 -0400 (EDT)
Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 28 Jun 2016 08:06:02 -0400
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Tue, 28 Jun 2016 08:06:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QDmwgNxx2MmsR06UX1KShMDkgXAVw74SMqWwEPflYqw=; b=IWpkXWa6RUJ+lC4aSCGKkdiayrl7dhMF2uoFYoyHkIUF9HZEodkqerFzLLWjRdGu6agTjitnLWod3yAEA+6GGBEwzHlDoEo0uJKihnbPE8TjtFVKCAcBnmgCVIoVaBZ/zgTqa4iVzEfR9zRRp07PE0s9Z8hr76foKlRlbXDuMlw=
Received: from BY2PR09MB1078.namprd09.prod.outlook.com (10.166.116.10) by BY2PR09MB1079.namprd09.prod.outlook.com (10.166.116.11) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 28 Jun 2016 12:05:55 +0000
Received: from BY2PR09MB1078.namprd09.prod.outlook.com ([10.166.116.10]) by BY2PR09MB1078.namprd09.prod.outlook.com ([10.166.116.10]) with mapi id 15.01.0523.024; Tue, 28 Jun 2016 12:05:56 +0000
From: "Haynes, Dan" <dhaynes@mitre.org>
To: Adam Montville <adam.w.montville@gmail.com>, Ira McDonald <blueroofmusic@gmail.com>
Thread-Topic: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability
Thread-Index: AdGwcFvLuy7EoIEtTYaAcqw7unANPgNvMHSAAHxc8hAAFObXAAHecrngAD5pOoAAIGDrgAAILXcAASCK9UAAAvzEgACnP6gAACCKZiA=
Date: Tue, 28 Jun 2016 12:05:55 +0000
Message-ID: <BY2PR09MB107882EB6572D4BE51F32C4BA5220@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> <CAN40gSu9zngd0FSRUZwyNyY+x1P6YwZQEO4fReOunanWi66mjQ@mail.gmail.com> <F7FFDC3F-537F-4FBE-B379-79C56676AC64@gmail.com>
In-Reply-To: <F7FFDC3F-537F-4FBE-B379-79C56676AC64@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dhaynes@mitre.org;
x-originating-ip: [192.160.51.86]
x-ms-office365-filtering-correlation-id: fafa8919-f734-4d82-c9c5-08d39f4c8f6f
x-microsoft-exchange-diagnostics: 1; BY2PR09MB1079; 6:nwmx2xpFkhMAdeuvEY6fQwrpO45p0ERfJ6eBiDQf/3TtORFYFRn1RXqLIeN66yIF7bSuUIRNYBGZ9pVDyRRjpjkg65ezPQlYF3FyPvMYbnuQcliDTxMYQ5CzpWJOxA0lw77GXP3/kFDqwaGptwLrdvu6RYdPTalKsUJRkl1HibUaNlXaxUEIg5ZlYCmPiXbs+KbyaoQTbnuuqVa9Z0XLPRLSR89Ld54J5lmqx4sDcUHO5/DPj5a+jm9WCL77bvBEXjtfE/XPUwKC/la8YwDjRJcDzae2HyhRR0gBeVGPo8lbRBTIe0Dz+C5JPyPJeA3kxj6AwWV+QCkee9xNxbd88HIuYfFeMKT9TC6i8gqLpaQ=; 5:1QtwZEitafX4DnTwR7y3uBLxBUnyPy2tZI8M7RIi0LVjjtJHbaVdjj9eEZPuMzfbtN3Eiy5n+Y+V1D7qEv3XSiL4bD2QNIqR9Tfc4hCb7QfK3/PTwe2qzxyI6IYgnIrw+5Qd/9hAeatufXRYte4p+Q==; 24:L+K+mxO00NIIJIxaGaFtBcg9rz7VvgbdqTtvhrgrNvTX8siVlT8n5KPGfhF+D8/OXsm26XUGbeObhKD+m5O7Qmsg7y1IE06bJmob2keW+MU=; 7:1ZzltHgtVqVJS37+n1xO647NM4iBaV4vhAirydlYL1O+tTYyZDCLXxU6MzHoJ4dUbL0B5YqrBYtLWAuemXjNYEwulf0tvqlLhulioD5Lg25E2et4iuHIAtWSxCIX5yNsRaMEr4gSCp228+0JaL24wn9BASMi+yKh81Lt05NmYU6imilSORqKA7qb8HurYijcOmEX0mk+LbFVIDnimEuBh2oELnbYP6LI97WUDU9ySPkzyDDyebdPn6g6+8okCnIlNM0UhFVulJsWt86BwPzW7Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB1079;
x-microsoft-antispam-prvs: <BY2PR09MB10793C95FD5F0F74EFD12E07A5220@BY2PR09MB1079.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820)(111039206520245)(211936372134217)(100405760836317)(21748063052155)(211171220733660);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BY2PR09MB1079; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB1079;
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(76104003)(377424004)(5383002)(189002)(24454002)(51914003)(13464003)(377454003)(199003)(57704003)(478694002)(586003)(87936001)(76576001)(19625215002)(7846002)(68736007)(189998001)(8936002)(77096005)(790700001)(99286002)(101416001)(3846002)(76176999)(33656002)(102836003)(86362001)(19273905006)(2950100001)(2900100001)(19300405004)(122556002)(16236675004)(6116002)(10400500002)(50986999)(5001770100001)(7736002)(97736004)(92566002)(5003600100003)(7696003)(9686002)(7906003)(19580395003)(8676002)(81166006)(81156014)(19609705001)(105586002)(19580405001)(19617315012)(66066001)(74316001)(2906002)(5002640100001)(54356999)(3280700002)(15975445007)(106356001)(93886004)(3660700001)(4326007)(16351025005)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB1079; H:BY2PR09MB1078.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR09MB107882EB6572D4BE51F32C4BA5220BY2PR09MB1078namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 12:05:55.9848 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB1079
X-OriginatorOrg: mitre.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/Di014n1Wawa-fA__T2FsVYwG1w4>
Cc: Jerome Athias <athiasjerome@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: Tue, 28 Jun 2016 12:06:07 -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 From: Adam Montville [mailto:adam.w.montville@gmail.com] Sent: Monday, June 27, 2016 4:32 PM To: Ira McDonald <blueroofmusic@gmail.com> Cc: Haynes, Dan <dhaynes@mitre.org>; Jerome Athias <athiasjerome@gmail.com>; sacm@ietf.org Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #5 - Change Detection with an Endpoint Management Capability +1 (contributor) On Jun 24, 2016, at 7:43 AM, Ira McDonald <blueroofmusic@gmail.com<mailto: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/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/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 *From:* Jerome Athias [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] 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/ [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<mailto:sacm@ietf.org> https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org<mailto:sacm@ietf.org> https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org<mailto: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