Subject: Re: [sacm] Proposed Updates to the Structure of the Information Model Draft

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 26 Aug 2015 18:16:39 +0000

I just wanted to follow-up on this thread.

So far, there has been some discussion around how to classify a network interface (hardware component vs. software component vs. software interface).  I think this is a good discussion and should definitely continue.

However, I haven't heard any feedback on the proposed changes to the structure of the Information Model listed below.  Without any feedback from the broader group, unless there are objections, I am inclined to make these changes to the structure of the Information Model because members of the Endpoint ID Design Team were in favor of them, they will give us a good framework from which to fill out the document moving forward, and so that the changes get captured in a document and don't just get lost on the list.

I would like to have all of these changes to the Information Model addressed prior to the SACM Virtual Interim Meeting on September 24th so that we can discuss them then and if we decide to take the approach of shifting our focus to solution drafts, we will have a good stopping point.

Please let me know what you think.  All feedback is greatly appreciated.

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Wednesday, August 19, 2015 12:42 PM
To: [email-masked]
Subject: [sacm] Proposed Updates to the Structure of the Information Model Draft

During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], we have discussed proposed changes to the structure of the Information Model draft.  The general consensus among the members, at the last two EID-DT meetings, was that the proposed changes to the structure of the Information Model were reasonable and should be accepted into the Information Model draft.  Given that, we wanted to propose these changes to the broader working group for feedback prior to making any updates to the draft.

Here is a summary of the proposed changes.

*         Combine the "Introduction" and "Problem Statement" sections.  Move the "Changes in Revision 01", "Changes in Revision 02", and "Mapping to SACM Use Cases" to an Appendix.

*         Add an "Information Model Framework" section.  This section describes the core concepts, constructs, and relationships that are used to model Assets and Elements in the Information Model.

*         Add an "Information Model Assets" section.  This section defines the different types of Assets used in the Information Model and the relationships between them.

*         Add an "Information Model Elements" section.  This section defines specific concrete constructs to be implemented by data models.  One example of this might be a network address as described in Lisa's Terminology Meeting Notes [3].  This section will absorb the current "Elements of the SACM Information Model" section.

For more information about the proposed changes, please see the latest draft of the Information Model table of contents (updated-im-toc-814.docx) which I have attached for your convenience.  There are also some other open questions in the comments of the document such as whether or not a few sections can be deleted.  It would be great to get feedback on these as well if you have time, but, I would say getting feedback on the changes listed above is the most critical.  I can always just open issue trackers for the remaining questions and they can be addressed later.

If there is consensus that these changes make sense, I will update the Information Model draft in GitHub.  I will also add a sentence or two, for each section, to capture what information should go there.  This will be especially important if the working group decides to table the core working group documents (Requirements, Architecture, and Information Model) drafts in favor of working on solution drafts as is being discussed on the list [4].  By the way, if you haven't chimed in on this thread please do :) as this decision will impact how the working group proceeds moving forward in the short term.

Anyways, please let me know what you think about these changes or if you have any questions.  I look forward to hearing your feedback.

Thanks,

Danny

[1] 8/7 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html
[2] 8/14 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html
[3] Terminology Notes http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html
[4] Short Term Path Forward http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html

---

From: Ira McDonald <[email-masked]>
Date: Wed, 26 Aug 2015 14:46:04 -0400

Hi Danny,

+1

Please make all of the proposed changes to the structure of the SACM Info
Model.

Afterward, we can go on splitting hairs but have a much better document
organization
that reflects our current understanding of the problem space.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Aug 26, 2015 at 2:16 PM, Haynes, Dan <[email-masked]> wrote:

> So far, there has been some discussion around how to classify a network
> interface (hardware component vs. software component vs. software
> interface).  I think this is a good discussion and should definitely
> continue.
>
>
>
> However, I haven’t heard any feedback on the proposed changes to the
> structure of the Information Model listed below.  Without any feedback from
> the broader group, unless there are objections, I am inclined to make these
> changes to the structure of the Information Model because members of the
> Endpoint ID Design Team were in favor of them, they will give us a good
> framework from which to fill out the document moving forward, and so that
> the changes get captured in a document and don’t just get lost on the list.
>
>
>
> I would like to have all of these changes to the Information Model
> addressed prior to the SACM Virtual Interim Meeting on September 24th so
> that we can discuss them then and if we decide to take the approach of
> shifting our focus to solution drafts, we will have a good stopping point.
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Haynes, Dan
> *Sent:* Wednesday, August 19, 2015 12:42 PM
> *To:* [email-masked]
> *Subject:* [sacm] Proposed Updates to the Structure of the Information
> Model Draft
>
>
>
> During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], we
> have discussed proposed changes to the structure of the Information Model
> draft.  The general consensus among the members, at the last two EID-DT
> meetings, was that the proposed changes to the structure of the Information
> Model were reasonable and should be accepted into the Information Model
> draft.  Given that, we wanted to propose these changes to the broader
> working group for feedback prior to making any updates to the draft.
>
>
>
> ·         Combine the “Introduction” and “Problem Statement” sections.
> Move the “Changes in Revision 01”, “Changes in Revision 02”, and “Mapping
> to SACM Use Cases” to an Appendix.
>
>
>
> ·         Add an “Information Model Framework” section.  This section
> describes the core concepts, constructs, and relationships that are used to
> model Assets and Elements in the Information Model.
>
>
>
> ·         Add an “Information Model Assets” section.  This section
> defines the different types of Assets used in the Information Model and the
> relationships between them.
>
>
>
> ·         Add an “Information Model Elements” section.  This section
> defines specific concrete constructs to be implemented by data models.  One
> example of this might be a network address as described in Lisa’s
> Terminology Meeting Notes [3].  This section will absorb the current
> “Elements of the SACM Information Model” section.
>
>
>
> For more information about the proposed changes, please see the latest
> draft of the Information Model table of contents (updated-im-toc-814.docx)
> which I have attached for your convenience.  There are also some other open
> questions in the comments of the document such as whether or not a few
> sections can be deleted.  It would be great to get feedback on these as
> well if you have time, but, I would say getting feedback on the changes
> listed above is the most critical.  I can always just open issue trackers
> for the remaining questions and they can be addressed later.
>
>
>
> If there is consensus that these changes make sense, I will update the
> Information Model draft in GitHub.  I will also add a sentence or two, for
> each section, to capture what information should go there.  This will be
> especially important if the working group decides to table the core working
> group documents (Requirements, Architecture, and Information Model) drafts
> in favor of working on solution drafts as is being discussed on the list
> [4].  By the way, if you haven’t chimed in on this thread please do :) as
> this decision will impact how the working group proceeds moving forward in
> the short term.
>
>
>
> Anyways, please let me know what you think about these changes or if you
> have any questions.  I look forward to hearing your feedback.
>
>
>
> Thanks,
>
> Danny
>
>
>
> [1] 8/7 EID-DT Meeting
> http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html
>
> [2] 8/14 EID-DT Meeting
> http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html
>
> [3] Terminology Notes
> http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html
>
> [4] Short Term Path Forward
> http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html
>
>
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 26 Aug 2015 15:29:18 -0400

A)
 From my understanding of how it is diagrammed in the reference to 
Lisa's note, a more complete entry for an address would look like this:

   container: network address
       container: IP address
           container: IPv4 address
             192.168.0.1
           container: IPv6 address
             fe80::20c:29ff:fe19:8af8
       container: MAC address
         00:0C:DE:AD:BE:EF
       container: timestamp
         2015-08-22T13:16:12.2345

and should also include parent containers for the interface, et al.

This is a workable representation, and possibly necessary if the goal is to fit information about network addresses into a common data format, but I want to be sure it's clear that the tuple of address + mac + timestamp needs to be considered as a whole because each part can be ephemeral.
It also can't be counted on that all three pieces of data will be available for correlation, with the reliability dependent on which items are available.  A rough list, in order of reliability, would be:

   IP
   MAC
   IP + MAC
   IP + timestamp
   MAC + timestamp
   IP + MAC + timestamp

Having a timestamp available greatly increases the reliability of an address as an identifier, but only if it can assured that the timestamp is accurately coordinated, which is a nontrivial problem and therefore likely to not be available.

Would this data structure also then need to include information that could be used to determine the reliability of the timestamp (such as time source, interval since last time check, amount of drift within that interval), or would that be handled at a higher level?  If handled at a higher level, would that mechanism also allow for tracking of intervals during which the reliability of that source was at a different level of reliability?

B)
A complete enumeration of the addresses on a device has diminishing 
value from the perspective of asset identification.  Some address types 
don't add any significant information.  Loopback addresses, for 
example.  Same, to a large degree, with multicast, unicast, PtP, etc.

On 8/26/2015 2:16 PM, Haynes, Dan wrote:
> So far, there has been some discussion around how to classify a 
> network interface (hardware component vs. software component vs. 
> software interface).  I think this is a good discussion and should 
> definitely continue.
>
> structure of the Information Model listed below.  Without any feedback 
> from the broader group, unless there are objections, I am inclined to 
> make these changes to the structure of the Information Model because 
> members of the Endpoint ID Design Team were in favor of them, they 
> will give us a good framework from which to fill out the document 
> moving forward, and so that the changes get captured in a document and 
> don’t just get lost on the list.
>
> addressed prior to the SACM Virtual Interim Meeting on September 24^th 
> so that we can discuss them then and if we decide to take the approach 
> of shifting our focus to solution drafts, we will have a good stopping 
> point.
>
> During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], 
> we have discussed proposed changes to the structure of the Information 
> Model draft.  The general consensus among the members, at the last two 
> EID-DT meetings, was that the proposed changes to the structure of the 
> Information Model were reasonable and should be accepted into the 
> Information Model draft.  Given that, we wanted to propose these 
> changes to the broader working group for feedback prior to making any 
> updates to the draft.
>
> ·Combine the “Introduction” and “Problem Statement” sections.  Move 
> the “Changes in Revision 01”, “Changes in Revision 02”, and “Mapping 
> ·Add an “Information Model Framework” section.  This section describes 
> the core concepts, constructs, and relationships that are used to 
> ·Add an “Information Model Assets” section.  This section defines the 
> different types of Assets used in the Information Model and the 
> ·Add an “Information Model Elements” section.  This section defines 
> specific concrete constructs to be implemented by data models.  One 
> draft of the Information Model table of contents 
> (updated-im-toc-814.docx) which I have attached for your convenience.  
> There are also some other open questions in the comments of the 
> document such as whether or not a few sections can be deleted.  It 
> would be great to get feedback on these as well if you have time, but, 
> I would say getting feedback on the changes listed above is the most 
> critical.  I can always just open issue trackers for the remaining 
> questions and they can be addressed later.
>
> Information Model draft in GitHub.  I will also add a sentence or two, 
> for each section, to capture what information should go there.  This 
> will be especially important if the working group decides to table the 
> core working group documents (Requirements, Architecture, and 
> Information Model) drafts in favor of working on solution drafts as is 
> being discussed on the list [4].  By the way, if you haven’t chimed in 
> on this thread please do :) as this decision will impact how the 
> working group proceeds moving forward in the short term.
>
> Anyways, please let me know what you think about these changes or if 
> you have any questions.  I look forward to hearing your feedback.
>
> Thanks,
>
> Danny
>
> [1] 8/7 EID-DT Meeting

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Wed, 26 Aug 2015 19:50:48 +0000

We're collecting (per interface) DNS FQDN, IPv6, IPv4, MAC, DNS server, interface name (e.g. "ethernet0"), and default gateway in our current tool.  Timestamps are generally accurate to within a few hours based on out-of-sync clock errors and different timezone problems.  At some point, we also plan to collect DNS server IP address and network DNS domain.

We have mixed equities in the network interface information in that it has identifiers mixed together with data that is useful for network mapping.  We have some other use cases, such as identifying VMs by looking for "VMWare" in one or more of the interface names on an endpoint.

If SACM doesn't support network mapping or device characterization use cases, you may choose to not support all the data elements we're collecting.

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 Gunnar Engelbach
Sent: Wednesday, August 26, 2015 3:29 PM
To: Haynes, Dan; [email-masked]
Subject: Re: [sacm] Proposed Updates to the Structure of the Information Model Draft

A) From my understanding of how it is diagrammed in the reference to Lisa's note, a more complete entry for an address would look like this: container: network address container: IP address container: IPv4 address 192.168.0.1 container: IPv6 address fe80::20c:29ff:fe19:8af8 container: MAC address 00:0C:DE:AD:BE:EF container: timestamp 2015-08-22T13:16:12.2345 and should also include parent containers for the interface, et al. This is a workable representation, and possibly necessary if the goal is to fit information about network addresses into a common data format, but I want to be sure it's clear that the tuple of address + mac + timestamp needs to be considered as a whole because each part can be ephemeral. It also can't be counted on that all three pieces of data will be available for correlation, with the reliability dependent on which items are available. A rough list, in order of reliability, would be: IP MAC IP + MAC IP + timestamp MAC + timestamp IP + MAC + timestamp Having 
 a timestamp available greatly increases the reliability of an address as an identifier, but only if it can assured that the timestamp is accurately coordinated, which is a nontrivial problem and therefore likely to not be available. Would this data structure also then need to include information that could be used to determine the reliability of the timestamp (such as time source, interval since last time check, amount of drift within that interval), or would that be handled at a higher level? If handled at a higher level, would that mechanism also allow for tracking of intervals during which the reliability of that source was at a different level of reliability? B) A complete enumeration of the addresses on a device has diminishing value from the perspective of asset identification. Some address types don't add any significant information. Loopback addresses, for example. Same, to a large degree, with multicast, unicast, PtP, etc. On 8/26/2015 2:16 PM, Haynes, Dan wrote: I just wan
 ted to follow-up on this thread. So far, there has been some discussion around how to classify a network interface (hardware component vs. software component vs. software interface). I think this is a good discussion and should definitely continue. However, I haven't heard any feedback on the proposed changes to the structure of the Information Model listed below. Without any feedback from the broader group, unless there are objections, I am inclined to make these changes to the structure of the Information Model because members of the Endpoint ID Design Team were in favor of them, they will give us a good framework from which to fill out the document moving forward, and so that the changes get captured in a document and don't just get lost on the list. I would like to have all of these changes to the Information Model addressed prior to the SACM Virtual Interim Meeting on September 24th so that we can discuss them then and if we decide to take the approach of shifting our focus to 
 solution drafts, we will have a good stopping point. Please let me know what you think. All feedback is greatly appreciated. Thanks, Danny From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan Sent: Wednesday, August 19, 2015 12:42 PM To: [email-masked] Subject: [sacm] Proposed Updates to the Structure of the Information Model Draft During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], we have discussed proposed changes to the structure of the Information Model draft. The general consensus among the members, at the last two EID-DT meetings, was that the proposed changes to the structure of the Information Model were reasonable and should be accepted into the Information Model draft. Given that, we wanted to propose these changes to the broader working group for feedback prior to making any updates to the draft. Here is a summary of the proposed changes. . Combine the "Introduction" and "Problem Statement" sections. Move the "Changes in Revision 01", "Chan
 ges in Revision 02", and "Mapping to SACM Use Cases" to an Appendix. . Add an "Information Model Framework" section. This section describes the core concepts, constructs, and relationships that are used to model Assets and Elements in the Information Model. . Add an "Information Model Assets" section. This section defines the different types of Assets used in the Information Model and the relationships between them. . Add an "Information Model Elements" section. This section defines specific concrete constructs to be implemented by data models. One example of this might be a network address as described in Lisa's Terminology Meeting Notes [3]. This section will absorb the current "Elements of the SACM Information Model" section. For more information about the proposed changes, please see the latest draft of the Information Model table of contents (updated-im-toc-814.docx) which I have attached for your convenience. There are also some other open questions in the comments of the docu
 ment such as whether or not a few sections can be deleted. It would be great to get feedback on these as well if you have time, but, I would say getting feedback on the changes listed above is the most critical. I can always just open issue trackers for the remaining questions and they can be addressed later. If there is consensus that these changes make sense, I will update the Information Model draft in GitHub. I will also add a sentence or two, for each section, to capture what information should go there. This will be especially important if the working group decides to table the core working group documents (Requirements, Architecture, and Information Model) drafts in favor of working on solution drafts as is being discussed on the list [4]. By the way, if you haven't chimed in on this thread please do :) as this decision will impact how the working group proceeds moving forward in the short term. Anyways, please let me know what you think about these changes or if you have any
  questions. I look forward to hearing your feedback. Thanks, Danny [1] 8/7 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html [2] 8/14 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html [3] Terminology Notes http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html [4] Short Term Path Forward http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html _______________________________________________ sacm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 26 Aug 2015 16:11:47 -0400

* FQDN is a nicety for human readability, but doesn't add anything as 
far as identification goes, since it's just an alias for the IP address.

* Timestamps aren't an either/or proposition, but offer a gradation of 
certainty based on the accuracy of the timestamp and the data item.  An 
error margin of a couple hours is very significant if the lease time on 
the DHCP server is six hours, but not so significant if the lease time 
is a week.  Just an example, since DHCP lease time is not the only 
factor in the ephemerality of an IP address.

* In the model, as I understand it, interface name would be a value 
associated with a parent container.

* DNS server and default gateway don't appear to add much as far as 
identification go, but given the ubiquity of RFC-1918 addresses, could 
potentially be used to differentiate between two targets with the same 
IP address (but not completely, since it could actually be the same 
mobile device that participated on both networks).  Given the number of 
other more usable attributes available, these represent an edge case 
that is very unlikely to be encountered -- a case of diminishing returns.

As far as identifying VMWare, or other vendors, I think you'll find it 
more reliable to do a lookup on the vendor portion of the MAC address 
than to do a string match on the interface name.  You can find the MAC 
vendor table at IEEE.

--gun

On 8/26/2015 3:50 PM, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
> A) From my understanding of how it is diagrammed in the reference to Lisa's note, a more complete entry for an address would look like this: container: network address container: IP address container: IPv4 address 192.168.0.1 container: IPv6 address fe80::20c:29ff:fe19:8af8 container: MAC address 00:0C:DE:AD:BE:EF container: timestamp 2015-08-22T13:16:12.2345 and should also include parent containers for the interface, et al. This is a workable representation, and possibly necessary if the goal is to fit information about network addresses into a common data format, but I want to be sure it's clear that the tuple of address + mac + timestamp needs to be considered as a whole because each part can be ephemeral. It also can't be counted on that all three pieces of data will be available for correlation, with the reliability dependent on which items are available. A rough list, in order of reliability, would be: IP MAC IP + MAC IP + timestamp MAC + timestamp IP + MAC + timestamp Having a timestamp available greatly increases the reliability of an address as an identifier, but only if it can assured that the timestamp is accurately coordinated, which is a nontrivial problem and therefore likely to not be available. Would this data structure also then need to include information that could be used to determine the reliability of the timestamp (such as time source, interval since last time check, amount of drift within that interval), or would that be handled at a higher level? If handled at a higher level, would that mechanism also allow for tracking of intervals during which the reliability of that source was at a different level of reliability? B) A complete enumeration of the addresses on a device has diminishing value from the perspective of asset identification. Some address types don't add any significant information. Loopback addresses, for example. Same, to a large degree, with multicast, unicast, PtP, etc. On 8/26/2015 2:16 PM, Haynes, Dan wrote: I just wanted to follow-up on this thread. So far, there has been some discussion around how to classify a network interface (hardware component vs. software component vs. software interface). I think this is a good discussion and should definitely continue. However, I haven't heard any feedback on the proposed changes to the structure of the Information Model listed below. Without any feedback from the broader group, unless there are objections, I am inclined to make these changes to the structure of the Information Model because members of the Endpoint ID Design Team were in favor of them, they will give us a good framework from which to fill out the document moving forward, and so that the changes get captured in a document and don't just get lost on the list. I would like to have all of these changes to the Information Model addressed prior to the SACM Virtual Interim Meeting on September 24th so that we can discuss them then and if we decide to take the approach of shifting our focus to solution drafts, we will have a good stopping point. Please let me know what you think. All feedback is greatly appreciated. Thanks, Danny From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan Sent: Wednesday, August 19, 2015 12:42 PM To: [email-masked] Subject: [sacm] Proposed Updates to the Structure of the Information Model Draft During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], we have discussed proposed changes to the structure of the Information Model draft. The general consensus among the members, at the last two EID-DT meetings, was that the proposed changes to the structure of the Information Model were reasonable and should be accepted into the Information Model draft. Given that, we wanted to propose these changes to the broader working group for feedback prior to making any updates to the draft. Here is a summary of the proposed changes. . Combine the "Introduction" and "Problem Statement" sections. Move the "Changes in Revision 01", "Changes in Revision 02", and "Mapping to SACM Use Cases" to an Appendix. . Add an "Information Model Framework" section. This section describes the core concepts, constructs, and relationships that are used to model Assets and Elements in the Information Model. . Add an "Information Model Assets" section. This section defines the different types of Assets used in the Information Model and the relationships between them. . Add an "Information Model Elements" section. This section defines specific concrete constructs to be implemented by data models. One example of this might be a network address as described in Lisa's Terminology Meeting Notes [3]. This section will absorb the current "Elements of the SACM Information Model" section. For more information about the proposed changes, please see the latest draft of the Information Model table of contents (updated-im-toc-814.docx) which I have attached for your convenience. There are also some other open questions in the comments of the document such as whether or not a few sections can be deleted. It would be great to get feedback on these as well if you have time, but, I would say getting feedback on the changes listed above is the most critical. I can always just open issue trackers for the remaining questions and they can be addressed later. If there is consensus that these changes make sense, I will update the Information Model draft in GitHub. I will also add a sentence or two, for each section, to capture what information should go there. This will be especially important if the working group decides to table the core working group documents (Requirements, Architecture, and Information Model) drafts in favor of working on solution drafts as is being discussed on the list [4]. By the way, if you haven't chimed in on this thread please do :) as this decision will impact how the working group proceeds moving forward in the short term. Anyways, please let me know what you think about these changes or if you have any questions. I look forward to hearing your feedback. Thanks, Danny [1] 8/7 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html [2] 8/14 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html [3] Terminology Notes http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html [4] Short Term Path Forward http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html _______________________________________________ sacm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/sacm

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Wed, 26 Aug 2015 20:35:47 +0000

I disagree on the FQDN since it will tend to be persistent over time, while IP address may change due to DHCP updates as devices leave and return to a given network.  The binding of an IP address to a FQDN is not guaranteed or expected to be persistent.  In the matching logic that we have implemented, we have a higher confidence in FQDN than IP addresses.  In practice, we will not claim to have identified a device based on IP address alone.

That said, I'm not completely confident that FQDN should be tightly bound to an interface in the IM.  In our mixed environments, we collect both NetBIOS and DNS FQDNs.  The NetBIOS FQDNs are not directly related to any network interface, but the DNS FQDNs are associated with interfaces that are connected to a given domain.  So you can't say that FQDNs always behave the same, with respect to network relationships.  It's a matter of what type of FQDN you're discussing.

In the NetD data model that we're using, FQDNs are directly related to the device object and not associated with a given network interface.

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

-----Original Message-----
From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 4:12 PM
To: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [email-masked]
Subject: Re: [sacm] Proposed Updates to the Structure of the Information Model Draft

--gun

On 8/26/2015 3:50 PM, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
> A) From my understanding of how it is diagrammed in the reference to Lisa's note, a more complete entry for an address would look like this: container: network address container: IP address container: IPv4 address 192.168.0.1 container: IPv6 address fe80::20c:29ff:fe19:8af8 container: MAC address 00:0C:DE:AD:BE:EF container: timestamp 2015-08-22T13:16:12.2345 and should also include parent containers for the interface, et al. This is a workable representation, and possibly necessary if the goal is to fit information about network addresses into a common data format, but I want to be sure it's clear that the tuple of address + mac + timestamp needs to be considered as a whole because each part can be ephemeral. It also can't be counted on that all three pieces of data will be available for correlation, with the reliability dependent on which items are available. A rough list, in order of reliability, would be: IP MAC IP + MAC IP + timestamp MAC + timestamp IP + MAC + timestamp Havin
 g a timestamp available greatly increases the reliability of an address as an identifier, but only if it can assured that the timestamp is accurately coordinated, which is a nontrivial problem and therefore likely to not be available. Would this data structure also then need to include information that could be used to determine the reliability of the timestamp (such as time source, interval since last time check, amount of drift within that interval), or would that be handled at a higher level? If handled at a higher level, would that mechanism also allow for tracking of intervals during which the reliability of that source was at a different level of reliability? B) A complete enumeration of the addresses on a device has diminishing value from the perspective of asset identification. Some address types don't add any significant information. Loopback addresses, for example. Same, to a large degree, with multicast, unicast, PtP, etc. On 8/26/2015 2:16 PM, Haynes, Dan wrote: I just w
 anted to follow-up on this thread. So far, there has been some discussion around how to classify a network interface (hardware component vs. software component vs. software interface). I think this is a good discussion and should definitely continue. However, I haven't heard any feedback on the proposed changes to the structure of the Information Model listed below. Without any feedback from the broader group, unless there are objections, I am inclined to make these changes to the structure of the Information Model because members of the Endpoint ID Design Team were in favor of them, they will give us a good framework from which to fill out the document moving forward, and so that the changes get captured in a document and don't just get lost on the list. I would like to have all of these changes to the Information Model addressed prior to the SACM Virtual Interim Meeting on September 24th so that we can discuss them then and if we decide to take the approach of shifting our focus t
 o solution drafts, we will have a good stopping point. Please let me know what you think. All feedback is greatly appreciated. Thanks, Danny From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan Sent: Wednesday, August 19, 2015 12:42 PM To: [email-masked] Subject: [sacm] Proposed Updates to the Structure of the Information Model Draft During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], we have discussed proposed changes to the structure of the Information Model draft. The general consensus among the members, at the last two EID-DT meetings, was that the proposed changes to the structure of the Information Model were reasonable and should be accepted into the Information Model draft. Given that, we wanted to propose these changes to the broader working group for feedback prior to making any updates to the draft. Here is a summary of the proposed changes. . Combine the "Introduction" and "Problem Statement" sections. Move the "Changes in Revision 01", "Ch
 anges in Revision 02", and "Mapping to SACM Use Cases" to an Appendix. . Add an "Information Model Framework" section. This section describes the core concepts, constructs, and relationships that are used to model Assets and Elements in the Information Model. . Add an "Information Model Assets" section. This section defines the different types of Assets used in the Information Model and the relationships between them. . Add an "Information Model Elements" section. This section defines specific concrete constructs to be implemented by data models. One example of this might be a network address as described in Lisa's Terminology Meeting Notes [3]. This section will absorb the current "Elements of the SACM Information Model" section. For more information about the proposed changes, please see the latest draft of the Information Model table of contents (updated-im-toc-814.docx) which I have attached for your convenience. There are also some other open questions in the comments of the do
 cument such as whether or not a few sections can be deleted. It would be great to get feedback on these as well if you have time, but, I would say getting feedback on the changes listed above is the most critical. I can always just open issue trackers for the remaining questions and they can be addressed later. If there is consensus that these changes make sense, I will update the Information Model draft in GitHub. I will also add a sentence or two, for each section, to capture what information should go there. This will be especially important if the working group decides to table the core working group documents (Requirements, Architecture, and Information Model) drafts in favor of working on solution drafts as is being discussed on the list [4]. By the way, if you haven't chimed in on this thread please do :) as this decision will impact how the working group proceeds moving forward in the short term. Anyways, please let me know what you think about these changes or if you have a
 ny questions. I look forward to hearing your feedback. Thanks, Danny [1] 8/7 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html [2] 8/14 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html [3] Terminology Notes http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html [4] Short Term Path Forward http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html _______________________________________________ sacm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 26 Aug 2015 17:09:06 -0400

Au contraire.

A DNS FQDN is not an attribute of an endpoint, but a text alias held by 
an external server and presented when you give it an IP address. The 
absolute best you can hope for is that the DNS server remains as 
accurate as the IP address over time -- in which case it is just a more 
human-readable alias for the IP address.  The IP/DNS name mapping would 
have to remain immutable for this to be reliable, and even then the DNS 
name has no more reliability than the original IP address.

If you use Microsoft DNS with WINS, then there is a decent probability 
that the DNS name will change when the IP address assigned to a target 
changes, but that doesn't help with correlation.  Other collection 
points, such as an (IDS, log server, external scanner, network proxy, 
whatever), would have to had to have done a lookup at the same time via 
the same server in order to get the same value -- and that's just not 
something you can rely on.  More likely something like an IDS will only 
be collecting IP addresses -- when you then later try to correlate the 
entry on the IDS with your security scan you'll need to do a DNS lookup 
to convert that to the DNS identifier that your security scan is using:  
and you can't count on them matching.

There might be some value to collecting the DNS name as something you 
can present to a user about what that target was known as at that point 
in time, but in my experience, especially on internal networks, DNS is 
not maintained well enough for this to be of real use -- very often it 
causes problems by supplying erroneous data.

--gun

---

From: Ira McDonald <[email-masked]>
Date: Wed, 26 Aug 2015 17:12:06 -0400

Hi Gunnar,

With all due respect, that's not the way the real world of the Web works.
URI resolution
goes *from* and FQDN *to* and IP address - not the other way around.

IP addresses are also (in large enterprises) administratively assigned, not
inherent
aspects of a device.

Cheers,
- Ira

On Wed, Aug 26, 2015 at 5:09 PM, Gunnar Engelbach <
[email-masked]> wrote:

>
> Au contraire.
>
> A DNS FQDN is not an attribute of an endpoint, but a text alias held by an
> external server and presented when you give it an IP address. The absolute
> best you can hope for is that the DNS server remains as accurate as the IP
> address over time -- in which case it is just a more human-readable alias
> for the IP address.  The IP/DNS name mapping would have to remain immutable
> for this to be reliable, and even then the DNS name has no more reliability
> than the original IP address.
>
> changes, but that doesn't help with correlation.  Other collection points,
> such as an (IDS, log server, external scanner, network proxy, whatever),
> would have to had to have done a lookup at the same time via the same
> server in order to get the same value -- and that's just not something you
> can rely on.  More likely something like an IDS will only be collecting IP
> addresses -- when you then later try to correlate the entry on the IDS with
> your security scan you'll need to do a DNS lookup to convert that to the
> DNS identifier that your security scan is using:  and you can't count on
> them matching.
>
>
> There might be some value to collecting the DNS name as something you can
> present to a user about what that target was known as at that point in
> time, but in my experience, especially on internal networks, DNS is not
> maintained well enough for this to be of real use -- very often it causes
> problems by supplying erroneous data.
>
>
> --gun
>
>
>
>> I disagree on the FQDN since it will tend to be persistent over time,
>> while IP address may change due to DHCP updates as devices leave and return
>> to a given network.  The binding of an IP address to a FQDN is not
>> guaranteed or expected to be persistent.  In the matching logic that we
>> have implemented, we have a higher confidence in FQDN than IP addresses.
>> In practice, we will not claim to have identified a device based on IP
>> address alone.
>>
>> That said, I'm not completely confident that FQDN should be tightly bound
>> to an interface in the IM.  In our mixed environments, we collect both
>> NetBIOS and DNS FQDNs.  The NetBIOS FQDNs are not directly related to any
>> network interface, but the DNS FQDNs are associated with interfaces that
>> are connected to a given domain.  So you can't say that FQDNs always behave
>> the same, with respect to network relationships.  It's a matter of what
>> type of FQDN you're discussing.
>>
>> In the NetD data model that we're using, FQDNs are directly related to
>> the device object and not associated with a given network interface.
>>
>> Joseph L. Wolfkiel
>> SCM Engineering Lead
>> DISA ID52
>> Work: (301) 225-8820
>> Gov Cell: (571) 814-8231
>>> We're collecting (per interface) DNS FQDN, IPv6, IPv4, MAC, DNS server,
>>> interface name (e.g. "ethernet0"), and default gateway in our current
>>> tool.  Timestamps are generally accurate to within a few hours based on
>>> out-of-sync clock errors and different timezone problems.  At some point,
>>> we also plan to collect DNS server IP address and network DNS domain.
>>>
>>> We have mixed equities in the network interface information in that it
>>> has identifiers mixed together with data that is useful for network
>>> mapping.  We have some other use cases, such as identifying VMs by looking
>>> for "VMWare" in one or more of the interface names on an endpoint.
>>>
>>> If SACM doesn't support network mapping or device characterization use
>>> cases, you may choose to not support all the data elements we're collecting.
>>>
>>> Joseph L. Wolfkiel
>>> SCM Engineering Lead
>>> DISA ID52
>>> Work: (301) 225-8820
>>> Gov Cell: (571) 814-8231
>>> A) From my understanding of how it is diagrammed in the reference to
>>> container: network address container: IP address container: IPv4 address
>>> 192.168.0.1 container: IPv6 address fe80::20c:29ff:fe19:8af8 container: MAC
>>> address 00:0C:DE:AD:BE:EF container: timestamp 2015-08-22T13:16:12.2345 and
>>> should also include parent containers for the interface, et al. This is a
>>> workable representation, and possibly necessary if the goal is to fit
>>> information about network addresses into a common data format, but I want
>>> to be sure it's clear that the tuple of address + mac + timestamp needs to
>>> be considered as a whole because each part can be ephemeral. It also can't
>>> be counted on that all three pieces of data will be available for
>>> correlation, with the reliability dependent on which items are available. A
>>> rough list, in order of reliability, would be: IP MAC IP + MAC IP +
>>> timestamp MAC + timestamp IP + MAC + timestamp Havi
>>>
>> ng a timestamp available greatly increases the reliability of an address
> as an identifier, but only if it can assured that the timestamp is
> accurately coordinated, which is a nontrivial problem and therefore likely
> to not be available. Would this data structure also then need to include
> information that could be used to determine the reliability of the
> timestamp (such as time source, interval since last time check, amount of
> drift within that interval), or would that be handled at a higher level? If
> handled at a higher level, would that mechanism also allow for tracking of
> intervals during which the reliability of that source was at a different
> level of reliability? B) A complete enumeration of the addresses on a
> device has diminishing value from the perspective of asset identification.
> Some address types don't add any significant information. Loopback
> addresses, for example. Same, to a large degree, with multicast, unicast,
> PtP, etc. On 8/26/2015 2:16 PM, Haynes, Dan wrote: I just wanted to
> follow-up on this thread. So far, there has been some discussion around how
> to classify a network interface (hardware component vs. software component
> vs. software interface). I think this is a good discussion and should
> definitely continue. However, I haven't heard any feedback on the proposed
> changes to the structure of the Information Model listed below. Without any
> feedback from the broader group, unless there are objections, I am inclined
> to make these changes to the structure of the Information Model because
> members of the Endpoint ID Design Team were in favor of them, they will
> give us a good framework from which to fill out the document moving
> forward, and so that the changes get captured in a document and don't just
> get lost on the list. I would like to have all of these changes to the
> Information Model addressed prior to the SACM Virtual Interim Meeting on
> September 24th so that we can discuss them then and if we decide to take
> the approach of shifting our focus to solution drafts, we will have a good
> stopping point. Please let me know what you think. All feedback is greatly
> appreciated. Thanks, Danny From: sacm [mailto:[email-masked]] On
> Behalf Of Haynes, Dan Sent: Wednesday, August 19, 2015 12:42 PM To:
> [email-masked] Subject: [sacm] Proposed Updates to the Structure of the
> Information Model Draft During the past two Endpoint ID Design Team
> (EID-DT) meetings [1][2], we have discussed proposed changes to the
> structure of the Information Model draft. The general consensus among the
> members, at the last two EID-DT meetings, was that the proposed changes to
> the structure of the Information Model were reasonable and should be
> accepted into the Information Model draft. Given that, we wanted to propose
> these changes to the broader working group for feedback prior to making any
> updates to the draft. Here is a summary of the proposed changes. . Combine
> the "Introduction" and "Problem Statement" sections. Move the "Changes in
> Revision 01", "C
> hanges in Revision 02", and "Mapping to SACM Use Cases" to an Appendix. .
> Add an "Information Model Framework" section. This section describes the
> core concepts, constructs, and relationships that are used to model Assets
> and Elements in the Information Model. . Add an "Information Model Assets"
> section. This section defines the different types of Assets used in the
> Information Model and the relationships between them. . Add an "Information
> Model Elements" section. This section defines specific concrete constructs
> to be implemented by data models. One example of this might be a network
> address as described in Lisa's Terminology Meeting Notes [3]. This section
> will absorb the current "Elements of the SACM Information Model" section.
> questions in the comments of the d
> ocument such as whether or not a few sections can be deleted. It would be
> great to get feedback on these as well if you have time, but, I would say
> getting feedback on the changes listed above is the most critical. I can
> always just open issue trackers for the remaining questions and they can be
> addressed later. If there is consensus that these changes make sense, I
> will update the Information Model draft in GitHub. I will also add a
> sentence or two, for each section, to capture what information should go
> there. This will be especially important if the working group decides to
> table the core working group documents (Requirements, Architecture, and
> being discussed on the list [4]. By the way, if you haven't chimed in on
> this thread please do :) as this decision will impact how the working group
> proceeds moving forward in the short term. Anyways, please let me know what
> you think about these changes or if you have any questions. I look forward
> to hearing your feedback. Thanks, Danny [1] 8/7 EID-DT Meeting
> http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html [2] 8/14
> EID-DT Meeting
> http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html [3]
> Terminology Notes
> http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html [4] Short
> Term Path Forward
> _______________________________________________ sacm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sacm
>
>
>>
>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Wed, 26 Aug 2015 21:58:55 +0000

I think only including attributes that everyone agrees are an inherent part of an endpoint may be too rigorous.  In today's environment, with VPN network adapters, wireless networks, ephemeral virtual machines, and DHCP, I don't think it's reasonable to say anything more definitive that an IP or MAC address pair is associated with a given endpoint for a period of time.  This may also be true of some FQDNs, but globally advertised FQDNs are generally persistent over time periods that are sufficiently long to be useful.  

However, in many cases, IP, MAC, and/or DNS FQDN may be all that are available, so they can be used to at least narrow down the population of candidate matches, if not to specifically create a high confidence 1:1 identity match.

To get higher confidence matching, I am focusing on collecting more attributes that are persistent, designed to be globally unique, and available to sensors with credentialed access to devices.  Candidates that I think are valuable for high-confidence matching include BIOS GUID, Motherboard Serial Number, and certain software application GUIDs (like AV application GUIDS, patch management agent GUID, etc.).  I'd like to do something intelligent with TPMs, but not sure exactly how since the ones we have aren't generally configured to act as good device identity agents.

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

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 5:12 PM
To: Gunnar Engelbach; Ira McDonald
Cc: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [email-masked]
Subject: Re: [sacm] Proposed Updates to the Structure of the Information Model Draft

Hi Gunnar,

With all due respect, that's not the way the real world of the Web works.  URI resolution

IP addresses are also (in large enterprises) administratively assigned, not inherent

aspects of a device.

Cheers,

- Ira

On Wed, Aug 26, 2015 at 5:09 PM, Gunnar Engelbach <[email-masked]> wrote:

	Au contraire.
	
	A DNS FQDN is not an attribute of an endpoint, but a text alias held by an external server and presented when you give it an IP address. The absolute best you can hope for is that the DNS server remains as accurate as the IP address over time -- in which case it is just a more human-readable alias for the IP address.  The IP/DNS name mapping would have to remain immutable for this to be reliable, and even then the DNS name has no more reliability than the original IP address.
	
	If you use Microsoft DNS with WINS, then there is a decent probability that the DNS name will change when the IP address assigned to a target changes, but that doesn't help with correlation.  Other collection points, such as an (IDS, log server, external scanner, network proxy, whatever), would have to had to have done a lookup at the same time via the same server in order to get the same value -- and that's just not something you can rely on.  More likely something like an IDS will only be collecting IP addresses -- when you then later try to correlate the entry on the IDS with your security scan you'll need to do a DNS lookup to convert that to the DNS identifier that your security scan is using:  and you can't count on them matching.

	There might be some value to collecting the DNS name as something you can present to a user about what that target was known as at that point in time, but in my experience, especially on internal networks, DNS is not maintained well enough for this to be of real use -- very often it causes problems by supplying erroneous data.

	--gun

		

		Joseph L. Wolfkiel
		SCM Engineering Lead
		DISA ID52
		Work: (301) 225-8820 <tel:%28301%29%20225-8820> 
		Gov Cell: (571) 814-8231 <tel:%28571%29%20814-8231> 
		[email-masked]

		-----Original Message-----
		From: Gunnar Engelbach [mailto:[email-masked]]
		Sent: Wednesday, August 26, 2015 4:12 PM
		To: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; [email-masked]
		Subject: Re: [sacm] Proposed Updates to the Structure of the Information Model Draft

		

		--gun

			

			Joseph L. Wolfkiel
			SCM Engineering Lead
			DISA ID52
			Work: (301) 225-8820 <tel:%28301%29%20225-8820> 
			Gov Cell: (571) 814-8231 <tel:%28571%29%20814-8231> 
			[email-masked]

			-----Original Message-----
			From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
			Sent: Wednesday, August 26, 2015 3:29 PM
			To: Haynes, Dan; [email-masked]
			Subject: Re: [sacm] Proposed Updates to the Structure of the Information Model Draft
			
			A) From my understanding of how it is diagrammed in the reference to Lisa's note, a more complete entry for an address would look like this: container: network address container: IP address container: IPv4 address 192.168.0.1 container: IPv6 address fe80::20c:29ff:fe19:8af8 container: MAC address 00:0C:DE:AD:BE:EF container: timestamp 2015-08-22T13:16:12.2345 and should also include parent containers for the interface, et al. This is a workable representation, and possibly necessary if the goal is to fit information about network addresses into a common data format, but I want to be sure it's clear that the tuple of address + mac + timestamp needs to be considered as a whole because each part can be ephemeral. It also can't be counted on that all three pieces of data will be available for correlation, with the reliability dependent on which items are available. A rough list, in order of reliability, would be: IP MAC IP + MAC IP + timestamp MAC + timestamp IP + MAC + timestamp Havi

	ng a timestamp available greatly increases the reliability of an address as an identifier, but only if it can assured that the timestamp is accurately coordinated, which is a nontrivial problem and therefore likely to not be available. Would this data structure also then need to include information that could be used to determine the reliability of the timestamp (such as time source, interval since last time check, amount of drift within that interval), or would that be handled at a higher level? If handled at a higher level, would that mechanism also allow for tracking of intervals during which the reliability of that source was at a different level of reliability? B) A complete enumeration of the addresses on a device has diminishing value from the perspective of asset identification. Some address types don't add any significant information. Loopback addresses, for example. Same, to a large degree, with multicast, unicast, PtP, etc. On 8/26/2015 2:16 PM, Haynes, Dan wrote: I just 
 wanted to follow-up on this thread. So far, there has been some discussion around how to classify a network interface (hardware component vs. software component vs. software interface). I think this is a good discussion and should definitely continue. However, I haven't heard any feedback on the proposed changes to the structure of the Information Model listed below. Without any feedback from the broader group, unless there are objections, I am inclined to make these changes to the structure of the Information Model because members of the Endpoint ID Design Team were in favor of them, they will give us a good framework from which to fill out the document moving forward, and so that the changes get captured in a document and don't just get lost on the list. I would like to have all of these changes to the Information Model addressed prior to the SACM Virtual Interim Meeting on September 24th so that we can discuss them then and if we decide to take the approach of shifting our focus 
 to solution drafts, we will have a good stopping point. Please let me know what you think. All feedback is greatly appreciated. Thanks, Danny From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan Sent: Wednesday, August 19, 2015 12:42 PM To: [email-masked] Subject: [sacm] Proposed Updates to the Structure of the Information Model Draft During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], we have discussed proposed changes to the structure of the Information Model draft. The general consensus among the members, at the last two EID-DT meetings, was that the proposed changes to the structure of the Information Model were reasonable and should be accepted into the Information Model draft. Given that, we wanted to propose these changes to the broader working group for feedback prior to making any updates to the draft. Here is a summary of the proposed changes. . Combine the "Introduction" and "Problem Statement" sections. Move the "Changes in Revision 01", "C
	hanges in Revision 02", and "Mapping to SACM Use Cases" to an Appendix. . Add an "Information Model Framework" section. This section describes the core concepts, constructs, and relationships that are used to model Assets and Elements in the Information Model. . Add an "Information Model Assets" section. This section defines the different types of Assets used in the Information Model and the relationships between them. . Add an "Information Model Elements" section. This section defines specific concrete constructs to be implemented by data models. One example of this might be a network address as described in Lisa's Terminology Meeting Notes [3]. This section will absorb the current "Elements of the SACM Information Model" section. For more information about the proposed changes, please see the latest draft of the Information Model table of contents (updated-im-toc-814.docx) which I have attached for your convenience. There are also some other open questions in the comments of the d
	ocument such as whether or not a few sections can be deleted. It would be great to get feedback on these as well if you have time, but, I would say getting feedback on the changes listed above is the most critical. I can always just open issue trackers for the remaining questions and they can be addressed later. If there is consensus that these changes make sense, I will update the Information Model draft in GitHub. I will also add a sentence or two, for each section, to capture what information should go there. This will be especially important if the working group decides to table the core working group documents (Requirements, Architecture, and Information Model) drafts in favor of working on solution drafts as is being discussed on the list [4]. By the way, if you haven't chimed in on this thread please do :) as this decision will impact how the working group proceeds moving forward in the short term. Anyways, please let me know what you think about these changes or if you have 
 any questions. I look forward to hearing your feedback. Thanks, Danny [1] 8/7 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html [2] 8/14 EID-DT Meeting http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html [3] Terminology Notes http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html [4] Short Term Path Forward http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html _______________________________________________ sacm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/sacm

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 27 Aug 2015 08:57:34 +0200

Hello,

a)
in most parts this is a very good example of a taxonomy (excluding the
timestamp). This is exactly on of the things that, for example, Nancy
has in mind, I think.

Most of the time, only the most specialized concepts in a taxonomy can
be instantiated in a meaningful way. Nevertheless, it is very useful -
and I think even important - to include the possibility to refer to a
more generalized concept in the context of queries, subscriptions and
acquisition (or sharing) of information in general.
Sometimes, one does not really know which specific kinds of addresses
are useful for a task - this is especially true in automation that
includes algorithmic intelligence.

I.e. a +1 here.

That said, this information is known implicitly and does not need to be
expressed in the instantiation of the model/schema, in general.
Especially, it there are the means implemented to discover, acquire and
apply dictionaries/models/schemas as, e.g. guidance (that's why these
operations are already mapped to basic SACM functions).

b)
I am not sure it this is true. Increasing the number of identifying
attributes to create a statement about the identity of an observed
target endpoint at one point in time should also increase the quality of
the statement. The chance that there is another endpoint with exactly
that layout of addresses assigned to interfaces decreases, I think. Am I
missing something?

The data to be transferred increases, too, of course. But I have the
suspicion that the number of interfaces and addresses of target
endpoints in constraint environments will also be more constrained.

Grüße,

Henk

On 08/26/2015 09:29 PM, Gunnar Engelbach wrote:
> 
> A)
> From my understanding of how it is diagrammed in the reference to Lisa's
> note, a more complete entry for an address would look like this:
> 
>> ·         Combine the “Introduction” and “Problem Statement”
>> sections.  Move the “Changes in Revision 01”, “Changes in Revision
>> 02”, and “Mapping to SACM Use Cases” to an Appendix.
>>
>>  
>>
>> describes the core concepts, constructs, and relationships that are
>> used to model Assets and Elements in the Information Model.
>>
>>  
>>
>> defines the different types of Assets used in the Information Model
>> and the relationships between them.
>>
>>  
>>
>> defines specific concrete constructs to be implemented by data
>> models.  One example of this might be a network address as described
>> in Lisa’s Terminology Meeting Notes [3].  This section will absorb the
>> current “Elements of the SACM Information Model” section.
>>
>>  
>>
>> <http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html>http://www.ietf.org/mail-archive/web/sacm/current/msg03147.html
>>
>> [2] 8/14 EID-DT Meeting
>> <http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html>http://www.ietf.org/mail-archive/web/sacm/current/msg03177.html
>>
>> [3] Terminology Notes
>> <http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html>http://www.ietf.org/mail-archive/web/sacm/current/msg03145.html
>>
>> <http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html>http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html
>>
>>  
>>
>>  
>>
>>
>>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 27 Aug 2015 09:20:38 +0200

Hello Joseph,

maybe you have the time to join one of the endpoint id DT calls? You
might find the progress the team did in regards to the attributes you
are interested in quite promising :)

As discussed at the last IETF meeting, we are starting to table the
process of finding additional identifying attributes for now and are
switching to how to express them (and basically every other "attribute
of interest") and their association.

A very interesting direction to go might be to express everything SACM
processes as statements (e.g. observations/collections or reports can be
expressed as statements), I think.
As a elemental principle, these statements - in contrast to the
concepts/"facts" the statements are about - could be uniquely
identifiable in a SACM domain (and probably even globally "across SACM
domains") and timestamped.
These statements could be expressed, e.g., via containers (implicit
relationships) or some triple/n-tuple'esque representation (explicit
relationships).
And different statements could contain conflicting content (statement
one: car foo is green vs. statement two: car foo is grey vs. statement
three: car foo should be red) without introducing inconsistency or
ambiguity.

Grüße,

Henk

On 08/26/2015 11:58 PM, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
> 			A) From my understanding of how it is diagrammed in the reference to Lisa's note, a more complete entry for an address would look like this: container: network address container: IP address container: IPv4 address 192.168.0.1 container: IPv6 address fe80::20c:29ff:fe19:8af8 container: MAC address 00:0C:DE:AD:BE:EF container: timestamp 2015-08-22T13:16:12.2345 and should also include parent containers for the interface, et al. This is a workable representation, and possibly necessary if the goal is to fit information about network addresses into a common data format, but I want to be sure it's clear that the tuple of address + mac + timestamp needs to be considered as a whole because each part can be ephemeral. It also can't be counted on that all three pieces of data will be available for correlation, with the reliability dependent on which items are available. A rough list, in order of reliability, would be: IP MAC IP + MAC IP + timestamp MAC + timestamp IP + MAC + tim!
 es!
>  tamp Havi
> 			
> 
> 	ng a timestamp available greatly increases the reliability of an address as an identifier, but only if it can assured that the timestamp is accurately coordinated, which is a nontrivial problem and therefore likely to not be available. Would this data structure also then need to include information that could be used to determine the reliability of the timestamp (such as time source, interval since last time check, amount of drift within that interval), or would that be handled at a higher level? If handled at a higher level, would that mechanism also allow for tracking of intervals during which the reliability of that source was at a different level of reliability? B) A complete enumeration of the addresses on a device has diminishing value from the perspective of asset identification. Some address types don't add any significant information. Loopback addresses, for example. Same, to a large degree, with multicast, unicast, PtP, etc. On 8/26/2015 2:16 PM, Haynes, Dan wro!
 te!
>  : I just 
>  wanted to follow-up on this thread. So far, there has been some discussion around how to classify a network interface (hardware component vs. software component vs. software interface). I think this is a good discussion and should definitely continue. However, I haven't heard any feedback on the proposed changes to the structure of the Information Model listed below. Without any feedback from the broader group, unless there are objections, I am inclined to make these changes to the structure of the Information Model because members of the Endpoint ID Design Team were in favor of them, they will give us a good framework from which to fill out the document moving forward, and so that the changes get captured in a document and don't just get lost on the list. I would like to have all of these changes to the Information Model addressed prior to the SACM Virtual Interim Meeting on September 24th so that we can discuss them then and if we decide to take the approach of shifting!
  o!
>  ur focus 
>  to solution drafts, we will have a good stopping point. Please let me know what you think. All feedback is greatly appreciated. Thanks, Danny From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan Sent: Wednesday, August 19, 2015 12:42 PM To: [email-masked] Subject: [sacm] Proposed Updates to the Structure of the Information Model Draft During the past two Endpoint ID Design Team (EID-DT) meetings [1][2], we have discussed proposed changes to the structure of the Information Model draft. The general consensus among the members, at the last two EID-DT meetings, was that the proposed changes to the structure of the Information Model were reasonable and should be accepted into the Information Model draft. Given that, we wanted to propose these changes to the broader working group for feedback prior to making any updates to the draft. Here is a summary of the proposed changes. . Combine the "Introduction" and "Problem Statement" sections. Move the "Changes in Revis!
 io!
>  n 01", "C
> 	hanges in Revision 02", and "Mapping to SACM Use Cases" to an Appendix. . Add an "Information Model Framework" section. This section describes the core concepts, constructs, and relationships that are used to model Assets and Elements in the Information Model. . Add an "Information Model Assets" section. This section defines the different types of Assets used in the Information Model and the relationships between them. . Add an "Information Model Elements" section. This section defines specific concrete constructs to be implemented by data models. One example of this might be a network address as described in Lisa's Terminology Meeting Notes [3]. This section will absorb the current "Elements of the SACM Information Model" section. For more information about the proposed changes, please see the latest draft of the Information Model table of contents (updated-im-toc-814.docx) which I have attached for your convenience. There are also some other open questions in the commen!
 ts!
>   of the d
> 	ocument such as whether or not a few sections can be deleted. It would be great to get feedback on these as well if you have time, but, I would say getting feedback on the changes listed above is the most critical. I can always just open issue trackers for the remaining questions and they can be addressed later. If there is consensus that these changes make sense, I will update the Information Model draft in GitHub. I will also add a sentence or two, for each section, to capture what information should go there. This will be especially important if the working group decides to table the core working group documents (Requirements, Architecture, and Information Model) drafts in favor of working on solution drafts as is being discussed on the list [4]. By the way, if you haven't chimed in on this thread please do :) as this decision will impact how the working group proceeds moving forward in the short term. Anyways, please let me know what you think about these changes or i!
 f !
>  you have

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 27 Aug 2015 12:35:45 +0000

Henk,

Thanks for the invite.  I have successfully joined a call or two.  Unfortunately the SACM work is more of a hobby for me than a primary part of my job description, so I'm not uniformly able to join the calls.  I apologize for not being able to fully keep up and for (probably) re-hashing issues that have already been finalized.

I agree with the concept of thinking of the data collected as statements.   Trying to ensure that humans arrive at a common understanding of what data "means" often identifies hidden assumptions and conflicting definitions.

As an example, I confused a lot of people by introducing the concept of "status events", which were statements that a property was observed about an endpoint at a given time, effectively making statements such as: "At 2015-06-01T23:00:08.166-04:00, device 1 was observed to have network adapter "ethernet01" configured with MAC Address "f4:6d:04:0a:42:ca" and IPv4 address "132.22.52.7".  This data was collected by sensor with ID="Sensor1.dod.mi" which is a network-based vulnerability scanner of type application="vendor,product name,version" during a full network scan.  The data was collected with root-level credentialed access."

A status event is different from a "change detection event" which might state something like the following:  "At 2015-06-01T23:00:08.166-04:00, the  ethernet01 network adapter on device 1 was observed to have a new configuration with MAC Address "52:2e:0a:6b:32:aa" and IPv4 address "132.22.52.9".  This data was collected by the SACM agent with GUID="ABCDEF1234567890" which is a configuration assessment agent of type application="vendor,product name,version" during a periodic change detection assessment with period="300seconds".  The agent was running with root-level privileges."  The timestamp would be the earliest the change was determined to occur, which would be accurate (in this case) to within 300 seconds.

The other common use case would be to have a SACM data collector that periodically monitors log files or files that have timestamps associated with events of interest (e.g. the Windows registry generally records when applications or patches were installed).  Depending on how much you trust the logging application, the timestamps may be significantly more accurate than those that are obtained by periodically monitoring for state changes.

Of course stating "device 1" assumes that some persistent identifier has been assigned to a given device.  Otherwise, it's not viable to assume that observations at different times can be attributed to the same endpoint.  In the first case, I would assume that correlation to a persistent identifier would use some combination of IP, MAC, and hostname/FQDN.  Prior to correlation to an endpoint identifier, you would state "an endpoint."  In the second, generally the agent GUID is used to persistently identify an endpoint.

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

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: Thursday, August 27, 2015 3:21 AM
To: [email-masked]
Subject: Re: [sacm] Proposed Updates to the Structure of the Information Model Draft

Hello Joseph,

Grüße,

Henk

 es!
 te!
  o!
 io!
 ts!
 f !

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 27 Aug 2015 11:04:33 -0400

> endpoints in constraint environments will also be more constrained.

Endpoint identity isn't just the collection of attributes.  The most 
important part is an algorithm that is aware of the meaning of each of 
the attributes, especially in relation to other attributes values and 
can account for values not being available.

It's not a simple algorithm and also needs to be part of the standard if 
it's going to be anything like a standard.

Having more information does, indeed, increase the ability to identify 
an endpoint, but each attribute needs to be accounted for in the 
algorithm, increasing its complexity, and some items don't add enough 
value to warrant their inclusion.  Id est, there is a point of 
diminishing returns.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 27 Aug 2015 11:54:36 -0400

Hi,

In case this is helpful, but it probably doesn't matter too much for
the fuller discussion...

> With all due respect, that's not the way the real world of the Web works.

I think we are talking about DNS resolution, not FQDNs in URIs, but
maybe I missed something.

> goes *from* and FQDN *to* and IP address - not the other way around.

The purpose of in-addr.arpa addresses is to allow for reverse lookups
of IP addresses to host names or FQDNs.

> IP addresses are also (in large enterprises) administratively assigned, not

Even with MAC addresses, this is changing for privacy reasons.
http://standards.ieee.org/news/2015/wireless_privacy_trials.html

We'll have to be careful around privacy concerns for both IP addresses
and FQDNs as well as other possible fields of interest in the data
model.

Best regards,
Kathleen

> On Wed, Aug 26, 2015 at 5:09 PM, Gunnar Engelbach
> <[email-masked]> wrote:
>>
>>
>> Au contraire.
>>
>> would have to had to have done a lookup at the same time via the same server
>> in order to get the same value -- and that's just not something you can rely
>> on.  More likely something like an IDS will only be collecting IP addresses
>> -- when you then later try to correlate the entry on the IDS with your
>> security scan you'll need to do a DNS lookup to convert that to the DNS
>> identifier that your security scan is using:  and you can't count on them
>> matching.
>>
>>
>> present to a user about what that target was known as at that point in time,
>> but in my experience, especially on internal networks, DNS is not maintained
>> well enough for this to be of real use -- very often it causes problems by
>> supplying erroneous data.
>>
>>
>> --gun
>>
>>
>>
>>> guaranteed or expected to be persistent.  In the matching logic that we have
>>> implemented, we have a higher confidence in FQDN than IP addresses.  In
>>> practice, we will not claim to have identified a device based on IP address
>>> alone.
>>>
>>> network interface, but the DNS FQDNs are associated with interfaces that are
>>> connected to a given domain.  So you can't say that FQDNs always behave the
>>> same, with respect to network relationships.  It's a matter of what type of
>>> FQDN you're discussing.
>>>
>>>> interface name (e.g. "ethernet0"), and default gateway in our current tool.
>>>> Timestamps are generally accurate to within a few hours based on out-of-sync
>>>> clock errors and different timezone problems.  At some point, we also plan
>>>> to collect DNS server IP address and network DNS domain.
>>>>
>>>> has identifiers mixed together with data that is useful for network mapping.
>>>> We have some other use cases, such as identifying VMs by looking for
>>>> "VMWare" in one or more of the interface names on an endpoint.
>>>>
>>>> information about network addresses into a common data format, but I want to
>>>> be sure it's clear that the tuple of address + mac + timestamp needs to be
>>>> considered as a whole because each part can be ephemeral. It also can't be
>>>> counted on that all three pieces of data will be available for correlation,
>>>> with the reliability dependent on which items are available. A rough list,
>>>> in order of reliability, would be: IP MAC IP + MAC IP + timestamp MAC +
>>>> timestamp IP + MAC + timestamp Havi
>>
>> information that could be used to determine the reliability of the timestamp
>> (such as time source, interval since last time check, amount of drift within
>> that interval), or would that be handled at a higher level? If handled at a
>> higher level, would that mechanism also allow for tracking of intervals
>> during which the reliability of that source was at a different level of
>> reliability? B) A complete enumeration of the addresses on a device has
>> diminishing value from the perspective of asset identification. Some address
>> types don't add any significant information. Loopback addresses, for
>> example. Same, to a large degree, with multicast, unicast, PtP, etc. On
>> 8/26/2015 2:16 PM, Haynes, Dan wrote: I just wanted to follow-up on this
>> thread. So far, there has been some discussion around how to classify a
>> network interface (hardware component vs. software component vs. software
>> continue. However, I haven't heard any feedback on the proposed changes to
>> the structure of the Information Model listed below. Without any feedback
>> from the broader group, unless there are objections, I am inclined to make
>> these changes to the structure of the Information Model because members of
>> the Endpoint ID Design Team were in favor of them, they will give us a good
>> the changes get captured in a document and don't just get lost on the list.
>> I would like to have all of these changes to the Information Model addressed
>> prior to the SACM Virtual Interim Meeting on September 24th so that we can
>> discuss them then and if we decide to take the approach of shifting our
>> focus to solution drafts, we will have a good stopping point. Please let me
>> know what you think. All feedback is greatly appreciated. Thanks, Danny
>> From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan Sent:
>> Wednesday, August 19, 2015 12:42 PM To: [email-masked] Subject: [sacm]
>> Proposed Updates to the Structure of the Information Model Draft During the
>> past two Endpoint ID Design Team (EID-DT) meetings [1][2], we have discussed
>> proposed changes to the structure of the Information Model draft. The
>> general consensus among the members, at the last two EID-DT meetings, was
>> that the proposed changes to the structure of the Information Model were
>> reasonable and should be accepted into the Information Model draft. Given
>> that, we wanted to propose these changes to the broader working group for
>> feedback prior to making any updates to the draft. Here is a summary of the
>> proposed changes. . Combine the "Introduction" and "Problem Statement"
>> sections. Move the "Changes in Revision 01", "C
>> For more information about the proposed changes, please see the latest draft
>> of the Information Model table of contents (updated-im-toc-814.docx) which I
>> have attached for your convenience. There are also some other open questions
>> in the comments of the d
>> addressed later. If there is consensus that these changes make sense, I will
>> update the Information Model draft in GitHub. I will also add a sentence or
>> two, for each section, to capture what information should go there. This
>> will be especially important if the working group decides to table the core
>> working group documents (Requirements, Architecture, and Information Model)
>> drafts in favor of working on solution drafts as is being discussed on the
>> list [4]. By the way, if you haven't chimed in on this thread please do :)
>> as this decision will impact how the working group proceeds moving forward
>> in the short term. Anyways, please let me know what you think about these
>> changes or if you have any questions. I look forward to hearing your
>> feedback. Thanks, Danny [1] 8/7 EID-DT Meeting

-- 

Best regards,
Kathleen

---

From: Ira McDonald <[email-masked]>
Date: Thu, 27 Aug 2015 12:20:16 -0400

Hi Kathleen,

Thanks for all those good clarifications and the wireless privacy link.

I was thinking about configuration of application services - they typically
publish a URI w/ an FQDN into LDAP and other directories - that is, the
device actually *does* know it's one or more associated FQDNs - they're
also collected in various network management and security automation
protocols already.

Cheers,
- Ira

On Thu, Aug 27, 2015 at 11:54 AM, Kathleen Moriarty <
[email-masked]> wrote:

> an
> points,
> server
> can
> time,
> >>> Subject: Re: [sacm] Proposed Updates to the Structure of the
> Information
> >>> Model Draft
> >>>
> >>>
> tool.
> mapping.
> >>>> Subject: Re: [sacm] Proposed Updates to the Structure of the
> Information
> >>>> Model Draft
> >>>>
> timestamp
> software
> make
> addressed
> Sent:
> draft
> will
> core