Subject: [sacm] Endpoint ID Design Team Update: 2015-03-13

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 13 Mar 2015 11:29:13 -0500

The Endpoint ID Design Team met again today (notes below).  The recording is available here: https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0 <https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0> 

Also, be aware that this design team will not be meeting next week (2015-03-20).

SACM Endpoint ID Design Team Notes
2015-03-13
==================================

Agenda

	Reminder:
		- WebEx Chat and SACM Jabber Room
		- Recording will be (is) enabled
	Today
		- Scenario Discussion
		- Discussion on updating information model
	Next Up
		- Review priorities
		- Capture recommendations for concepts needing additional work
	Discussions To Have
		- Pruning Discussions
			* "Sufficient" for "primary" identity attributes
			* Is "account" as an identity attribute in scope?
		- BIOS/Firmware information for identification
		- Should ASCII diagram survive as-is?
		- Provenance Discussion (W3C considerations)

Attendees:
	Danny Haynes
	David Waltermire
	Ron Colvin
	Adam Montville
	Jim Bieda
	Henk Birkholz
	Clifford Kahn

Overview
========
Reviewing Danny's scenario (we have concluded that we would view this as a "classic IT scenario").  He notes that "guidance" isn't defined in the terminology draft (this is something that we need to do).  There's a controller out there and it needs to get information without really knowing where that information resides on the network.  How do we contact that controller?  This could be endpoint identity information.  

Dave has some opinions.  There are a couple of points.  It's possible to get the guidance from a repository and that it would go through a controller.  One of the things introduced is that identity information isn't limited to scoping results but may also be important for determining appropriate guidance for the device.  How the endpoint authenticates to the controller/repository aside, it seems to Dave that this identifying information might be part of the query for guidance acquisition.  As part of that you may need to identify the endpoint properly in terms of criticality, organizational stature, etc.  It seems that endpoint identity may or may not be sufficient for class selection.  

We're having a good discussion about classifying endpoints for targeting and guidance acquisition.

Endpoint classification may depend on endpoint identification.  The endpoint doesn't need to know what class it's in, but it needs to report what it knows.  

Cliff is asking how does a controller know which guidance applies to an endpoint?  The guidance will need to have some notion of endpoint class, even perhaps targeted to a specific endpoint in some cases, within it.  

If we presume that endpoints provide identifying information at the point of registration, then we may not need to include endpoint class information in guidance.  However, in order to express guidance, we need to describe to what that guidance applies.  We could consider "class" as the result of a query: What are all the endpoitns with attributes x, y, and z.

When looking at "Atrributes Provided/Needed", we're discussing what is sufficient for identification of hardware, software, and configuration inventory.  Cliff mentioned that he knows SWID, but also recognizes that there's a desire to include other identification schemes.  So, given a particular identification scheme, what does that scheme need to provide to be relied upon?

It seems reasonable to expect that we'll need unique identifiers for software (i.e. class of software), software instances, hardware, attributes, etc.  We will likely need a set of things to rely on rather than one model.  This issue will need to be explored further.  For purposes of applying guidance, a lot of things are relevant.

Danny: Key thing: associate posture attributes with that endpoint (particularly useful when sticking that information in a datastore).  In the information model we came up with a list of identifying attributes and said whatever attributes are available, then these (if available) should be used.  It was unclear about which ones are really needed vs. which ones we didn't need.  This might vary by endpoint type.   

Not every usage scenario is going to need every identity attribute we've been discussing.  What we want to look at is what is the comprehensive set of attributes for a paritcular usage scenario.  It might make sense to talk about what attributes might be physically available?

Perhaps endpoint type (i.e. class) is important when considering which identity attributes are important.

Or, we need to have some concept of the important dimensions to define around the scenarios.  Danny is suggesting that there's four different types of endpoints.  Traditional, mobile, network devices, constrained (ICS, etc.).  Then you might have other endpoints that are composed of different endpoints.  There seems to be some agreement on figuring these wide endpoint classes for the sake of simplifying conversation and potentially to scope our work efforts moving forward.  Cliff is suggesting that such things might be considered in the requirements document.

Cliff is specifically mentioning BYOD, and it seems that there's some agreement that this will need to be considered, but not as a separate category of endpoints (they need to be considered as managed vs. unmanaged within those categories).  This might be a case where we want to know compliance without knowing identity (in the context of "managed").  

Henk is pointing out that we inherently know identity to some degree - we have an anchor of some type to an entity.  This has to be reidentified over time.  We may not be setting things out this way.  This might be the tension between good-enough identification while retaining good-enough privacy?

Danny's scenario identifies related requirements: G-014 Target Endpoint Identity, IM-001 Extensible Attribute Dictionary, and IM-002 Ephemerality.  Do we wnat to include other requirements as being associated with such a scenario?  What identifying attributes do we wnat to make a strong recommendation as being commonly provided?  

Future Discussion Points
========================

	* Discuss identification information from bios/firmware (e.g. serial numbers, asset tags, VM id) that can be queried on the device using software
	* Provenance information from W3C PROV
	* Is "account" as an identity attribute in scope?
	* Should *the* ASCII diagram survive as-is, or should it be replaced (with something more robust) or broken apart?  Is the diagram something we want to explicitly state as being normative?
	* Scenario for external collection
	* Explore how guidance is applied
	* Tension between endpoint identity and entity privacy (BYOD context)

NEXT STEPS (Agenda Items to track)
==================================

	* Dedicate next week's time to developing scenarios for pruning
	* Review priorities that need to get done
	* Potentially come up with recommendations regarding additional concepts needing work