Subject: [sacm] Endpoint ID Design Team Notes: 2015-06-05

From: "Adam W. Montville" <[email-masked]>
Date: Mon, 8 Jun 2015 06:59:11 -0500

Thanks to Danny for helping out with the meeting and taking these notes…  Meeting recording will be uploaded shortly.

Attendees
Henk Birkholz
Cliff Kahn
Lisa Lorenzin
Danny Haynes
 
Note Well
 
Agenda
Progress from past week on the endpoint identity outline for the information model
Next Steps
 
Materials
[1] https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0 <https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0>
[2] http://www.ietf.org/mail-archive/web/sacm/current/msg02850.html <http://www.ietf.org/mail-archive/web/sacm/current/msg02850.html>
[3] http://www.ietf.org/mail-archive/web/sacm/current/msg02851.html <http://www.ietf.org/mail-archive/web/sacm/current/msg02851.html>
[4] http://www.ietf.org/mail-archive/web/sacm/current/msg02849.html <http://www.ietf.org/mail-archive/web/sacm/current/msg02849.html>
 
Notes
First, the Endpoint ID Design Team discussed Cliff’s message [2] which included a proposed template for describing identifying attributes in Section 4.x.1.  The IP address attribute was used in the template.  Out of this discussion a few important points were raised.  It was mentioned that unicast might only be associated with IPv4 and that we should also include statements saying that it must not be a broadcast or multicast address.  There was a suggestion that the information about the source of the attribute value should be captured.  The source could be categorized as internally collected (e.g. collected directly from the endpoint), externally collected through assignment (e.g. DHCP server assigned an endpoint an IP address), or externally collected through observation (e.g. sensor on the network).  It was also raised how a NETCONF client could be considered an internal collector because it collects data directly off of the endpoint.  It was then suggested that we may need to stop thinking about the location of the components and instead think about the location of the data as it is more important.  This will probably require modifications to the definitions of internal and external collectors.  Next, it was suggested that multiplicity consider cases such as 0-or-more values.  For example, a RADIUS server may provide an assertion about an endpoint, but, it will not have an IP address to associate with it.  It was asked whether or not we should be stating, in the information model, that a particular attribute should or should not be required in a data model.  The group agreed that the information model should explicitly include this type of information.
 
Second, the Endpoint ID Design Team reviewed and discussed Joe’s message [3] which discussed how some attributes may only be valuable when paired with other attributes (e.g. IP address and MAC address).  The group agreed this was an important point and should be accounted for in the information model and that a flat structure of attributes, as currently written, probably wouldn’t support this.
 
Next, the Endpoint ID Design Team reviewed and discussed Henk’s message [4] which provided some additional information about the use of raw assertions in Section 4.y and associated attributes in Section 4.x.3.  Out of this discussion a few important points were raised.  The group agreed there needs to be further discussion around whether or not identity is asserted with collected data versus assessed data.  It was also mentioned that it is confusing to say an endpoint has an identity as identity, for us, is just a verb to decide if we are talking about the same endpoint (i.e. correlation) which is slightly different than using the same information to acquire guidance which is more aligned with characterization.  It was agreed the information model should also include text to better distinguish between identity and characterization.  Furthermore, the group agreed that identity is likely built up by multiple SACM components rather than just an individual SACM component and that they want to further discuss reliable assertions versus lower level assertions that don’t necessarily provide that.  Next, a question was asked as to whether or not there is a need to label associations between attributes.  The group was leaning towards that it is probably necessary because a collector can create an association between an endpoint and the assertions of identifying attributes.  It was also clarified that if there were multiple relationships, we would also likely need labels to distinguish them.  Processes, containers, and virtual machines were given as examples where these relationships may need to be provided.  Lastly, it was discussed as to whether or not the information model diagram needed to be updated to highlight that it could be modeled as a graph of triples (e.g. left, right, and relationship).  Given that this would represent a significant change, Henk offered to discuss it with the other draft editors before proposing any changes.
 
Action Items for Next Week
Add a section for “source” to the template for describing an attribute in Section 4.x.1 (Cliff Kahn)
Propose text for Section 4.x.5 (Lisa Lorenzin)
Create a table explaining the different categories that describe the source of the data (Lisa Lorenzin)
Start to put together the catalog for Section 4.x.2 (Dave Waltermire)
Reach out to other draft editors to determine if the information model diagram should be updated to say it could be modeled as a graph of triples (Henk Birkholz)

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 8 Jun 2015 12:41:49 +0000

For consideration, I've attaches some sample DOD ARF that contains many of the identifiers being used to correlate device identity between our host-based protection management console and our vulnerability scanner.

Rather than just have a bunch of attributes in a big document, we use the identifiers where they fit in a "device" data model.  In this model, IP and MAC address are associated with network interfaces.  Software GUIDs would be associated with their respective piece of software, in a software inventory.

Hardware/firmware GUIDs and serial numbers would best fit in a hardware inventory construct.  The only construct that I haven't really found a good "place" for is the FQDN, which goes in a "device identifiers" section, which would also include "synthetic identifiers" that would be identifiers assigned to a device in an asset management database.

Based on some research done in the DoD, I am pursuing motherboard serial number, BIOS GUID/UUID, and software GUIDs (like the GUID of our host-based management agent) as the "highest confidence" device identifiers.  The motherboard serial number is of interest because it will allow for correlation with our property management systems.  The BIOS GUID/UUID is of interest because, when copying VMs, the only way that I've heard consistently works to tell two copied VMs apart is to check the UUID.

To support the argument that a flat list of attributes probably isn't the best answer, I would like to point out that FQDNs are composed of Domain plus Host Name and that software GUIDs are only meaningful if they are packaged with the software name and respective GUID together.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Monday, June 08, 2015 7:59 AM
To: <[email-masked]>
Subject: [sacm] Endpoint ID Design Team Notes: 2015-06-05

Attendees
Henk Birkholz
Cliff Kahn
Lisa Lorenzin
Danny Haynes
 
Note Well
 
Agenda
 
Materials

[1] https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0

[2] http://www.ietf.org/mail-archive/web/sacm/current/msg02850.html

[3] http://www.ietf.org/mail-archive/web/sacm/current/msg02851.html

[4] http://www.ietf.org/mail-archive/web/sacm/current/msg02849.html

Notes

---

From: Jerome Athias <[email-masked]>
Date: Tue, 9 Jun 2015 08:41:49 +0300

Thanks for re-introducing* ARF (NISTIR 7694)
http://scap.nist.gov/specifications/arf/
with a bit of Asset Identification (NISTIR 7693)

Do you know if an AI/ARF extension (Geolocation in mind for example)
is planned?...

Regarding Virtual Machine, I remember that a good specification was
pointed out a while ago (unfortunately not captured at that time, lost
in my emails, or maybe was in the previous mailing-list).

Regarding FQDN, the Domain_Name_Object could potentially be defined
like http://cybox.mitre.org/language/version2.1/xsddocs/objects/Domain_Name_Object.html
See also (for DNS, NIS, NetBIOS)
http://cybox.mitre.org/language/version2.1/xsddocs/objects/Hostname_Object.html

* https://www.ietf.org/mail-archive/web/sacm/current/msg00508.html

2015-06-08 15:41 GMT+03:00 Wolfkiel, Joseph L CIV DISA ID (US)
<[email-masked]>:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 9 Jun 2015 13:55:28 +0000

Comments inline marked with [daw:].

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Tuesday, June 09, 2015 1:42 AM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Adam W. Montville; <[email-masked]>
Subject: Re: [sacm] Endpoint ID Design Team Notes: 2015-06-05

Thanks for re-introducing* ARF (NISTIR 7694) http://scap.nist.gov/specifications/arf/
with a bit of Asset Identification (NISTIR 7693)

[daw: We are willing to contribute these data models to SACM if there is interest.]

Do you know if an AI/ARF extension (Geolocation in mind for example) is planned?...

[daw: Geolocation is already supported using the ai:locations and ai:location-point elements in NIST7693.]

Regarding Virtual Machine, I remember that a good specification was pointed out a while ago (unfortunately not captured at that time, lost in my emails, or maybe was in the previous mailing-list).

Regarding FQDN, the Domain_Name_Object could potentially be defined like http://cybox.mitre.org/language/version2.1/xsddocs/objects/Domain_Name_Object.html
See also (for DNS, NIS, NetBIOS)
http://cybox.mitre.org/language/version2.1/xsddocs/objects/Hostname_Object.html

> Based on some research done in the DoD, I am pursuing motherboard serial number, BIOS GUID/UUID, and software GUIDs (like the GUID of our host-based management agent) as the "highest confidence" de…

[daw: +1. This is something we have discussed in the endpoint id design team as useful identification information. IMHO, this should be supported by SACM.]

> Progress from past week on the endpoint identity outline for the 
> information model Next Steps
>
> Materials
>
> [1] 
> https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?d
> l=0
>
> Add a section for “source” to the template for describing an attribute 
> in Section 4.x.1 (Cliff Kahn) Propose text for Section 4.x.5 (Lisa 
> Lorenzin) Create a table explaining the different categories that 
> describe the source of the data (Lisa Lorenzin) Start to put together 
> the catalog for Section 4.x.2 (Dave Waltermire) Reach out to other 
> draft editors to determine if the information model diagram should be 
> updated to say it could be modeled as a graph of triples (Henk 
> Birkholz)
>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Tue, 9 Jun 2015 20:09:25 +0000

Just to clarify, the NIST ARF is not the same as the DoD ARF example that I attached.  Maybe NIST could provide an equivalent document.  The DoD ARF background can be found at http://measurablesecurity.mitre.org/incubator/arf/

For IM vs DM discussion, I propose the best approach may be to build a general device model, possibly in UML and supporting data models expressed in XML and JSON, as a minimum.  I actually have an effort ongoing now to build much more efficient XML and JSON data models for transferring device data between systems using web services.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Work: (301) 225-8820
Gov Cell: (571) 814-8231

---

From: Jerome Athias <[email-masked]>
Date: Sun, 14 Jun 2015 13:17:46 +0300

Thanks for the clarification.
It makes total sense, IMHO, to work on asset models, where in the SACM
context, a device model (and its components?) appears to be
needed/requirement.
This would definitively help for evaluation of the TOE (Target of
Evaluation in ISO/IEC 15408).
I concur that UML, XML, JSON makes sense.
Happy trying to contribute

Best regards