Re: [sacm] ECP Architecture Diagram Feedback

[Henk Birkholz <[e-mail]>]

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