Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 7 Jul 2014 19:38:44 +0000

After a light read, here are some quick thoughts on the draft-camwinget-sacm-architecture-00:

General:

This draft is fairly light on defining the roles of repositories of different types of security automation data (e.g., guidance, attribute data, processing artifacts) which can be consumers and providers in their own right. I don't believe these should be handled as part of the control plane, but should be considered first-class components in the architecture (perhaps as distinct classes of provider/consumer like collectors and evaluators.)

What was the reasoning behind including these components in the control plane?

Section 2.1:

The draft states "a Consumer may also desire to obtain the information without
   having to know the available providers."

I would expect that the consumer, at minimum, should have some way of identifying and authenticating the provider in addition to any authentication services provided by the control plane. To not do so would leave the system open to a number of security concerns relating to potentially malicious provider or middle box. Having anonymous providers would also prevent the consumer from knowing the provenance of the provided data, tracking history from the same provider, or being able to go back to a given provider to query additional information relative to the first exchange. I don't think this is a workable solution.

Also, an evaluator is notionally a consumer of collected posture data and a provider of evaluation results. The notions of collectors and evaluators are associated with providers in section 2.2, but not with consumers in section 2.1. It should also be possible under this architecture to have aggregating  collectors and evaluators that request/subscribe and consume collection and evaluation data respectively, and then provide the corresponding aggregate data based on requests/subscriptions. Another case might be a collector proxy such as an MDM which is a specialized type of provider/consumer. Some discussion of this general flow should be included in the architectural overview (section 2).

The generalization of providers and consumers is nice, but I am afraid this will break down when we are considering mandatory to implement for data models and transports for collectors and evaluators. We may also find that there are more specific requirements for specific types of provider/consumer interfaces. More thought/discussion is needed here.

I'll provide more comments once I am able to consider this architecture in the context of the information model drafts.

Thanks,
Dave

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 7 Jul 2014 21:22:53 +0000

A few more questions.

Is the use of a broker/proxy a required component of the architecture? If so, are there any concerns that this might restrict usage to only large-scale enterprise deployments?
Is it possible for the providers/consumers to implement the broker/proxy interfaces directly? In other words, in the most simplistic implementation case, can providers/consumers directly negotiate about tasking/formats without an intermediary? If so, what functions are required for each "side" of the communication?
Does this approach restrict the use of DNS SRV records  [RFC2782] for basic service discovery (e.g., identifying potential providers or consumers)?
Can the providers/consumers work with an existing authorization provider within the enterprise or does this require a specialized SACM component?

Also, one typo in section 2.3: "R's may request information independent of knowing the identities of the P's and Providers (P's)"

Is the first "P's" a consumer or is this intended to just read "identities of the P's"?

Thanks,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Monday, July 07, 2014 3:39 PM
To: [email-masked]
Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00

General:

Section 2.1:

Thanks,
Dave

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 21 Jul 2014 16:17:58 +0000

Hi Adam,

Further comments below:

From: <Waltermire>, "David A." <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 7, 2014 at 12:38 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00

General:

This draft is fairly light on defining the roles of repositories of different types of security automation data (e.g., guidance, attribute data, processing artifacts) which can be consumers and providers in their own right. I don’t believe these should be handled as part of the control plane, but should be considered first-class components in the architecture (perhaps as distinct classes of provider/consumer like collectors and evaluators.)
[NCW] Yes, my bad on not providing more details as I was pressed for time in putting more content into the draft but I can certainly work on providing more color.

What was the reasoning behind including these components in the control plane?
[NCW] The control plane is meant to be an abstraction that handles the security behind the “sharing” of information as well as the discovery/registration.  That is, I believe the group will want to allow for different data models and transports (albeit SACM will define at least one MUST).  I believe the roles will be defined by each of the consumer and the provider, but it is up to the control plane to manage (and “trust” the information provided by these components).

Section 2.1:

The draft states “a Consumer may also desire to obtain the information without
   having to know the available providers.”

I would expect that the consumer, at minimum, should have some way of identifying and authenticating the provider in addition to any authentication services provided by the control plane. To not do so would leave the system open to a number of security concerns relating to potentially malicious provider or middle box. Having anonymous providers would also prevent the consumer from knowing the provenance of the provided data, tracking history from the same provider, or being able to go back to a given provider to query additional information relative to the first exchange. I don’t think this is a workable solution.
[NCW]  That is one possibility…..but I think there are cases in which there may be several providers (in a very large enterprise, there may be for instance, multiple AAA systems or Posture collector/validators)….each of which (in a model where the control plane is distinct, like a broker) could authenticate to the control plane .  This is akin to a pub/sub mechanism.

Also, an evaluator is notionally a consumer of collected posture data and a provider of evaluation results. The notions of collectors and evaluators are associated with providers in section 2.2, but not with consumers in section 2.1. It should also be possible under this architecture to have aggregating  collectors and evaluators that request/subscribe and consume collection and evaluation data respectively, and then provide the corresponding aggregate data based on requests/subscriptions. Another case might be a collector proxy such as an MDM which is a specialized type of provider/consumer. Some discussion of this general flow should be included in the architectural overview (section 2).
[NCW]  So, this is where I will need to add more text once we get consensus of the group.  Perhaps there is a tier or operations (vs. roles) that an entity can perform:
 - consume posture information: but within the consumption, there may be restrictive ways in which the information could be consumed.  That is, for some use cases, the information provided to the consumer may not include identity information for privacy reasons.
 - produce posture information: like a consumer, there may be restrictions in how it can produce the information both due to policy or due to its own limited set of capabilities

So, when an entity “joins”,  as you state above, it can “join” to consume and produce (or some combination of)….but that has to be proven through the authentication/authorization process (which we place in the control plane).  To be able to have the example you describe above.  I will need to add more text around this to clarify, so thanks for raising this.

I’ll provide more comments once I am able to consider this architecture in the context of the information model drafts.

Thanks,
Dave

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 21 Jul 2014 16:26:33 +0000

Hi Adam,

More below:

From: <Waltermire>, "David A." <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 7, 2014 at 2:22 PM
To: "Waltermire, David A." <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Comments on draft-camwinget-sacm-architecture-00

A few more questions.

Is the use of a broker/proxy a required component of the architecture? If so, are there any concerns that this might restrict usage to only large-scale enterprise deployments?
[NCW]  Actually, it was added to address large scale systems :-)  But we’ll need consensus to determine what is MUST (mandatory to implement)

Is it possible for the providers/consumers to implement the broker/proxy interfaces directly? In other words, in the most simplistic implementation case, can providers/consumers directly negotiate about tasking/formats without an intermediary? If so, what functions are required for each “side” of the communication?
[NCW]  Yes, it is possible for each entity to provide their own control plane interface.  They will need to provide their own (effective AAA services), that is the means to authenticate, authorize and manage the consumption or production of information for all the subscribers or publishers respectively.  More importantly, they would have to handle the identity and policy management.

Does this approach restrict the use of DNS SRV records  [RFC2782] for basic service discovery (e.g., identifying potential providers or consumers)?
[NCW] I do not believe so.

Can the providers/consumers work with an existing authorization provider within the enterprise or does this require a specialized SACM component?
[NCW] The intent, especially in defining the control plane is to allow for SACM to leverage/piggyback the already existing authorization mechanisms (as well as authentication mechanisms too)

Also, one typo in section 2.3: “R's may request information independent of knowing the identities of the P's and Providers (P's)”

Is the first “P’s” a consumer or is this intended to just read “identities of the P's”?
[NCW] the P is a Provider.  The intent is to state that a Requestor may just want information from the enterprise knowing that the control plane is handling the authentication and authorization of all the Providers; similarly an enterprise can set up all the Providers to authenticate directly to the control plane to publish information without the Providers needing to authenticate all the Requestors.

Thanks,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Monday, July 07, 2014 3:39 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] Comments on draft-camwinget-sacm-architecture-00

General:

Section 2.1:

Thanks,
Dave