Re: [sacm] ECP Architecture Diagram Feedback
Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 10 April 2018 15:34 UTC
Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 1411D12D9FF for <sacm@ietfa.amsl.com>; Tue, 10 Apr 2018 08:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SqxihPXSKlmI for <sacm@ietfa.amsl.com>; Tue, 10 Apr 2018 08:34:26 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA81412D95D for <sacm@ietf.org>; Tue, 10 Apr 2018 08:34:24 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w3AFYLo0030817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Apr 2018 17:34:22 +0200
Received: from [10.203.31.138] (80.187.112.97) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.389.1; Tue, 10 Apr 2018 17:34:14 +0200
Date: Tue, 10 Apr 2018 17:34:12 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <CAOxmg6tz7BxQwG+4Et91hSQL8x2PDsGS5aF7CQxvMa6MJziNuA@mail.gmail.com>
References: <DM5PR0901MB2197070C2CF8BA9A4283251CA5A60@DM5PR0901MB2197.namprd09.prod.outlook.com> <D0D3E5A5-2D22-4B3A-AD3E-27386CC43887@gmail.com> <DM5PR0901MB2197CA6B3C285DD17A0D1C04A5A50@DM5PR0901MB2197.namprd09.prod.outlook.com> <CAOxmg6tbzQBpqubuxn5DPFe1mcB7gjhX3hr5g8A4hMoexyki-A@mail.gmail.com> <DM5PR0901MB21977263C87CA80E2D277750A5A40@DM5PR0901MB2197.namprd09.prod.outlook.com> <CAOxmg6s1GMnbZO2pzR2baNJ_MCPwqacdcjm+8yA5Tjkh0-+fNQ@mail.gmail.com> <DM5PR0901MB21971D0D935BD3A6BB1E7A42A5BF0@DM5PR0901MB2197.namprd09.prod.outlook.com> <CAOxmg6tsRNVdbDQbm0qmcY=6_WqE4vXtJeHM0oxok5BzAntvEA@mail.gmail.com> <4aba97cd-f2fd-2c0f-8b2d-53379a5c74c6@sit.fraunhofer.de> <CAOxmg6vLPvFRtZBCzb_79ezJz2iX2EE1upQtNafMGsANRQpd7w@mail.gmail.com> <46e44aad-7112-94a8-0b98-905a606ec38e@sit.fraunhofer.de> <CAOxmg6tDDeSJPRTh0siJoD832JidLtyP7bVXvUL9mTE=iJO9UA@mail.gmail.com> <1283219b-af55-984c-0d6e-a81e9dd0f2c1@sit.fraunhofer.de> <CAOxmg6tz7BxQwG+4Et91hSQL8x2PDsGS5aF7CQxvMa6MJziNuA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----S9TV56VOAHQ7TGG6IV57W0MCGU3SW7"
Content-Transfer-Encoding: 7bit
To: Sherif Mansour <cherifmansour@gmail.com>
CC: sacm@ietf.org
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <2F5BF86C-9D1C-4C53-BEDD-221A1068988D@sit.fraunhofer.de>
X-Originating-IP: [80.187.112.97]
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/m-czl4L9RBnLVWiyH1WU6n5BXVA>
Subject: Re: [sacm] ECP Architecture Diagram Feedback
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2018 15:34:32 -0000
Correct, but I did not intend to refer to the solutions created by I2NSF WG, but only the small building block that is the ECA model used in some of them. Another example of a WG exploring the application of the ECA model is NETCONF, I think. I am not able to assess the applicability if BDD ad-hoc. That's basically the only reason why I brought up ECA - to get more context :-) Is anyone else on the list familiar or has experience with BDD. Viele Grüße, Henk On April 10, 2018 4:41:23 PM GMT+02:00, Sherif Mansour <cherifmansour@gmail.com> wrote: >Hi Henk, > >Correct me if I am wrong but i2nsf focuses on Network Security Function >correct? > >If so, the second difference, is easy of adoption. > >Many developers already know BDD so you can hire for that and there is >already a lot of code done for mapping many testing functionality, >including for security: >https://www.continuumsecurity.net/bdd-security/ >Finally, its simple & battle tested. > >If i2nsf fits the bill then fine, I appreciate I am also late in the >game >on this one, but it looks like it is one step removed from a DSL. > >All I can tell you is I do see people writing BDD test scenarios as the >set >of tests they use to execute on their security requirements, and it >looks >like a logocal extension to what QA engineering peers have been doing. > >-Sherif > >On Tue, 10 Apr 2018 at 3:24 pm, Henk Birkholz < >henk.birkholz@sit.fraunhofer.de> wrote: > >> Hello Sharif, >> >> On 04/10/2018 03:46 PM, Sherif Mansour wrote: >> > Thanks Henk, >> > >> > I have provided some feedback inline. >> > >> > I would also recommend the group look at what the develoment >comunity >> > have done with Behaviour-Driven Development >> > <http://en.wikipedia.org/wiki/Behavior_driven_development> (BDD). I >am >> > seeing more and more security engineers looking how they can >translate >> > individual policy/standard porcedures into test scenarios (this >also >> > challenges GRC folk to only write requirments which are testable), >and >> > then write test Scenarios which are human readable but map to code >under >> > the hood (in our case OVAL/SCAP/Other). >> >> Is there a particular difference - next to the agile'esque stories, >> which is a nice nuance - between the model illustrated by the slides >> (not included in this reply) and the ECA (Event/Condition/Action) >model >> that is used, e.g. in i2nsf? >> >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Apr 10, 2018 at 12:23 PM, Henk Birkholz >> > <henk.birkholz@sit.fraunhofer.de >> > <mailto:henk.birkholz@sit.fraunhofer.de>> wrote: >> > >> > Hello Sherif, >> > >> > I assume that only the "gray" upper part of your diagram is a >flow >> > chart and the blocks in the lower part compose a workflow of >data on >> > the data plane between components? Is that correct? >> > >> > well.. it was late at night so forgive me the upper grey area is a >> > simple SDLC cycbe so it is a flow chart. The rest is an >architecrure >> > diagram of SACM with the green parts are what I can see have been >taken >> > into account, but the other colored areas are ones that I do not >see, >> > but might be relevant in the over all eco-system. >> >> If the rest of the diagram is an architecture diagram of SACM, I have >> not seen that one before. It seems to be an instantiation or mapping >of >> the architecture to me, but I might be missing something obvious >here. >> >> > >> > >> > If so, the workflow illustrated can be mapped to the current >(and in >> > this case also the original/generic) SACM architecture. The >> > dedicated data flows depicted (again, assuming that the black >arrows >> > in the lower part of the diagram are somehow data flows - >although >> > the direction of arrows seems to contradict that assumption at >some >> > points) between green boxes would be mapped to an n-2-m message >> > distribution system (e.g. a message broker, message bus, >> > multi-client pub/sub) using the common SACM data and >interaction >> model. >> > >> > Arrows from boxes "not green", e.g. "pink" and "orange" boxes, >would >> > be covered by SACM components with the collector (or reporter) >role, >> > using existing open or proprietary transfer methods (or also >the >> > common SACM data and interaction model, if applicable). >> > >> > I would avoid making assumptions that they would be done if not >> > explictly stated, specifically inventory is key. If you do not have >a >> > good inventory you may not be securing all the assets you need to. >> >> The SACM WG is not prescriptive on how to design a repository >internally >> or how to model data at rest respectively, I think. In consequence, >the >> representation of information provided by a repository in combination >> with the representation of its set of operations are (I am not 100% >with >> the latter, others might provide better answers here) the >capabilities a >> repository propagates via registration (on the control plane) - and >> therefore, the only indicators you can assess by, if an "inventory" >is >> "good" wrt to your domain of application. >> >> If, for example, your domain requires a relational database, with a >> specific data base schema, and a specific structured query language, >> that is fine, but you need a SACM component to interface with that >> "non-SACM" protocol in order to make the information available to the >> SACM domain, or at least register that Interface and its Capabilities >> via a minimal SACM Component that handles registration on the control >> plane - in order to broker that interface capability to SACM >components >> that can query the database interface natively (and appropriately, >e.g. >> via a imperative guidance repo). >> >> > >> > >> > Orange arrows would either be brokered peer-2-peer data flows >that >> > do not use the common SACM data and interaction model, or the >> > external ("not green") components would have to be enrolled >with >> > appropriate imperative guidance via methods that are out of >scope >> > (e.g. manually) to communicate with green boxes (SACM >components) >> > via orange arrows (not the common SACM data and interaction >model). >> > >> > I do not know if right now it is possible to map a finding from say >a >> > vulnerability scanner to a specific patch easily. The idea behind >this >> > part of the diagram is to ensure that the fix is mapped to the >> > vulnerability/finding in the collector and the orchatrator can >> > deploy/schedule the fix >> >> It is. The SACM information model incorporates explicit references >> between Content Element Subjects via the Relationship Information >> Element. At the moment, the Relationship IE is an enumeration of >> relationship types, but as the IM is still under development, >feedback >> and contributions are welcome. >> >> > >> > >> > In most scenarios (approx. everything larger than the S in SME, >for >> > example), would probably use more than one "Repo", I assume. >> > >> > Yes, and in some cases there is not repo (think mis-configureation >and >> > the "Fix" might be a custom script). >> >> Agreed, but that has to be handled by a SACM component in a feasible >> way. I think this is a gap that has no corresponding proposed >approach >> at the moment. >> >> > >> > >> > >> > Some exemplary mapping: >> > >> > "We know the assets I need to account for." -> TE Repo >> > "We are performing the necessary security assessments." -> >Evaluator >> > requiring a specific Imperative Guidance Repo (OVAL and the >> > Vulnerability Assessment Scenario evolving from it might >provide a >> > more specific repo component name already) >> > "We are scouring the findings based on risk." -> Another >Evaluator >> > requiring another specific Imperative Guidance Repo. >> > "We are reporting the issues..." -> this would be a specific >SACM >> > Report component, or a TE Characterization Repo >> > >> > Remediation is not a target of our current phase. >> > >> > About the things we might need: >> > >> > "A data model that can map a finding/vulnerability to a fix >> > (patch/config change etc..)." -> I think we are working to >provide >> > the basis for exactly that (amongst other goals) >> > >> > "An automated process for detection" -> which would be the >> > evaluation task (or a conditional concatenation of multiple, >staged >> > evaluation tasks) >> > >> > This is easy in static assets, but ephemoral hosts are a challenge, >this >> > is when the running workloads do not need to be fixed you need to >map >> > them back to the source image then fix the image spin the workloads >down >> > and spin up new workloads with the updated image. >> >> Association of running software instance (process tag) to software >> package (payload/evidence tag) to installation package (corpus tag) >is >> in the domain of software identifier tags, I think. If there is a gap >> there that is important to your usage scenario, feedback and >> contributions are very welcome! >> >> Also, this is where Target Endpoint Characterization Records come >into >> play. The concept is tailored to deal with changing, "un-owned", >> unknown, or ephemeral target endpoints. Basically the Target >Endpoints >> on the other end of the spectrum of ECP, I think (which are well >known, >> and have a "nea collector" (sorry for oversimplifying! residing on >them). >> >> > >> > >> > "An automated process for fixing issues" -> which will be a >future >> > goal in a future phase (please correct me, if I am telling >fairy >> > tales here) >> > >> > "An orchestration system to provide tech teams with the ability >to >> > automatically detect and fix when and where it makes sense." -> >the >> > composite that is a SACM Domain per se provides a distributed >> > orchestration capability by itself. As per comment above, at >some >> > point a dedicated orchestrator is probably required to make >best use >> > of resources and avoid bottlenecks in the data flow between >> > components (or detect attacks that try to "play the system >itself"). >> > >> > >> > >> >> >> Viele Grüße, >> >> Henk >> >> >> >> >> > >> > >> > >> > >> > >> > >> > On 04/10/2018 01:11 AM, Sherif Mansour wrote: >> > >> > Thanks Henk, >> > >> > The image below should help explain where I am going with >this >> > (I hope). The green blocks are what I think are covered by >SACM, >> > the over all eco-system has a few more players that I have >> > colored differently. Its easier to walkthrough via the >phone. >> > >> > However I think this can be simplified by the follwing >story: >> > >> > As a technology team, we want to be able to detect all >security >> > findings on our endpoints/enviroment and rate each finding >based >> > on the risk so that we can remediate the fidnings in a >> > prioritiesed and timely fashion before they are exploited >by an >> > adversary. >> > >> > This in turn means: >> > >> > * We know the assets I need to account for. Hence the >> > Reference Data >> > * We are performing the neccsary security assesments. >Hence >> the >> > Security tools >> > * We are socuring the findings based on risk. Hence Repo >> > (missed the >> > evaluator in the diagram apologies). >> > * We are reporting the issues to the right people at the >> > right time. >> > Hence the reporting system & bug tracker integration >(some >> tech >> > teams would want the data into their reporting systems >to >> > action). >> > * We have a recommandations/guidance on how to fix those >> issues. >> > >> > If we think of the ideal future state, we would not want to >slow >> > tech team members down. We would want to get to the minimum >> > ammount of time between discovering an issue and >remediating it >> > hence self healing. >> > >> > We would need a few things: >> > >> > * A data model that can map a finding/vulnerability to a >fix >> > (patch/config change etc..). >> > * An automated process for detection >> > * An automated process for fixing issues >> > * An orchstration sytem to provide tech teams with the >> ability to >> > automaticically detect and fix when and where it makes >> sense. >> > >> > Hope this helps >> > >> > >> > >> > -Sherif >> > >> > >> > >> > On Mon, Apr 9, 2018 at 5:19 PM, Henk Birkholz >> > <henk.birkholz@sit.fraunhofer.de >> > <mailto:henk.birkholz@sit.fraunhofer.de> >> > <mailto:henk.birkholz@sit.fraunhofer.de >> > <mailto:henk.birkholz@sit.fraunhofer.de>>> wrote: >> > >> > Hi all, >> > >> > well, it is both. You don not necessarily need an >> > orchestrator, if >> > every SACM component can discover and provide IE by >itself >> > and each >> > SACM component is enrolled with or can always discover >its >> > intended >> > imperative guidance. At a given scale this can become >very >> > confusing >> > and bottlenecks can arise. Hence, using (again >scalable >> > mesh) of >> > orchestrators seems a good approach :) >> > >> > If an external entity (I think this is Jenkins in the >> > example below, >> > a user outside the SACM domain) wants to trigger a >workflow >> of >> > tasks, we need an "external" interface. In fact, this >can >> > be the >> > same type of interface that is used between SACM >> > components, but it >> > must not necessarily. In fact, there might be good >reasons >> > fot it >> > not to be the same kind of protocol/API/interaction >model, >> but >> > again, it may most certainly be the same. >> > >> > An Orchestrator, as a minimum, takes on the control >plane >> > function >> > of instantiating SACM tasks on specific SACM >components - >> > on behalf >> > of triggers (or actually, events) that are created by >a SACM >> > component or an external entity. The frequency of sets >of >> > actions >> > (instantiated tasks) in SACM ranges from ad-hoc, to >> > conditional, >> > scheduled, and continuously. >> > >> > Viele Grüße, >> > >> > Henk >> > >> > On 04/09/2018 05:05 PM, Sherif Mansour wrote: >> > >> > Hi Dan, >> > Let me respond later this evening, I am also happy >to >> > call if >> > you have a minute. >> > >> > On Mon, 9 Apr 2018 at 3:48 pm, Haynes Jr., Dan >> > <dhaynes@mitre.org <mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>> >> > <mailto:dhaynes@mitre.org ><mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>>> >wrote: >> > >> > Thanks for the clarification Sherif!____ >> > >> > __ __ >> > >> > So, it sounds like beyond just a pub/sub >interface >> for >> > communicating >> > with other components, you want it to also be >able >> to >> > manage jobs >> > among other things. Does the list of current >SACM >> > tasks >> > (collection, >> > endpoint characterization, endpoint >> > classification, evaluation) >> > sound like the jobs you would want it to >manage? >> > The SACM >> > tasks are >> > defined here >> > >> > ( >> >https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md).____ >> > < >> >https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md).____ >> > >> > >> > < >> >https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md).____ >> > < >> >https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md).____ >> >> >> > >> > __ __ >> > >> > Are there other capabilities that you would >> > specifically >> > like to see >> > in the orchestrator?____ >> > >> > __ __ >> > >> > Also, how do others envision the orchestrator >> > working?____ >> > >> > __ __ >> > >> > Thanks, >> > >> > Danny____ >> > >> > __ __ >> > >> > *From:* Sherif Mansour >> > [mailto:cherifmansour@gmail.com ><mailto:cherifmansour@gmail.com> >> > <mailto:cherifmansour@gmail.com >> > <mailto:cherifmansour@gmail.com>> >> > <mailto:cherifmansour@gmail.com >> > <mailto:cherifmansour@gmail.com> >> > <mailto:cherifmansour@gmail.com >> > <mailto:cherifmansour@gmail.com>>>] >> > >> > *Sent:* Saturday, April 07, 2018 6:18 AM >> > >> > >> > *To:* Haynes Jr., Dan <dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org ><mailto:dhaynes@mitre.org>> >> > <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org ><mailto:dhaynes@mitre.org>>>> >> > *Cc:* Montville, Adam W >> > <adam.w.montville@gmail.com ><mailto:adam.w.montville@gmail.com> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com>> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com>>>>; sacm@ietf.org >> > <mailto:sacm@ietf.org> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org>> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org>>> >> > >> > *Subject:* Re: [sacm] ECP Architecture >Diagram >> > Feedback____ >> > >> > __ __ >> > >> > In a devops model, you generally want to move >from >> > “the >> > team that >> > does stuff for other people” to “the team >that >> builds >> > capabilities >> > for others”.____ >> > >> > __ __ >> > >> > In that case, stage-1 might look a little >> > different. You >> > would start >> > with the Orchastrator. So there would be a >Jenkins >> > job the >> > fires, >> > hits the orchestrator, asks it to check a few >end >> > points, >> > reads the >> > results than makes an informed decision. >There are >> > several >> > use cases >> > for self service testing the main one right >is to >> > make sure end >> > points have been hardened and there sre >currently >> > no known show >> > stopers before the assets “hits the factory >> > floor”. ____ >> > >> > __ __ >> > >> > Ideally we want to get to a stage of self >healing. >> > ____ >> > >> > __ __ >> > >> > Where a dev/sysadmin/other would ping the >> > orchestrator to >> > check an >> > asset(s) identify issues, if those issues are >> > mapped to >> > specific >> > “fixes” then the customer is also given the >option >> to >> > automagically >> > schedule a patch/fix.____ >> > >> > __ __ >> > >> > All this means that the interface between the >> > orchestrator and >> > external parties needs to be thought out. The >main >> > value of the >> > orchestrator is vendor independent management >and >> > self service >> > automation.____ >> > >> > __ __ >> > >> > On Wed, 4 Apr 2018 at 9:12 pm, Haynes Jr., >Dan >> > <dhaynes@mitre.org <mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>> >> > <mailto:dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org> <mailto:dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org>>>> >> > >> > wrote:____ >> > >> > Hi Sherif,____ >> > >> > ____ >> > >> > I think as long as we have standardized >> > interfaces whether >> > directly (posture manager <-> repository, >> > evaluator <–> >> > repository) or indirectly through the >> > orchestrator, we >> > should be >> > able to swap posture managers in and out. >One >> > concern >> > is that I >> > am not sure we want to require an >orchestrator >> > in order >> > to store >> > information in the repository as the >> > repository may be >> > co-located with the posture manager or >the >> > orchestrator >> > may be >> > unnecessary for smaller or more limited >> > networks. By >> > keeping the >> > components as-is with both direct and >indirect >> > interfaces, the >> > architecture of the solution can be >arranged >> in a >> > manner that >> > best supports the needs of the >organization. >> One >> > approach that >> > might help is if we break out the diagram >into >> > different stages.____ >> > >> > ____ >> > >> > Stage 1 – Reporting endpoint information >to the >> > repository via >> > the server. Note: the repository may be >> > co-located with >> > posture >> > manager on the server.____ >> > >> > ____ >> > >> > Posture Manager >> > Endpoint____ >> > >> > +---------------+ >> > +---------------+____ >> > >> > | | >> > | |____ >> > >> > | +-----------+ | >| >> > +-----------+ |____ >> > >> > | | Posture | | >| | >> > Posture | |____ >> > >> > | | Validator | | >| | >> > Collector >> > | |____ >> > >> > | +-----------+ | >| >> > +-----------+ |____ >> > >> > | | | >| >> > | |____ >> > >> > | | | >| >> > | |____ >> > >> > Repository | | | >| >> > | |____ >> > >> > +--------+ | +-----------+ >|<-------| >> > +-----------+ |____ >> > >> > | | | | Posture | | report >| | >> > Posture | |____ >> > >> > | | | | Collection| | >| | >> > Collection| |____ >> > >> > | |<-----| | Manager | | >| | >> > Engine | |____ >> > >> > | | store| +-----------+ | >| >> > +-----------+ |____ >> > >> > | | | | >> > | |____ >> > >> > | | | | >> > | |____ >> > >> > +--------+ +---------------+ >> > +---------------+____ >> > >> > ____ >> > >> > Stage 2 - Evaluator queries information >from >> the >> > repository. If >> > needed, the evaluator queries the >endpoint for >> > information via >> > the posture manager.____ >> > >> > ____ >> > >> > Posture Manager Endpoint____ >> > >> > +---------------+ +---------------+____ >> > >> > | >> > | | |____ >> > >> > | +-----------+ | | +-----------+ |____ >> > >> > | | Posture | | | | Posture | |____ >> > >> > | | Validator | | | | Collector | |____ >> > >> > | +-----------+ | | +-----------+ |____ >> > >> > | | | | | |____ >> > >> > | | | | | |____ >> > >> > Evaluator Repository | | >> > | | | |____ >> > >> > +------+ +--------+ | >+-----------+ >> > |<-------| +-----------+ |____ >> > >> > | | | | | | >Posture >> | | >> > report | | Posture | |____ >> > >> > | | | | | | >Collection| >> > | | | Collection| |____ >> > >> > | |<-----> | |<-----| | >Manager >> | | >> > query | | Engine | |____ >> > >> > | |request/| | store| >+-----------+ >> > |------->| +-----------+ |____ >> > >> > | |respond | | | >> > | | |____ >> > >> > | | | | | >> > | | |____ >> > >> > +------+ +--------+ >> > +---------------+ +---------------+____ >> > >> > ____ >> > >> > Stage 3 – Evaluator, repository, and >posture >> > manager >> > sharing >> > information via the orchestrator.____ >> > >> > ____ >> > >> > Orchestrator____ >> > >> > >> > +-----------------------------------------------+____ >> > >> > | |____ >> > >> > | |____ >> > >> > >> > +-----------------------------------------------+____ >> > >> > ^ ^ >^____ >> > >> > |pub/sub |pub/sub >> > |pub/sub____ >> > >> > | | >|____ >> > >> > | | >|____ >> > >> > | | >v____ >> > >> > | | >Posture >> > Manager Endpoint____ >> > >> > | | >> > +---------------+ +---------------+____ >> > >> > | | | >> > | | |____ >> > >> > | | | >> +-----------+ >> > | | +-----------+ |____ >> > >> > | | | | >Posture >> | >> > | | | Posture | |____ >> > >> > | | | | >Validator >> | >> > | | | Collector | |____ >> > >> > | | | >> +-----------+ >> > | | +-----------+ |____ >> > >> > | | | | >> > | | | |____ >> > >> > v v | | >> > | | | |____ >> > >> > Evaluator Repository | | >> > | | | |____ >> > >> > +------+ +--------+ | >+-----------+ >> > |<-------| +-----------+ |____ >> > >> > | | | | | | >Posture >> | | >> > report | | Posture | |____ >> > >> > | | | | | | >Collection| >> > | | | Collection| |____ >> > >> > | | | | | | >Manager >> | | >> > query | | Engine | |____ >> > >> > | | | | | >+-----------+ >> > |------->| +-----------+ |____ >> > >> > | | | | | >> > | | |____ >> > >> > | | | | | >> > | | |____ >> > >> > +------+ +--------+ >> > +---------------+ +---------------+____ >> > >> > ____ >> > >> > Regarding the invisible box of reference >data, >> > yes, the >> > repository would support it. I don’t >believe >> > there is >> > anything >> > in the draft that prevents that type of >data >> > form being >> > stored. ____ >> > >> > ____ >> > >> > Also, I agree that there should be an >> > interface between the >> > out-of-scope reporting system and the >> > repository. This will >> > eventually be supported by the interface >that >> > we create for >> > accessing the repository.____ >> > >> > ____ >> > >> > Lastly, can you provide more information >on >> > how you see >> > this >> > integrating into the DevOps model?____ >> > >> > ____ >> > >> > Thanks, >> > >> > Danny____ >> > >> > ____ >> > >> > *From:* Sherif Mansour >> > [mailto:cherifmansour@gmail.com ><mailto:cherifmansour@gmail.com> >> > <mailto:cherifmansour@gmail.com >> > <mailto:cherifmansour@gmail.com>> >> > <mailto:cherifmansour@gmail.com >> > <mailto:cherifmansour@gmail.com> >> > <mailto:cherifmansour@gmail.com >> > <mailto:cherifmansour@gmail.com>>>] >> > *Sent:* Tuesday, April 03, 2018 5:36 >PM____ >> > >> > >> > *To:* Haynes Jr., Dan <dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org ><mailto:dhaynes@mitre.org>> >> > <mailto:dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org> <mailto:dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org>>>>____ >> > >> > *Cc:* Montville, Adam W >> > <adam.w.montville@gmail.com ><mailto:adam.w.montville@gmail.com> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com>> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com>>>>; sacm@ietf.org >> > <mailto:sacm@ietf.org> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org>> >> > <mailto:sacm@ietf.org ><mailto:sacm@ietf.org> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org>>>____ >> > >> > >> > >> > *Subject:* Re: [sacm] ECP Architecture >Diagram >> > Feedback____ >> > >> > ____ >> > >> > Hi Danny,____ >> > >> > I would recommend that the Orchestrator >sits >> > between >> > the posture >> > manager and repository. This is for a few >> > reasons, some >> > tactical >> > and some strategic:____ >> > >> > * Strategically (Long term), it allows >you >> > to switch >> > between >> > posture managers without having to do >much >> > (if any) >> > changes >> > on the repository, in their all it >means >> > is it will be >> > pulling data through the orchatrator, >it >> just >> > happens to be >> > from a different tool.____ >> > * Tactically (short term), is is >because >> these >> > connections >> > currently do not exist, so if you >have >> > many posture >> > managers >> > you need to develop different >integration >> in >> > several areas >> > (one connection for the orchestrator >& >> > repository). By >> > leveraging the orchastrator, you only >need >> to >> > create a singe >> > integration with the posture manager, >it >> > simply >> > just needs >> > more features (i.e. the ability to >pull >> > security >> > end point >> > findings, both in raw vendor specific >data >> > or in a >> > uniform >> > agreed data model).____ >> > >> > The second point is that there are a few >> > "invisible" >> > boxes. The >> > first is reference data, a lot of the >> > repository data >> > would be >> > enriched with information that is >specific to >> the >> > organization >> > such as the team which owns specific >assets or >> the >> > context to >> > which they are used. Now, on thing that >is out >> > of scope >> > is the >> > reporting, I am aware this is out of >scope, >> but an >> > organisation >> > has not moved the needle in terms of >security >> > if they have >> > detected security issues but not resolved >> > them. It is >> > therefore >> > natural that there is an interface >somewhere >> > between the >> > repository and a reporting system. __ __ >> > >> > Finally one key benefit of the >orchestrator is >> > automation and >> > self service, there for an interface to >allow >> > it to >> > work in a >> > devops model would also increase its >value, if >> the >> > interface can >> > (easily) integrate with Jenkins/Bamboo, >or >> > chef recipes / >> > Ansible playbooks, this would go a long >way for >> > adoption.____ >> > >> > -Sherif____ >> > >> > ____ >> > >> > ____ >> > >> > ____ >> > >> > ____ >> > >> > On Tue, Apr 3, 2018 at 7:36 PM, Haynes >Jr., Dan >> > <dhaynes@mitre.org ><mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>> >> > <mailto:dhaynes@mitre.org ><mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>>> >> wrote:____ >> > >> > >> > Hi Adam,____ >> > >> > ____ >> > >> > I hope it was a good trip out there >and >> > that you >> > were able >> > to see some of the sights!____ >> > >> > ____ >> > >> > As far as scoping and the diagram, I >think >> > it’s worth >> > nothing that all the components in it >are >> > in scope >> > for ECP. >> > It is just a matter of when we >actually >> > get to creating >> > drafts for them (if that makes any >sense). >> > I think >> > what you >> > are looking for is a diagram that >shows >> > what we are >> > currently working on? Or, maybe I am >> > misunderstanding your >> > comments?____ >> > >> > ____ >> > >> > Thanks, >> > >> > Danny ____ >> > >> > ____ >> > >> > *From:* Adam Montville >> > [mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com>> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com> >> > <mailto:adam.w.montville@gmail.com >> > <mailto:adam.w.montville@gmail.com>>>] >> > *Sent:* Monday, April 02, 2018 3:33 >PM >> > *To:* Haynes Jr., Dan ><dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org ><mailto:dhaynes@mitre.org>> >> > <mailto:dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org> <mailto:dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org>>>> >> > *Cc:* sacm@ietf.org ><mailto:sacm@ietf.org> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org>> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org> >> > <mailto:sacm@ietf.org <mailto:sacm@ietf.org>>> >> > >> > *Subject:* Re: [sacm] ECP >Architecture >> Diagram >> > Feedback____ >> > >> > ____ >> > >> > Hi Danny,____ >> > >> > ____ >> > >> > We missed you in London. I think the >> > diagram is ok, >> > but I do >> > have scoping questions (just sent to >the >> list) >> > which may >> > suggest some modification to the >diagram >> once >> > resolved. If >> > the way I'm interpreting the ECP >draft at >> > this point is >> > close to accurate, then it might be a >good >> > idea to >> > add a >> > horizontal scoping line between the >left >> > hand and >> > the right >> > hand of the diagram, where the >posture >> > manager is >> > the first >> > component on the right-hand side. >> > Alternatively, an >> > in-scope >> > boundary box could be drawn around >the >> > appropriate >> > components.____ >> > >> > ____ >> > >> > What really matters is whether the >diagram >> > accurately >> > depicts the intended scope of the >draft >> > from the >> > authors' >> > perspectives, and whether a typical >reader >> > would >> > see it that >> > way.____ >> > >> > ____ >> > >> > Adam____ >> > >> > ____ >> > >> > On Apr 2, 2018, at 1:32 PM, >Haynes >> > Jr., Dan >> > <dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org> <mailto:dhaynes@mitre.org >> > <mailto:dhaynes@mitre.org>> >> > <mailto:dhaynes@mitre.org ><mailto:dhaynes@mitre.org> >> > <mailto:dhaynes@mitre.org <mailto:dhaynes@mitre.org>>>> >> wrote:____ >> > >> > >> > ____ >> > >> > Hi Everyone, >> > >> > At IETF 101, we presented an >updated >> > architecture >> > diagram [1] that was based on >feedback >> > from the >> > September virtual interim [2][3] >and >> was >> > included in the >> > ECP -01 draft [4]. During the >meeting, >> > we did not >> > receive any feedback on the >> architecture >> > diagram.____ >> > >> > ____ >> > >> > As a result, we just wanted to >> > follow-up on the >> > list and >> > see if there was any feedback or >> > objections to the >> > updated ECP architecture diagram >that >> was >> > proposed.____ >> > >> > ____ >> > >> > Thanks, >> > >> > Danny____ >> > >> > ____ >> > >> > ____ >> > >> > >> > [1] >> >https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00(see >> > < >> >https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00(see >> > >> > >> > < >> >https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00(see >> > < >> >https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00(see >> >> >> > slide 4)____ >> > >> > >> > [2] >> >https://datatracker.ietf.org/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see >> > < >> >https://datatracker.ietf.org/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see >> > >> > >> > < >> >https://datatracker.ietf.org/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see >> > < >> >https://datatracker.ietf.org/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see >> >> >> > slide 5)____ >> > >> > >> > [3] >> >https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900-00(see >> > < >> >https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900-00(see >> > >> > >> > < >> >https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900-00(see >> > < >> >https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900-00(see >> >> >> > page 1 and 2)____ >> > >> > >> > >[4]https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____ >> > <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____> >> > >> > <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____ >> > ><https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____>> >> > >> > ____ >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
- [sacm] ECP Architecture Diagram Feedback Haynes Jr., Dan
- Re: [sacm] ECP Architecture Diagram Feedback Adam Montville
- Re: [sacm] ECP Architecture Diagram Feedback Adam Montville
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Haynes Jr., Dan
- Re: [sacm] ECP Architecture Diagram Feedback Adam Montville
- Re: [sacm] ECP Architecture Diagram Feedback Haynes Jr., Dan
- Re: [sacm] ECP Architecture Diagram Feedback Haynes Jr., Dan
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Haynes Jr., Dan
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Henk Birkholz
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Henk Birkholz
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Henk Birkholz
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Henk Birkholz
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Adam Montville
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour
- Re: [sacm] ECP Architecture Diagram Feedback Sherif Mansour