From nobody Wed Mar 1 07:42:54 2017 Return-Path: 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 648C7129572 for ; Wed, 1 Mar 2017 07:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 Hvupb6juHJOu for ; Wed, 1 Mar 2017 07:42:52 -0800 (PST) Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (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 054F5129593 for ; Wed, 1 Mar 2017 07:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=zmbf/xrZ+1de/w/fDU6IFY6MCTk=; b=hgc+FtiZBNrxe4+t Qedf7zhbm0hMVMT1s4ytxRLxrSk7qCm+Ni4hWfxGk5UbcQMFYlCIBoHhT0JpQBT+ zETq6gwCw1bqqw8NwxW8hf9/3RgyR0StXTUSoRnKBOMibLnhHmRK/hHOqTd21diS C9fwuXaxVF2UwMVq9g0G0b0ZN9w= Received: by filter0477p1las1.sendgrid.net with SMTP id filter0477p1las1-28627-58B6EBF3-50 2017-03-01 15:42:43.665815585 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id WuQfJgccSh2-ALkRgT0UsQ for ; Wed, 01 Mar 2017 15:42:43.317 +0000 (UTC) Date: Wed, 01 Mar 2017 07:42:43 -0800 From: Jerome Athias To: sacmwg/draft-ietf-sacm-coswid Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58b6ebf333499_28123f8efed3dc3c74939"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: athiasjerome X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9H6rXzGpPQITz8ikMri3C7WnpMcJyerCan6VmJE5fTFHCBMFedumS+4HSf+ lc7YhageIo5O4sde63iKAi5B+MZikenaKauzhjccBDBz32I32nWUMOvADOhasyQjkjOSgBp7KkzHbo vL42+N9zdCqmQ71V2R/Uh/7vRTHcY0FMJiwO9jYBbNJL9ctbpEfyFq+oJjW/2ZYYZfAtUlICj15mjQ 0= Archived-At: Cc: Subscribed Subject: [sacm] [sacmwg/draft-ietf-sacm-coswid] CDDL vs JAS (JAEN) (#1) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-coswid List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:42:53 -0000 ----==_mimepart_58b6ebf333499_28123f8efed3dc3c74939 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit More of a pointer/open question for the experts than an issue while I'm trying to figure out how potentially avoid potential duplication of efforts in the representation of overlapping schemas https://github.com/OpenC2-org/jaen -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-coswid/issues/1 ----==_mimepart_58b6ebf333499_28123f8efed3dc3c74939 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

More of a pointer/open question for the experts than an issue while I'm trying to figure out how potentially avoid potential duplication of efforts in the representation of overlapping schemas
https://github.com/OpenC2-org/jaen

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58b6ebf333499_28123f8efed3dc3c74939-- From nobody Thu Mar 2 04:05:36 2017 Return-Path: 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 25281129968 for ; Thu, 2 Mar 2017 04:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 tFeM_g3WGEik for ; Thu, 2 Mar 2017 04:05:26 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 2E0AF1296DE for ; Thu, 2 Mar 2017 04:05:26 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id x37so5742594ota.2 for ; Thu, 02 Mar 2017 04:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KbuUXggqsbWm1YLeNu7i2S4Znd1LyqxVLAZ1F4h1QMU=; b=LMLR4IBe1yO9ExH4E87MsBlqsnD+TKkqo9of1d/bpvUgcVuRRuYaG/vTK8ZCcoMS+u xuLW6VokmOk9fuyTw/cUdB1STCpyJnuGHj4GfGORB7VSwsYnQl6sMwcxwIABefmNtqYX tbawDyuzW36CK6DlUNPVoxZcFcYN2a7ZiM52XiuIOmbCE6BNegeBFuR0rI8T0fCVE+WE 4OnoHVA3bOTS4ETlAAM7TZXvb3fFt2VV+i4hrL00t056RfHxQ/2Dcb1iWnu+onYIroyG 59tMSExyQdOKa4pgozfqOKbzGEFuibnMSiplv2khlk6roOOr0IEyOCtE9aFFawtOmfkQ KlcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KbuUXggqsbWm1YLeNu7i2S4Znd1LyqxVLAZ1F4h1QMU=; b=TkVAI0WRKxCX73KFI98wiA0UjwGgflAyqqhnVYOCm2wnvJLROEVSz1OT8ZwJW/Q46z VjH8bkvPxTUAIb5N3sNDHhc9lMoso5tpHKDifD5NG65UIJccgS2/IFCce6ZrHtAV4QZT kJNiteCLgZzzDR+oF0thz4tZi3tMunsFm3duBxtKKi1BmGdyBwG/Q8PxXxyPOUYuWUDR kQJti5OvrdeRENHZnKiLVtQKTj4lOj5olBVvHwtvoiSjZ8nSgdlacT3JLMumLBB3FwtL x2z3RWCE8SbzTG/89vf4J61rTEPdlhUlY+1j6tm5ZYIYqdtlxsVeMQdqStl+32P9bhb9 U88Q== X-Gm-Message-State: AMke39kYfxAUcccOLpZ6TmrptZEWFYIW+gkxmKZ1G6W0oXdTMypZwvr4awP9WJCFKhOTvZK/KMi/cuPkrN1UcA== X-Received: by 10.157.56.180 with SMTP id p49mr6188048otc.165.1488456325074; Thu, 02 Mar 2017 04:05:25 -0800 (PST) MIME-Version: 1.0 References: <147f77a8-ea0f-ed43-f585-a70a231110fe@sit.fraunhofer.de> In-Reply-To: From: Adam Montville Date: Thu, 02 Mar 2017 12:05:14 +0000 Message-ID: To: Jerome Athias , "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary=001a11c10ec28516300549be3e30 Archived-At: Cc: Bill Munyan , Henk Birkholz , "" Subject: Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability Scenario Working Session) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:05:34 -0000 --001a11c10ec28516300549be3e30 Content-Type: text/plain; charset=UTF-8 Yes, I agree that identifying trigger points is useful and helps with clarity. What does such identification do for pushing data through our notional system? From my perspective, getting information through the system to answer questions is the hard part. Triggers seem relatively easy. Then, perhaps I'm missing something. On Tue, Feb 28, 2017 at 11:45 PM Jerome Athias wrote: > Yes correct. > I concur with your recommended approach of identifying the workflow entry > points. > > An example is a change in the endpoint repository, lets say event: a new > device is connected, one would want to trigger an assessment "a la NAC" > > > On Tue, Feb 28, 2017 at 9:31 PM, Waltermire, David A. (Fed) < > david.waltermire@nist.gov> wrote: > > Jerome, > > > > IMHO, we need to identify the places within the workflow where triggers > may occur. These are the workflow entry points. It would also be useful to > identify the events that may cause these triggers for clarity sake. > > > > Is this what you are saying? > > > > Regards, > > Dave > > > > > > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Jerome Athias > *Sent:* Tuesday, February 28, 2017 5:39 AM > *To:* Bill Munyan > *Cc:* Henk Birkholz ; < > sacm@ietf.org>; Adam Montville > *Subject:* Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability > Scenario Working Session) > > > > Greetings, > > > > So taking IACD (Ref [0] Appendix A1) as an example for illustration, would > that help to first list triggering "events"/preconditions? > > > > Regards > > > > [0] > https://secwww.jhuapl.edu/iacdcommunityday/Resources/IACD%20Baseline%20Reference%20Architecture%20-%20Final%20PR.pdf > > > > > > > > On Mon, Feb 6, 2017 at 5:17 PM, Bill Munyan > wrote: > > I wanted to clarify one assumption I have been making when viewing the > diagram. I am viewing the overall vulnerability scenario as a series of > event-driven use-cases, with this diagram simply depicting one of those > use-cases: When new VDD is introduced into the scenario. > > > > Feasibly, a number of different events could trigger entry into the > vulnerability scenario, such as a "staleness trigger", or a "new endpoint > added trigger", and many more. Each of these events could (and should) > have their own diagram outlining how the components interact to request > new/updated VDD, determine the endpoints which should be assessed, and what > to do with their results. As such, each of the components in the diagrams > can be seen as conceptual, allowing for implementers to determine how best > to consolidate components for their use. > > > > Please bash my thought process if I'm way off on this, but I thought it > might help in this discussion, because it seems like some of the > "disagreement" in the diagram is stemming from "events" which aren't > necessarily applicable to this particular "event use-case". > > > > Cheers, > > -Bill M. > > > > > > On Fri, Feb 3, 2017 at 5:19 PM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > Also inline. I hope it is still readable. > > On 02/03/2017 10:55 PM, Adam Montville wrote: > > Thanks for chiming in Henk. I'll go inline. Nothing being said as > chair. Just making observations. > > On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz > > wrote: > > Hi group, > > to recap my understanding: > > There will be trigger conditions that initiate collections of fresh > endpoint attributes (from which endpoint posture can be derived) from a > target endpoint. > > The obvious trigger condition that an asserting component (in every > diagram, I think, that is the Vulnerability Assessor. This assumption > is > based on the interpretation of the diagram, not based on the name of > the > component). From my point of view, in order to assert that a known > record is, for example, "stale" (aka does not satisfy an declarative > guidance that expresses the quality of freshness) or, as another > example, is not yet created the Vulnerability Assessor requires an > always up-to-date and exhaustive list of all Assessment Result records. > > > I would disagree. I have a record from the endpoint repository that it > timestamped as 3 days old. My policy says I should not rely on anything > older than 2 days old. Then the information is stale, and I instruct to > collect anew. > > > If the "I" is the Vulnerability Assessor, how does it always have the > Assessment Result records to check that declarative guidance? Or do you > propose (in v3) that the Endpoint Repository is checking that freshness > continuously and notifying the Vulnerability Assessor? > > > > > In consequence, I would assume that either the the Assessment Result > Repository component collapses with the Vulnerability Assessor or the > Vulnerability Assessor always retains a complete in-sync copy of the > Assessment Result Repository. > > > I would again disagree. It may well be that actual software collapses > these components into one, but it may be that there is a results > repository, which is used downstream from vulnerability assessment, into > which the assessor dumps results. > > > Yes, downstream records are dumped as a result in the corresponding repo. > But how does the information of not satisfying declarative guidance (a > result got stale) makes it "upstream" again to trigger collection - > including imperative guidance what to collect (what just got stale)? > > > Consider when we have configuration assessment down the road. Would we > then have a vulnerability assessor and a configuration assessor each > with their own repository conceptually, or would we be better off with > one "results repository"? I think the one. > > > It depends on scalability, I guess, but in the bare-bone first proof of > concept it seems to be feasible to collapse related pools of data into > justthe one, as there are no multiple consumers? > > > In practice, applications can choose to implement more than one > conceptual component. > > > Yes, that is why it is not a problem to collapse sets of functions into a > single component, in general. I hope this will remain a core feature of the > architecture at all time. > > > > > Alternatively, the Assessment Result Repository component is collapsed > with the Endpoint Repository (as proposed in diagram v3), in which case > now the Vulnerability Assessor to retain an continuously in-sync copy > of > the Endpoint Repository? If it is to trigger on the "stale" condition? > > > Again, I am not necessarily in favor of this viewpoint (and I'm not > necessarily against). The endpoint repository represents an interface > to acquire information about endpoints, which does not necessarily need > to include assessment results pertaining to those endpoints entirely. > > > But isn't that what is depicted in the diagram v3: the assessment results > repo is merged with endpoint repo? Maybe I am actually a little bit dense > right now :) > > > > > > The "keeping pools of data in-sync" seems to be introducing extra steps > in the work-flow. > > > Is it really data in sync? I understand what you're saying, but to me > the endpoint repository component is where we find assertions about the > endpoints, the assessors take those assertions and apply some logic to > pass judgement on the endpoint, and that judgement is stored in the > assessment results repository component. > > > I simply did not assume that a repository is more than a data store. If it > does continuous assessments of endpoint records it contains, it most > certainly can trigger a collection. Maybe the label of the component is > just misleading me here. > > > > > A pro for this would be that there could be multiple additional > consumers of Assessment Results that justify an interface that provides > that data to multiple parties. > > > Yes! There are in practice. Assessment results have downstream uses > outside the scope of our charter. > > > I thought so, but it is of course not part of the single snapshot diagram > and is therefore only implied at best. > > > > > A con for this is the universal "redundant data stores always pose a > source of complexity and hence risk of inconsistency" argument. > > Another point of view could be that the "evaluation task" is > independent > from the "trigger collection" (I just made that one up) task? Or maybe > it is associated with the worn component? > > Multiple emerging architectures include an orchestration component that > consumes notification of changes and derives appropriate actions that > it > can trigger or even conduct. Please note, I am not advocating to > introduce yet another component type (which would again add complexity, > error, scope creep...) :) > > > Bill mentioned something to me offline yesterday about orchestration. > In the vulnerability scenario, the orchestration is really being > performed by the assessor. > > > I think that in the reply above you illustrated that the Endpoint Repo > also does this assessment by checking for staleness? Or would it "just" > notify the Assessor to trigger a task? Why not trigger the collector > directly? What about the imperative guidance what to actually collect again? > > It seems that I really have a difficult time to wrap my head around the > proposal still. Please stay patient with me! :) > > > > > I just try to get a feasible grasp of the actual workflow that the > diagram is intended to represent. > > > The most basic path through the system. > > > > What am I missing? I actually am surprised that the Assessment Result > Repository merges with the Endpoint Repository and not the > Vulnerability > Assessor. What is the advantage? > > > I think we're still talking this one through. What's the advantage to > collapsing them at all? > > > Collapsing redundant pools of data is reducing redundancy :) Tasks that > depend on data that has to be acquired to be conducted benefit from high > availability and low latency. But I totally understand the "multiple > consumer" argument. > > > > > Best, > > Henk > > On 02/03/2017 05:43 PM, Adam Montville wrote: > > I thought I'd try to break this discussion out of it's former thread > > into one of its own, in case that makes it easier for folks to opine. > > The list of "components" or "function groups" seems reasonable to me. > > In practice, there *may* be a desire to have that software acting > as an > > endpoint repository also act as the repository for assessment > results. > > Or, these could be implemented in distinct services. > > > > What works for our purposes? > > > > Adam > > > > On Thu, Feb 2, 2017 at 10:40 AM Adam Montville > > > >> wrote: > > > > Once folks have had an opportunity to review the vulnerability > > scenario information we've been working on, what are your > thoughts > > on the main components we're presently focused on for this > narrowly > > scoped exercise? These are: > > > > Vulnerability Detection Data Repository > > Vulnerability Assessor > > Endpoint Repository > > Collector > > Assessment Result Repository > > Endpoint > > > > > > > > > > On Thu, Feb 2, 2017 at 10:28 AM Adam Montville > > > > > >> wrote: > > > > Hi Everyone. A few of us were able to make the vulnerability > > scenario call today and I think we had a good, though at > times > > spirited, discussion. We did record the meeting, which is > > available at [1]. We discussed the attached (annotated with > > some meeting notes) UML-ish sequence diagram. I had created > > that diagram to start a conversation (mission accomplished on > > that front I think) -- a conversation that would lead us > toward > > identifying the discrete components, interfaces, and > information > > required to be sent over those interfaces. The UML-ish > diagram > > represents a *single* flow through the system -- a "one-time" > > flow through the system. It ignores, for the time being, the > > continuous aspect of our charter in favor of getting started > > with the basics. Once we have a good understanding of the > > basics -- the components, interfaces, and information > required > > -- we can start look at a continuous monitoring sequence > (which > > could be represented as a distinct diagram) to determine what > > more we need. Then, I think, we can start drafting > solutions. > > > > One of the first issues is that we need to figure out if the > > components in the base flow are accurate. The main > suggestion > > we've tossed around so far is to combine the Endpoint > Repository > > with the Assessment Result Repository. > > > > We talked briefly about what interface we could use for > the VDD > > Repository, and naturally ROLIE came up as an option. > > > > We talked a little bit about the first "get endpoints" > operation > > between the Vulnerability Assessor and the Endpoint > Repository > > -- specifically about whether we should represent on this > > sequence diagram that information supporting a judgement of > > "stale" would be needed. > > > > We left open the time when we would next meet, favoring to > work > > that out on-list. Next week is TCG, so that may be > difficult; > > the following week is RSA, so that may be difficult. > > > > For those who were in attendance today, please add to this > note > > with your comments/corrections. > > > > Kind regards, > > > > Adam > > > > [1] > https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E > > > > On Mon, Jan 30, 2017 at 11:21 AM Adam Montville > > > > >>> > > wrote: > > > > Hi everyone. Just a friendly reminder that we are > planning > > to meet again this Thursday at the same time (2/2 @ 10am > > Eastern/3pm UTC) using SACM's meeting room at > > https://ietf.webex.com/meet/sacm. > > > > Kind regards, > > > > Adam > > > > > > On Thu, Jan 19, 2017 at 11:35 AM Adam Montville > > > > > > >> wrote: > > > > Hello. A few of us met informally today to discuss > the > > vulnerability scenario in some more detail with > the goal > > of maintaining the narrow focus on a vulnerability > > assessment slice through our notional environment. > We > > are tending to look at major components as black > boxes > > with interfaces and data format expectations, and > we are > > not necessarily concerned with how those components > do > > things internally/behind the scenes. > > > > The meeting was recorded (you can find it with > today's > > date at [1]). The topic of discussion was > primarily in > > the "phase 1" area of what Danny sent to the list not > > very long ago [2], and resulted in a *starting point* > > diagram [3]. > > > > The group who met today are (roughly) agreed on > the six > > main "components" represented in that diagram, but > also > > see that we have some work ahead. Specifically, we > > quickly recognized that some of the assumptions the > > vulnerability draft makes may be assumptions we > cannot > > afford to make and need to include in the > exploration. > > > > We thought it would be a good idea to have another > > informal discussion in a couple of weeks (February > 2) at > > the same time (10am Eastern / 3pm UTC), using the > same > > WebEx [4]. At that time we intend to roll > through the > > vulnerability assessment scenario assumptions in an > > effort to determine which ones can be left as > > assumptions and which ones cannot. Then we'll take > > another look at the diagram and work on its next > version. > > > > Stay tuned. > > > > Thanks to Danny, Stephen, and Jerome for joining and > > contributing! > > > > Kind regards, > > > > Adam > > > > > > [1] > https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E > > [2] > https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_OVLFhB5NSU58MXDM > > [3] > https://drive.google.com/open?id=0B8Wf9Un5FdCbMU5pdTRjejJtNHc > > [4] https://ietf.webex.com/meet/sacm > > > > > > > > _______________________________________________ > > sacm mailing list > > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > --001a11c10ec28516300549be3e30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I agree that identifying trigger points is useful and= helps with clarity.=C2=A0 What does such identification do for pushing dat= a through our notional system?=C2=A0 From my perspective, getting informati= on through the system to answer questions is the hard part.=C2=A0 Triggers = seem relatively easy.=C2=A0 Then, perhaps I'm missing something.
<= br>
On Tue, Feb 28, 2017 at 11:4= 5 PM Jerome Athias <athiasjero= me@gmail.com> wrote:
Yes correct.
I concur= with your recommended approach of identifying the workflow entry points.

An example is a change in the=C2=A0endpoint repository, lets say event: a new device is = connected, one would want to trigger an assessment "a la NAC"


On Tue, Feb 28, 2017 at 9:31 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:

Jerome,

=C2=A0

IMHO, we need to iden= tify the places within the workflow where triggers may occur. These are the= workflow entry points. It would also be useful to identify the events that may cause these triggers for clarity sake.

=C2=A0

Is this what you are = saying?

=C2=A0

Regards,

Dave

=C2=A0

=C2=A0

From: sacm [mailto:sacm-bounces@ietf.= org] On Behalf Of Jerome Athias
Sent: Tuesday, February 28, 2017 5:39 AM
To: Bill Munyan <bill.munyan.ietf@gm= ail.com>
Cc: Henk Birkholz <henk.birkhol= z@sit.fraunhofer.de>; <sacm@ietf.org> <sacm@ietf.org>; A= dam Montville <adam.w.montville@gmail.com>
Subject: Re: [sacm] Main Components: WAS (Re: No= tes on Vulnerability Scenario Working Session)

=C2=A0

Greetings,

=C2=A0

So taking IACD (Ref [0] Appendix A1) as an= example for illustration, would that help to first list triggering "e= vents"/preconditions?

=C2=A0

Regards

=C2=A0

[0]=C2=A0https://secwww.j= huapl.edu/iacdcommunityday/Resources/IACD%20Baseline%20Reference%20Architec= ture%20-%20Final%20PR.pdf

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 6, 2017 at 5:17 PM, Bill Munya= n <bill.munyan.ietf@gmail.com> wrote:

I wanted to clarify one assumption I h= ave been making when viewing the diagram.=C2=A0 I am viewing the overall vu= lnerability scenario as a series of event-driven use-cases, with this diagr= am simply depicting one of those use-cases: =C2=A0When new VDD is introduced into th= e scenario. =C2=A0

=C2=A0

Feasibly, a number of different events= could trigger entry into the vulnerability scenario, such as a "stale= ness trigger", or a "new endpoint added trigger", and many m= ore.=C2=A0 Each of these events could (and should) have their own diagram outlining how the components int= eract to request new/updated VDD, determine the endpoints which should be a= ssessed, and what to do with their results.=C2=A0 As such, each of the comp= onents in the diagrams can be seen as conceptual, allowing for implementers to determine how best to consolidate= components for their use.

=C2=A0

Please bash my thought process if I= 9;m way off on this, but I thought it might help in this discussion, becaus= e it seems like some of the "disagreement" in the diagram is stem= ming from "events" which aren't necessarily applicable to this particular "event use= -case".

=C2=A0

Cheers,=C2=A0

-Bill M.

=C2=A0

=C2=A0

On Fri, Feb 3, 2017 at 5:19 PM, Henk Birkh= olz <henk.birkholz@sit.fraunhofer.de> wrote:

Also inline. I hope it is still readable.<= br class=3D"gmail_msg">
On 02/03/2017 10:55 PM, Adam Montville wrote:

Thanks for chiming in Henk.=C2=A0 I'll= go inline.=C2=A0 Nothing being said as
chair.=C2=A0 Just making observations.

On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz
<henk.birkholz@sit.fraunhofer.de
<mailto:henk.birkholz@sit.fraunhofer.de>> wrote:=

=C2=A0 =C2=A0 Hi group,

=C2=A0 =C2=A0 to recap my understanding:

=C2=A0 =C2=A0 There will be trigger conditions that initiate collections of= fresh
=C2=A0 =C2=A0 endpoint attributes (from which endpoint posture can be deriv= ed) from a
=C2=A0 =C2=A0 target endpoint.

=C2=A0 =C2=A0 The obvious trigger condition that an asserting component (in= every
=C2=A0 =C2=A0 diagram, I think, that is the Vulnerability Assessor. This as= sumption is
=C2=A0 =C2=A0 based on the interpretation of the diagram, not based on the = name of the
=C2=A0 =C2=A0 component). From my point of view, in order to assert that a = known
=C2=A0 =C2=A0 record is, for example, "stale" (aka does not satis= fy an declarative
=C2=A0 =C2=A0 guidance that expresses the quality of freshness) or, as anot= her
=C2=A0 =C2=A0 example, is not yet created the Vulnerability Assessor requir= es an
=C2=A0 =C2=A0 always up-to-date and exhaustive list of all Assessment Resul= t records.


I would disagree.=C2=A0 I have a record from the endpoint repository that i= t
timestamped as 3 days old.=C2=A0 My policy says I should not rely on anythi= ng
older than 2 days old.=C2=A0 Then the information is stale, and I instruct = to
collect anew.


If the "I" is the Vulnerability Assessor, how does it always have= the Assessment Result records to check that declarative guidance? Or do yo= u propose (in v3) that the Endpoint Repository is checking that freshness c= ontinuously and notifying the Vulnerability Assessor?




=C2=A0 =C2=A0 In consequence, I would assume that either the the Assessment= Result
=C2=A0 =C2=A0 Repository component collapses with the Vulnerability Assesso= r or the
=C2=A0 =C2=A0 Vulnerability Assessor always retains a complete in-sync copy= of the
=C2=A0 =C2=A0 Assessment Result Repository.


I would again disagree.=C2=A0 It may well be that actual software collapses=
these components into one, but it may be that there is a results
repository, which is used downstream from vulnerability assessment, into which the assessor dumps results.


Yes, downstream records are dumped as a result in the corresponding repo. B= ut how does the information of not satisfying declarative guidance (a resul= t got stale) makes it "upstream" again to trigger collection - in= cluding imperative guidance what to collect (what just got stale)?


Consider when we have configuration assessment down the road.=C2=A0 Would w= e
then have a vulnerability assessor and a configuration assessor each
with their own repository conceptually, or would we be better off with
one "results repository"?=C2=A0 I think the one.


It depends on scalability, I guess, but in the bare-bone first proof of con= cept it seems to be feasible to collapse related pools of data into justthe= one, as there are no multiple consumers?


In practice, applications can choose to implement more than one
conceptual component.=


Yes, that is why it is not a problem to collapse sets of functions into a s= ingle component, in general. I hope this will remain a core feature of the = architecture at all time.=




=C2=A0 =C2=A0 Alternatively, the Assessment Result Repository component is = collapsed
=C2=A0 =C2=A0 with the Endpoint Repository (as proposed in diagram v3), in = which case
=C2=A0 =C2=A0 now the Vulnerability Assessor to retain an continuously in-s= ync copy of
=C2=A0 =C2=A0 the Endpoint Repository? If it is to trigger on the "sta= le" condition?


Again, I am not necessarily in favor of this viewpoint (and I'm not
necessarily against).=C2=A0 The endpoint repository represents an interface=
to acquire information about endpoints, which does not necessarily need
to include assessment results pertaining to those endpoints entirely.


But isn't that what is depicted in the diagram v3: the assessment resul= ts repo is merged with endpoint repo? Maybe I am actually a little bit dens= e right now :)





=C2=A0 =C2=A0 The "keeping pools of data in-sync" seems to be int= roducing extra steps
=C2=A0 =C2=A0 in the work-flow.


Is it really data in sync?=C2=A0 I understand what you're saying, but t= o me
the endpoint repository component is where we find assertions about the
endpoints, the assessors take those assertions and apply some logic to
pass judgement on the endpoint, and that judgement is stored in the
assessment results repository component.


I simply did not assume that a repository is more than a data store. If it = does continuous assessments of endpoint records it contains, it most certai= nly can trigger a collection. Maybe the label of the component is just misl= eading me here.




=C2=A0 =C2=A0 A pro for this would be that there could be multiple addition= al
=C2=A0 =C2=A0 consumers of Assessment Results that justify an interface tha= t provides
=C2=A0 =C2=A0 that data to multiple parties.


Yes!=C2=A0 There are in practice.=C2=A0 Assessment results have downstream = uses
outside the scope of our charter.


I thought so, but it is of course not part of the single snapshot diagram a= nd is therefore only implied at best.




=C2=A0 =C2=A0 A con for this is the universal "redundant data stores a= lways pose a
=C2=A0 =C2=A0 source of complexity and hence risk of inconsistency" ar= gument.

=C2=A0 =C2=A0 Another point of view could be that the "evaluation task= " is independent
=C2=A0 =C2=A0 from the "trigger collection" (I just made that one= up) task? Or maybe
=C2=A0 =C2=A0 it is associated with the worn component?

=C2=A0 =C2=A0 Multiple emerging architectures include an orchestration comp= onent that
=C2=A0 =C2=A0 consumes notification of changes and derives appropriate acti= ons that it
=C2=A0 =C2=A0 can trigger or even conduct. Please note, I am not advocating= to
=C2=A0 =C2=A0 introduce yet another component type (which would again add c= omplexity,
=C2=A0 =C2=A0 error, scope creep...) :)


Bill mentioned something to me offline yesterday about orchestration.
In the vulnerability scenario, the orchestration is really being
performed by the assessor.


I think that in the reply above you illustrated that the Endpoint Repo also= does this assessment by checking for staleness? Or would it "just&quo= t; notify the Assessor to trigger a task? Why not trigger the collector dir= ectly? What about the imperative guidance what to actually collect again?

It seems that I really have a difficult time to wrap my head around the pro= posal still. Please stay patient with me! :)




=C2=A0 =C2=A0 I just try to get a feasible grasp of the actual workflow tha= t the
=C2=A0 =C2=A0 diagram is intended to represent.


The most basic path through the system.



=C2=A0 =C2=A0 What am I missing? I actually am surprised that the Assessmen= t Result
=C2=A0 =C2=A0 Repository merges with the Endpoint Repository and not the Vu= lnerability
=C2=A0 =C2=A0 Assessor. What is the advantage?


I think we're still talking this one through.=C2=A0 What's the adva= ntage to
collapsing them at all?


Collapsing redundant pools of data is reducing redundancy :) Tasks that dep= end on data that has to be acquired to be conducted benefit from high avail= ability and low latency. But I totally understand the "multiple consum= er" argument.




=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 Henk

=C2=A0 =C2=A0 On 02/03/2017 05:43 PM, Adam Montville wrote:
=C2=A0 =C2=A0 > I thought I'd try to break this discussion out of it= 's former thread
=C2=A0 =C2=A0 > into one of its own, in case that makes it easier for fo= lks to opine.
=C2=A0 =C2=A0 > The list of "components" or "function gro= ups" seems reasonable to me.
=C2=A0 =C2=A0 > In practice, there *may* be a desire to have that softwa= re acting
=C2=A0 =C2=A0 as an
=C2=A0 =C2=A0 > endpoint repository also act as the repository for asses= sment results.
=C2=A0 =C2=A0 > Or, these could be implemented in distinct services.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What works for our purposes?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Thu, Feb 2, 2017 at 10:40 AM Adam Montville
=C2=A0 =C2=A0 > <adam.w.montville@gmail.com <mailto:= adam.w.montville@gmail.com>
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>>= ; wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Once folks have had an opportunity to= review the vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0scenario information we've been w= orking on, what are your thoughts
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0on the main components we're pres= ently focused on for this
=C2=A0 =C2=A0 narrowly
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0scoped exercise?=C2=A0 These are:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Vulnerability Detection Data Reposito= ry
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Vulnerability Assessor
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Endpoint Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Collector
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Assessment Result Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Endpoint
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Thu, Feb 2, 2017 at 10:28 AM Adam = Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<adam.w.montville@gmail.c= om
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com


=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>>= ; wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Everyone.=C2=A0 A fe= w of us were able to make the vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scenario call today and= I think we had a good, though at times
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spirited, discussion.= =C2=A0 We did record the meeting, which is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0available at [1].=C2=A0= We discussed the attached (annotated with
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some meeting notes) UML= -ish sequence diagram.=C2=A0 I had created
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that diagram to start a= conversation (mission accomplished on
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that front I think) -- = a conversation that would lead us
=C2=A0 =C2=A0 toward
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identifying the discret= e components, interfaces, and
=C2=A0 =C2=A0 information
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0required to be sent ove= r those interfaces.=C2=A0 The UML-ish
=C2=A0 =C2=A0 diagram
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0represents a *single* f= low through the system -- a "one-time"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flow through the system= .=C2=A0 It ignores, for the time being, the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continuous aspect of ou= r charter in favor of getting started
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the basics.=C2=A0 = Once we have a good understanding of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0basics -- the component= s, interfaces, and information required
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- we can start look at= a continuous monitoring sequence
=C2=A0 =C2=A0 (which
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0could be represented as= a distinct diagram) to determine what
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more we need.=C2=A0 The= n, I think, we can start drafting solutions.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One of the first issues= is that we need to figure out if the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0components in the base = flow are accurate.=C2=A0 The main suggestion
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we've tossed around= so far is to combine the Endpoint
=C2=A0 =C2=A0 Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the Assessment Res= ult Repository.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We talked briefly about= what interface we could use for
=C2=A0 =C2=A0 the VDD
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Repository, and natural= ly ROLIE came up as an option.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We talked a little bit = about the first "get endpoints"
=C2=A0 =C2=A0 operation
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between the Vulnerabili= ty Assessor and the Endpoint Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- specifically about w= hether we should represent on this
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sequence diagram that i= nformation supporting a judgement of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"stale" would= be needed.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We left open the time w= hen we would next meet, favoring to
=C2=A0 =C2=A0 work
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that out on-list.=C2=A0= Next week is TCG, so that may be difficult;
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the following week is R= SA, so that may be difficult.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For those who were in a= ttendance today, please add to this
=C2=A0 =C2=A0 note
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with your comments/corr= ections.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kind regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[1]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Jan 30, 2017 at= 11:21 AM Adam Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<adam.w.mon= tville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>

=C2=A0 =C2=A0 <mailto:adam.w.m= ontville@gmail.com <mailto:adam.w.montville@gmail.com&g= t;>>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi everyo= ne.=C2=A0 Just a friendly reminder that we are
=C2=A0 =C2=A0 planning
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to meet a= gain this Thursday at the same time (2/2 @ 10am
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Eastern/3= pm UTC) using SACM's meeting room at
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ietf.webex.com/meet/sacm.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kind rega= rds,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, J= an 19, 2017 at 11:35 AM Adam Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<adam.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:adam.w.montville@gmail.com


=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>>= ; wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Hello. A few of us met informally today to discuss the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability scenario in some more detail with
=C2=A0 =C2=A0 the goal
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0of maintaining the narrow focus on a vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0assessment slice through our notional environment.=C2=A0 We
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0are tending to look at major components as black boxes
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with interfaces and data format expectations, and
=C2=A0 =C2=A0 we are
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0not necessarily concerned with how those components do
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0things internally/behind the scenes.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The meeting was recorded (you can find it with today's
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0date at [1]).=C2=A0 The topic of discussion was
=C2=A0 =C2=A0 primarily in
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the "phase 1" area of what Danny sent to the list not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0very long ago [2], and resulted in a *starting point*
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0diagram [3].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The group who met today are (roughly) agreed on
=C2=A0 =C2=A0 the six
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0main "components" represented in that diagram, but
=C2=A0 =C2=A0 also
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0see that we have some work ahead.=C2=A0 Specifically, we
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0quickly recognized that some of the assumptions the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability draft makes may be assumptions we cannot
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0afford to make and need to include in the exploration.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0We thought it would be a good idea to have another
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0informal discussion in a couple of weeks (February
=C2=A0 =C2=A0 2) at
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the same time (10am Eastern / 3pm UTC), using the same
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0WebEx [4].=C2=A0 =C2=A0At that time we intend to roll
=C2=A0 =C2=A0 through the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability assessment scenario assumptions in an
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0effort to determine which ones can be left as
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0assumptions and which ones cannot.=C2=A0 Then we'll take
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0another look at the diagram and work on its next
=C2=A0 =C2=A0 version.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Stay tuned.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Thanks to Danny, Stephen, and Jerome for joining and
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0contributing!
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Kind regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[1]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[2]
=C2=A0 =C2=A0 https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_OVLFhB5NSU58MXDM<= br class=3D"gmail_msg"> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[3]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbMU5pdTRjejJtNHc
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[4] https://ietf.webex.com/meet/sacm
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > sacm mailing list

=C2=A0 =C2= =A0 > sacm@ietf.org <mailto:sacm@ietf.org>
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/= sacm
=C2=A0 =C2=A0 >


_______________________________________________
sacm mailing list
sacm= @ietf.org
https://www.ietf.org/mailman/listinfo/sacm

=C2=A0


_______________________________________________
sacm mailing list
sacm= @ietf.org
https://www.ietf.org/mailman/listinfo/sacm

=C2=A0


--001a11c10ec28516300549be3e30-- From nobody Thu Mar 2 04:33:47 2017 Return-Path: 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 D8771129513 for ; Thu, 2 Mar 2017 04:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 3fg_rEzqEvAW for ; Thu, 2 Mar 2017 04:33:42 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 5B72A1294F9 for ; Thu, 2 Mar 2017 04:33:42 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id f54so74384130uaa.1 for ; Thu, 02 Mar 2017 04:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zeG1vNOOkS6G4Iib+R/H3rQPCt99f3CJ8Ima//Ufb3M=; b=ENoHYDgGy8eNc5kjNwMFSHpZyOawB9XORZFGhj9BRTogyG6KhegOzWnI7WzLskPEwy Jj30LvhjYg3sN5LHYd+7k/wao3J9/f6bvEKKNJlOEqJQRDuAzYri3gIXCCvUubSMf7sC E+cS6YGkeuwtO0dkr88X2EdCPuXOJ3OjCZlqLHxDpp7Oz83j23T0KpvnreFK3iQAsLdq ZLh1h6smSlANQ5W8Rh9IL856YOAJvzfWYXMMG8JwUxowqBYxXUrCBPLwVXE+dnnx59C8 9QtmQw/k1aYsVv8+iDbFM4zrlER/6ZleYr252CKHHGbWaEdGz0QsgCzXXvxQ0thVLrk5 B6TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zeG1vNOOkS6G4Iib+R/H3rQPCt99f3CJ8Ima//Ufb3M=; b=NMU4lGks2qPJTSMPYcM6mUFEN62yd/nWGNbmd/GEnJqVdwdVxYEydkwBNjzfEC+qB7 lPva4vlWfKkMsmEaZU7Khp76tbwrnhbVHSQOY3uZhPHHUcuaAm9OYaRSuSC714H6VTQY o41na8rzfqwQfzQD8p+r7YxFO0W+KAJvJr9eoamvPWB4FWmrguAxVHJ7QQJ7CAC0yWBm xLpvyId02Jm1EpOnOUPNah3szxLm362Pmdt3Y1Bq6YQWfEtjGP/Iohpr4aBSQEkd1W/7 upQgy2fkAECVyXGlSPp7zzktu74RPBHCZLxCrRn1g0Cnfc+ZDB6djgUn3T+rkOw5wHLS jpyg== X-Gm-Message-State: AMke39lwu4yQqNfyYnBZZT04A5SVrx6/ERLTQBFvaU9BSRtpIjKIVtU0A/KAkX2zCZ+a6mJb3nXozp8J+EIImQ== X-Received: by 10.176.74.86 with SMTP id r22mr5663728uae.18.1488458021170; Thu, 02 Mar 2017 04:33:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.160.14 with HTTP; Thu, 2 Mar 2017 04:33:40 -0800 (PST) In-Reply-To: References: <147f77a8-ea0f-ed43-f585-a70a231110fe@sit.fraunhofer.de> From: Jerome Athias Date: Thu, 2 Mar 2017 15:33:40 +0300 Message-ID: To: Adam Montville Content-Type: multipart/alternative; boundary=f403045f8ee49d94c60549bea3a2 Archived-At: Cc: Bill Munyan , "Waltermire, David A. \(Fed\)" , "" , Henk Birkholz Subject: Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability Scenario Working Session) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:33:46 -0000 --f403045f8ee49d94c60549bea3a2 Content-Type: text/plain; charset=UTF-8 no, you're right and I agree. I was just trying to clarify that Henk and Bill assumptions were correct On Thu, Mar 2, 2017 at 3:05 PM, Adam Montville wrote: > Yes, I agree that identifying trigger points is useful and helps with > clarity. What does such identification do for pushing data through our > notional system? From my perspective, getting information through the > system to answer questions is the hard part. Triggers seem relatively > easy. Then, perhaps I'm missing something. > > On Tue, Feb 28, 2017 at 11:45 PM Jerome Athias > wrote: > >> Yes correct. >> I concur with your recommended approach of identifying the workflow entry >> points. >> >> An example is a change in the endpoint repository, lets say event: a new >> device is connected, one would want to trigger an assessment "a la NAC" >> >> >> On Tue, Feb 28, 2017 at 9:31 PM, Waltermire, David A. (Fed) < >> david.waltermire@nist.gov> wrote: >> >> Jerome, >> >> >> >> IMHO, we need to identify the places within the workflow where triggers >> may occur. These are the workflow entry points. It would also be useful to >> identify the events that may cause these triggers for clarity sake. >> >> >> >> Is this what you are saying? >> >> >> >> Regards, >> >> Dave >> >> >> >> >> >> *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Jerome Athias >> *Sent:* Tuesday, February 28, 2017 5:39 AM >> *To:* Bill Munyan >> *Cc:* Henk Birkholz ; < >> sacm@ietf.org>; Adam Montville >> *Subject:* Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability >> Scenario Working Session) >> >> >> >> Greetings, >> >> >> >> So taking IACD (Ref [0] Appendix A1) as an example for illustration, >> would that help to first list triggering "events"/preconditions? >> >> >> >> Regards >> >> >> >> [0] https://secwww.jhuapl.edu/iacdcommunityday/Resources/ >> IACD%20Baseline%20Reference%20Architecture%20-%20Final%20PR.pdf >> >> >> >> >> >> >> >> On Mon, Feb 6, 2017 at 5:17 PM, Bill Munyan >> wrote: >> >> I wanted to clarify one assumption I have been making when viewing the >> diagram. I am viewing the overall vulnerability scenario as a series of >> event-driven use-cases, with this diagram simply depicting one of those >> use-cases: When new VDD is introduced into the scenario. >> >> >> >> Feasibly, a number of different events could trigger entry into the >> vulnerability scenario, such as a "staleness trigger", or a "new endpoint >> added trigger", and many more. Each of these events could (and should) >> have their own diagram outlining how the components interact to request >> new/updated VDD, determine the endpoints which should be assessed, and what >> to do with their results. As such, each of the components in the diagrams >> can be seen as conceptual, allowing for implementers to determine how best >> to consolidate components for their use. >> >> >> >> Please bash my thought process if I'm way off on this, but I thought it >> might help in this discussion, because it seems like some of the >> "disagreement" in the diagram is stemming from "events" which aren't >> necessarily applicable to this particular "event use-case". >> >> >> >> Cheers, >> >> -Bill M. >> >> >> >> >> >> On Fri, Feb 3, 2017 at 5:19 PM, Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de> wrote: >> >> Also inline. I hope it is still readable. >> >> On 02/03/2017 10:55 PM, Adam Montville wrote: >> >> Thanks for chiming in Henk. I'll go inline. Nothing being said as >> chair. Just making observations. >> >> On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz >> > > wrote: >> >> Hi group, >> >> to recap my understanding: >> >> There will be trigger conditions that initiate collections of fresh >> endpoint attributes (from which endpoint posture can be derived) from >> a >> target endpoint. >> >> The obvious trigger condition that an asserting component (in every >> diagram, I think, that is the Vulnerability Assessor. This assumption >> is >> based on the interpretation of the diagram, not based on the name of >> the >> component). From my point of view, in order to assert that a known >> record is, for example, "stale" (aka does not satisfy an declarative >> guidance that expresses the quality of freshness) or, as another >> example, is not yet created the Vulnerability Assessor requires an >> always up-to-date and exhaustive list of all Assessment Result >> records. >> >> >> I would disagree. I have a record from the endpoint repository that it >> timestamped as 3 days old. My policy says I should not rely on anything >> older than 2 days old. Then the information is stale, and I instruct to >> collect anew. >> >> >> If the "I" is the Vulnerability Assessor, how does it always have the >> Assessment Result records to check that declarative guidance? Or do you >> propose (in v3) that the Endpoint Repository is checking that freshness >> continuously and notifying the Vulnerability Assessor? >> >> >> >> >> In consequence, I would assume that either the the Assessment Result >> Repository component collapses with the Vulnerability Assessor or the >> Vulnerability Assessor always retains a complete in-sync copy of the >> Assessment Result Repository. >> >> >> I would again disagree. It may well be that actual software collapses >> these components into one, but it may be that there is a results >> repository, which is used downstream from vulnerability assessment, into >> which the assessor dumps results. >> >> >> Yes, downstream records are dumped as a result in the corresponding repo. >> But how does the information of not satisfying declarative guidance (a >> result got stale) makes it "upstream" again to trigger collection - >> including imperative guidance what to collect (what just got stale)? >> >> >> Consider when we have configuration assessment down the road. Would we >> then have a vulnerability assessor and a configuration assessor each >> with their own repository conceptually, or would we be better off with >> one "results repository"? I think the one. >> >> >> It depends on scalability, I guess, but in the bare-bone first proof of >> concept it seems to be feasible to collapse related pools of data into >> justthe one, as there are no multiple consumers? >> >> >> In practice, applications can choose to implement more than one >> conceptual component. >> >> >> Yes, that is why it is not a problem to collapse sets of functions into a >> single component, in general. I hope this will remain a core feature of the >> architecture at all time. >> >> >> >> >> Alternatively, the Assessment Result Repository component is collapsed >> with the Endpoint Repository (as proposed in diagram v3), in which >> case >> now the Vulnerability Assessor to retain an continuously in-sync copy >> of >> the Endpoint Repository? If it is to trigger on the "stale" condition? >> >> >> Again, I am not necessarily in favor of this viewpoint (and I'm not >> necessarily against). The endpoint repository represents an interface >> to acquire information about endpoints, which does not necessarily need >> to include assessment results pertaining to those endpoints entirely. >> >> >> But isn't that what is depicted in the diagram v3: the assessment results >> repo is merged with endpoint repo? Maybe I am actually a little bit dense >> right now :) >> >> >> >> >> >> The "keeping pools of data in-sync" seems to be introducing extra >> steps >> in the work-flow. >> >> >> Is it really data in sync? I understand what you're saying, but to me >> the endpoint repository component is where we find assertions about the >> endpoints, the assessors take those assertions and apply some logic to >> pass judgement on the endpoint, and that judgement is stored in the >> assessment results repository component. >> >> >> I simply did not assume that a repository is more than a data store. If >> it does continuous assessments of endpoint records it contains, it most >> certainly can trigger a collection. Maybe the label of the component is >> just misleading me here. >> >> >> >> >> A pro for this would be that there could be multiple additional >> consumers of Assessment Results that justify an interface that >> provides >> that data to multiple parties. >> >> >> Yes! There are in practice. Assessment results have downstream uses >> outside the scope of our charter. >> >> >> I thought so, but it is of course not part of the single snapshot diagram >> and is therefore only implied at best. >> >> >> >> >> A con for this is the universal "redundant data stores always pose a >> source of complexity and hence risk of inconsistency" argument. >> >> Another point of view could be that the "evaluation task" is >> independent >> from the "trigger collection" (I just made that one up) task? Or maybe >> it is associated with the worn component? >> >> Multiple emerging architectures include an orchestration component >> that >> consumes notification of changes and derives appropriate actions that >> it >> can trigger or even conduct. Please note, I am not advocating to >> introduce yet another component type (which would again add >> complexity, >> error, scope creep...) :) >> >> >> Bill mentioned something to me offline yesterday about orchestration. >> In the vulnerability scenario, the orchestration is really being >> performed by the assessor. >> >> >> I think that in the reply above you illustrated that the Endpoint Repo >> also does this assessment by checking for staleness? Or would it "just" >> notify the Assessor to trigger a task? Why not trigger the collector >> directly? What about the imperative guidance what to actually collect again? >> >> It seems that I really have a difficult time to wrap my head around the >> proposal still. Please stay patient with me! :) >> >> >> >> >> I just try to get a feasible grasp of the actual workflow that the >> diagram is intended to represent. >> >> >> The most basic path through the system. >> >> >> >> What am I missing? I actually am surprised that the Assessment Result >> Repository merges with the Endpoint Repository and not the >> Vulnerability >> Assessor. What is the advantage? >> >> >> I think we're still talking this one through. What's the advantage to >> collapsing them at all? >> >> >> Collapsing redundant pools of data is reducing redundancy :) Tasks that >> depend on data that has to be acquired to be conducted benefit from high >> availability and low latency. But I totally understand the "multiple >> consumer" argument. >> >> >> >> >> Best, >> >> Henk >> >> On 02/03/2017 05:43 PM, Adam Montville wrote: >> > I thought I'd try to break this discussion out of it's former thread >> > into one of its own, in case that makes it easier for folks to >> opine. >> > The list of "components" or "function groups" seems reasonable to >> me. >> > In practice, there *may* be a desire to have that software acting >> as an >> > endpoint repository also act as the repository for assessment >> results. >> > Or, these could be implemented in distinct services. >> > >> > What works for our purposes? >> > >> > Adam >> > >> > On Thu, Feb 2, 2017 at 10:40 AM Adam Montville >> > >> > >> wrote: >> > >> > Once folks have had an opportunity to review the vulnerability >> > scenario information we've been working on, what are your >> thoughts >> > on the main components we're presently focused on for this >> narrowly >> > scoped exercise? These are: >> > >> > Vulnerability Detection Data Repository >> > Vulnerability Assessor >> > Endpoint Repository >> > Collector >> > Assessment Result Repository >> > Endpoint >> > >> > >> > >> > >> > On Thu, Feb 2, 2017 at 10:28 AM Adam Montville >> > > >> > >> >> >> wrote: >> > >> > Hi Everyone. A few of us were able to make the >> vulnerability >> > scenario call today and I think we had a good, though at >> times >> > spirited, discussion. We did record the meeting, which is >> > available at [1]. We discussed the attached (annotated with >> > some meeting notes) UML-ish sequence diagram. I had created >> > that diagram to start a conversation (mission accomplished >> on >> > that front I think) -- a conversation that would lead us >> toward >> > identifying the discrete components, interfaces, and >> information >> > required to be sent over those interfaces. The UML-ish >> diagram >> > represents a *single* flow through the system -- a >> "one-time" >> > flow through the system. It ignores, for the time being, >> the >> > continuous aspect of our charter in favor of getting started >> > with the basics. Once we have a good understanding of the >> > basics -- the components, interfaces, and information >> required >> > -- we can start look at a continuous monitoring sequence >> (which >> > could be represented as a distinct diagram) to determine >> what >> > more we need. Then, I think, we can start drafting >> solutions. >> > >> > One of the first issues is that we need to figure out if the >> > components in the base flow are accurate. The main >> suggestion >> > we've tossed around so far is to combine the Endpoint >> Repository >> > with the Assessment Result Repository. >> > >> > We talked briefly about what interface we could use for >> the VDD >> > Repository, and naturally ROLIE came up as an option. >> > >> > We talked a little bit about the first "get endpoints" >> operation >> > between the Vulnerability Assessor and the Endpoint >> Repository >> > -- specifically about whether we should represent on this >> > sequence diagram that information supporting a judgement of >> > "stale" would be needed. >> > >> > We left open the time when we would next meet, favoring to >> work >> > that out on-list. Next week is TCG, so that may be >> difficult; >> > the following week is RSA, so that may be difficult. >> > >> > For those who were in attendance today, please add to this >> note >> > with your comments/corrections. >> > >> > Kind regards, >> > >> > Adam >> > >> > [1] >> https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E >> > >> > On Mon, Jan 30, 2017 at 11:21 AM Adam Montville >> > > >> >> > >>> >> > wrote: >> > >> > Hi everyone. Just a friendly reminder that we are >> planning >> > to meet again this Thursday at the same time (2/2 @ 10am >> > Eastern/3pm UTC) using SACM's meeting room at >> > https://ietf.webex.com/meet/sacm. >> > >> > Kind regards, >> > >> > Adam >> > >> > >> > On Thu, Jan 19, 2017 at 11:35 AM Adam Montville >> > > >> > > >> >> >> wrote: >> > >> > Hello. A few of us met informally today to discuss >> the >> > vulnerability scenario in some more detail with >> the goal >> > of maintaining the narrow focus on a vulnerability >> > assessment slice through our notional environment. >> We >> > are tending to look at major components as black >> boxes >> > with interfaces and data format expectations, and >> we are >> > not necessarily concerned with how those components >> do >> > things internally/behind the scenes. >> > >> > The meeting was recorded (you can find it with >> today's >> > date at [1]). The topic of discussion was >> primarily in >> > the "phase 1" area of what Danny sent to the list >> not >> > very long ago [2], and resulted in a *starting >> point* >> > diagram [3]. >> > >> > The group who met today are (roughly) agreed on >> the six >> > main "components" represented in that diagram, but >> also >> > see that we have some work ahead. Specifically, we >> > quickly recognized that some of the assumptions the >> > vulnerability draft makes may be assumptions we >> cannot >> > afford to make and need to include in the >> exploration. >> > >> > We thought it would be a good idea to have another >> > informal discussion in a couple of weeks (February >> 2) at >> > the same time (10am Eastern / 3pm UTC), using the >> same >> > WebEx [4]. At that time we intend to roll >> through the >> > vulnerability assessment scenario assumptions in an >> > effort to determine which ones can be left as >> > assumptions and which ones cannot. Then we'll take >> > another look at the diagram and work on its next >> version. >> > >> > Stay tuned. >> > >> > Thanks to Danny, Stephen, and Jerome for joining and >> > contributing! >> > >> > Kind regards, >> > >> > Adam >> > >> > >> > [1] >> https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E >> > [2] >> https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_ >> OVLFhB5NSU58MXDM >> > [3] >> https://drive.google.com/open?id=0B8Wf9Un5FdCbMU5pdTRjejJtNHc >> > [4] https://ietf.webex.com/meet/sacm >> > >> > >> > >> > _______________________________________________ >> > sacm mailing list >> >> > sacm@ietf.org >> > https://www.ietf.org/mailman/listinfo/sacm >> > >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> >> >> >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >> >> >> >> >> --f403045f8ee49d94c60549bea3a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
no, you're right and I agree.
I was just trying to= clarify that Henk and Bill assumptions were correct

On Thu, Mar 2, 2017 at 3:05= PM, Adam Montville <adam.w.montville@gmail.com> wr= ote:
Yes, I agree that i= dentifying trigger points is useful and helps with clarity.=C2=A0 What does= such identification do for pushing data through our notional system?=C2=A0= From my perspective, getting information through the system to answer ques= tions is the hard part.=C2=A0 Triggers seem relatively easy.=C2=A0 Then, pe= rhaps I'm missing something.

On Tue, Feb 28, 2017 at = 11:45 PM Jerome Athias <athiasjerome@gmail.com> wrote:
Y= es correct.
I concur with you= r recommended approach of identifying the workflow entry points.

An exampl= e is a change in the=C2=A0endpoint repository, lets say event: a new device= is connected, one would want to trigger an assessment "a la NAC"=


On Tue, Feb= 28, 2017 at 9:31 PM, Waltermire, David A. (Fed) <david.w= altermire@nist.gov> wrote:

Jerome,=

=C2= =A0

IMHO, we need to identify the places within the work= flow where triggers may occur. These are the workflow entry points. It woul= d also be useful to identify the events that may cause these triggers for clarity sake.

=C2= =A0

Is this what you are saying?<= /span>

=C2= =A0

Regards,

Dave

=C2= =A0

=C2= =A0

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Jerome Athias=
Sent: Tuesday, February 28= , 2017 5:39 AM
To: Bill Munyan <bill.munyan.ietf@gmail.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>= ;; <sacm@ietf.org> <sacm@i= etf.org>; Adam Montville <adam.w.m= ontville@gmail.com>
Subject: Re: [sacm] Main C= omponents: WAS (Re: Notes on Vulnerability Scenario Working Session)

=C2=A0

Greetings,

=C2=A0

So taking IACD (Ref = [0] Appendix A1) as an example for illustration, would that help to first l= ist triggering "events"/preconditions?

=C2=A0

Regards

=C2=A0

[0]=C2=A0https://secwww.jhuapl.edu/iacdcommunityday= /Resources/IACD%20Baseline%20Reference%20Architecture%20-%20Final= %20PR.pdf

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 6, 2017 = at 5:17 PM, Bill Munyan <bill.munyan.ietf= @gmail.com> wrote:<= u class=3D"m_-7359019547289384325gmail_msg">

I wanted to clarify one assumption I have been making when viewing th= e diagram.=C2=A0 I am viewing the overall vulnerability scenario as a serie= s of event-driven use-cases, with this diagram simply depicting one of those use-cases: =C2=A0When new VDD is introduced into th= e scenario. =C2=A0

=C2=A0

Feasibly, a number of different events could trigger entry into the v= ulnerability scenario, such as a "staleness trigger", or a "= new endpoint added trigger", and many more.=C2=A0 Each of these events could (and should) have their own diagram outlining how the components int= eract to request new/updated VDD, determine the endpoints which should be a= ssessed, and what to do with their results.=C2=A0 As such, each of the comp= onents in the diagrams can be seen as conceptual, allowing for implementers to determine how best to consolidate= components for their use.=

=C2=A0

Please bash my thought process if I'm way off on this, but I thou= ght it might help in this discussion, because it seems like some of the &qu= ot;disagreement" in the diagram is stemming from "events" which aren't necessarily applicable to this particular "event use= -case".

=C2=A0

Cheers,=C2=A0

-Bill M.

=C2=A0

=C2=A0

On Fri, Feb 3, 2017 = at 5:19 PM, Henk Birkholz <henk.birk= holz@sit.fraunhofer.de> wrote:

Also inline. I hope = it is still readable.

On 02/03/2017 10:55 PM, Adam Montville wrote:

Thanks for chiming i= n Henk.=C2=A0 I'll go inline.=C2=A0 Nothing being said as
chair.=C2=A0 Just making observations.

On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz
<henk.birkholz@sit.fraunhofer.d= e
<mailto:henk.birkholz@sit.fraun= hofer.de>> wrote:

=C2=A0 =C2=A0 Hi group,

=C2=A0 =C2=A0 to recap my understanding:

=C2=A0 =C2=A0 There will be trigger conditions that initiate collections of= fresh
=C2=A0 =C2=A0 endpoint attributes (from which endpoint posture can be deriv= ed) from a
=C2=A0 =C2=A0 target endpoint.

=C2=A0 =C2=A0 The obvious trigger condition that an asserting component (in= every
=C2=A0 =C2=A0 diagram, I think, that is the Vulnerability Assessor. This as= sumption is
=C2=A0 =C2=A0 based on the interpretation of the diagram, not based on the = name of the
=C2=A0 =C2=A0 component). From my point of view, in order to assert that a = known
=C2=A0 =C2=A0 record is, for example, "stale" (aka does not satis= fy an declarative
=C2=A0 =C2=A0 guidance that expresses the quality of freshness) or, as anot= her
=C2=A0 =C2=A0 example, is not yet created the Vulnerability Assessor requir= es an
=C2=A0 =C2=A0 always up-to-date and exhaustive list of all Assessment Resul= t records.


I would disagree.=C2=A0 I have a record from the endpoint repository that i= t
timestamped as 3 days old.=C2=A0 My policy says I should not rely on anythi= ng
older than 2 days old.=C2=A0 Then the information is stale, and I instruct = to
collect anew.


If the "I" is the Vulnerability Assessor, how does it always have= the Assessment Result records to check that declarative guidance? Or do yo= u propose (in v3) that the Endpoint Repository is checking that freshness c= ontinuously and notifying the Vulnerability Assessor?




=C2=A0 =C2=A0 In consequence, I would assume that either the the Assessment= Result
=C2=A0 =C2=A0 Repository component collapses with the Vulnerability Assesso= r or the
=C2=A0 =C2=A0 Vulnerability Assessor always retains a complete in-sync copy= of the
=C2=A0 =C2=A0 Assessment Result Repository.


I would again disagree.=C2=A0 It may well be that actual software collapses=
these components into one, but it may be that there is a results
repository, which is used downstream from vulnerability assessment, into which the assessor dumps results.


Yes, downstream records are dumped as a result in the corresponding repo. B= ut how does the information of not satisfying declarative guidance (a resul= t got stale) makes it "upstream" again to trigger collection - in= cluding imperative guidance what to collect (what just got stale)?


Consider when we have configuration assessment down the road.=C2=A0 Would w= e
then have a vulnerability assessor and a configuration assessor each
with their own repository conceptually, or would we be better off with
one "results repository"?=C2=A0 I think the one.


It depends on scalability, I guess, but in the bare-bone first proof of con= cept it seems to be feasible to collapse related pools of data into justthe= one, as there are no multiple consumers?


In practice, applications can choose to implement more than one
conceptual component.


Yes, that is why it is not a problem to collapse sets of functions into a s= ingle component, in general. I hope this will remain a core feature of the = architecture at all time.<= u class=3D"m_-7359019547289384325gmail_msg">




=C2=A0 =C2=A0 Alternatively, the Assessment Result Repository component is = collapsed
=C2=A0 =C2=A0 with the Endpoint Repository (as proposed in diagram v3), in = which case
=C2=A0 =C2=A0 now the Vulnerability Assessor to retain an continuously in-s= ync copy of
=C2=A0 =C2=A0 the Endpoint Repository? If it is to trigger on the "sta= le" condition?


Again, I am not necessarily in favor of this viewpoint (and I'm not
necessarily against).=C2=A0 The endpoint repository represents an interface=
to acquire information about endpoints, which does not necessarily need
to include assessment results pertaining to those endpoints entirely.


But isn't that what is depicted in the diagram v3: the assessment resul= ts repo is merged with endpoint repo? Maybe I am actually a little bit dens= e right now :)





=C2=A0 =C2=A0 The "keeping pools of data in-sync" seems to be int= roducing extra steps
=C2=A0 =C2=A0 in the work-flow.


Is it really data in sync?=C2=A0 I understand what you're saying, but t= o me
the endpoint repository component is where we find assertions about the
endpoints, the assessors take those assertions and apply some logic to
pass judgement on the endpoint, and that judgement is stored in the
assessment results repository component.


I simply did not assume that a repository is more than a data store. If it = does continuous assessments of endpoint records it contains, it most certai= nly can trigger a collection. Maybe the label of the component is just misl= eading me here.




=C2=A0 =C2=A0 A pro for this would be that there could be multiple addition= al
=C2=A0 =C2=A0 consumers of Assessment Results that justify an interface tha= t provides
=C2=A0 =C2=A0 that data to multiple parties.


Yes!=C2=A0 There are in practice.=C2=A0 Assessment results have downstream = uses
outside the scope of our charter.


I thought so, but it is of course not part of the single snapshot diagram a= nd is therefore only implied at best.




=C2=A0 =C2=A0 A con for this is the universal "redundant data stores a= lways pose a
=C2=A0 =C2=A0 source of complexity and hence risk of inconsistency" ar= gument.

=C2=A0 =C2=A0 Another point of view could be that the "evaluation task= " is independent
=C2=A0 =C2=A0 from the "trigger collection" (I just made that one= up) task? Or maybe
=C2=A0 =C2=A0 it is associated with the worn component?

=C2=A0 =C2=A0 Multiple emerging architectures include an orchestration comp= onent that
=C2=A0 =C2=A0 consumes notification of changes and derives appropriate acti= ons that it
=C2=A0 =C2=A0 can trigger or even conduct. Please note, I am not advocating= to
=C2=A0 =C2=A0 introduce yet another component type (which would again add c= omplexity,
=C2=A0 =C2=A0 error, scope creep...) :)


Bill mentioned something to me offline yesterday about orchestration.
In the vulnerability scenario, the orchestration is really being
performed by the assessor.=


I think that in the reply above you illustrated that the Endpoint Repo also= does this assessment by checking for staleness? Or would it "just&quo= t; notify the Assessor to trigger a task? Why not trigger the collector dir= ectly? What about the imperative guidance what to actually collect again?

It seems that I really have a difficult time to wrap my head around the pro= posal still. Please stay patient with me! :)




=C2=A0 =C2=A0 I just try to get a feasible grasp of the actual workflow tha= t the
=C2=A0 =C2=A0 diagram is intended to represent.


The most basic path through the system.



=C2=A0 =C2=A0 What am I missing? I actually am surprised that the Assessmen= t Result
=C2=A0 =C2=A0 Repository merges with the Endpoint Repository and not the Vu= lnerability
=C2=A0 =C2=A0 Assessor. What is the advantage?


I think we're still talking this one through.=C2=A0 What's the adva= ntage to
collapsing them at all?


Collapsing redundant pools of data is reducing redundancy :) Tasks that dep= end on data that has to be acquired to be conducted benefit from high avail= ability and low latency. But I totally understand the "multiple consum= er" argument.




=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 Henk

=C2=A0 =C2=A0 On 02/03/2017 05:43 PM, Adam Montville wrote:
=C2=A0 =C2=A0 > I thought I'd try to break this discussion out of it= 's former thread
=C2=A0 =C2=A0 > into one of its own, in case that makes it easier for fo= lks to opine.
=C2=A0 =C2=A0 > The list of "components" or "function gro= ups" seems reasonable to me.
=C2=A0 =C2=A0 > In practice, there *may* be a desire to have that softwa= re acting
=C2=A0 =C2=A0 as an
=C2=A0 =C2=A0 > endpoint repository also act as the repository for asses= sment results.
=C2=A0 =C2=A0 > Or, these could be implemented in distinct services.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What works for our purposes?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Thu, Feb 2, 2017 at 10:40 AM Adam Montville
=C2=A0 =C2=A0 > <adam.w.montville@gma= il.com <mailto:adam.w.montville@gmail.com>
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Once folks have had an opportunity to= review the vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0scenario information we've been w= orking on, what are your thoughts
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0on the main components we're pres= ently focused on for this
=C2=A0 =C2=A0 narrowly
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0scoped exercise?=C2=A0 These are:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Vulnerability Detection Data Reposito= ry
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Vulnerability Assessor
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Endpoint Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Collector
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Assessment Result Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Endpoint
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Thu, Feb 2, 2017 at 10:28 AM Adam = Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<ad= am.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com


=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Everyone.=C2=A0 A fe= w of us were able to make the vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scenario call today and= I think we had a good, though at times
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spirited, discussion.= =C2=A0 We did record the meeting, which is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0available at [1].=C2=A0= We discussed the attached (annotated with
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some meeting notes) UML= -ish sequence diagram.=C2=A0 I had created
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that diagram to start a= conversation (mission accomplished on
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that front I think) -- = a conversation that would lead us
=C2=A0 =C2=A0 toward
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identifying the discret= e components, interfaces, and
=C2=A0 =C2=A0 information
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0required to be sent ove= r those interfaces.=C2=A0 The UML-ish
=C2=A0 =C2=A0 diagram
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0represents a *single* f= low through the system -- a "one-time"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flow through the system= .=C2=A0 It ignores, for the time being, the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continuous aspect of ou= r charter in favor of getting started
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the basics.=C2=A0 = Once we have a good understanding of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0basics -- the component= s, interfaces, and information required
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- we can start look at= a continuous monitoring sequence
=C2=A0 =C2=A0 (which
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0could be represented as= a distinct diagram) to determine what
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more we need.=C2=A0 The= n, I think, we can start drafting solutions.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One of the first issues= is that we need to figure out if the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0components in the base = flow are accurate.=C2=A0 The main suggestion
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we've tossed around= so far is to combine the Endpoint
=C2=A0 =C2=A0 Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the Assessment Res= ult Repository.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We talked briefly about= what interface we could use for
=C2=A0 =C2=A0 the VDD
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Repository, and natural= ly ROLIE came up as an option.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We talked a little bit = about the first "get endpoints"
=C2=A0 =C2=A0 operation
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between the Vulnerabili= ty Assessor and the Endpoint Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- specifically about w= hether we should represent on this
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sequence diagram that i= nformation supporting a judgement of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"stale" would= be needed.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We left open the time w= hen we would next meet, favoring to
=C2=A0 =C2=A0 work
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that out on-list.=C2=A0= Next week is TCG, so that may be difficult;
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the following week is R= SA, so that may be difficult.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For those who were in a= ttendance today, please add to this
=C2=A0 =C2=A0 note
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with your comments/corr= ections.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kind regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[1]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Jan 30, 2017 at= 11:21 AM Adam Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<adam.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>

=C2=A0 =C2=A0 <ma= ilto:adam.w.montville@gmail.com <= ;mailto:adam.w.montville@gmail.com&= gt;>>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi everyo= ne.=C2=A0 Just a friendly reminder that we are
=C2=A0 =C2=A0 planning
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to meet a= gain this Thursday at the same time (2/2 @ 10am
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Eastern/3= pm UTC) using SACM's meeting room at
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ietf.webex.com/meet/sacm.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kind rega= rds,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, J= an 19, 2017 at 11:35 AM Adam Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<adam.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:adam.w.montville@gmail.com


=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Hello. A few of us met informally today to discuss the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability scenario in some more detail with
=C2=A0 =C2=A0 the goal
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0of maintaining the narrow focus on a vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0assessment slice through our notional environment.=C2=A0 We
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0are tending to look at major components as black boxes
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with interfaces and data format expectations, and
=C2=A0 =C2=A0 we are
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0not necessarily concerned with how those components do
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0things internally/behind the scenes.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The meeting was recorded (you can find it with today's
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0date at [1]).=C2=A0 The topic of discussion was
=C2=A0 =C2=A0 primarily in
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the "phase 1" area of what Danny sent to the list not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0very long ago [2], and resulted in a *starting point*
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0diagram [3].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The group who met today are (roughly) agreed on
=C2=A0 =C2=A0 the six
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0main "components" represented in that diagram, but
=C2=A0 =C2=A0 also
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0see that we have some work ahead.=C2=A0 Specifically, we
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0quickly recognized that some of the assumptions the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability draft makes may be assumptions we cannot
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0afford to make and need to include in the exploration.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0We thought it would be a good idea to have another
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0informal discussion in a couple of weeks (February
=C2=A0 =C2=A0 2) at
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the same time (10am Eastern / 3pm UTC), using the same
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0WebEx [4].=C2=A0 =C2=A0At that time we intend to roll
=C2=A0 =C2=A0 through the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability assessment scenario assumptions in an
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0effort to determine which ones can be left as
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0assumptions and which ones cannot.=C2=A0 Then we'll take
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0another look at the diagram and work on its next
=C2=A0 =C2=A0 version.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Stay tuned.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Thanks to Danny, Stephen, and Jerome for joining and
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0contributing!
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Kind regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[1]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[2]
=C2=A0 =C2=A0 https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_OVLFhB5NSU5= 8MXDM
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[3]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbMU5pdTRjejJtNHc
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[4] https://ietf.webex.com/meet/sacm
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > sacm mailing list

=C2=A0 =C2=A0 > sacm@ietf.org <mailto:sacm@ietf.org>
=C2=A0 =C2=A0 > https://www.ietf= .org/mailman/listinfo/sacm
=C2=A0 =C2=A0 >


_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/l= istinfo/sacm

=C2=A0


_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/l= istinfo/sacm

=C2=A0



--f403045f8ee49d94c60549bea3a2-- From nobody Thu Mar 2 04:38:49 2017 Return-Path: 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 A7AF61294FB for ; Thu, 2 Mar 2017 04:38:48 -0800 (PST) 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 acZ5Ckux1l0o for ; Thu, 2 Mar 2017 04:38:45 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 50D52129503 for ; Thu, 2 Mar 2017 04:38:45 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id m124so38368254oig.1 for ; Thu, 02 Mar 2017 04:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TPXQ+WdZkZ5vV5sExAv6K/XiXdyAqRFBWnHZzau95O8=; b=mQSylMIcx92rRSbj0q6bEZlW7mFr/MTSt/76eDm03qfcrGnqL6F+d32ke9gYmxteyL c7ogZMnJahiWXZWFkaFJKvsYImFrF1BdFHznR708YILiQHoaC4w7cwbiv8RGb34Om1c5 QbL+o0EERjeQLkUgHcw+bFOXQF0Xr6LtbkoVUNs8qpIIhIV2Reg2lX9VDncuf7nqNaMk /PELNrmGvk06/tVlITJZSAOyJPwrvmhHkHMoGTbdBzrY+JeBNybNXb8b824jwp8AThZ9 8eLJM+XYYC2ydtyj+nBxjEL5yhaRJE6lwArV5Y/rF9l7/gdhsOD2flh21zyEaWowVhHa SAPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TPXQ+WdZkZ5vV5sExAv6K/XiXdyAqRFBWnHZzau95O8=; b=UCOlxcgBz2wn1frzEE+AHygUnqfsS8OLtRc6CIH7Px6x6TAwkP0RSQkJy/7g3eKf1/ bC5zV89rr9tCZc812PWdViBWtzfn/4cbhtmsd5noCa79tvbBR7qeSmFM9we79TM5NW2W 2wmjTqc7PhZpdpSjCO64TGh1W7rGSktiqAqn9gg7CKUtfiJCHqo0V/zOIbvCCW7GsbhB QFmYcL6acVrX8S7wprABmhPSr8ucsX9VnVtEJfrHRf+Zd+Rkhh2wohLkyOY2buXLcXA8 nRgRlohZXgTWk72CgShbuF19uOJ+welYRwJswwcWM4UXLISvi3qoCY3wvvyIqGqMKHSc KvAg== X-Gm-Message-State: AMke39kgH0C3/sOFPKthunqvJgpoStcy0Kq5J/OAAlCTN7o9AHuivEPkiN/TvwFAPcH52pxv8IEmmC4wC7umsQ== X-Received: by 10.202.107.143 with SMTP id g137mr6468829oic.163.1488458324275; Thu, 02 Mar 2017 04:38:44 -0800 (PST) MIME-Version: 1.0 References: <147f77a8-ea0f-ed43-f585-a70a231110fe@sit.fraunhofer.de> In-Reply-To: From: Adam Montville Date: Thu, 02 Mar 2017 12:38:33 +0000 Message-ID: To: Jerome Athias Content-Type: multipart/alternative; boundary=001a11417c44ae7a2c0549beb58b Archived-At: Cc: Bill Munyan , "Waltermire, David A. \(Fed\)" , "" , Henk Birkholz Subject: Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability Scenario Working Session) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:38:48 -0000 --001a11417c44ae7a2c0549beb58b Content-Type: text/plain; charset=UTF-8 Ah, I see. (That's what I get for not paying attention for too long) On Thu, Mar 2, 2017 at 6:33 AM Jerome Athias wrote: > no, you're right and I agree. > I was just trying to clarify that Henk and Bill assumptions were correct > > On Thu, Mar 2, 2017 at 3:05 PM, Adam Montville > wrote: > > Yes, I agree that identifying trigger points is useful and helps with > clarity. What does such identification do for pushing data through our > notional system? From my perspective, getting information through the > system to answer questions is the hard part. Triggers seem relatively > easy. Then, perhaps I'm missing something. > > On Tue, Feb 28, 2017 at 11:45 PM Jerome Athias > wrote: > > Yes correct. > I concur with your recommended approach of identifying the workflow entry > points. > > An example is a change in the endpoint repository, lets say event: a new > device is connected, one would want to trigger an assessment "a la NAC" > > > On Tue, Feb 28, 2017 at 9:31 PM, Waltermire, David A. (Fed) < > david.waltermire@nist.gov> wrote: > > Jerome, > > > > IMHO, we need to identify the places within the workflow where triggers > may occur. These are the workflow entry points. It would also be useful to > identify the events that may cause these triggers for clarity sake. > > > > Is this what you are saying? > > > > Regards, > > Dave > > > > > > *From:* sacm [mailto:sacm-bounces@ietf.org] *On Behalf Of *Jerome Athias > *Sent:* Tuesday, February 28, 2017 5:39 AM > *To:* Bill Munyan > *Cc:* Henk Birkholz ; < > sacm@ietf.org>; Adam Montville > *Subject:* Re: [sacm] Main Components: WAS (Re: Notes on Vulnerability > Scenario Working Session) > > > > Greetings, > > > > So taking IACD (Ref [0] Appendix A1) as an example for illustration, would > that help to first list triggering "events"/preconditions? > > > > Regards > > > > [0] > https://secwww.jhuapl.edu/iacdcommunityday/Resources/IACD%20Baseline%20Reference%20Architecture%20-%20Final%20PR.pdf > > > > > > > > On Mon, Feb 6, 2017 at 5:17 PM, Bill Munyan > wrote: > > I wanted to clarify one assumption I have been making when viewing the > diagram. I am viewing the overall vulnerability scenario as a series of > event-driven use-cases, with this diagram simply depicting one of those > use-cases: When new VDD is introduced into the scenario. > > > > Feasibly, a number of different events could trigger entry into the > vulnerability scenario, such as a "staleness trigger", or a "new endpoint > added trigger", and many more. Each of these events could (and should) > have their own diagram outlining how the components interact to request > new/updated VDD, determine the endpoints which should be assessed, and what > to do with their results. As such, each of the components in the diagrams > can be seen as conceptual, allowing for implementers to determine how best > to consolidate components for their use. > > > > Please bash my thought process if I'm way off on this, but I thought it > might help in this discussion, because it seems like some of the > "disagreement" in the diagram is stemming from "events" which aren't > necessarily applicable to this particular "event use-case". > > > > Cheers, > > -Bill M. > > > > > > On Fri, Feb 3, 2017 at 5:19 PM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > Also inline. I hope it is still readable. > > On 02/03/2017 10:55 PM, Adam Montville wrote: > > Thanks for chiming in Henk. I'll go inline. Nothing being said as > chair. Just making observations. > > On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz > > wrote: > > Hi group, > > to recap my understanding: > > There will be trigger conditions that initiate collections of fresh > endpoint attributes (from which endpoint posture can be derived) from a > target endpoint. > > The obvious trigger condition that an asserting component (in every > diagram, I think, that is the Vulnerability Assessor. This assumption > is > based on the interpretation of the diagram, not based on the name of > the > component). From my point of view, in order to assert that a known > record is, for example, "stale" (aka does not satisfy an declarative > guidance that expresses the quality of freshness) or, as another > example, is not yet created the Vulnerability Assessor requires an > always up-to-date and exhaustive list of all Assessment Result records. > > > I would disagree. I have a record from the endpoint repository that it > timestamped as 3 days old. My policy says I should not rely on anything > older than 2 days old. Then the information is stale, and I instruct to > collect anew. > > > If the "I" is the Vulnerability Assessor, how does it always have the > Assessment Result records to check that declarative guidance? Or do you > propose (in v3) that the Endpoint Repository is checking that freshness > continuously and notifying the Vulnerability Assessor? > > > > > In consequence, I would assume that either the the Assessment Result > Repository component collapses with the Vulnerability Assessor or the > Vulnerability Assessor always retains a complete in-sync copy of the > Assessment Result Repository. > > > I would again disagree. It may well be that actual software collapses > these components into one, but it may be that there is a results > repository, which is used downstream from vulnerability assessment, into > which the assessor dumps results. > > > Yes, downstream records are dumped as a result in the corresponding repo. > But how does the information of not satisfying declarative guidance (a > result got stale) makes it "upstream" again to trigger collection - > including imperative guidance what to collect (what just got stale)? > > > Consider when we have configuration assessment down the road. Would we > then have a vulnerability assessor and a configuration assessor each > with their own repository conceptually, or would we be better off with > one "results repository"? I think the one. > > > It depends on scalability, I guess, but in the bare-bone first proof of > concept it seems to be feasible to collapse related pools of data into > justthe one, as there are no multiple consumers? > > > In practice, applications can choose to implement more than one > conceptual component. > > > Yes, that is why it is not a problem to collapse sets of functions into a > single component, in general. I hope this will remain a core feature of the > architecture at all time. > > > > > Alternatively, the Assessment Result Repository component is collapsed > with the Endpoint Repository (as proposed in diagram v3), in which case > now the Vulnerability Assessor to retain an continuously in-sync copy > of > the Endpoint Repository? If it is to trigger on the "stale" condition? > > > Again, I am not necessarily in favor of this viewpoint (and I'm not > necessarily against). The endpoint repository represents an interface > to acquire information about endpoints, which does not necessarily need > to include assessment results pertaining to those endpoints entirely. > > > But isn't that what is depicted in the diagram v3: the assessment results > repo is merged with endpoint repo? Maybe I am actually a little bit dense > right now :) > > > > > > The "keeping pools of data in-sync" seems to be introducing extra steps > in the work-flow. > > > Is it really data in sync? I understand what you're saying, but to me > the endpoint repository component is where we find assertions about the > endpoints, the assessors take those assertions and apply some logic to > pass judgement on the endpoint, and that judgement is stored in the > assessment results repository component. > > > I simply did not assume that a repository is more than a data store. If it > does continuous assessments of endpoint records it contains, it most > certainly can trigger a collection. Maybe the label of the component is > just misleading me here. > > > > > A pro for this would be that there could be multiple additional > consumers of Assessment Results that justify an interface that provides > that data to multiple parties. > > > Yes! There are in practice. Assessment results have downstream uses > outside the scope of our charter. > > > I thought so, but it is of course not part of the single snapshot diagram > and is therefore only implied at best. > > > > > A con for this is the universal "redundant data stores always pose a > source of complexity and hence risk of inconsistency" argument. > > Another point of view could be that the "evaluation task" is > independent > from the "trigger collection" (I just made that one up) task? Or maybe > it is associated with the worn component? > > Multiple emerging architectures include an orchestration component that > consumes notification of changes and derives appropriate actions that > it > can trigger or even conduct. Please note, I am not advocating to > introduce yet another component type (which would again add complexity, > error, scope creep...) :) > > > Bill mentioned something to me offline yesterday about orchestration. > In the vulnerability scenario, the orchestration is really being > performed by the assessor. > > > I think that in the reply above you illustrated that the Endpoint Repo > also does this assessment by checking for staleness? Or would it "just" > notify the Assessor to trigger a task? Why not trigger the collector > directly? What about the imperative guidance what to actually collect again? > > It seems that I really have a difficult time to wrap my head around the > proposal still. Please stay patient with me! :) > > > > > I just try to get a feasible grasp of the actual workflow that the > diagram is intended to represent. > > > The most basic path through the system. > > > > What am I missing? I actually am surprised that the Assessment Result > Repository merges with the Endpoint Repository and not the > Vulnerability > Assessor. What is the advantage? > > > I think we're still talking this one through. What's the advantage to > collapsing them at all? > > > Collapsing redundant pools of data is reducing redundancy :) Tasks that > depend on data that has to be acquired to be conducted benefit from high > availability and low latency. But I totally understand the "multiple > consumer" argument. > > > > > Best, > > Henk > > On 02/03/2017 05:43 PM, Adam Montville wrote: > > I thought I'd try to break this discussion out of it's former thread > > into one of its own, in case that makes it easier for folks to opine. > > The list of "components" or "function groups" seems reasonable to me. > > In practice, there *may* be a desire to have that software acting > as an > > endpoint repository also act as the repository for assessment > results. > > Or, these could be implemented in distinct services. > > > > What works for our purposes? > > > > Adam > > > > On Thu, Feb 2, 2017 at 10:40 AM Adam Montville > > > >> wrote: > > > > Once folks have had an opportunity to review the vulnerability > > scenario information we've been working on, what are your > thoughts > > on the main components we're presently focused on for this > narrowly > > scoped exercise? These are: > > > > Vulnerability Detection Data Repository > > Vulnerability Assessor > > Endpoint Repository > > Collector > > Assessment Result Repository > > Endpoint > > > > > > > > > > On Thu, Feb 2, 2017 at 10:28 AM Adam Montville > > > > > >> wrote: > > > > Hi Everyone. A few of us were able to make the vulnerability > > scenario call today and I think we had a good, though at > times > > spirited, discussion. We did record the meeting, which is > > available at [1]. We discussed the attached (annotated with > > some meeting notes) UML-ish sequence diagram. I had created > > that diagram to start a conversation (mission accomplished on > > that front I think) -- a conversation that would lead us > toward > > identifying the discrete components, interfaces, and > information > > required to be sent over those interfaces. The UML-ish > diagram > > represents a *single* flow through the system -- a "one-time" > > flow through the system. It ignores, for the time being, the > > continuous aspect of our charter in favor of getting started > > with the basics. Once we have a good understanding of the > > basics -- the components, interfaces, and information > required > > -- we can start look at a continuous monitoring sequence > (which > > could be represented as a distinct diagram) to determine what > > more we need. Then, I think, we can start drafting > solutions. > > > > One of the first issues is that we need to figure out if the > > components in the base flow are accurate. The main > suggestion > > we've tossed around so far is to combine the Endpoint > Repository > > with the Assessment Result Repository. > > > > We talked briefly about what interface we could use for > the VDD > > Repository, and naturally ROLIE came up as an option. > > > > We talked a little bit about the first "get endpoints" > operation > > between the Vulnerability Assessor and the Endpoint > Repository > > -- specifically about whether we should represent on this > > sequence diagram that information supporting a judgement of > > "stale" would be needed. > > > > We left open the time when we would next meet, favoring to > work > > that out on-list. Next week is TCG, so that may be > difficult; > > the following week is RSA, so that may be difficult. > > > > For those who were in attendance today, please add to this > note > > with your comments/corrections. > > > > Kind regards, > > > > Adam > > > > [1] > https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E > > > > On Mon, Jan 30, 2017 at 11:21 AM Adam Montville > > > > >>> > > wrote: > > > > Hi everyone. Just a friendly reminder that we are > planning > > to meet again this Thursday at the same time (2/2 @ 10am > > Eastern/3pm UTC) using SACM's meeting room at > > https://ietf.webex.com/meet/sacm. > > > > Kind regards, > > > > Adam > > > > > > On Thu, Jan 19, 2017 at 11:35 AM Adam Montville > > > > > > >> wrote: > > > > Hello. A few of us met informally today to discuss > the > > vulnerability scenario in some more detail with > the goal > > of maintaining the narrow focus on a vulnerability > > assessment slice through our notional environment. > We > > are tending to look at major components as black > boxes > > with interfaces and data format expectations, and > we are > > not necessarily concerned with how those components > do > > things internally/behind the scenes. > > > > The meeting was recorded (you can find it with > today's > > date at [1]). The topic of discussion was > primarily in > > the "phase 1" area of what Danny sent to the list not > > very long ago [2], and resulted in a *starting point* > > diagram [3]. > > > > The group who met today are (roughly) agreed on > the six > > main "components" represented in that diagram, but > also > > see that we have some work ahead. Specifically, we > > quickly recognized that some of the assumptions the > > vulnerability draft makes may be assumptions we > cannot > > afford to make and need to include in the > exploration. > > > > We thought it would be a good idea to have another > > informal discussion in a couple of weeks (February > 2) at > > the same time (10am Eastern / 3pm UTC), using the > same > > WebEx [4]. At that time we intend to roll > through the > > vulnerability assessment scenario assumptions in an > > effort to determine which ones can be left as > > assumptions and which ones cannot. Then we'll take > > another look at the diagram and work on its next > version. > > > > Stay tuned. > > > > Thanks to Danny, Stephen, and Jerome for joining and > > contributing! > > > > Kind regards, > > > > Adam > > > > > > [1] > https://drive.google.com/open?id=0B8Wf9Un5FdCbWGhDOHpVR0tMd1E > > [2] > https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_OVLFhB5NSU58MXDM > > [3] > https://drive.google.com/open?id=0B8Wf9Un5FdCbMU5pdTRjejJtNHc > > [4] https://ietf.webex.com/meet/sacm > > > > > > > > _______________________________________________ > > sacm mailing list > > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > > > > > --001a11417c44ae7a2c0549beb58b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, I see. =C2=A0(That's what I get for not paying att= ention for too long)

O= n Thu, Mar 2, 2017 at 6:33 AM Jerome Athias <athiasjerome@gmail.com> wrote:
no, you're right= and I agree.
I was just trying to clarify that Hen= k and Bill assumptions were correct

On Th= u, Mar 2, 2017 at 3:05 PM, Adam Montville <adam.w.montville@gmail.com> wrote:
Yes, I agree that identifying trigger points is useful an= d helps with clarity.=C2=A0 What does such identification do for pushing da= ta through our notional system?=C2=A0 From my perspective, getting informat= ion through the system to answer questions is the hard part.=C2=A0 Triggers= seem relatively easy.=C2=A0 Then, perhaps I'm missing something.
=

On Tue, Feb 28, 2017 at= 11:45 PM Jerome Athias <athiasjerome@gmail.com> wrote:
Yes correct.
I concur with your recommended approach of identify= ing the workflow entry points.

An example is a change= in the=C2=A0endpoint repository, lets say = event: a new device is connected, one would want to trigger an assessment &= quot;a la NAC"


On Tue, Feb 28, 2017 at = 9:31 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov&g= t; wrote:

Jerome,

=C2=A0

IMHO, we need to identify the places within the workflow where = triggers may occur. These are the workflow entry points. It would also be u= seful to identify the events that may cause these triggers for clarity sake.

=C2=A0

Is this what you are saying?

=C2=A0

Regards,

Dave

=C2=A0

=C2=A0

From: sacm [mailto:sacm-bounces@ietf.org] bill.munyan.ietf@gmail.com>
henk.birkholz@sit.fraunhofer.de>; <sacm@ietf.org> <sacm@ietf.org>; Adam Mon= tville <a= dam.w.montville@gmail.com>

=C2=A0

Greetings,

=C2=A0

So taking IACD (Ref [0] Appendix A1) as an example for illustra= tion, would that help to first list triggering "events"/precondit= ions?

=C2=A0

Regards

=C2=A0

[0]=C2=A0https://secwww.jhuapl.edu/iacdcommunityday/Resources/IACD%= 20Baseline%20Reference%20Architecture%20-%20Final%20PR.pdf<= /p>

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 6, 2017 at 5:17 PM, Bill Munyan <bill.munyan.ietf@gmail.com<= /a>> wrote:

I wan= ted to clarify one assumption I have been making when viewing the diagram.= =C2=A0 I am viewing the overall vulnerability scenario as a series of event= -driven use-cases, with this diagram simply depicting one of those use-cases: =C2=A0When new VDD is introduced into th= e scenario. =C2=A0

=C2=A0

Feasi= bly, a number of different events could trigger entry into the vulnerabilit= y scenario, such as a "staleness trigger", or a "new endpoin= t added trigger", and many more.=C2=A0 Each of these events could (and should) have their own diagram outlining how the components int= eract to request new/updated VDD, determine the endpoints which should be a= ssessed, and what to do with their results.=C2=A0 As such, each of the comp= onents in the diagrams can be seen as conceptual, allowing for implementers to determine how best to consolidate= components for their use.

=C2=A0

Pleas= e bash my thought process if I'm way off on this, but I thought it migh= t help in this discussion, because it seems like some of the "disagree= ment" in the diagram is stemming from "events" which aren't necessarily applicable to this particular "event use= -case".

=C2=A0

Cheer= s,=C2=A0

-Bill= M.

=C2=A0

=C2=A0

On Fri, Feb 3, 2017 at 5:19 PM, Henk Birkholz <henk.birkholz@sit.fr= aunhofer.de> wrote:

Also inline. I hope it is still readable.

On 02/03/2017 10:55 PM, Adam Montville wrote:

Thanks for chiming in Henk.=C2=A0 I'll go inline.=C2=A0 Not= hing being said as
chair.=C2=A0 Just making observations.

On Fri, Feb 3, 2017 at 3:25 PM Henk Birkholz
<hen= k.birkholz@sit.fraunhofer.de
<mailto:henk.birkholz@sit.fraunhofer.de>> wrote:

=C2=A0 =C2=A0 Hi group,

=C2=A0 =C2=A0 to recap my understanding:

=C2=A0 =C2=A0 There will be trigger conditions that initiate collections of= fresh
=C2=A0 =C2=A0 endpoint attributes (from which endpoint posture can be deriv= ed) from a
=C2=A0 =C2=A0 target endpoint.

=C2=A0 =C2=A0 The obvious trigger condition that an asserting component (in= every
=C2=A0 =C2=A0 diagram, I think, that is the Vulnerability Assessor. This as= sumption is
=C2=A0 =C2=A0 based on the interpretation of the diagram, not based on the = name of the
=C2=A0 =C2=A0 component). From my point of view, in order to assert that a = known
=C2=A0 =C2=A0 record is, for example, "stale" (aka does not satis= fy an declarative
=C2=A0 =C2=A0 guidance that expresses the quality of freshness) or, as anot= her
=C2=A0 =C2=A0 example, is not yet created the Vulnerability Assessor requir= es an
=C2=A0 =C2=A0 always up-to-date and exhaustive list of all Assessment Resul= t records.


I would disagree.=C2=A0 I have a record from the endpoint repository that i= t
timestamped as 3 days old.=C2=A0 My policy says I should not rely on anythi= ng
older than 2 days old.=C2=A0 Then the information is stale, and I instruct = to
collect anew.


If the "I" is the Vulnerability Assessor, how does it always have= the Assessment Result records to check that declarative guidance? Or do yo= u propose (in v3) that the Endpoint Repository is checking that freshness c= ontinuously and notifying the Vulnerability Assessor?




=C2=A0 =C2=A0 In consequence, I would assume that either the the Assessment= Result
=C2=A0 =C2=A0 Repository component collapses with the Vulnerability Assesso= r or the
=C2=A0 =C2=A0 Vulnerability Assessor always retains a complete in-sync copy= of the
=C2=A0 =C2=A0 Assessment Result Repository.


I would again disagree.=C2=A0 It may well be that actual software collapses=
these components into one, but it may be that there is a results
repository, which is used downstream from vulnerability assessment, into which the assessor dumps results.


Yes, downstream records are dumped as a result in the corresponding repo. B= ut how does the information of not satisfying declarative guidance (a resul= t got stale) makes it "upstream" again to trigger collection - in= cluding imperative guidance what to collect (what just got stale)?


Consider when we have configuration assessment down the road.=C2=A0 Would w= e
then have a vulnerability assessor and a configuration assessor each
with their own repository conceptually, or would we be better off with
one "results repository"?=C2=A0 I think the one.


It depends on scalability, I guess, but in the bare-bone first proof of con= cept it seems to be feasible to collapse related pools of data into justthe= one, as there are no multiple consumers?


In practice, applications can choose to implement more than one
conceptual component.


Yes, that is why it is not a problem to collapse sets of functions into a s= ingle component, in general. I hope this will remain a core feature of the = architecture at all time.




=C2=A0 =C2=A0 Alternatively, the Assessment Result Repository component is = collapsed
=C2=A0 =C2=A0 with the Endpoint Repository (as proposed in diagram v3), in = which case
=C2=A0 =C2=A0 now the Vulnerability Assessor to retain an continuously in-s= ync copy of
=C2=A0 =C2=A0 the Endpoint Repository? If it is to trigger on the "sta= le" condition?


Again, I am not necessarily in favor of this viewpoint (and I'm not
necessarily against).=C2=A0 The endpoint repository represents an interface=
to acquire information about endpoints, which does not necessarily need
to include assessment results pertaining to those endpoints entirely.=
But isn't that what is depicted in the diagram v3: the assessment resul= ts repo is merged with endpoint repo? Maybe I am actually a little bit dens= e right now :)





=C2=A0 =C2=A0 The "keeping pools of data in-sync" seems to be int= roducing extra steps
=C2=A0 =C2=A0 in the work-flow.


Is it really data in sync?=C2=A0 I understand what you're saying, but t= o me
the endpoint repository component is where we find assertions about the
endpoints, the assessors take those assertions and apply some logic to
pass judgement on the endpoint, and that judgement is stored in the
assessment results repository component.


I simply did not assume that a repository is more than a data store. If it = does continuous assessments of endpoint records it contains, it most certai= nly can trigger a collection. Maybe the label of the component is just misl= eading me here.




=C2=A0 =C2=A0 A pro for this would be that there could be multiple addition= al
=C2=A0 =C2=A0 consumers of Assessment Results that justify an interface tha= t provides
=C2=A0 =C2=A0 that data to multiple parties.


Yes!=C2=A0 There are in practice.=C2=A0 Assessment results have downstream = uses
outside the scope of our charter.


I thought so, but it is of course not part of the single snapshot diagram a= nd is therefore only implied at best.




=C2=A0 =C2=A0 A con for this is the universal "redundant data stores a= lways pose a
=C2=A0 =C2=A0 source of complexity and hence risk of inconsistency" ar= gument.

=C2=A0 =C2=A0 Another point of view could be that the "evaluation task= " is independent
=C2=A0 =C2=A0 from the "trigger collection" (I just made that one= up) task? Or maybe
=C2=A0 =C2=A0 it is associated with the worn component?

=C2=A0 =C2=A0 Multiple emerging architectures include an orchestration comp= onent that
=C2=A0 =C2=A0 consumes notification of changes and derives appropriate acti= ons that it
=C2=A0 =C2=A0 can trigger or even conduct. Please note, I am not advocating= to
=C2=A0 =C2=A0 introduce yet another component type (which would again add c= omplexity,
=C2=A0 =C2=A0 error, scope creep...) :)


Bill mentioned something to me offline yesterday about orchestration.
In the vulnerability scenario, the orchestration is really being
performed by the assessor.


I think that in the reply above you illustrated that the Endpoint Repo also= does this assessment by checking for staleness? Or would it "just&quo= t; notify the Assessor to trigger a task? Why not trigger the collector dir= ectly? What about the imperative guidance what to actually collect again?

It seems that I really have a difficult time to wrap my head around the pro= posal still. Please stay patient with me! :)




=C2=A0 =C2=A0 I just try to get a feasible grasp of the actual workflow tha= t the
=C2=A0 =C2=A0 diagram is intended to represent.


The most basic path through the system.



=C2=A0 =C2=A0 What am I missing? I actually am surprised that the Assessmen= t Result
=C2=A0 =C2=A0 Repository merges with the Endpoint Repository and not the Vu= lnerability
=C2=A0 =C2=A0 Assessor. What is the advantage?


I think we're still talking this one through.=C2=A0 What's the adva= ntage to
collapsing them at all?


Collapsing redundant pools of data is reducing redundancy :) Tasks that dep= end on data that has to be acquired to be conducted benefit from high avail= ability and low latency. But I totally understand the "multiple consum= er" argument.




=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 Henk

=C2=A0 =C2=A0 On 02/03/2017 05:43 PM, Adam Montville wrote:
=C2=A0 =C2=A0 > I thought I'd try to break this discussion out of it= 's former thread
=C2=A0 =C2=A0 > into one of its own, in case that makes it easier for fo= lks to opine.
=C2=A0 =C2=A0 > The list of "components" or "function gro= ups" seems reasonable to me.
=C2=A0 =C2=A0 > In practice, there *may* be a desire to have that softwa= re acting
=C2=A0 =C2=A0 as an
=C2=A0 =C2=A0 > endpoint repository also act as the repository for asses= sment results.
=C2=A0 =C2=A0 > Or, these could be implemented in distinct services.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What works for our purposes?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Thu, Feb 2, 2017 at 10:40 AM Adam Montville
=C2=A0 =C2=A0 > <adam.w.montville@gmail.com <mailto:adam.w.montville@gmail.com>= ;
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Once folks have had an opportunity to= review the vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0scenario information we've been w= orking on, what are your thoughts
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0on the main components we're pres= ently focused on for this
=C2=A0 =C2=A0 narrowly
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0scoped exercise?=C2=A0 These are:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Vulnerability Detection Data Reposito= ry
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Vulnerability Assessor
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Endpoint Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Collector
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Assessment Result Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Endpoint
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Thu, Feb 2, 2017 at 10:28 AM Adam = Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<adam.w.montville@gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com


=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Everyone.=C2=A0 A fe= w of us were able to make the vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scenario call today and= I think we had a good, though at times
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spirited, discussion.= =C2=A0 We did record the meeting, which is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0available at [1].=C2=A0= We discussed the attached (annotated with
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some meeting notes) UML= -ish sequence diagram.=C2=A0 I had created
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that diagram to start a= conversation (mission accomplished on
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that front I think) -- = a conversation that would lead us
=C2=A0 =C2=A0 toward
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identifying the discret= e components, interfaces, and
=C2=A0 =C2=A0 information
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0required to be sent ove= r those interfaces.=C2=A0 The UML-ish
=C2=A0 =C2=A0 diagram
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0represents a *single* f= low through the system -- a "one-time"
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flow through the system= .=C2=A0 It ignores, for the time being, the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continuous aspect of ou= r charter in favor of getting started
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the basics.=C2=A0 = Once we have a good understanding of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0basics -- the component= s, interfaces, and information required
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- we can start look at= a continuous monitoring sequence
=C2=A0 =C2=A0 (which
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0could be represented as= a distinct diagram) to determine what
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more we need.=C2=A0 The= n, I think, we can start drafting solutions.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One of the first issues= is that we need to figure out if the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0components in the base = flow are accurate.=C2=A0 The main suggestion
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we've tossed around= so far is to combine the Endpoint
=C2=A0 =C2=A0 Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the Assessment Res= ult Repository.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We talked briefly about= what interface we could use for
=C2=A0 =C2=A0 the VDD
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Repository, and natural= ly ROLIE came up as an option.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We talked a little bit = about the first "get endpoints"
=C2=A0 =C2=A0 operation
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between the Vulnerabili= ty Assessor and the Endpoint Repository
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- specifically about w= hether we should represent on this
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sequence diagram that i= nformation supporting a judgement of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"stale" would= be needed.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We left open the time w= hen we would next meet, favoring to
=C2=A0 =C2=A0 work
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that out on-list.=C2=A0= Next week is TCG, so that may be difficult;
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the following week is R= SA, so that may be difficult.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For those who were in a= ttendance today, please add to this
=C2=A0 =C2=A0 note
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with your comments/corr= ections.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kind regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[1]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Jan 30, 2017 at= 11:21 AM Adam Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<adam.w.montville@gmail.com<= br class=3D"m_-6029744847208455909m_-7359019547289384325gmail_msg gmail_msg= "> =C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>

=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com <mailto:adam.w.montville@gm= ail.com>>>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi everyo= ne.=C2=A0 Just a friendly reminder that we are
=C2=A0 =C2=A0 planning
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to meet a= gain this Thursday at the same time (2/2 @ 10am
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Eastern/3= pm UTC) using SACM's meeting room at
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ietf.webex.c= om/meet/sacm.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kind rega= rds,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, J= an 19, 2017 at 11:35 AM Adam Montville
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<adam.w.montville@= gmail.com
=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:adam.w.mon= tville@gmail.com


=C2=A0 =C2=A0 <mailto:adam.w.montville@gmail.com>>> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Hello. A few of us met informally today to discuss the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability scenario in some more detail with
=C2=A0 =C2=A0 the goal
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0of maintaining the narrow focus on a vulnerability
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0assessment slice through our notional environment.=C2=A0 We
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0are tending to look at major components as black boxes
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with interfaces and data format expectations, and
=C2=A0 =C2=A0 we are
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0not necessarily concerned with how those components do
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0things internally/behind the scenes.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The meeting was recorded (you can find it with today's
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0date at [1]).=C2=A0 The topic of discussion was
=C2=A0 =C2=A0 primarily in
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the "phase 1" area of what Danny sent to the list not
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0very long ago [2], and resulted in a *starting point*
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0diagram [3].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The group who met today are (roughly) agreed on
=C2=A0 =C2=A0 the six
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0main "components" represented in that diagram, but
=C2=A0 =C2=A0 also
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0see that we have some work ahead.=C2=A0 Specifically, we
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0quickly recognized that some of the assumptions the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability draft makes may be assumptions we cannot
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0afford to make and need to include in the exploration.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0We thought it would be a good idea to have another
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0informal discussion in a couple of weeks (February
=C2=A0 =C2=A0 2) at
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0the same time (10am Eastern / 3pm UTC), using the same
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0WebEx [4].=C2=A0 =C2=A0At that time we intend to roll
=C2=A0 =C2=A0 through the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0vulnerability assessment scenario assumptions in an
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0effort to determine which ones can be left as
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0assumptions and which ones cannot.=C2=A0 Then we'll take
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0another look at the diagram and work on its next
=C2=A0 =C2=A0 version.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Stay tuned.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Thanks to Danny, Stephen, and Jerome for joining and
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0contributing!
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Kind regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Adam
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[1]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbWGhDOHpVR0tMd1E
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[2]
=C2=A0 =C2=A0 https://mailarchive.ietf.org/arch/msg/sacm/_LiKlyvAws_OVLFhB5NSU58MXDM<= br class=3D"m_-6029744847208455909m_-7359019547289384325gmail_msg gmail_msg= "> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[3]
=C2=A0 =C2=A0 https://drive.google.com/open?id=3D0B8Wf9Un5FdCbMU5pdTRjejJtNHc
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[4] https://ietf.webex.com/meet/sacm
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > sacm mailing list

=C2=A0 =C2=A0 > sacm@ietf.org <mailto:sacm@ietf.org>
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/sacm
=C2=A0 =C2=A0 >


_______________________________________________
sacm mailing list
sacm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sacm

=C2=A0


_______________________________________________
sacm mailing list
sacm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sacm

=C2=A0



--001a11417c44ae7a2c0549beb58b-- From nobody Thu Mar 2 19:33:25 2017 Return-Path: <928053580@qq.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 361531296B9 for ; Thu, 2 Mar 2017 19:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qq.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 aMU4_8luc_l5 for ; Thu, 2 Mar 2017 19:33:21 -0800 (PST) Received: from smtpbg298.qq.com (smtpbg298.qq.com [184.105.67.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5415A129407 for ; Thu, 2 Mar 2017 19:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1488511999; bh=PWETlYcZZXDmAnuAyHgBLjhJLW+rrfEPBZYL75U1Uu0=; h=From:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID; b=qHon+rXMacw17IycJliNQx7OgTkxGrqrb4Wn/4V9xVRFPp8xMrmE66P1TPORc9mMZ 70Q3/Ih/sWoDPOE3NmfPgbSV+d0qYHtC/0JNN23g2BsXUuE0/h9llQfFYBbxbxgVTe AC2+vxe/8IV/OFoexoUUfrJGWcKwRv1fYEnecrIU= X-QQ-FEAT: 0abLp1D7a8LOtylATWcHXsWTeXGtE2t+LJVrcUS7kjtqBKBKamqI4GpabdVru wTuA+HPVq6TUpk9ThhxbZ2pc8BE2X8MKcIYEiGbJg1aXV4mVW3TcbbTv+/C/qq/uZEkMk+S G5DF0lEkJTwlIPYd3YVrmJDmiiuMLWRQJutG1eWg6Il8oJAw9/2lTB40mtG6M7IJ3A1SXwP 6A8K8Z9p3rsbuXQXa8geWub1Os+LHn1MdHSMzd56jjMOGH+ErAD7qL6Md9Jxa1n3Z/p5y1l PfZg== X-QQ-SSF: 00000000000000F000000000000000Z X-HAS-ATTACH: no X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 113.251.221.136 X-QQ-STYLE: X-QQ-mid: webmail541t1488511996t3300532 From: "=?gb18030?B?tMu85A==?=" <928053580@qq.com> To: "=?gb18030?B?c2FjbQ==?=" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_58B8E3FC_0BB31D78_7ED313FF" Content-Transfer-Encoding: 8Bit Date: Fri, 3 Mar 2017 11:33:16 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 X-QQ-FName: 95E8844FDEC64223918E7A4CF07BFABA X-QQ-LocalIP: 10.130.87.224 Archived-At: Subject: [sacm] draft-li-sacm-anomaly-detection-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 03:33:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_58B8E3FC_0BB31D78_7ED313FF Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KTXkgY29sbGVhZ3VlcyBhbmQgSSBwdXQgZm9yd2FyZCBzb21lIGlkZWFz IGFib3V0IGFub21hbHkgZGV0ZWN0aW9uIG9mIEluZHVzdHJpYWwgQ29udHJvbCBTeXN0ZW0g YmFzZWQgb24gTW9kYnVzL1RDUCx3ZSBhbHNvIGhhdmUgc3VibWl0dGVkIGFuIGRvY3VtZW50 IG9ubGluZSB0byBzYWNtIGdyb3VwICB3b3JraW5nIG9mIElFVEYgb3JnYW5pemF0aW9uLCB3 aGljaCBpcyAiZHJhZnQtbGktc2FjbS1hbm9tYWx5LWRldGVjdGlvbi0wMCIsIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpLXNhY20tYW5vbWFseS1kZXRlY3Rp b24vDQoNCg0KQWltaW5nIGF0IHRoZSB2dWxuZXJhYmlsaXR5IGFuZCBzZWN1cml0eSB0aHJl YXQgb2YgSW5kdXN0cmlhbCBDb250cm9sIFN5c3RlbSwgdGhpcyBkb2N1bWVudCBwcm9wb3Nl ZCBhIGRldGVjdGlvbiBtb2RlbCBiYXNlZCBvbiB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIE1v ZGJ1cy9UQ1AgcHJvdG9jb2wuDQoNCkxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHJlcGx5IGFu ZCBmZWVrYmFjaw0KDQpCZXN0IHdpc2hlcywNCg0KICAgICAgICAgICAgICAgICAgICBKaWUg TGlhbw== ------=_NextPart_58B8E3FC_0BB31D78_7ED313FF Content-Type: text/html; charset="gb18030" Content-Transfer-Encoding: base64 PGRpdj48ZGl2PkhlbGxvIGFsbCw8L2Rpdj48ZGl2Pk15IGNvbGxlYWd1ZXMgYW5kIEkgcHV0 IGZvcndhcmQgc29tZSBpZGVhcyBhYm91dCBhbm9tYWx5IGRldGVjdGlvbiBvZiBJbmR1c3Ry aWFsIENvbnRyb2wgU3lzdGVtIGJhc2VkIG9uIE1vZGJ1cy9UQ1Asd2UgYWxzbyBoYXZlIHN1 Ym1pdHRlZCBhbiBkb2N1bWVudCBvbmxpbmUgdG8gc2FjbSBncm91cCAmbmJzcDt3b3JraW5n IG9mIElFVEYgb3JnYW5pemF0aW9uLCB3aGljaCBpcyAiZHJhZnQtbGktc2FjbS1hbm9tYWx5 LWRldGVjdGlvbi0wMCIsJm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbGktc2FjbS1hbm9tYWx5LWRldGVjdGlvbi88L2Rpdj48L2Rpdj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Ik9MRV9MSU5LMjMiPjwvYT48YSBuYW1lPSJPTEVf TElOSzIyIj48c3BhbiBsYW5nPSJFTi1VUyI+QWltaW5nIGF0IHRoZSB2dWxuZXJhYmlsaXR5 IGFuZCBzZWN1cml0eSB0aHJlYXQKb2YgSW5kdXN0cmlhbCBDb250cm9sIFN5c3RlbSwgdGhp cyBkb2N1bWVudDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiBwcm9wb3NlPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj5kPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gYSBkZXRl Y3Rpb24gbW9kZWwgYmFzZWQgb24gdGhlCmNoYXJhY3RlcmlzdGljcyBvZiBNb2RidXM8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPi88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlRDUCBw cm90b2NvbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb29raW5nIGZvcndhcmQgdG8geW91ciByZXBseSBh bmQgZmVla2JhY2s8L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCB3aXNoZXMsPC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKaWUgTGlhbzwvcD48ZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+PGZvbnQgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMy44cHg7Ij48L3NwYW4+PC9mb250PjwvZGl2 PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgbGluZS1oZWlnaHQ6IDIz LjhweDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE2cHg7Ij48L3NwYW4+PC9kaXY+PC9k aXY+ ------=_NextPart_58B8E3FC_0BB31D78_7ED313FF-- From nobody Fri Mar 3 04:32:03 2017 Return-Path: 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 09F431294F4 for ; Fri, 3 Mar 2017 04:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 1TNIzNjDazBi for ; Fri, 3 Mar 2017 04:32:02 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 DFC7F129864 for ; Fri, 3 Mar 2017 04:32:01 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id o24so7767317otb.1 for ; Fri, 03 Mar 2017 04:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Do1njnY5NtKyv9DaA5A7h4VwQmLBJlDa+7AGouiTkYk=; b=qAVb4l7oZHatbJ186zbZsIpI4FntuBlKnQH73t9UBMKsI7l2gWA5nLdV7KhW6h0CZO vwXC060gFZj9syFmjLDYy4ERRHM2woMZhdVAmGa1UYXcXFSErdPefqOy1M2+Z7V7av+o HE1aNd/EegV+AOVH5WsNjB5zcQluM8FTxR0MiJHOLgu3k7F0iIYLdvaOi88zxjn+B0es mPJBD7gsqXDmzf+2Que2nIRQi/aCTzFpie2HswEmYc84swa2a/ReBPJZKgk6oFtQiU9G DrmtsoHM5xYDD1673aAoCkVdH4Bc/X+n6ONgNQ3lS4TUu9rRAQ0Rb7vwvsN51RlBzYOr k/Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Do1njnY5NtKyv9DaA5A7h4VwQmLBJlDa+7AGouiTkYk=; b=cnMPpQlvNLLrJ3wI6lR471OVQYQBMrYJ+V+185Er34ruho/qCbAmYSd+mxhqvQup0i z0/pLVAP5ZF1a8qirgKOD6JwhQ6V8kKleLFYs55a1c4L0NmvPVNdn51sOaBmuAVU6OMB o6HsNIEzi4/u0azeePUg7m3uzchSoniNLYzJYYiZ2m5QjTlkUMNvqwU3cyz3zJhi3ssK 327i8gwOSsnjmyrx2WCD/Pr1pBljF4q2LFmvx7fMsk0eLYO2EwdXBOJ+O2hPV5vLq28q 92v0qxftm7mgJaJ8r+FAO3s2oyNwDFTaOBON/5YmQ0OYx/vEGwreos82BwcrROyMtLqY tN1w== X-Gm-Message-State: AMke39kuXmsZBS2/OjSYf9I3TO8ihLECqTkZ+YIRMriwMZz+kdvRFxJ+Q3MfWXjtKlMdveHc18dvPhVNUAy2RQ== X-Received: by 10.157.52.253 with SMTP id t58mr1357555otd.267.1488544320857; Fri, 03 Mar 2017 04:32:00 -0800 (PST) MIME-Version: 1.0 From: Adam Montville Date: Fri, 03 Mar 2017 12:31:50 +0000 Message-ID: To: "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a1140a4627a46300549d2bbea Archived-At: Subject: [sacm] Call for Agenda Items X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 12:32:03 -0000 --001a1140a4627a46300549d2bbea Content-Type: text/plain; charset=UTF-8 Hello SACM folks. If you'd like to get something on the agenda for our session in just over three weeks, please say something soon. Kind regards, Adam --001a1140a4627a46300549d2bbea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello SACM folks.=C2=A0 If you'd like to get something= on the agenda for our session in just over three weeks, please say somethi= ng soon.

Kind regards,

Adam
--001a1140a4627a46300549d2bbea-- From nobody Fri Mar 3 04:54:12 2017 Return-Path: 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 373E912986C for ; Fri, 3 Mar 2017 04:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 PCJ_IyXFglRf for ; Fri, 3 Mar 2017 04:54:10 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 09636129527 for ; Fri, 3 Mar 2017 04:54:10 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id q7so78624176uaf.2 for ; Fri, 03 Mar 2017 04:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zomy9ZLeJgyXpmlh339E7mpK542fsAd3P79Ijji2VZM=; b=ZMCw44laTZthHm8x/cwfE/yJKhkMyH0ILiJ2xtTHLF5Yrcq20PRYzVbcM+paQ24ZRB AcVkA5MGDtw1B0mj6AmYdr0Mol7AxqdPScwwsNYgUyoKTrbVocIKxhWNUjcCUlY83sLJ V6tG8g47Q7QObo4fsIL1xXA7zexygNvzV7g5UdVWTRTJiUV9ITh8Ux65yqcepobO9jjn 1oBZvc4/B7P8T3vQIpRJn0imRH9x0DV/e5+wAMwkbIwaxRZJI5/ebv2gQGSNr1iBZibI 2sI4lZnt7LVd8SmK0Q2d2z8aauO21tchsvIUmmiCJ7/pYwJX+l3BMDhr1m8spAlCbuEM 7y6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zomy9ZLeJgyXpmlh339E7mpK542fsAd3P79Ijji2VZM=; b=E/naJfX0j0zdcwappSvuYt1ttdt6zxd4CMlYqmougT4fLNOvhPXdoSwb8gtHa3rM25 7txSyHAv8lyHr0fo/0piIhZlIGqLYFA0pAyPt9M4Tj8MEX+KO9M/aAkG5N5eV8aUMI17 pHx6P7XzCBgR0j5e8zxFz1JF5huHNaWkoBOvgei0ML8IKfp99+NElYAHmfvFM/v/P4rR NkoAE4MkV6O9MpSojS1RcUoJQUYuDwwWhwr/+2S9TKlq71/YHYxv1sOYPA8kd2UFiHUE /Bc7asiNjy5T7Fb7ad1kbx3lSM+44kVd9YD7qcvO7lKjOISJeHXoxb2LUqvdIh+sQAbL u/IA== X-Gm-Message-State: AMke39nV+vgHsnihxSkDdBSwaIPB/k86M7GhSd+2aJOZc1NEoGPUuH0TuYm7TEdzep302e66CkjWgYi5eyY1aQ== X-Received: by 10.176.2.146 with SMTP id 18mr1032503uah.79.1488545649151; Fri, 03 Mar 2017 04:54:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jerome Athias Date: Fri, 03 Mar 2017 12:53:58 +0000 Message-ID: To: Adam Montville , "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a113d0240a652530549d30acc Archived-At: Subject: Re: [sacm] Call for Agenda Items X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 12:54:11 -0000 --001a113d0240a652530549d30acc Content-Type: text/plain; charset=UTF-8 Hi Any interest for a model covering softwares' components and web vulnerabilities ? On Fri, 3 Mar 2017 at 15:32, Adam Montville wrote: > Hello SACM folks. If you'd like to get something on the agenda for our > session in just over three weeks, please say something soon. > > Kind regards, > > Adam > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --001a113d0240a652530549d30acc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Any interest for a model covering software= s' components and web vulnerabilities ?

On Fri, 3 Mar 2017 at 15:32, Adam Montville <adam.w.montville@gmail.com> wrote:=
Hello SAC= M folks.=C2=A0 If you'd like to get something on the agenda for our ses= sion in just over three weeks, please say something soon.

Kind regards,=

Adam
_______________________________________________
sacm mailing list
sacm= @ietf.org
https://www.ietf.org/mailman/listinfo/= sacm
--001a113d0240a652530549d30acc-- From nobody Fri Mar 3 05:02:34 2017 Return-Path: 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 E4E5812950E for ; Fri, 3 Mar 2017 05:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8jkRXl4w3nMi for ; Fri, 3 Mar 2017 05:02:30 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 9CCF91296DE for ; Fri, 3 Mar 2017 05:02:30 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id c11so62274682uaa.0 for ; Fri, 03 Mar 2017 05:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Sm5pgh+Dn0upl+dsr3t88pudZHYnKsEyWB0WyF3rRR0=; b=XuiLwWZ3SgpmYx6CgwItYaN4fevl6JpXAicD6LXQMcXnf/RyEk3eKJ+15SDjiwRU/X ncdOyPtKJvFk9DRr4VKQDTvcnNYaae5VjXgZk3J+LarUBURgCYXaXpoev89gQKJJxlq0 /ZZiTxsYW6fkCoHV/p1LxGN9ekgBIYKt7ojs+4XDXHzEgWJpr4MPF7nX5J92tAWtc76R lZIk2SC0Y9Ns4xiwvI3r1M2Gou5Grf+n7RbyRltp0GCzkrzB/5GFcC78uHqGDjiwDxum q3P+KmYFQ0vGoB1R7Sar8OooYUI+VvfgpUxYHpPlhW6AqYc0/1g3qJjoj+zwHRkghnpU 2UGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Sm5pgh+Dn0upl+dsr3t88pudZHYnKsEyWB0WyF3rRR0=; b=XuwfBFB1oPjGk7PXBQm4ELU/UBnvtear4RbtzdWioS8QoyXtzZsxiRgu7laaiExq/1 Qw1h+la+WyBh9qdBNMFsNZp0PcXXLbNO+4boLgZhds46OkR1xXkuVoY7G6+sR3OiuGh+ ITIs+chJs2NCFRos5UW2G1+F0nzXxnCLXi1+B05HIbpPBttL1HWswex5ltCGLhV3Kbec m/+GY9MWaKPBedIBgaeQqXQ4EyaSoZTOCwfU/IdYGHo7F8OMX+l9FLR9rLXq0etGU06r U8EKrg58PhcMl2iFeLLpp5YS6RgzUrNgVPnVBGkv1ThgW85Bc3PcA+GVcojquS2T+BrI gmnA== X-Gm-Message-State: AMke39kFUiBCWd5L/gT64wD0yUKkqkKRz9+e0kVIZN/iHYI2Tdw+AeLsFhLERnCIquYHMxPqG2iBn37xq+pAKg== X-Received: by 10.31.171.205 with SMTP id u196mr917662vke.22.1488546149610; Fri, 03 Mar 2017 05:02:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jerome Athias Date: Fri, 03 Mar 2017 13:02:19 +0000 Message-ID: To: sacm , =?UTF-8?B?5q2k6Ze0?= <928053580@qq.com> Content-Type: multipart/alternative; boundary=001a1143ea107abcab0549d32820 Archived-At: Subject: Re: [sacm] draft-li-sacm-anomaly-detection-00 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 13:02:33 -0000 --001a1143ea107abcab0549d32820 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Thanks for sharing Few comments. I think it's a bit out of scope for SACM (for now). It is of interest and the approach makes sense. The "input labeling" part would be interesting' especially if the protocol characteristics could be represented in a structured language. Do you have samples to share while some observables/patterns could be interesting Best regards On Fri, 3 Mar 2017 at 06:33, =E6=AD=A4=E9=97=B4 <928053580@qq.com> wrote: > Hello all, > My colleagues and I put forward some ideas about anomaly detection of > Industrial Control System based on Modbus/TCP,we also have submitted an > document online to sacm group working of IETF organization, which is > "draft-li-sacm-anomaly-detection-00", > https://datatracker.ietf.org/doc/draft-li-sacm-anomaly-detection/ > > Aiming at the vulnerability and security threat of Industrial Control > System, this document proposed a detection model based on the > characteristics of Modbus/TCP protocol. > > Looking forward to your reply and feekback > > Best wishes, > > Jie Liao > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --001a1143ea107abcab0549d32820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for sharing=C2=A0
Few comments.
I think it's a bit out of scope for= SACM (for now).
It is of interest and the approach makes sense.<= /div>
The "input labeling" part would be interesting' esp= ecially if the protocol characteristics could be represented in a structure= d language. Do you have samples to share while some observables/patterns co= uld be interesting

Best regards=C2=A0
On Fri, 3 Mar 2017 at 06:33, =E6=AD=A4=E9= =97=B4 <928053580@qq.com> wro= te:
Hello all,
My colleagues a= nd I put forward some ideas about anomaly detection of Industrial Control S= ystem based on Modbus/TCP,we also have submitted an document online to sacm= group =C2=A0working of IETF organization, which is "draft-li-sacm-ano= maly-detection-00",=C2=A0http= s://datatracker.ietf.org/doc/draft-li-sacm-anomaly-detection/

Aiming at the vulnerability and security threat of Industrial Control System, this document proposed a detection model based = on the characteristics of Modbus/<= /span>TCP protocol.

Looking forward to = your reply and feekback

Best wishes,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jie Liao


_________________________= ______________________
sacm mailing list
sacm= @ietf.org
https://www.ietf.org/mailman/listinfo/= sacm
--001a1143ea107abcab0549d32820-- From nobody Fri Mar 3 09:22:35 2017 Return-Path: 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 1C8CB129457 for ; Fri, 3 Mar 2017 09:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 Y9ZFWtafxheu for ; Fri, 3 Mar 2017 09:22:31 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8CA127735 for ; Fri, 3 Mar 2017 09:22:31 -0800 (PST) Date: Fri, 03 Mar 2017 09:22:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1488561750; bh=kUsqnSD36VCXEVOd+cl/Tx0VhVOkXq+fsJnUmQZT3MA=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ttPaeqrP3gT/2+ZweBo0ov85q2ljdKh0KPfIFaUWo5U+Vx7TQ663k/GToprGfcX8P 3lc3buiz998EQx8qinaYISMagAK2exL5xQG20gVjePEZDLVkzf96KeaJ3oDmPHdWyr hOlwOcPjkPPQee1NSYlN9+mIOV+oJOezyyNw59FY= From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58b9a656d4b95_66be3fb9d14b7c2c11983c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] Section 4.1 - Identifying Attributes (#17) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:22:33 -0000 ----==_mimepart_58b9a656d4b95_66be3fb9d14b7c2c11983c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Given Jim's feedback and the lack of other feedback on this issue, I am going to close it out. If you have any questions or concerns, please let me know. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/17#issuecomment-284015339 ----==_mimepart_58b9a656d4b95_66be3fb9d14b7c2c11983c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Given Jim's feedback and the lack of other feedback on this issue, I a= m going to close it out. If you have any questions or concerns, please le= t me know.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, vi= ew it on GitHub, or mute th= e thread.3D""

----==_mimepart_58b9a656cf5f4_57693fa3aa43dc3418056f-- From nobody Fri Mar 3 09:26:07 2017 Return-Path: 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 4661212952F for ; Fri, 3 Mar 2017 09:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 x8v7RsnpBrZB for ; Fri, 3 Mar 2017 09:26:05 -0800 (PST) Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (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 43227129566 for ; Fri, 3 Mar 2017 09:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=vZYq19nJGPLVHtYUblDrCl+NMRU=; b=mSGaZ2qNjDACQpgU lQER/BcmLHbKdg5pycGNg5IrRjlaO/rJPA6ChZEmy9zL7Fl/MWrENfIJTtmrpbia infQtBwhgjziDYM5D48lm8n73SM04rSD6drE9vP4T6lTnij/ofXxRy0h8W+yJWl3 VzAqWzvOYLecFhdI4mwYV7eTkH0= Received: by filter0042p1las1.sendgrid.net with SMTP id filter0042p1las1-20088-58B9A72C-49 2017-03-03 17:26:04.643723273 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id LtO1zOBCR1-VSVGAX2yVyQ for ; Fri, 03 Mar 2017 17:26:04.747 +0000 (UTC) Date: Fri, 03 Mar 2017 09:26:04 -0800 From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58b9a72c9f791_2db83f9b450f5c381143ce"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9HwHS8ysdrvu0rvkQQdpBEsvd89UCa/awWFOuNzJEiRYqzYhvwiKcr3NKQ5 5ftTPwfQmE/lVDeMyMS1JTLZqKiGqHkuKKi8fKKlTRCEOg9yBmYHf1QQsWER75F9jbFuy+jjFIBIo4 JTSYmF9wISdpNN18+C/EDOoEq4wAQQuq0DDblVvzJeyh5xtCLuyO0rmsOg== Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] Identification and definition of attributes (#15) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:26:06 -0000 ----==_mimepart_58b9a72c9f791_2db83f9b450f5c381143ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Based on Jim's feedback and the fact he opened the issue, I am going to close it out. Please let me know if you have any questions or concerns. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/15#issuecomment-284016285 ----==_mimepart_58b9a72c9f791_2db83f9b450f5c381143ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Based on Jim's feedback and the fact he opened the issue, I am going to = close it out. Please let me know if you have any questions or concerns.

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on= GitHub, or mute the thread= .3D""

= ----==_mimepart_58b9a72c9f791_2db83f9b450f5c381143ce-- From nobody Fri Mar 3 09:26:46 2017 Return-Path: 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 0F221129570 for ; Fri, 3 Mar 2017 09:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 u7t9ZUdvIl4H for ; Fri, 3 Mar 2017 09:26:44 -0800 (PST) Received: from o8.sgmail.github.com (o8.sgmail.github.com [167.89.101.199]) (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 0CD9D12952F for ; Fri, 3 Mar 2017 09:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=fxlE0/ewp4ImUNx2OaLpY99UM/4=; b=VcHFAeweSCpIZo7f X79uRf3CE1XJgziPIT3LuHGF9Q+MaQPAEFiefiExqRBPkbjvjfOcrRcR48qqGnVX 3xr2EzmOhGs2acd3zKFCF7JQa1LEKOyhxEOPoTCPUS4VFiERVmANPBT/izTbggqV shcBrwRGVJEQswS2TTwBsiU9hyo= Received: by filter0139p1las1.sendgrid.net with SMTP id filter0139p1las1-18392-58B9A72C-1C 2017-03-03 17:26:04.68110038 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id QQSl2CCiS8i5nMBGXasJ2g for ; Fri, 03 Mar 2017 17:26:04.655 +0000 (UTC) Date: Fri, 03 Mar 2017 09:26:04 -0800 From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58b9a72c841ed_57943fa3aa43dc3414924"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9H5TSLzm+DI3Tw3Fqq0Z16042dmehMkXJOPSQDIa28i9kOO2H7kWTzWwWey BPtgwRv/uvrZPGC4Bf7tr28suNhIBhFcvAwMpPFY/hxf4+MGPZaS+HPDfypMNCvAARi0/j2ylHuD1p 0qgPEp1KLhRlv46bkz47ZKVUKM6SoJqY2i5hQszrWuqDMul3PJVIE3jUsg== Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] Identification and definition of attributes (#15) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:26:45 -0000 ----==_mimepart_58b9a72c841ed_57943fa3aa43dc3414924 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #15. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/15#event-985749261 ----==_mimepart_58b9a72c841ed_57943fa3aa43dc3414924 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #15.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58b9a72c841ed_57943fa3aa43dc3414924-- From nobody Fri Mar 3 16:00:38 2017 Return-Path: X-Original-To: sacm@ietf.org Delivered-To: sacm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D77B1129A22; Fri, 3 Mar 2017 15:55:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533287.15846.16376177214580825272.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:32 -0800 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, sacm@ietf.org Subject: [sacm] sacm - Requested session has been scheduled for IETF 98 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:34 -0000 Dear Karen O'Donoghue, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sacm Session 1 (2:30:00) Thursday, Morning Session I 0900-1130 Room Name: Zurich A size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Security Automation and Continuous Monitoring Area Name: Security Area Session Requester: Karen O'Donoghue Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: acme anima cfrg core dots i2nsf ipsecme mile ntp saag tictoc trans Second Priority: radext ace netmod curdle tls oauth People who must be present: Karen O'Donoghue Kathleen Moriarty Adam W. Montville Resources Requested: Meetecho support in room Special Requests: We would like to avoid Monday if possible. --------------------------------------------------------- From nobody Mon Mar 6 11:06:12 2017 Return-Path: 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 29438129979 for ; Mon, 6 Mar 2017 11:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.383 X-Spam-Level: X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 EpoaiG1q-czQ for ; Mon, 6 Mar 2017 11:06:09 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4B2129886 for ; Mon, 6 Mar 2017 11:06:09 -0800 (PST) Date: Mon, 06 Mar 2017 11:06:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1488827168; bh=q3fzuBQqFqxDtkLEvFOgzOrKZz11h/hC3CeTPSkPTOA=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ly1GgaqupP23PBI97mMfyXmQJig/X8xLtKvafOLTsF7oUJN0WdIIh11SJ2a/o+mn0 ePfEUIUIBRCYi0VDYOITmoSqWCxVA6echO75yF8cqDIrKzDrATQWzs4VNPWLWEvEG0 nK2zLB+3JByhFP5GyRq4Da5S4RFp3Ac6dr2Xj0YQ= From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdb320adfa8_324f3fa37531fc3858857"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] Section 4.1.1 - How Known (#18) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:06:11 -0000 ----==_mimepart_58bdb320adfa8_324f3fa37531fc3858857 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #18 via cd34881953333a983e3ff5186821df514fdabf91. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/18#event-988293227 ----==_mimepart_58bdb320adfa8_324f3fa37531fc3858857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #18 via cd34881.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58bdb320adfa8_324f3fa37531fc3858857-- From nobody Mon Mar 6 11:15:23 2017 Return-Path: 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 88BC6129984 for ; Mon, 6 Mar 2017 11:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.383 X-Spam-Level: X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 WXksVD8oCqW1 for ; Mon, 6 Mar 2017 11:15:20 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C57A129983 for ; Mon, 6 Mar 2017 11:15:20 -0800 (PST) Date: Mon, 06 Mar 2017 11:15:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1488827719; bh=f34x4+1NC2maI46syLgeSyQOpo8xAWaBwzhPIFX5K/U=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=aoWJaOiOSI/RgmOCINGeOWMj32xIP6ZZ4V3ufocd1+75U3T9sHWRDBtpnv317poBT FOMhtS5OhIyUJ6drUtR4XqWbGF+W3F0bAzVQfi6TflI8wSkbtRdNLosBVcasqBuRgp 7llVTHNTDR3xQG70E3Ltcn4x0rxpSuAdnK+WHwUw= From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdb5479de73_13b63fef308a1c2c512e6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] update examples that use content-type to statement-type (#56) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:15:21 -0000 ----==_mimepart_58bdb5479de73_13b63fef308a1c2c512e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #56 via e0109f961632e23a28c888c91dca1572c9b643d1. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/56#event-988307757 ----==_mimepart_58bdb5479de73_13b63fef308a1c2c512e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #56 via e0109f9.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58bdb5479de73_13b63fef308a1c2c512e6-- From nobody Mon Mar 6 11:27:47 2017 Return-Path: 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 D925212998A for ; Mon, 6 Mar 2017 11:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 AuXZheyKQynU for ; Mon, 6 Mar 2017 11:27:44 -0800 (PST) Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (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 6F005129989 for ; Mon, 6 Mar 2017 11:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=22x24tQgQ8EtHe7QFf+XYWuB1oc=; b=rxJfdwsrtcPSGD8p z9/DRuCObVcfUuq5af7Pn6Ocvew6Lo0Q+Qd3zOMLY7vfQ59V94UcPAkxEVsymV2i a0WG1oEHP7A8mtYkGxQCY2J9I8gE8aDmiGAYM0ApUdIy9kh54j3wL2KLx5qCWLw+ hTtsrMe0fwtddBSQD4XO/ARahhA= Received: by filter0554p1mdw1.sendgrid.net with SMTP id filter0554p1mdw1-2787-58BDB82B-28 2017-03-06 19:27:39.303839451 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id KtUvb7PhTLqi8mcDDSPcdA for ; Mon, 06 Mar 2017 19:27:39.336 +0000 (UTC) Date: Mon, 06 Mar 2017 11:27:39 -0800 From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdb82b36dcb_43f73ff833aefc3427816c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: comment X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9H3duTepTrJmIOUx0yLCYKlKK2KYjorLwrBIDm4iK6rTIQCxhGZNSExivZt ruIU7RHwqc8BKMCUZDy8uOfLCAIs7q/9nURqAtIIjs8YtoxRtaWjUB7ejdit32M+wPqc7SADKq9CZP tdV7aMd6VG8L46RvL+pyuk43kwukWzY5WaadnIvOofcwtfe0kqjxCCxxLg== Archived-At: Cc: Comment , sacm Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] Consider Network Topology and Location Information as Primary Identifying Attributes (#9) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:27:46 -0000 ----==_mimepart_58bdb82b36dcb_43f73ff833aefc3427816c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Here's a link to the three words location scheme that David mentioned. http://what3words.com/ -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/9#issuecomment-284504553 ----==_mimepart_58bdb82b36dcb_43f73ff833aefc3427816c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Here's a link to the three words location scheme that David mentioned.

http://what3words.com/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58bdb82b36dcb_43f73ff833aefc3427816c-- From nobody Mon Mar 6 11:59:29 2017 Return-Path: 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 843D51299C8 for ; Mon, 6 Mar 2017 11:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 HHxvwNHfKkIJ for ; Mon, 6 Mar 2017 11:59:25 -0800 (PST) Received: from o11.sgmail.github.com (o11.sgmail.github.com [167.89.101.202]) (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 9DC461299AF for ; Mon, 6 Mar 2017 11:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=bmCVFA9ED13IxLMFpTWCzoYaUe8=; b=pIOibd5qSeDbzD9s niCbqDjuhRAxkI07GJd1epCV+a26PA0nZ9/4Ws5sGBLCLnBW8bRnpULg4lvhre/k vz9rFsvTBVYNHFsSNYrEZS9NouCf7kd5I8HVTFkqRTzGeZaRi8nQfpDgioFJOhp/ i43qVnflbObkJx0glumiFnaWvIk= Received: by filter0422p1mdw1.sendgrid.net with SMTP id filter0422p1mdw1-7143-58BDBF9C-31 2017-03-06 19:59:24.496837444 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id 9UUoPjvJQhCu5am-oh_Liw for ; Mon, 06 Mar 2017 19:59:24.447 +0000 (UTC) Date: Mon, 06 Mar 2017 11:59:24 -0800 From: Henk Birkholz To: sacmwg/draft-ietf-sacm-information-model Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdbf9c5c18e_73253ff079b9dc3821205a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: henkbirkholz X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9Hz7XUI7gQ7gNY3Ggu9CMG9XS7sUAV1X7f79gz0zJ0yWSftGeZAHDZlOnzN PoqgVrduv1BrOBZ9zG5OkSxJdIIZzJbrzEkwZo2J/hWokXZDB/OD/kqdga5DAVFFa/2ykf2b0SJ3V/ DICcCO3eHPU837O0GIhStDoA4kPPzPvN2cJqfEl0txDCarmSlGqhMyFE2Q== Archived-At: Cc: Subscribed Subject: [sacm] [sacmwg/draft-ietf-sacm-information-model] Generating IE in the I-D from a CSV file (#75) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:59:27 -0000 ----==_mimepart_58bdbf9c5c18e_73253ff079b9dc3821205a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The threshold of contributing to the set of IE could be significantly lowered (and the resulting entries in the corresponding sections in the draft homogenized), if the IE sections would be generated from a separate CSV file, I think. What does the group think about this proposal? At the moment, a table is generated from the written draft text, which is of course useful, but if we would start from a table in the first place, anyone with a spread sheet editor could easily add or modify the content (e.g. via pull request). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/75 ----==_mimepart_58bdbf9c5c18e_73253ff079b9dc3821205a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

The threshold of contributing to the set of IE could be significantly lowered (and the resulting entries in the corresponding sections in the draft homogenized), if the IE sections would be generated from a separate CSV file, I think.

What does the group think about this proposal?

At the moment, a table is generated from the written draft text, which is of course useful, but if we would start from a table in the first place, anyone with a spread sheet editor could easily add or modify the content (e.g. via pull request).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58bdbf9c5c18e_73253ff079b9dc3821205a-- From nobody Mon Mar 6 12:01:38 2017 Return-Path: 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 840EE1299E0 for ; Mon, 6 Mar 2017 12:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 KkwF1hVJ7Ji8 for ; Mon, 6 Mar 2017 12:01:35 -0800 (PST) Received: from o6.sgmail.github.com (o6.sgmail.github.com [192.254.113.101]) (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 51DC81299F5 for ; Mon, 6 Mar 2017 12:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=gQqX7udcrhvnmiOgcPeSijwPqxU=; b=kejnNRdwAQL9L1yu VVLAX8TptCYu+BMAxbeP4BqIVVbEaG4qPfdincXyJLxGqlXnLCu3oZoZBtcgX3IP 8HUKPLtQTQs1s7cZklciIZmDrU5tRMLgqQhOR+v+0KbzTIzVcB6S/FU7AkvexDf2 Jf4vvoboTD2OXc8+ezo+izqRx7k= Received: by filter0465p1mdw1.sendgrid.net with SMTP id filter0465p1mdw1-31692-58BDC014-91 2017-03-06 20:01:24.854997668 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id OFQG7TYMQzqsdj1A8CaS9w for ; Mon, 06 Mar 2017 20:01:24.821 +0000 (UTC) Date: Mon, 06 Mar 2017 12:01:24 -0800 From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdc014ab654_41093fd32abebc3889630"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: comment X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9H45woNWSkZwb6bWf2UEkeIjtjIrypioXDVVZV3fx2YsaC8e1Bsj3LGSOZk SiWP8L0pWEXyT3f1buiK4Ua4o0GCCndcYqMPgWDzYXvL55SROJmYQMwVERzfQI5aWEJncv9KkRCY0I U5PRHcCBjYPRooOqou0WhGulDB7i1I27W9xWy+ha2hNqwOOJJCLzkpSQMg== Archived-At: Cc: Comment , sacm Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] Consider Network Topology and Location Information as Primary Identifying Attributes (#9) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:01:36 -0000 ----==_mimepart_58bdc014ab654_41093fd32abebc3889630 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #9 via 90b9ef86d117eb139fc573994f03b9068ae86947. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/9#event-988383943 ----==_mimepart_58bdc014ab654_41093fd32abebc3889630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #9 via 90b9ef8.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58bdc014ab654_41093fd32abebc3889630-- From nobody Mon Mar 6 12:02:28 2017 Return-Path: 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 5554B1299D6 for ; Mon, 6 Mar 2017 12:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 DRUKz9u4Ebvk for ; Mon, 6 Mar 2017 12:02:26 -0800 (PST) Received: from o5.sgmail.github.com (o5.sgmail.github.com [192.254.113.10]) (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 26A151299D5 for ; Mon, 6 Mar 2017 12:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=CXkK8fnLYJmCAxIdwCgpVQg3nyU=; b=WN45Ydp1KB09b/42 U+QipCpaXFuR3aeWoC+90p6UQSm1svfgIcuWp8qnlMo8vBMpYg30r1iwZNjC6oGA 0SW1kL39cjgHRUenb5xH2zVBLb57a5OACi3s50Xt5DI5u65zUnP9ohupMK1e/l2D idH71OmbEITZYI03M8NWjhRPjaA= Received: by filter0981p1mdw1.sendgrid.net with SMTP id filter0981p1mdw1-455-58BDC04E-F 2017-03-06 20:02:22.058269398 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id ppIP9WitR1SdsHpNYv6z5Q for ; Mon, 06 Mar 2017 20:02:21.993 +0000 (UTC) Date: Mon, 06 Mar 2017 12:02:20 -0800 From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdc04cac99d_f713f9b3d2e5c30169994"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9H98IKQUrqgyTAFUN7Od3OPK+VmPhOE0mlcg8vyWH15LnJbOTbKPpJq4gRP BLOAK0LKyyv2yvVP7r+dlx4Wd43Fo8wuAIaATRRMlStTz8IFJSrZKaptp0k6908mLMbDTnSWPJAuXF WpxC1svOgbB3AEkqzO2DM4LB84kczUiodaSTgfKWzWsa6MPCnujacZ4MwQ== Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] Generating IE in the I-D from a CSV file (#75) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:02:27 -0000 ----==_mimepart_58bdc04cac99d_f713f9b3d2e5c30169994 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit +1. I like that idea if someone wants to put it together. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/75#issuecomment-284514770 ----==_mimepart_58bdc04cac99d_f713f9b3d2e5c30169994 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

+1. I like that idea if someone wants to put it together.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58bdc04cac99d_f713f9b3d2e5c30169994-- From nobody Mon Mar 6 12:45:46 2017 Return-Path: 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 C493F129A0F for ; Mon, 6 Mar 2017 12:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 7m-OFwEwyjt8 for ; Mon, 6 Mar 2017 12:45:43 -0800 (PST) Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (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 5FD56129A07 for ; Mon, 6 Mar 2017 12:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=PAnYQJc6VDTZqWZ0aEfEmHAIuwE=; b=RZnLip4cROyqjrL8 sflMzIuz7V+gtYxeXyh3YenaKTlV762oTER1gfSNHwnPOhGKQRp2G59sMVjGcOPx CiBmw9n7Tk4rP+4cVXVAYIPSi7UTsGvjNb+o50UcBQEQt/dQj5ZFb48JAo/ij5h0 rmHhE3xNQ6PNnLQZC18HgItiw5Q= Received: by filter1126p1mdw1.sendgrid.net with SMTP id filter1126p1mdw1-12280-58BDCA76-19 2017-03-06 20:45:42.171311488 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id snUEmzE5RnecMXbYaSbxew for ; Mon, 06 Mar 2017 20:45:42.155 +0000 (UTC) Date: Mon, 06 Mar 2017 12:45:42 -0800 From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdca76101d3_35d23fc0afdd7c3c2030dd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9HxGln4ikXLg1tcqPqaC3ytG6wQ9PdFdTXmdNNVCvtunvDMFsj5cJrSGNBJ Z+WVlcSZfcgXxsMinbNR6qbBKOIA0wJYh+gHsT83iz6WwErof7b5EZeXMimxcTVROhDBYTIrcxR5HJ v7lAQP/e5mmBEjTq4HDzivI/gwljpoSSoMRgpmPqJXp11MKw4qPdscuKyA== Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] how to indicate special things about information elements (#39) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:45:45 -0000 ----==_mimepart_58bdca76101d3_35d23fc0afdd7c3c2030dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #39. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39#event-988453880 ----==_mimepart_58bdca76101d3_35d23fc0afdd7c3c2030dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #39.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58bdca76101d3_35d23fc0afdd7c3c2030dd-- From nobody Mon Mar 6 12:45:53 2017 Return-Path: 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 94F49129A0D for ; Mon, 6 Mar 2017 12:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 kmbO-A1l606s for ; Mon, 6 Mar 2017 12:45:47 -0800 (PST) Received: from o6.sgmail.github.com (o6.sgmail.github.com [192.254.113.101]) (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 DA03C129A12 for ; Mon, 6 Mar 2017 12:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=EXLn2QiAuMfWXOemZYXIdZT1AFk=; b=bCEOUEbMJqndWmcv D0JgPGnmYaFKHwaAwceswD6xvryFNwZ1+KvP/K/gW2isELN8wVJqSNGKMDgY35AP v1uhLYigNLkP3ss7CXct3Fb1enGJrFCAzc1Fggy6+4xnRb0/NfJQ/P45LpzmfLXL hVnVgDUILBa0VtUHD5YMHPzpiIs= Received: by filter0830p1mdw1.sendgrid.net with SMTP id filter0830p1mdw1-5837-58BDCA76-1F 2017-03-06 20:45:42.347363362 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id bQEyhjvtQDaLyDDnr9Do0g for ; Mon, 06 Mar 2017 20:45:42.337 +0000 (UTC) Date: Mon, 06 Mar 2017 12:45:42 -0800 From: Danny Haynes To: sacmwg/draft-ietf-sacm-information-model Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58bdca76322c9_7a7f3fd37000dc2c1382a7"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: djhaynes X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9H41GED4ggEVKYc/U2uci1mM9OdvWQagKSG2qUQl9bDojGcw6sf9ACJbtM5 XU33VfA9sLilp3YHLA87qiHhUAnWN31Jnf5rzZ44r8x80yYFR6OxOo71+NGDDVgl7vRYGCMK+VLgSX QyXNBqkytCpjL9Fk7ee0AVsl0zpNaSTwYdPg0wKsAgQzOYkxuuYyVEvq/g== Archived-At: Cc: Subscribed Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] how to indicate special things about information elements (#39) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: sacmwg/draft-ietf-sacm-information-model List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:45:48 -0000 ----==_mimepart_58bdca76322c9_7a7f3fd37000dc2c1382a7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I believe this issue has been overcome by events and can be closed out. The WG IM and I-D IM have been merged (see #41), there is a tracker to separate IEs depending on if they facilitate communication between components and endpoint information rather than by metadata, designation, etc., (see #60) and whether or not an IE is useful for endpoint designation or represents privacy information is being left to the an organization deploying a SACM-based solution (see #17 and #7). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39#issuecomment-284526654 ----==_mimepart_58bdca76322c9_7a7f3fd37000dc2c1382a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I believe this issue has been overcome by events and can be closed out. = The WG IM and I-D IM have been merged (see #41), there= is a tracker to separate IEs depending on if they facilitate communication= between components and endpoint information rather than by metadata, desig= nation, etc., (see #60) and whether or not an IE is u= seful for endpoint designation or represents privacy information is being l= eft to the an organization deploying a SACM-based solution (see #17 and #7).

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on= GitHub, or mute the thread= .3D""

----==_mimepart_58c6eb678c4b_6a3b3faa83391c381093d8-- From nobody Mon Mar 13 12:06:26 2017 Return-Path: X-Original-To: sacm@ietf.org Delivered-To: sacm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D734412945C; Mon, 13 Mar 2017 12:06:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943198184.20381.1482546414818668489@ietfa.amsl.com> Date: Mon, 13 Mar 2017 12:06:21 -0700 Archived-At: Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-information-model-09.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:06:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Automation and Continuous Monitoring of the IETF. Title : SACM Information Model Authors : David Waltermire Kim Watson Clifford Kahn Lisa Lorenzin Michael Cokus Daniel Haynes Henk Birkholz Filename : draft-ietf-sacm-information-model-09.txt Pages : 155 Date : 2017-03-13 Abstract: This document defines the Information Elements that are transported between SACM components and their interconnected relationships. The primary purpose of the Secure Automation and Continuous Monitoring (SACM) Information Model is to ensure the interoperability of corresponding SACM data models and addresses the use cases defined by SACM. The Information Elements and corresponding types are maintained as the IANA "SACM Information Elements" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sacm-information-model-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-information-model-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 13:45:34 2017 Return-Path: X-Original-To: sacm@ietf.org Delivered-To: sacm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CA8129B1F; Mon, 13 Mar 2017 13:45:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943793333.20338.16215776544084994307@ietfa.amsl.com> Date: Mon, 13 Mar 2017 13:45:33 -0700 Archived-At: Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-nea-swid-patnc-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:45:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Automation and Continuous Monitoring of the IETF. Title : Software Inventory Message and Attributes (SWIMA) for PA-TNC Authors : Charles Schmidt Daniel Haynes Chris Coffin David Waltermire Jessica Fitzgerald-McKay Filename : draft-ietf-sacm-nea-swid-patnc-01.txt Pages : 91 Date : 2017-03-13 Abstract: This document extends the PA-TNC specification [RFC5792] by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA server (as described in [RFC5209]). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swid-patnc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sacm-nea-swid-patnc-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-nea-swid-patnc-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 13:51:13 2017 Return-Path: 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 5A1A0129496 for ; Mon, 13 Mar 2017 13:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 jf7W5FmL_-_q for ; Mon, 13 Mar 2017 13:51:10 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4981293D6 for ; Mon, 13 Mar 2017 13:51:10 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69DE56C027A for ; Mon, 13 Mar 2017 16:51:10 -0400 (EDT) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 5459F6C01E3 for ; Mon, 13 Mar 2017 16:51:10 -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.1263.5; Mon, 13 Mar 2017 16:51:08 -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.1263.5 via Frontend Transport; Mon, 13 Mar 2017 16:51:08 -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=mLWDEj9MZDvwNOvK32krnunpXF3ihTm0szIqSBaHW0E=; b=OEckxBmajYwqvoFHpuD+bkhn7byEFqIZC38WGXY36sGmWYBRCf8liq2tdsthD2DJqzbhnYKDxiUy8pvV0onmBp85krFHXt5onbsmNe9NbBSMSnR0OqGrJkbN2fiUn0kbiWi11MmQNlayKdR9ovPqwhsk6IWL2Zo5TlVO96cd+xE= Received: from CY4PR09MB1351.namprd09.prod.outlook.com (10.172.67.9) by CY4PR09MB1349.namprd09.prod.outlook.com (10.172.67.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Mon, 13 Mar 2017 20:51:07 +0000 Received: from CY4PR09MB1351.namprd09.prod.outlook.com ([10.172.67.9]) by CY4PR09MB1351.namprd09.prod.outlook.com ([10.172.67.9]) with mapi id 15.01.0947.023; Mon, 13 Mar 2017 20:51:07 +0000 From: "Haynes, Dan" To: "sacm@ietf.org" Thread-Topic: I-D was expired Thread-Index: AQHSm8iwzX9VZxPGyEmqUoBcCk4fSaGTPSJw Date: Mon, 13 Mar 2017 20:51:07 +0000 Message-ID: References: <148938890584.26845.4339531095386582731.idtracker@ietfa.amsl.com> In-Reply-To: <148938890584.26845.4339531095386582731.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.160.51.87] x-ms-office365-filtering-correlation-id: c5430700-4717-4122-18d4-08d46a52ac63 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1349; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1349; 7:tXIRjB8fSY12kxg4ugZIG9lRWfZIDuhfdroISbQCHvzEy/vU11ND/qyOyu1JOrSdi0XBmUmGXoa8YdZdO+T5s4CDI8/VDgcmloeH7l9u2eOgKhxAWPaSAKY9v9PNEz8anqByg6hUZkq5bdU0yZzJg1wFlFzHl+/RKWEZuclPF6hG8lj1N0PUdbd0gUB8XxsNmYg+UpPvwOZxhmPxYwYQkuCJb4oD8lOKHynOGWkq/0JK7xJyLa9J0KUmPfaXkErGAKdNEq6sliFMMS3VIpncaQx6up7fSNjKqwFMkDfrI/cvxJCmlk02WT23y6EIHfsB0RtVQZKJec/7lYkNTjdS2Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:CY4PR09MB1349; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1349; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39860400002)(55674003)(53754006)(69234005)(13464003)(377454003)(3660700001)(2351001)(8936002)(66066001)(7736002)(305945005)(110136004)(38730400002)(6116002)(1730700003)(5660300001)(3280700002)(3846002)(2900100001)(99286003)(102836003)(2473003)(8676002)(81166006)(86362001)(6306002)(55016002)(74316002)(25786008)(5640700003)(106116001)(7696004)(122556002)(6506006)(6436002)(2501003)(54356999)(230783001)(77096006)(53936002)(76176999)(6916009)(2950100002)(33656002)(229853002)(189998001)(2906002)(53546007)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR09MB1349; H:CY4PR09MB1351.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 20:51:07.5818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1349 X-OriginatorOrg: mitre.org Archived-At: Subject: [sacm] FW: I-D was expired X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:51:12 -0000 SGkgRXZlcnlvbmUsIA0KDQpKdXN0IGFuIEZZSSwgd2UgbGV0IHRoZSBTQUNNIFZ1bG5lcmFiaWxp dHkgQXNzZXNzbWVudCBTY2VuYXJpbyBleHBpcmUgYXMgd2UgYXJlIHBsYW5uaW5nIHRvIGhvc3Qg dGhlIGRyYWZ0IG9uIHRoZSBTQUNNIFdpa2kgcGFnZSAoaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2FjbS93aWtpKS4gVGhpcyBkZWNpc2lvbiB3YXMgY29uZmlybWVkIGF0IHRoZSBKYW51YXJ5 IDExLCAyMDE3IFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nIChodHRwczovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy9pbnRlcmltLTIwMTctc2FjbS0wMS9taW51dGVzL21pbnV0ZXMtaW50ZXJpbS0y MDE3LXNhY20tMDEtMjAxNzAxMTExMDAwLTAwKS4gSSB3aWxsIGZvbGxvdy11cCBvbiB0aGlzIHRo cmVhZCB3aGVuIHRoZSB3aWtpIHBhZ2UgaGFzIGJlZW4gdXBkYXRlZC4NCg0KSW4gdGhlIG1lYW50 aW1lLCB5b3UgY2FuIGZpbmQgdGhlIGV4cGlyZWQgZHJhZnQgaGVyZSAoaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zYWNtLXZ1bG4tc2NlbmFyaW8vKSBhcyB3ZSBw cmVwYXJlIHRvIGRpc2N1c3MgdGhpcyB3b3JrIGR1cmluZyBJRVRGIDk4IGF0IHRoZSBlbmQgb2Yg dGhlIG1vbnRoLg0KDQpUaGFua3MsDQoNCkRhbm55DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBJLUQgRXhwaXJpbmcgU3lzdGVtIFttYWlsdG86aWV0Zi1zZWNyZXRhcmlhdC1y ZXBseUBpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1hcmNoIDEzLCAyMDE3IDM6MDggQU0NClRv OiBkcmFmdC1pZXRmLXNhY20tdnVsbi1zY2VuYXJpb0BpZXRmLm9yZw0KQ2M6IHNhY20tY2hhaXJz QGlldGYub3JnOyBLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTsgQWRhbSBNb250dmls bGUgPGFkYW0udy5tb250dmlsbGVAZ21haWwuY29tPjsgYWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5j b20NClN1YmplY3Q6IEktRCB3YXMgZXhwaXJlZCA8ZHJhZnQtaWV0Zi1zYWNtLXZ1bG4tc2NlbmFy aW8tMDIudHh0Pg0KDQo8ZHJhZnQtaWV0Zi1zYWNtLXZ1bG4tc2NlbmFyaW8tMDIudHh0PiB3YXMg anVzdCBleHBpcmVkLg0KVGhpcyBkcmFmdCBpcyBpbiB0aGUgc3RhdGUgIkFEIGlzIHdhdGNoaW5n IiBpbiB0aGUgSUQgVHJhY2tlci4NCg0KDQpUaGFua3MsDQpJRVRGIFNlY3JldGFyaWF0Lg0KDQoN Cg== From nobody Mon Mar 13 15:41:33 2017 Return-Path: X-Original-To: sacm@ietf.org Delivered-To: sacm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1BC129458; Mon, 13 Mar 2017 15:41:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944488759.20417.13248319188558620818@ietfa.amsl.com> Date: Mon, 13 Mar 2017 15:41:27 -0700 Archived-At: Cc: sacm@ietf.org Subject: [sacm] I-D Action: draft-ietf-sacm-terminology-12.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.17 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:41:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Automation and Continuous Monitoring of the IETF. Title : Security Automation and Continuous Monitoring (SACM) Terminology Authors : Henk Birkholz Jarrett Lu John Strassner Nancy Cam-Winget Filename : draft-ietf-sacm-terminology-12.txt Pages : 27 Date : 2017-03-13 Abstract: This memo documents terminology used in the documents produced by SACM (Security Automation and Continuous Monitoring). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sacm-terminology-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-terminology-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 15 22:31:49 2017 Return-Path: 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 6652F1241FC for ; Wed, 15 Mar 2017 22:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.178 X-Spam-Level: X-Spam-Status: No, score=-8.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 hn0gFty7KbIx for ; Wed, 15 Mar 2017 22:31:48 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D11F12025C for ; Wed, 15 Mar 2017 22:31:48 -0700 (PDT) Date: Wed, 15 Mar 2017 22:31:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1489642307; bh=bwvfy0KbozAsZXqZLFBd/o56MtLvQAZHFhHcGCUdy9Y=; h=From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=H763y9mgQiFnywihDV0+r1+IUhAlBEVX2Lzd/kAQpLsQ6RsQu2GQ8Tuhu36XxQmKH nfXTJ88Qd9HZfMJedZHYqQ5WtRPelB3CshSMTuKJmYz5Yl+Yddd+qP2oousbZRhUxo Jqj1lZ4wpB80xwgotEpdLcHjAuDNVInCEbdsh9CA= From: Jerome Athias Reply-To: sacmwg/draft-ietf-sacm-information-model To: sacmwg/draft-ietf-sacm-information-model Cc: Subscribed Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58ca234365a9c_1a0e3fea2a9b9c3c9227a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: athiasjerome X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org Archived-At: Subject: [sacm] [sacmwg/draft-ietf-sacm-information-model] softwareClass does not support softwareDependencies (#76) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 05:31:49 -0000 ----==_mimepart_58ca234365a9c_1a0e3fea2a9b9c3c9227a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit As per current softwareClass, and as indicated in CIM_SoftwareIdentity Version 2.28.0 "Note that ConcreteIdentity can also be used to describe the relationship of the software to any LogicalFiles that result from installing it. As above, there may not be sufficient detail or instrumentation to instantiate this association.": I suggest also adding CIM_SoftwareElement -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76 ----==_mimepart_58ca234365a9c_1a0e3fea2a9b9c3c9227a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

As per current softwareClass, and as indicated in CIM_SoftwareIdentity Version 2.28.0 "Note that ConcreteIdentity can also be used to describe the relationship of the software to any LogicalFiles that result from installing it. As above, there may not be sufficient detail or instrumentation to instantiate this association.":
I suggest also adding CIM_SoftwareElement

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58ca234365a9c_1a0e3fea2a9b9c3c9227a-- From nobody Thu Mar 16 07:22:55 2017 Return-Path: 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 47ECE1294E8 for ; Thu, 16 Mar 2017 07:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=usdhs.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 NBqZQbw0q2eU for ; Thu, 16 Mar 2017 07:22:50 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0079.outbound.protection.outlook.com [23.103.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DAF12951E for ; Thu, 16 Mar 2017 07:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=usdhs.onmicrosoft.com; s=selector1-hq-dhs-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b5SxdbiwTr70/RzBn5IUq4mC1HHoVWJWbPkE8nSRj5g=; b=ThyRD4kCtz4iICklLf5NGqfCp7jmnxZQofnIV5hTbKg31ioQviPk6MYwuu+IomKiiyzHAhfJS6LPYFvyd++IBssmZZglJP9PpN49IqJMIspRUcctuBc/N0HqbM5XIPEsc/lZ5CLvo5Bf26+0D3TIj0UvPwKq27u2a4EauVTYG4Q= Received: from BLUPR09CA0023.namprd09.prod.outlook.com (10.255.214.151) by CY4PR09MB1783.namprd09.prod.outlook.com (10.172.139.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 16 Mar 2017 14:22:47 +0000 Received: from BY2FFO11OLC012.protection.gbl (2a01:111:f400:7c0c::157) by BLUPR09CA0023.outlook.office365.com (2a01:111:e400:8b7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11 via Frontend Transport; Thu, 16 Mar 2017 14:22:47 +0000 Authentication-Results: spf=pass (sender IP is 216.81.85.157) smtp.mailfrom=hq.dhs.gov; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=HQ.DHS.GOV; Received-SPF: Pass (protection.outlook.com: domain of hq.dhs.gov designates 216.81.85.157 as permitted sender) receiver=protection.outlook.com; client-ip=216.81.85.157; helo=D2IAPPREACIP5.dhs.gov; Received: from D2IAPPREACIP5.dhs.gov (216.81.85.157) by BY2FFO11OLC012.mail.protection.outlook.com (10.1.15.23) with Microsoft SMTP Server id 15.1.961.10 via Frontend Transport; Thu, 16 Mar 2017 14:22:46 +0000 Received: from unknown (HELO D2ASEVPEMHU04.DSA.DHS) ([10.239.234.227]) by D2IAPPREACIP5.dhs.gov with ESMTP; 16 Mar 2017 14:22:46 +0000 Received: from D2ASEPREA009.DSA.DHS ([10.232.104.26]) by D2ASEVPEMHU04.DSA.DHS ([fe80::30c5:1af3:de41:ff07%15]) with mapi id 14.03.0279.002; Thu, 16 Mar 2017 10:22:45 -0400 From: "Struse, Richard" To: "sacm@ietf.org" Thread-Topic: Cross-posting: Request for Public Comments on STIX 2.0 Thread-Index: AdKeYMXflf9gh1JMSqSkAvk7HgQ22g== Date: Thu, 16 Mar 2017 14:22:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.239.235.225] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01B3_01D29E3F.3EDC9F20" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:216.81.85.157; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(2980300002)(438002)(199003)(252514010)(189002)(9170700003)(512954002)(54896002)(110136004)(8676002)(63266004)(53936002)(2900100001)(7066003)(99936001)(2906002)(2501003)(53416004)(33716001)(45126002)(50986999)(236005)(7826002)(33656002)(606005)(77096006)(38730400002)(106466001)(81166006)(6306002)(8936002)(9686003)(5890100001)(260700001)(2351001)(356003)(102836003)(84326002)(7736002)(5660300001)(3846002)(54356999)(16799955002)(19609705001)(2920100001)(790700001)(86362001)(1730700003)(568964002)(42882006)(6916009)(5640700003)(8558605004)(6116002)(189998001)(71636004)(270700001)(2930100002)(7906003)(55846006)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR09MB1783; H:D2IAPPREACIP5.dhs.gov; FPR:; SPF:Pass; MLV:sfv; A:0; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC012; 1:r5lQTdKqECEc4HB2nGXh2FW+UdzQjwvUzGnQl2lqiKugZDLmwl1pMbNv0yZYlWrUTF+qkNaHFiynbNimpd7t4s8tukqks4kNEKVhoHdmUyscY1W3gjemAkF3PwcYRLqDusPg1qN6kQh5cTz/CNwreneTuaLdWUVlR7DM4PCyTVWhOX46ACKkzcWEtJk2x11I2faY+FQOCcULzReNoEUOFdB/nwwp7hISC868FhrMcilnfpRyfj1apALLnFriYWnTiVZp1PCFW2ml6CdlZZxr6Pe5w4TyHCubWyVp5BtBu7X88a0CNSmq/quq1OSCvHnLkiPmlw+aE5T9K54Mslnk2jaVSbj8rIjGU9gVr/EvgrDY3joTvmn3COhEv3sGHcfyaLXbXpU+VsFibbgnTFmKw8Bq8Cqf2sfE/hTpy+n46lZ+41brmWELJmccGDzTvdlnJLOvM3L+kqqi+SUaEJ/sJbdOVDnUwger0q8S/mFr98xFsFV+HJwzW9HOyR44avxRyfZi6SfH5KY1BCiUFBZCdg== X-MS-Office365-Filtering-Correlation-Id: 02486574-2084-43a5-2913-08d46c77eb3c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:CY4PR09MB1783; X-Microsoft-Exchange-Diagnostics: 1; CY4PR09MB1783; 3:DDwQ/NXTHh7FMK6ZNl1ZgJTsRTGKZYgdcU/0CKfP7iV9Xo+yS/CL6m3oJFASy33CG3bnFRNIHjbxJbmKXA6kNhAyaAAIVF7cPzDdGTrnncjfEYsL40yywFYUZ4vwuaXbP3d230WCjaaZbE0ivs95ukba72dTZwy5x7u5HCwuui8i3p5tB3xhKNTDPS6FtDKXA932dwTDMI3IqKdL8rRVMHbrGdIyz6hYtN6z8+aW3Cn1qooBNGkRCq3mNxiO6fcMfNYLpz63B1puuazIh4kENBcL+5Qur2yLFCO57YV4GGPGFaPFxyT3Gfa2rQoGL5I8jn7IPNLrqnfKa+m5e8cS5k58ux4FNeCrNfcJOE2z857USSViO7sG22DqW4PW2olDb0K93RbwSYN8tiYRfid6Wg==; 25:i7A3gOKJdqr1mmC1I2pWI2qAsH0E/EAsPSgbRia9t9f5cmKVJo3/aavF9oAd7I7q2jWkglQOeydRZXE/R7XRqDPy7z/XHCI9VwCO2VzyujJzI70hsRe/WjYFGBx0CR6kO/Vm7S9ZM0f/yVJDKYe05pQBpqTMnKMVJ9QZxPsaw204MhFXYRzKiM7zUwTzIpPPUUz31FUw4g0awqqjGe9u/8TtNP74wYB/e8iLBl2hiz9KOQd2IOaMa9yMUaMZnCfoxKE3Ys3/H0oNweyuf4RCVZaYXajubPaPaZVTgeO4Tf8KGThzsKBDPHhT94MbXhX7m+xlN6BNB2/iDmwUQdvJ4uxuFZ5sVKjEwjq8aeDujjZeKgiqkNZLMtxw9BPpeSVx1Ercy5BObgL0xDAoaWw3puJjAh0xs8i+GXBhQ3k9Qrp+V4AMm5TWZeIaq7rQMcPn+F0FTciBxa2wGinaE10jNA== X-Microsoft-Exchange-Diagnostics: 1; CY4PR09MB1783; 31:pWGrb4YKhEDeFS1J7VAL1VJ921YA64MrmFbb3uZSVtvGSPjXwwSM3x+ZyZY0gKwFHmr2oe86Jdu5sm3TzuE8CcUhkYehJz0MfGJOaKJQIgV730KM1F90RZpm1EhJsMLEEFWPvDylrZM6OZWQHp4DATbe87bZDUq6Y7ihdFF1jrHeyJvIJNWRrArddO1bOXCUjPtXs0sK9z59jm2053jd7rk6vquZd/Z2tYpVdJQ8gzh2/hc6gxlGtXWp7dpP1Qz7; 20:B3mKEOxf24/8jULROWUQWzNQPCe7sirNk1ptggfEwZHdmhkmrxDmV7ybQxsXWyyICezBNCa7flfvm3Oro/C20ppiML+vatwv/zl7uEF7XgYb9E/DENHn6aiTl2laRfwCUbtwbm4/3vAxMZVNw2szsaAFu48zgBlHG5JyINYUoIL4sM05YbwpyMH5/BtElT/K1026vDsqBqU2d0GegRAvFQ4/j26i4l9UVW15QiJTDoA/ar3C6Pz4/vmfRjMaFWoi5wgEI6vNpqnxqIuF19z53tjjF6yYqIzsrC1dHRe7IiVaMzqW15oO1JVMlwpbHVHkxtI8ESR4hPjN080C8ct7mi4q83SaOrABdRhHWIUMzER+KUCeUQgZK2lM+scfRmxsobdIAfBKr3EGuyY2/12yriUJlWO6JzglEekhNxJpD3U8f5ErSFpnMpDa5ZDdR++ETVNbYIqFaJMVEmrG5M2nu5Tk+MV2Arymje924CgUD8MdZxEyayoJ/WDt6XrUGt0I X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(38170694233816)(152865683959669)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13015025)(13017025)(8121501046)(5005006)(13023025)(13018025)(13024025)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(6072148); SRVR:CY4PR09MB1783; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1783; X-Microsoft-Exchange-Diagnostics: 1; CY4PR09MB1783; 4:9Uj0ekNSKBsh62NEsnuouCrseA0IBbthgeT95EuOtSItreYfI8SEbTVnEbRb13AmbMxp65lhYxsEdD5RXk/+4O4QyOYejlN1QPMlPGK2TboRZqaqhMhqNRt/8dldktcChlgayL58QKBxMLfZ+JgyLyj/Nm3LJr8be9NVXYFBtw5h0stFbzjZ7FWdKQHbQmeByPHoxlzfonq0Be/Ft7Ei1r8/ZwobspqbDWs8Y2fwo0xGWaXQD0jY9vAavewQwua/ipElBdzIHsn3ePEtHaX6wqDUbikgxIVmEGuuUgDkJoTy+1lHk1HZ1Hp02lf+aG9aaSKQAb69CsScJTCGU5vBp9DSlfkFYhLVqZPRsrEE16XH4C1kWex5mMOVH1S3rih/sV8+SQo6BGIQ3OoFjjv9NV+WIrNHfTIu1oWOPR+4vBk/1qyy4JHW0qN2SLH3YTfdwXDBHE4BFmj4QAHRbfSdFxP0C75gPPB7iB5wqfTn5WKjAcfFtx3BaXpZIDmEF8CPKrWf0uI6wZLCKPSKfJETGMnoiucbJf6nrcz/Z53gPVWdreBIUJSxjl/oViq9gVtcxkGvyWcYMGlBDwpYHb2i2drQlDX8WSd96UOYggB26kwLmIY/rjVcvz4YwIV49/Bc+mvGtJhwhI0im/il9ru4u96Q7E2McwTKkLvFmFzUCs/CBNe9JZWGZO+3R3VjeljsiM6chDvAfJ0ANQi1Eejd/77+ucHgJutE6j0pdG6Z0vrDo9LT0bBihg6FiBA1o8/rygpKbVG2WZOMKzjDL4lWbYMmcADkHMS2yxVxdSomh/TebY0FfOKk6hjgccDQr2dtY+HPWaBO0rZBHcZTDTDCXomg633QxJE/jNiH7+Ik6QA= X-Forefront-PRVS: 024847EE92 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR09MB1783; 23:o8RepAWCkg4lacFb0md72nxTCC4cfkWBBf9cLD9vS?= =?us-ascii?Q?t/eLoANd+l8b09wOiy2B7CapT3zp4yj/8aWRG9DA0AgZkDkNReiv6KouWqeU?= =?us-ascii?Q?RoKEF7+lsGSPuRVgvG9pyHjmMUDPrFGE3U84kVwwLhbTY3ZDCH0amPy6T16K?= =?us-ascii?Q?TQulojJPUGuKSuXvS6NgW9UFcYKN8uBxU1k9mfKaMaOYipLHfl+Ui8OYJR7o?= =?us-ascii?Q?n30oWyxdQP9KmfPzodJQ9h72MgdCU3uAUNutoiIrKJUyAqhdBIaKgy928e0l?= =?us-ascii?Q?iXegKWWu1kjyiVIjxtyCtM0rhIG45GSD3mb7G7VPUr4XI0qy/lYUsE+ys2Bl?= =?us-ascii?Q?kKzPiX+KPinoukEzyQfg5zUCw3GjgEmCUy5F1di/pEpHDBa7XrZsgwjuaYE0?= =?us-ascii?Q?bAi+kijrU3Zzj7r9fSF6JS1ucCA0d7H8kf12gZ+cfuVgCAhZV71dK/P/jfCd?= =?us-ascii?Q?khpuwTryhLNGT3+jNM2DCUCcDMVodFulAUhQ7kThzWzAjc0+RZR2Sye2UA+K?= =?us-ascii?Q?Sja4F3XHILN5WVyh5OJdm7P/utPK/1Fnhvhv6In2/SG/045YgWrv5UNje5jv?= =?us-ascii?Q?bCAKfk2LMRPRLdVjwBWR6jnzQDS/QI+ZAwucdGG/pKrIbl35Q8LooUuVdCDS?= =?us-ascii?Q?/d+tNB2LMTI8CerzJEAMt+/QG7FMUl8U0Dg7uev1KUR9MAoLvf7gqyF9dphL?= =?us-ascii?Q?ltJ39fjBpEguEOFUcVI5MhlHXt5di9+45xZdyYKp6LNxGrfTLg1yREheq1cq?= =?us-ascii?Q?FNJ6ZAIvZvuyXHWlOEN9/AKmQ7vgEWJryYDoxahXUmT1hllryOWFXvji7sch?= =?us-ascii?Q?hRf2G41kuroSuuVkuAkZR3StpWqPl/i37ld4zMBoTy58sF6EYR73I+/oxV1a?= =?us-ascii?Q?H6+8Ed5i904X7VQAJN8r4ZceoBXC64gpSy02YEwc6Lspm0BYOSSNv8EVePLB?= =?us-ascii?Q?OFS4oesU8PU8EFDbli2B+JF4xPXJd/4Ljfr+u1GdWbvxQfZW7YAz2HBh0bB4?= =?us-ascii?Q?nfU7qNgBNU8A/Ycc/te+bhQQTDaMcnoBHKbTeJECjR/vXHuenKNCRlq4K5+P?= =?us-ascii?Q?bU4hLIGK35DgAlfj3oGSXpIWJMG0knCVkh9QSDJysJ0SXjYrlKIPLvIBQNjk?= =?us-ascii?Q?+UBRB4kZsXOsalKmRN1rqiIZ2Rr9gVFaiZR093dpZpF4B2wNiSnXw6vOJEjg?= =?us-ascii?Q?rQ2C6cHO4efh5UyxNdztTP6xBosn6x4KyUJwhqvKy0MOUBpn/YJ0xWOULH7o?= =?us-ascii?Q?a686836GridYRYsIQu1T4MYY8m26qileFDFWgCN2ImThILBIOCmbZxNo8279?= =?us-ascii?Q?KXi86ydUDVNGdjkq+83CjawI7rCpVXiq76Q/blytAccjPYHEkEv8CUi1onq4?= =?us-ascii?Q?4rCmVYGTr2Qudmxi5hZI2OfSXDzO2r0up0p/cPnMsAwOZXiFUXl2d0NaIyaD?= =?us-ascii?Q?7ZE8WN2ymMJMrDlwWIalmjn6jraJnu4VKGQt2CDJ9Xf5BKmd2j91OSr1+Y76?= =?us-ascii?Q?CqTXHMjYDXu5BDLK9MGIpEzftUXYCSXc9ve4bZ5WCBbC4PNckGWSt7nxIQ/f?= =?us-ascii?Q?OwzXFl1MmngCb7LH+uslc9K5Gib/hzzRIrBARW87vnyWsIfsij7X3PMCjCL?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR09MB1783; 6:tkYuW1SiZps+GaNxPsaOeJ8OP+1ZSt3mHI2XVtB0ehl1nfBu2iYNcFz+Rqx0CKPT80mhp6P2xztueX3WfofSd2UAMP7MFBafOD4YK+5nZ8swpdfkAw2Sy/FgpYS5ys576WsLkI9nauAk75/aX61Q1LtFYg3PRvRi0ep7/5A8q+eeqUTmhXVXbjCDcnsRD3/xqRH5DGNJ29BOH+qo2RSC/SVZC8qadIlcLWAnnJo/h2GoHL29Gz4NYhrF/6hBUJtCkwu1CIKQriyxAlw5+o6aDB9fgqoamDwVs5kgH55b/8JOjs7POYejU0qqaXKgD7/2ymrm2wWTIZGlIWcfmZHgU4wBAFmRekd25WY8nEACIo58M4x1Tp20Bf/5/yhdW0pn9wBsf1BaE++loBnaNBYJyyyFpt1/1sN90mFyCJCfzU4=; 5:fIGbJkdQC88DRSedbGP5QTDBhWRZZ7t0cvbERG8PKM15p6ympKPXHNarQq3yuAL+V6fuJ5e50V/+INrodWcH+IoqduJn058bXEuXe4WXkkBNjGBtfLxoHInKQNvx3XBD5Yiose4fYNkHyyhzYext2w==; 24:xIcKD67lO2fPWuxIkPeyon02J6rV0N+kwUmvzRbJUTMfHpGQhCvy9K0uTk+gfloB1uhgNQx6cSk8FasNhcfDzKWK3CkVHaaJcR4X0GmV2D4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR09MB1783; 7:8Klim7sttCAvAkQNfibxrH4IRZn2+V/9JCZ/tafuY6ErU2atpOYPhXLpQ883KyZpdPjLD2AvZ5d07miFHpu1I6cb9JfT414TNCj2wPHi6wgp6fZV5kusc3hjQs5svkXG193XyRHsr4iG0u+bL6wwVHihjs0jo+2boO06rUnj6MtlCSKKO2427zRKbObFMuB9FsYuxzH7x+du2Izjn1D7A6teGQjzHqoOnEy+CbVjbwTNDBu7uI9RGYGahnU+qSbpr/oxMjxcsvvZusDCrL8p7Ys7C3Vncr9tQDGGqGh3jFiiMUV/LbVtQQYjZuwr2aTu38Lr0r23jUbh3rhLStrGUA== X-OriginatorOrg: hq.dhs.gov X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2017 14:22:46.7239 (UTC) X-MS-Exchange-CrossTenant-Id: 3ccde76c-946d-4a12-bb7a-fc9d0842354a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3ccde76c-946d-4a12-bb7a-fc9d0842354a; Ip=[216.81.85.157]; Helo=[D2IAPPREACIP5.dhs.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1783 Archived-At: Subject: [sacm] Cross-posting: Request for Public Comments on STIX 2.0 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:22:53 -0000 ------=_NextPart_000_01B3_01D29E3F.3EDC9F20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01B4_01D29E3F.3EDC9F20" ------=_NextPart_001_01B4_01D29E3F.3EDC9F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Cybersecurity Community Member, The OASIS Cyber Threat Intelligence Technical Committee (CTI TC ) members have recently approved STIX 2.0 as a Committee Specification Draft (CSD) and submitted it for 30-day public review. The public review started 08 March 2017 at 00:00 UTC and ends 06 April 2017 at 23:59 UTC. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. What is STIX? Structured Threat Information Expression (STIX) is a language and serialization format used to exchange cyber threat intelligence (CTI). STIX enables organizations to share CTI with one another in a consistent and machine readable manner, allowing security communities to better understand what computer-based attacks they are most likely to see and to anticipate and/or respond to those attacks faster and more effectively. STIX is designed to improve many different capabilities, such as collaborative threat analysis, automated threat exchange, automated detection and response, and more. More information can be found here . What's New in STIX 2.0? STIX 2.0 represents a significant evolution in the design and implementation of STIX. To date, STIX has been very successful in demonstrating that machine-readable cyber threat intelligence can be widely shared and used operationally. Both commercial and government threat intelligence feeds provide it and many threat intelligence tools produce and/or consume it. As with anything, however, in developing and implementing STIX 1.x the community (both vendors and consumers) have found that it also had some shortcomings. These included excessive complexity and excessive flexibility. In addition, STIX 1.x used XML, which has fallen out of favor with much of the developer community. STIX 2 is a redesign of STIX that has the same goals and builds on the same foundational concepts but in a way that addresses those shortcomings. It is not backwards-compatible but is intended to be a replacement for STIX 1.x. STIX 2.0 is the first release of STIX 2 and is intended to be a framework on which future capabilities can be built. In fact, while STIX 2.0 is currently under review, the community is already working on additional capabilities to add in STIX 2.1. All of the releases in the STIX 2 series will build on each other such that upgrading from one version to the next should be easy (unlike the change from STIX 1 to STIX 2). For more information, consult the FAQ . STIX 2.0 Documents STIX Version 2.0 is a five-part specification. The prose documents and related files are available here: Part # Title Links 1 STIX Core Concepts Editable Authoritative Source (DOCX) HTML PDF 2 STIX Objects Editable Authoritative Source (DOCX) HTML PDF 3 Cyber Observable Core Concepts Editable Authoritative Source (DOCX) HTML PDF 4 Cyber Observable Objects Editable Authoritative Source (DOCX) HTML PDF 5 STIX Patterning Editable Authoritative Source (DOCX) HTML PDF For your convenience, OASIS also provides a complete package of the prose documents and related files in a ZIP distribution file. You can download the ZIP file here . How To Comment on STIX 2.0 Comments on STIX 2.0 may be submitted to the TC by any person through the use of the OASIS TC Comment Facility . Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed here . Please submit any comments before the public comment period ends on April 6, 2017. By submitting comments you implicitly agree to the terms of the OASIS Feedback License , which ensures that any alterations made to the specifications based upon your feedback are covered by the same IPR protections under which TC members operate. In addition, in connection with this public review of STIX 2.0, we call your attention to the OASIS IPR Policy applicable to the work of this technical committee. While all members of the TC should already be familiar with this document (which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification), public reviewers who are not TC members are encouraged to review the OASIS IPR Policy. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. Invitation to Forward This Call for Comments OASIS and the CTI TC encourage widespread public review of the STIX 2.0 specifications. Therefore, please feel free to forward this call for comments onto any and all interested parties. Thank you. Regards, Richard J. Struse Chair, OASIS Cyber Threat Intelligence (CTI) Technical Committee Chief Advanced Technology Officer National Cybersecurity and Communications Integration Center (NCCIC) Cyber Security & Communications U.S. Department of Homeland Security e-mail: Richard.Struse@dhs.gov Phone: 202-527-2361 ------=_NextPart_001_01B4_01D29E3F.3EDC9F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Cybersecurity Community Member,

 

The OASIS = Cyber Threat Intelligence Technical Committee (CTI TC) members = have recently approved STIX 2.0 as a Committee Specification Draft (CSD) = and submitted it for 30-day public review.  The public review = started 08 March 2017 at 00:00 UTC and ends = 06 April 2017 at 23:59 UTC. 

 

This is an = open invitation to comment. OASIS solicits feedback from = potential users, developers and others, whether OASIS members or not, = for the sake of improving the interoperability and quality of its = technical work.

 

What is = STIX?

Structured Threat = Information Expression (STIX) is a language and serialization format = used to exchange cyber threat intelligence (CTI). STIX enables = organizations to share CTI with one another in a consistent and machine = readable manner, allowing security communities to better understand what = computer-based attacks they are most likely to see and to anticipate = and/or respond to those attacks faster and more effectively. STIX is = designed to improve many different capabilities, such as collaborative = threat analysis, automated threat exchange, automated detection and = response, and more.  More information can be found here.

 

What’s New in STIX = 2.0?

STIX 2.0 represents a = significant evolution in the design and implementation of STIX.  To = date, STIX has been very successful in demonstrating that = machine-readable cyber threat intelligence can be widely shared and used = operationally. Both commercial and government threat intelligence feeds = provide it and many threat intelligence tools produce and/or consume = it.  As with anything, however, in developing and implementing STIX = 1.x the community (both vendors and consumers) have found that it also = had some shortcomings. These included excessive complexity and excessive = flexibility. In addition, STIX 1.x used XML, which has fallen out of = favor with much of the developer community.

 

STIX 2 is a = redesign of STIX that has the same goals and builds on the same = foundational concepts but in a way that addresses those shortcomings. It = is not backwards-compatible but is intended to be a replacement for STIX = 1.x.  STIX 2.0 is the first release of STIX 2 and is intended to be = a framework on which future capabilities can be built. In fact, while = STIX 2.0 is currently under review, the community is already working on = additional capabilities to add in STIX 2.1. All of the releases in the = STIX 2 series will build on each other such that upgrading from one = version to the next should be easy (unlike the change from STIX 1 to = STIX 2).  For more information, consult the FAQ.

 

STIX 2.0 = Documents

STIX Version 2.0 = is a five-part specification. The prose documents and related files are = available here:

 

<= /tr>

Part #

Title

Links

1

STIX Core = Concepts

Editable Authoritative Source = (DOCX)

HTML

PDF

2

STIX Objects

Editable Authoritative = Source (DOCX)

HTML

PDF

3

Cyber Observable Core = Concepts

Editable = Authoritative Source (DOCX)

HTML<= o:p>

PDF

4

Cyber Observable = Objects

Edi= table Authoritative Source (DOCX)

HTM= L

PDF<= /a>

5

STIX Patterning

Editable = Authoritative Source (DOCX)

HTML

PDF

=

 

For your convenience, OASIS also provides a complete = package of the prose documents and related files in a ZIP distribution = file. You can download the ZIP file here.

 

How To Comment on STIX = 2.0

Comments on STIX 2.0 = may be submitted to the TC by any person through the use = of the OASIS TC Comment Facility.  Comments submitted by TC = non-members for this work and for other work of this TC are publicly = archived and can be viewed here.&nbs= p; Please submit any comments before the public comment period ends = on April 6, 2017.

 

By = submitting comments you implicitly agree to the terms of the OAS= IS Feedback License, which ensures that any alterations made to the = specifications based upon your feedback are covered by the same IPR = protections under which TC members operate.  In addition, in = connection with this public review of STIX 2.0, we call your attention = to the OASIS IPR Policy applicable to the work of this technical = committee. While all members of the TC should already be familiar with = this document (which may create obligations regarding the disclosure and = availability of a member's patent, copyright, trademark and license = rights that read on an approved OASIS specification), public reviewers = who are not TC members are encouraged to review the OASIS IPR = Policy.  OASIS invites any persons who know of any such claims to = disclose these if they may be essential to the implementation of the = above specification, so that notice of them may be posted to the notice = page for this TC's work.

 

Invitation to Forward This = Call for Comments

OASIS = and the CTI TC encourage widespread public review of the STIX 2.0 = specifications.  Therefore, please feel free to forward this call = for comments onto any and all interested = parties.

Thank = you.

 

Regards,

 

Richard = J. Struse 

Chair, OASIS = Cyber Threat Intelligence (CTI) Technical Committee

 

Chief = Advanced Technology Officer

National = Cybersecurity and Communications Integration Center (NCCIC) =

Cyber = Security & Communications

U.S. = Department of Homeland Security


e-mail:  = Richard.Struse@dhs.gov
Phone:  = 202-527-2361

 

 

------=_NextPart_001_01B4_01D29E3F.3EDC9F20-- ------=_NextPart_000_01B3_01D29E3F.3EDC9F20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIX9jCCBGAw ggNIoAMCAQICAgEwMA0GCSqGSIb3DQEBCwUAMFkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDTALBgNVBAsTBEZQS0kxITAfBgNVBAMTGEZlZGVyYWwgQ29tbW9uIFBvbGlj eSBDQTAeFw0xMDEyMDExNjQ1MjdaFw0zMDEyMDExNjQ1MjdaMFkxCzAJBgNVBAYTAlVTMRgwFgYD VQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBEZQS0kxITAfBgNVBAMTGEZlZGVyYWwgQ29t bW9uIFBvbGljeSBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANh1+zUWNFpBv1qv XDAEFByteES16ibqdWHHzTZ5+HzYvSlRZlkh43mr1Hi+sC2wodWyNRYj0Mwevg7oq9zDydYS16dy aBgxuBcisj5+ughtxv3RWCxpoAPwKqP2PyElPd+3MsWOJ7MjpeBSs12W6bC4xcWfu8WgboJAu8Un BTZJ1iYnaQw0j88neioKo0FfjR0DhoMV4FXBxZgsnuwactxIwT75hNKEgsEbw3Q2t7nHNjJ6+DK2 0DauIhgxjFBzIZ7+gzswiCTj6cF+3u2Yxx+SEIqfW2IvnaS81YVvOv3JU6cgS6rbIKshTh0NTuaY heWrEUddnT/EI8DjFAZu/p0CAwEAAaOCATAwggEsMA8GA1UdEwEB/wQFMAMBAf8wgekGCCsGAQUF BwELBIHcMIHZMD8GCCsGAQUFBzAFhjNodHRwOi8vaHR0cC5mcGtpLmdvdi9mY3BjYS9jYUNlcnRz SXNzdWVkQnlmY3BjYS5wN2MwgZUGCCsGAQUFBzAFhoGIbGRhcDovL2xkYXAuZnBraS5nb3YvY249 RmVkZXJhbCUyMENvbW1vbiUyMFBvbGljeSUyMENBLG91PUZQS0ksbz1VLlMuJTIwR292ZXJubWVu dCxjPVVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFyeTAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFK0MenVc5fOYxHmYDqwo/Zf05wL8MA0GCSqGSIb3DQEB CwUAA4IBAQCPc9rhf4Cxh/bsLM/RhGMe9vGIt5ryEbXvVK2Kbhg3KO9cG+TvULdsJhgjIk0dJkcg 6Qmc4nBicasRz5GJ6LP1KqBHwBTLTkLB3QwOG/CHW+zld9eq4FTXRfSFPuy0Hd58in9bTZyWitCi Mp/abDEM+KTvfnPokdwIenBaoK9igVn4AHSiyN1UykFWR73pwE/tIN3jpQnfrijC/NHIF9gSx2/e Lum9mpHyPFqULpEigImhjFjMg3omGXUCpQ59CiZzUeqGyweoyP1jWjWb0q+/TzFIwYRw2zV7mhkP 5Y/0agxvM9nrHHCiDeO5UANhAv9K7JKk3C3uKjSTB7cs5xiPMIIF2zCCBMOgAwIBAgICNm4wDQYJ KoZIhvcNAQELBQAwWTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsG A1UECxMERlBLSTEhMB8GA1UEAxMYRmVkZXJhbCBDb21tb24gUG9saWN5IENBMB4XDTE2MDQxODE1 MTA0MloXDTE5MDQxODE1MDY0N1owgY4xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVy bm1lbnQxIzAhBgNVBAsTGkRlcGFydG1lbnQgb2YgdGhlIFRyZWFzdXJ5MSIwIAYDVQQLExlDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0aWVzMRwwGgYDVQQLExNVUyBUcmVhc3VyeSBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6CQEWcyYx3xksWrXOylIx7tY6t+ixCqT0WjWi4PC KkDmauxuGt/pI+9UYdrlou12AGkE1Uzyv8QbaIVRrgenONkKs1IRNp8igd4ESHe+qK+y8XgurMRY h1CGAgx7N2gInWJNtQm38RZz2wToRumIkyXI2m2jqIwh38bXNlgg2632jBKAIpdY9ONCi33R9H65 f1bvujG8SewSrwiAueKXYmB/74P5Y97rcG6rxE8PNBKmy60mQ8uPA8bzniQeKoOwauYp/1cesW5f T0DVQrWq1bRR5LJ7Wwb8gqLMsRa/PkTHo2S3gvZoctvm/nth2/6udXbM3GxS2bwHqDlm64+aywID AQABo4ICdTCCAnEwDwYDVR0TAQH/BAUwAwEB/zCBswYDVR0gBIGrMIGoMAwGCmCGSAFlAwIBAwEw DAYKYIZIAWUDAgEDAjAMBgpghkgBZQMCAQMGMAwGCmCGSAFlAwIBAwcwDAYKYIZIAWUDAgEDCDAM BgpghkgBZQMCAQMkMAwGCmCGSAFlAwIBAw0wDAYKYIZIAWUDAgEDEDAMBgpghkgBZQMCAQMRMAwG CmCGSAFlAwIBAycwDAYKYIZIAWUDAgEDKDAMBgpghkgBZQMCAQMpME8GCCsGAQUFBwEBBEMwQTA/ BggrBgEFBQcwAoYzaHR0cDovL2h0dHAuZnBraS5nb3YvZmNwY2EvY2FDZXJ0c0lzc3VlZFRvZmNw Y2EucDdjMIGNBgNVHSEEgYUwgYIwGAYKYIZIAWUDAgEDAQYKYIZIAWUDAgEFAjAYBgpghkgBZQMC AQMCBgpghkgBZQMCAQUDMBgGCmCGSAFlAwIBAwYGCmCGSAFlAwIBBQcwGAYKYIZIAWUDAgEDBwYK YIZIAWUDAgEFBDAYBgpghkgBZQMCAQMQBgpghkgBZQMCAQUFMEAGCCsGAQUFBwELBDQwMjAwBggr BgEFBQcwBYYkaHR0cDovL3BraS50cmVhc3VyeS5nb3Yvcm9vdF9zaWEucDdjMA4GA1UdDwEB/wQE AwIBBjAfBgNVHSMEGDAWgBStDHp1XOXzmMR5mA6sKP2X9OcC/DA1BgNVHR8ELjAsMCqgKKAmhiRo dHRwOi8vaHR0cC5mcGtpLmdvdi9mY3BjYS9mY3BjYS5jcmwwHQYDVR0OBBYEFGiEFUiMVHB/LRJY DuwceO88LllkMA0GCSqGSIb3DQEBCwUAA4IBAQCsE7pwaCpISt8zUAUCjefyt81PrIGLTl3RmIQK BCVwfGiqUksRrHU7GAo+oabc6vbc4InAZGpvlQ4uCpBEdQ5mkzgTeawzzyj0lZZ5c/I0wsJVXYzu 5RjEJS0WtlT2jtQhUnpgmbIa6RQbHJ1VvBnsvD2isr3SUajJBPqt8fUsSCc69lTTQpCrZJYKqzQS FayPzLdi8GFS4mPEa6R4Zzxu74TODy2Fac/f3OI7g7TvdboB8C7yhEkQlTsvNhXHrf14Kl3lk+VR Y3hvmGqJH/rgBJzmWNhY0sAhenuNLmXN6jXsvBjiX2VarDXMTIAEUFy+mTwijMzsaXFQJVJxggLH MIIGDTCCBPWgAwIBAgIETjmBKDANBgkqhkiG9w0BAQsFADCBjjELMAkGA1UEBhMCVVMxGDAWBgNV BAoTD1UuUy4gR292ZXJubWVudDEjMCEGA1UECxMaRGVwYXJ0bWVudCBvZiB0aGUgVHJlYXN1cnkx IjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxHDAaBgNVBAsTE1VTIFRyZWFzdXJ5 IFJvb3QgQ0EwHhcNMTUwNjEzMTQzNTA0WhcNMjUwNjEzMTUwNTA0WjCBhzELMAkGA1UEBhMCVVMx GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEoMCYGA1UECxMfRGVwYXJ0bWVudCBvZiBIb21lbGFu ZCBTZWN1cml0eTEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEQMA4GA1UECxMH REhTIENBNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ6z5QKA2hjOSvwVu0SWd/TJ sJv2Xd2WN7yTo9OCSPiQ+U89oAE8xlIpo+97mMK3DjwU4GdeMP0cdpKarcL7BBSPCK2j1f3o5PNi YU6RDJBR6pgfuvE6LJDAmpKZGcJITnLjui25aMAy6dlNX0aNFu2JApB9yDE9VrIODNhZsD6LG4iC a1mATxtGQfIqfZhT/aSNnfcbzIddZYvhQlYMF53S9+oAJv21XyHLHO91PW75UteWVxWZvxLfQZmk wzeAxJI37YnpRrHGvtjjeRVgtUKi3wj3CpvRSVLMy05CAKlgsG56vvG3lgkeIoJrwiBV+sY4G3ao T7+efJgRnJpxCYcCAwEAAaOCAnYwggJyMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGXBgNVHSAEgY8wgYwwDAYKYIZIAWUDAgEDBjAMBgpghkgBZQMCAQMHMAwGCmCGSAFlAwIBAwgw DAYKYIZIAWUDAgEDDTAMBgpghkgBZQMCAQMQMAwGCmCGSAFlAwIBAxEwDAYKYIZIAWUDAgEDJDAM BgpghkgBZQMCAQMnMAwGCmCGSAFlAwIBAygwDAYKYIZIAWUDAgEDKTBBBggrBgEFBQcBAQQ1MDMw MQYIKwYBBQUHMAKGJWh0dHA6Ly9wa2kudHJlYXN1cnkuZ292L2Roc2NhX2FpYS5wN2MwQQYIKwYB BQUHAQsENTAzMDEGCCsGAQUFBzAFhiVodHRwOi8vcGtpLnRyZWFzdXJ5Lmdvdi9kaHNjYV9zaWEu cDdjMIHuBgNVHR8EgeYwgeMwNaAzoDGGL2h0dHA6Ly9wa2kudHJlYXN1cnkuZ292L1VTX1RyZWFz dXJ5X1Jvb3RfQ0EuY3JsMIGpoIGmoIGjpIGgMIGdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MSMwIQYDVQQLExpEZXBhcnRtZW50IG9mIHRoZSBUcmVhc3VyeTEiMCAGA1UE CxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEcMBoGA1UECxMTVVMgVHJlYXN1cnkgUm9vdCBD QTENMAsGA1UEAxMEQ1JMMTAfBgNVHSMEGDAWgBRohBVIjFRwfy0SWA7sHHjvPC5ZZDAdBgNVHQ4E FgQUfMNKXLofNquDUX304OUOkH8cE0EwDQYJKoZIhvcNAQELBQADggEBAFOQwIQWhIzLNbzkya8Z +U7BoFSrsg+aVXT4StNJjdWPCZO5fP6KU9OW2gcHAz/GylC65JrbFM6Wo7Zn+rrTrZZvDnd7uyja feUDnnI4VwPwYrPUQllyru7YC9aZjp6fMm8S+MUN69Dpb7NMFHt2876CYRco+q0t/ESN1T+YLrqG AhPjwz1+opTyrhY3NSBRtJ8xUzNIcDP34r9td0SXtiidmxX/dDLiGi0YvzD90sSWNAKOANl3MyhI PerCuADFqpALUkkY5zTa+ZlPHDf/4pfedZN4cJDpv9X49/RterYIj0cGw8UyWFaObSAOVEBrYe+T z+l0RQ3GVQ8mhpBK2YIwggeeMIIGhqADAgECAgRXJqwQMA0GCSqGSIb3DQEBCwUAMIGHMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MSgwJgYDVQQLEx9EZXBhcnRtZW50IG9m IEhvbWVsYW5kIFNlY3VyaXR5MSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzMRAw DgYDVQQLEwdESFMgQ0E0MB4XDTE2MDUyNDE3MzkzMVoXDTE5MDUyMzA0MDAwMFowga8xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxKDAmBgNVBAsTH0RlcGFydG1lbnQgb2Yg SG9tZWxhbmQgU2VjdXJpdHkxDzANBgNVBAsTBkRIUyBIUTEPMA0GA1UECxMGUGVvcGxlMTowFwYD VQQDExBSSUNIQVJEIEogU1RSVVNFMB8GCgmSJomT8ixkAQETETAyMjczMTQ4NDQuREhTIEhRMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzi/wOfzuSkqwBvhkh/ZBaVQx+qVgiae7huck KM+NMLpsf9xx3CJvNpHZkoQh2DpAwDC8yc8FKynmIhv4j+bozuSmTApPyNdmIaenGiOOUsHu3VOm yok2TxoRhyBOq7jy52rZNVQ0NqqCvBY2G1g9nJhI80dJeadtxSnFW//kyFNoRni47FglGN0lT0Xr KmsozWEcF9StdLlJWSHFTLN2QdgsaFPt0TqF19okkrbLARc8RpIoy58qMcHwQ8tIsrKPYJ/JSH5U oQkBVSjv184QxwmEuyW/RSLBd5ZziG1IC3KxSjSuTtjzvn5ggcAHRa9mnBTAjA342bkkqfLD6Sv+ kQIDAQABo4ID5jCCA+IwDgYDVR0PAQH/BAQDAgeAMBcGA1UdIAQQMA4wDAYKYIZIAWUDAgEDDTAl BgNVHSUEHjAcBgorBgEEAYI3FAICBggrBgEFBQcDAgYEVR0lADAQBglghkgBZQMGCQEEAwEB/zCC ARsGCCsGAQUFBwEBBIIBDTCCAQkwNAYIKwYBBQUHMAKGKGh0dHA6Ly9wa2kuZGltYy5kaHMuZ292 L2Roc2NhX2VlX2FpYS5wN2MwgaoGCCsGAQUFBzAChoGdbGRhcDovL2xkYXAwMS5kaW1jLmRocy5n b3Yvb3U9REhTJTIwQ0E0LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvdT1EZXBhcnRt ZW50JTIwb2YlMjBIb21lbGFuZCUyMFNlY3VyaXR5LG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9j QUNlcnRpZmljYXRlO2JpbmFyeTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGltYy5kaHMuZ292 MG0GA1UdEQRmMGSBEjAyMjczMTQ4NDRAZGhzLmdvdqAlBgorBgEEAYI3FAIDoBcMFTAyMjczMTQ4 NDRASFEuREhTLkdPVqAnBghghkgBZQMGBqAbBBnXAhDYIQwtMgW5DYNoWChHMwIIhIcCEMPiMIIB kwYDVR0fBIIBijCCAYYwggFXoIIBU6CCAU+kgZwwgZkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9V LlMuIEdvdmVybm1lbnQxKDAmBgNVBAsTH0RlcGFydG1lbnQgb2YgSG9tZWxhbmQgU2VjdXJpdHkx IjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxEDAOBgNVBAsTB0RIUyBDQTQxEDAO BgNVBAMTB0NSTDQxNDWGga1sZGFwOi8vbGRhcDAxLmRpbWMuZGhzLmdvdi9jbj1DUkw0MTQ1LG91 PURIUyUyMENBNCxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsb3U9RGVwYXJ0bWVudCUy MG9mJTIwSG9tZWxhbmQlMjBTZWN1cml0eSxvPVUuUy4lMjBHb3Zlcm5tZW50LGM9VVM/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdDApoCegJYYjaHR0cDovL3BraS5kaW1jLmRocy5nb3YvREhTX0NB Mi5jcmwwHwYDVR0jBBgwFoAUfMNKXLofNquDUX304OUOkH8cE0EwHQYDVR0OBBYEFHRjSQMozkn0 cRQkVWeiycDcRh4yMBkGCSqGSIb2fQdBAAQMMAobBFY4LjEDAgQwMA0GCSqGSIb3DQEBCwUAA4IB AQBvuwLTyECvhvh6YQvlIsKNJ3Rq66c5rSc68cdhY2yrb/g2ovXRBnE9U6zVLcwzxVChMG8IXTZ1 tv/mF4zntHFvGbpFeMbsOM2HtKs650vfSQseWn721OGNlBy7Bb/qEgwH1lM7Qzg1uQ+QRvblBV6F X6l1J8OWt3xwgEcZsH6ngr5kXTAUNtVCZiPSnwLHE01HyVXI/7wFEzoaxJJWd0ZrvlN0DfwDwV0A UFGpUBdk8t0tFcQUx4+9KJqS/draBm5xJhE1xwU5BOk8LIUIHWFuiQT8nSroYOi75ih8cnSciy63 HIuR30UK2TMgttZCMwNiRBUtzxhS7jUubDsnMNfQMYICMTCCAi0CAQEwgZAwgYcxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxKDAmBgNVBAsTH0RlcGFydG1lbnQgb2YgSG9t ZWxhbmQgU2VjdXJpdHkxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxEDAOBgNV BAsTB0RIUyBDQTQCBFcmrBAwCQYFKw4DAhoFAKB3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw GAYJKoZIhvcNAQkPMQswCTAHBgUrDgMCGjAcBgkqhkiG9w0BCQUxDxcNMTcwMzE2MTQyMjQyWjAj BgkqhkiG9w0BCQQxFgQUQjFItggAQYrj8QTRJzlCgyB2m7IwDQYJKoZIhvcNAQEBBQAEggEAUkqI 7UYN/FThV/arRDHJwcArlHErPye/1tZjqyRiuG1s1nnBej8C7lID1t+I/7HE/yVtgPM9TIND2GZ4 7hUvHUkg+vOm02fr68oAwb3WyQT4sC2cJDMKLehi55Wt7FFkIJmykMuB2NGm1ZYRnKUILGs0jlJL EYJ0B2Zwg8TxaR+zCEv/eJbiemneFjJNT//He1QNO+qdMgSS4G/gDk6bSMJGvQZq1Ntn+62zEMQh b8n+yUWAv+hBbmk7xMLXqGnsIButx3IKKqT6rpBKZLBW9OMd/kO/+lupz5Fef7327Vh2aWYq99Ld mIg/Ty6VkfxsnjKcAWchco0CBaif0bhLcQAAAAAAAA== ------=_NextPart_000_01B3_01D29E3F.3EDC9F20-- From nobody Thu Mar 16 11:25:10 2017 Return-Path: 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 978781296DA for ; Thu, 16 Mar 2017 11:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 7icMOWQfVkNT for ; Thu, 16 Mar 2017 11:25:06 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id B57A7129876 for ; Thu, 16 Mar 2017 11:25:06 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DD1E37BC03A for ; Thu, 16 Mar 2017 14:25:06 -0400 (EDT) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id CBEB17BC015 for ; Thu, 16 Mar 2017 14:25:06 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Mar 2017 14:25:05 -0400 Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 16 Mar 2017 14:25:04 -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=vCEERbNZWQCrKDiPoHw0I2Rpsfqf5IKnsvSldRAm3nI=; b=RQMAreRETFUrne3HWSddz5+t2A6HXyMlpwARfO75cwjpttIB0gesg9oCAPMlmMeH5w33Od8qW0DBUrWsgKtEMsvBbMhrzhlclebdMIqHWYZVWCvA3zISiuiMsjDBBc4yeWGM8eWFh5/T5J2psDBYE9No9ZeUZ31KO4FjgXDTWU8= Received: from CY1PR09MB0889.namprd09.prod.outlook.com (10.163.43.27) by CY1PR09MB0889.namprd09.prod.outlook.com (10.163.43.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 16 Mar 2017 18:25:03 +0000 Received: from CY1PR09MB0889.namprd09.prod.outlook.com ([10.163.43.27]) by CY1PR09MB0889.namprd09.prod.outlook.com ([10.163.43.27]) with mapi id 15.01.0977.010; Thu, 16 Mar 2017 18:25:03 +0000 From: "Schmidt, Charles M." To: "" Thread-Topic: New version of SWIMA - draft-ietf-sacm-nea-swid-patnc-01 Thread-Index: AdKefvOAYUEWADRFSAe7NaK6QOb5cA== Date: Thu, 16 Mar 2017 18:25:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.160.51.87] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0889; 7:a7Rwo/PKSNUMuKZ3VUeiNICDpujs0PJv0/Lxka+nzpIUOXt1jODLReWzo7gZNiGrSuHXRWet3U1syYIWVKSsyUZuDVpnmHXiSLQzrSB2QkOT77CPSgnz/105PURjhAkrmSwg+fjoWm761jPZETUt0FYlP/OF6OeEtvHrqgnpn8If65+lw1Qk0aTWK5eIM4sTaw/hli06uNyXpznFD0VXUzcsmng9ZVsm4bFMO4HFPpvpZ2U25uMN+HVWJsLkVhA5kmYt8mm1IxUuLSiyFRUYzQIk+DAsUPtRbOibWe5fDiwYx5SpLWABE+x5EZWFMZG1tXg/HDOs76lEuFC94F21/Q== x-ms-office365-filtering-correlation-id: 3742a9e8-feca-4800-bd2a-08d46c99c3eb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR09MB0889; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR09MB0889; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0889; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39840400002)(39450400003)(53754006)(74316002)(5660300001)(25786008)(6306002)(7696004)(81166006)(122556002)(102836003)(2900100001)(189998001)(6436002)(77096006)(2906002)(99286003)(6506006)(55016002)(86362001)(6116002)(50986999)(53936002)(230783001)(8676002)(3280700002)(110136004)(33656002)(8936002)(38730400002)(54356999)(9686003)(66066001)(7736002)(305945005)(3660700001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0889; H:CY1PR09MB0889.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 18:25:03.7635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0889 X-OriginatorOrg: mitre.org Archived-At: Subject: [sacm] New version of SWIMA - draft-ietf-sacm-nea-swid-patnc-01 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:25:10 -0000 Hi all, A new version of SWIMA has been uploaded to the IETF document repository (h= ttps://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swid-patnc/) and to the= GitHub repo (https://github.com/sacmwg/software-identification). This new = draft includes some rearrangement to make it easier to read and a bit short= er (thanks Dave Waltermire). I believe this version now addresses all issue= s currently listed in GitHub. The biggest change between the -00 and -01 versions is in the source identi= fication mechanisms. The Source First Use flag was removed from all message= s per the suggestions at the virtual interim call. I have also added two ne= w attributes: Source Metadata Request and Source Metadata Response. These a= re used to convey information about the various sources a SW-PC uses. These= attributes are described in sections 5.14 and 5.15. The section on Source = Identifiers (section 3.4.5) has been expanded to provide more guidance on s= ource handling and tracking. This addresses open issue #1 in GitHub. All of the other issues were addressed in the -00 version. No concerns were= raised about the approaches used there either at the last virtual interim = call or in response to request for feedback on the mailing list. For simpli= city, I'm adding the list of issues addressed in the -00 version along with= how they were addressed and where. Issue #3: Include installation location - Section 3.4.4 describes how softw= are location information is captured when reporting records, and all attrib= utes that deliver records have new fields used to indicate the software loc= ation. Issue #4: Support of user/vendor-defined data models - The data model is in= dicated with a combination of PEN and data model type identifier. Each vend= or can use their PEN to define their own namespace of data model type ident= ifier values. The spec also reserves all values greater than or equal to 19= 2 in the IANA PEN (0) as definable by the local enterprise. Section 3.2 dis= cusses data models in more detail, section 3.4.2 describes how data model i= nformation is captured in records, and all attributes conveying software da= ta records have fields to capture this. In addition, section 10.4 describes= the IANA registry for Software Data Models. Issue #5: Clarify that SWIMA servers (specifically SW-PVs) MUST accept all = data models - This is included in section 3.2 Issue #6: MTI Data Models - Also addressed in section 3.2. Requirement is t= o support (i.e., be able to generate Software Identifiers for) the formats = specified in section 5 of the spec. Currently, those are SWID 2015 in XML a= nd SWID 2009 in XML. No other formats have been suggested. Please take a look at this new version and send any feedback to the list. Thanks, Charles From nobody Mon Mar 20 06:33:24 2017 Return-Path: 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 D72C61252BA for ; Mon, 20 Mar 2017 06:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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=-0.001] 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 aeHBOGKznGqd for ; Mon, 20 Mar 2017 06:33:22 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9312426E for ; Mon, 20 Mar 2017 06:33:21 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 856296C010B for ; Mon, 20 Mar 2017 09:33:23 -0400 (EDT) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 75C3D6C0108 for ; Mon, 20 Mar 2017 09:33:23 -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.1263.5; Mon, 20 Mar 2017 09:33:20 -0400 Received: from gcc01-CY1-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.1263.5 via Frontend Transport; Mon, 20 Mar 2017 09:33:20 -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=ojjRJQANuDBwzxuIE+KTGeZc+GLoObtNIHrO0dXB0L0=; b=KHGEfVIFzvc0FlBkl9/5OjfuSnVWd/MXExYD+f5jxosdbJ/E7vyqKFXY+VsuEF+1w41hz2I/z8h2IL24TmWMxvrGcQb1W7PL9jAgh01HhXmzfnYNjOxymyFSfC2U1XDMpzrKGmYbFoF/HNP4Qfugryiz3bG9VcssQkVNh89aj5U= Received: from DM5PR09MB1354.namprd09.prod.outlook.com (10.172.38.135) by DM5PR09MB1353.namprd09.prod.outlook.com (10.172.38.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Mon, 20 Mar 2017 13:33:19 +0000 Received: from DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) by DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) with mapi id 15.01.0977.019; Mon, 20 Mar 2017 13:33:19 +0000 From: "Haynes, Dan" To: "sacm@ietf.org" Thread-Topic: SACM Vulnerability Assessment Scenario Now on the SACM Wiki Thread-Index: AdKhfe+E9JPk3QtrR2CtShEe3K6fiw== Date: Mon, 20 Mar 2017 13:33:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.160.51.87] x-microsoft-exchange-diagnostics: 1; DM5PR09MB1353; 7:IjZrlFcQUjYHJD/QkC8ktPeAeFd+jL6BirL280D9BRQtjWJ7UOXbqqzcJKAE0EGJtLeYA4/n8YObZVvkuLf3QOs3loGHEpgmXrwuvoiyMfBvd6+bWy0e6W0XmK4sLwjFRfzNTfxsdso/d/7C6ZjsL/nUCjTwjwMgxDVXO+wfQ6OOxY1GnUdzd7DyM1zxqlmWplL0YkFt4KA8OeYx+OmlATnPPhuukWAZRrDkq6LAIOtIpASQS4TsXVvV2yVHx/WE64TKNoHXp/SYMwucTWFpXQYJ2ovp1klZR6ydhpDJSO4TEN35wVk4mns9TIKSreHl/zdisr0dmsy3SyGfX746cA== x-ms-office365-filtering-correlation-id: 95290d7f-2818-4d08-73fe-08d46f95ac47 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM5PR09MB1353; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:DM5PR09MB1353; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1353; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(53754006)(51694002)(25786008)(74316002)(7696004)(50986999)(77096006)(54356999)(9326002)(2351001)(606005)(6436002)(7736002)(122556002)(2501003)(7906003)(53936002)(6916009)(2900100001)(110136004)(38730400002)(5660300001)(3660700001)(54896002)(5640700003)(2906002)(8936002)(66066001)(189998001)(236005)(3280700002)(33656002)(86362001)(8676002)(55016002)(5630700001)(99286003)(6506006)(790700001)(1730700003)(81166006)(6116002)(102836003)(3846002)(6306002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR09MB1353; H:DM5PR09MB1354.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR09MB1354059C5097963AB66DD68DA53A0DM5PR09MB1354namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 13:33:19.5975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1353 X-OriginatorOrg: mitre.org Archived-At: Subject: [sacm] SACM Vulnerability Assessment Scenario Now on the SACM Wiki X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 13:33:24 -0000 --_000_DM5PR09MB1354059C5097963AB66DD68DA53A0DM5PR09MB1354namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, I just wanted to let you know that the SACM Vulnerability Assessment Scenar= io is now up on the SACM wiki. It can be found at the following link. https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario There is also a link to the SACM Vulnerability Assessment Scenario from the= main IETF wiki page which can be found at the following link. https://trac.ietf.org/trac/sacm/wiki/WikiStart Let me know if you have any questions, find anything that needs to be fixed= , or have any other feedback. Thanks, Danny --_000_DM5PR09MB1354059C5097963AB66DD68DA53A0DM5PR09MB1354namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Everyone,

I just wanted to let you know that the SACM Vulnerability Assessment Scenar= io is now up on the SACM wiki. It can be found at the following link.<= /o:p>

 

https://trac.ietf.org/trac/sacm/wiki/SacmV= ulnerabilityAssessmentScenario

 

There is also a link to the SACM Vulnerability Asses= sment Scenario from the main IETF wiki page which can be found at the follo= wing link.

 

https://trac.ietf.org/trac/sacm/wiki/WikiStart

 

Let me know if you have any questions, find anything= that needs to be fixed, or have any other feedback.

 

Thanks,

Danny

 

--_000_DM5PR09MB1354059C5097963AB66DD68DA53A0DM5PR09MB1354namp_-- From nobody Thu Mar 23 12:13:03 2017 Return-Path: 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 B11C8129BF2 for ; Thu, 23 Mar 2017 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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=-0.001, URIBL_BLOCKED=0.001] 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 fSWnBNF_T5wS for ; Thu, 23 Mar 2017 12:12:59 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 1E187129BEF for ; Thu, 23 Mar 2017 12:12:59 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AD40073C018 for ; Thu, 23 Mar 2017 15:13:01 -0400 (EDT) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 9E7716C4045 for ; Thu, 23 Mar 2017 15:13:01 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Mar 2017 15:12:58 -0400 Received: from gcc01-CY1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 23 Mar 2017 15:12:58 -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=8UHesREZxV6sPEl5Qb68qhxP9cpeg/aMsQEhhuIhoIE=; b=SD9eHE10XMUFgIYiRHG0PZVZJsSKsQ/OIXRm59GoCJe3BewAePx6IdG6Y56Uv1hjEncYLxreuxTvSaoYETPvo3H7hkDbVtTsMrcWBPIfBfZpWRNADBZfwvlDDcFObAA7dpgZRuNQ4C1sBSLu+mi+o1qfLyfa2wnrVAc0/L1r9IY= Received: from DM5PR09MB1354.namprd09.prod.outlook.com (10.172.38.135) by DM5PR09MB1356.namprd09.prod.outlook.com (10.172.39.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 23 Mar 2017 19:12:56 +0000 Received: from DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) by DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) with mapi id 15.01.0991.013; Thu, 23 Mar 2017 19:12:56 +0000 From: "Haynes, Dan" To: "sacm@ietf.org" Thread-Topic: IETF 98: SACM Vulnerability Assessment Scenario Follow-Up Work Thread-Index: AdKeofZI18TKbnbeRK6hM5c/aW5Lhw== Date: Thu, 23 Mar 2017 19:12:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.160.51.87] x-microsoft-exchange-diagnostics: 1; DM5PR09MB1356; 7:ov/SSn4mgrKbF43cky44kIWAep9TNM1FRGX+ljsDpp/rSqaKx8JYOo7lPtKRD4vF8HTesYtwu83vmSl7eLq4laRHqRvUOmM0+MMcUROUvUoI7w9WiCUBtmdjeR4lhPIkE61P/396cedTa5cCRAgHHMxlsccwrzBMVJooAyMANIkRyDmguVveFg9fojZx+A817Iew39HsRv5Vd6T8M3/Qro1d2zH/vRzJvPG9dvFaJA6AWNXeTXJWLHjiws666AkDbMmY+N7hkIIbj3FXNadg4yS68z+65YkEYfg6rqu9Ap1eVlyEsPSvfjV1MwfBJRalVR0HryB0njux/YhOP+5cYA== x-ms-office365-filtering-correlation-id: 030b4cf6-700d-4562-990c-08d472209d14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM5PR09MB1356; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:DM5PR09MB1356; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1356; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(53754006)(50986999)(54356999)(97736004)(2900100001)(2906002)(6916009)(66066001)(2501003)(5630700001)(9326002)(6306002)(8936002)(122556002)(81166006)(9686003)(54896002)(99286003)(6506006)(2351001)(6436002)(1730700003)(77096006)(55016002)(6116002)(53936002)(8676002)(790700001)(3846002)(74316002)(5640700003)(7696004)(86362001)(7736002)(3660700001)(189998001)(5660300001)(33656002)(38730400002)(110136004)(3280700002)(25786009)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR09MB1356; H:DM5PR09MB1354.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR09MB1354008850F09E8D768C3C91A53F0DM5PR09MB1354namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 19:12:56.3833 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1356 X-OriginatorOrg: mitre.org Archived-At: Subject: [sacm] IETF 98: SACM Vulnerability Assessment Scenario Follow-Up Work X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:13:02 -0000 --_000_DM5PR09MB1354008850F09E8D768C3C91A53F0DM5PR09MB1354namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, During the Vulnerability Assessment Scenario session at IETF 98, we would l= ike to work towards the following. * Reaching consensus on the components necessary for a single flow t= hrough the Vulnerability Assessment Scenario * Reaching consensus on the interactions between components * Reaching consensus on a diagram that shows the components and thei= r interactions with each other * Reaching consensus on the different tasks and identify where they = occur in the diagram * Enumerating the IEs necessary for the interactions between compone= nts Since IETF 97, we have had a virtual interim meeting [1][2] and two follow-= up calls [3][4] as well as some discussion on the mailing lists [5][6]. Als= o, the SACM Vulnerability Assessment Scenario has been moved to the SACM wi= ki [7][8]. Please let me know if you have any questions or if there is anything else y= ou would like to add to the discussion since we have 90+ minutes according = to the agenda :). Thanks, Danny [1] https://www.ietf.org/proceedings/interim-2017-sacm-01/slides/slides-int= erim-2017-sacm-01-sessa-vulnerability-assessment-scenario-00.pdf [2] https://www.ietf.org/proceedings/interim-2017-sacm-01/minutes/minutes-i= nterim-2017-sacm-01-201701111000-00 [3] https://www.ietf.org/mail-archive/web/sacm/current/msg04631.html [4] https://www.ietf.org/mail-archive/web/sacm/current/msg04637.html [5] https://www.ietf.org/mail-archive/web/sacm/current/msg04630.html [6] https://www.ietf.org/mail-archive/web/sacm/current/msg04650.html [7] https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenari= o [8] https://www.ietf.org/mail-archive/web/sacm/current/msg04697.html --_000_DM5PR09MB1354008850F09E8D768C3C91A53F0DM5PR09MB1354namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Everyone,


During the Vulnerability Assessment Scenario session at IETF 98, we would l= ike to work towards the following.

 

·        Reaching consensus on the components necessa= ry for a single flow through the Vulnerability Assessment Scenario

·        Reaching consensus on the interactions betwe= en components

·        Reaching consensus on a diagram that shows t= he components and their interactions with each other

·        Reaching consensus on the different tasks an= d identify where they occur in the diagram

·        Enumerating the IEs necessary for the intera= ctions between components

 

Since IETF 97, we have had a virtual interim meeting= [1][2] and two follow-up calls [3][4] as well as some discussion on the ma= iling lists [5][6]. Also, the SACM Vulnerability Assessment Scenario has be= en moved to the SACM wiki [7][8].

 

Please let me know if you have any questions or if t= here is anything else you would like to add to the discussion since we have= 90+ minutes according to the agenda :).

 

Thanks,


Danny

 

[1] https://www.ietf.org/proceedings/interim-2017-sa= cm-01/slides/slides-interim-2017-sacm-01-sessa-vulnerability-assessment-sce= nario-00.pdf

[2] https://www.ietf.org/proceedings/interim-2017-sa= cm-01/minutes/minutes-interim-2017-sacm-01-201701111000-00

[3] https://www.ietf.org/mail-archive/web/sacm/curre= nt/msg04631.html

[4] https://www.ietf.org/mail-archive/web/sacm/curre= nt/msg04637.html

[5] https://www.ietf.org/mail-archive/web/sacm/curre= nt/msg04630.html

[6] https://www.ietf.org/mail-archive/web/sacm/curre= nt/msg04650.html

[7] https://trac.ietf.org/trac/sacm/wiki/SacmVulnera= bilityAssessmentScenario

[8] https://www.ietf.org/mail-archive/web/sacm/curre= nt/msg04697.html

 

--_000_DM5PR09MB1354008850F09E8D768C3C91A53F0DM5PR09MB1354namp_-- From nobody Thu Mar 23 12:37:42 2017 Return-Path: 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 CBEF613163D for ; Thu, 23 Mar 2017 12:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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=-0.001, URIBL_BLOCKED=0.001] 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 BEYpMRz1Dem5 for ; Thu, 23 Mar 2017 12:37:33 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id C949D131643 for ; Thu, 23 Mar 2017 12:37:32 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5E4BDEBC812 for ; Thu, 23 Mar 2017 15:37:35 -0400 (EDT) Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 470D8EBC04C for ; Thu, 23 Mar 2017 15:37:35 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Mar 2017 15:37:31 -0400 Received: from gcc01-CY1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 23 Mar 2017 15:37:31 -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=/8CJBwUKKWfm/0wqFT41BGDNYirnhl+VMV36D8JsMbg=; b=rDlr06b5Wr9+2j96n+9NqiswTRkruw5Hat8CD0Eq04YvqGpQfb7Cf00ajmL7ofuW0P4XIGc/W2A4LUgODL0ST+6XgK1jVlnOihfpbhdZ41+gdPSrmml0+cjFH5RzDM/9ZtL/pVNR/FVke6WEU4DGvuIFFkv1eTnioM8poVwahYc= Received: from DM5PR09MB1354.namprd09.prod.outlook.com (10.172.38.135) by DM5PR09MB1354.namprd09.prod.outlook.com (10.172.38.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 23 Mar 2017 19:37:30 +0000 Received: from DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) by DM5PR09MB1354.namprd09.prod.outlook.com ([10.172.38.135]) with mapi id 15.01.0991.013; Thu, 23 Mar 2017 19:37:30 +0000 From: "Haynes, Dan" To: "sacm@ietf.org" Thread-Topic: SACM Information Model Status Update Thread-Index: AdKkCfeQmIbPlYv0SFqQbcwJGe41CQ== Date: Thu, 23 Mar 2017 19:37:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-originating-ip: [192.160.51.87] x-microsoft-exchange-diagnostics: 1; DM5PR09MB1354; 7:KYGfix/ox0Oq699g1exKzGz3GV2SDLaDe7J1Y5FXnyWz2h2OvrF6pQDd7mE8fWCwES0yfhqg5w89E7QhADhF9PJal3YaTPh+VSVKJ1MnWNaAMRYPUTmbJMinkGRgAoM1lsO6aHPcAYG3IRWIQwHIUv9j2HVEenzTYWcO3niPQwLS4O8xcY+xgyngU8Nlp/AbHZuLT5uvd/Xly1B3v4hRPxI07vDjvSUlCkKjOI8loOzkU3WEm4i2XOiS5QsjC77qjFwz34xgtAMQJMZgigHOSyBihxHwdsHCXtcz3fRImSfs78zn8OqJCBZTmexcBUoiNp/4CJ8Ci3hrmMcMktApBw== x-ms-office365-filtering-correlation-id: 96cffede-9b9a-459b-5df1-08d472240bc1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM5PR09MB1354; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123558025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:DM5PR09MB1354; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1354; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(25584004)(53754006)(51694002)(1730700003)(77096006)(2906002)(6506006)(81166006)(7110500001)(99286003)(5640700003)(6306002)(10710500007)(9326002)(2351001)(33656002)(8676002)(86362001)(53936002)(606005)(3280700002)(2420400007)(189998001)(55016002)(15650500001)(236005)(3660700001)(6436002)(9686003)(50986999)(8936002)(54896002)(54356999)(122556002)(97736004)(790700001)(6116002)(38730400002)(102836003)(3846002)(110136004)(66066001)(74316002)(2900100001)(2501003)(7736002)(5660300001)(7696004)(5630700001)(7906003)(25786009)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR09MB1354; H:DM5PR09MB1354.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR09MB1354038A2EDB35197C139F51A53F0DM5PR09MB1354namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 19:37:30.6072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1354 X-OriginatorOrg: mitre.org Archived-At: Subject: [sacm] SACM Information Model Status Update X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:37:35 -0000 --_000_DM5PR09MB1354038A2EDB35197C139F51A53F0DM5PR09MB1354namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, I just wanted to give a quick status update on the SACM Information Model s= ince we will not be providing an update at IETF 98. We published revision -09 on March 13, 2017. It addressed the following iss= ues. * Added "derived", "authority", and "verified" to the collectionTask= Type IE (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues= /18). * Updated IE examples that use content-type to use statement-type (h= ttps://github.com/sacmwg/draft-ietf-sacm-information-model/issues/56). * Added "networkZoneLocation", "layer2NetworkLocation", and "layer3N= etworkLocation" IEs (https://github.com/sacmwg/draft-ietf-sacm-information-= model/issues/9). * Created a softwareClass attribute IE and added it to the softwareI= nstance subject IE. Also, removed the os* attribute IEs (https://github.co= m/sacmwg/draft-ietf-sacm-information-model/issues/10). There are still some open issues associated with this draft, but, the major= ity do not represent roadblocks and can be added at any time (e.g. new IE a= nd datatype requests, etc.). With that said, there is the open discussion a= round the scope of the IM which has been a roadblock :) and we are trying t= o work through that on the Vulnerability Assessment Scenario front. Please let me know if you have any questions or comments on these changes. Thanks, Danny --_000_DM5PR09MB1354038A2EDB35197C139F51A53F0DM5PR09MB1354namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Everyone,


I just wanted to give a quick status update on the SACM Information Model s= ince we will not be providing an update at IETF 98.

 

We published revision -09 on March 13, 2017. It addr= essed the following issues.

 

=
·        Added "derived", "=
authority", and "verified" to the collectionTaskType IE (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/18).
=
·        Updated IE examples that use cont=
ent-type to use statement-type (https://github.com/sacmwg/draft-ietf=
-sacm-information-model/issues/56).
=
·        Added "networkZoneLocation&q=
uot;, "layer2NetworkLocation", and "layer3NetworkLocation&qu=
ot; IEs (https://github.com/sacmwg/draft-ietf-sacm-information-model/=
issues/9).
=
·        Created a softwareClass attribute=
 IE and added it to the softwareInstance subject IE.  Also, removed th=
e os* attribute IEs (https://github.com/sacmwg/draft-ietf-sacm-infor=
mation-model/issues/10).
 
There are still some open issues associated with this dra=
ft, but, the majority do not represent roadblocks and can be added at any t=
ime (e.g. new IE and datatype requests, etc.). With that said, there is the=
 open discussion around the scope of the IM which has been a roadblock :) a=
nd we are trying to work through that on the Vulnerability Assessment Scena=
rio front.
 
Please let me know if you have any questions or comments =
on these changes.
 
Thanks,

Danny

 

--_000_DM5PR09MB1354038A2EDB35197C139F51A53F0DM5PR09MB1354namp_-- From nobody Fri Mar 24 04:50:17 2017 Return-Path: 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 0A82912965E for ; Fri, 24 Mar 2017 04:50:16 -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 ZvlgSv-apxHq for ; Fri, 24 Mar 2017 04:50:13 -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 7827F12963F for ; Fri, 24 Mar 2017 04:50:13 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w81so5583576oig.1 for ; Fri, 24 Mar 2017 04:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gFKXHFkA3GLagQY4BzQZiLMnrlzDJZNM167M0LXmWaI=; b=H5RQUD9cYHeOn/IWxInes1T19SJ61T/F8e85+9oEFOu0lKK1UYOts65N/bVoZijPFA QXFgFvY2BdhS7CDx+rM2sHtW35UWnfGGMJlBKBuNAE/BV13Ro+wZzhDy6bkxvVZdcHma pJAs/BE68XbZxaLPox19do8FaU3Wad7zp3ZOwcly1GggOHnCdRovwSHsbgz8d4kldBQt WnlGu4Vb5y41kLY1urXEGwwvRBsbmjYzq4KrDHZlcLQSN3GakVankFHDwb0XoBOVRGJG EWVox8Ql6Ly65+Uuqwaw53XC8CilFm/oXHtQ1SNKSpBf7sZ9EZPoHFejXKGQqkFHwT8f 6tgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gFKXHFkA3GLagQY4BzQZiLMnrlzDJZNM167M0LXmWaI=; b=AsNI5HfGxJ59jkwQguOupHy/FY5msRZeCYF69DWXKkBeV4AVQbnzjRFADKcvrNhCjX EzwAaXoI3DzO+SKso/GIyS/n2FuYLtCkKehhDCCn9NSxY+BGkRtVayypmkmkHzY+XlGA Jxc6LJt8ztjFW5VIgW+g9j9VPRmxda/7h8IbG9wXsjxTqyvq7+9JxybCZKKPjdeotIZ1 SYbz0bTb6ykcFw3w29X5Ev4iLm6SG/iM/P/eFNK6od27U1jCfD9heU1+qn14NYX20w5w Ow+qIVcQ0IgW015PcdYUpOKCicrj6D69gjUHRRigfMzW4X/vW1WSayLoUBqv+Ur/Zkpg acnA== X-Gm-Message-State: AFeK/H30HiGKbXSs/+e93FGetxxzQycXW5z+AZg5HdykWkXhIKGd+i7Tx9u5XXOmC5Tgbf+UOOoo5y2QIaQLEA== X-Received: by 10.202.92.11 with SMTP id q11mr4310767oib.51.1490356212518; Fri, 24 Mar 2017 04:50:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adam Montville Date: Fri, 24 Mar 2017 11:50:01 +0000 Message-ID: To: "Haynes, Dan" , "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a113d60eaa2d75d054b7898b1 Archived-At: Subject: Re: [sacm] IETF 98: SACM Vulnerability Assessment Scenario Follow-Up Work X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 11:50:16 -0000 --001a113d60eaa2d75d054b7898b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for sending this out, Danny. Those five bullet points seem big enough to consume an hour and a half. At one point we were going to look at a couple of specific existing CVEs, but I don't think we ever got as far as picking them out... If doing something like that seems like a reasonable idea, we could pick some representative CVEs to walk through the diagram. In that way, we'd have something more concrete to talk about, especially when it comes to enumerating necessary information elements. Thoughts? Adam On Thu, Mar 23, 2017 at 2:13 PM Haynes, Dan wrote: > Hi Everyone, > > > During the Vulnerability Assessment Scenario session at IETF 98, we would > like to work towards the following. > > > > =C2=B7 Reaching consensus on the components necessary for a single= flow > through the Vulnerability Assessment Scenario > > =C2=B7 Reaching consensus on the interactions between components > > =C2=B7 Reaching consensus on a diagram that shows the components a= nd > their interactions with each other > > =C2=B7 Reaching consensus on the different tasks and identify wher= e > they occur in the diagram > > =C2=B7 Enumerating the IEs necessary for the interactions between > components > > > > Since IETF 97, we have had a virtual interim meeting [1][2] and two > follow-up calls [3][4] as well as some discussion on the mailing lists > [5][6]. Also, the SACM Vulnerability Assessment Scenario has been moved t= o > the SACM wiki [7][8]. > > > > Please let me know if you have any questions or if there is anything else > you would like to add to the discussion since we have 90+ minutes accordi= ng > to the agenda :). > > > > Thanks, > > > Danny > > > > [1] > https://www.ietf.org/proceedings/interim-2017-sacm-01/slides/slides-inter= im-2017-sacm-01-sessa-vulnerability-assessment-scenario-00.pdf > > [2] > https://www.ietf.org/proceedings/interim-2017-sacm-01/minutes/minutes-int= erim-2017-sacm-01-201701111000-00 > > [3] https://www.ietf.org/mail-archive/web/sacm/current/msg04631.html > > [4] https://www.ietf.org/mail-archive/web/sacm/current/msg04637.html > > [5] https://www.ietf.org/mail-archive/web/sacm/current/msg04630.html > > [6] https://www.ietf.org/mail-archive/web/sacm/current/msg04650.html > > [7] > https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario > > [8] https://www.ietf.org/mail-archive/web/sacm/current/msg04697.html > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --001a113d60eaa2d75d054b7898b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for sending this out, Danny.=C2=A0 Those five bulle= t points seem big enough to consume an hour and a half.=C2=A0 At one point = we were going to look at a couple of specific existing CVEs, but I don'= t think we ever got as far as picking them out...=C2=A0 If doing something = like that seems like a reasonable idea, we could pick some representative C= VEs to walk through the diagram.=C2=A0 In that way, we'd have something= more concrete to talk about, especially when it comes to enumerating neces= sary information elements.

Thoughts?

Adam

On Thu, Mar 23, 2017 at 2:13 PM Haynes, Dan <dhaynes@mitre.org> wrote:

Hi Everyone,


During the Vulnerability Assessment Scenario session at IETF 98, we would l= ike to work towards the following.

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reaching consensus on the c= omponents necessary for a single flow through the Vulnerability Assessment = Scenario

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reaching consensus on the i= nteractions between components

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reaching consensus on a dia= gram that shows the components and their interactions with each other

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reaching consensus on the d= ifferent tasks and identify where they occur in the diagram

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Enumerating the IEs necessa= ry for the interactions between components

=C2=A0

Since IETF 97, we have had a virtual inter= im meeting [1][2] and two follow-up calls [3][4] as well as some discussion= on the mailing lists [5][6]. Also, the SACM Vulnerability Assessment Scena= rio has been moved to the SACM wiki [7][8].

=C2=A0

Please let me know if you have any questio= ns or if there is anything else you would like to add to the discussion sin= ce we have 90+ minutes according to the agenda :).

=C2=A0

Thanks,


Danny

=C2=A0

[1] ht= tps://www.ietf.org/proceedings/interim-2017-sacm-01/slides/slides-interim-2= 017-sacm-01-sessa-vulnerability-assessment-scenario-00.pdf

[2] https://www.ietf.org/proceeding= s/interim-2017-sacm-01/minutes/minutes-interim-2017-sacm-01-201701111000-00=

[3] https://www.ietf.org/mail-archive/web/sacm/current/msg04631.html

[4] https://www.ietf.org/mail-archive/web/sacm/current/msg04637.html

[5] https://www.ietf.org/mail-archive/web/sacm/current/msg04630.html

[6] https://www.ietf.org/mail-archive/web/sacm/current/msg04650.html

[7] https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmen= tScenario

[8] https://www.ietf.org/mail-archive/web/sacm/current/msg04697.html

=C2=A0

_______________________________________________
sacm mailing list
sacm= @ietf.org
https://www.ietf.org/mailman/listinfo/= sacm
--001a113d60eaa2d75d054b7898b1-- From nobody Fri Mar 24 04:51:27 2017 Return-Path: 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 56ADE12963F for ; Fri, 24 Mar 2017 04:51:25 -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 lnXxDbMPfQ9R for ; Fri, 24 Mar 2017 04:51:22 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 C3CD912965E for ; Fri, 24 Mar 2017 04:51:22 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id l203so13675oia.0 for ; Fri, 24 Mar 2017 04:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lCQYBLxvsxVP6AuAnvvhhBX6ez7D57VEu4cQgEM+XBg=; b=H/NG1zwmUqjesDMdOvnXF8iXqgF9Phdtg0NLoBHXJGFtKjJB0zW82YsjqohLn8QNNV 230W43CbU+koFiBZ3ZDZ0ZoxMtqN9m2+SDPUsehmU6n8nFjUk5cW2B2Ggc3l1fsUg7zs P+fOD2RVS612shsGweSLMABpY1rSSEQWo6b1trtN9OtKW8jlWvCeAzJAYPDH33s1gdnX 1JTvfL0iSs3S/CLfctsPnGGxznlSF06yKT6ihMluAPIWiOOxBkLMrQLMaAdjoif/PF83 L7nBUQgtxdkNmmrCQJEAgimzIfZlYvFAQTK/QIyhqmtOiu7CsZvL4NQPkDP99f/fJUue OiMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lCQYBLxvsxVP6AuAnvvhhBX6ez7D57VEu4cQgEM+XBg=; b=klBh/Z4oYWbSgUb6XgdsGyHM0mHoLSfiGAizGEtImDclMz++v33jWnqCaR7sobIQjv M+U9lQ9brPYmEwUfh0K+DrW1kXxQSt7E196SV+EWcw+yuJlj8fHL1qh+Xz0adcNcdKT1 fCMaj1vAVnsyjBHJr1laPqBv45IiZvelWYx3gQ1rdO3wJVqFPBoEnYcl+MM3UjbNL30V 0Rz9eEZm4CzJ+fWa5jbksWPun/+0CW9tNlEi9YFf5f6H+knBxSfEgqKX8ruSbAhjYNkm WIfwhBcbE39vo3rmHceN5ujf0JhL1s0zO3vGPmIalKLoOpwBvRupuXOyp4V/65AmKcKs JNeQ== X-Gm-Message-State: AFeK/H1t9cIk70y7tVDEgKxfKYMCZdfOam+mIs0RBAbsjaBz65TZt9C6KQAlXw6Jch+PFO9PtgIL4dS9QVs9nA== X-Received: by 10.202.107.7 with SMTP id g7mr3914689oic.163.1490356281928; Fri, 24 Mar 2017 04:51:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adam Montville Date: Fri, 24 Mar 2017 11:51:11 +0000 Message-ID: To: "Haynes, Dan" , "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a11402cc6c5f353054b789c8f Archived-At: Subject: Re: [sacm] SACM Information Model Status Update X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 11:51:25 -0000 --001a11402cc6c5f353054b789c8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the update, Danny. Would it be accurate to say, then, that at this point there are not contentious issues with the information model? Tangent: Do you believe the information model, as it stands, does well enough for endpoint identification? Kind regards, Adam On Thu, Mar 23, 2017 at 2:37 PM Haynes, Dan wrote: > Hi Everyone, > > > I just wanted to give a quick status update on the SACM Information Model > since we will not be providing an update at IETF 98. > > > > We published revision -09 on March 13, 2017. It addressed the following > issues. > > > > =C2=B7 Added "derived", "authority", and "verified" to the collect= ionTaskType IE (https://github.com/sacmwg/draft-ietf-sacm-information-model= /issues/18). > > =C2=B7 Updated IE examples that use content-type to use statement-= type (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/56= ). > > =C2=B7 Added "networkZoneLocation", "layer2NetworkLocation", and "= layer3NetworkLocation" IEs (https://github.com/sacmwg/draft-ietf-sacm-infor= mation-model/issues/9). > > =C2=B7 Created a softwareClass attribute IE and added it to the so= ftwareInstance subject IE. Also, removed the os* attribute IEs (https://gi= thub.com/sacmwg/draft-ietf-sacm-information-model/issues/10). > > > > There are still some open issues associated with this draft, but, the maj= ority do not represent roadblocks and can be added at any time (e.g. new IE= and datatype requests, etc.). With that said, there is the open discussion= around the scope of the IM which has been a roadblock :) and we are trying= to work through that on the Vulnerability Assessment Scenario front. > > > > Please let me know if you have any questions or comments on these changes= . > > > > Thanks, > > Danny > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > --001a11402cc6c5f353054b789c8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the update, Danny.=C2=A0 Would it be accurat= e to say, then, that at this point there are not contentious issues with th= e information model? =C2=A0

Tangent: Do you believe the = information model, as it stands, does well enough for endpoint identificati= on?

Kind regards,

Adam

On Thu, Mar 23, 20= 17 at 2:37 PM Haynes, Dan <dhaynes@= mitre.org> wrote:

Hi Everyone,


I just wanted to give a quick status update on the SACM Information Model s= ince we will not be providing an update at IETF 98.<= /u>

=C2=A0

We published revision -09 on March 13, 201= 7. It addressed the following issues.

=C2=A0

=
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 Added "derived", "authority", and=
 "verified" to the collectionTaskType IE (https://github.com/sacmwg/draft-ietf-sacm-information=
-model/issues/18).
=
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 Updated IE examples that use content-type to use stat=
ement-type (https://github.com=
/sacmwg/draft-ietf-sacm-information-model/issues/56).
=
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 Added "networkZoneLocation", "layer2Ne=
tworkLocation", and "layer3NetworkLocation" IEs (https://github.com/sacmwg/draft-ietf-sacm-=
information-model/issues/9).
=
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 Created a softwareClass attribute IE and added it to =
the softwareInstance subject IE.=C2=A0 Also, removed the os* attribute IEs =
(https://github.com/sacmwg/dra=
ft-ietf-sacm-information-model/issues/10).
=C2=A0
There are still s=
ome open issues associated with this draft, but, the majority do not repres=
ent roadblocks and can be added at any time (e.g. new IE and datatype reque=
sts, etc.). With that said, there is the open discussion around the scope o=
f the IM which has been a roadblock :) and we are trying to work through th=
at on the Vulnerability Assessment Scenario front.
=C2=A0
Please let me kno=
w if you have any questions or comments on these changes.
=C2=A0
Thanks,

Danny

=C2=A0

_______________________________________________
sacm mailing list
sacm= @ietf.org
https://www.ietf.org/mailman/listinfo/= sacm
--001a11402cc6c5f353054b789c8f-- From nobody Sun Mar 26 03:38:58 2017 Return-Path: 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 92EB3120726 for ; Sun, 26 Mar 2017 03:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 GRTj_O2kn_vQ for ; Sun, 26 Mar 2017 03:38:55 -0700 (PDT) Received: from o5.sgmail.github.com (o5.sgmail.github.com [192.254.113.10]) (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 B8A851200C1 for ; Sun, 26 Mar 2017 03:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=DFbVJrVBMEJ+WtripFPQErSqs04=; b=oqrZHYCai/iRpagT 8XjrOtgsX+TKZg8FY7JurLaIH/Z4GrrsTjL/W4KUVHlIXycNsZ71BZHmtQEu4v9q mgxW2L2LIP2wO7i3GpyyNVvOIXRAXM7B7yTqEPqQSgElFBhBGlPef9g9ntBOe3PR 5b+ax4oWhTKQjCYf2lv3pzN4Jbs= Received: by filter0945p1mdw1.sendgrid.net with SMTP id filter0945p1mdw1-27823-58D79A3E-35 2017-03-26 10:38:54.73921478 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id cxkZ99a6RP-1q2HxrzyGDg for ; Sun, 26 Mar 2017 10:38:54.650 +0000 (UTC) Date: Sun, 26 Mar 2017 03:38:54 -0700 From: Jerome Athias Reply-To: sacmwg/draft-ietf-sacm-information-model To: sacmwg/draft-ietf-sacm-information-model Cc: Subscribed Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58d79a3e8989e_cca3f91658ddc3c552bb"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: athiasjerome X-GitHub-Recipient: sacm X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: sacm@ietf.org X-SG-EID: UtArl2HfP/Y+1oZ8SNY9H5rtKsff/A/VH18evFXNKZIBn1L1sqo+Rk9UAvWkeag6sIz3UQcBYcOzvM GIVKpcpjIoG7iMryaA+G3YR0BnFipZQKtsl3XqBaGbyYlDeGDGF5w3Q5Km42iTXLqV5hjIgRk6ev+n K2UiUkNtR9d0w1cffrEC47k2heUhWx4E647snpJ5h1JdbUTcdgbUOCkgEg== Archived-At: Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] softwareClass does not support softwareDependencies (#76) X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 10:38:57 -0000 ----==_mimepart_58d79a3e8989e_cca3f91658ddc3c552bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit somehow close to applicationComponent -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-289271671 ----==_mimepart_58d79a3e8989e_cca3f91658ddc3c552bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

somehow close to applicationComponent

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58d79a3e8989e_cca3f91658ddc3c552bb-- From nobody Sun Mar 26 15:34:25 2017 Return-Path: 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 25DD01286CA; Sun, 26 Mar 2017 15:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 YtBT3vI4UCiU; Sun, 26 Mar 2017 15:34:04 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0118.outbound.protection.outlook.com [23.103.201.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B75126BF6; Sun, 26 Mar 2017 15:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kRlebIrkaonK3beZ9dRyY9pgdGDvNaR4lhvQAvggURM=; b=Nz+1adadMyBd+R5mPsCCjAWwV3/mUg05e+3l3RA8LFc0cirSGWtxy8G+C69XlE/f+FQSdtr8LQQk8DRNadqxVVDH8MjJo2VaByslC1ap8gp4yBx/MeoJ6Zv83VUenVZEf0wdtoX/SJgEYrYvxRhUYtXgKLmaSN5XSKUFGAvOgp4= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Sun, 26 Mar 2017 22:34:02 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.020; Sun, 26 Mar 2017 22:34:01 +0000 From: "Waltermire, David A. (Fed)" To: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8g== Date: Sun, 26 Mar 2017 22:34:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.139] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:hClKWSPOlpJaHaSusXNqvUn2+aKbt/Rr9pKEAoIfd9jzNKkjkWBjiwZpyodwJaX9pfqcZcmO0PUki2D7LW58cV8awv2NPXwL48+xcCiBOatbRJsm9OK+ZDb4CgqfkDrgvQn8WbVhDoJ7EUej1Dxk7Wn4RNf4u3/jyn7OQnNOq03us3436SEWN4D3EDi8ko187EY0r65cXVhLCr02nopa9Uz55QKED6R1pCLFujK5kmM6EIxS4k5JHQKCZYi0l5mgp7hcbrPNosPefSCwWb7Y6gCYDFBDbK/JIxedaL1Uq1IAw1RX9gBjs4AOzD0tHwNRgX55loptWGMw+xpb58LJgQ== x-ms-office365-filtering-correlation-id: d1714e22-885a-4c53-e580-08d4749833d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39840400002)(39450400003)(39410400002)(39850400002)(5660300001)(2501003)(6116002)(102836003)(3846002)(8936002)(74316002)(97736004)(122556002)(7736002)(189998001)(25786009)(2201001)(450100002)(53936002)(8676002)(7696004)(81166006)(38730400002)(86362001)(305945005)(33656002)(99286003)(9686003)(55016002)(6506006)(6436002)(77096006)(2900100001)(3660700001)(66066001)(2906002)(50986999)(54356999)(3280700002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 22:34:01.8200 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: [sacm] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 22:34:07 -0000 The US Government has been working within the IETF SACM work group to stand= ardize the collection of endpoint configuration and other posture informati= on from enterprise endpoints. Collecting this information is critical to su= pport automation of common network security tasks, including asset, softwar= e, vulnerability, and configuration management. Thus far, our efforts have = focused primarily on standards to collect information in support of asset, = software and vulnerability management use cases, and has worked with other = IETF members to determine what data would need to be to be collected, and h= ow that data would be securely communicated across the network. Through suc= h exchanges an organization can know what client endpoints are connected to= their network, and if they are vulnerable to attack. Given the proliferation of attacks against network infrastructure devices, = it is clear that the next step in our enterprise security automation effort= must be to enable standardized reporting of similar information from netwo= rk infrastructure devices. With the growing number of Yang models and incre= ased adoption of NETCONF, RESTCONF, and related protocol work, the time is = right to work out how these standards can be used to measure the health of = network devices. This information will, as in our efforts in SACM for clien= t devices, support asset, software, vulnerability, and configuration manage= ment use cases. Standards-based reporting of this information from network = infrastructure devices will help network defenders protect against known at= tacks, and provide the necessary knowledge to detect and mitigate future at= tacks.=20 We would like to start a discussion about how to leverage the existing IETF= network management protocols to best address security automation for netwo= rk infrastructure devices. We would like your ideas on how to best pursue t= his work, and your insights into network infrastructure security problems t= hat will impact our networks in the future. We are holding a side meeting a= t IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion abou= t how to move forward. We will be meeting in Vevey 4 at the IETF meeting ve= nue. Here is a summary of the meeting details: PANIC (Posture Assessment through Network Information Collection) Bar BoF Wednesday, March 29th, 2017 @ 6:30pm CDT Swissotel Conference Center - Vevey 4 We look forward to working with you, and hope to see you in Chicago at the = PANIC Bar BoF. Regards, Dave David Waltermire Information Technology Laboratory | Computer Security Division National Institute of Standards and Technology From nobody Tue Mar 28 13:32:10 2017 Return-Path: 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 E11031275AB for ; Tue, 28 Mar 2017 13:32:07 -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 hqsYBT0tbDYg for ; Tue, 28 Mar 2017 13:32:06 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 11680129A16 for ; Tue, 28 Mar 2017 13:32:06 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id f193so46152569oib.2 for ; Tue, 28 Mar 2017 13:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SOchfxno1qRwu+TCUflAR/hHBFQty2tDdFoWnHCoIe0=; b=YZP/le1LlmKVQObyO8W5NbeK/nl5tUaloE7OTCWrMPaSA6vF6G2JNpsEiLuLoBT0+E Ic5QR5BMEiyycybX+h+cNOHUerIF7bzVrNTgaBC3YVO1lzcEXIGcGiOA4SgwFlNB+JaG nAEtTHeziOOiJnfbLamJ1jiNL5UcCQaY8ZXvBBPJB3aCuhj1I7moABbppnmd3TBLChMK xoWpIOtavceqBhv0W4XEyxK3piL5ZA4K+HrByA0nadzh01kxs6juN/7ugtddVQ8msa7r Pnal7dCK9y+x/H4f2RWWeTs41iWz+HPwXFxoF5WHA8UpK32gyBRX7Av7MYiSeOa5wEvU h+kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SOchfxno1qRwu+TCUflAR/hHBFQty2tDdFoWnHCoIe0=; b=BpaPImvOGarSvqwxLnaKU8gn28Twr/udkJt9KRw8UGej4tq11bGwrN5YuJOZyeV+C0 qXDlfGAiSEqvs/A4rd9e1XZxGO++WXr5YrQSndOgZv/4Km+oJamNz1FB8KAfJdLQqJ5T Ov6rMjJvo7uZrGetdaNY80KgACu5A0qP1yoFJ/HhLJB6L2i6rmQEkqzGyaJH11UmHKmi 79HUxjGveKJwfBwWJ0XUx9z2n4CTHpW/caqtT8+1mJ8+ZwL7os7zvV2u1KdkVois4guX AJibnoEvggK2GcXy5kPcPYnLjY4ZmLiUtRavHt0pbZvVLnDsncbKv3jperxQrpUD4I+W +1EQ== X-Gm-Message-State: AFeK/H0sdKhJnhW4a154yiaf3tYUSLLgA9VYf3zq52ooMrNUm8D+h02oyFltfsRqNfSU8EL9iqm+tY5jz+uvTA== X-Received: by 10.202.213.88 with SMTP id m85mr5599787oig.51.1490733125022; Tue, 28 Mar 2017 13:32:05 -0700 (PDT) MIME-Version: 1.0 From: Adam Montville Date: Tue, 28 Mar 2017 20:31:54 +0000 Message-ID: To: "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a113b02945f43ca054bd05a6b Archived-At: Subject: [sacm] This week's session... X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 20:32:08 -0000 --001a113b02945f43ca054bd05a6b Content-Type: text/plain; charset=UTF-8 If you're on this week's agenda [*], please send your slides soon. Also, we are in need of two note takers and a jabber scribe. If you are willing to volunteer, please let the chairs know! Kind regards, Adam [*] https://www.ietf.org/proceedings/98/agenda/agenda-98-sacm-00 --001a113b02945f43ca054bd05a6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you're on this week's agenda [*], please send y= our slides soon.

Also, we are in need of two note takers= and a jabber scribe. If you are willing to volunteer, please let the chair= s know!

Kind regards,

--001a113b02945f43ca054bd05a6b-- From nobody Tue Mar 28 14:46:32 2017 Return-Path: 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 54B171200A0 for ; Tue, 28 Mar 2017 14:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 N3iYFzFcCUlK for ; Tue, 28 Mar 2017 14:46:28 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 3EA0F129686 for ; Tue, 28 Mar 2017 14:46:27 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id r45so76207734qte.3 for ; Tue, 28 Mar 2017 14:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZE/2yZ63wsljJP5zuykmvTLZb0JtVezjJ0X8EG3H6Aw=; b=gS0krxdRL2n6KoCwMPsr/sPuNdb+8WzMv6bWunboclbKFNlxFXdVwStLH6Yil0OcJS wAwEPN1czu7qNb0IWtMporBxmsx/O1Aec7OdHkZQcSiB8J2VPrCTUJShe5lEEC6+ixfA 9pU47BS1hYmRz/fTRHSHxhW3Wv9cV9TvBJeHyHKqdaVKEQj2oFSGcJ4YGE8851jBhy+V yy68Hir3b8kCXhEX0Bik+7vuLNyFojf7v+nVkLZkuBYUrKO7GktpLBy0d6C22Zw+3StB Vv9kSfxDVhnC1iH116DNMHwBh2RFFULN4yJH4YY3+SesQ9Jm4MB/HPQAUpywyagzuf2P qqHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZE/2yZ63wsljJP5zuykmvTLZb0JtVezjJ0X8EG3H6Aw=; b=K3Gb9ggNXTmNMWjBSba8nNILhspCSWX9ZHiYyIiefKpPWOuMy1JuxH53wuKxlm9SsJ ex13HeB78/sqzGR3xjqCwl/rv2091sTGHwazX7GTB6fIVDn01lJgojj4/SKyD67maQSj KplbIGYcDsPNPP4LGqmnl9wCZpLOFf6OP4xly3wmjFgadmoVzNATuSllNqf7iaGVgc+k /6tW8TlY5GVKqcreqY99mDboPLmPvgpF272s61MJMdYub0wt64eRAzvV76ONgPzXoNUn 5asxu+sfspxneRqDtcIMpq4MW3+iupif5j+RBoZyajXrot2lVflgHuw5okUVNnPK7GTt DUrQ== X-Gm-Message-State: AFeK/H1b/pPxKGjJ11BmOHwWi17AWyu8AgOvjYPpGecI5RS4Ho0d01x+pi75b6gGWW1cJ71bGiQp+AP5qYvtmQ== X-Received: by 10.237.62.211 with SMTP id o19mr32329506qtf.135.1490737586376; Tue, 28 Mar 2017 14:46:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.28.116 with HTTP; Tue, 28 Mar 2017 14:46:05 -0700 (PDT) In-Reply-To: References: From: Ira McDonald Date: Tue, 28 Mar 2017 17:46:05 -0400 Message-ID: To: Adam Montville , Ira McDonald Cc: "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a114386d44a1731054bd16499 Archived-At: Subject: Re: [sacm] This week's session... X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 21:46:30 -0000 --001a114386d44a1731054bd16499 Content-Type: text/plain; charset=UTF-8 Hi Adam, I can't make it to IETF98 SACM call-in. Conflicting appointments. 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 Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Mar 28, 2017 at 4:31 PM, Adam Montville wrote: > If you're on this week's agenda [*], please send your slides soon. > > Also, we are in need of two note takers and a jabber scribe. If you are > willing to volunteer, please let the chairs know! > > Kind regards, > > Adam > > [*] https://www.ietf.org/proceedings/98/agenda/agenda-98-sacm-00 > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > --001a114386d44a1731054bd16499 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adam,

I can't make it t= o IETF98 SACM call-in.=C2=A0 Conflicting appointments.

Cheers,=
- Ira


<= div>
Ira McDonald (Musician / Software Archite= ct)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Founda= tion Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-= Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expe= rt - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
ma= ilto: blueroof= music@gmail.com
Jan-April: 579 Park Place=C2=A0 Saline, MI=C2=A0 481= 76=C2=A0 734-944-0094
May-Dec: PO Box 221=C2=A0 Grand Marais, MI 49839= =C2=A0 906-494-2434


On Tue, Mar 28, 2017 at 4:31 PM, Adam Montvi= lle <adam.w.montville@gmail.com> wrote:
If you're on this week's ag= enda [*], please send your slides soon.

Also, we are in = need of two note takers and a jabber scribe. If you are willing to voluntee= r, please let the chairs know!

Kind regards,
=


_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm


--001a114386d44a1731054bd16499-- From nobody Thu Mar 30 11:04:18 2017 Return-Path: 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 34C4E128C84 for ; Thu, 30 Mar 2017 11:04:16 -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 6y2JalRvmFL4 for ; Thu, 30 Mar 2017 11:04:14 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 3B17D1296CF for ; Thu, 30 Mar 2017 11:04:14 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id f193so38936043oib.2 for ; Thu, 30 Mar 2017 11:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oWg/VikEcelen4VEbTMc9zEFYIvuXTKh+Z5dcXkx2DY=; b=giCzUn4Kw4NxFogXdL9lbrDo4iIyZHn6XWogL68kB4cZu1r6k4lXmMOuw3JjRBTaHi 6WR90nAMSrOqdJXyGq0Kav5vuiRaFcCcjap8pf1nDOsvEVZU6W+narU13apgDWnyDPhn LeoHr25doIhTqpyA63Ge6mu8ptTyVf05AXYKyAXkw92aTgznWdMjCBkouQzJ2nm4oYB8 a9fAzmyqJPP6o0a4Vd2b+iqn3weQAtUIyaVp3vCHaXIMSULZMxNp5S9MvH5RKfqsdvzA uUrFuMoURI7rA/9DLHtI8Ha5sxFU8hdPAm7AJwIWuzbVYjeu9Ay5KEKCatRYELtZj5O6 +wGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oWg/VikEcelen4VEbTMc9zEFYIvuXTKh+Z5dcXkx2DY=; b=iF8ukY870vLuiAqjJqo7Vx8nDBC1OSQP2dkL80SLpDBKlUZPSF4Y/ksP92sKIyutP+ B1Xl7tno1q3ZXXE7bbvYw3xmXJWdZiCeYFKMN+b0WVPQUSgL5SioTbJwMlaXnmsC5Gby TPzNtbs2w5Ihjfl3JoCnHVlr2xzJDIkcKiEfey1aZip9ix9/0V0kROwQyZ1jvYGyXFXS caGkjhTtXU3l9v29yA8ohyw0hPmzmwpeNc9qnhmGVJsUKrtFzoav8+if2VEtPcjIgYUS uPTd2QL/vu4YICO02ngcIeb9GJwFhEa8bKeq8X2jGDe0ux5JW7kBjP983bFmx26nfadI Y4jg== X-Gm-Message-State: AFeK/H2WHNCsB1hwV6Z1g0ZMhGBVu6tAaP5e2o8ZeIjSa55/rwsA/WbGOBaN3Xpw06FH3WDKf1IocjmiCaTkQg== X-Received: by 10.202.196.71 with SMTP id u68mr658131oif.210.1490897053111; Thu, 30 Mar 2017 11:04:13 -0700 (PDT) MIME-Version: 1.0 From: Adam Montville Date: Thu, 30 Mar 2017 18:04:02 +0000 Message-ID: To: "sacm@ietf.org" Content-Type: multipart/alternative; boundary=001a11351c863f5c02054bf6859d Archived-At: Subject: [sacm] IETF 98 Notes Uploaded X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:04:16 -0000 --001a11351c863f5c02054bf6859d Content-Type: text/plain; charset=UTF-8 To those who were able to attend this morning's session, thank you! I've posted the notes from the session (thanks for taking them, Roman) here: https://www.ietf.org/proceedings/98/minutes/minutes-98-sacm-00 Kind regards, Adam --001a11351c863f5c02054bf6859d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To those who were able to attend this morning's sessio= n, thank you!=C2=A0 I've posted the notes from the session (thanks for = taking them, Roman) here:=C2=A0https://www.ietf.org/proceedings/98/minutes/= minutes-98-sacm-00

Kind regards,

Adam
--001a11351c863f5c02054bf6859d-- From nobody Thu Mar 30 14:10:52 2017 Return-Path: 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 4BDC9129583; Thu, 30 Mar 2017 14:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 B7MuL1UCXfPV; Thu, 30 Mar 2017 14:10:23 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 60722129483; Thu, 30 Mar 2017 14:09:32 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id g2so49777515pge.3; Thu, 30 Mar 2017 14:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7n0OsvI/E7+Yq5EncNM9IcshiVZcXglle39gzrq8Dc=; b=ih8nvURFKBQYdAAxqj3PCbkKDGGUS1bUlcMZMvwAAyBvP1fG38yLaZn79WUrK3U+HM Anoq9z+WGsfkWUoodyGhb/GbsF9+iRSMwPK4OvVq0Hx20Ro2KmxK5Wgwkh5AfEvKMa8R E7Sml4iBo6oVeEQGJ7YYLD3kY8yQOoJgSXaEcJ8SjGACxId1GoPpfJjgp30kd8li5FU8 A79ORrCsbHXkFCCQl2brQfUWPO6DTO04TJ1LCxIcghZO1bAY0hYx/7DvjibAEtGryjEQ 2Q3/fC6BWTTCVebtBixpsYxYu006keBevnABnk3L9YY1wMIV14cTXCQNCVaHS7Ie5t0v KWFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7n0OsvI/E7+Yq5EncNM9IcshiVZcXglle39gzrq8Dc=; b=n+62Z6GQQGvBUky4ktktzai45icgI+TN/HFngZMkhFbHOsiumoQyWUFZwGzhAaH95f bezxVHU4g0j1A/tdkVQmNMvvwB0UE0jCHYddCWUpRWbtQtrrbDWGtvhYsFNfJl5DRJEq i/6b73/S3EMQExTXobywjdcB7JxD5oPU8Mpd7GBR6tqOY+gt7zt7CrtquN7o9WRvmmzd 2Yx7NK/qKUjg8JwS/tVk3Ox8YlVDg6kV22eGbe6/sE/2Pyz/PZYjapM0t4pIxONczuBy 8WMVJZvHMd/QuwKQT+jacuOzabfKd9fjGZ45/uJflnkyekotX2mXpFLL7P7SeU3vYPv/ hdeA== X-Gm-Message-State: AFeK/H1FThdrfqT9Yk+sPekffJkWhKQQ9ykryI8h8495srZHvSZPFu2vOuSuX6biZUxX2g== X-Received: by 10.84.149.168 with SMTP id m37mr1342822pla.97.1490908171684; Thu, 30 Mar 2017 14:09:31 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1006::483? ([2001:420:c0c8:1006::483]) by smtp.gmail.com with ESMTPSA id b80sm6178658pfe.87.2017.03.30.14.09.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Mar 2017 14:09:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 30 Mar 2017 16:09:28 -0500 Cc: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> References: To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:10:26 -0000 David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) = wrote: >=20 >=20 > The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture = information from enterprise endpoints. Collecting this information is = critical to support automation of common network security tasks, = including asset, software, vulnerability, and configuration management. = Thus far, our efforts have focused primarily on standards to collect = information in support of asset, software and vulnerability management = use cases, and has worked with other IETF members to determine what data = would need to be to be collected, and how that data would be securely = communicated across the network. Through such exchanges an organization = can know what client endpoints are connected to their network, and if = they are vulnerable to attack. >=20 > Given the proliferation of attacks against network infrastructure = devices, it is clear that the next step in our enterprise security = automation effort must be to enable standardized reporting of similar = information from network infrastructure devices. With the growing number = of Yang models and increased adoption of NETCONF, RESTCONF, and related = protocol work, the time is right to work out how these standards can be = used to measure the health of network devices. This information will, as = in our efforts in SACM for client devices, support asset, software, = vulnerability, and configuration management use cases. Standards-based = reporting of this information from network infrastructure devices will = help network defenders protect against known attacks, and provide the = necessary knowledge to detect and mitigate future attacks.=20 >=20 > We would like to start a discussion about how to leverage the existing = IETF network management protocols to best address security automation = for network infrastructure devices. We would like your ideas on how to = best pursue this work, and your insights into network infrastructure = security problems that will impact our networks in the future. We are = holding a side meeting at IETF 98 on Wednesday, March 29th at 6:30pm CDT = to start a discussion about how to move forward. We will be meeting in = Vevey 4 at the IETF meeting venue. Maybe this was discussed in the BoF =E2=80=A6 The best way to have a discussion would be to present the proposal in = the form of a draft in the NETCONF WG. >=20 > Here is a summary of the meeting details: >=20 > PANIC (Posture Assessment through Network Information Collection) Bar = BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 >=20 > We look forward to working with you, and hope to see you in Chicago at = the PANIC Bar BoF. >=20 > Regards, > Dave >=20 > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Mar 30 14:38:27 2017 Return-Path: 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 1EC5C12957A; Thu, 30 Mar 2017 14:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 v7Vjhi8uSBcT; Thu, 30 Mar 2017 14:38:15 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EF512953D; Thu, 30 Mar 2017 14:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fhpXRk2GXCuvUgvGh+EBOd5yyb2hEdf9Y+A3Gg7UDCg=; b=sAc443pJMGmmB+rvDgp7auJLvAC5gpLiBEDJZEPjRDx2tjaJxhhxxBBYTBFaNYT7r1L5cEZW4xb2P1+pFGJJt/59jajXXYjQq6my+i+q4m3tW9sqUmVpH3e2B/srI8UyQ6J51tXSkLdqjMusOzw/hadQM6auuofO1ACthGQoF7I= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 30 Mar 2017 21:38:12 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.022; Thu, 30 Mar 2017 21:38:12 +0000 From: "Waltermire, David A. (Fed)" To: Mahesh Jethanandani CC: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8= Date: Thu, 30 Mar 2017 21:38:12 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> In-Reply-To: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2600:1008:b026:3c5b:880a:2104:6fcd:5c70] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:fmv4/kXlxEmSHZh/xh02rUjNmsl0GtUs05jZK7Y5JFRT7yWIkni0cnk2SgQZQiUNjYRZoLTnk2WVzy2tCEDpK/MoPb0+MisFwIhwqY7uvEPHQImImx+ebtTn0hJtnaWMEmV7pq9rZr2QBgjyDuh9QztAe0k32sStINXMDl60EX5w7kYmusucQ30aor9koMF+Y8/Hu2M38uMklSJ8lRhVyow5dlcSQdFVdmvwNSf4UNqt3lKNTYgUjlssksNS34F6d7+giRWkjm1pv2qSf+qBTaFSFyyxEN9VzCtC8O2KSxODbLjhj9Rbo5kQIwP5FXsI/7rkguFdPdU4We0kC7Q3Vg== x-ms-office365-filtering-correlation-id: 0b91b875-39a5-4d7b-8e91-08d477b510f1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39850400002)(39450400003)(39400400002)(39410400002)(24454002)(377454003)(33716001)(2950100002)(81166006)(229853002)(8676002)(8936002)(1411001)(2900100001)(2860100001)(7736002)(102836003)(2920100001)(6116002)(86362001)(3280700002)(5660300001)(3660700001)(7906003)(55846006)(6916009)(6486002)(77096006)(2906002)(6506006)(606005)(6436002)(99286003)(6306002)(9686003)(54896002)(54906002)(6512007)(53936002)(561944003)(76176999)(54356999)(236005)(39060400002)(110136004)(33656002)(38730400002)(4326008)(6246003)(25786009)(122556002)(189998001)(50986999)(82676001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 21:38:12.1393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:38:19 -0000 --_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" wr= ote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF =85 The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
We plan to write up a description adddessing the problem and 

On: 30 March 2017 16:09, "Mahesh Jethanandani" <mjethanandani@= gmail.com> wrote:
David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.walt= ermire@nist.gov> wrote:
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF =85

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com



 --_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_-- From nobody Thu Mar 30 14:44:15 2017 Return-Path: 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 D922C1294FF; Thu, 30 Mar 2017 14:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 eqPa49MvjPl0; Thu, 30 Mar 2017 14:43:45 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0132.outbound.protection.outlook.com [23.103.200.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E2012960F; Thu, 30 Mar 2017 14:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bgy2cJz1F/T9adb2KnkuXVvqo86DsAhG2xpN1H3tqTg=; b=xhzIPm+kHjjtlg+Qe7OsmT9AhZw12Iire5D5VWqeRcUHAQUkardpSdr0JGxrDR6vHaA/SWOEA27RohNM0PHXEpfPrP7M9Xc5ZFZkhN05yzlMvfwAOLXVYtocHhYxV6CWkeWuQNvC3CJWlNII1HAU7kqTBicxcqqh4PM8m5Poix0= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 30 Mar 2017 21:43:38 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.022; Thu, 30 Mar 2017 21:43:38 +0000 From: "Waltermire, David A. (Fed)" To: Mahesh Jethanandani CC: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AADCZJw== Date: Thu, 30 Mar 2017 21:43:38 +0000 Message-ID: <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2600:1008:b026:3c5b:880a:2104:6fcd:5c70] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 7:gPsskoOr3cXkVmihP4hWs0QtZDGbhd8A2Kp/gNTQmsAbfI9Cfi14UXdKY02b3Uvhv4lNfT2xRpurzw37oB8vbbmTWk+b5pY9bAA+oAptCjRd53sJNLJsbpknTcdhBOefZmtvZZEQd4auihnLBiPeu7KhahevujGV1BrnWa+a5q3h9nLJoXS0kjK3yu3cHsiMS+dOAGBjfXU2j8c7fy5jKMGNNH4tl90GwKU5yayxhUmqajLIG7AZwiWYTfGPl49ofLloK9WapwYrVh5vhfq5/BfLEwwdVlVDHUSiPQv1GG24u+MFCZfbY87JHPgeDZZV4pXs/ls/1IjLrpP7BnZhbg== x-ms-office365-filtering-correlation-id: 4dced6c9-e1e6-46be-7105-08d477b5d358 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39840400002)(39400400002)(39850400002)(39860400002)(24454002)(377454003)(6512007)(54356999)(9686003)(236005)(39060400002)(38730400002)(99286003)(81166006)(110136004)(54906002)(6506006)(6306002)(76176999)(54896002)(55846006)(6246003)(8676002)(2906002)(5660300001)(50986999)(7736002)(606005)(2920100001)(7906003)(2900100001)(2860100001)(122556002)(6436002)(25786009)(2950100002)(33716001)(3280700002)(8936002)(3660700001)(561944003)(86362001)(4326008)(1411001)(189998001)(77096006)(6486002)(33656002)(229853002)(102836003)(6116002)(53936002)(6916009)(82676001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 21:43:38.1864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:43:48 -0000 --_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry. Clicked send on my phone accidentally. We plan to write a draft describing the problem and scope of what we want t= o address. We will share this on the PANIC list and continue the conversati= on from there. We may want to present ideas in WGs like NETCONF at some tim= e in the future. We will know more once further discussion is had. Thanks, Dave ________________________________ On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" wrote: We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" wr= ote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF =85 The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sorry. Clicked send on my phone accidentally.

We plan to write a draft describing the problem and scope = of what we want to address. We will share this on the PANIC list and contin= ue the conversation from there. We may want to present ideas in WGs&nb= sp;like NETCONF at some time in the future. We will know more once further discussion is had.

Thanks,
Dave

On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" <david.w= altermire@nist.gov> wrote:
We plan to write up a description adddessing the problem and 

On: 30 March 2017 16:09, "Mahesh Jethanandani" <mjethanandani@= gmail.com> wrote:
David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.walt= ermire@nist.gov> wrote:
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF =85

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com



--_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_-- From nobody Thu Mar 30 15:27:02 2017 Return-Path: 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 76387129494; Thu, 30 Mar 2017 15:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 SSnFxnE6wQO9; Thu, 30 Mar 2017 15:26:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB941293EE; Thu, 30 Mar 2017 15:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13061; q=dns/txt; s=iport; t=1490912798; x=1492122398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=19mVUMQghqkUXDVMyPEbKC6F3Nr1e6SrPaD79QcZXeE=; b=g/k9I3Rb/jz5+kQWtXEraOpwQ6cUwvvGx7WsDbRvL7yxcxWYFRF4tjTh kekVVgp1uRDnHDzTECp7c4WNMa0rYwJjEt0Nz1bGXWQgKVmC3lI8g9AJu GNy/RVmNYCfT7FCyUip1Vdepw5hp5Zs431KE+rg9LYfuXrA6ejJwbDEgg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCdhd1Y/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm4/KWGBCweNbJFViBmIBoUxgg4fAQyCQIJsSgKDOD8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFQEBAQECAQEBKzsGCwULAgEIGAwbByEGCxQRAQEEAQ0FCIg+gS0DD?= =?us-ascii?q?QgOrVuHKg2DIwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4JRRociBZwvOwG?= =?us-ascii?q?GfIcbhC+RQIpyiHoBHziBBVsVQYZZdYkCgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,249,1486425600"; d="scan'208,217";a="226906754" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 22:26:37 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2UMQbBv000371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 22:26:37 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 18:26:36 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 18:26:36 -0400 From: "Eric Voit (evoit)" To: "Waltermire, David A. (Fed)" , "Mahesh Jethanandani" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AAQkXsA== Date: Thu, 30 Mar 2017 22:26:36 +0000 Message-ID: <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.244.210] Content-Type: multipart/alternative; boundary="_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 22:26:42 -0000 --_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, I know it is early, but for the secure communication part, have you conside= red using the YANG Push work being developed in the NETCONF WG? With this approach, you can subscribe to state changes within a device's YA= NG models. These could be PANIC developed YANG models, existing YANG mode= ls such as IETF-System, IETF-keychain, or some combination. Then if a hac= ker inserts new hardware, changes software versions, adds keys, adds users,= etc. that state change can be securely pushed to a subscribing where it ca= n be determined whether the change was expected/desired. Eric ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

I know it is early, but for the secur= e communication part, have you considered using the YANG Push work being developed in the NETCONF WG?

 

With this approach, you can subscribe= to state changes within a device‘s YANG models.  These could be= PANIC developed YANG models,  existing YANG models such as IETF-System, IETF-keychain, or some combination.   Then if a = hacker inserts new hardware, changes software versions, adds keys, adds use= rs, etc. that state change can be securely pushed to a subscribing where it= can be determined whether the change was expected/desired. 

 

Eric

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com


--_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_-- From nobody Fri Mar 31 10:55:27 2017 Return-Path: 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 200C9126D74; Fri, 31 Mar 2017 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 UoVXRZggRVzT; Fri, 31 Mar 2017 10:55:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607AD128DF6; Fri, 31 Mar 2017 10:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14467; q=dns/txt; s=iport; t=1490982905; x=1492192505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4vKofzxxu709iQwFQtlzKVJn2p8fQiwY0PGnr6QpS00=; b=l2aDiqbcpj7xjdQEZ05KQ1KvLLhimLfCcp1TQbbeQMdTvcHZ+IGKogLb LvXkjFC8E1vGvtMsnOdAsf2i9+NTz7Rto1rb0eyWSLneTd33C3yOQmWxs wcjXhlZN+5GexoYCUCaAGoNU/8rcs63Amiz5sDjNq5ZWUa9lpZmg0bCMe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBUl95Y/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm49KWGBCweNbZFUiBmIBoUxgg4fAQqCQoJsSgKDRz8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFQEBAQECAQEBKzsGCwULAgEIEQQBAQEnByEGCxQJCAEBBA4FCIhAg?= =?us-ascii?q?S0DDQgOsAaHKw2DJAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4JRgjmFLwW?= =?us-ascii?q?cLzsBjheEL5FDinaIegEfOIEFWxVBhll1iE6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208,217";a="405643111" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 17:55:04 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2VHt3Eq008873 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 17:55:04 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 12:55:03 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 12:55:03 -0500 From: "Panos Kampanakis (pkampana)" To: "Waltermire, David A. (Fed)" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AADCZJwAqSdrQ Date: Fri, 31 Mar 2017 17:55:03 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com>, <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> In-Reply-To: <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.5] Content-Type: multipart/alternative; boundary="_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 17:55:09 -0000 --_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a list for PANIC already? I couldn't find it. From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Waltermire, David A.= (Fed) Sent: Thursday, March 30, 2017 5:44 PM To: Mahesh Jethanandani Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Sorry. Clicked send on my phone accidentally. We plan to write a draft describing the problem and scope of what we want t= o address. We will share this on the PANIC list and continue the conversati= on from there. We may want to present ideas in WGs like NETCONF at some tim= e in the future. We will know more once further discussion is had. Thanks, Dave ________________________________ On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" > wrote: We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there a  list for PANIC alrea= dy?

I couldn’t find it.<= /span>

 

 

From: mile [mailto:mile-bounces@ietf= .org] On Behalf Of Waltermire, David A. (Fed)
Sent: Thursday, March 30, 2017 5:44 PM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org<= br> Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Sorry. Clicked send on m= y phone accidentally.

 =

We plan to write a draft= describing the problem and scope of what we want to address. We will share= this on the PANIC list and continue the conversation from there. We may wa= nt to present ideas in WGs like NETCONF at some time in the future. We will know more once further discussion is had.=

 =

Thanks,

Dave

 =

On: 30 March 2017 16:38,= "Waltermire, David A. (Fed)" <david.waltermire@nist.gov> wrote:

We plan to write up a description adddessing the problem and&nb= sp;

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com


--_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_-- From nobody Fri Mar 31 14:17:01 2017 Return-Path: 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 86F081299F4; Fri, 31 Mar 2017 14:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 aPXpEDRMWTKx; Fri, 31 Mar 2017 14:16:36 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0094.outbound.protection.outlook.com [23.103.201.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2147D129A0F; Fri, 31 Mar 2017 14:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0ZLQGdQ0+YrrwHNcFbPDvkhpBquqDGzffvfbKuTDLMI=; b=I63z9I5kdjpu6vxhwC0g8LbQbkT9CGyFDovI5tJRufXvOPbUkHGa3kQ+otkmwwUW9VXrbzlTf4E7nClT975dXwkBhLkzK9b17acqD2z1nICVIvLAg7BCKZUTkkr2TliOGFGXuM7M6lqNcq3ZFnCaucuVzh1De9PjvEv/uj52idc= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 21:16:33 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.023; Fri, 31 Mar 2017 21:16:33 +0000 From: "Waltermire, David A. (Fed)" To: "Eric Voit (evoit)" , Mahesh Jethanandani CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AAQkXsAApvTOA Date: Fri, 31 Mar 2017 21:16:32 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> In-Reply-To: <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.96] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:jFJhSBUZCZMUkfv7NwbnR9aA/cu2RcBMqpz3z+qBd+koPuk6tcMfSkbe3sZshJHn9cF9chTip3V1DAERgdgmonjWEpsjMfdaTZV/RYG52w4x3rZEndtf8qpBbn+UAYrZNGPxfQI6JlomlbzRQAGD17btDWfDhjPDZWebeWC5kqJ8R51f03AW+wiCNbgbSmjVALZpKg551Db7CoH+vPSRXA39zhEXv9He9T+C/6F9xapgqaMaCwoNsN86TCQqIuq5IO2cFIeXGJwxMO+yn/rGS1jQF/5m81ahBm7RDtwfEWg437IUS9Xd/AMqrRsCe5NjRcIRsYsE6Ng6/+J6q/CatA== x-ms-office365-filtering-correlation-id: 870e64b7-77b2-49f8-67af-08d4787b34f4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(120809045254105)(192374486261705)(95692535739014)(21748063052155)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39400400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(3846002)(6116002)(8676002)(790700001)(102836003)(93886004)(7736002)(81156014)(81166006)(6246003)(74316002)(3660700001)(2950100002)(3280700002)(53546009)(25786009)(39060400002)(53936002)(77096006)(38730400002)(7906003)(4326008)(6506006)(7696004)(99286003)(8936002)(66066001)(229853002)(6306002)(2906002)(606005)(9686003)(54896002)(5660300001)(236005)(19609705001)(6436002)(2900100001)(54906002)(122556002)(561944003)(50986999)(76176999)(54356999)(55016002)(189998001)(33656002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 21:16:32.8633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:16:40 -0000 --_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, We have considered YANG Push as part of PANIC. I have read the draft and I = attended your presentation during NETCONF. I think Yang Push is something w= e should consider as part of the PANIC solution. Do you have an implementat= ion of YANG Push that can be experimented with? Regards, Dave From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, March 30, 2017 6:27 PM To: Waltermire, David A. (Fed) ; Mahesh Jethanan= dani Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Hi David, I know it is early, but for the secure communication part, have you conside= red using the YANG Push work being developed in the NETCONF WG? With this approach, you can subscribe to state changes within a device's YA= NG models. These could be PANIC developed YANG models, existing YANG mode= ls such as IETF-System, IETF-keychain, or some combination. Then if a hac= ker inserts new hardware, changes software versions, adds keys, adds users,= etc. that state change can be securely pushed to a subscribing where it ca= n be determined whether the change was expected/desired. Eric ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

We have considered YANG Push as part of PANIC. I ha= ve read the draft and I attended your presentation during NETCONF. I think = Yang Push is something we should consider as part of the PANIC solution. Do you have an implementation of YANG Push that can= be experimented with?

 

Regards,

Dave

 

From: Eric Voit (evoit) [mailto:evoi= t@cisco.com]
Sent: Thursday, March 30, 2017 6:27 PM
To: Waltermire, David A. (Fed) <david.waltermire@nist.gov>; Ma= hesh Jethanandani <mjethanandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org<= br> Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Hi David,

 

I know it is early, but for the secur= e communication part, have you considered using the YANG Push work being developed in the NETCONF WG?

 

With this approach, you can subscribe= to state changes within a device‘s YANG models.  These could be= PANIC developed YANG models,  existing YANG models such as IETF-System, IETF-keychain, or some combination.   Then if a = hacker inserts new hardware, changes software versions, adds keys, adds use= rs, etc. that state change can be securely pushed to a subscribing where it= can be determined whether the change was expected/desired. 

 

Eric

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com=

--_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_-- From nobody Fri Mar 31 14:18:02 2017 Return-Path: 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 DA9FF129A0F; Fri, 31 Mar 2017 14:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 5njpH8njgP25; Fri, 31 Mar 2017 14:17:59 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0131.outbound.protection.outlook.com [23.103.201.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F9A1299F4; Fri, 31 Mar 2017 14:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aW14rQ64WfLW9mzTRTK9aaVmNJBIx1f3V5oEqcMxPNA=; b=hpUOIJ1uVPoMNfr/Jq9M035Ve71IubtMcYr7jzjb4+nMgcZHsilT7VD+X8NBaBEAcTy7LY07i37SWCRVLM9ISqlZCQv9FPjFhYqhhuhmfmBfa6+V1FMETCHj+KVsM6FpsKO6XTGCixV9cYNOF8H9dm3c/Pk/i7zodsD3N6xigNk= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 21:17:56 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.023; Fri, 31 Mar 2017 21:17:56 +0000 From: "Waltermire, David A. (Fed)" To: "Panos Kampanakis (pkampana)" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AADCZJwAqSdrQAAcUj4A= Date: Fri, 31 Mar 2017 21:17:55 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com>, <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.96] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:ilvMp1wVulrAzgWCMh//83kCjV9uIhC1BSXRA3CuWOUQ9H9+IvUGOPMLTaCZz+R5zvZrgYEAH4iNuYyncP1zQ5ROnV9It77nk3s6GbE2p5G/iK7GHnAOOCkiFrR0oU/ZO82pAEYdo5OaUvg/CL1q/MqQMm05nWfwDPRe/E8GfLbNuf4cUYJDK9a+HSAx5cUeeUMdeFEJtX3jAtMDEWdxypRss2O1UNhlkQuXt/qq+kPH59uERwfzFRiOqsSM0F0KQfvttfN38VWsJY2ULXumJ0WBw3ocfqbJkhb+ONJsrumZ2+ZeB51D4hiwvfnfbxjWv9/duSZLarVoyr2H+9zC6A== x-ms-office365-filtering-correlation-id: fd71323e-2060-4daa-2f11-08d4787b6670 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(95692535739014)(21748063052155)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39400400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(3846002)(6116002)(8676002)(790700001)(102836003)(93886004)(7736002)(81166006)(6246003)(74316002)(6916009)(3660700001)(2950100002)(3280700002)(53546009)(25786009)(53936002)(77096006)(110136004)(38730400002)(7906003)(4326008)(6506006)(7696004)(99286003)(8936002)(66066001)(229853002)(6306002)(2906002)(606005)(9686003)(54896002)(5660300001)(236005)(19609705001)(6436002)(2900100001)(54906002)(122556002)(561944003)(50986999)(76176999)(54356999)(55016002)(189998001)(33656002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 21:17:55.9119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:18:02 -0000 --_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Panos, We have requested a list to be setup. We will post again with signup info o= nce the list is created. Thanks, Dave From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Friday, March 31, 2017 1:55 PM To: Waltermire, David A. (Fed) Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Is there a list for PANIC already? I couldn't find it. From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Waltermire, David A.= (Fed) Sent: Thursday, March 30, 2017 5:44 PM To: Mahesh Jethanandani > Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Sorry. Clicked send on my phone accidentally. We plan to write a draft describing the problem and scope of what we want t= o address. We will share this on the PANIC list and continue the conversati= on from there. We may want to present ideas in WGs like NETCONF at some tim= e in the future. We will know more once further discussion is had. Thanks, Dave ________________________________ On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" > wrote: We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Panos,

 

We have requested a list to be setup. We will post = again with signup info once the list is created.

 

Thanks,

Dave

 

From: Panos Kampanakis (pkampana) [m= ailto:pkampana@cisco.com]
Sent: Friday, March 31, 2017 1:55 PM
To: Waltermire, David A. (Fed) <david.waltermire@nist.gov>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org<= br> Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Is there a  list for PANIC alrea= dy?

I couldn’t find it.<= /span>

 

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Waltermire, David A. (Fed)
Sent: Thursday, March 30, 2017 5:44 PM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org
Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Sorry. Clicked send on m= y phone accidentally.

 =

We plan to write a draft= describing the problem and scope of what we want to address. We will share= this on the PANIC list and continue the conversation from there. We may wa= nt to present ideas in WGs like NETCONF at some time in the future. We will know more once further discussion is had.=

 =

Thanks,

Dave

 =

On: 30 March 2017 16:38,= "Waltermire, David A. (Fed)" <david.waltermire@nist.gov> wrote:

We plan to write up a description adddessing the problem and&nb= sp;

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com

--_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_-- From nobody Fri Mar 31 14:23:17 2017 Return-Path: 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 4A50D1270FC; Fri, 31 Mar 2017 14:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 Nv8DxTKnBpHT; Fri, 31 Mar 2017 14:23:00 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0116.outbound.protection.outlook.com [23.103.201.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D364129A0C; Fri, 31 Mar 2017 14:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/p4KiTAn78IHZvOywMqia9OhuKCnXolpaYvdIUAvSj4=; b=QdQEWSkeW+h+kzinF+k4Kc6LuwJryYK5ik4t1FqtqV4+dboDpoK44TfLCDWPOuVrLRr+1pe3yYHRSjbEjsVcy83htaV3EIoTpKrFaD0i3xNkewqegs4CRmYCeuKzkdJP6yMuSda0tlXTd2Wr0p+fHCTIG55BboBvJI+ZZHuTeqs= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 21:22:57 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.023; Fri, 31 Mar 2017 21:22:57 +0000 From: "Waltermire, David A. (Fed)" To: Mahesh Jethanandani CC: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAADKZ5cA= Date: Fri, 31 Mar 2017 21:22:57 +0000 Message-ID: References: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> In-Reply-To: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.96] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:hTA2/3Zbv17b+e/hSFMR128IXfsMO523GkmSjE08Uts5tF5P6v0liUGswG3aPDw1DtE+r0JVx2mP4kafn88o9QC6Rq8YW+cSDCenvtWHMZ64jLsqelEn+8w1ZqNN3CuCCPbHpFRNyghhNSJqbA0WekH0WYfICoA64CrrBjzd0sRfFOq0HQgjNf4f82GkQS+AM1Won8a7zisNlmfPSPH0VBja08WMzkXGDIM9yS6/7U81IS8/4wp1gIKf6FaAFfTSaf3ubAn8hG7ArKFuVtnzyaZVRhyw0iH/Bgjd2sFCPFwBles6eO38QpZPBRiWTsbfEqGag8n0XnUZxQs2qcxV5w== x-ms-office365-filtering-correlation-id: c503eee0-ada9-4568-96d4-08d4787c1a31 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39410400002)(39840400002)(39450400003)(39400400002)(377454003)(13464003)(24454002)(5660300001)(66066001)(8936002)(9686003)(2906002)(229853002)(6306002)(76176999)(54356999)(50986999)(561944003)(33656002)(189998001)(86362001)(55016002)(6436002)(2900100001)(122556002)(54906002)(99286003)(6916009)(2950100002)(3660700001)(3280700002)(102836003)(8676002)(7736002)(3846002)(6116002)(74316002)(81156014)(81166006)(6246003)(110136004)(38730400002)(7696004)(6506006)(4326008)(53546009)(53936002)(77096006)(1411001)(305945005)(25786009)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 21:22:57.4265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:23:02 -0000 TWFoZXNoLA0KDQpTdWJtaXR0aW5nIGEgZHJhZnQgdG8gdGhlIE5FVENPTkYgV0cgbWlnaHQgYmUg YSBwYXRoIGZvcndhcmQuIEJhc2VkIG9uIHRoZSBmZWVkYmFjayB3ZSByZWNlaXZlZCwgd2UgYXJl IHdvcmtpbmcgb24gYSBzY29wZSBkcmFmdCB0byBmb2N1cyB0aGUgZGlzY3Vzc2lvbiBhcm91bmQg aG93IHdlIGNhbiBsZXZlcmFnZSBleGlzdGluZyB3b3JrLiBJIGhhdmUgYSBwZXJzb25hbCBpbmRp dmlkdWFsIHN0cmVhbSBkcmFmdCByZWFkeSBhbmQgd2lsbCBwb3N0IGl0IGFzIHNvb24gYXMgSSBj YW4gd29yayBvdXQgYW4gaXNzdWUgd2l0aCB0aGUgc3VibWlzc2lvbiB0b29sLg0KDQpSZWdhcmRz LA0KRGF2ZSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYWhlc2gg SmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQo+IFNlbnQ6IFRo dXJzZGF5LCBNYXJjaCAzMCwgMjAxNyA1OjA5IFBNDQo+IFRvOiBXYWx0ZXJtaXJlLCBEYXZpZCBB LiAoRmVkKSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4NCj4gQ2M6IG5ldGNvbmZAaWV0Zi5v cmc7IG5ldG1vZEBpZXRmLm9yZzsgc2FjbUBpZXRmLm9yZzsgbWlsZUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW05ldGNvbmZdIFBBTklDIEJhciBCb0YgV2VkbmVzZGF5IEAgNjozMHBtIENEVA0K PiANCj4gRGF2aWQsDQo+IA0KPiA+IE9uIE1hciAyNiwgMjAxNywgYXQgNTozNCBQTSwgV2FsdGVy bWlyZSwgRGF2aWQgQS4gKEZlZCkNCj4gPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+IHdyb3Rl Og0KPiA+DQo+ID4NCj4gPiBUaGUgVVMgR292ZXJubWVudCBoYXMgYmVlbiB3b3JraW5nIHdpdGhp biB0aGUgSUVURiBTQUNNIHdvcmsgZ3JvdXAgdG8NCj4gc3RhbmRhcmRpemUgdGhlIGNvbGxlY3Rp b24gb2YgZW5kcG9pbnQgY29uZmlndXJhdGlvbiBhbmQgb3RoZXIgcG9zdHVyZQ0KPiBpbmZvcm1h dGlvbiBmcm9tIGVudGVycHJpc2UgZW5kcG9pbnRzLiBDb2xsZWN0aW5nIHRoaXMgaW5mb3JtYXRp b24gaXMgY3JpdGljYWwNCj4gdG8gc3VwcG9ydCBhdXRvbWF0aW9uIG9mIGNvbW1vbiBuZXR3b3Jr IHNlY3VyaXR5IHRhc2tzLCBpbmNsdWRpbmcgYXNzZXQsDQo+IHNvZnR3YXJlLCB2dWxuZXJhYmls aXR5LCBhbmQgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50LiBUaHVzIGZhciwgb3VyIGVmZm9ydHMN Cj4gaGF2ZSBmb2N1c2VkIHByaW1hcmlseSBvbiBzdGFuZGFyZHMgdG8gY29sbGVjdCBpbmZvcm1h dGlvbiBpbiBzdXBwb3J0IG9mDQo+IGFzc2V0LCBzb2Z0d2FyZSBhbmQgdnVsbmVyYWJpbGl0eSBt YW5hZ2VtZW50IHVzZSBjYXNlcywgYW5kIGhhcyB3b3JrZWQNCj4gd2l0aCBvdGhlciBJRVRGIG1l bWJlcnMgdG8gZGV0ZXJtaW5lIHdoYXQgZGF0YSB3b3VsZCBuZWVkIHRvIGJlIHRvIGJlDQo+IGNv bGxlY3RlZCwgYW5kIGhvdyB0aGF0IGRhdGEgd291bGQgYmUgc2VjdXJlbHkgY29tbXVuaWNhdGVk IGFjcm9zcyB0aGUNCj4gbmV0d29yay4gVGhyb3VnaCBzdWNoIGV4Y2hhbmdlcyBhbiBvcmdhbml6 YXRpb24gY2FuIGtub3cgd2hhdCBjbGllbnQNCj4gZW5kcG9pbnRzIGFyZSBjb25uZWN0ZWQgdG8g dGhlaXIgbmV0d29yaywgYW5kIGlmIHRoZXkgYXJlIHZ1bG5lcmFibGUgdG8NCj4gYXR0YWNrLg0K PiA+DQo+ID4gR2l2ZW4gdGhlIHByb2xpZmVyYXRpb24gb2YgYXR0YWNrcyBhZ2FpbnN0IG5ldHdv cmsgaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcywgaXQNCj4gaXMgY2xlYXIgdGhhdCB0aGUgbmV4dCBz dGVwIGluIG91ciBlbnRlcnByaXNlIHNlY3VyaXR5IGF1dG9tYXRpb24gZWZmb3J0IG11c3QNCj4g YmUgdG8gZW5hYmxlIHN0YW5kYXJkaXplZCByZXBvcnRpbmcgb2Ygc2ltaWxhciBpbmZvcm1hdGlv biBmcm9tIG5ldHdvcmsNCj4gaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcy4gV2l0aCB0aGUgZ3Jvd2lu ZyBudW1iZXIgb2YgWWFuZyBtb2RlbHMgYW5kDQo+IGluY3JlYXNlZCBhZG9wdGlvbiBvZiBORVRD T05GLCBSRVNUQ09ORiwgYW5kIHJlbGF0ZWQgcHJvdG9jb2wgd29yaywgdGhlDQo+IHRpbWUgaXMg cmlnaHQgdG8gd29yayBvdXQgaG93IHRoZXNlIHN0YW5kYXJkcyBjYW4gYmUgdXNlZCB0byBtZWFz dXJlIHRoZQ0KPiBoZWFsdGggb2YgbmV0d29yayBkZXZpY2VzLiBUaGlzIGluZm9ybWF0aW9uIHdp bGwsIGFzIGluIG91ciBlZmZvcnRzIGluIFNBQ00gZm9yDQo+IGNsaWVudCBkZXZpY2VzLCBzdXBw b3J0IGFzc2V0LCBzb2Z0d2FyZSwgdnVsbmVyYWJpbGl0eSwgYW5kIGNvbmZpZ3VyYXRpb24NCj4g bWFuYWdlbWVudCB1c2UgY2FzZXMuIFN0YW5kYXJkcy1iYXNlZCByZXBvcnRpbmcgb2YgdGhpcyBp bmZvcm1hdGlvbiBmcm9tDQo+IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcyB3aWxsIGhl bHAgbmV0d29yayBkZWZlbmRlcnMgcHJvdGVjdCBhZ2FpbnN0DQo+IGtub3duIGF0dGFja3MsIGFu ZCBwcm92aWRlIHRoZSBuZWNlc3Nhcnkga25vd2xlZGdlIHRvIGRldGVjdCBhbmQgbWl0aWdhdGUN Cj4gZnV0dXJlIGF0dGFja3MuDQo+ID4NCj4gPiBXZSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgZGlz Y3Vzc2lvbiBhYm91dCBob3cgdG8gbGV2ZXJhZ2UgdGhlIGV4aXN0aW5nIElFVEYNCj4gbmV0d29y ayBtYW5hZ2VtZW50IHByb3RvY29scyB0byBiZXN0IGFkZHJlc3Mgc2VjdXJpdHkgYXV0b21hdGlv biBmb3INCj4gbmV0d29yayBpbmZyYXN0cnVjdHVyZSBkZXZpY2VzLiBXZSB3b3VsZCBsaWtlIHlv dXIgaWRlYXMgb24gaG93IHRvIGJlc3QNCj4gcHVyc3VlIHRoaXMgd29yaywgYW5kIHlvdXIgaW5z aWdodHMgaW50byBuZXR3b3JrIGluZnJhc3RydWN0dXJlIHNlY3VyaXR5DQo+IHByb2JsZW1zIHRo YXQgd2lsbCBpbXBhY3Qgb3VyIG5ldHdvcmtzIGluIHRoZSBmdXR1cmUuIFdlIGFyZSBob2xkaW5n IGEgc2lkZQ0KPiBtZWV0aW5nIGF0IElFVEYgOTggb24gV2VkbmVzZGF5LCBNYXJjaCAyOXRoIGF0 IDY6MzBwbSBDRFQgdG8gc3RhcnQgYQ0KPiBkaXNjdXNzaW9uIGFib3V0IGhvdyB0byBtb3ZlIGZv cndhcmQuIFdlIHdpbGwgYmUgbWVldGluZyBpbiBWZXZleSA0IGF0IHRoZQ0KPiBJRVRGIG1lZXRp bmcgdmVudWUuDQo+IA0KPiBNYXliZSB0aGlzIHdhcyBkaXNjdXNzZWQgaW4gdGhlIEJvRiDigKYN Cj4gDQo+IFRoZSBiZXN0IHdheSB0byBoYXZlIGEgZGlzY3Vzc2lvbiB3b3VsZCBiZSB0byBwcmVz ZW50IHRoZSBwcm9wb3NhbCBpbiB0aGUNCj4gZm9ybSBvZiBhIGRyYWZ0IGluIHRoZSBORVRDT05G IFdHLg0KPiANCj4gPg0KPiA+IEhlcmUgaXMgYSBzdW1tYXJ5IG9mIHRoZSBtZWV0aW5nIGRldGFp bHM6DQo+ID4NCj4gPiBQQU5JQyAoUG9zdHVyZSBBc3Nlc3NtZW50IHRocm91Z2ggTmV0d29yayBJ bmZvcm1hdGlvbiBDb2xsZWN0aW9uKSBCYXINCj4gPiBCb0YgV2VkbmVzZGF5LCBNYXJjaCAyOXRo LCAyMDE3IEAgNjozMHBtIENEVCBTd2lzc290ZWwgQ29uZmVyZW5jZQ0KPiA+IENlbnRlciAtIFZl dmV5IDQNCj4gPg0KPiA+IFdlIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdpdGggeW91LCBhbmQg aG9wZSB0byBzZWUgeW91IGluIENoaWNhZ28gYXQNCj4gdGhlIFBBTklDIEJhciBCb0YuDQo+ID4N Cj4gPiBSZWdhcmRzLA0KPiA+IERhdmUNCj4gPg0KPiA+IERhdmlkIFdhbHRlcm1pcmUNCj4gPiBJ bmZvcm1hdGlvbiBUZWNobm9sb2d5IExhYm9yYXRvcnkgfCBDb21wdXRlciBTZWN1cml0eSBEaXZp c2lvbg0KPiA+IE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kN Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+IA0KPiBNYWhlc2gg SmV0aGFuYW5kYW5pDQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+IA0KPiANCg0K From nobody Fri Mar 31 15:30:35 2017 Return-Path: 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 EF40F126DCA; Fri, 31 Mar 2017 15:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 940bh4kTDmyQ; Fri, 31 Mar 2017 15:30:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034BA124217; Fri, 31 Mar 2017 15:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19613; q=dns/txt; s=iport; t=1490999419; x=1492209019; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7wxMQWivaC05J4CoJSQp3a/2s4VZdrYsseKXlN32Seo=; b=KZCNZ6aHuLUc3/SIJYtM6MDH7b+GStxp6tBVCiEnFd/1sGd95I3yWlc8 Js8QBsTJGBIJjzdCNNRhSmLE+EvV8pnSIeKV+/Yg7a3SGjXe07TzoqrJi 61YA2hnImMkrHPFukkKn3MvV4Os1RNGvxH1OpSR4DXNX58RHuKCzY5NLu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQBB2N5Y/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm49KWGBCweNbZFViBqNN4IOHwEMgkCCbEoCg0k/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBASs7BgsFCwIBCBEEAQEBDBsHIQYLFAkIAQEEAQ0FCBOIL?= =?us-ascii?q?YEtAw0IDq9BhywNgyQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZOhG+CUUaBc4U?= =?us-ascii?q?vBZwvOwGGfIcbhC+CBokFhjiKdoh6AR84gQVbFUGGWXWIToENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,254,1486425600"; d="scan'208,217";a="216950536" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 22:30:18 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2VMUIhm028690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 22:30:18 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 18:30:17 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 18:30:17 -0400 From: "Eric Voit (evoit)" To: "Waltermire, David A. (Fed)" , "Mahesh Jethanandani" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AAQkXsAApvTOAAAkfouA= Date: Fri, 31 Mar 2017 22:30:17 +0000 Message-ID: <20f788b0479b41fd8db957f78dc983aa@XCH-RTP-013.cisco.com> References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SACM WG mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 22:30:23 -0000 --_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For experimentation, OpenDaylight has YANG Push code for the both subscribe= r and publisher. I can work with you offline to help define a viable testb= ed. Eric From: Waltermire, David A, March 31, 2017 5:17 PM Eric, We have considered YANG Push as part of PANIC. I have read the draft and I = attended your presentation during NETCONF. I think Yang Push is something w= e should consider as part of the PANIC solution. Do you have an implementat= ion of YANG Push that can be experimented with? Regards, Dave From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, March 30, 2017 6:27 PM To: Waltermire, David A. (Fed) >; Mahesh Jethanandani > Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Hi David, I know it is early, but for the secure communication part, have you conside= red using the YANG Push work being developed in the NETCONF WG? With this approach, you can subscribe to state changes within a device's YA= NG models. These could be PANIC developed YANG models, existing YANG mode= ls such as IETF-System, IETF-keychain, or some combination. Then if a hac= ker inserts new hardware, changes software versions, adds keys, adds users,= etc. that state change can be securely pushed to a subscribing where it ca= n be determined whether the change was expected/desired. Eric ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For experimentation, OpenDaylight has= YANG Push code for the both subscriber and publisher.  I can work wit= h you offline to help define a viable testbed.

 

Eric

 

From: Waltermire, David A,  Mar= ch 31, 2017 5:17 PM

Eric,

 

We have considered YANG Push as part of PANIC. I ha= ve read the draft and I attended your presentation during NETCONF. I think = Yang Push is something we should consider as part of the PANIC solution. Do you have an implementation of YANG Push that can= be experimented with?

 

Regards,

Dave

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Thursday, March 30, 2017 6:27 PM
To: Waltermire, David A. (Fed) <david.waltermire@nist.gov>; Mahesh Jethanandani <mjetha= nandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org
Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Hi David,

 

I know it is early, but for the secur= e communication part, have you considered using the YANG Push work being developed in the NETCONF WG?

 

With this approach, you can subscribe= to state changes within a device‘s YANG models.  These could be= PANIC developed YANG models,  existing YANG models such as IETF-System, IETF-keychain, or some combination.   Then if a = hacker inserts new hardware, changes software versions, adds keys, adds use= rs, etc. that state change can be securely pushed to a subscribing where it= can be determined whether the change was expected/desired. 

 

Eric

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wro= te:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <= david.waltermire@nist.gov> w= rote:
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com=

--_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_--