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

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 19 Aug 2015 16:42:13 +0000

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: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 20 Aug 2015 12:54:57 +0000

Just a small protest on the "network interface" concept.  I'm not sure how "network interface" got to be defined as only a hardware component.  The piece of hardware that implements an interface to a network isn't all that interesting to me.  It's the set of information associated with interfacing with a network that is critical to me.

For example, a TCP/IP network will have, per interface, a MAC and IP address, a domain, a default gateway, a DNS server, and a FQDN.  We may also want to collect a time when the device first configured the network interface, and a time when the device last communicated over the network.  A cellular phone network will have a SIM card identifier, a telephone number, a carrier, a network type, and other information.  Many network interfaces, such as an IPsec VPN connector, are typically virtual and don't have any firm connection to hardware.

>From the work we've been doing in the DoD, it's been consistently valuable to think of devices as having a software configuration, hardware configuration, network configuration, operational context information, and relationship to other devices (from a virtualization/hypervisor perspective).

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 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

.         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.

Thanks,

Danny

[1] 8/7 EID-DT Meeting 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> 

[4] Short Term Path Forward http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html <http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html>

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Thu, 20 Aug 2015 13:27:32 +0000

Adding to Joe's protest, on Windows a number of VPN solutions, including
Junos Pulse and Cisco AnyConnect, as well as virtualization products,
including VMWare and VirtualBox, create virtual network adapters.  Do these
and miniport adapters fall under another concept or should the "network
interface" concept be revised to include virtual/miniport adapters and other
any other software based network interface?

Timothy Harrison
Lead Technologist
Mobile 717-372-5768
www.boozallen.com

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel, Joseph L
CIV DISA ID (US)
Sent: Thursday, August 20, 2015 8:55 AM
To: [email-masked]
Cc: Haynes, Dan <[email-masked]>
Subject: [External] Re: [sacm] Proposed Updates to the Structure of the
Information Model Draft

Just a small protest on the "network interface" concept.  I'm not sure how
"network interface" got to be defined as only a hardware component.  The
piece of hardware that implements an interface to a network isn't all that
interesting to me.  It's the set of information associated with interfacing
with a network that is critical to me.

For example, a TCP/IP network will have, per interface, a MAC and IP
address, a domain, a default gateway, a DNS server, and a FQDN.  We may also
want to collect a time when the device first configured the network
interface, and a time when the device last communicated over the network.  A
cellular phone network will have a SIM card identifier, a telephone number,
a carrier, a network type, and other information.  Many network interfaces,
such as an IPsec VPN connector, are typically virtual and don't have any
firm connection to hardware.

>From the work we've been doing in the DoD, it's been consistently valuable
to think of devices as having a software configuration, hardware
configuration, network configuration, operational context information, and
relationship to other devices (from a virtualization/hypervisor
perspective).

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 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
<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> 

[4] Short Term Path Forward
http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html
<http://www.ietf.org/mail-archive/web/sacm/current/msg03163.html>

---

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

Hi,

I think that separating a network interface out from hardware component
and software component is a slippery slope.

Given virtual network adapters, etc., many "network interfaces" are simply
one more of the many "software interfaces" and I question the value of the
effort to classify a network interface as hardware (it's often not), while
also
ignoring the fact that all useful network interfaces inherently include one
or
more software APIs.

Software interfaces seem like they should get some more coverage in the
SACM Information Model.

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 Thu, Aug 20, 2015 at 9:27 AM, Harrison, Timothy [USA] <
[email-masked]> wrote:

> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 20 Aug 2015 15:17:55 +0000

Yet firmware is another software interface, so why not just treat everything as a software interface?  

However, if we want to collect some common set of data, based on some sort of object model, we'll need to define the attributes for the object models we want to collect against or check for compliance.  Without acknowledging that a network interface is a targeted object, there's no supporting object model that would support the idea that individual IP addresses, MAC addresses, and domains are logically grouped together.

I suppose the model you end up with if you really have to explicitly state that all SACM data is ultimately collected by having software talk to software interfaces would look something like the following. 

                    SACM Sensor/Data Collector
                                          |
                        Software Interfaces
            |               |                  |                   |
  Network  Hardware   Application User

All the objects we want to collect information about exist on the other side of a software interface from the SACM data collector.  Or maybe you see it differently?  Further, I suppose the set of software interfaces used to communicate with the objects we want to collect data about are generally contained in the operating system.

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: Thursday, August 20, 2015 10:28 AM
To: Harrison, Timothy [USA]; Ira McDonald
Cc: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]; Haynes, Dan
Subject: Re: [sacm] [External] Re: Proposed Updates to the Structure of the Information Model Draft

Hi,

one more of the many "software interfaces" and I question the value of the 
effort to classify a network interface as hardware (it's often not), while also

ignoring the fact that all useful network interfaces inherently include one or 
more software APIs.

SACM Information Model.

Cheers,

- Ira

On Thu, Aug 20, 2015 at 9:27 AM, Harrison, Timothy [USA] <[email-masked]> wrote:

	Timothy Harrison
	Lead Technologist
	Mobile 717-372-5768
	www.boozallen.com

	-----Original Message-----
	From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel, Joseph L
	CIV DISA ID (US)
	Sent: Thursday, August 20, 2015 8:55 AM
	To: [email-masked]
	Cc: Haynes, Dan <[email-masked]>
	Subject: [External] Re: [sacm] Proposed Updates to the Structure of the
	Information Model Draft

	
	
	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 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

	

	

	

	

	
	Thanks,
	
	Danny

	[1] 8/7 EID-DT Meeting
	
	[2] 8/14 EID-DT Meeting
	
	[3] Terminology Notes

---

From: Ira McDonald <[email-masked]>
Date: Thu, 20 Aug 2015 11:32:13 -0400

Hi Joseph,

I think you're suggesting that flattening everything into a software
interface
makes for an uninteresting model?

I recognize that it's intuitive to break out network interfaces in any
network
management or security management model.  But disentangling the actual
hardware (which might just be a chip on a motherboard) from the firmware
on that hardware, the OS lower layer protocol stacks, the user process
higher
layer protocol stacks, and the actual application interface (operations,
schema,
etc.) seems to lead to some arbitrary distinctions.

And containers and virtual machines blur the distinctions even further.  For
example, is a virtual TPM or other virtual HSM running in a VM part of the
data context of the virtual application?  I'll stick my neck out and say
yes.

It's a good thing there are a lot of sharp people active in SACM WG, because
the problem space seems to be quite a lot larger than is usually considered
by a single IETF WG.

Cheers,
- Ira

On Thu, Aug 20, 2015 at 11:17 AM, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> wrote:

> However, if we want to collect some common set of data, based on some sort
> of object model, we'll need to define the attributes for the object models
> we want to collect against or check for compliance.  Without acknowledging
> that a network interface is a targeted object, there's no supporting object
> model that would support the idea that individual IP addresses, MAC
> addresses, and domains are logically grouped together.
>
> I suppose the model you end up with if you really have to explicitly state
> that all SACM data is ultimately collected by having software talk to
> software interfaces would look something like the following.
>
>
> All the objects we want to collect information about exist on the other
> side of a software interface from the SACM data collector.  Or maybe you
> see it differently?  Further, I suppose the set of software interfaces used
> to communicate with the objects we want to collect data about are generally
> contained in the operating system.
>
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> Work: (301) 225-8820
> Gov Cell: (571) 814-8231

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 20 Aug 2015 15:59:13 +0000

Not uninteresting.  It just adds an abstraction layer between the SACM sensor and the objects we want to evaluate or assess.  It adds complexity and I'm struggling with understanding the value we get in return.  I'm also struggling with the idea of *how* the SACM sensor will communicate with and collect data from the endpoints versus defining *what* data it would collect about which logical objects since our conversation seems to blur the lines.

My primary objection to not having "network interface" as a defined object is the idea that without having an "interface" object to group data elements together, a given device would just have a bunch of IP addresses, a bunch of MAC addresses, and a bunch of FQDNs.  In my experience, grouping them per network interface makes them much more powerful identifiers than just dumping them into a big list.  If we treat network interfaces as just pieces of hardware, I don't think we get where we need to be.

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 Ira McDonald
Sent: Thursday, August 20, 2015 11:32 AM
To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald
Cc: Haynes, Dan; Harrison, Timothy [USA]; [email-masked]
Subject: Re: [sacm] [External] Re: Proposed Updates to the Structure of the Information Model Draft

Hi Joseph, I think you're suggesting that flattening everything into a software interface makes for an uninteresting model? I recognize that it's intuitive to break out network interfaces in any network management or security management model. But disentangling the actual hardware (which might just be a chip on a motherboard) from the firmware on that hardware, the OS lower layer protocol stacks, the user process higher layer protocol stacks, and the actual application interface (operations, schema, etc.) seems to lead to some arbitrary distinctions. And containers and virtual machines blur the distinctions even further. For example, is a virtual TPM or other virtual HSM running in a VM part of the data context of the virtual application? I'll stick my neck out and say yes. It's a good thing there are a lot of sharp people active in SACM WG, because the problem space seems to be quite a lot larger than is usually considered by a single IETF WG. 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 Thu, Aug 20, 2015 at 11:17 AM, Wolfkiel, Joseph L CIV DISA ID (US) > wrote: Yet firmware is another software interface, so why not just treat everything as a software interface? However, if we want to collect some common set of data, based on some sort of object model, we'll need to define the attributes for the object models we want to collect against or check for compliance. Without acknowledging that a network interface is a targeted object, there's no supporting object model that 
 would support the idea that individual IP addresses, MAC addresses, and domains are logically grouped together. I suppose the model you end up with if you really have to explicitly state that all SACM data is ultimately collected by having software talk to software interfaces would look something like the following. SACM Sensor/Data Collector | Software Interfaces | | | | Network Hardware Application User All the objects we want to collect information about exist on the other side of a software interface from the SACM data collector. Or maybe you see it differently? Further, I suppose the set of software interfaces used to communicate with the objects we want to collect data about are generally contained in the operating system. Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Work: (301) 225-8820 Gov Cell: (571) 814-8231 [email-masked] -----Original Message----- From: Ira McDonald [mailto:[email-masked]] Sent: Thursday, August 20, 2015 10:28 AM To: Harriso
 n, Timothy [USA]; Ira McDonald Cc: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]; Haynes, Dan Subject: Re: [sacm] [External] Re: Proposed Updates to the Structure of the Information Model Draft Hi, I think that separating a network interface out from hardware component and software component is a slippery slope. Given virtual network adapters, etc., many "network interfaces" are simply one more of the many "software interfaces" and I question the value of the effort to classify a network interface as hardware (it's often not), while also ignoring the fact that all useful network interfaces inherently include one or more software APIs. Software interfaces seem like they should get some more coverage in the SACM Information Model. 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 Des
 ignated 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 Thu, Aug 20, 2015 at 9:27 AM, Harrison, Timothy [USA] > wrote: Adding to Joe's protest, on Windows a number of VPN solutions, including Junos Pulse and Cisco AnyConnect, as well as virtualization products, including VMWare and VirtualBox, create virtual network adapters. Do these and miniport adapters fall under another concept or should the "network interface" concept be revised to include virtual/miniport adapters and other any other software based network interface? Timothy Harrison Lead Technologist Mobile 717-372-5768 www.boozallen.com -----Original Message----- From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel, Joseph L CIV DISA ID (US) Sent: Thursday, August 20, 2015 8:55 A
 M To: [email-masked] Cc: Haynes, Dan > Subject: [External] Re: [sacm] Proposed Updates to the Structure of the Information Model Draft Just a small protest on the "network interface" concept. I'm not sure how "network interface" got to be defined as only a hardware component. The piece of hardware that implements an interface to a network isn't all that interesting to me. It's the set of information associated with interfacing with a network that is critical to me. For example, a TCP/IP network will have, per interface, a MAC and IP address, a domain, a default gateway, a DNS server, and a FQDN. We may also want to collect a time when the device first configured the network interface, and a time when the device last communicated over the network. A cellular phone network will have a SIM card identifier, a telephone number, a carrier, a network type, and other information. Many network interfaces, such as an IPsec VPN connector, are typically virtual and don't have any firm connection
  to hardware. >From the work we've been doing in the DoD, it's been consistently valuable to think of devices as having a software configuration, hardware configuration, network configuration, operational context information, and relationship to other devices (from a virtualization/hypervisor perspective). 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 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 abso
 rb 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) dr
 afts 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: Ira McDonald <[email-masked]>
Date: Thu, 20 Aug 2015 12:09:23 -0400

Hi Joseph,

On balance, I agree that we need a network interface abstraction which has
to cover both the physical hardware/firmware that makes available physical
connectivity and the collection of protocol stack layer identifiers (MAC,
IP,
TCP, *maybe* application URI, etc.) and directory identifiers (FQDN, etc.).

For a running software instance, do we want to capture upper layer
identifiers
such as TLS or higher session IDs?  These have short lifetimes, but are very
relevant to access control (caches, session resumption, session discard).

Cheers,
- Ira

On Thu, Aug 20, 2015 at 11:59 AM, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> wrote:

> Not uninteresting.  It just adds an abstraction layer between the SACM
> sensor and the objects we want to evaluate or assess.  It adds complexity
> and I'm struggling with understanding the value we get in return.  I'm also
> struggling with the idea of *how* the SACM sensor will communicate with and
> collect data from the endpoints versus defining *what* data it would
> collect about which logical objects since our conversation seems to blur
> the lines.
>
> My primary objection to not having "network interface" as a defined object
> is the idea that without having an "interface" object to group data
> elements together, a given device would just have a bunch of IP addresses,
> a bunch of MAC addresses, and a bunch of FQDNs.  In my experience, grouping
> them per network interface makes them much more powerful identifiers than
> just dumping them into a big list.  If we treat network interfaces as just
> pieces of hardware, I don't think we get where we need to be.
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> Work: (301) 225-8820
> Gov Cell: (571) 814-8231
> Hi Joseph, I think you're suggesting that flattening everything into a
> software interface makes for an uninteresting model? I recognize that it's
> intuitive to break out network interfaces in any network management or
> security management model. But disentangling the actual hardware (which
> might just be a chip on a motherboard) from the firmware on that hardware,
> the OS lower layer protocol stacks, the user process higher layer protocol
> stacks, and the actual application interface (operations, schema, etc.)
> seems to lead to some arbitrary distinctions. And containers and virtual
> machines blur the distinctions even further. For example, is a virtual TPM
> or other virtual HSM running in a VM part of the data context of the
> virtual application? I'll stick my neck out and say yes. It's a good thing
> there are a lot of sharp people active in SACM WG, because the problem
> space seems to be quite a lot larger than is usually considered by a single
> IETF WG. 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/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 Thu, Aug 20, 2015 at 11:17 AM,
> Wolfkiel, Joseph L CIV DISA ID (US) > wrote: Yet firmware is another
> software interface, so why not just treat everything as a software
> interface? However, if we want to collect some common set of data, based on
> some sort of object model, we'll need to define the attributes for the
> object models we want to collect against or check for compliance. Without
> acknowledging that a network interface is a targeted object, there's no
> supporting object model that would support the idea that individual IP
> addresses, MAC addresses, and domains are logically grouped together. I
> suppose the model you end up with if you really have to explicitly state
> software interfaces would look something like the following. SACM
> Sensor/Data Collector | Software Interfaces | | | | Network Hardware
> Application User All the objects we want to collect information about exist
> on the other side of a software interface from the SACM data collector. Or
> maybe you see it differently? Further, I suppose the set of software
> interfaces used to communicate with the objects we want to collect data
> about are generally contained in the operating system. Joseph L. Wolfkiel
> SCM Engineering Lead DISA ID52 Work: (301) 225-8820 Gov Cell: (571)
> 814-8231 [email-masked] -----Original Message----- From:
> Ira McDonald [mailto:[email-masked]] Sent: Thursday, August 20,
> 2015 10:28 AM To: Harrison, Timothy [USA]; Ira McDonald Cc: Wolfkiel,
> Joseph L CIV DISA ID (US); [email-masked]; Haynes, Dan Subject: Re: [sacm]
> [External] Re: Proposed Updates to the Structure of the Information Model
> Draft Hi, I think that separating a network interface out from hardware
> component and software component is a slippery slope. Given virtual network
> adapters, etc., many "network interfaces" are simply one more of the many
> "software interfaces" and I question the value of the effort to classify a
> network interface as hardware (it's often not), while also ignoring the
> fact that all useful network interfaces inherently include one or more
> software APIs. Software interfaces seem like they should get some more
> coverage in the SACM Information Model. 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/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 Thu, Aug 20, 2015 at 9:27 AM,
> Harrison, Timothy [USA] > wrote: Adding to Joe's protest, on Windows a
> number of VPN solutions, including Junos Pulse and Cisco AnyConnect, as
> well as virtualization products, including VMWare and VirtualBox, create
> virtual network adapters. Do these and miniport adapters fall under another
> concept or should the "network interface" concept be revised to include
> virtual/miniport adapters and other any other software based network
> interface? Timothy Harrison Lead Technologist Mobile 717-372-5768
> www.boozallen.com -----Original Message----- From: sacm [mailto:
> [email-masked]] On Behalf Of Wolfkiel, Joseph L CIV DISA ID (US)
> Sent: Thursday, August 20, 2015 8:55 AM To: [email-masked] Cc: Haynes, Dan
> Information Model Draft Just a small protest on the "network interface"
> concept. I'm not sure how "network interface" got to be defined as only a
> hardware component. The piece of hardware that implements an interface to a
> network isn't all that interesting to me. It's the set of information
> associated with interfacing with a network that is critical to me. For
> example, a TCP/IP network will have, per interface, a MAC and IP address, a
> domain, a default gateway, a DNS server, and a FQDN. We may also want to
> collect a time when the device first configured the network interface, and
> a time when the device last communicated over the network. A cellular phone
> network will have a SIM card identifier, a telephone number, a carrier, a
> network type, and other information. Many network interfaces, such as an
> IPsec VPN connector, are typically virtual and don't have any firm
> connection to hardware. >From the work we've been doing in the DoD, it's
> been consistently valuable to think of devices as having a software
> configuration, hardware configuration, network configuration, operational
> context information, and relationship to other devices (from a
> virtualization/hypervisor perspective). 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 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
> 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
> _______________________________________________ sacm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sacm
>

---

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

You asked: For a running software instance, do we want to capture upper layer identifiers such as TLS or higher session IDs? These have short lifetimes, but are very relevant to access control (caches, session resumption, session discard).

My opinion: For the use cases I envision for SACM, I wouldn't think that level of detail would be feasible.  I'm thinking SACM would be more interested in the configuration settings in the OS and applications that would govern how the TLS and session control would be handled and then determine if the settings are in compliance with a security policy, but I wouldn't expect SACM to be concerned with trying to derive, based on endpoint behavior, whether the device is secured correctly or not. 

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: Thursday, August 20, 2015 12:09 PM
To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald
Cc: Haynes, Dan; Harrison, Timothy [USA]; [email-masked]
Subject: Re: [sacm] [External] Re: Proposed Updates to the Structure of the Information Model Draft

Hi Joseph, On balance, I agree that we need a network interface abstraction which has to cover both the physical hardware/firmware that makes available physical connectivity and the collection of protocol stack layer identifiers (MAC, IP, TCP, *maybe* application URI, etc.) and directory identifiers (FQDN, etc.). For a running software instance, do we want to capture upper layer identifiers such as TLS or higher session IDs? These have short lifetimes, but are very relevant to access control (caches, session resumption, session discard). Cheers, - Ira On Thu, Aug 20, 2015 at 11:59 AM, Wolfkiel, Joseph L CIV DISA ID (US) > wrote: Not uninteresting. It just adds an abstraction layer between the SACM sensor and the objects we want to evaluate or assess. It adds complexity and I'm struggling with understanding the value we get in return. I'm also struggling with the idea of *how* the SACM sensor will communicate with and collect data from the endpoints versus defining *what* data it woul
 d collect about which logical objects since our conversation seems to blur the lines. My primary objection to not having "network interface" as a defined object is the idea that without having an "interface" object to group data elements together, a given device would just have a bunch of IP addresses, a bunch of MAC addresses, and a bunch of FQDNs. In my experience, grouping them per network interface makes them much more powerful identifiers than just dumping them into a big list. If we treat network interfaces as just pieces of hardware, I don't think we get where we need to be. 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 Ira McDonald Sent: Thursday, August 20, 2015 11:32 AM To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald Cc: Haynes, Dan; Harrison, Timothy [USA]; [email-masked] Subject: Re: [sacm] [External] Re: 
 Proposed Updates to the Structure of the Information Model Draft Hi Joseph, I think you're suggesting that flattening everything into a software interface makes for an uninteresting model? I recognize that it's intuitive to break out network interfaces in any network management or security management model. But disentangling the actual hardware (which might just be a chip on a motherboard) from the firmware on that hardware, the OS lower layer protocol stacks, the user process higher layer protocol stacks, and the actual application interface (operations, schema, etc.) seems to lead to some arbitrary distinctions. And containers and virtual machines blur the distinctions even further. For example, is a virtual TPM or other virtual HSM running in a VM part of the data context of the virtual application? I'll stick my neck out and say yes. It's a good thing there are a lot of sharp people active in SACM WG, because the problem space seems to be quite a lot larger than is usually consi
 dered by a single IETF WG. 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 Thu, Aug 20, 2015 at 11:17 AM, Wolfkiel, Joseph L CIV DISA ID (US) > wrote: Yet firmware is another software interface, so why not just treat everything as a software interface? However, if we want to collect some common set of data, based on some sort of object model, we'll need to define the attributes for the object models we want to collect against or check for compliance. Without acknowledging that a network interf
 ace is a targeted object, there's no supporting object model that would support the idea that individual IP addresses, MAC addresses, and domains are logically grouped together. I suppose the model you end up with if you really have to explicitly state that all SACM data is ultimately collected by having software talk to software interfaces would look something like the following. SACM Sensor/Data Collector | Software Interfaces | | | | Network Hardware Application User All the objects we want to collect information about exist on the other side of a software interface from the SACM data collector. Or maybe you see it differently? Further, I suppose the set of software interfaces used to communicate with the objects we want to collect data about are generally contained in the operating system. Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Work: (301) 225-8820 Gov Cell: (571) 814-8231 [email-masked] -----Original Message----- From: Ira McDonald [mailto:blueroofmus
 [email-masked]] Sent: Thursday, August 20, 2015 10:28 AM To: Harrison, Timothy [USA]; Ira McDonald Cc: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]; Haynes, Dan Subject: Re: [sacm] [External] Re: Proposed Updates to the Structure of the Information Model Draft Hi, I think that separating a network interface out from hardware component and software component is a slippery slope. Given virtual network adapters, etc., many "network interfaces" are simply one more of the many "software interfaces" and I question the value of the effort to classify a network interface as hardware (it's often not), while also ignoring the fact that all useful network interfaces inherently include one or more software APIs. Software interfaces seem like they should get some more coverage in the SACM Information Model. 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 Gro
 up 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 Thu, Aug 20, 2015 at 9:27 AM, Harrison, Timothy [USA] > wrote: Adding to Joe's protest, on Windows a number of VPN solutions, including Junos Pulse and Cisco AnyConnect, as well as virtualization products, including VMWare and VirtualBox, create virtual network adapters. Do these and miniport adapters fall under another concept or should the "network interface" concept be revised to include virtual/miniport adapters and other any other software based network interface? Timothy Harrison Lead Technologist Mobile 717-372-5768 www.boozallen.com -----Original Message----- From: sacm [mailto:[email-masked]] On Behalf Of Wolfkiel
 , Joseph L CIV DISA ID (US) Sent: Thursday, August 20, 2015 8:55 AM To: [email-masked] Cc: Haynes, Dan > Subject: [External] Re: [sacm] Proposed Updates to the Structure of the Information Model Draft Just a small protest on the "network interface" concept. I'm not sure how "network interface" got to be defined as only a hardware component. The piece of hardware that implements an interface to a network isn't all that interesting to me. It's the set of information associated with interfacing with a network that is critical to me. For example, a TCP/IP network will have, per interface, a MAC and IP address, a domain, a default gateway, a DNS server, and a FQDN. We may also want to collect a time when the device first configured the network interface, and a time when the device last communicated over the network. A cellular phone network will have a SIM card identifier, a telephone number, a carrier, a network type, and other information. Many network interfaces, such as an IPsec VPN c
 onnector, are typically virtual and don't have any firm connection to hardware. >From the work we've been doing in the DoD, it's been consistently valuable to think of devices as having a software configuration, hardware configuration, network configuration, operational context information, and relationship to other devices (from a virtualization/hypervisor perspective). 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 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 describ
 ed 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 grou
 p 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, 20 Aug 2015 20:48:53 +0200

Hello all,

it is not completely clear to me what kind of interfaces this discussion
is about. A few general comments:

Of course communication of an endpoint via its hardware interfaces (such
as a NIC) is done via software (on a typical endpoint this software is
basically only the OS). Therefore, the collection tasks of a SACM
collector residing on an endpoint typically use software interfaces
(API) to collect endpoint attributes about, for example, hardware
network interfaces.

I think that it is established consensus that network interfaces are
needed to group addresses assigned to an endpoint and that network
interfaces can be nested. Hardware network interfaces are typically the
root of potential nested hierarchies of network interfaces and this
could be a reason to differentiate physical interfaces (at least through
annotation) specifically. There are prominent exceptions to this
scenario (e.g. in the scope of virtual multi-tenant environments).

I.e., information about network interfaces is acquired via the
configuration settings (and the resulting state) in the OS and running
applications.

I am not sure if a firmware and a virtual network interface (with
assigned addresses) should be both regarded as a specialization of
software interface. But maybe this is a misconception on my end and this
is not the point that is being discussed?
The term interface by itself is probably a little bit ambiguous. APIs
and network interface are of course both specific kind of interfaces.

Grüße,

Henk

On 08/20/2015 06:35 PM, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
> Hi Joseph, On balance, I agree that we need a network interface abstraction which has to cover both the physical hardware/firmware that makes available physical connectivity and the collection of protocol stack layer identifiers (MAC, IP, TCP, *maybe* application URI, etc.) and directory identifiers (FQDN, etc.). For a running software instance, do we want to capture upper layer identifiers such as TLS or higher session IDs? These have short lifetimes, but are very relevant to access control (caches, session resumption, session discard). Cheers, - Ira On Thu, Aug 20, 2015 at 11:59 AM, Wolfkiel, Joseph L CIV DISA ID (US) > wrote: Not uninteresting. It just adds an abstraction layer between the SACM sensor and the objects we want to evaluate or assess. It adds complexity and I'm struggling with understanding the value we get in return. I'm also struggling with the idea of *how* the SACM sensor will communicate with and collect data from the endpoints versus defining *what* d!
 at!
>  a it woul
>  d collect about which logical objects since our conversation seems to blur the lines. My primary objection to not having "network interface" as a defined object is the idea that without having an "interface" object to group data elements together, a given device would just have a bunch of IP addresses, a bunch of MAC addresses, and a bunch of FQDNs. In my experience, grouping them per network interface makes them much more powerful identifiers than just dumping them into a big list. If we treat network interfaces as just pieces of hardware, I don't think we get where we need to be. 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 Ira McDonald Sent: Thursday, August 20, 2015 11:32 AM To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald Cc: Haynes, Dan; Harrison, Timothy [USA]; [email-masked] Subject: Re: [sacm] [Ext!
 er!
>  nal] Re: 
>  Proposed Updates to the Structure of the Information Model Draft Hi Joseph, I think you're suggesting that flattening everything into a software interface makes for an uninteresting model? I recognize that it's intuitive to break out network interfaces in any network management or security management model. But disentangling the actual hardware (which might just be a chip on a motherboard) from the firmware on that hardware, the OS lower layer protocol stacks, the user process higher layer protocol stacks, and the actual application interface (operations, schema, etc.) seems to lead to some arbitrary distinctions. And containers and virtual machines blur the distinctions even further. For example, is a virtual TPM or other virtual HSM running in a VM part of the data context of the virtual application? I'll stick my neck out and say yes. It's a good thing there are a lot of sharp people active in SACM WG, because the problem space seems to be quite a lot larger than is us!
 ua!
>  lly consi
>  dered by a single IETF WG. 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 Thu, Aug 20, 2015 at 11:17 AM, Wolfkiel, Joseph L CIV DISA ID (US) > wrote: Yet firmware is another software interface, so why not just treat everything as a software interface? However, if we want to collect some common set of data, based on some sort of object model, we'll need to define the attributes for the object models we want to collect against or check for compliance. Without acknowledging that a net!
 wo!
>  rk interf
>  ace is a targeted object, there's no supporting object model that would support the idea that individual IP addresses, MAC addresses, and domains are logically grouped together. I suppose the model you end up with if you really have to explicitly state that all SACM data is ultimately collected by having software talk to software interfaces would look something like the following. SACM Sensor/Data Collector | Software Interfaces | | | | Network Hardware Application User All the objects we want to collect information about exist on the other side of a software interface from the SACM data collector. Or maybe you see it differently? Further, I suppose the set of software interfaces used to communicate with the objects we want to collect data about are generally contained in the operating system. Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Work: (301) 225-8820 Gov Cell: (571) 814-8231 [email-masked] -----Original Message----- From: Ira McDonald [mailto:!
 bl!
>  ueroofmus
>  [email-masked]] Sent: Thursday, August 20, 2015 10:28 AM To: Harrison, Timothy [USA]; Ira McDonald Cc: Wolfkiel, Joseph L CIV DISA ID (US); [email-masked]; Haynes, Dan Subject: Re: [sacm] [External] Re: Proposed Updates to the Structure of the Information Model Draft Hi, I think that separating a network interface out from hardware component and software component is a slippery slope. Given virtual network adapters, etc., many "network interfaces" are simply one more of the many "software interfaces" and I question the value of the effort to classify a network interface as hardware (it's often not), while also ignoring the fact that all useful network interfaces inherently include one or more software APIs. Software interfaces seem like they should get some more coverage in the SACM Information Model. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer !
 Wo!
>  rking Gro
>  up 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 Thu, Aug 20, 2015 at 9:27 AM, Harrison, Timothy [USA] > wrote: Adding to Joe's protest, on Windows a number of VPN solutions, including Junos Pulse and Cisco AnyConnect, as well as virtualization products, including VMWare and VirtualBox, create virtual network adapters. Do these and miniport adapters fall under another concept or should the "network interface" concept be revised to include virtual/miniport adapters and other any other software based network interface? Timothy Harrison Lead Technologist Mobile 717-372-5768 www.boozallen.com -----Original Message----- From: sacm [mailto:[email-masked]] On Behalf !
 Of!
>   Wolfkiel
>  , Joseph L CIV DISA ID (US) Sent: Thursday, August 20, 2015 8:55 AM To: [email-masked] Cc: Haynes, Dan > Subject: [External] Re: [sacm] Proposed Updates to the Structure of the Information Model Draft Just a small protest on the "network interface" concept. I'm not sure how "network interface" got to be defined as only a hardware component. The piece of hardware that implements an interface to a network isn't all that interesting to me. It's the set of information associated with interfacing with a network that is critical to me. For example, a TCP/IP network will have, per interface, a MAC and IP address, a domain, a default gateway, a DNS server, and a FQDN. We may also want to collect a time when the device first configured the network interface, and a time when the device last communicated over the network. A cellular phone network will have a SIM card identifier, a telephone number, a carrier, a network type, and other information. Many network interfaces, such as an !
 IP!
>  sec VPN c
>  onnector, are typically virtual and don't have any firm connection to hardware. >From the work we've been doing in the DoD, it's been consistently valuable to think of devices as having a software configuration, hardware configuration, network configuration, operational context information, and relationship to other devices (from a virtualization/hypervisor perspective). 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 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 !
 ch!
>  anges 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!
  a!
>  s describ
>  ed 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 w!
 or!
>  king grou