Re: [sacm] ECP Architecture Diagram Feedback

[Sherif Mansour <[e-mail]>]

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