Subject: Re: [sacm] FEEDBACK REQUESTED: ECP Diagrams

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 4 Jan 2018 14:16:22 +0000

Hi Everyone,

I just wanted to follow up with this and see if anyone had any thoughts on the different options.

Thanks,

Danny

From: Haynes, Dan
Sent: Tuesday, December 19, 2017 10:14 AM
To: [email-masked]
Subject: FEEDBACK REQUESTED: ECP Diagrams

Hi Everyone,

Sorry for the delay on this, but, we had an action item to draw up some diagrams for ECP based on the WG discussion at the September Virtual Interim Meeting [1][2]. I have included the diagrams below :).

The first three show the current NETCONF/YANG architecture, NEA architecture, and ECP diagram. After that, there is the revised ECP diagram which was proposed at the meeting and two alternate diagrams that were created based on discussion during that meeting.

Please let us know what you think about the different options good and bad so that we can work together to come up with a diagram that makes the most sense for the group.

Also, let me know if you have any questions.

Thanks,

Danny

[1] https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900/ (see pages 7-9)

[2] https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/slides-interim-2017-sacm-03-sessa-ecp/

=====================================================================================================================================================================

                       +----------------------------+

                       |Server (device)             |

                       |    +--------------------+  |

                      |    |      configuration |  |

            +----+     |    |     ---------------|  |

            |YANG|+    |    | m d  state data    |  |

           |mods||+   |    | e a ---------------|  |

           +----+|| -----> | t t  notifications |  |

            +----+|   |    | a a ---------------|  |

             +----+   |    |      operations    |  |

                      |    +--------------------+  |

                      |           ^                |

                      |           |                |

                      |           v                |

    +------+          |     +-------------+        |

    |      | -------------> |             |        |

    |Client| <rpc>    |     |  NETCONF    |        |

    | (app)|          |     |   engine    |        |

    |      | <------------  |             |        |

    +------+ <rpc-reply>    +-------------+        |

                       |       /        \           |

                       |      /          \          |

                       |     /            \         |

                       | +--------+   +---------+   |

                       | | config |   |system   |+  |

                       | |  data- |   |software ||+ |

                       | |   base |   |component||| |

                       | +--------+   +---------+|| |

                       |               +---------+| |

                       |                +---------+ |

                       +----------------------------+

Figure 1: NETCONF/YANG Architecture (RFC622, Section 3.1)

=====================================================================================================================================================================

    +-------------+                          +--------------+

    |  Posture    |   <--------PA-------->   |   Posture    |

    |  Validators |                          |   Collectors |

    |  (1 .. N)   |                          |   (1 .. N)   |

    +-------------+                          +--------------+

          |                                         |

          |                                         |

          |                                         |

    +-------------+                          +--------------+

    |   Posture   |                          |   Posture    |

    |   Broker    |   <--------PB-------->   |   Broker     |

    |   Server    |                          |   Client     |

    +-------------+                          +--------------+

          |                                         |

          |                                         |

    +-------------+                          +--------------+

    |   Posture   |                          |   Posture    |

    |   Transport |   <--------PT-------->   |   Transport  |

    |   Server    |                          |   Client     |

    |   (1 .. N)  |                          |   (1 .. N)   |

    +-------------+                          +--------------+

       NEA SERVER                               NEA CLIENT

Figure 2: NEA Architecture

=====================================================================================================================================================================
  Server                   Endpoint

                +---------------+        +---------------+

                |               |        |               |

                | +-----------+ |        | +-----------+ |

                | | Posture   | |        | | Posture   | |

                | | Validator | |        | | Collector | |

                | +-----------+ |        | +-----------+ |

                |      |        |        |      |        |

                |      |        |        |      |        |

Repository      |      |        |        |      |        |

+--------+      | +-----------+ |        | +-----------+ |

|        |      | | Posture   | |        | | Posture   | |

|        |<------->| | Server    | |        | | Client    | |

|        |      | +-----------+ |        | +-----------+ |

|        |      |      |        |        |      |        |

|        |      |      |        |        |      |        |

+--------+      |      |        |        |      |        |

                |      |        |        |      |        |

                | +-----------+ |        | +-----------+ |

                | | Comms     | |        | | Comms     | |

                | | Server    | |<------>| | Client    | |

                | +-----------+ |        | +-----------+ |

                |               |        |               |

                +---------------+        +---------------+

Figure 3: Current ECP Diagram

=====================================================================================================================================================================

  Posture Manager              Endpoint

Orchestrator    Repository      +---------------+        +---------------+

+--------+      +--------+      |               |        |               |

|        |      |        |      | +-----------+ |        | +-----------+ |

|        |<---->|        |      | | Posture   | |        | | Posture   | |

|        | pub/ |        |      | | Validator | |        | | Collector | |

|        | sub  |        |      | +-----------+ |        | +-----------+ |

+--------+      |        |      |      |        |        |      |        |

                |        |      |      |        |        |      |        |

Evaluator       |        |      |      |        |        |      |        |
+------+        |        |      | +-----------+ |<-------| +-----------+ |

|      |        |        |      | | Posture   | | report | | Posture   | |

|      |        |        |      | | Collection| |        | | Collection| |

|      |<-----> |        |<-----| | Manager   | | query  | | Engine    | |

|      |request/|        | store| +-----------+ |------->| +-----------+ |

|      |respond |        |      |               |        |               |

|      |        |        |      |               |        |               |

|      |        |        |      +---------------+        +---------------+

+------+        +--------+

Figure 4: Proposed ECP Diagram (Option 1)

=====================================================================================================================================================================
                                                                   Posture Manager              Endpoint

              Orchestrator     +---------------+        +---------------+

                +--------+      |               |        |               |

                |        |      | +-----------+ |        | +-----------+ |

                |        |<---->| | Posture   | |        | | Posture   | |

                |        | pub/ | | Validator | |        | | Collector | |

                |        | sub  | +-----------+ |        | +-----------+ |

                +--------+      |      |        |        |      |        |

                                |      |        |        |      |        |

Evaluator       Repository      |      |        |        |      |        |

+------+        +--------+      | +-----------+ |<-------| +-----------+ |

|      |        |        |      | | Posture   | | report | | Posture   | |

|      |        |        |      | | Collection| |        | | Collection| |

|      |<-----> |        |<-----| | Manager   | | query  | | Engine    | |

|      |request/|        | store| +-----------+ |------->| +-----------+ |

|      |respond |        |      |               |        |               |

|      |        |        |      |               |        |               |

+------+        +--------+      +---------------+        +---------------+

Figure 5: Alternate Diagram Based on WG Discussion (Option 2)

=====================================================================================================================================================================

                Orchestrator

+-----------------------------------------------+

|                                               |

|                                               |

+-----------------------------------------------+

   ^                ^                   ^

   |pub/sub         |pub/sub            |pub/sub

   |                |                   |

   V                v                   v

Evaluator       Repository        Posture Manager              Endpoint

+------+        +--------+      +---------------+        +---------------+

|      |        |        |      |               |        |               |

|      |        |        |      | +-----------+ |        | +-----------+ |

|      |        |        |      | | Posture   | |        | | Posture   | |

|      |        |        |      | | Validator | |        | | Collector | |

|      |        |        |      | +-----------+ |        | +-----------+ |

|      |        |        |      |      |        |        |      |        |

|      |<------>|        |<-----|      |        |        |      |        |

|      |request/|        |store |      |        |        |      |        |

|      |respond |        |      | +-----------+ |<-------| +-----------+ |

|      |        |        |      | | Posture   | | report | | Posture   | |

|      |        |        |      | | Collection| |        | | Collection| |

|      |        |        |      | | Manager   | | query  | | Engine    | |

|      |        |        |      | +-----------+ |------->| +-----------+ |

|      |        |        |      |               |        |               |

|      |        |        |      |               |        |               |

|      |        |        |      +---------------+        +---------------+

+------+        +--------+

Figure 6: Alternate Diagram Based on WG Discussion (Option 3)

=====================================================================================================================================================================

---

From: Adam Montville <[email-masked]>
Date: Thu, 04 Jan 2018 16:43:43 +0000

Danny, thanks for the ping.

I like Figure 5, but perhaps with the following caveats. First, the
connection between Posture Manager and Repository could be direct or
brokered, if we wanted it to be. Second, the whole of collection could be
present on a single device to handle remote (i.e. agentless) collection,
which may obviate the need for protocol-based report/query between
components traditionally executing on a Posture Manager and those
traditionally executing on the Endpoint.

In general, I think ECP (looking at SWIMA as an example) is probably a good
framework for collection, but leaves more to be done outside of that. We
still need to consider agentless collection. We also need to address how we
enable/encourage a more pluggable ecosystem of security-related tools in
the enterprise.

Adam

On Thu, Jan 4, 2018 at 8:16 AM Haynes, Dan <[email-masked]> wrote:

> *From:* Haynes, Dan
> *Sent:* Tuesday, December 19, 2017 10:14 AM
> *To:* [email-masked]
> *Subject:* FEEDBACK REQUESTED: ECP Diagrams
>
>
>
> Hi Everyone,
>
>
> Sorry for the delay on this, but, we had an action item to draw up some
> diagrams for ECP based on the WG discussion at the September Virtual
> Interim Meeting [1][2]. I have included the diagrams below :).
>
>
>
> The first three show the current NETCONF/YANG architecture, NEA
> architecture, and ECP diagram. After that, there is the revised ECP diagram
> which was proposed at the meeting and two alternate diagrams that were
> created based on discussion during that meeting.
>
>
>
> Please let us know what you think about the different options good and bad
> so that we can work together to come up with a diagram that makes the most
> sense for the group.
>
>
>
> [1]
> https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/minutes-interim-2017-sacm-03-201709260900/
> (see pages 7-9)
>
> [2]
> https://datatracker.ietf.org/meeting/interim-2017-sacm-03/materials/slides-interim-2017-sacm-03-sessa-ecp/
>
>
>
>
> |        |ß---à| | Server    | |        | | Client    | |
>
>                 |        |      |      |        |        |      |
> |
> Evaluator       |        |      |      |        |        |      |
> |
> |      |        |        |      |               |        |
> |
>                                                                    Posture
> Manager              Endpoint
>                                 |      |        |        |      |
> |
> |      |        |        |      |               |        |
> |
> |      |        |        |      |               |        |
> |
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Fri, 5 Jan 2018 14:47:13 -0500

I also prefer Figure 5. Other comments in-line.

Jess

On Thu, Jan 4, 2018 at 11:43 AM, Adam Montville <[email-masked]>
wrote:

> brokered, if we wanted it to be.
>

​[JMF] The Posture Manager and Repository could also be co-located, as they
are in the strongSwan SWIMA implementation. I think we should capture these
options in the ECP initially, and then discuss on list whether or not we
need to mandate a selection of these possibilities using normative
language. Thoughts on that approach?
​

> Second, the whole of collection could be present on a single device to
> handle remote (i.e. agentless) collection, which may obviate the need for
> protocol-based report/query between components traditionally executing on a
> Posture Manager and those traditionally executing on the Endpoint.
>
> In general, I think ECP (looking at SWIMA as an example) is probably a
> good framework for collection, but leaves more to be done outside of that.
> We still need to consider agentless collection. We also need to address how
> we enable/encourage a more pluggable ecosystem of security-related tools in
> the enterprise.
>

​[JMF] There are lots of non-standardized ways to do collection. SWIMA and
netconf/YANG are the two standardized methods the work group agreed to
incorporate into ECP, let's start with them.

>> Please let us know what you think about the different options good and
>> bad so that we can work together to come up with a diagram that makes the
>> most sense for the group.
>>
>>
>>
>> [1] https://datatracker.ietf.org/meeting/interim-2017-sacm-03/
>> materials/minutes-interim-2017-sacm-03-201709260900/ (see pages 7-9)
>>
>> [2] https://datatracker.ietf.org/meeting/interim-2017-sacm-03/
>> materials/slides-interim-2017-sacm-03-sessa-ecp/
>>
>>
>>
>> ============================================================
>> ============================================================
>> =============================================
>>
>> ============================================================
>> ============================================================
>> =============================================
>>
>> ============================================================
>> ============================================================
>> =============================================
>>
>>
>>   Server                   Endpoint
>>
>> ============================================================
>> ============================================================
>> =============================================
>>
>>
>>
>>   Posture Manager              Endpoint
>>
>> ============================================================
>> ============================================================
>> =============================================
>>
>>
>>                                                                    Posture
>> Manager              Endpoint
>>
>> ============================================================
>> ============================================================
>> =============================================
>>
>>
>>                 Orchestrator
>>
>> ============================================================
>> ============================================================
>> =============================================
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>