Re: [sacm] ECP Architecture Diagram Feedback

Its more about the path of least resistance, and a single interface for
external requests like an automated scan that als needs to pull the results
right away. It helps with “singing from a single sheet of music”.

On Wed, 4 Apr 2018 at 2:04 pm, Adam Montville <adam.w.montville@gmail.com>
wrote:

>
> On Apr 3, 2018, at 4:36 PM, Sherif Mansour <cherifmansour@gmail.com>
> wrote:
>
> 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).
>
> Logically, I think I could see this, but in practice it's not always
> applicable. An orchestrator should orchestrate, but not necessarily be
> responsible for data transfer.
>
> The second point is that there are a few "invisible" boxes. The first is
> reference data, a lot of the repository data would be enriched with
> information that is specific to the organization such as the team which
> owns specific assets or the context to which they are used. Now, on thing
> that is out of scope is the reporting, I am aware this is out of scope, but
> an organisation has not moved the needle in terms of security if they have
> detected security issues but not resolved them. It is therefore natural
> that there is an interface somewhere between the repository and a reporting
> system.
>
> Finally one key benefit of the orchestrator is automation and self
> service, there for an interface to allow it to work in a devops model would
> also increase its value, if the interface can (easily) integrate with
> Jenkins/Bamboo, or chef recipes / Ansible playbooks, this would go a long
> way for adoption.
>
> -Sherif
>
>
>
>
>
> On Tue, Apr 3, 2018 at 7:36 PM, Haynes Jr., Dan <dhaynes@mitre.org> wrote:
>
>> Hi Adam,
>>
>>
>>
>> I hope it was a good trip out there and that you were able to see some of
>> the sights!
>>
>>
>>
>> As far as scoping and the diagram, I think it’s worth nothing that all
>> the components in it are in scope for ECP. It is just a matter of when we
>> actually get to creating drafts for them (if that makes any sense). I think
>> what you are looking for is a diagram that shows what we are currently
>> working on? Or, maybe I am misunderstanding your comments?
>>
>>
>>
>> Thanks,
>>
>> Danny
>>
>>
>>
>> *From:* Adam Montville [mailto:adam.w.montville@gmail.com]
>> *Sent:* Monday, April 02, 2018 3:33 PM
>> *To:* Haynes Jr., Dan <dhaynes@mitre.org>
>> *Cc:* sacm@ietf.org
>> *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 <dhaynes@mitre.org> 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
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>>
>>
>> _______________________________________________
>> sacm mailing list
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>>
>