Re: [sacm] ECP Architecture Diagram Feedback
Sherif Mansour <cherifmansour@gmail.com> Tue, 10 April 2018 15:40 UTC
Return-Path: <cherifmansour@gmail.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FD5129C6A for <sacm@ietfa.amsl.com>; Tue, 10 Apr 2018 08:40:50 -0700 (PDT)
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 TcmP8SHIew71 for <sacm@ietfa.amsl.com>; Tue, 10 Apr 2018 08:40:43 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 A94BB126DED for <sacm@ietf.org>; Tue, 10 Apr 2018 08:40:42 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id r19so7270533vkf.4 for <sacm@ietf.org>; Tue, 10 Apr 2018 08:40:42 -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=4bQ6y0Ml/wB0yLtyNyLKxNtD5mWWBohnJDSBuXSBvYA=; b=gFqu33gj1o5FSBrRYizFgFC8+lda7+SeG1pyBSezt6P5zY152OLuGkHMxMygqkrJ/G hoYm7JbESmoxSbE3bNSPVDz4NNf84B9ZnWPsVPHS+N+C9E/ZoE8DBaaruGWaG0xsQC4I /0r8HWG8hH1yk7W2oMtYouLJDv+e3Gfhhq8B8cNwF7qVMQHV3vHMUmSpFG7ltBkBLk5S /SbkjkFTrWsTOyC5OXRubQ7LdP73HAZwXiU885sn4Oi6kRb4aMDV+pFpKh70WDAHKh9E aIX0TXgk5bdSBEhkO3JBUI8tYFuUb5MW7HfD0+vVMhP7w+srdPvPziQ8Nkedga8WFw1K NmUQ==
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=4bQ6y0Ml/wB0yLtyNyLKxNtD5mWWBohnJDSBuXSBvYA=; b=YMstrY+yyZHU9zUH/xM3Y77U/n/gk5mIjW5GSNW4SBkPIM2RKr/2v1nSJQYymyFMzy 2jWl8PLwKbCeY9BGblPC8aQA+8NJEMVWpPQCoySRMuFQqDq3FQdK5ZS3u7WRiPvHp7R/ 4F67odAsCgXHDnnrvf3TS9PKBqR29VtjG3orqv/MfJZu0CjKZ9tdR8OPcJeQ+1aG80IT hZW2dLVH1fJC85SHoPjGji4ziG0BmbReNvpSlpB0x0zlvAaQjT0b9xxRDOHHL6XBkti6 t1tfcSWqUhL2z1caXVVYc396LpKMpxpIT17QjTRzo+lwJ+PSN/893x8sR+eV/SJ9V8Oe qgqQ==
X-Gm-Message-State: ALQs6tCYA25mr4aZFErT38Oi2vjC+ZW/8P4LH55ikDLpJYzSabDXus5q jDKSIo+yIF0fDpn4FyeZ8yfZB2u80jVUbz0/QDYQxg==
X-Google-Smtp-Source: AIpwx4/4Q+QPhtTSKuzXbhypqindpdlAH9om8lJXhjWv/zhLGUuOrBpQAnwVwg836OCECtSkSObZ7TIGTfI03R8VGwM=
X-Received: by 10.31.44.193 with SMTP id s184mr719413vks.147.1523374841424; Tue, 10 Apr 2018 08:40:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.219.24 with HTTP; Tue, 10 Apr 2018 08:40:40 -0700 (PDT)
In-Reply-To: <2F5BF86C-9D1C-4C53-BEDD-221A1068988D@sit.fraunhofer.de>
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> <2F5BF86C-9D1C-4C53-BEDD-221A1068988D@sit.fraunhofer.de>
From: Sherif Mansour <cherifmansour@gmail.com>
Date: Tue, 10 Apr 2018 16:40:40 +0100
Message-ID: <CAOxmg6tOhfNETpperEjjtcsYgim-k73Ky3i3=ru1WWf1Zxm4=g@mail.gmail.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: sacm@ietf.org
Content-Type: multipart/alternative; boundary="001a11425ce4489cb505698058aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/ZRNGuPbCSspl4cMFpUuZVnyG5ko>
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:40:51 -0000
Ok so....what's next? :-) Hey Dan, 27 emails into this thread I assume you have enough feedback? Are there any other next steps? e.g. research BDD as a potential Domain Specific Language (DSL)? -Sherif On Tue, Apr 10, 2018 at 4:34 PM, Henk Birkholz < henk.birkholz@sit.fraunhofer.de> wrote: > 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