Subject: [sacm] Review need of draft-schaad-sacm-architecture-00

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 1 Nov 2016 19:57:41 +0000

Jim and I developed the following draft to drive some architecture discussion at the IETF 97 meeting and on the list.

https://datatracker.ietf.org/doc/draft-schaad-sacm-architecture/

We have asked the chairs to add a slot to the SACM meeting agenda at IETF 97 in a couple weeks to facilitate some discussion.

It is our hope that we can get as many people as possible to read the draft to allow for a robust conversation going forward. We are happy to answer any questions and look forward to hearing any feedback. 

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 31, 2016 7:15 PM
To: Waltermire, David A. (Fed) <[email-masked]>; Jim Schaad <[email-masked]>
Subject: New Version Notification for draft-schaad-sacm-architecture-00.txt

A new version of I-D, draft-schaad-sacm-architecture-00.txt
has been successfully submitted by Jim Schaad and posted to the IETF repository.

Name:		draft-schaad-sacm-architecture
Revision:	00
Title:		Prospective Architecture for SACM
Document date:	2016-10-31
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-schaad-sacm-architecture-00.txt
Status:         https://datatracker.ietf.org/doc/draft-schaad-sacm-architecture/
Htmlized:       https://tools.ietf.org/html/draft-schaad-sacm-architecture-00

Abstract:
   This document describes the high level architecture for Security
   Automation and Continuous Monitoring (SACM).  The architecture
   identifies the components that provide for the collection, storage,
   dissemination, and evaluation of posture information.  This
   architecture also describes the interfaces and associated operations
   that define the interactions between these components.  This
   information will inform future engineering work around identifying
   existing standards for collecting, storing, disseminating, and
   evaluating endpoint posture information.  This architecture will also
   help in identifying standardization gaps that require new engineering
   effort.

   Security practitioners need to request, analyze, and aggregate
   posture information from disparate sources that use differing means
   to identify endpoints, hardware, software, and configurations.  This
   task is made harder by the large number of different protocols and
   formats needed to bring together all of this information into a
   single view.  This architecture provides a means to automatically
   gather posture data together for standardized dissemination to
   downstream components.  This allows security practitioners that
   leverage this architecture to focus on managing security problems,
   not data.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Tue, 8 Nov 2016 12:35:16 -0500

This is an interesting draft. It clarifies the relationship between SACM's
current solutions draft (Software Inventory Message and Atrributes) with
earlier solution proposals. SACM's current architecture draft describes a
more xmpp-grid-like architecture that did not align with specifications
more recently adopted by the work group, so this is a step forward in
reducing the confusion caused by that disconnect. There are still areas
where we need increased clarity-- in particular, when defining components
of this architecture, and the role of the data model in this architecture.
I've listed a few questions below; looking forward to talking about this
more.

Thanks,
Jess

1) Aggregator-- is an aggregator a specific case of an evaluator? It takes
in data, performs an action on that data, and then publishes it back out.
What is the value in describing aggregator more explicitly?

2) Policy Management (sic)-- Again, this seems like a specific type of
evaluator. Why does it need to be more explicitly described? Are there
other types of evaluators that should be listed as a component? How do we
distinguish between the types of evaluators we will describe in detail?

3) SACM Proxy-- Is this a component that we are chartered to address in our
architecture? I have nothing against it as a concept, but it seems to be
out of scope for SACM to tackle (and we have enough on our plate to tackle
already).

4) External Event-- I'm struggling to understand how an event is a role of
an architecture. Could you clarify?

5) Authenticator and Authorizor-- Why are authentication and authorization
not features of the protocols we specify? And, if they are, why the need
for separate architectural components?

6) SACM Cloud-- Figure 1 includes a SACM Cloud, but it is not listed as a
component. What is it?

7) Broker-- Figure 2 includes a Broker. Is is also not listed as a
component. What is it?

8) Messaging Protocol-- Figure 2 includes a Messaging Protocol. Is a
protocol a component of the architecture? What is being illustrated here?

9) Data Model-- Section 5 describes some internal confusion about the role
of the data model in the SACM WG. I am not sure this is entirely
appropriate to include in an architecture. Unless it was intended to drive
discussion?

On Tue, Nov 1, 2016 at 3:57 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> Jim and I developed the following draft to drive some architecture
> discussion at the IETF 97 meeting and on the list.
>
> We have asked the chairs to add a slot to the SACM meeting agenda at IETF
> 97 in a couple weeks to facilitate some discussion.
>
> It is our hope that we can get as many people as possible to read the
> draft to allow for a robust conversation going forward. We are happy to
> answer any questions and look forward to hearing any feedback.
>
> Regards,
> Dave
>
> URL:            https://www.ietf.org/internet-
> drafts/draft-schaad-sacm-architecture-00.txt
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 8 Nov 2016 11:17:48 -0800

Comments in-line

From: sacm [mailto:[email-masked]] On Behalf Of Jessica Fitzgerald-McKay
Sent: Tuesday, November 08, 2016 9:35 AM
To: Waltermire, David A. <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] Review need of draft-schaad-sacm-architecture-00

This is an interesting draft. It clarifies the relationship between SACM's current solutions draft (Software Inventory Message and Atrributes) with earlier solution proposals. SACM's current architecture draft describes a more xmpp-grid-like architecture that did not align with specifications more recently adopted by the work group, so this is a step forward in reducing the confusion caused by that disconnect. There are still areas where we need increased clarity-- in particular, when defining components of this architecture, and the role of the data model in this architecture. I've listed a few questions below; looking forward to talking about this more.

Thanks,
Jess

1) Aggregator-- is an aggregator a specific case of an evaluator? It takes in data, performs an action on that data, and then publishes it back out. What is the value in describing aggregator more explicitly?

[JLS] This question was raised by Dave as well.  I thought of them as being different when I originally wrote the draft as I saw the tasks as being different.  An evaluator compared current state against a standard and published the result of that evaluation.  An aggregator did things like end-point comparisons, linking together current data and historic data for time-line views or combining results from different reporters into a common view.   I am not wedded to them being separate.

2) Policy Management (sic)-- Again, this seems like a specific type of evaluator. Why does it need to be more explicitly described? Are there other types of evaluators that should be listed as a component? How do we distinguish between the types of evaluators we will describe in detail?

[JLS] I thought of this as an interaction with a human type task.  This is where policies are entered, modified and deleted.  As such it is not an evaluator.

3) SACM Proxy-- Is this a component that we are chartered to address in our architecture? I have nothing against it as a concept, but it seems to be out of scope for SACM to tackle (and we have enough on our plate to tackle already).

[JLS] A couple of arguments: 1) it is in the use case document so I think we need to address it.  2) I would argue that even things which we do not plan on doing but are part of the picture need to be covered.  3) The architecture document covers how things are put together, but some of the pieces may or may not be standardized in the same way.  I think that a SACM proxy is going to look a lot like a data store, so even though it is not explicitly covered the majority of how interactions are done is going to be covered.

4) External Event-- I'm struggling to understand how an event is a role of an architecture. Could you clarify?

[JLS] When I was looking at this, I was thinking in terms of getting mile reports, external vulnerability reports and so forth.  These items need to get received and processed.  It is possible that one could consider this to be a type of collector instead.

5) Authenticator and Authorizor-- Why are authentication and authorization not features of the protocols we specify? And, if they are, why the need for separate architectural components?

[JLS] They are features but you still need to have components that you talk to in the end to do the processing and that perform the management tasks associated with this tasks.  For example, where would you put a Certificate Authority that issues certificates?  It would be an authenticator.

6) SACM Cloud-- Figure 1 includes a SACM Cloud, but it is not listed as a component. What is it?

[JLS] It is a bad name.  This should probably be replaced with “network”.

7) Broker-- Figure 2 includes a Broker. Is is also not listed as a component. What is it?

[JLS] Broker == Directory.   We ran out of time for harmonization.

8) Messaging Protocol-- Figure 2 includes a Messaging Protocol. Is a protocol a component of the architecture? What is being illustrated here?

[JLS] Not totally clear to me – but this is probably talking about a protocol that is moving data between components.

9) Data Model-- Section 5 describes some internal confusion about the role of the data model in the SACM WG. I am not sure this is entirely appropriate to include in an architecture. Unless it was intended to drive discussion? 

[JLS] Until we resolve the internal confusion, it is hard to talk about what goes here.  The confusion need to be resolved, at least in my mind, before I can really write good text.  I am starting to get more ideas about what goes here.

Jim

On Tue, Nov 1, 2016 at 3:57 PM, Waltermire, David A. (Fed) <[email-masked] <mailto:[email-masked]> > wrote:

Regards,
Dave

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Monday, October 31, 2016 7:15 PM
To: Waltermire, David A. (Fed) <[email-masked] <mailto:[email-masked]> >; Jim Schaad <[email-masked] <mailto:[email-masked]> >
Subject: New Version Notification for draft-schaad-sacm-architecture-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .

The IETF Secretariat

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