Subject: [sacm] Fwd: Endpoint ID Design Team Notes: 2015-10-23

From: "Adam W. Montville" <[email-masked]>
Date: Sat, 14 Nov 2015 19:03:51 -0600

Forwarding for Gunnar…  Response to his comments inline also.

> Begin forwarded message:
> 
> From: Gunnar Engelbach <[email-masked] <mailto:[email-masked]>>
> Date: November 14, 2015 at 3:49:07 PM CST
> To: "Adam W. Montville" <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23
> 
> 
> 
> On 11/13/2015 7:57 PM, Adam W. Montville wrote:
>> The complete thread from this message has been an interesting read.  Here are some possible conclusions based on what I've read from the entire conversation (in no particular order; some are potentially obvious; there may be others).
>> 
>> * Endpoint identification is different from the notion of applicability.
>> 
>> * Asset management requires endpoint identification
>> 
>> * Vulnerability and configuration assessment depend on asset management
>> 
>> * Segregation of collection and evaluation adds requirements to asset management: Capture information suitable for applicability
>> 
>> * Applicability is likely to require an applicability language, which may, in part, rely on endpoint identification (SW and/or HW) elements
>> 
>> * Determining applicability will require accommodating a mix of mechanisms (i.e. SWID, CPE, OVAL, or similar)
>> 
>> Also from the thread are some outstanding questions (there may be others):
>> 
>> * For Gunnar: Can you identify places in our use cases where SWIDs don't (can't??) apply?
> 
> This seems to me like the wrong question to ask.  SWIDs are a potential source of useful data, but are not going to be universally available.

For the record, this wasn’t my question, but one from Jess (IIRC).

> 
> More important is to consider how the automated guidance, the benchmarks, are going to be expressed.  That's what drives the expression of what to collect and how to interpret the returned data, and needs to be based on something that is reliably available.  Facilities of the base operating system can be relied up as available, but SWIDs cannot.
> 
> 
> Or is the thought that SWIDs will be used as the data model?  They won't work for that, either.  First because they don't cover the entirety of the attributes that need to be collected, so it will be necessary to have some other data model.  Second, because even for the areas they do cover well the information they contain is incomplete:  no audit categories, ACLs, SELinux settings, etc ( http://standards.iso.org/iso/19770/-2/2009/schema.xsd <http://standards.iso.org/iso/19770/-2/2009/schema.xsd> ).

Given some of the conclusions I wrote about above, it still seems that SWID is one of several potential mechanisms offering benefit to SACM’s scope.  Is SWID _the_ answer for all of our identification/applicability needs?  Not now. Probably never.

But, can we agree that considering SWID for specific uses within SACM is something we should explore?

> 
> 
>> 
>> * Have we done enough work in the Endpoint ID design to start working on the endpoint identification issue within the information model?
>> 
>> * What work needs to be done on making applicability determinations?  (Seems that the foundation of this is being able to identify hardware and software.)
>> 
>> * How do we deal with the "chicken and egg" problem brought about by segregating evaluation from collection? (Gunnar raised this general point, from which I infer that the asset management database will need to be continually updated.)
>> 
>> I have a thought on that last question.  Because we're separating evaluation from collection, and we have a chicken/egg problem, do we need to stress over that?  Yes, there's the possibility for a "miss" when an evaluation is performed on data stored in the CMDB/datastore, but this is a problem that's been solved in other domains.  Consider page files and what happens when an OS looks for a page in memory that doesn't exist.  It goes out to disk to find it.  We could do something similar with an option for the CMDB and/or the collector itself to remember the missed request, so that it's not missed in the future.  (We're doing this anyway with stale data, so it doesn't feel like a stretch.)
>> 
>> Kind regards,
>> 
>> Adam
>> 
>> 
>> On 10/23/2015 12:33 PM, Haynes, Dan wrote:
>>> Hi Everyone,
>>> 
>>> Here are the notes from today’s Endpoint ID Design Team Meeting (EID-DT).
>>>  
>>> Attendees
>>> ·         Ron Colvin
>>> ·         Josh Stevens
>>> ·         Joe Wolfkiel
>>> ·         Danny Haynes
>>>  
>>> Note Well
>>>  
>>> Agenda
>>> ·         Task descriptions
>>> ·         Open issues from the last virtual interim meeting
>>> ·         Next steps
>>>  
>>> Materials
>>> ·         Slides from meeting (see attached)
>>> ·         Task descriptions (see attached).  
>>>  
>>> Notes
>>> ·         First, the task descriptions document was discussed.  All the discussion and feedback around this was captured in Word comments in the document.  An updated version based on feedback and discussion, will be sent out prior to the next EID-DT meeting.
>>>  
>>> ·         A question was asked about where we were at with the Architecture document.  It was explained that we have made a lot of good progress recently during the two calls after the virtual interim meeting and that notes for those meetings were captured in the GitHub issue trackers that were discussed.  It was also noted that if anyone had feedback on the Architecture that they should send it out to the group sooner rather than later.
>>>  
>>> ·         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as “these are all the devices owned by an organization”, or “these are all the devices in a single location”.  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive information, and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.
>>>  
>>> Action Items
>>> ·         Update tasks descriptions before next EID-DT meeting (Danny Haynes)
>>> ·         Contribute NetD data model  (Joe Wolfkiel).
>>>  
>>> Please let me know if I missed anything, got anything wrong, or if you have any questions.
>>>  
>>> Thanks,
>>> 
>>> Danny
>>> 
>>> 
>>> _______________________________________________
>>> sacm mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
>> 
>> 
>> 
>> _______________________________________________
>> sacm mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
>