Subject: [sacm] ECP Architecture Diagram Feedback

From: "Haynes Jr., Dan" <[email-masked]>
Date: Mon, 2 Apr 2018 18:32:28 +0000

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/

---

From: Adam Montville <[email-masked]>
Date: Mon, 2 Apr 2018 14:32:34 -0500

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 <[email-masked]> wrote:
> 
> Hi Everyone,
> 
> [1] https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00 <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/ <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 <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/>
>  
> _______________________________________________
> sacm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Tue, 3 Apr 2018 18:36:58 +0000

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:[email-masked]]
Sent: Monday, April 02, 2018 3:33 PM
To: Haynes Jr., Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] ECP Architecture Diagram Feedback

Hi Danny,

Adam

On Apr 2, 2018, at 1:32 PM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Everyone,

Thanks,

Danny

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Sherif Mansour <[email-masked]>
Date: Tue, 3 Apr 2018 22:36:01 +0100

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 <[email-masked]> wrote:

> 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:[email-masked]]
> *Sent:* Monday, April 02, 2018 3:33 PM
> *To:* Haynes Jr., Dan <[email-masked]>
> *Cc:* [email-masked]
> *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
>
>
>
> 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)
>
> [3] https://datatracker.ietf.org/meeting/interim-2017-sacm-
> 03/materials/minutes-interim-2017-sacm-03-201709260900-00 (see page 1 and
> 2)
>
> [email-masked]
> [email-masked]

---

From: Adam Montville <[email-masked]>
Date: Wed, 4 Apr 2018 08:00:04 -0500

That helps, Danny, but then my comment about the ECP draft would change. As I read it, I do not take some of those components as being in scope (maybe some requirements for a cooperating component, but not - strictly speaking - in scope for ECP). If components such as the orchestrator and the repository are to be taken as in scope, it feels like that could be made more explicit.

Maybe I'm the only one who sees it this way?

Adam

> On Apr 3, 2018, at 1:36 PM, Haynes Jr., Dan <[email-masked]> wrote:
> 
> Hi Adam,
>  
> 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   
>  
> On Apr 2, 2018, at 1:32 PM, Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Everyone,
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 4 Apr 2018 08:04:18 -0500

> On Apr 3, 2018, at 4:36 PM, Sherif Mansour <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Adam,
> 
>  
> 
> From: Adam Montville [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>

---

From: Sherif Mansour <[email-masked]>
Date: Wed, 04 Apr 2018 13:17:54 +0000

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 <[email-masked]>
wrote:

>    - Tactically (short term), is is because these connections currently
>    do not exist, so if you have many posture managers you need to develop
> 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.
>
> 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
>> 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
>> 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
>>
>>
>>
>> [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)
>>

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Wed, 4 Apr 2018 13:18:08 +0000

Hi Adam,

What type of information are you looking for to make these components more explicit?

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Wednesday, April 04, 2018 9:00 AM
To: Haynes Jr., Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] ECP Architecture Diagram Feedback

Adam

On Apr 3, 2018, at 1:36 PM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Monday, April 02, 2018 3:33 PM
To: Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] ECP Architecture Diagram Feedback

Hi Danny,

Adam

Hi Everyone,

Thanks,

Danny

---

From: Adam Montville <[email-masked]>
Date: Wed, 4 Apr 2018 08:42:15 -0500

> On Apr 4, 2018, at 8:18 AM, Haynes Jr., Dan <[email-masked]> wrote:
> 
> Hi Adam,
>  

On a separate thread, I offered to attempt a scope statement of some kind (as well as helping to trim things back a bit). Let's leave this portion of the conversation in that thread?

> On Apr 3, 2018, at 1:36 PM, Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Adam,
>

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Wed, 4 Apr 2018 14:11:54 +0000

Works for me. I am going through that thread now.

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Wednesday, April 04, 2018 9:42 AM
To: Haynes Jr., Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] ECP Architecture Diagram Feedback

On Apr 4, 2018, at 8:18 AM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

Thanks,

Danny

Adam

Hi Adam,

Thanks,

Danny

Hi Danny,

Adam

Hi Everyone,

Thanks,

Danny

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Wed, 4 Apr 2018 20:12:42 +0000

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:[email-masked]]
Sent: Tuesday, April 03, 2018 5:36 PM
To: Haynes Jr., Dan <[email-masked]>
Cc: Montville, Adam W <[email-masked]>; [email-masked]
Subject: Re: [sacm] ECP Architecture Diagram Feedback

Hi Danny,

  *   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).

-Sherif

On Tue, Apr 3, 2018 at 7:36 PM, Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Adam,

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]<mailto:[email-masked]>]

Hi Danny,

Adam

Hi Everyone,

Thanks,

Danny

---

From: Sherif Mansour <[email-masked]>
Date: Sat, 07 Apr 2018 10:18:18 +0000

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 <[email-masked]> 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
>
> Stage 2 -  Evaluator queries information from the repository. If needed,
> the evaluator queries the endpoint for information via the posture manager.
>
>
>
>                                 Posture Manager          Endpoint
>
> 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.
>
>
>
> *From:* Sherif Mansour [mailto:[email-masked]]
> *Sent:* Tuesday, April 03, 2018 5:36 PM
>
>
> *Cc:* Montville, Adam W <[email-masked]>; [email-masked]
>
>

---

From: "Haynes Jr., Dan" <[email-masked]>
Date: Mon, 9 Apr 2018 14:47:58 +0000

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

Sent: Saturday, April 07, 2018 6:18 AM

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”.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sherif,

                Posture Manager          Endpoint

                                Posture Manager          Endpoint

                                |               |        |               |

                                |      |        |        |      |        |

                                |      |        |        |      |        |

|      |respond |        |      |               |        |               |

|      |        |        |      |               |        |               |

                Orchestrator

|                                               |

|                                               |

   ^                ^                   ^

   |                |                   |

   |                |                   |

   |                |                   v

   |                |           |               |        |               |

   |                |           |      |        |        |      |        |

   v                v           |      |        |        |      |        |

|      |        |        |      |               |        |               |

|      |        |        |      |               |        |               |

Thanks,

Danny

From: Sherif Mansour [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, April 03, 2018 5:36 PM

To: Haynes Jr., Dan <[email-masked]<mailto:[email-masked]>>
Cc: Montville, Adam W <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Danny,

-Sherif

Thanks,

Danny

Hi Danny,

Adam

Hi Everyone,

Thanks,

Danny

---

From: Sherif Mansour <[email-masked]>
Date: Mon, 09 Apr 2018 15:05:46 +0000

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 <[email-masked]> wrote:

> 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
> ).
>
>
>
> *Sent:* Saturday, April 07, 2018 6:18 AM
>
>
> 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.
>
>
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 9 Apr 2018 18:19:41 +0200

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:
> On Mon, 9 Apr 2018 at 3:48 pm, Haynes Jr., Dan <[email-masked] 
> <mailto:[email-masked]>> 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:[email-masked]
>     <mailto:[email-masked]>]
> 
>     *To:* Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Montville, Adam W <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     *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. ____
> 
>     __ __
> 
>     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 <[email-masked]
>     <mailto:[email-masked]>> 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:[email-masked]
>         <mailto:[email-masked]>]
>         *Sent:* Tuesday, April 03, 2018 5:36 PM____
> 
> 
>         *To:* Haynes Jr., Dan <[email-masked]
>         <mailto:[email-masked]>>____
> 
>         *Cc:* Montville, Adam W <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>____
> 
> 
>         *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
>         <[email-masked] <mailto:[email-masked]>> 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:[email-masked]
>             <mailto:[email-masked]>]
>             *To:* Haynes Jr., Dan <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* [email-masked] <mailto:[email-masked]>
>             *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
>                 <[email-masked] <mailto:[email-masked]>> 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/____
> 
>                 ____
> 
>                 https://www.ietf.org/mailman/listinfo/sacm____
> 
>             ____
> 
> 
>             https://www.ietf.org/mailman/listinfo/sacm____
> 
>         ____
> 
> 
>

---

From: Sherif Mansour <[email-masked]>
Date: Tue, 10 Apr 2018 00:11:29 +0100

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 <
[email-masked]> wrote:

> 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 :)
>
> 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.
>
> 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
>
>>     (https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/
>> master/draft-ietf-sacm-terminology.md).____
>>
>>     __ __
>>
>>             v                v           |      |        |        |
>>                 [1]https://datatracker.ietf.or
>> g/meeting/101/materials/slides-101-sacm-endpoint-compliance-
>> profile-00(see
>>                 slide 4)____
>>
>>                 [2]https://datatracker.ietf.or
>> g/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see
>>                 slide 5)____
>>
>>                 [3]https://datatracker.ietf.or
>> g/meeting/interim-2017-sacm-03/materials/minutes-interim-201
>> 7-sacm-03-201709260900-00(see
>>                 page 1 and 2)____
>>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 10 Apr 2018 13:23:10 +0200

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?

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).

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).

In most scenarios (approx. everything larger than the S in SME, for 
example), would probably use more than one "Repo", I assume.

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)

"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:
> 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
>   * 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.
> 
>   * A data model that can map a finding/vulnerability to a fix
>   * An automated process for detection
>   * An automated process for fixing issues
>   * An orchstration sytem to provide tech teams with the ability to
> On Mon, Apr 9, 2018 at 5:19 PM, Henk Birkholz 
> <[email-masked] 
> <mailto:[email-masked]>> 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
>     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
> 
>         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
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>         <https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md).____>
> 
>              __ __
> 
>         <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>]
> 
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>>; [email-masked]
>         <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>
>              On Wed, 4 Apr 2018 at 9:12 pm, Haynes Jr., Dan
>         <[email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:____
> 
>                  Hi Sherif,____
> 
>                  ____
> 
>                                                   |              
>                  |      |        |        |      |              
>                      v                v           |      |       
>                  |      |        |        |      |              
>                  |      |        |        |      |              
>         <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>         <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>____
> 
>         <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>>; [email-masked]
>         <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>____
> 
> 
>                  <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
> 
>                      Hi Adam,____
> 
>                      ____
> 
>         <mailto:[email-masked]>
>                      <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>         <mailto:[email-masked]>
>                      <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                          <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
> 
>                          ____
> 
>                          Hi Everyone,
> 
>         <https://datatracker.ietf.org/meeting/101/materials/slides-101-sacm-endpoint-compliance-profile-00(see>
>                          slide 4)____
> 
>                         
>         <https://datatracker.ietf.org/doc/slides-interim-2017-sacm-03-sessa-ecp/00/(see>
>                          slide 5)____
> 
>                         
>         <https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900-00(see>
>                          page 1 and 2)____
> 
>                         
>         <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____>
> 
>                          ____
> 
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <https://www.ietf.org/mailman/listinfo/sacm____>
> 
>                      ____
> 
> 
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <https://www.ietf.org/mailman/listinfo/sacm____>
> 
>                  ____
> 
> 
> 
>         <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
>     <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> 
>

---

From: Sherif Mansour <[email-masked]>
Date: Tue, 10 Apr 2018 14:46:23 +0100

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).

> 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 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.
>
> 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.

>
> 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

> 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).

> requiring a specific Imperative Guidance Repo (OVAL and the Vulnerability
> Assessment Scenario evolving from it might provide a more specific repo
> component name already)
> "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.

>
> "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)
>
> 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").

>> 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:
>>
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     Hi all,
>>
>>                     (https://github.com/sacmwg/dra
>> ft-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).____>
>>
>>              __ __
>>
>>                      <mailto:[email-masked] <mailto:[email-masked]
>> >>>
>>         <https://datatracker.ietf.org/meeting/101/materials/slides-1
>> 01-sacm-endpoint-compliance-profile-00(see>
>>                          slide 4)____
>>
>>         <https://datatracker.ietf.org/meeting/interim-2017-sacm-03/m
>> aterials/minutes-interim-2017-sacm-03-201709260900-00(see>
>>                          page 1 and 2)____
>>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 10 Apr 2018 16:23:18 +0200

Hello Sharif,

On 04/10/2018 03:46 PM, Sherif Mansour wrote:
> I would also recommend the group look at what the develoment comunity 
> have done with Behaviour-Driven Development 
> 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 
>     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.

>     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).
> 
> 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 

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.

> 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.

>     Vulnerability Assessment Scenario evolving from it might provide a
>     more specific repo component name already)
>     "We are reporting the issues..." -> this would be a specific SACM
>     Report component, or a TE Characterization Repo
> 
>     (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)
> 
>     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

>         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.
> 
>         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:
> 
>         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.
> 
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>              Hi all,
> 
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> 
>                       among other things. Does the list of current SACM
>         tasks
>                  (collection,
>                       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).____>>
> 
>                       __ __
> 
>                       Are there other capabilities that you would
>         specifically
>                  like to see
>                       in the orchestrator?____
> 
>                       __ __
> 
>                       *From:* Sherif Mansour
>         [mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>]
> 
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>>
>                       *Cc:* Montville, Adam W
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>>; [email-masked]
>         <mailto:[email-masked]>
>                       <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
> 
>                       In a devops model, you generally want to move from
>         “the
>                  team that
>                       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
>                       Where a dev/sysadmin/other would ping the
>         orchestrator to
>                  check an
>                       asset(s) identify issues, if those issues are
>         mapped to
>                  specific
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                       <mailto:[email-masked]
>         <mailto:[email-masked]>>>>
> 
>                  wrote:____
> 
>                           Hi Sherif,____
> 
>                           ____
> 
>                           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
>                           co-located with the posture manager or the
>         orchestrator
>                  may be
>                           unnecessary for smaller or more limited
>         networks. By
>                  keeping the
>                           the server. Note: the repository may be
>         co-located with
>                  posture
>                                            | | Validator | |        | |
>         Collector
>                           Stage 3 – Evaluator, repository, and posture
>         manager
>                  sharing
>                           repository would support it. I don’t believe
>         there is
>                  anything
>                           in the draft that prevents that type of data
>         form being
>                  stored. ____
> 
>                           ____
> 
>                           Lastly, can you provide more information on
>         how you see
>                  this
>                           *From:* Sherif Mansour
>         [mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>]
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                           <mailto:[email-masked]
>         <mailto:[email-masked]>>>>____
> 
>                           *Cc:* Montville, Adam W
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>>; [email-masked]
>         <mailto:[email-masked]>
>                           <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>____
> 
> 
> 
>                           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
>                               currently do not exist, so if you have
>         many posture
>                  managers
>                               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
>                           which they are used. Now, on thing that is out
>         of scope
>                  is the
>                           detected security issues but not resolved
>         them. It is
>                  therefore
>                           self service, there for an interface to allow
>         it to
>                  work in a
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:____
> 
> 
>                               Hi Adam,____
> 
>                               ____
> 
>                               I hope it was a good trip out there and
>         that you
>                  were able
>                               nothing that all the components in it are
>         in scope
>                  for ECP.
>                               drafts for them (if that makes any sense).
>         I think
>                  what you
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>]
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                               <mailto:[email-masked]
>         <mailto:[email-masked]>>>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
> 
>                               We missed you in London. I think the
>         diagram is ok,
>                  but I do
>                               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
>                               depicts the intended scope of the draft
>         from the
>                  authors'
>                               perspectives, and whether a typical reader
>         would
>                  see it that
>                               way.____
> 
>                               ____
> 
>                               Adam____
> 
>                               ____
> 
>                                   <[email-masked]
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:____
> 
> 
>                                   ____
> 
>                                   Hi Everyone,
> 
>                                   As a result, we just wanted to
>         follow-up on the
>                  list and
>         <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)____
> 
>                                         
>         <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)____
> 
>                                         
>         <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)____
> 
>                                         
>         <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____
>         <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/____>>
> 
>                                   ____
> 
>                                  
>         <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>
>                  <https://www.ietf.org/mailman/listinfo/sacm____
>         <https://www.ietf.org/mailman/listinfo/sacm____>>
> 
>                               ____
> 
> 
>                              
>         <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>
>                  <https://www.ietf.org/mailman/listinfo/sacm____
>         <https://www.ietf.org/mailman/listinfo/sacm____>>
> 
>                           ____
> 
> 
> 
>                  <https://www.ietf.org/mailman/listinfo/sacm
>         <https://www.ietf.org/mailman/listinfo/sacm>>
> 
> 
>              <https://www.ietf.org/mailman/listinfo/sacm
>         <https://www.ietf.org/mailman/listinfo/sacm>>
> 
> 
> 
>

---

From: Sherif Mansour <[email-masked]>
Date: Tue, 10 Apr 2018 14:41:23 +0000

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 <
[email-masked]> wrote:

> >                       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
> >         (
> 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).____
> >>
> >
> >                       __ __
> >
> >                       does stuff for other people” to “the team that
> builds
> >                  capabilities
> >                       for others”.____
> >
> >                       __ __
> >
> >                       “fixes” then the customer is also given the option
> to
> >                  automagically
> >                           architecture of the solution can be arranged
> in a
> >                  manner that
> >                           best supports the needs of the organization.
> One
> >                  approach that
> >                           Stage 2 -  Evaluator queries information from
> the
> >                  repository. If
> >                           |      |        |        |      | | Posture
> >                  report | | Posture   | |____
> >
> >                           |      |        |        |      | | Collection|
> >                  |        | | Collection| |____
> >
> >                           |      |<-----> |        |<-----| | Manager
> | |
> >                  query  | | Engine    | |____
> >
> +-----------+
> >                  |        | +-----------+ |____
> >                               |                |           | | Posture
> >                  |        | | Posture   | |____
> >                               |                |           | | Validator
> >                  |        | | Collector | |____
> +-----------+
> >                  |        | +-----------+ |____
> >                           |      |        |        |      | | Posture
> >                  report | | Posture   | |____
> >
> >                           |      |        |        |      | | Collection|
> >                  |        | | Collection| |____
> >
> >                           |      |        |        |      | | Manager
> | |
> >                  query  | | Engine    | |____
> >
> >                           |      |        |        |      | +-----------+
> >                               pulling data through the orchatrator, it
> just
> >                  happens to be
> >                             * Tactically (short term), is is because
> these
> >                  connections
> >                               you need to develop different integration
> in
> >                  several areas
> >                               leveraging the orchastrator, you only need
> to
> >                  create a singe
> >                           enriched with information that is specific to
> the
> >                  organization
> >                           such as the team which owns specific assets or
> the
> >                  context to
> >                           reporting, I am aware this is out of scope,
> but an
> >                  organisation
> >                           devops model would also increase its value, if
> the
> >                  interface can
> >                               *Subject:* Re: [sacm] ECP Architecture
> Diagram
> >                  Feedback____
> >
> >                               ____
> >
> >                               Hi Danny,____
> >
> >                               ____
> >
> >                               have scoping questions (just sent to the
> list)
> >                  which may
> >                               suggest some modification to the diagram
> once
> >                  resolved. If
> >                                   September virtual interim [2][3] and
> was
> >                  included in the
> >                                   receive any feedback on the
> architecture
> >                  diagram.____
> >
> >                                   ____
> >
> >                                   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)____
> >
> >

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 10 Apr 2018 17:34:12 +0200

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 <[email-masked]> wrote:
>> >     multi-client pub/sub) using the common SACM data and
>interaction
>> model.
>> >
>> >            * We are performing the neccsary security assesments.
>Hence
>> the
>> >              Security tools
>> >              Hence the reporting system & bug tracker integration
>(some
>> tech
>> >              teams would want the data into their reporting systems
>to
>> >         action).
>> >              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
>> >              a user outside the SACM domain) wants to trigger a
>workflow
>> of
>> >              tasks, we need an "external" interface. In fact, this
>can
>> >         be the
>> >              must not necessarily. In fact, there might be good
>reasons
>> >         fot it
>> >              not to be the same kind of protocol/API/interaction
>model,
>> but
>> >              An Orchestrator, as a minimum, takes on the control
>plane
>> >         function
>> >              of instantiating SACM tasks on specific SACM
>components -
>> >         on behalf
>> >              component or an external entity. The frequency of sets
>of
>> >         actions
>> >                  Let me respond later this evening, I am also happy
>to
>> >         call if
>> >                  you have a minute.
>> >
>> >                       for self service testing the main one right
>is to
>> >         make sure end
>> >                       points have been hardened and there sre
>currently
>> >         no known show
>> >                       external parties needs to be thought out. The
>main
>> >         value of the
>> >                       orchestrator is vendor independent management
>and
>> >         self service
>> >                       automation.____
>> >
>> >                       __ __
>> >
>> >                           components as-is with both direct and
>indirect
>> >                  interfaces, the
>> >                           might help is if we break out the diagram
>into
>> >                  different stages.____
>> >
>> >                           ____
>> >
>> >                           Stage 1 – Reporting endpoint information
>to the
>> >                  repository via
>> >                                            | +-----------+ |       
>> >                  +-----------+ |____
>> >                                            | | Posture   | |       
>> >         Posture          | |____
>> >                                            | | Validator | |       
>> >                                            | +-----------+ |       
>> >                  +-----------+ |____
>> >                           Repository      |      |        |       
>> >                           +--------+      | +-----------+
>|<-------|
>> >                  +-----------+ |____
>> >
>> >                           |        |      | | Posture   | | report
>| |
>> >         Posture          | |____
>> >
>> >                           |        |      | | Collection| |       
>| |
>> >                  Collection| |____
>> >
>> >                           |        |<-----| | Manager   | |       
>| |
>> >         Engine           | |____
>> >
>> >                           |        | store| +-----------+ |       
>|
>> >                  +-----------+ |____
>> >
>> >                           |        |      |               |
>> >           |               |____
>> >
>> >                           |        |      |               |
>> >           |               |____
>> >
>> >                           needed, the evaluator queries the
>endpoint for
>> >                  information via
>> >                           the posture manager.____
>> >
>> >                             ____
>> >
>> >                           +------+        +--------+      |
>> >                  |<-------| +-----------+ |____
>> >
>> >                           |      |        |        |      | |
>Posture
>> | |
>Collection|
>> >                  |        | | Collection| |____
>> >                           |      |request/|        | store|
>> >                  |------->| +-----------+ |____
>> >
>> >                           |      |respond |        |      |
>> >                                 |        |               |____
>> >
>> >                           |      |        |        |      |
>> >                  |        |               |____
>> >
>> >                           +------+        +--------+
>> >                               ^                ^                  
>^____
>|____
>|____
>v____
>Posture
>Validator
>> >                           +------+        +--------+      |
>> >                  |<-------| +-----------+ |____
>> >
>> >                           |      |        |        |      | |
>Posture
>> | |
>Collection|
>> >                  |        | | Collection| |____
>Manager
>> >                  |------->| +-----------+ |____
>> >
>> >                           |      |        |        |      |
>> >                  |        |               |____
>> >
>> >                           |      |        |        |      |
>> >                  |        |               |____
>> >
>> >                           +------+        +--------+
>> >                           Regarding the invisible box of reference
>data,
>> >         yes, the
>> >                           eventually be supported by the interface
>that
>> >         we create for
>> >                               on the repository, in their all it
>means
>> >         is it will be
>> >                               (one connection for the orchestrator
>&
>> >         repository). By
>> >                           has not moved the needle in terms of
>security
>> >         if they have
>> >                           natural that there is an interface
>somewhere
>> >         between the
>> >                           Finally one key benefit of the
>orchestrator is
>> >                  automation and
>> >                           (easily) integrate with Jenkins/Bamboo,
>or
>> >         chef recipes /
>> >                           Ansible playbooks, this would go a long
>way for
>> >                  adoption.____
>> >
>> >                           -Sherif____
>> >
>> >                           ____
>> >
>> >                           ____
>> >
>> >                           ____
>> >
>> >                           ____
>> >
>> >                               As far as scoping and the diagram, I
>think
>> >         it’s worth
>> >                               It is just a matter of when we
>actually
>> >         get to creating
>> >                               are looking for is a diagram that
>shows
>> >         what we are
>> >                               the way I'm interpreting the ECP
>draft at
>> >         this point is
>> >                               boundary box could be drawn around
>the
>> >         appropriate
>> >                               components.____
>> >
>> >                               ____
>> >
>> >                               What really matters is whether the
>diagram
>> >         accurately
>> >                                   On Apr 2, 2018, at 1:32 PM,
>Haynes
>> >         Jr., Dan
>> >                                   <[email-masked]
>> >                                   At IETF 101, we presented an
>updated
>> >         architecture
>> >                                   diagram [1] that was based on
>feedback
>> >         from the
>> >                                   ECP -01 draft [4]. During the
>meeting,
>> >         we did not

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Sherif Mansour <[email-masked]>
Date: Tue, 10 Apr 2018 16:40:40 +0100

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 <
[email-masked]> 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 :-)
>
>> 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
>>
>>> (some tech
>>> workflow of
>>> model, but
>>> >                       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
>>> >         (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).____>>
>>> >
>>> >                       __ __
>>> >
>>> >         <[email-masked] <mailto:[email-masked]
>>> >
>>> >                       “fixes” then the customer is also given the
>>> option to
>>> >                  automagically
>>> >                           best supports the needs of the
>>> organization.  One
>>> >                  approach that
>>> >                           Stage 1 – Reporting endpoint information to
>>> the
>>> >                  repository via
>>> >                           Stage 2 -  Evaluator queries information
>>> from the
>>> >                  repository. If
>>> >                           needed, the evaluator queries the endpoint
>>> for
>>> >                  information via
>>> >                           the posture manager.____
>>> >
>>> >                             ____
>>> >
>>> Posture   | |
>>> >                           |      |<-----> |        |<-----| |
>>> Manager   | |
>>> Posture   |
>>> Validator |
>>> Posture   | |
>>> Manager   | |
>>> >         <[email-masked] <mailto:[email-masked]
>>> >
>>> >                               you need to develop different
>>> integration in
>>> >                  several areas
>>> >                               leveraging the orchastrator, you only
>>> need to
>>> >                  create a singe
>>> >                           enriched with information that is specific
>>> to the
>>> >                  organization
>>> >                           such as the team which owns specific assets
>>> or the
>>> >                  context to
>>> >                           Finally one key benefit of the orchestrator
>>> is
>>> >                  automation and
>>> >                           devops model would also increase its value,
>>> if the
>>> >                  interface can
>>> >                           Ansible playbooks, this would go a long way
>>> for
>>> >                  adoption.____
>>> >
>>> >                           -Sherif____
>>> >
>>> >                           ____
>>> >
>>> >                           ____
>>> >
>>> >                           ____
>>> >
>>> >                           ____
>>> >
>>> >                           <[email-masked] <mailto:[email-masked]
>>> >
>>> >                                   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)____
>>> >
>>> >
>>> >         [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)____
>>> >
>>> >

---

From: Adam Montville <[email-masked]>
Date: Tue, 24 Apr 2018 14:00:39 -0500

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 <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> On April 10, 2018 4:41:23 PM GMT+02:00, Sherif Mansour <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Henk,
> 
> Correct me if I am wrong but i2nsf focuses on Network Security Function correct? 
> 
> 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/> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Sharif,
> 
> > <http://en.wikipedia.org/wiki/Behavior_driven_development <http://en.wikipedia.org/wiki/Behavior_driven_development>> (BDD). I am
> > <[email-masked] <mailto:[email-masked]>
> > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >
> >     Hello Sherif,
> >
> >         <[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> >
> >              Hi all,
> >
> >                  <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
> >
> >         (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).____>>>
> >
> >                       __ __
> >
> >         [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >                       <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>]
> >
> >                       *To:* Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>>
> >                       *Cc:* Montville, Adam W
> >         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >                       <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>>; [email-masked] <mailto:[email-masked]>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >                       <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
> >
> >                  <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >         <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>>
> >
> >                  wrote:____
> >
> >                           Hi Sherif,____
> >
> >                           ____
> >
> >         [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >                           <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>]
> >                           *To:* Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >         <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>>____
> >
> >                           *Cc:* Montville, Adam W
> >         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >                           <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>>; [email-masked] <mailto:[email-masked]>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >                           <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>____
> >
> >
> >
> >                           <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:____
> >
> >
> >                               Hi Adam,____
> >
> >                               ____
> >
> >                               *From:* Adam Montville
> >                  [mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >                               <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >                  <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>]
> >                               *To:* Haynes Jr., Dan <[email-masked] <mailto:[email-masked]>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >         <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>>
> >                               *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>
> >
> >         <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> >                  <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:____
> >
> >
> >                                   ____
> >
> >                                   Hi Everyone,
> >
> >         [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/____>>>
> >
> >                                   ____
> 
> --

---

From: Sherif Mansour <[email-masked]>
Date: Thu, 26 Apr 2018 09:26:57 +0000

Yeah, I actually spoke to Expedia about this yesterday and they DevOps
teams ears perked.
They have an automation platform called Flyte
https://github.com/HotelsDotCom/flyte/blob/master/README.md
So they might place BDD test scenarios on top to manage security
requirements. At least they like the idea, and its also human readable to
an auditor for example.

On Tue, 24 Apr 2018 at 8:00 pm, Adam Montville <[email-masked]>
wrote:

> 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.
>
>
>>> 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.
>>>
>>>> Hence the
>>>> >                       for self service testing the main one right is
>>>> to
>>>> >         make sure end
>>>> >                           architecture of the solution can be
>>>> arranged in a
>>>> >                  manner that
>>>> >                                            | | Posture   | |        |
>>>> >                                            | | Validator | |        |
>>>> >                           <mailto:[email-masked] <mailto:[email-masked]
>>>> >
>>>> >                               pulling data through the orchatrator,
>>>> it just
>>>> >                  happens to be
>>>> >         <mailto:sac <[email-masked]>
>>>
>>>