Subject: [sacm] Thoughts on the SACM architecture

From: Trevor Freeman <[email-masked]>
Date: Tue, 13 May 2014 23:09:46 +0000

Hi All,
Here are my thoughts on yesterday's call.

We have use case for collecting posture attributes from end points. We have a set of standards from NEA on how to collect the data from and end point. A repository could have other sources of attributes besides those collected by NEA i.e. a sensor is not mandated to use NEA to exchange attributes with a repository.

Attribute can be of several types.

*         3rd party observed by another end point

*         Self-asserted from the device

*         Hardware rooted from the device

*         Derived by 3rd party from other attributes
Some attributes are tied to the time of collection or observation, others would have a lifetime.

The binding of the attributes to the end point also has different levels of assurance.
Level 0 - via public data e.g. a MAC address
Level 1 - self asserted identity via an unmanaged secret == 800-63 level 1
Level 2 - minimal verification, minimally protected secret  == 800-63 level 2
Level 3 - moderate verification, moderately protected secret == 800-63 level 3
Level 4 - high verification, highly protected secret == 800-63 level 4

We have a set of SACM clients who want to query for attributes about end points for a variety of reasons from our usage scenarios. That can be checklist verification, deviation detection, analysis etc. The SACM clients can have their own SACM repository i.e. it's an aggregator, or it could write back any derived attributes to the same repository.

This seems in line with Nancy's slide.

MILE has approached the problem of access control to the IODEF data by marking the data. This seems a much more scalable solution than proposing centralized control servers. We live in a federated world were SACM repositories will be numerous and distributed. Some of the endpoints are on-premise and some in the cloud and  some could belong to my partner. A SACM client will have to change down the data from many repositories.

I have updates my architecture diagram to reflect yesterday's discussion.

So far based on the use cases, I hear the need for a posture attribute collection standard - which we have in NEA, and a SACM posture attribute query\response standard which is tbd. IF-MAP was not a good candidate here so we should look at RID to see if that fits.

Trevor

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 27 May 2014 06:19:16 +0000

Hi Trevor,

Right, the information model will need to define the taxonomy for well understood attributes (and likely define some of the mandatory to implement).  So, my question to the group is that there may be "several" such examples NEA being one, IODEF being another so not sure if we are striving to converge to one or allow for coexistence?

Based on the ad hoc group, I've attached the updated slides that we can discuss with the working group on a potential architecture.

Thanks, Nancy.

From: Trevor Freeman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 4:09 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] Thoughts on the SACM architecture

Hi All,
Here are my thoughts on yesterday’s call.

·         3rd party observed by another end point

·         Self-asserted from the device

·         Hardware rooted from the device

·         Derived by 3rd party from other attributes
Some attributes are tied to the time of collection or observation, others would have a lifetime.

The binding of the attributes to the end point also has different levels of assurance.
Level 0 – via public data e.g. a MAC address
Level 1 – self asserted identity via an unmanaged secret == 800-63 level 1
Level 2 – minimal verification, minimally protected secret  == 800-63 level 2
Level 3 – moderate verification, moderately protected secret == 800-63 level 3
Level 4 – high verification, highly protected secret == 800-63 level 4

We have a set of SACM clients who want to query for attributes about end points for a variety of reasons from our usage scenarios. That can be checklist verification, deviation detection, analysis etc. The SACM clients can have their own SACM repository i.e. it’s an aggregator, or it could write back any derived attributes to the same repository.

This seems in line with Nancy’s slide.

I have updates my architecture diagram to reflect yesterday’s discussion.

So far based on the use cases, I hear the need for a posture attribute collection standard – which we have in NEA, and a SACM posture attribute query\response standard which is tbd. IF-MAP was not a good candidate here so we should look at RID to see if that fits.

Trevor