Subject: [sacm] Architecture Draft

From: Adam Montville <[email-masked]>
Date: Fri, 12 Jul 2019 13:09:00 -0500

Greetings all:

During the last virtual interim we talked about some of the next things we wanted to work on, and one of those is the current architecture draft. Per the notes, we would like this to be an item to discuss during our session in Montreal, and it seems like a good idea to have some discussion points ready before then. Our goal (again, as stated in the notes) is to drive the direction of the draft to conclusion.

What needs to be done with the draft to get there?

Kind regards,

Adam

2019-06-25 VI Notes: https://datatracker.ietf.org/doc/minutes-interim-2019-sacm-02-201906251300/ 

SACM Architecture 01: https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 13 Jul 2019 22:16:04 -0400

Hi Adam,

Thanks for raising the question to the list.  I just skimmed (and sorry if
I missed it) and am wondering how does ROLIE, SWIMA, and NEA fit into the
architecture?  Does this align with the SCAP 2.0 vision or does it diverge
(we don't have to follow NIST obviously, but it would be good to understand
the picture and if they do align, could or should.

Since the ECP draft has a reliance on NEA (and I think SWIMA, but will be
reading the ECP draft again this week), they are all part of the overall
architecture, right?  Having this picture of how these pieces fit and if
there are identified gaps would be very helpful to me, likely others as
well.

Thank you!
Kathleen

On Fri, Jul 12, 2019 at 2:09 PM Adam Montville <[email-masked]>
wrote:

> Greetings all:
>
> During the last virtual interim we talked about some of the next things we
> wanted to work on, and one of those is the current architecture draft. Per
> the notes, we would like this to be an item to discuss during our session
> in Montreal, and it seems like a good idea to have some discussion points
> ready before then. Our goal (again, as stated in the notes) is to drive the
> direction of the draft to conclusion.
>
> 2019-06-25 VI Notes:
> https://datatracker.ietf.org/doc/minutes-interim-2019-sacm-02-201906251300/
>
> SACM Architecture 01:
> https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

-- 

Best regards,
Kathleen

---

From: Adam Montville <[email-masked]>
Date: Mon, 15 Jul 2019 06:43:40 -0500

Hi Kathleen,

Thank you for your questions.

I’ll start with EPCP, which is depicted in Figure 3 of the current draft as a collection subsystem (using the language from the draft). Addressing EPCP in this way covers NEA, as EPCP is based on NEA, and it covers SWIMA in that SWIMA is used within that collection subsystem. In this sense EPCP describes a type of collection subsystem relative to the proposed SACM architecture. The SACM architecture then has the freedom to rely on other collection subsystems where needed.

Similarly, ROLIE would be a type of repository. While not explicitly referenced, see Figure 1, where ROLIE would be a repository connected to the messaging system, and see Figure 3, where ROLIE could be the Policy Repository.

As far as SCAP 2.0 is concerned, I think we both align and diverge. We align in that we are attempting to solve the same problems. Both architectures have collection, repositories (of various types, including CMDB), and downstream components (i.e. analysis and reporting). We diverge in a couple of ways. First, SCAP 2.0 appears to rely exclusively on EPCP as a collection subsystem (at least presently). The SACM architecture explicitly recognizes a need for multiple collection subsystems to be supported. Second, SCAP 2.0 appears to rely on point-to-point component communication, where the components of the architecture have direct awareness of other components. The SACM architecture allows not only point-to-point connections, but also supports things like pub/sub. (NOTE: I have not spent hours studying SCAP 2.0.)

The SACM architecture is focused on defining components, their capabilities and interfaces, and the workflows they explicitly support. We started with three common workflow domains (IT asset management, vulnerability management, configuration management), and we explicitly recognize that there are multiple ways to collect data necessary in these domains. We anticipate that there will always be multiple ways to collect information, and further believe that we cannot rely on one particular collection subsystem to cover the whole of an enterprise, which must consider cloud-native and hybrid environments equally with traditional endpoint-centric approaches). 

Does this help?

Kind regards,

Adam

> On Jul 13, 2019, at 9:16 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Adam,
> 
> Thanks for raising the question to the list.  I just skimmed (and sorry if I missed it) and am wondering how does ROLIE, SWIMA, and NEA fit into the architecture?  Does this align with the SCAP 2.0 vision or does it diverge (we don't have to follow NIST obviously, but it would be good to understand the picture and if they do align, could or should.
> 
> Since the ECP draft has a reliance on NEA (and I think SWIMA, but will be reading the ECP draft again this week), they are all part of the overall architecture, right?  Having this picture of how these pieces fit and if there are identified gaps would be very helpful to me, likely others as well.
> 
> Thank you!
> Kathleen
> 
> On Fri, Jul 12, 2019 at 2:09 PM Adam Montville <[email-masked] <mailto:[email-masked]>> wrote:
> Greetings all:
> 
> 2019-06-25 VI Notes: https://datatracker.ietf.org/doc/minutes-interim-2019-sacm-02-201906251300/ <https://datatracker.ietf.org/doc/minutes-interim-2019-sacm-02-201906251300/> 
> 
> SACM Architecture 01: https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 15 Jul 2019 08:45:55 -0400

On Mon, Jul 15, 2019 at 7:43 AM Adam Montville <[email-masked]>
wrote:

> I’ll start with EPCP, which is depicted in Figure 3 of the current draft
> as a collection subsystem (using the language from the draft). Addressing
> EPCP in this way covers NEA, as EPCP is based on NEA, and it covers SWIMA
> in that SWIMA is used within that collection subsystem. In this sense EPCP
> describes a type of collection subsystem relative to the proposed SACM
> architecture. The SACM architecture then has the freedom to rely on other
> collection subsystems where needed.
>
> Similarly, ROLIE would be a type of repository. While not explicitly
> referenced, see Figure 1, where ROLIE would be a repository connected to
> the messaging system, and see Figure 3, where ROLIE could be the Policy
> Repository.
>
> As far as SCAP 2.0 is concerned, I think we both align and diverge. We
> align in that we are attempting to solve the same problems. Both
> architectures have collection, repositories (of various types, including
> CMDB), and downstream components (i.e. analysis and reporting). We diverge
> in a couple of ways. First, SCAP 2.0 appears to rely exclusively on EPCP as
> a collection subsystem (at least presently). The SACM architecture
> explicitly recognizes a need for multiple collection subsystems to be
> supported. Second, SCAP 2.0 appears to rely on point-to-point component
> communication, where the components of the architecture have direct
> awareness of other components. The SACM architecture allows not only
> point-to-point connections, but also supports things like pub/sub. (NOTE: I
> have not spent hours studying SCAP 2.0.)
>
> The SACM architecture is focused on defining components, their
> capabilities and interfaces, and the workflows they explicitly support. We
> started with three common workflow domains (IT asset management,
> vulnerability management, configuration management), and we explicitly
> recognize that there are multiple ways to collect data necessary in these
> domains. We anticipate that there will always be multiple ways to collect
> information, and further believe that we cannot rely on one particular
> collection subsystem to cover the whole of an enterprise, which must
> consider cloud-native and hybrid environments equally with traditional
> endpoint-centric approaches).
>
> Does this help?
>

Thank you, Adam.  Yes, it does.  I may come back with more questions after
reading the ECP draft in last call.

Best regards,
Kathleen

> On Fri, Jul 12, 2019 at 2:09 PM Adam Montville <
> [email-masked]> wrote:
>
>> Greetings all:
>>
>> During the last virtual interim we talked about some of the next things
>> we wanted to work on, and one of those is the current architecture draft.
>> Per the notes, we would like this to be an item to discuss during our
>> session in Montreal, and it seems like a good idea to have some discussion
>> points ready before then. Our goal (again, as stated in the notes) is to
>> drive the direction of the draft to conclusion.
>>

-- 

Best regards,
Kathleen

---

From: Adam Montville <[email-masked]>
Date: Mon, 15 Jul 2019 08:44:50 -0500

> On Jul 15, 2019, at 7:45 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> On Mon, Jul 15, 2019 at 7:43 AM Adam Montville <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Kathleen,
> 
> Thank you, Adam.  Yes, it does.  I may come back with more questions after reading the ECP draft in last call.

Excellent, thank you - questions are good :-)

> 
> Best regards,
> Kathleen
> 
> Kind regards,
> 
> Adam
> 
> 
> 
>> On Jul 13, 2019, at 9:16 PM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Adam,
>>