Re: [sacm] ECP Architecture Diagram Feedback

[Adam Montville <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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/ <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 <[e-mail] <mailto:[e-mail]>> 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 <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
> > <[e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>> 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
> >         <[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>> 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
> >                  <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>> 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).____>>
> >
> >         <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:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>
> >                       <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>]
> >
> >                       *Sent:* Saturday, April 07, 2018 6:18 AM
> >
> >
> >                       *To:* Haynes Jr., Dan <[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>>
> >                       *Cc:* Montville, Adam W
> >         <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>
> >                       <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>>; [e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                       <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>
> >
> >                       *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
> >                  <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                       <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>>
> >
> >                  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:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>
> >                           <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>]
> >                           *Sent:* Tuesday, April 03, 2018 5:36 PM____
> >
> >
> >                           *To:* Haynes Jr., Dan <[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                           <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>>____
> >
> >                           *Cc:* Montville, Adam W
> >         <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>
> >                           <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>>; [e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                           <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>____
> >
> >
> >
> >                           *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
> >                           <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>> 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:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>
> >                               <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>]
> >                               *Sent:* Monday, April 02, 2018 3:33 PM
> >                               *To:* Haynes Jr., Dan <[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                               <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>>>
> >                               *Cc:* [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>
> >
> >                               *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
> >                                   <[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>>
> >                  <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >         <mailto:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>>> 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>>
> >
> >         <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>>
> >
> >         <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>>
> >
> >         <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/____>>
> >
> >         <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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm