Re: [sacm] ECP Architecture Diagram Feedback
Sherif Mansour <cherifmansour@gmail.com> Tue, 02 October 2018 15:23 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 E7294130EB9 for <sacm@ietfa.amsl.com>; Tue, 2 Oct 2018 08:23:58 -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 VhKU56W12CiN for <sacm@ietfa.amsl.com>; Tue, 2 Oct 2018 08:23:52 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 A98F2130E16 for <sacm@ietf.org>; Tue, 2 Oct 2018 08:23:51 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id q19-v6so2473104edr.1 for <sacm@ietf.org>; Tue, 02 Oct 2018 08:23:51 -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 :cc; bh=i+FN9INC7ePhRUnBIQF07bK+maVZ+jqbYN64kg1lO8g=; b=P9wENuVk5pK3SDQNozh9uU2dwQEPDViF199DIc/DALZq2FRy2iKPcSdnB/++b0tgqz mi9Gv3Uj1Fkb7dqpx7Gr/3590dHqEEjl3+bQfymumQmz2juiP744sCSRU7EMBpQ86azi LairYpGX+1sQYhqVdeThdkZKN6yQRPWnPAHHJ0dhElYWdV1GoIwsQM23LYZfuVQX7LrG GyGHmoQo5B6e2lLN7hyQx+OuvlYSM7qHGMHDx6Q6foXICJfIUPilAlSRrl4aF5+1S/Xf ZAsG5ck53NCPCVtyutolu0QhGpSLyT0OlKGLkIKSt2IeyXyVUG5KODbx1M3eMfG2j/fR RzGw==
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=i+FN9INC7ePhRUnBIQF07bK+maVZ+jqbYN64kg1lO8g=; b=K6Ld/wHM9ClyslRBJl1GLU1G8X5EU+ihHj9SnBl7P2vPH6gXvlTtJCmQbi2KGI/A39 qVRHFQSwV/kH5F7wvynDpUVBfK6Fg7vGgiJU/D8icQ1/a85FF5Lr2BKNehSaimEaRWmG 0kYv/lAfUjqeqY0TD42StV8WGNa4WgVtt5LsfrTrn/UnlEKtbe7jQoSjnqWemiChG0YL G7X+a/91elXNYJx2JCPc9Xm+2x2lqKY7wvmgONe5X50uZDW0ntBLUAUeQZDOlRbR5ll8 x9bOxJomtAgD0r/U2HQGHHRmIcGFLpbIEaAfnNySOpr6KdmaTSb2dT/e3ofieAyTl4dH CJ+g==
X-Gm-Message-State: ABuFfogDxnbxA4vB1Cap7wPGZHpplZ8NeCrhncA1NdSxLHtOsKezRGhP Ewsea1fGYqrEUVJKAahEXx3B1nrc6C+pC83qfqM=
X-Google-Smtp-Source: ACcGV60s3GxyR/lS7jX44Ex/bZ7qEkDUtN8TCnJS6frxQb2+bNSgZ4uyALelcfNNAYSUc/zILL9j18+Rdqi5q4copCo=
X-Received: by 2002:a50:cb03:: with SMTP id g3-v6mr4048488edi.287.1538493829898; Tue, 02 Oct 2018 08:23:49 -0700 (PDT)
MIME-Version: 1.0
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> <CAOxmg6tOhfNETpperEjjtcsYgim-k73Ky3i3=ru1WWf1Zxm4=g@mail.gmail.com> <F9C00CAC-734F-4913-8AE4-3691051874FC@gmail.com> <CAOxmg6uBRX8rHB3Ti0Fcu+61+9QSW=gBVXySNGXh2A=ErPg2nQ@mail.gmail.com>
In-Reply-To: <CAOxmg6uBRX8rHB3Ti0Fcu+61+9QSW=gBVXySNGXh2A=ErPg2nQ@mail.gmail.com>
From: Sherif Mansour <cherifmansour@gmail.com>
Date: Tue, 02 Oct 2018 17:23:37 +0200
Message-ID: <CAOxmg6vByhROaouyVv-na2VDLPTBeBiwDOdTcH2+5iPRjORMRg@mail.gmail.com>
To: Adam Montville <adam.w.montville@gmail.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, sacm@ietf.org
Content-Type: multipart/alternative; boundary="00000000000038686f0577408272"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/zUyqCHUgiIPez4RQDse5B-b0PZo>
Subject: Re: [sacm] ECP Architecture Diagram Feedback
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Oct 2018 15:23:59 -0000
Picking up this thread again - so a few months go by and now I am more proficient in some data science tech such as property graphs and Apache Spark. I also have a few weeks of downtime so I would like to see if I can create a DSL on top of Spark (which also supports graph objects) similar to what Henk noted (ECA) for infosec activity. Mainly to write heuristic rules, let’s see what comes out of it. On Thu, 26 Apr 2018 at 11:26 am, Sherif Mansour <cherifmansour@gmail.com> wrote: > Yeah, I actually spoke to Expedia about this yesterday and they DevOps > teams ears perked. > They have an automation platform called Flyte > https://github.com/HotelsDotCom/flyte/blob/master/README.md > So they might place BDD test scenarios on top to manage security > requirements. At least they like the idea, and its also human readable to > an auditor for example. > > On Tue, 24 Apr 2018 at 8:00 pm, Adam Montville <adam.w.montville@gmail.com> > wrote: > >> I like the idea of exploring BDD/DSL types of approaches. Our QA folks do >> this and I've seen other organizations run with this type of thing in the >> past as well. Still, it seems like we need to have something around which >> to define such a DSL... I like the notion of ECA also - we shouldn't >> reinvent the wheel. >> >> >> On Apr 10, 2018, at 10:40 AM, Sherif Mansour <cherifmansour@gmail.com> >> wrote: >> >> 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:sac <sacm@ietf.org> >>>> >>>>
- [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