Re: [sacm] ECP Architecture Diagram Feedback

[Sherif Mansour <[e-mail]>]

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]> 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]> 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 <
>> [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> (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]>> 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]>>> 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]>>>> 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:[e-mail] <mailto:cherifmansour@gmail.
>>> com>
>>> >                  <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]
>>> >>>>
>>> >                       *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]>>>>; [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]>>>>
>>> >
>>> >                  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:cherifmansour@gmail.
>>> com>
>>> >                  <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]>>>>____
>>> >
>>> >                           *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]>>>>; [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]>>>>
>>> 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]>>>]
>>> >                               *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]>>>>
>>> >                               *Cc:* [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]>>>>
>>> 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.
>