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

From: "Haynes, Dan" <[email-masked]>
Date: Mon, 2 Nov 2015 08:27:00 +0000

Thanks for the feedback Gunnar and Adam!  What do others think about this?

Thanks,

Danny

From: Adam Montville [mailto:[email-masked]]
Sent: Monday, October 26, 2015 8:59 PM
To: Gunnar Engelbach <[email-masked]>
Cc: Haynes, Dan <[email-masked]>; [email-masked]
Subject: Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <[email-masked]<mailto:[email-masked]>> wrote:

Defining an algorithm would help with consistency in correlation outcomes between implementers.  However, it would need to be acknowledged that such an algorithm could not be expected to cover all scenarios, and that in some cases that consistency could just mean it was consistently incorrect.

As part of a standard, I'd like to see such an algorithm and have it cover as much variance as possible -- the whole endpoint identification thing does not have much worth as a standard if results are inconsistent/unpredictable across implementers.  At the same time implementers are going to be much quicker to respond to errors and changing technologies than a standards body and they need to be free to do so.

So I think this creates two needs:

1) The algorithm should not attempt to cover all variations, just as many as we have a high confidence in being able to define
2) The ability to utilize the algorithm should be available on request, but not required to always be used.  For example, when a consumer is making a request from a provider, that request should have the ability to specify that correlation must be done using the standard algorithm.

These seem reasonable.  We should consider algorithm agility as another need.

--gun

On 10/23/2015 1:33 PM, Haynes, Dan wrote:
Hi Everyone,

Here are the notes from today's Endpoint ID Design Team Meeting (EID-DT).

Attendees
*         Ron Colvin
*         Josh Stevens
*         Joe Wolfkiel
*         Danny Haynes

Note Well

Agenda
*         Task descriptions
*         Open issues from the last virtual interim meeting
*         Next steps

Materials
*         Slides from meeting (see attached)
*         Task descriptions (see attached).

Notes
*         First, the task descriptions document was discussed.  All the discussion and feedback around this was captured in Word comments in the document.  An updated version based on feedback and discussion, will be sent out prior to the next EID-DT meeting.

*         A question was asked about where we were at with the Architecture document.  It was explained that we have made a lot of good progress recently during the two calls after the virtual interim meeting and that notes for those meetings were captured in the GitHub issue trackers that were discussed.  It was also noted that if anyone had feedback on the Architecture that they should send it out to the group sooner rather than later.

*         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive information, and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.

Action Items
*         Update tasks descriptions before next EID-DT meeting (Danny Haynes)
*         Contribute NetD data model  (Joe Wolfkiel).

Please let me know if I missed anything, got anything wrong, or if you have any questions.

Thanks,

Danny

_______________________________________________

sacm mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/sacm

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

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 2 Nov 2015 13:10:01 +0000

+1 here.  We're in the process of updating our matching algorithm now.

Defining an algorithm will also inform the process of collecting a common set of data and being able to mediate it into a standardized format for comparison.

We should also keep in mind that different SACM sensors will have differing abilities to establish and track device identities over time.  Agent-based sensors can use the ID of their deployed agents, which (in my opinion) are pretty robust.  Over-the network active, authenticated scanners can try to retrieve some persistent, unique device attributes that can be used for identification.  Passive or unauthenticated scanners will be limited to trying to identify devices based on information the device(s) use to identify themselves on the network, information that can be derived by observing traffic sent and received by a device, or information received from unauthenticated service calls or probes.

It's my assumption that the point of doing endpoint identification is to be able to differentiate whether a device discovered by one sensor is or isn't the same device discovered by another or that information about a device described by a sensor at a point in time can be retrieved at a later point in time based on some "identification" heuristic.

The "identification" described above is a different issue than doing device "population" identification, which would consider how to describe and target policies or data collection efforts at groups of devices that share some common set of characteristics.

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

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Monday, November 02, 2015 3:27 AM
To: Adam Montville; Gunnar Engelbach
Cc: [email-masked]
Subject: Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

This email was sent from a non-Department of Defense email account, and contained active links. All links are disabled, and require you to copy and paste the address to a Web browser. Please verify the identity of the sender, and confirm authenticity of all links contained within the message. 

________________________________

Thanks,

Danny

From: Adam Montville [Caution-mailto:[email-masked]]

	On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	

	
	
	--gun

		Hi Everyone,

		Attendees

		.         Ron Colvin

		.         Josh Stevens

		.         Joe Wolfkiel

		.         Danny Haynes

		Note Well

		Agenda

		.         Task descriptions

		.         Open issues from the last virtual interim meeting

		.         Next steps

		Materials

		.         Slides from meeting (see attached)

		.         Task descriptions (see attached). 

		Notes

		.         First, the task descriptions document was discussed.  All the discussion and feedback around this was captured in Word comments in the document.  An updated version based on feedback and discussion, will be sent out prior to the next EID-DT meeting.

		.         A question was asked about where we were at with the Architecture document.  It was explained that we have made a lot of good progress recently during the two calls after the virtual interim meeting and that notes for those meetings were captured in the GitHub issue trackers that were discussed.  It was also noted that if anyone had feedback on the Architecture that they should send it out to the group sooner rather than later.

		.         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive information, 
 and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.

		Action Items

		.         Update tasks descriptions before next EID-DT meeting (Danny Haynes)

		.         Contribute NetD data model  (Joe Wolfkiel).

		Thanks,
		
		Danny

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

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

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 2 Nov 2015 09:53:13 -0500

> It's my assumption that the point of doing endpoint identification is to be able to differentiate whether a device discovered by one sensor is or isn't the same device discovered by another or that…

Those are two possible uses.  Two more are:

  * Being able to look up the proper ownership/role/etc information for 
an endpoint so that the proper guidance can be selected for it.
  * Being able to find the correct record of an endpoint in a data 
store:  to update attributes, retrieve other attributes, etc.

Other uses will abound, of course, but being able to satisfy at least 
these four seem to be necessary for the current scope of SACM.

Others?

> 		.         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive information, and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.
>
> 		
>
> 		Action Items
>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 2 Nov 2015 18:46:16 +0000

For the 2nd of your cases, is the thought that SACM would classify data stores as being ID-compliant or non ID-compliant?  At least one of the tools I'm familiar with uses the last known IP address as its primary identifier, so (in a DHCP environment), there's no guarantee that a device you search for and find with the tool's primary "identifier" on one day is the same device you'll find using the same "identifier" on a later date.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Monday, November 02, 2015 9:53 AM
To: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; Adam Montville
Cc: [email-masked]
Subject: Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

Others?

> 		.         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive information
 , and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 2 Nov 2015 14:33:25 -0500

> For the 2nd of your cases, is the thought that SACM would classify data stores as being ID-compliant or non ID-compliant?  At least one of the tools I'm familiar with uses the last known IP address…

That sounds like a reasonable supposition.  And it is likely possible to 
write an interface to that tool, either as part of that tool or from a 
separate system that has access to the data that tool stores, that 
implements the SACM communicates and data model sufficiently to enable 
it to part of a SACM environment.

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 2 Nov 2015 20:58:46 +0000

OK.  That's pretty close to what we're doing.  We collect the set of BIOS GUID, Motherboard S/N, DNS FQDN, NetBIOS FQDN, Other Vendor SACM agent GUID, host name, IPv4, IPv6, and MAC address, where available, and apply a device ID matching algorithm to attempt to match devices in our central repository.

In the central repository and in our agent-based tool, we just trust the locally assigned ID to be persistent and unique over time so we can usually skip the complex matching when we receive new data about a device or want to retrieve updated data from the repository.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Monday, November 02, 2015 2:33 PM
To: Wolfkiel, Joseph L CIV DISA ID (US); Haynes, Dan; Adam Montville
Cc: [email-masked]
Subject: Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

>> 		.         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive informatio
 n, and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 2 Nov 2015 16:36:17 -0500

Creating and passing around a unique identifier is an approach worth 
talking about further.  I can understand why you are doing it, and have 
implemented that kind of approach before, but even so I'm not certain 
there's any actual benefit to it.

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Mon, 2 Nov 2015 21:55:18 +0000

Gunnar,

Can you elaborate on how you are evaluating the benefit of such an approach?

Thanks,
Tim

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Gunnar Engelbach [[email-masked]]
Received: Monday, 02 Nov 2015, 4:36pm
To: Wolfkiel, Joseph L CIV DISA ID (US) [[email-masked]]; Haynes, Dan [[email-masked]]; Adam Montville [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: [External]  Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

On 11/2/2015 3:58 PM, Wolfkiel, Joseph L CIV DISA ID (US) wrote:
>>>             .         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive informati
 on, and running these databases.  It was noted that there are no explicit plans to create matching algorithms, etc. as of yet, but, that you could seem the matching possibly being part of a query language for interfacing with a repository or the information about the location of an endpoint or the sensitivity of the data on an endpoint being covered under the manually assigned data associated with an endpoint.  This is something the broader group may want to discuss further.

[email-masked]

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Mon, 2 Nov 2015 22:04:15 +0000

I'm probably just used to the idea.  We've been using the resource/record_id concept to send around device identifiers for quite a while, so it's pretty much baked into all our systems.  The "resource" is usually the common name of the sensor from its device PKI certificate, while the record_id is the database ID of a given device in the local DBMS for a given device.  We experimented with using GUIDs early on, but it turns out they're pretty long and don't compress well at all, while database IDs are sequential integers that start out small and compress pretty well.  Database IDs are also guaranteed to be unique due to RDBMS referential integrity constraints.

In our production system, you can get a http page with all known information about a device by sending a URL like the following, which is basically the resource concatenated with the record_id - https://cmrs.dod.mil/Pages/DeviceDetails.aspx?DeviceId=226736.  (Not a valid URL, but similar to production.  Sorry, OPSEC.) To the best of our ability to design it, going to this URL will always return the latest data about the same device, regardless of changes to its host name, IP, or MAC addresses.

Without a unique ID concept, you end up sending all the identifying information you have and getting back one or more matches, from which someone/thing has to figure out which is really the intended device.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Mon, 2 Nov 2015 23:46:28 +0000

Joe,

Just curious, but have you evaluated using a hash of a set of endpoint details, excluding details prone to change like IP address?  If so, did that run into the same challenges as the GUID, was it to inflexible for you're purposes, or something else entirely?

V/r,
Tim

-----Original Message-----
From: Wolfkiel, Joseph L CIV DISA ID (US) [[email-masked]]
Received: Monday, 02 Nov 2015, 5:04pm
To: Gunnar Engelbach [[email-masked]]; Haynes, Dan [[email-masked]]; Adam Montville [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: [External]  Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 2 Nov 2015 22:25:27 -0500

I'm just thinking of a pro/con evaluation of the approach.

Pros are things like smaller message payloads, not having to do the 
computation of an algorithm, and having a common handle that can be used 
for things like direct table lookups.

Cons are things like some points of observation won't have the ability 
to use an identifier, or when the identifier gets replicated to multiple 
endpoints (such as when instantiating multiple VMs from a master image, 
or ghosting a physical systems).  Every place a generated identifier is 
used in lieu of attribute matching the assumption is being made that the 
original correlation remains correct, so using the identifier makes it 
harder to detect and correct such a mistake.  And so on.

Most of the time using an assigned identifier is a nice simplification, 
and is more reliable than an attribute match, which is always fuzzy at best.

But in practical usage we are constantly finding exceptions that have to 
be detectable and accounted for, which means we still end up having to 
do attribute correlation anyway.  The presence of the identifier means 
there is a higher confidence in the identity of the endpoint, but it 
doesn't remove the need to have to still do attribute correlation.

--gun

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Tue, 3 Nov 2015 03:53:57 +0000

Thanks Gunnar!  I had a hunch, but you've bridged that gap.  So as I inquired in my response to Joe, would a hash of specific attributes help address these challenges or simply further complicate things.

My suggestion arises from some consideration regarding how search engines may differentiate between sites containing similar information, but with different HTML markup, or other information agnostic deltas which could be ignored in calculating "distance".  Though, this approach would be looking to include the closest match vs. filter it out.

Just spit balling on this one, feel free to flame on the errors/shortcomings of my suggestion.

Cheers,
Tim

-----Original Message-----
From: Gunnar Engelbach [[email-masked]]
Received: Monday, 02 Nov 2015, 10:25pm
To: Harrison, Timothy [USA] [[email-masked]]; [email-masked] [[email-masked]]; [email-masked] [[email-masked]]; [email-masked] [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [External] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

--gun

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 3 Nov 2015 09:01:01 -0500

For a hash to be useful it would need to not change, which means it 
needs to be based on information that does not change.  That could be 
used to indicate that sets of attributes are different, but it would not 
be reliable for identification.

--gun

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Tue, 3 Nov 2015 14:09:43 +0000

Agreed, and once you implement additional measures to overcome the
shortcomings for reliable identification it would likely be to resource
intensive to viable.  Thanks for setting me straight on this one.

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

-----Original Message-----
From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Tuesday, November 03, 2015 9:01 AM
To: Harrison, Timothy [USA] <[email-masked]>;
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [External] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

For a hash to be useful it would need to not change, which means it needs to
be based on information that does not change.  That could be used to
indicate that sets of attributes are different, but it would not be reliable
for identification.

--gun

On 11/2/2015 10:53 PM, Harrison, Timothy [USA] wrote:
> Thanks Gunnar!  I had a hunch, but you've bridged that gap.  So as I
inquired in my response to Joe, would a hash of specific attributes help
address these challenges or simply further complicate things.
>
> My suggestion arises from some consideration regarding how search engines
may differentiate between sites containing similar information, but with
different HTML markup, or other information agnostic deltas which could be
ignored in calculating "distance".  Though, this approach would be looking
to include the closest match vs. filter it out.
> To: Harrison, Timothy [USA] [[email-masked]]; 
> [email-masked] [[email-masked]]; 
> [email-masked] [[email-masked]]; [email-masked] 
> [[email-masked]]
> computation of an algorithm, and having a common handle that can be 
> used for things like direct table lookups.
>
> to use an identifier, or when the identifier gets replicated to 
> multiple endpoints (such as when instantiating multiple VMs from a 
> master image, or ghosting a physical systems).  Every place a 
> generated identifier is used in lieu of attribute matching the 
> assumption is being made that the original correlation remains 
> correct, so using the identifier makes it harder to detect and correct
such a mistake.  And so on.
>
>
> Most of the time using an assigned identifier is a nice 
> simplification, and is more reliable than an attribute match, which is
always fuzzy at best.
>
> But in practical usage we are constantly finding exceptions that have 
> to be detectable and accounted for, which means we still end up having 
> to do attribute correlation anyway.  The presence of the identifier 
> means there is a higher confidence in the identity of the endpoint, 
> but it doesn't remove the need to have to still do attribute correlation.
>
>
> --gun
>
>
>
>> To: Wolfkiel, Joseph L CIV DISA ID (US) 
>> [[email-masked]]; Haynes, Dan [[email-masked]]; 
>> Adam Montville [[email-masked]]
>> talking about further.  I can understand why you are doing it, and 
>> have implemented that kind of approach before, but even so I'm not 
>> certain there's any actual benefit to it.
>>
>>
>>
>>> OK.  That's pretty close to what we're doing.  We collect the set of
BIOS GUID, Motherboard S/N, DNS FQDN, NetBIOS FQDN, Other Vendor SACM agent
GUID, host name, IPv4, IPv6, and MAC address, where available, and apply a
device ID matching algorithm to attempt to match devices in our central
repository.
>>>
>>> In the central repository and in our agent-based tool, we just trust the
locally assigned ID to be persistent and unique over time so we can usually
skip the complex matching when we receive new data about a device or want to
retrieve updated data from the repository.
>>>> For the 2nd of your cases, is the thought that SACM would classify data
stores as being ID-compliant or non ID-compliant?  At least one of the tools
I'm familiar with uses the last known IP address as its primary identifier,
so (in a DHCP environment), there's no guarantee that a device you search
for and find with the tool's primary "identifier" on one day is the same
device you'll find using the same "identifier" on a later date.
>>> That sounds like a reasonable supposition.  And it is likely 
>>> possible to write an interface to that tool, either as part of that 
>>> tool or from a separate system that has access to the data that tool 
>>> stores, that implements the SACM communicates and data model 
>>> sufficiently to enable it to part of a SACM environment.
>>>
>>>
>>>
>>>> Joseph L. Wolfkiel
>>>> SCM Engineering Lead
>>>> DISA ID52
>>>>> Defining an algorithm will also inform the process of collecting a
common set of data and being able to mediate it into a standardized format
for comparison.
>>>>>
>>>>> We should also keep in mind that different SACM sensors will have
differing abilities to establish and track device identities over time.
Agent-based sensors can use the ID of their deployed agents, which (in my
opinion) are pretty robust.  Over-the network active, authenticated scanners
can try to retrieve some persistent, unique device attributes that can be
used for identification.  Passive or unauthenticated scanners will be
limited to trying to identify devices based on information the device(s) use
to identify themselves on the network, information that can be derived by
observing traffic sent and received by a device, or information received
from unauthenticated service calls or probes.
>>>>>
>>>>> It's my assumption that the point of doing endpoint identification is
to be able to differentiate whether a device discovered by one sensor is or
isn't the same device discovered by another or that information about a
device described by a sensor at a point in time can be retrieved at a later
point in time based on some "identification" heuristic.
>>>>       * Being able to look up the proper ownership/role/etc 
>>>> information for an endpoint so that the proper guidance can be selected
for it.
>>>> Other uses will abound, of course, but being able to satisfy at 
>>>> least these four seem to be necessary for the current scope of SACM.
>>>>
>>>> Others?
>>>>
>>>>
>>>>
>>>>> The "identification" described above is a different issue than doing
device "population" identification, which would consider how to describe and
target policies or data collection efforts at groups of devices that share
some common set of characteristics.
>>>>> This email was sent from a non-Department of Defense email account,
and contained active links. All links are disabled, and require you to copy
and paste the address to a Web browser. Please verify the identity of the
sender, and confirm authenticity of all links contained within the message.
>>>>>       On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach
<[email-masked] <
Caution-mailto:[email-masked] > > wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       Defining an algorithm would help with consistency in correlation
outcomes between implementers.  However, it would need to be acknowledged
that such an algorithm could not be expected to cover all scenarios, and
that in some cases that consistency could just mean it was consistently
incorrect.
>>>>>
>>>>>       As part of a standard, I'd like to see such an algorithm and
have it cover as much variance as possible -- the whole endpoint
identification thing does not have much worth as a standard if results are
inconsistent/unpredictable across implementers.  At the same time
implementers are going to be much quicker to respond to errors and changing
technologies than a standards body and they need to be free to do so.
>>>>>       1) The algorithm should not attempt to cover all variations,
just as many as we have a high confidence in being able to define
>>>>>       2) The ability to utilize the algorithm should be available on
request, but not required to always be used.  For example, when a consumer
is making a request from a provider, that request should have the ability to
specify that correlation must be done using the standard algorithm.
>>>>>               .         First, the task descriptions document was
discussed.  All the discussion and feedback around this was captured in Word
comments in the document.  An updated version based on feedback and
discussion, will be sent out prior to the next EID-DT meeting.
>>>>>
>>>>>
>>>>>
>>>>>               .         A question was asked about where we were at
with the Architecture document.  It was explained that we have made a lot of
good progress recently during the two calls after the virtual interim
meeting and that notes for those meetings were captured in the GitHub issue
trackers that were discussed.  It was also noted that if anyone had feedback
on the Architecture that they should send it out to the group sooner rather
than later.
>>>>>
>>>>>
>>>>>
>>>>>               .         There was also a question about the SACM
Charter.  Specifically, in addition to specifying the different data fields
associated with identifying endpoints, are their plans to standardize any
business logic around them.  For example, an algorithm for matching devices
using the data collected by two different sensors.  If the data collected by
two sensors, using the algorithm, match then the data could be combined as
it all represents the same endpoint.  It was noted that this is a real
problem that they are facing in the field and that it might be good to have
an industry standard around it.  Another example, is around defining
populations such as "these are all the devices owned by an organization", or
"these are all the devices in a single location".  There is also a question
around how accurate can it be (state, city, building, closet, etc.).  A last
example is making statements such as this applies to all servers running
Windows 2012, containing sensitive informati
>>    on, and running these databases.  It was noted that there are no
explicit plans to create matching algorithms, etc. as of yet, but, that you
could seem the matching possibly being part of a query language for
interfacing with a repository or the information about the location of an
endpoint or the sensitivity of the data on an endpoint being covered under
the manually assigned data associated with an endpoint.  This is something
the broader group may want to discuss further.
>>>>>               Caution-https://www.ietf.org/mailman/listinfo/sacm < 
>>>>> Caution-https://www.ietf.org/mailman/listinfo/sacm >
>>>>>
>>>>>
>>>>>       Caution-https://www.ietf.org/mailman/listinfo/sacm < 
>>>>> Caution-https://www.ietf.org/mailman/listinfo/sacm >
>>>>>
>>>>>
>>>>>

---

From: Chris Inacio <[email-masked]>
Date: Wed, 4 Nov 2015 23:54:59 +0000

I would be nervous about standardizing the algorithm.  I think an informational draft describing various algorithm methodologies and tradeoffs would be great to capture – but I’m nervous about setting “into stone” per se the algorithm.  Especially as I believe the right way forward will be to have an IANA registry for data model elements, and as we add more data elements, that might really change the landscape.

--
Chris Inacio
[email-masked]

> On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]> wrote:
> 
> 		.         There was also a question about the SACM Charter.  Specifically, in addition to specifying the different data fields associated with identifying endpoints, are their plans to standardize any business logic around them.  For example, an algorithm for matching devices using the data collected by two different sensors.  If the data collected by two sensors, using the algorithm, match then the data could be combined as it all represents the same endpoint.  It was noted that this is a real problem that they are facing in the field and that it might be good to have an industry standard around it.  Another example, is around defining populations such as "these are all the devices owned by an organization", or "these are all the devices in a single location".  There is also a question around how accurate can it be (state, city, building, closet, etc.).  A last example is making statements such as this applies to all servers running Windows 2012, containing sensitive info!
> rmation,

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 5 Nov 2015 13:23:17 +0000

Without an algorithm, how do you justify or prioritize collecting identification attributes?  If you want multi-vendor interoperability, it seems like we have to specify, at some level, what attributes are expected to be collected, how to exchange them between tools, and some standard thing we think the tools will do with them to "match" identities.  Right?  Or is there some other vision?  Can you explain how you would see this working if there's no common baseline matching algorithm?

I do agree that it seems reasonable to periodically update the attributes over time as we identify which attributes provide the highest confidence matches, followed by an update to the matching algorithm to incorporate the new capabilities.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Chris Inacio [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2015 6:55 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; [email-masked]
Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

All active links contained in this email were disabled.  Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.  

----

--
Chris Inacio
[email-masked]

> From: sacm [Caution-mailto:[email-masked]] On Behalf Of Haynes, Dan
> From: Adam Montville [Caution-Caution-mailto:[email-masked]]
> 	On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <[email-masked] < Caution-Caution-mailto:[email-masked] > > wrote:
> 
> 	 
> 
> 	
> 		[email-masked] < Caution-Caution-mailto:[email-masked] > 
> 		Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm > 
> 
> 	
> 	[email-masked] < Caution-Caution-mailto:[email-masked] > 
> 	Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm > 
> 
> 
> 
> Caution-https://www.ietf.org/mailman/listinfo/sacm

---

From: Sherif Mansour Farag <[email-masked]>
Date: Thu, 5 Nov 2015 14:18:38 +0000

Looking at it from an enterprise perspective with several vendors, I would expect there to be an interface with defined required and optional set of attributes.

This allows a vendor to integrate into scam, by creating features/modules that translate their information into attributes scam expects. The goal is for them to know what to push/pull, and how. Equally if they need to provide a listening service for scam, then that is also defined. 

For example we might assume some high-level attributes would not change (OS,IP,Hostname, etc..) while some might change overtime hence setting them as optional leaving room for a vendor to add and remove.

However even if a vendor sends their data in the correct model scam would require, there is also the issue that different vendors might send different values for the same e.g  for OS you might get WinXp/Windows XP/Microsoft Windows XP etc... 

This might seem a bit pedantic, but if you want to query how many windows XP machines are impacted by a specific security issue, you will not have a complete picture.

It would be too prescriptive to state the value of of attribute X should look exactly as it does in the following config/registry/command output. 

Sherif Mansour
Enterprise Information Security
Sr Security Engineer | EIS – Secure Design & Consulting
T + 44 (0) 203 194 5245 |  M + 44 (0) 7860 782936
Expedia.com Ltd – 407 St John St, London EC1V4EX
____________________________________
From: sacm <[email-masked]> on behalf of Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]>
Sent: Thursday, November 05, 2015 1:23 PM
To: Chris Inacio
Cc: Gunnar Engelbach; Haynes, Dan; Adam Montville; [email-masked]
Subject: Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Chris Inacio [mailto:[email-masked]]
Sent: Wednesday, November 04, 2015 6:55 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; [email-masked]
Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

----

--
Chris Inacio
[email-masked]

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 12:38:15 -0500

> However even if a vendor sends their data in the correct model scam would require, there is also the issue that different vendors might send different values for the same e.g  for OS you might get…

I'm glad you brought this up, because it has been a significant and 
ongoing problem.

Even when an existing standard, like CPE, is used to normalize 
identifications, there still is a lot of slop due to exactly this problem.

The solution that has grown up in a rather ad-hoc fashion is to ignore 
the CPE dictionary, but to make identifiers self-deterministic by 
referencing code that can be executed and evaluated.  In the SCAP world, 
this code is OVAL, and because it is a published open standard with a 
validation process, and unambiguously dictates which system attributes 
to collect and the logic for interpreting them, it is portable and 
accurate for all validated implementations.

This is less of a problem for system identification.  In that case, the 
system attributes are most likely to be collected via the same agency, 
so the collected values will be self-consistent and therefore correlate 
properly.  But to allow for the possibility that multiple agencies will 
be collecting identification attributes from the same endpoint, it will 
also be necessary to strive to specify where certain values come from 
(the Windows product name, for example, comes from the registry key 
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName).  It 
would also be possible to maintain a table of the standardized values 
used for certain fields, but the problems related to maintaining such a 
table and keep it up to date at all points of usage makes it a 
workaround I would really like to avoid.

---

From: Sherif Mansour Farag <[email-masked]>
Date: Thu, 5 Nov 2015 17:59:48 +0000

Ok, given that SACM's scope is more than vulnerabilities, does it make sense to build on OVAL and expand on it to include additional attributes we care about?
This might help limit this problem, and leverage the existing support for OVAL already out there.

Thoughts?

________________________________________
From: Gunnar Engelbach <[email-masked]>
Sent: Thursday, November 05, 2015 5:38 PM
To: Sherif Mansour Farag; Wolfkiel, Joseph L CIV DISA ID (US); Chris Inacio
Cc: Haynes, Dan; Adam Montville; [email-masked]
Subject: Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 5 Nov 2015 13:12:22 -0500

>
>
> However even if a vendor sends their data in the correct model scam would
> require, there is also the issue that different vendors might send
> different values for the same e.g  for OS you might get WinXp/Windows
> XP/Microsoft Windows XP etc...
>
>
​The solution to this is to allow the software vendor to specify how their
software will be identified. This is already happening with vendor adoption
of SWID tags. The SWID tag can be created by the software vendor and
included as a part of the software. Many vendors (including Microsoft) are
doing this for licensing issues. If a vendor does not include a SWID tag
with their software, an installer can create a tag at the time of
installation, or freely-available open source software can create tags for
products on enterprise endpoints (an ideal solution for older endpoints).

> This might seem a bit pedantic, but if you want to query how many windows
> XP machines are impacted by a specific security issue, you will not have a
> complete picture.
>

​Not pedantic at all!​

​It's been a problem that has plagued our networks for far too long now,
and must be tackled by this work group if we are going to solve our broader
use cases.
​

>
> It would be too prescriptive to state the value of of attribute X should
> look exactly as it does in the following config/registry/command output.
>

​Agreed. That is why the SWID tag format is useful here.
​

> From: sacm <[email-masked]> on behalf of Wolfkiel, Joseph L CIV
> DISA ID (US) <[email-masked]>
> Without an algorithm, how do you justify or prioritize collecting
> identification attributes?  If you want multi-vendor interoperability, it
> seems like we have to specify, at some level, what attributes are expected
> to be collected, how to exchange them between tools, and some standard
> thing we think the tools will do with them to "match" identities.  Right?
> Or is there some other vision?  Can you explain how you would see this
> working if there's no common baseline matching algorithm?
>
> I do agree that it seems reasonable to periodically update the attributes
> over time as we identify which attributes provide the highest confidence
> matches, followed by an update to the matching algorithm to incorporate the
> new capabilities.
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> All active links contained in this email were disabled.  Please verify the
> identity of the sender, and confirm the authenticity of all links contained
> within the message prior to copying and pasting the address to a Web
> browser.
>
>
>
>
> ----
>
>
>
> I would be nervous about standardizing the algorithm.  I think an
> informational draft describing various algorithm methodologies and
> tradeoffs would be great to capture – but I’m nervous about setting “into
> stone” per se the algorithm.  Especially as I believe the right way forward
> will be to have an IANA registry for data model elements, and as we add
> more data elements, that might really change the landscape.
>
>
>
> --
> Chris Inacio
> [email-masked]
>
>
>
> opinion) are pretty robust.  Over-the network active, authenticated
> scanners can try to retrieve some persistent, unique device attributes that
> can be used for identification.  Passive or unauthenticated scanners will
> be limited to trying to identify devices based on information the device(s)
> use to identify themselves on the network, information that can be derived
> by observing traffic sent and received by a device, or information received
> > It's my assumption that the point of doing endpoint identification is to
> be able to differentiate whether a device discovered by one sensor is or
> device "population" identification, which would consider how to describe
> and target policies or data collection efforts at groups of devices that
> share some common set of characteristics.
> >
> > Joseph L. Wolfkiel
> > SCM Engineering Lead
> > DISA ID52
> > This email was sent from a non-Department of Defense email account, and
> contained active links. All links are disabled, and require you to copy and
> paste the address to a Web browser. Please verify the identity of the
> >       On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <
> [email-masked] < Caution-Caution-mailto:
> [email-masked] > > wrote:
> >
> >
> >
> >
> >       As part of a standard, I'd like to see such an algorithm and have
> it cover as much variance as possible -- the whole endpoint identification
> thing does not have much worth as a standard if results are
> >       1) The algorithm should not attempt to cover all variations, just
> as many as we have a high confidence in being able to define
> is making a request from a provider, that request should have the ability
> to specify that correlation must be done using the standard algorithm.
> >
> >
> >
> discussed.  All the discussion and feedback around this was captured in
> Word comments in the document.  An updated version based on feedback and
> >               .         A question was asked about where we were at with
> the Architecture document.  It was explained that we have made a lot of
> trackers that were discussed.  It was also noted that if anyone had
> feedback on the Architecture that they should send it out to the group
> sooner rather than later.
> >
> >
> >
> using the data collected by two different sensors.  If the data collected
> by two sensors, using the algorithm, match then the data could be combined
> as it all represents the same endpoint.  It was noted that this is a real
> populations such as "these are all the devices owned by an organization",
> or "these are all the devices in a single location".  There is also a
> question around how accurate can it be (state, city, building, closet,
> etc.).  A last example is making statements such as this applies to all
> servers running Windows 2012, containing sensitive info!
> > rmation,
> > and running these databases.  It was noted that there are no explicit
> plans to create matching algorithms, etc. as of yet, but, that you could
> seem the matching possibly being part of a query language for interfacing
> with a repository or the information about the location of an endpoint or
> the sensitivity of the data on an endpoint being covered under the manually
> assigned data associated with an endpoint.  This is something the broader
> group may want to discuss further.
> >
> >
> >
> >               Action Items
> >
> >               Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm
> < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm >
> >
> >
> >       Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm <
> Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm >
> >
> >
> >

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Thu, 5 Nov 2015 18:20:36 +0000

Hi Jessica,

If customer ‘A’ creates a SWID tag during installation for a product and customer ‘B’, who has no visibility back to customer A, creates a SWID tag for the same piece of software during installation will their SWID tags be the same?

Thanks,

Tim

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

 <http://www.boozallen.com/> www.boozallen.com

From: sacm [mailto:[email-masked]] On Behalf Of Jessica Fitzgerald-McKay
Sent: Thursday, November 05, 2015 1:12 PM
To: Sherif Mansour Farag <[email-masked]>
Cc: Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>; Gunnar Engelbach <[email-masked]>; Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]>; Chris Inacio <[email-masked]>; [email-masked]
Subject: [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

​The solution to this is to allow the software vendor to specify how their software will be identified. This is already happening with vendor adoption of SWID tags. The SWID tag can be created by the software vendor and included as a part of the software. Many vendors (including Microsoft) are doing this for licensing issues. If a vendor does not include a SWID tag with their software, an installer can create a tag at the time of installation, or freely-available open source software can create tags for products on enterprise endpoints (an ideal solution for older endpoints).

​Not pedantic at all!​

​It's been a problem that has plagued our networks for far too long now, and must be tackled by this work group if we are going to solve our broader use cases.
​

Sherif Mansour
Enterprise Information Security
Sr Security Engineer | EIS – Secure Design & Consulting
T + 44 (0) 203 194 5245 |  M + 44 (0) 7860 782936
Expedia.com Ltd – 407 St John St, London EC1V4EX
____________________________________
From: sacm <[email-masked] <mailto:[email-masked]> > on behalf of Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] <mailto:[email-masked]> >
Sent: Thursday, November 05, 2015 1:23 PM
To: Chris Inacio
Cc: Gunnar Engelbach; Haynes, Dan; Adam Montville; [email-masked] <mailto:[email-masked]> 
Subject: Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Fort Meade DISA Acquisiton Bldg Cube A4A58E
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked] <mailto:[email-masked]> 

-----Original Message-----
From: Chris Inacio [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Wednesday, November 04, 2015 6:55 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; [email-masked] <mailto:[email-masked]> 
Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

----

--
Chris Inacio
[email-masked] <mailto:[email-masked]> 

> On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] <mailto:[email-masked]> > wrote:
>
> [email-masked] <mailto:[email-masked]> 
>
>
> From: sacm [Caution-mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Haynes, Dan
> Cc: [email-masked] <mailto:[email-masked]> 
> From: Adam Montville [Caution-Caution-mailto:[email-masked] <mailto:[email-masked]> ]
> To: Gunnar Engelbach <[email-masked] <mailto:[email-masked]> >
> Cc: Haynes, Dan <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
>       On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <[email-masked] <mailto:[email-masked]>  < Caution-Caution-mailto:[email-masked] <mailto:[email-masked]>  > > wrote:
>
>
>
>
>               [email-masked] <mailto:[email-masked]>  < Caution-Caution-mailto:[email-masked] <mailto:[email-masked]>  >
>       [email-masked] <mailto:[email-masked]>  < Caution-Caution-mailto:[email-masked] <mailto:[email-masked]>  >
> [email-masked] <mailto:[email-masked]> 
_______________________________________________
sacm mailing list
[email-masked] <mailto:[email-masked]>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 13:27:08 -0500

OVAL is one possibility, but SACM has not progressed far enough yet to 
make that determination.  And the example I give of CPE using OVAL to do 
self-determination is just one example, that type of self-determination 
can be done with any accepted standard as long as it has sufficient 
capabilities.  I'm not aware of anything other than OVAL, however, that 
can do it*.

* Well, certainly, C/C++, Java, etc -- but those would be unacceptable 
for other reasons.

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 5 Nov 2015 13:28:39 -0500

That depends on the tool they use the create the tag. Potentially, yes. We
are looking at a decreasing set of products that do not drop a tag at the
time of installation, so it's not a given that this will be a huge problem.

More interestingly, an enterprise can ensure that SWID creation within
their network create the same tag for the same product across their
network. Think about it in terms of the vulnerability assessment use case:
when a vulnerability is announced for SoftwareXYZ, customers A and B do not
need to know how the other creates a SWID tag for SoftwareXYZ. They need to
know how their network creates a tag for SoftwareXYZ, and to be able to
locate the endpoints that have that tag.

I hope that folks interested in this topic will take another look at the
Endpoint Compliance Internet Draft:
https://datatracker.ietf.org/doc/draft-fitzgeraldmckay-sacm-endpointcompliance/.
It describes how tags can be collected and stored as soon as they are
installed on an endpoint. This enables asset management, as well as the
vulnerability assessment use case.

On Thu, Nov 5, 2015 at 1:20 PM, Harrison, Timothy [USA] <
[email-masked]> wrote:

> Hi Jessica,
>
>
>
> If customer ‘A’ creates a SWID tag during installation for a product and
> customer ‘B’, who has no visibility back to customer A, creates a SWID tag
> for the same piece of software during installation will their SWID tags be
> the same?
>
>
>
> Thanks,
>
> Tim
>
>
>
>
>
>
> Timothy Harrison
>
> Lead Technologist
>
> Mobile 717-372-5768
>
> www.boozallen.com
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Jessica
> Fitzgerald-McKay
> *Sent:* Thursday, November 05, 2015 1:12 PM
> *To:* Sherif Mansour Farag <[email-masked]>
> *Cc:* Haynes, Dan <[email-masked]>; Adam Montville <
> [email-masked]>; Gunnar Engelbach <
> [email-masked]>; Wolfkiel, Joseph L CIV DISA ID (US) <
> [email-masked]>; Chris Inacio <[email-masked]>;
> [email-masked]
> *Subject:* [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design
> Team Notes: 2015-10-23
>
>
>
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 13:29:54 -0500

SWID works great for cases where there is a definitive vendor tag, and 
as such needs to be taken care of.  But otherwise it's just the same 
problem wrapped in an XML schema.

On 11/5/2015 1:12 PM, Jessica Fitzgerald-McKay wrote:
>
>
>     However even if a vendor sends their data in the correct model
>     scam would require, there is also the issue that different vendors
>     might send different values for the same e.g  for OS you might get
>     WinXp/Windows XP/Microsoft Windows XP etc...
>
>
> ​The solution to this is to allow the software vendor to specify how 
> their software will be identified. This is already happening with 
> vendor adoption of SWID tags. The SWID tag can be created by the 
> software vendor and included as a part of the software. Many vendors 
> (including Microsoft) are doing this for licensing issues. If a vendor 
> does not include a SWID tag with their software, an installer can 
> create a tag at the time of installation, or freely-available open 
> source software can create tags for products on enterprise endpoints 
> (an ideal solution for older endpoints).
>
>     This might seem a bit pedantic, but if you want to query how many
>     windows XP machines are impacted by a specific security issue, you
>     will not have a complete picture.
>
>
> ​Not pedantic at all!​
> ​It's been a problem that has plagued our networks for far too long 
> now, and must be tackled by this work group if we are going to solve 
> our broader use cases.
> ​
>
>
>     It would be too prescriptive to state the value of of attribute X
>     should look exactly as it does in the following
>     config/registry/command output.
>
>
>     From: sacm <[email-masked] <mailto:[email-masked]>>
>     on behalf of Wolfkiel, Joseph L CIV DISA ID (US)
>     <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     identification attributes?  If you want multi-vendor
>     interoperability, it seems like we have to specify, at some level,
>     what attributes are expected to be collected, how to exchange them
>     between tools, and some standard thing we think the tools will do
>     with them to "match" identities.  Right?  Or is there some other
>     vision?  Can you explain how you would see this working if there's
>     no common baseline matching algorithm?
>
>     I do agree that it seems reasonable to periodically update the
>     attributes over time as we identify which attributes provide the
>     highest confidence matches, followed by an update to the matching
>     algorithm to incorporate the new capabilities.
>
>     Joseph L. Wolfkiel
>     SCM Engineering Lead
>     DISA ID52
>     From: Chris Inacio [mailto:[email-masked] <mailto:[email-masked]>]
>     <mailto:[email-masked]>
>     All active links contained in this email were disabled.  Please
>     verify the identity of the sender, and confirm the authenticity of
>     all links contained within the message prior to copying and
>     pasting the address to a Web browser.
>
>
>
>
>     ----
>
>
>
>     tradeoffs would be great to capture – but I’m nervous about
>     setting “into stone” per se the algorithm.  Especially as I
>     believe the right way forward will be to have an IANA registry for
>     data model elements, and as we add more data elements, that might
>     really change the landscape.
>
>
>
>     --
>     Chris Inacio
>     > On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV DISA ID (US)
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Defining an algorithm will also inform the process of collecting
>     a common set of data and being able to mediate it into a
>     standardized format for comparison.
>     >
>     > We should also keep in mind that different SACM sensors will
>     have differing abilities to establish and track device identities
>     over time.  Agent-based sensors can use the ID of their deployed
>     agents, which (in my opinion) are pretty robust.  Over-the network
>     active, authenticated scanners can try to retrieve some
>     persistent, unique device attributes that can be used for
>     identification.  Passive or unauthenticated scanners will be
>     limited to trying to identify devices based on information the
>     device(s) use to identify themselves on the network, information
>     that can be derived by observing traffic sent and received by a
>     device, or information received from unauthenticated service calls
>     or probes.
>     >
>     > It's my assumption that the point of doing endpoint
>     identification is to be able to differentiate whether a device
>     discovered by one sensor is or isn't the same device discovered by
>     another or that information about a device described by a sensor
>     at a point in time can be retrieved at a later point in time based
>     on some "identification" heuristic.
>     >
>     > The "identification" described above is a different issue than
>     doing device "population" identification, which would consider how
>     to describe and target policies or data collection efforts at
>     groups of devices that share some common set of characteristics.
>     >
>     > Joseph L. Wolfkiel
>     > SCM Engineering Lead
>     > DISA ID52
>     <mailto:[email-masked]>
>     >
>     >
>     > From: sacm [Caution-mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Haynes, Dan
>     > This email was sent from a non-Department of Defense email
>     account, and contained active links. All links are disabled, and
>     require you to copy and paste the address to a Web browser. Please
>     verify the identity of the sender, and confirm authenticity of all
>     links contained within the message.
>     >
>     >
>     > From: Adam Montville
>     [Caution-Caution-mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > To: Gunnar Engelbach <[email-masked]
>     <mailto:[email-masked]>>
>     > Cc: Haynes, Dan <[email-masked] <mailto:[email-masked]>>;
>     <[email-masked]
>     <mailto:[email-masked]> <
>     Caution-Caution-mailto:[email-masked]
>     <mailto:[email-masked]> > > wrote:
>     >
>     >
>     >
>     >
>     >       Defining an algorithm would help with consistency in
>     correlation outcomes between implementers.  However, it would need
>     to be acknowledged that such an algorithm could not be expected to
>     cover all scenarios, and that in some cases that consistency could
>     just mean it was consistently incorrect.
>     >
>     >       As part of a standard, I'd like to see such an algorithm
>     and have it cover as much variance as possible -- the whole
>     endpoint identification thing does not have much worth as a
>     standard if results are inconsistent/unpredictable across
>     implementers.  At the same time implementers are going to be much
>     quicker to respond to errors and changing technologies than a
>     standards body and they need to be free to do so.
>     >
>     >       1) The algorithm should not attempt to cover all
>     variations, just as many as we have a high confidence in being
>     able to define
>     >       2) The ability to utilize the algorithm should be
>     available on request, but not required to always be used.  For
>     example, when a consumer is making a request from a provider, that
>     request should have the ability to specify that correlation must
>     be done using the standard algorithm.
>     >
>     >
>     >
>     >               .         First, the task descriptions document
>     was discussed.  All the discussion and feedback around this was
>     captured in Word comments in the document.  An updated version
>     based on feedback and discussion, will be sent out prior to the
>     next EID-DT meeting.
>     >
>     >
>     >
>     >               .         A question was asked about where we were
>     at with the Architecture document.  It was explained that we have
>     made a lot of good progress recently during the two calls after
>     the virtual interim meeting and that notes for those meetings were
>     captured in the GitHub issue trackers that were discussed.  It was
>     also noted that if anyone had feedback on the Architecture that
>     they should send it out to the group sooner rather than later.
>     >
>     >
>     >
>     Charter.  Specifically, in addition to specifying the different
>     data fields associated with identifying endpoints, are their plans
>     to standardize any business logic around them.  For example, an
>     algorithm for matching devices using the data collected by two
>     different sensors.  If the data collected by two sensors, using
>     the algorithm, match then the data could be combined as it all
>     represents the same endpoint.  It was noted that this is a real
>     problem that they are facing in the field and that it might be
>     good to have an industry standard around it. Another example, is
>     around defining populations such as "these are all the devices
>     owned by an organization", or "these are all the devices in a
>     single location".  There is also a question around how accurate
>     can it be (state, city, building, closet, etc.).  A last example
>     is making statements such as this applies to all servers running
>     Windows 2012, containing sensitive info!
>     > rmation,
>     > and running these databases.  It was noted that there are no
>     explicit plans to create matching algorithms, etc. as of yet, but,
>     that you could seem the matching possibly being part of a query
>     language for interfacing with a repository or the information
>     about the location of an endpoint or the sensitivity of the data
>     on an endpoint being covered under the manually assigned data
>     associated with an endpoint. This is something the broader group
>     may want to discuss further.
>     >
>     >
>     >
>     >               Action Items
>     >
>     >               Please let me know if I missed anything, got
>     anything wrong, or if you have any questions.
>     >
>     >
>     >
>     >               Thanks,
>     >
>     >               Danny
>     >
>     >
>     >
>     >
>     >
>     >
>     > [email-masked] <mailto:[email-masked]> <
>     Caution-Caution-mailto:[email-masked] <mailto:[email-masked]> >
>     >             
>     > [email-masked] <mailto:[email-masked]> <
>     Caution-Caution-mailto:[email-masked] <mailto:[email-masked]> >

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 5 Nov 2015 13:34:19 -0500

I disagree. I am going to joyously steal content from Dave Waltermire (hi,
Dave!) since he recently addressed this topic in the MILE WG. SWIDS are
good for:

- Providing authoritative, high-fidelity software data generated at build
time by the software creator/publisher. CPEs are commonly generated by 3rd
parties in a labor intensive way by scraping vendor websites and
vulnerability bulletins for software data that is often incomplete and
inaccurate.

- Providing more robust software metadata that goes beyond the 11 fields
supported by CPE including tags/identification for patches which CPE
doesn't support.

- Normalizing the data representation for installed software on endpoints
regardless of platform/software specific technologies.

- Providing software footprint details including composite files, versions,
and hashes. This is not something that CPE supports.

Simply put, SWIDs provide greater support for the management of software
across the deployment lifecycle than CPE allows for.

On Thu, Nov 5, 2015 at 1:29 PM, Gunnar Engelbach <
[email-masked]> wrote:

>
> SWID works great for cases where there is a definitive vendor tag, and as
> such needs to be taken care of.  But otherwise it's just the same problem
> wrapped in an XML schema.
>
>
>> DISA ID (US) < <[email-masked]>
>> [email-masked]>
>> Cc: Gunnar Engelbach; Haynes, Dan; Adam Montville; <[email-masked]>
>> [email-masked]
>> Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; <[email-masked]>
>> [email-masked]
>> All active links contained in this email were disabled.  Please verify
>> the identity of the sender, and confirm the authenticity of all links
>> contained within the message prior to copying and pasting the address to a
>> Web browser.
>>
>>
>>
>>
>> ----
>>
>>
>>
>> > From: sacm [Caution-mailto: <[email-masked]>
>> [email-masked]] On Behalf Of Haynes, Dan
>> > From: Adam Montville [Caution-Caution-mailto:
>> <[email-masked]>[email-masked]]
>> > To: Gunnar Engelbach < <[email-masked]>
>> [email-masked]>
>> with the Architecture document.  It was explained that we have made a lot
>> of good progress recently during the two calls after the virtual interim
>> >               Caution-Caution-
>> <https://www.ietf.org/mailman/listinfo/sacm>
>> https://www.ietf.org/mailman/listinfo/sacm < Caution-Caution-
>> https://www.ietf.org/mailman/listinfo/sacm >
>> >
>> >

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Thu, 5 Nov 2015 18:34:53 +0000

Thanks for clarifying things.  So, to add one level of complexity to the scenario consider customers A and B must feed this data to some overarching organization for tracking purposes.  If their tags differ is there a means by which one may easily correlate the two tags as being for the same product without any additional provenance details?

BTW, thanks for the link!

Cheers,

Tim

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

From: Jessica Fitzgerald-McKay [mailto:[email-masked]] 
Sent: Thursday, November 05, 2015 1:29 PM
To: Harrison, Timothy [USA] <[email-masked]>
Cc: Sherif Mansour Farag <[email-masked]>; Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>; Gunnar Engelbach <[email-masked]>; Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]>; Chris Inacio <[email-masked]>; [email-masked]
Subject: Re: [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

That depends on the tool they use the create the tag. Potentially, yes. We are looking at a decreasing set of products that do not drop a tag at the time of installation, so it's not a given that this will be a huge problem.

More interestingly, an enterprise can ensure that SWID creation within their network create the same tag for the same product across their network. Think about it in terms of the vulnerability assessment use case: when a vulnerability is announced for SoftwareXYZ, customers A and B do not need to know how the other creates a SWID tag for SoftwareXYZ. They need to know how their network creates a tag for SoftwareXYZ, and to be able to locate the endpoints that have that tag.

I hope that folks interested in this topic will take another look at the Endpoint Compliance Internet Draft: https://datatracker.ietf.org/doc/draft-fitzgeraldmckay-sacm-endpointcompliance/. It describes how tags can be collected and stored as soon as they are installed on an endpoint. This enables asset management, as well as the vulnerability assessment use case.

On Thu, Nov 5, 2015 at 1:20 PM, Harrison, Timothy [USA] <[email-masked] <mailto:[email-masked]> > wrote:

Hi Jessica,

Thanks,

Tim

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

From: sacm [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Jessica Fitzgerald-McKay
Sent: Thursday, November 05, 2015 1:12 PM
To: Sherif Mansour Farag <[email-masked] <mailto:[email-masked]> >
Cc: Haynes, Dan <[email-masked] <mailto:[email-masked]> >; Adam Montville <[email-masked] <mailto:[email-masked]> >; Gunnar Engelbach <[email-masked] <mailto:[email-masked]> >; Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] <mailto:[email-masked]> >; Chris Inacio <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

​Not pedantic at all!​

Sherif Mansour

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Chris Inacio [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Wednesday, November 04, 2015 6:55 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; [email-masked] <mailto:[email-masked]> 
Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

----

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 5 Nov 2015 13:56:01 -0500

Like I said before, I think this problem is decreasing as adoption of SWID
tags increases. But, you are right, it will be a situation that has to be
dealt with for legacy software. There will need to be a mapping, but it
will be simplified because each customer will use the same tag within its
own enterprise network. Comparing a tag from customer A to a tag from
customer B will not be difficult. And, if tag comparison will be a constant
issue between two customers, they can choose the same SWID tag creator and
bypass the problem entirely.

On Thu, Nov 5, 2015 at 1:34 PM, Harrison, Timothy [USA] <
[email-masked]> wrote:

> Thanks for clarifying things.  So, to add one level of complexity to the
> scenario consider customers A and B must feed this data to some overarching
> organization for tracking purposes.  If their tags differ is there a means
> by which one may easily correlate the two tags as being for the same
> product without any additional provenance details?
>
>
>
> *From:* Jessica Fitzgerald-McKay [mailto:[email-masked]]
> *Sent:* Thursday, November 05, 2015 1:29 PM
> *To:* Harrison, Timothy [USA] <[email-masked]>
> *Cc:* Sherif Mansour Farag <[email-masked]>; Haynes, Dan <
> [email-masked]>; Adam Montville <[email-masked]>; Gunnar
> Engelbach <[email-masked]>; Wolfkiel, Joseph L CIV DISA
> ID (US) <[email-masked]>; Chris Inacio <[email-masked]>;
> [email-masked]
> *Subject:* Re: [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID
> Design Team Notes: 2015-10-23
>
>
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 14:02:25 -0500

It's not just that the creation of the SWID tags (or any tagging system) 
needs to be consistent, but that value used in the tag needs to be one 
that is recognized at the point of usage.

For the purpose of system identification, this is not a problem because 
the string is arbitrary -- it's just important that it be consistent.  
Which could still happen even with a single generated SWID because other 
systems might not be using SWIDs.

For something like applicability testing, however, the actual collected 
value is important and must match.  Which only works when there is a 
single global known value.  And we're having this discussion because 
that's not the case.

What has been shown to work very reliably, however, is for assessment 
content to use the same collection and evaluation system to specify the 
attributes and values necessary to self-determine its own 
applicability.  A language like OVAL is flexible enough to take 
advantage of a SWID if it is available or otherwise use other 
attributes, but even then it would have to be a SWID whose values were 
known to the content author.

On 11/5/2015 1:28 PM, Jessica Fitzgerald-McKay wrote:
> That depends on the tool they use the create the tag. Potentially, 
> yes. We are looking at a decreasing set of products that do not drop a 
> tag at the time of installation, so it's not a given that this will be 
> a huge problem.
>
> network. Think about it in terms of the vulnerability assessment use 
> case: when a vulnerability is announced for SoftwareXYZ, customers A 
> and B do not need to know how the other creates a SWID tag for 
> SoftwareXYZ. They need to know how their network creates a tag for 
> SoftwareXYZ, and to be able to locate the endpoints that have that tag.
>
> I hope that folks interested in this topic will take another look at 
> the Endpoint Compliance Internet Draft: 
> installed on an endpoint. This enables asset management, as well as 
> the vulnerability assessment use case.
>
> On Thu, Nov 5, 2015 at 1:20 PM, Harrison, Timothy [USA] 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Jessica,
>
>     If customer ‘A’ creates a SWID tag during installation for a
>     product and customer ‘B’, who has no visibility back to customer
>     A, creates a SWID tag for the same piece of software during
>     installation will their SWID tags be the same?
>
>     Thanks,
>
>     Tim
>
>     Booz Allen Hamilton
>
>     Timothy Harrison
>
>     Lead Technologist
>
>     Mobile 717-372-5768
>
>     www.boozallen.com <http://www.boozallen.com/>
>
>     *From:*sacm [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Jessica
>     Fitzgerald-McKay
>     *To:* Sherif Mansour Farag <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Haynes, Dan <[email-masked] <mailto:[email-masked]>>;
>     Adam Montville <[email-masked]
>     <mailto:[email-masked]>>; Gunnar Engelbach
>     <mailto:[email-masked]>>; Wolfkiel, Joseph L CIV
>     DISA ID (US) <[email-masked]
>     <mailto:[email-masked]>>; Chris Inacio
>     <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID
>         scam would require, there is also the issue that different
>         vendors might send different values for the same e.g  for OS
>         you might get WinXp/Windows XP/Microsoft Windows XP etc...
>
>     ​The solution to this is to allow the software vendor to specify
>     how their software will be identified. This is already happening
>     with vendor adoption of SWID tags. The SWID tag can be created by
>     the software vendor and included as a part of the software. Many
>     vendors (including Microsoft) are doing this for licensing issues.
>     If a vendor does not include a SWID tag with their software, an
>     installer can create a tag at the time of installation, or
>     freely-available open source software can create tags for products
>     on enterprise endpoints (an ideal solution for older endpoints).
>
>         This might seem a bit pedantic, but if you want to query how
>         many windows XP machines are impacted by a specific security
>         issue, you will not have a complete picture.
>
>     ​Not pedantic at all!​
>
>     ​It's been a problem that has plagued our networks for far too
>     long now, and must be tackled by this work group if we are going
>     to solve our broader use cases.
>     ​
>
>
>         It would be too prescriptive to state the value of of
>         attribute X should look exactly as it does in the following
>         From: sacm <[email-masked]
>         <mailto:[email-masked]>> on behalf of Wolfkiel, Joseph
>         L CIV DISA ID (US) <[email-masked]
>         Without an algorithm, how do you justify or prioritize
>         collecting identification attributes?  If you want
>         multi-vendor interoperability, it seems like we have to
>         specify, at some level, what attributes are expected to be
>         collected, how to exchange them between tools, and some
>         standard thing we think the tools will do with them to "match"
>         identities.  Right?  Or is there some other vision?  Can you
>         explain how you would see this working if there's no common
>         baseline matching algorithm?
>
>         attributes over time as we identify which attributes provide
>         the highest confidence matches, followed by an update to the
>         matching algorithm to incorporate the new capabilities.
>
>         Joseph L. Wolfkiel
>         SCM Engineering Lead
>         DISA ID52
>         All active links contained in this email were disabled. 
>         Please verify the identity of the sender, and confirm the
>         authenticity of all links contained within the message prior
>         to copying and pasting the address to a Web browser.
>
>
>
>
>         ----
>
>
>
>         I would be nervous about standardizing the algorithm.  I think
>         an informational draft describing various algorithm
>         methodologies and tradeoffs would be great to capture – but
>         I’m nervous about setting “into stone” per se the algorithm. 
>         Especially as I believe the right way forward will be to have
>         an IANA registry for data model elements, and as we add more
>         data elements, that might really change the landscape.
>
>
>
>         --
>         Chris Inacio
>         > On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV DISA ID
>         (US) <[email-masked]
>         > Defining an algorithm will also inform the process of
>         collecting a common set of data and being able to mediate it
>         into a standardized format for comparison.
>         >
>         have differing abilities to establish and track device
>         identities over time. Agent-based sensors can use the ID of
>         their deployed agents, which (in my opinion) are pretty
>         robust.  Over-the network active, authenticated scanners can
>         try to retrieve some persistent, unique device attributes that
>         can be used for identification.  Passive or unauthenticated
>         scanners will be limited to trying to identify devices based
>         on information the device(s) use to identify themselves on the
>         network, information that can be derived by observing traffic
>         sent and received by a device, or information received from
>         unauthenticated service calls or probes.
>         >
>         discovered by one sensor is or isn't the same device
>         discovered by another or that information about a device
>         described by a sensor at a point in time can be retrieved at a
>         later point in time based on some "identification" heuristic.
>         >
>         > The "identification" described above is a different issue
>         than doing device "population" identification, which would
>         consider how to describe and target policies or data
>         collection efforts at groups of devices that share some common
>         set of characteristics.
>         >
>         > Joseph L. Wolfkiel
>         > SCM Engineering Lead
>         > DISA ID52
>         account, and contained active links. All links are disabled,
>         and require you to copy and paste the address to a Web
>         browser. Please verify the identity of the sender, and confirm
>         authenticity of all links contained within the message.
>         >
>         >
>         > Cc: Haynes, Dan <[email-masked]
>         <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>         correlation outcomes between implementers. However, it would
>         need to be acknowledged that such an algorithm could not be
>         expected to cover all scenarios, and that in some cases that
>         consistency could just mean it was consistently incorrect.
>         >
>         >       As part of a standard, I'd like to see such an
>         algorithm and have it cover as much variance as possible --
>         the whole endpoint identification thing does not have much
>         worth as a standard if results are inconsistent/unpredictable
>         across implementers.  At the same time implementers are going
>         to be much quicker to respond to errors and changing
>         example, when a consumer is making a request from a provider,
>         that request should have the ability to specify that
>         correlation must be done using the standard algorithm.
>         >
>         >
>         >
>         >               .         First, the task descriptions
>         document was discussed.  All the discussion and feedback
>         around this was captured in Word comments in the document.  An
>         updated version based on feedback and discussion, will be sent
>         out prior to the next EID-DT meeting.
>         >
>         >
>         >
>         >               .         A question was asked about where we
>         were at with the Architecture document.  It was explained that
>         we have made a lot of good progress recently during the two
>         calls after the virtual interim meeting and that notes for
>         those meetings were captured in the GitHub issue trackers that
>         were discussed. It was also noted that if anyone had feedback
>         on the Architecture that they should send it out to the group
>         >               .         There was also a question about the
>         SACM Charter.  Specifically, in addition to specifying the
>         different data fields associated with identifying endpoints,
>         are their plans to standardize any business logic around
>         them.  For example, an algorithm for matching devices using
>         the data collected by two different sensors.  If the data
>         collected by two sensors, using the algorithm, match then the
>         data could be combined as it all represents the same
>         endpoint.  It was noted that this is a real problem that they
>         are facing in the field and that it might be good to have an
>         industry standard around it.  Another example, is around
>         defining populations such as "these are all the devices owned
>         by an organization", or "these are all the devices in a single
>         location".  There is also a question around how accurate can
>         it be (state, city, building, closet, etc.).  A last example
>         is making statements such as this applies to all servers
>         running Windows 2012, containing sensitive info!
>         > rmation,
>         explicit plans to create matching algorithms, etc. as of yet,
>         but, that you could seem the matching possibly being part of a
>         query language for interfacing with a repository or the
>         information about the location of an endpoint or the
>         sensitivity of the data on an endpoint being covered under the
>         manually assigned data associated with an endpoint.  This is
>         something the broader group may want to discuss further.
>         >
>         >
>         >
>         >               Action Items
>         >

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Thu, 5 Nov 2015 19:10:48 +0000

Thanks Jessica!

 

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

Sent: Thursday, November 05, 2015 1:56 PM

Like I said before, I think this problem is decreasing as adoption of SWID tags increases. But, you are right, it will be a situation that has to be dealt with for legacy software. There will need to be a mapping, but it will be simplified because each customer will use the same tag within its own enterprise network. Comparing a tag from customer A to a tag from customer B will not be difficult. And, if tag comparison will be a constant issue between two customers, they can choose the same SWID tag creator and bypass the problem entirely.

On Thu, Nov 5, 2015 at 1:34 PM, Harrison, Timothy [USA] <[email-masked] <mailto:[email-masked]> > wrote:

Cheers,

Tim

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

From: Jessica Fitzgerald-McKay [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, November 05, 2015 1:29 PM
To: Harrison, Timothy [USA] <[email-masked] <mailto:[email-masked]> >
Cc: Sherif Mansour Farag <[email-masked] <mailto:[email-masked]> >; Haynes, Dan <[email-masked] <mailto:[email-masked]> >; Adam Montville <[email-masked] <mailto:[email-masked]> >; Gunnar Engelbach <[email-masked] <mailto:[email-masked]> >; Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] <mailto:[email-masked]> >; Chris Inacio <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

Hi Jessica,

Thanks,

Tim

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

​Not pedantic at all!​

Sherif Mansour

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Chris Inacio [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Wednesday, November 04, 2015 6:55 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; [email-masked] <mailto:[email-masked]> 
Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

----

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 14:17:46 -0500

Well, yeah.  SWIDs are basically a set of pre-collected attributes. Very 
handy if it is available, for all the reasons that attribute collection 
is important to SACM as a whole.  However:

  * Even when a cryptographically secure vendor-supplied SWID is 
present, that does not mean it's an accurate representation of the 
current state of that endpoint
  * The values as expressed in the SWID must match the values expected 
for making security state determinations.  That's much less likely to be 
the case for third-party generated SWIDs, unless each enterprise that 
generates SWIDs also does the work of writing their own policy content 
to match them.
  * Some networked devices are unlikely to ever have SWIDs.  Routers, 
switches, SCADA, IoT, ...

By all means, let's take advantage of SWIDs to the degree to which they 
are available, but there are some problems related to SACM for which 
they are not a solution.

To put it another way, I don't see SWIDs as a good solution for the 
types of problems that are within the current scope of SACM, but there 
are enough compelling reasons for organizations to use them, to the 
point of using third-party SWID generators, that we can expect to find 
them increasingly available and something to take advantage of while not 
being dependent upon.

On 11/5/2015 1:34 PM, Jessica Fitzgerald-McKay wrote:
> I disagree. I am going to joyously steal content from Dave Waltermire 
> (hi, Dave!) since he recently addressed this topic in the MILE WG. 
> SWIDS are good for:
>
> - Providing authoritative, high-fidelity software data generated at 
> build time by the software creator/publisher. CPEs are commonly 
> generated by 3^rd parties in a labor intensive way by scraping vendor 
> websites and vulnerability bulletins for software data that is often 
> incomplete and inaccurate.
>
>
> - Providing more robust software metadata that goes beyond the 11 
> fields supported by CPE including tags/identification for patches 
> which CPE doesn't support.
>
>
> - Normalizing the data representation for installed software on 
> endpoints regardless of platform/software specific technologies.
>
>
> - Providing software footprint details including composite files, 
> versions, and hashes. This is not something that CPE supports.
>
> Simply put, SWIDs provide greater support for the management of 
> software across the deployment lifecycle than CPE allows for.
>
>
>
>
> On Thu, Nov 5, 2015 at 1:29 PM, Gunnar Engelbach 
> <mailto:[email-masked]>> wrote:
>
>
>     SWID works great for cases where there is a definitive vendor tag,
>     and as such needs to be taken care of.  But otherwise it's just
>     the same problem wrapped in an XML schema.
>
>
>>         However even if a vendor sends their data in the correct
>>         model scam would require, there is also the issue that
>>         different vendors might send different values for the same
>>         e.g  for OS you might get WinXp/Windows XP/Microsoft Windows
>>         XP etc...
>>
>>
>>     ​ The solution to this is to allow the software vendor to specify
>>     vendors (including Microsoft) are doing this for licensing
>>     issues. If a vendor does not include a SWID tag with their
>>     software, an installer can create a tag at the time of
>>     installation, or freely-available open source software can create
>>     tags for products on enterprise endpoints (an ideal solution for
>>     older endpoints).
>>
>>     ​ Not pedantic at all!​
>>     ​ It's been a problem that has plagued our networks for far too
>>     ​ Agreed. That is why the SWID tag format is useful here.
>>     ​
>>
>>
>>         Sherif Mansour
>>         standard thing we think the tools will do with them to
>>         "match" identities.  Right?  Or is there some other vision? 
>>         Can you explain how you would see this working if there's no
>>         common baseline matching algorithm?
>>
>>         I do agree that it seems reasonable to periodically update
>>         the attributes over time as we identify which attributes
>>         provide the highest confidence matches, followed by an update
>>         to the matching algorithm to incorporate the new capabilities.
>>
>>         Joseph L. Wolfkiel
>>         SCM Engineering Lead
>>         DISA ID52
>>         I would be nervous about standardizing the algorithm.  I
>>         think an informational draft describing various algorithm
>>         > We should also keep in mind that different SACM sensors
>>         will have differing abilities to establish and track device
>>         try to retrieve some persistent, unique device attributes
>>         that can be used for identification.  Passive or
>>         unauthenticated scanners will be limited to trying to
>>         identify devices based on information the device(s) use to
>>         identify themselves on the network, information that can be
>>         derived by observing traffic sent and received by a device,
>>         or information received from unauthenticated service calls or
>>         probes.
>>         >
>>         identification is to be able to differentiate whether a
>>         device discovered by one sensor is or isn't the same device
>>         described by a sensor at a point in time can be retrieved at
>>         a later point in time based on some "identification" heuristic.
>>         >
>>         collection efforts at groups of devices that share some
>>         common set of characteristics.
>>         >
>>         > Joseph L. Wolfkiel
>>         > SCM Engineering Lead
>>         > DISA ID52
>>         browser. Please verify the identity of the sender, and
>>         confirm authenticity of all links contained within the message.
>>         >
>>         >
>>         variations, just as many as we have a high confidence in
>>         being able to define
>>         available on request, but not required to always be used. 
>>         For example, when a consumer is making a request from a
>>         provider, that request should have the ability to specify
>>         that correlation must be done using the standard algorithm.
>>         >
>>         >
>>         >
>>         around this was captured in Word comments in the document. 
>>         An updated version based on feedback and discussion, will be
>>         sent out prior to the next EID-DT meeting.
>>         >
>>         >
>>         >
>>         were at with the Architecture document.  It was explained
>>         that we have made a lot of good progress recently during the
>>         two calls after the virtual interim meeting and that notes
>>         for those meetings were captured in the GitHub issue trackers
>>         that were discussed.  It was also noted that if anyone had
>>         feedback on the Architecture that they should send it out to
>>         the group sooner rather than later.
>>         >
>>         >
>>         >
>>         by an organization", or "these are all the devices in a
>>         single location".  There is also a question around how
>>         accurate can it be (state, city, building, closet, etc.).  A
>>         last example is making statements such as this applies to all
>>         > and running these databases.  It was noted that there are
>>         no explicit plans to create matching algorithms, etc. as of
>>         yet, but, that you could seem the matching possibly being
>>         part of a query language for interfacing with a repository or
>>         the information about the location of an endpoint or the
>>         sensitivity of the data on an endpoint being covered under
>>         the manually assigned data associated with an endpoint.  This
>>         is something the broader group may want to discuss further.
>>         >
>>         >
>>         >
>>         >               Action Items
>>         >

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 5 Nov 2015 14:20:20 -0500

The requirements document lists collection and evaluation as separate SACM
"tasks". This was done purposely, to enable the separation of collection
and evaluation of endpoint posture data, and to avoid some of the
implementation issues that come up when collection and evaluation are
performed simultaneously.

The vulnerability assessment scenario provides a good demonstration of why
separating those tasks is important. It is unscalable to scan all your
endpoints for applicable software each time a new vulnerability is
announced. What makes a great deal more sense is to maintain a database
with records of the software installed on each endpoint, then search that
database for endpoints that reported running that vulnerable software. You
are right that this will require an applicability language, and I fully
support the idea of SACM developing this as part of a vulnerability
assessment solution!

On Thu, Nov 5, 2015 at 2:02 PM, Gunnar Engelbach <
[email-masked]> wrote:

> needs to be consistent, but that value used in the tag needs to be one that
> is recognized at the point of usage.
>
> value is important and must match.  Which only works when there is a single
> global known value.  And we're having this discussion because that's not
> the case.
>
> attributes and values necessary to self-determine its own applicability.  A
> language like OVAL is flexible enough to take advantage of a SWID if it is
> available or otherwise use other attributes, but even then it would have to
> be a SWID whose values were known to the content author.
>
>
>
>
> <[email-masked]>[email-masked]> wrote:
>
>> Hi Jessica,
>>
>>
>>
>> <http://www.boozallen.com/>www.boozallen.com
>>
>>
>>
>> *To:* Sherif Mansour Farag < <[email-masked]>
>> [email-masked]>
>> <[email-masked]>[email-masked]>; Chris
>> Inacio <[email-masked]>; [email-masked]
>> their software will be identified. This is already happening with vendor
>> adoption of SWID tags. The SWID tag can be created by the software vendor
>> and included as a part of the software. Many vendors (including Microsoft)
>> are doing this for licensing issues. If a vendor does not include a SWID
>> tag with their software, an installer can create a tag at the time of
>> From: Chris Inacio [mailto: <[email-masked]>[email-masked]]
>> > Cc: Haynes, Dan < <[email-masked]>[email-masked]>; [email-masked]
>> <[email-masked]>[email-masked] <
>> Caution-Caution-mailto: <[email-masked]>
>> >                <[email-masked]>[email-masked] < Caution-Caution-mailto:
>> <[email-masked]>[email-masked] >
>> >               Caution-Caution-
>> >       [email-masked] < Caution-Caution-mailto: <[email-masked]>
>> [email-masked] >
>> >       Caution-Caution- <https://www.ietf.org/mailman/listinfo/sacm>

---

From: "Harrison, Timothy [USA]" <[email-masked]>
Date: Thu, 5 Nov 2015 19:23:22 +0000

Agreed, with OVAL there is more flexibility, but it comes at the cost of resource consumption.

Is the added resource consumption significant enough to impact the viability of leveraging OVAL in an enterprise environment?

Would it be acceptable for tools to convert it to a less resource intensive means of communicating and evaluating it so long as results are consistent?

 

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

From: Gunnar Engelbach [mailto:[email-masked]] 
Sent: Thursday, November 05, 2015 2:02 PM
To: Jessica Fitzgerald-McKay <[email-masked]>; Harrison, Timothy [USA] <[email-masked]>
Cc: Sherif Mansour Farag <[email-masked]>; Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>; Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]>; Chris Inacio <[email-masked]>; [email-masked]
Subject: Re: [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

It's not just that the creation of the SWID tags (or any tagging system) needs to be consistent, but that value used in the tag needs to be one that is recognized at the point of usage.

For the purpose of system identification, this is not a problem because the string is arbitrary -- it's just important that it be consistent.  Which could still happen even with a single generated SWID because other systems might not be using SWIDs.

For something like applicability testing, however, the actual collected value is important and must match.  Which only works when there is a single global known value.  And we're having this discussion because that's not the case.

What has been shown to work very reliably, however, is for assessment content to use the same collection and evaluation system to specify the attributes and values necessary to self-determine its own applicability.  A language like OVAL is flexible enough to take advantage of a SWID if it is available or otherwise use other attributes, but even then it would have to be a SWID whose values were known to the content author.

Hi Jessica,

Thanks,

Tim

Timothy Harrison

Lead Technologist

Mobile 717-372-5768

www.boozallen.com <http://www.boozallen.com> 

​Not pedantic at all!​

Sherif Mansour

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Chris Inacio [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Wednesday, November 04, 2015 6:55 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; [email-masked] <mailto:[email-masked]> 
Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

----

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 5 Nov 2015 14:31:52 -0500

>   * Even when a cryptographically secure vendor-supplied SWID is present,
> that does not mean it's an accurate representation of the current state of
> that endpoint
>

​The lying endpoint problem! It comes up so often in these types of
conversations, and I know everyone wants to have it solved once and for
all. But, if your machine is already hosed, scanning may not catch it
either. It may, but it may not, and now you are stuck in the same
uncomfortable position of not knowing what an accurate representation of
the current state of an endpoint looks like. SACM needs to focus on:

   - making sure healthy machines stay healthy; and,
   - getting an endpoint report that you can compare to network
   observations to catch an attacked endpoint in a lie (to site a common
   example around here, "hey, you told me you were a printer, why did I just
   see you open Internet Explorer!")

​

>  * The values as expressed in the SWID must match the values expected for
> making security state determinations.  That's much less likely to be the
> case for third-party generated SWIDs, unless each enterprise that generates
> SWIDs also does the work of writing their own policy content to match them.
>

​You just need to ensure that your enterprises SWID tags (when you are
forced to create them, which is getting more rare (sorry, I sound like a
broken record even to myself!)) are reflected in your policy. This is more
a matter of editing a policy (which almost all enterprises will do anyway)
than rewriting.
​

> switches, SCADA, IoT, ...

​I'm with you on SCADA and maybe IoT (its a broad category, so I don't want
to ever go on record about what I think IoT will or will not do!), but I
wouldn't bet against routers and switches just yet. ​Even if they never
adopt SWIDs, it is trivial to take SNMP or netconf/yang data and express
the same SWID-tag-like information we would want to gather from more
traditional endpoints. I don't think their lack of current adoption of the
SWID tag standard should stop us from using it where appropriate.

> are available, but there are some problems related to SACM for which they
> are not a solution.
>
> To put it another way, I don't see SWIDs as a good solution for the types
> of problems that are within the current scope of SACM, but there are enough
> compelling reasons for organizations to use them, to the point of using
> third-party SWID generators, that we can expect to find them increasingly
> available and something to take advantage of while not being dependent upon.
>
>
​Much as I sound like a SWID tag apologist, I am sure you are right. There
are definitely problems they cannot solve. Can you point to examples from
our use case document where we should be considering other software
identification schema?
​

>>> However even if a vendor sends their data in the correct model scam
>>> would require, there is also the issue that different vendors might send
>> ​ The solution to this is to allow the software vendor to specify how
>>> windows XP machines are impacted by a specific security issue, you will not
>>> have a complete picture.
>>>
>>
>> ​ Not pedantic at all!​
>>
>> ​ It's been a problem that has plagued our networks for far too long now,
>>> attributes over time as we identify which attributes provide the highest
>>> confidence matches, followed by an update to the matching algorithm to
>>> incorporate the new capabilities.
>>>
>>> Joseph L. Wolfkiel
>>> SCM Engineering Lead
>>> DISA ID52
>>> > On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV DISA ID (US) <
>>> <[email-masked]>[email-masked]> wrote:
>>> >

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 14:52:55 -0500

Yup, you've nailed the drawback to the self-determination approach. If 
it was simply a matter of trying every benchmark against every endpoint 
to find which ones are applicable, that's a cross product that quickly 
becomes untenable.

But you're talking about separating collection from evaluation, doing 
the actual evaluation using a data store.  And there's the thing:  in 
order for that to work, all of the attributes necessary to perform the 
security evaluation have to have already been collected.  And that list 
changes over time as policies change, new vulnerabilities are found, new 
software is installed, an endpoints role changes, etc.  The actual 
source of those attributes don't matter (SWID vice directly from the OS, 
for example), just that there is a path from what is needed to evaluate 
the policy to what needs to be collected.

The attributes for benchmark self-applicability testing are just 
attributes that should have already been collected.

However, unless you want to attempt to collect every known attribute 
required by every policy, there's a check-and-egg problem.  Knowing what 
attributes to collect depends on what policies apply to that endpoint.  
Knowing what policies apply means already having done attribute 
collection.  Just being able to broadly classify the endpoint 
(Unix/Linux/Windows/Cisco) makes this process feasible.

If SWIDs are available, it would make sense to take advantage of them 
for this purpose.  Benchmarks could take advantage of SWID values to do 
their self-determination, but that only works if the benchmark is 
authored with knowledge of how data is represented in a SWID.  Further, 
I would not rely on a set of SWIDs to be the complete representation of 
the software installed on an endpoint, nor that the data in the SWID is 
an accurate reflection of the current state of that software on that 
endpoint.

On 11/5/2015 2:20 PM, Jessica Fitzgerald-McKay wrote:
> The requirements document lists collection and evaluation as separate 
> SACM "tasks". This was done purposely, to enable the separation of 
> collection and evaluation of endpoint posture data, and to avoid some 
> of the implementation issues that come up when collection and 
> evaluation are performed simultaneously.
>
> The vulnerability assessment scenario provides a good demonstration of 
> why separating those tasks is important. It is unscalable to scan all 
> your endpoints for applicable software each time a new vulnerability 
> is announced. What makes a great deal more sense is to maintain a 
> database with records of the software installed on each endpoint, then 
> search that database for endpoints that reported running that 
> vulnerable software. You are right that this will require an 
> applicability language, and I fully support the idea of SACM 
> developing this as part of a vulnerability assessment solution!
>
> On Thu, Nov 5, 2015 at 2:02 PM, Gunnar Engelbach 
>     It's not just that the creation of the SWID tags (or any tagging
>     system) needs to be consistent, but that value used in the tag
>     needs to be one that is recognized at the point of usage.
>
>     For the purpose of system identification, this is not a problem
>     because the string is arbitrary -- it's just important that it be
>     consistent.  Which could still happen even with a single generated
>     SWID because other systems might not be using SWIDs.
>
>     For something like applicability testing, however, the actual
>     collected value is important and must match.  Which only works
>     when there is a single global known value.  And we're having this
>     discussion because that's not the case.
>
>     What has been shown to work very reliably, however, is for
>     assessment content to use the same collection and evaluation
>     system to specify the attributes and values necessary to
>     self-determine its own applicability.  A language like OVAL is
>     flexible enough to take advantage of a SWID if it is available or
>     otherwise use other attributes, but even then it would have to be
>     a SWID whose values were known to the content author.
>
>
>
>
>>     That depends on the tool they use the create the tag.
>>     Potentially, yes. We are looking at a decreasing set of products
>>     that do not drop a tag at the time of installation, so it's not a
>>     given that this will be a huge problem.
>>
>>     More interestingly, an enterprise can ensure that SWID creation
>>     within their network create the same tag for the same product
>>     across their network. Think about it in terms of the
>>     vulnerability assessment use case: when a vulnerability is
>>     announced for SoftwareXYZ, customers A and B do not need to know
>>     how the other creates a SWID tag for SoftwareXYZ. They need to
>>     know how their network creates a tag for SoftwareXYZ, and to be
>>     able to locate the endpoints that have that tag.
>>
>>     I hope that folks interested in this topic will take another look
>>     at the Endpoint Compliance Internet Draft:
>>     It describes how tags can be collected and stored as soon as they
>>     are installed on an endpoint. This enables asset management, as
>>     well as the vulnerability assessment use case.
>>
>>         product and customer ‘B’, who has no visibility back to
>>         customer A, creates a SWID tag for the same piece of software
>>         during installation will their SWID tags be the same?
>>
>>         Thanks,
>>
>>         Tim
>>
>>         Booz Allen Hamilton
>>
>>         Timothy Harrison
>>
>>         Lead Technologist
>>
>>         Mobile 717-372-5768
>>
>>         <http://www.boozallen.com>
>>
>>         *Cc:* Haynes, Dan <[email-masked]
>>         <mailto:[email-masked]>>; Adam Montville
>>         <[email-masked]
>>         <mailto:[email-masked]>>; Wolfkiel, Joseph
>>         *Subject:* [External] Re: [sacm] [Non-DoD Source] Re:
>>         Endpoint ID Design Team Notes: 2015-10-23
>>
>>
>>             different vendors might send different values for the
>>             same e.g  for OS you might get WinXp/Windows XP/Microsoft
>>             Windows XP etc...
>>
>>         ​The solution to this is to allow the software vendor to
>>         specify how their software will be identified. This is
>>         already happening with vendor adoption of SWID tags. The SWID
>>         tag can be created by the software vendor and included as a
>>         part of the software. Many vendors (including Microsoft) are
>>         doing this for licensing issues. If a vendor does not include
>>         a SWID tag with their software, an installer can create a tag
>>         at the time of installation, or freely-available open source
>>         software can create tags for products on enterprise endpoints
>>             This might seem a bit pedantic, but if you want to query
>>             how many windows XP machines are impacted by a specific
>>             security issue, you will not have a complete picture.
>>
>>         ​Not pedantic at all!​
>>
>>         ​ It's been a problem that has plagued our networks for far
>>         too long now, and must be tackled by this work group if we
>>         are going to solve our broader use cases.
>>         ​
>>
>>
>>             attribute X should look exactly as it does in the
>>             following config/registry/command output.
>>
>>             <mailto:[email-masked]>> on behalf of Wolfkiel,
>>             Joseph L CIV DISA ID (US) <[email-masked]
>>             specify, at some level, what attributes are expected to
>>             be collected, how to exchange them between tools, and
>>             some standard thing we think the tools will do with them
>>             to "match" identities. Right?  Or is there some other
>>             vision?  Can you explain how you would see this working
>>             if there's no common baseline matching algorithm?
>>
>>             I do agree that it seems reasonable to periodically
>>             update the attributes over time as we identify which
>>             attributes provide the highest confidence matches,
>>             followed by an update to the matching algorithm to
>>             authenticity of all links contained within the message
>>             prior to copying and pasting the address to a Web browser.
>>
>>
>>
>>
>>             ----
>>
>>
>>
>>             methodologies and tradeoffs would be great to capture –
>>             but I’m nervous about setting “into stone” per se the
>>             algorithm. Especially as I believe the right way forward
>>             will be to have an IANA registry for data model elements,
>>             and as we add more data elements, that might really
>>             change the landscape.
>>
>>
>>
>>             --
>>             Chris Inacio
>>             > On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV
>>             collecting a common set of data and being able to mediate
>>             it into a standardized format for comparison.
>>             >
>>             will have differing abilities to establish and track
>>             device identities over time.  Agent-based sensors can use
>>             the ID of their deployed agents, which (in my opinion)
>>             are pretty robust.  Over-the network active,
>>             authenticated scanners can try to retrieve some
>>             identification.  Passive or unauthenticated scanners will
>>             be limited to trying to identify devices based on
>>             information the device(s) use to identify themselves on
>>             the network, information that can be derived by observing
>>             traffic sent and received by a device, or information
>>             received from unauthenticated service calls or probes.
>>             >
>>             device discovered by one sensor is or isn't the same
>>             device discovered by another or that information about a
>>             device described by a sensor at a point in time can be
>>             retrieved at a later point in time based on some
>>             "identification" heuristic.
>>             >
>>             > The "identification" described above is a different
>>             issue than doing device "population" identification,
>>             which would consider how to describe and target policies
>>             or data collection efforts at groups of devices that
>>             > This email was sent from a non-Department of Defense
>>             email account, and contained active links. All links are
>>             disabled, and require you to copy and paste the address
>>             to a Web browser. Please verify the identity of the
>>             >       Defining an algorithm would help with consistency
>>             in correlation outcomes between implementers. However, it
>>             would need to be acknowledged that such an algorithm
>>             could not be expected to cover all scenarios, and that in
>>             some cases that consistency could just mean it was
>>             consistently incorrect.
>>             >
>>             algorithm and have it cover as much variance as possible
>>             -- the whole endpoint identification thing does not have
>>             much worth as a standard if results are
>>             inconsistent/unpredictable across implementers.  At the
>>             same time implementers are going to be much quicker to
>>             respond to errors and changing technologies than a
>>             available on request, but not required to always be
>>             used.  For example, when a consumer is making a request
>>             from a provider, that request should have the ability to
>>             around this was captured in Word comments in the
>>             document.  An updated version based on feedback and
>>             >               .      A question was asked about where
>>             we were at with the Architecture document. It was
>>             explained that we have made a lot of good progress
>>             recently during the two calls after the virtual interim
>>             meeting and that notes for those meetings were captured
>>             in the GitHub issue trackers that were discussed.  It was
>>             also noted that if anyone had feedback on the
>>             Architecture that they should send it out to the group
>>             >               .      There was also a question about
>>             the SACM Charter.  Specifically, in addition to
>>             specifying the different data fields associated with
>>             identifying endpoints, are their plans to standardize any
>>             business logic around them.  For example, an algorithm
>>             for matching devices using the data collected by two
>>             different sensors.  If the data collected by two sensors,
>>             using the algorithm, match then the data could be
>>             combined as it all represents the same endpoint.  It was
>>             noted that this is a real problem that they are facing in
>>             the field and that it might be good to have an industry
>>             standard around it. Another example, is around defining
>>             populations such as "these are all the devices owned by
>>             an organization", or "these are all the devices in a
>>             accurate can it be (state, city, building, closet,
>>             etc.).  A last example is making statements such as this
>>             applies to all servers running Windows 2012, containing
>>             sensitive info!
>>             > rmation,
>>             > and running these databases.  It was noted that there
>>             are no explicit plans to create matching algorithms, etc.
>>             as of yet, but, that you could seem the matching possibly
>>             being part of a query language for interfacing with a
>>             repository or the information about the location of an
>>             endpoint or the sensitivity of the data on an endpoint
>>             being covered under the manually assigned data associated
>>             with an endpoint.  This is something the broader group
>>             <
>>             <

---

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Thu, 5 Nov 2015 15:00:23 -0500

Oh, I completely agree that there will be times you need to do a scan for a
particular endpoint attribute. I'm just saying, an endpoint self report of
identity and software load will get you a long way for most use cases,
particularly the vulnerability assessment use case. Take a look at the
appendix C in this internet draft:
https://tools.ietf.org/html/draft-coffin-sacm-vuln-scenario-00.

You can get nearly all of the info communicated in most vulnerability
reports from a SWID tag endpoint self-report stored in a CMDB, and then
scan for attributes as needed. Definitely increases the scalability of a
SACM vulnerability management solution.

On Thu, Nov 5, 2015 at 2:52 PM, Gunnar Engelbach <
[email-masked]> wrote:

>
>
> Yup, you've nailed the drawback to the self-determination approach.  If it
> was simply a matter of trying every benchmark against every endpoint to
> find which ones are applicable, that's a cross product that quickly becomes
> untenable.
>
> But you're talking about separating collection from evaluation, doing the
> actual evaluation using a data store.  And there's the thing:  in order for
> that to work, all of the attributes necessary to perform the security
> evaluation have to have already been collected.  And that list changes over
> time as policies change, new vulnerabilities are found, new software is
> installed, an endpoints role changes, etc.  The actual source of those
> attributes don't matter (SWID vice directly from the OS, for example), just
> that there is a path from what is needed to evaluate the policy to what
> needs to be collected.
>
> If SWIDs are available, it would make sense to take advantage of them for
> this purpose.  Benchmarks could take advantage of SWID values to do their
> self-determination, but that only works if the benchmark is authored with
> knowledge of how data is represented in a SWID.  Further, I would not rely
> on a set of SWIDs to be the complete representation of the software
> installed on an endpoint, nor that the data in the SWID is an accurate
> reflection of the current state of that software on that endpoint.
>
>
>
>
>> That depends on the tool they use the create the tag. Potentially, yes.
>> We are looking at a decreasing set of products that do not drop a tag at
>> the time of installation, so it's not a given that this will be a huge
>> problem.
>>
>> <https://datatracker.ietf.org/doc/draft-fitzgeraldmckay-sacm-endpointcompliance/>
>>> <http://www.boozallen.com/> <http://www.boozallen.com>www.boozallen.com
>>>
>>>
>>>
>>> *Cc:* Haynes, Dan < <[email-masked]>[email-masked]>; Adam
>>> Montville < <[email-masked]>[email-masked]>;
>>> Gunnar Engelbach < <[email-masked]>
>>> [email-masked]>; Chris Inacio < <[email-masked]>
>>> [email-masked]>; [email-masked]
>>> ​ It's been a problem that has plagued our networks for far too long
>>> now, and must be tackled by this work group if we are going to solve our
>>> broader use cases.
>>> ​
>>>
>>>
>>> From: sacm < <[email-masked]>[email-masked]> on behalf of
>>> Wolfkiel, Joseph L CIV DISA ID (US) < <[email-masked]>
>>> <[email-masked]>[email-masked]
>>>
>>>
>>>
>>> <[email-masked]>[email-masked]
>>>
>>>
>>>
>>> > <[email-masked]>[email-masked]
>>> >
>>> >
>>> > Cc: <[email-masked]>[email-masked]
>>> > Cc: Haynes, Dan < <[email-masked]>[email-masked]>;
>>> <[email-masked]>[email-masked]
>>> > <[email-masked]>[email-masked]
>>> > Caution- <https://www.ietf.org/mailman/listinfo/sacm>
>>> <[email-masked]>[email-masked]
>>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 15:23:46 -0500

On 11/5/2015 2:31 PM, Jessica Fitzgerald-McKay wrote:
> conversations, and I know everyone wants to have it solved once and 
> for all.

It's not the lying endpoint issue.  It's that it's possible for an 
installed piece of software to be altered without that being reflected 
in the corresponding SWID.  Also, if you're going to draw 
security-related conclusions from a SWID in a data store, you want some 
level of assurance that the software and therefore associated SWID on 
the endpoint match what is in your data store.  Maybe collection time is 
enough for that.

> But, if your machine is already hosed, scanning may not catch it 
> uncomfortable position of not knowing what an accurate representation 
> of the current state of an endpoint looks like. SACM needs to focus on:
>
>   * making sure healthy machines stay healthy; and,
>   * getting an endpoint report that you can compare to network
>     observations to catch an attacked endpoint in a lie (to site a
>     common example around here, "hey, you told me you were a printer,
>     why did I just see you open Internet Explorer!")
>
> ​
>
>      * The values as expressed in the SWID must match the values
>     expected for making security state determinations.  That's much
>     less likely to be the case for third-party generated SWIDs, unless
>     each enterprise that generates SWIDs also does the work of writing
>     their own policy content to match them.
>
>
> forced to create them, which is getting more rare (sorry, I sound like 
> a broken record even to myself!)) are reflected in your policy. This 
> is more a matter of editing a policy (which almost all enterprises 
> will do anyway) than rewriting.
> ​
>
>      * Some networked devices are unlikely to ever have SWIDs. 
>     Routers, switches, SCADA, IoT, ...
>
>
> ​I'm with you on SCADA and maybe IoT (its a broad category, so I don't 
> want to ever go on record about what I think IoT will or will not 
> do!), but I wouldn't bet against routers and switches just yet. ​Even 
> if they never adopt SWIDs, it is trivial to take SNMP or netconf/yang 
> data and express the same SWID-tag-like information we would want to 
> gather from more traditional endpoints. I don't think their lack of 
> current adoption of the SWID tag standard should stop us from using it 
> where appropriate.
>
>
>
>     By all means, let's take advantage of SWIDs to the degree to which
>     they are available, but there are some problems related to SACM
>     for which they are not a solution.
>
>     To put it another way, I don't see SWIDs as a good solution for
>     the types of problems that are within the current scope of SACM,
>     but there are enough compelling reasons for organizations to use
>     them, to the point of using third-party SWID generators, that we
>     can expect to find them increasingly available and something to
>     take advantage of while not being dependent upon.
>
>
> ​Much as I sound like a SWID tag apologist, I am sure you are right. 
> There are definitely problems they cannot solve. Can you point to 
> examples from our use case document where we should be considering 
> other software identification schema?
> ​
>
>
>
>
>>     I disagree. I am going to joyously steal content from Dave
>>     Waltermire (hi, Dave!) since he recently addressed this topic in
>>     the MILE WG. SWIDS are good for:
>>
>>     - Providing authoritative, high-fidelity software data generated
>>     at build time by the software creator/publisher. CPEs are
>>     commonly generated by 3^rd parties in a labor intensive way by
>>     scraping vendor websites and vulnerability bulletins for software
>>     data that is often incomplete and inaccurate.
>>
>>
>>         SWID works great for cases where there is a definitive vendor
>>         tag, and as such needs to be taken care of.  But otherwise
>>         it's just the same problem wrapped in an XML schema.
>>
>>
>>>             same e.g  for OS you might get WinXp/Windows
>>>         ​ The solution to this is to allow the software vendor to
>>>         already happening with vendor adoption of SWID tags. The
>>>         SWID tag can be created by the software vendor and included
>>>         as a part of the software. Many vendors (including
>>>         Microsoft) are doing this for licensing issues. If a vendor
>>>         does not include a SWID tag with their software, an
>>>         freely-available open source software can create tags for
>>>             Please verify the identity of the sender, and confirm
>>>             the authenticity of all links contained within the
>>>             message prior to copying and pasting the address to a
>>>             Web browser.
>>>
>>>
>>>
>>>
>>>             ----
>>>
>>>
>>>
>>>             think an informational draft describing various
>>>             algorithm methodologies and tradeoffs would be great to
>>>             capture – but I’m nervous about setting “into stone” per
>>>             se the algorithm. Especially as I believe the right way
>>>             forward will be to have an IANA registry for data model
>>>             elements, and as we add more data elements, that might
>>>             collecting a common set of data and being able to
>>>             mediate it into a standardized format for comparison.
>>>             >
>>>             > We should also keep in mind that different SACM
>>>             sensors will have differing abilities to establish and
>>>             track device identities over time.  Agent-based sensors
>>>             can use the ID of their deployed agents, which (in my
>>>             opinion) are pretty robust.  Over-the network active,
>>>             persistent, unique device attributes that can be used
>>>             for identification.  Passive or unauthenticated scanners
>>>             will be limited to trying to identify devices based on
>>>             the network, information that can be derived by
>>>             observing traffic sent and received by a device, or
>>>             information received from unauthenticated service calls
>>>             or probes.
>>>             >
>>>             >       Defining an algorithm would help with
>>>             consistency in correlation outcomes between
>>>             implementers. However, it would need to be acknowledged
>>>             that such an algorithm could not be expected to cover
>>>             all scenarios, and that in some cases that consistency
>>>             could just mean it was consistently incorrect.
>>>             >
>>>             >       2) The ability to utilize the algorithm should
>>>             be available on request, but not required to always be
>>>             in the GitHub issue trackers that were discussed.  It
>>>             was also noted that if anyone had feedback on the
>>>             identifying endpoints, are their plans to standardize
>>>             any business logic around them.  For example, an
>>>             algorithm for matching devices using the data collected
>>>             by two different sensors.  If the data collected by two
>>>             sensors, using the algorithm, match then the data could
>>>             be combined as it all represents the same endpoint.  It
>>>             was noted that this is a real problem that they are
>>>             facing in the field and that it might be good to have an
>>>             defining populations such as "these are all the devices
>>>             owned by an organization", or "these are all the devices
>>>             in a single location".  There is also a question around
>>>             how accurate can it be (state, city, building, closet,
>>>             are no explicit plans to create matching algorithms,
>>>             etc. as of yet, but, that you could seem the matching
>>>             possibly being part of a query language for interfacing
>>>             with a repository or the information about the location
>>>             of an endpoint or the sensitivity of the data on an
>>>             endpoint being covered under the manually assigned data
>>>             associated with an endpoint.  This is something the
>>>             broader group may want to discuss further.
>>>             >
>>>             >
>>>             >
>>>             >  Action Items
>>>             >

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 5 Nov 2015 16:09:11 -0500

On 11/5/2015 3:00 PM, Jessica Fitzgerald-McKay wrote:
> Oh, I completely agree that there will be times you need to do a scan 
> for a particular endpoint attribute. I'm just saying, an endpoint self 
> report of identity and software load will get you a long way for most 
> use cases, particularly the vulnerability assessment use case. Take a 
> look at the appendix C in this internet draft: 
> reports from a SWID tag endpoint self-report stored in a CMDB, and 
> then scan for attributes as needed. Definitely increases the 
> scalability of a SACM vulnerability management solution.

You made a comment elsewhere that organizations do their own content 
customization.  Somewhere in this thread that I can't find now.  And 
that's a point I have to strongly disagree with -- expressing the 
evaluation content in a standard format is the most important thing to 
be standardized.  Otherwise we might as well go back to proprietary 
solutions, of which there are already a number out there.

I'm going to skip justifying that position, unless somebody really wants 
to hear it.

In order for automated security content to work properly (in this 
context) it needs two things:  to be able to unambiguously identify each 
attribute, and to be able to unambiguously interpret the value that is 
collected for that attribute.

This is relatively straightforward when the data source is the endpoint 
operating system.  Which is also the base scenario that must be 
supported because it's the one that is known to always be available.

To the degree that a SWID is available and known at the time that 
content is being authored, that could be used as an alternate data 
source accounted for by the author, but other ways of identifying 
attributes and how they represent data (generated SWIDs, OVAL/NEA/SNMP, 
etc) means having to re-implement the same content for each.  And that's 
a non-starter.

This is such a big problem that there really isn't a standard for CMDBs.

>
> On Thu, Nov 5, 2015 at 2:52 PM, Gunnar Engelbach 
>     Yup, you've nailed the drawback to the self-determination
>     approach.  If it was simply a matter of trying every benchmark
>     against every endpoint to find which ones are applicable, that's a
>     cross product that quickly becomes untenable.
>
>     But you're talking about separating collection from evaluation,
>     doing the actual evaluation using a data store.  And there's the
>     thing:  in order for that to work, all of the attributes necessary
>     to perform the security evaluation have to have already been
>     collected.  And that list changes over time as policies change,
>     new vulnerabilities are found, new software is installed, an
>     endpoints role changes, etc.  The actual source of those
>     attributes don't matter (SWID vice directly from the OS, for
>     example), just that there is a path from what is needed to
>     evaluate the policy to what needs to be collected.
>
>     However, unless you want to attempt to collect every known
>     attribute required by every policy, there's a check-and-egg
>     problem.  Knowing what attributes to collect depends on what
>     policies apply to that endpoint.  Knowing what policies apply
>     means already having done attribute collection.  Just being able
>     to broadly classify the endpoint (Unix/Linux/Windows/Cisco) makes
>     this process feasible.
>
>     If SWIDs are available, it would make sense to take advantage of
>     them for this purpose.  Benchmarks could take advantage of SWID
>     values to do their self-determination, but that only works if the
>     benchmark is authored with knowledge of how data is represented in
>     a SWID.  Further, I would not rely on a set of SWIDs to be the
>     complete representation of the software installed on an endpoint,
>     nor that the data in the SWID is an accurate reflection of the
>     current state of that software on that endpoint.
>
>
>
>
>>     The requirements document lists collection and evaluation as
>>     separate SACM "tasks". This was done purposely, to enable the
>>     separation of collection and evaluation of endpoint posture data,
>>     and to avoid some of the implementation issues that come up when
>>     collection and evaluation are performed simultaneously.
>>
>>     The vulnerability assessment scenario provides a good
>>     demonstration of why separating those tasks is important. It is
>>     unscalable to scan all your endpoints for applicable software
>>     each time a new vulnerability is announced. What makes a great
>>     deal more sense is to maintain a database with records of the
>>     software installed on each endpoint, then search that database
>>     for endpoints that reported running that vulnerable software. You
>>     are right that this will require an applicability language, and I
>>     fully support the idea of SACM developing this as part of a
>>     vulnerability assessment solution!
>>
>>         It's not just that the creation of the SWID tags (or any
>>         tagging system) needs to be consistent, but that value used
>>         in the tag needs to be one that is recognized at the point of
>>         usage.
>>
>>         For the purpose of system identification, this is not a
>>         problem because the string is arbitrary -- it's just
>>         important that it be consistent.  Which could still happen
>>         even with a single generated SWID because other systems might
>>         not be using SWIDs.
>>
>>         collected value is important and must match.  Which only
>>         works when there is a single global known value. And we're
>>         having this discussion because that's not the case.
>>
>>         self-determine its own applicability.  A language like OVAL
>>         is flexible enough to take advantage of a SWID if it is
>>         available or otherwise use other attributes, but even then it
>>         would have to be a SWID whose values were known to the
>>         content author.
>>
>>
>>
>>
>>>         Potentially, yes. We are looking at a decreasing set of
>>>         products that do not drop a tag at the time of installation,
>>>         so it's not a given that this will be a huge problem.
>>>
>>>         More interestingly, an enterprise can ensure that SWID
>>>         creation within their network create the same tag for the
>>>         same product across their network. Think about it in terms
>>>         of the vulnerability assessment use case: when a
>>>         vulnerability is announced for SoftwareXYZ, customers A and
>>>         B do not need to know how the other creates a SWID tag for
>>>         SoftwareXYZ. They need to know how their network creates a
>>>         tag for SoftwareXYZ, and to be able to locate the endpoints
>>>         that have that tag.
>>>
>>>         I hope that folks interested in this topic will take another
>>>         look at the Endpoint Compliance Internet Draft:
>>>         It describes how tags can be collected and stored as soon as
>>>         they are installed on an endpoint. This enables asset
>>>         management, as well as the vulnerability assessment use case.
>>>
>>>             If customer ‘A’ creates a SWID tag during installation
>>>             for a product and customer ‘B’, who has no visibility
>>>             back to customer A, creates a SWID tag for the same
>>>             piece of software during installation will their SWID
>>>             tags be the same?
>>>
>>>             Thanks,
>>>
>>>             Tim
>>>
>>>             Booz Allen Hamilton
>>>
>>>             Timothy Harrison
>>>
>>>             Lead Technologist
>>>
>>>             Mobile 717-372-5768
>>>
>>>             <mailto:[email-masked]>>; Wolfkiel,
>>>             <[email-masked] <mailto:[email-masked]>>;
>>>                 However even if a vendor sends their data in the
>>>                 correct model scam would require, there is also the
>>>                 issue that different vendors might send different
>>>                 values for the same e.g  for OS you might get
>>>             SWID tag can be created by the software vendor and
>>>             included as a part of the software. Many vendors
>>>             (including Microsoft) are doing this for licensing
>>>             issues. If a vendor does not include a SWID tag with
>>>             their software, an installer can create a tag at the
>>>             time of installation, or freely-available open source
>>>             software can create tags for products on enterprise
>>>             endpoints (an ideal solution for older endpoints).
>>>
>>>                 This might seem a bit pedantic, but if you want to
>>>                 query how many windows XP machines are impacted by a
>>>                 specific security issue, you will not have a
>>>                 complete picture.
>>>
>>>             ​Not pedantic at all!​
>>>
>>>             ​ It's been a problem that has plagued our networks for
>>>             far too long now, and must be tackled by this work group
>>>             if we are going to solve our broader use cases.
>>>             ​
>>>
>>>
>>>                 It would be too prescriptive to state the value of
>>>                 of attribute X should look exactly as it does in the
>>>                 <mailto:[email-masked]>> on behalf of
>>>                 Wolfkiel, Joseph L CIV DISA ID (US)
>>>                 Without an algorithm, how do you justify or
>>>                 prioritize collecting identification attributes? If
>>>                 you want multi-vendor interoperability, it seems
>>>                 like we have to specify, at some level, what
>>>                 attributes are expected to be collected, how to
>>>                 exchange them between tools, and some standard thing
>>>                 we think the tools will do with them to "match"
>>>                 identities. Right?  Or is there some other vision?
>>>                 Can you explain how you would see this working if
>>>                 there's no common baseline matching algorithm?
>>>
>>>                 All active links contained in this email were
>>>                 disabled. Please verify the identity of the sender,
>>>                 and confirm the authenticity of all links contained
>>>                 within the message prior to copying and pasting the
>>>                 address to a Web browser.
>>>
>>>
>>>
>>>
>>>                 ----
>>>
>>>
>>>
>>>                 I would be nervous about standardizing the
>>>                 algorithm.  I think an informational draft
>>>                 describing various algorithm methodologies and
>>>                 tradeoffs would be great to capture – but I’m
>>>                 nervous about setting “into stone” per se the
>>>                 algorithm. Especially as I believe the right way
>>>                 forward will be to have an IANA registry for data
>>>                 model elements, and as we add more data elements,
>>>                 that might really change the landscape.
>>>
>>>
>>>
>>>                 --
>>>                 Chris Inacio
>>>                 > On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L
>>>                 CIV DISA ID (US) <[email-masked]
>>>                 > Defining an algorithm will also inform the process
>>>                 of collecting a common set of data and being able to
>>>                 sensors will have differing abilities to establish
>>>                 and track device identities over time. Agent-based
>>>                 sensors can use the ID of their deployed agents,
>>>                 which (in my opinion) are pretty robust. Over-the
>>>                 network active, authenticated scanners can try to
>>>                 retrieve some persistent, unique device attributes
>>>                 unauthenticated scanners will be limited to trying
>>>                 to identify devices based on information the
>>>                 device(s) use to identify themselves on the network,
>>>                 information that can be derived by observing traffic
>>>                 sent and received by a device, or information
>>>                 > It's my assumption that the point of doing
>>>                 endpoint identification is to be able to
>>>                 differentiate whether a device discovered by one
>>>                 sensor is or isn't the same device discovered by
>>>                 another or that information about a device described
>>>                 by a sensor at a point in time can be retrieved at a
>>>                 > The "identification" described above is a
>>>                 different issue than doing device "population"
>>>                 identification, which would consider how to describe
>>>                 and target policies or data collection efforts at
>>>                 > This email was sent from a non-Department of
>>>                 Defense email account, and contained active links.
>>>                 All links are disabled, and require you to copy and
>>>                 paste the address to a Web browser. Please verify
>>>                 the identity of the sender, and confirm authenticity
>>>                 of all links contained within the message.
>>>                 >
>>>                 >
>>>                 >       On Oct 23, 2015, at 1:22 PM, Gunnar
>>>                 Engelbach <[email-masked]
>>>                 in correlation outcomes between implementers.
>>>                 However, it would need to be acknowledged that such
>>>                 an algorithm could not be expected to cover all
>>>                 scenarios, and that in some cases that consistency
>>>                 >       As part of a standard, I'd like to see such
>>>                 an algorithm and have it cover as much variance as
>>>                 possible -- the whole endpoint identification thing
>>>                 does not have much worth as a standard if results
>>>                 are inconsistent/unpredictable across implementers.
>>>                 At the same time implementers are going to be much
>>>                 quicker to respond to errors and changing
>>>                 >       1) The algorithm should not attempt to cover
>>>                 all variations, just as many as we have a high
>>>                 confidence in being able to define
>>>                 >       2) The ability to utilize the algorithm
>>>                 should be available on request, but not required to
>>>                 always be used.  For example, when a consumer is
>>>                 making a request from a provider, that request
>>>                 should have the ability to specify that correlation
>>>                 must be done using the standard algorithm.
>>>                 >
>>>                 >
>>>                 >
>>>                 discussed. All the discussion and feedback around
>>>                 this was captured in Word comments in the document.
>>>                 An updated version based on feedback and discussion,
>>>                 will be sent out prior to the next EID-DT meeting.
>>>                 >
>>>                 >
>>>                 >
>>>                 at with the Architecture document.  It was explained
>>>                 that we have made a lot of good progress recently
>>>                 during the two calls after the virtual interim
>>>                 meeting and that notes for those meetings were
>>>                 captured in the GitHub issue trackers that were
>>>                 discussed.  It was also noted that if anyone had
>>>                 feedback on the Architecture that they should send
>>>                 it out to the group sooner rather than later.
>>>                 >
>>>                 >
>>>                 >
>>>                 Charter. Specifically, in addition to specifying the
>>>                 different data fields associated with identifying
>>>                 endpoints, are their plans to standardize any
>>>                 business logic around them.  For example, an
>>>                 algorithm for matching devices using the data
>>>                 collected by two different sensors.  If the data
>>>                 collected by two sensors, using the algorithm, match
>>>                 then the data could be combined as it all represents
>>>                 the same endpoint.  It was noted that this is a real
>>>                 problem that they are facing in the field and that
>>>                 it might be good to have an industry standard around
>>>                 it. Another example, is around defining populations
>>>                 such as "these are all the devices owned by an
>>>                 organization", or "these are all the devices in a
>>>                 single location". There is also a question around
>>>                 how accurate can it be (state, city, building,
>>>                 closet, etc.).  A last example is making statements
>>>                 such as this applies to all servers running Windows
>>>                 2012, containing sensitive info!
>>>                 > rmation,
>>>                 > and running these databases.  It was noted that
>>>                 there are no explicit plans to create matching
>>>                 algorithms, etc. as of yet, but, that you could seem
>>>                 the matching possibly being part of a query language
>>>                 for interfacing with a repository or the information
>>>                 about the location of an endpoint or the sensitivity
>>>                 of the data on an endpoint being covered under the
>>>                 manually assigned data associated with an endpoint.
>>>                 This is something the broader group may want to
>>>                 discuss further.
>>>                 >
>>>                 >
>>>                 >
>>>                 >      Action Items
>>>                 >

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Thu, 5 Nov 2015 21:15:40 +0000

If possible, I would like to treat device identification and software identification as two separate issues.  I've kind of given up on doing meaningful software identification and just allowed our users to use wildcard matching and complex queries to allow them to manually identify all the software names that mean the same thing.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Thursday, November 05, 2015 4:09 PM
To: Jessica Fitzgerald-McKay
Cc: Haynes, Dan; Adam Montville; Sherif Mansour Farag; Wolfkiel, Joseph L CIV DISA ID (US); Chris Inacio; Harrison, Timothy [USA]; [email-masked]
Subject: Re: [sacm] [External] Re: [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

Oh, I completely agree that there will be times you need to do a scan for a particular endpoint attribute. I'm just saying, an endpoint self report of identity and software load will get you a long way for most use cases, particularly the vulnerability assessment use case. Take a look at the appendix C in this internet draft: Caution-https://tools.ietf.org/html/draft-coffin-sacm-vuln-scenario-00 < Caution-https://tools.ietf.org/html/draft-coffin-sacm-vuln-scenario-00 > .

You can get nearly all of the info communicated in most vulnerability reports from a SWID tag endpoint self-report stored in a CMDB, and then scan for attributes as needed. Definitely increases the scalability of a SACM vulnerability management solution.

You made a comment elsewhere that organizations do their own content customization.  Somewhere in this thread that I can't find now.  And that's a point I have to strongly disagree with -- expressing the evaluation content in a standard format is the most important thing to be standardized.  Otherwise we might as well go back to proprietary solutions, of which there are already a number out there.

I'm going to skip justifying that position, unless somebody really wants to hear it.

In order for automated security content to work properly (in this context) it needs two things:  to be able to unambiguously identify each attribute, and to be able to unambiguously interpret the value that is collected for that attribute.

This is relatively straightforward when the data source is the endpoint operating system.  Which is also the base scenario that must be supported because it's the one that is known to always be available.

To the degree that a SWID is available and known at the time that content is being authored, that could be used as an alternate data source accounted for by the author, but other ways of identifying attributes and how they represent data (generated SWIDs, OVAL/NEA/SNMP, etc) means having to re-implement the same content for each.  And that's a non-starter.

On Thu, Nov 5, 2015 at 2:52 PM, Gunnar Engelbach <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	Yup, you've nailed the drawback to the self-determination approach.  If it was simply a matter of trying every benchmark against every endpoint to find which ones are applicable, that's a cross product that quickly becomes untenable.
	
	But you're talking about separating collection from evaluation, doing the actual evaluation using a data store.  And there's the thing:  in order for that to work, all of the attributes necessary to perform the security evaluation have to have already been collected.  And that list changes over time as policies change, new vulnerabilities are found, new software is installed, an endpoints role changes, etc.  The actual source of those attributes don't matter (SWID vice directly from the OS, for example), just that there is a path from what is needed to evaluate the policy to what needs to be collected.
	
	The attributes for benchmark self-applicability testing are just attributes that should have already been collected.
	
	However, unless you want to attempt to collect every known attribute required by every policy, there's a check-and-egg problem.  Knowing what attributes to collect depends on what policies apply to that endpoint.  Knowing what policies apply means already having done attribute collection.  Just being able to broadly classify the endpoint (Unix/Linux/Windows/Cisco) makes this process feasible.
	
	If SWIDs are available, it would make sense to take advantage of them for this purpose.  Benchmarks could take advantage of SWID values to do their self-determination, but that only works if the benchmark is authored with knowledge of how data is represented in a SWID.  Further, I would not rely on a set of SWIDs to be the complete representation of the software installed on an endpoint, nor that the data in the SWID is an accurate reflection of the current state of that software on that endpoint. 

		The requirements document lists collection and evaluation as separate SACM "tasks". This was done purposely, to enable the separation of collection and evaluation of endpoint posture data, and to avoid some of the implementation issues that come up when collection and evaluation are performed simultaneously.
		
		The vulnerability assessment scenario provides a good demonstration of why separating those tasks is important. It is unscalable to scan all your endpoints for applicable software each time a new vulnerability is announced. What makes a great deal more sense is to maintain a database with records of the software installed on each endpoint, then search that database for endpoints that reported running that vulnerable software. You are right that this will require an applicability language, and I fully support the idea of SACM developing this as part of a vulnerability assessment solution!

		On Thu, Nov 5, 2015 at 2:02 PM, Gunnar Engelbach <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> > wrote:

			

				I hope that folks interested in this topic will take another look at the Endpoint Compliance Internet Draft: Caution-https://datatracker.ietf.org/doc/draft-fitzgeraldmckay-sacm-endpointcompliance/. It describes how tags can be collected and stored as soon as they are installed on an endpoint. This enables asset management, as well as the vulnerability assessment use case.

				On Thu, Nov 5, 2015 at 1:20 PM, Harrison, Timothy [USA] <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> > wrote:

					Hi Jessica,

					Thanks,

					Tim

					Timothy Harrison

					Lead Technologist

					Mobile 717-372-5768

					 < Caution-http://www.boozallen.com/ > Caution-www.boozallen.com < Caution-http://www.boozallen.com >  <Caution-http://www.boozallen.com> 

					From: sacm [Caution-mailto:[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> ] On Behalf Of Jessica Fitzgerald-McKay
					Sent: Thursday, November 05, 2015 1:12 PM
					To: Sherif Mansour Farag <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >
					Cc: Haynes, Dan <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >; Adam Montville <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >; Gunnar Engelbach <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >; Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >; Chris Inacio <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >; [email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 
					Subject: [External] Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

					​Not pedantic at all!​

					​ It's been a problem that has plagued our networks for far too long now, and must be tackled by this work group if we are going to solve our broader use cases.
					​

						
						Sherif Mansour
						Enterprise Information Security
						Sr Security Engineer | EIS – Secure Design & Consulting
						T + 44 (0) 203 194 5245 |  M + 44 (0) 7860 782936
						Expedia.com Ltd – 407 St John St, London EC1V4EX
						____________________________________
						From: sacm <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> > on behalf of Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >
						Sent: Thursday, November 05, 2015 1:23 PM
						To: Chris Inacio
						Cc: Gunnar Engelbach; Haynes, Dan; Adam Montville; [email-masked] < Caution-mailto:[email-masked] > 
						Subject: Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

						
						Joseph L. Wolfkiel
						SCM Engineering Lead
						DISA ID52
						Fort Meade DISA Acquisiton Bldg Cube A4A58E
						Work: (301) 225-8820
						Gov Cell: (571) 814-8231
						[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 

						-----Original Message-----
						From: Chris Inacio [Caution-mailto:[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> ]
						Sent: Wednesday, November 04, 2015 6:55 PM
						To: Wolfkiel, Joseph L CIV DISA ID (US)
						Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; [email-masked] < Caution-mailto:[email-masked] > 
						Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

						
						
						----

						
						--
						Chris Inacio
						[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 

						> On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> > wrote:
						>
						> The "identification" described above is a different issue than doing device "population" identification, which would consider how to describe and target policies or data collection efforts at groups of devices that share some common set ofcharacteristics.
						>
						> Joseph L. Wolfkiel
						> SCM Engineering Lead
						> DISA ID52
						> [email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 
						>
						>
						> From: sacm [Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
						> Cc: [email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 
						> From: Adam Montville[Caution-Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked] > ]
						> To: Gunnar Engelbach <[email-masked] < Caution-mailto:[email-masked] > >
						> Cc: Haynes, Dan <[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >; [email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 
						>       On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <[email-masked] < Caution-mailto:[email-masked] >  < Caution-Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked] >  > > wrote:
						>
						>
						>
						>
						>               [email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]>  < Caution-Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked] >  >
						>               Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  <Caution-https://www.ietf.org/mailman/listinfo/sacm>  < Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  <Caution-https://www.ietf.org/mailman/listinfo/sacm>  >
						>
						>
						>       [email-masked] < Caution-mailto:[email-masked] >  < Caution-Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked] >  >
						>       Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  <Caution-https://www.ietf.org/mailman/listinfo/sacm>  < Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  <Caution-https://www.ietf.org/mailman/listinfo/sacm>  >
						>
						>
						>
						> [email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 
						> Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  <Caution-https://www.ietf.org/mailman/listinfo/sacm> 
						_______________________________________________
						sacm mailing list
						[email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> 

						Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >  <Caution-https://www.ietf.org/mailman/listinfo/sacm>

---

From: "Landfield, Kent B" <[email-masked]>
Date: Thu, 5 Nov 2015 18:55:39 +0000

Why did CPE have issues?

  *   It was supposed to initially be done by software creators/publishers, or at least that was the hope.  It did not happen and we had to resort to third parties to do it and add it to the dictionary.
  *   We needed to have a reasonably current version of the dictionary to make CPE most effective. Not always convenient or possible due to operational considerations or architectural layout of environment.
  *   Limits on fields as listed below. Inflexible in many respects.
  *   Complicated matching/searching mechanisms
  *   Auto generated names almost never worked properly

Why will SWID struggle?

  *   Needs to have wide spread adoption before it is an effective means
  *   Adoption is happening with a few of the larger software creators/publishers but not yet mainstream
  *   Until there is a large adoption rate the means to identify installed software will continue to be an archeological discovery process that will be inconsistent and inaccurate (except when SWIDs are present).
  *   Some perceived limitations on installed hardware identification

Defensive coding to identify systems is going to take algorithms that examine multiple means to identify an endpoint to have any hope of being somewhat accurate for the foreseeable future.

SWID is better that CPEs but … Reality is there is no one way at the present time.  Adoption is critical for SWID to be effective.  It is easy to generate SWID tags during the build process and hard to get the message out globally to all of its value. We need to make sure what we develop here improves the situation, not make it more complicated.

From: sacm <[email-masked]<mailto:[email-masked]>> on behalf of Jessica Fitzgerald-McKay <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 5, 2015 at 12:34 PM
To: Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>
Cc: Dan Haynes <[email-masked]<mailto:[email-masked]>>, Adam Montville <[email-masked]<mailto:[email-masked]>>, Sherif Mansour Farag <[email-masked]<mailto:[email-masked]>>, "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]<mailto:[email-masked]>>, Chris Inacio <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

I disagree. I am going to joyously steal content from Dave Waltermire (hi, Dave!) since he recently addressed this topic in the MILE WG. SWIDS are good for:

- Providing authoritative, high-fidelity software data generated at build time by the software creator/publisher. CPEs are commonly generated by 3rd parties in a labor intensive way by scraping vendor websites and vulnerability bulletins for software data that is often incomplete and inaccurate.

- Providing more robust software metadata that goes beyond the 11 fields supported by CPE including tags/identification for patches which CPE doesn't support.

- Normalizing the data representation for installed software on endpoints regardless of platform/software specific technologies.

- Providing software footprint details including composite files, versions, and hashes. This is not something that CPE supports.

Simply put, SWIDs provide greater support for the management of software across the deployment lifecycle than CPE allows for.

On Thu, Nov 5, 2015 at 1:29 PM, Gunnar Engelbach <[email-masked]<mailto:[email-masked]>> wrote:

SWID works great for cases where there is a definitive vendor tag, and as such needs to be taken care of.  But otherwise it's just the same problem wrapped in an XML schema.

​Not pedantic at all!​

Sherif Mansour
Enterprise Information Security
Sr Security Engineer | EIS – Secure Design & Consulting
T + 44 (0) 203 194 5245 |  M + 44 (0) 7860 782936
Expedia.com Ltd – 407 St John St, London EC1V4EX
____________________________________
From: sacm <[email-masked]<mailto:[email-masked]>> on behalf of Wolfkiel, Joseph L CIV DISA ID (US) <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 05, 2015 1:23 PM
To: Chris Inacio
Cc: Gunnar Engelbach; Haynes, Dan; Adam Montville; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Fort Meade DISA Acquisiton Bldg Cube A4A58E
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: Chris Inacio [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 04, 2015 6:55 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Haynes, Dan; Adam Montville; Gunnar Engelbach; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: [Non-DoD Source] Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23

----

--
Chris Inacio
[email-masked]<mailto:[email-masked]>

> On Nov 2, 2015, at 10:10 PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>
>
>
> From: sacm [Caution-mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>] On Behalf Of Haynes, Dan
> Cc: [email-masked]<mailto:[email-masked]>
> From: Adam Montville [Caution-Caution-mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]
> To: Gunnar Engelbach <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
> Cc: Haynes, Dan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>       On Oct 23, 2015, at 1:22 PM, Gunnar Engelbach <[email-masked]<mailto:[email-masked]> < Caution-Caution-mailto:[email-masked]<mailto:[email-masked]> > > wrote:
>
>
>
>
>               [email-masked]<mailto:[email-masked]> < Caution-Caution-mailto:[email-masked]<mailto:[email-masked]> >
>               Caution-Caution-<https://www.ietf.org/mailman/listinfo/sacm>https://www.ietf.org/mailman/listinfo/sacm < Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm >
>
>
>       [email-masked]<mailto:[email-masked]> < Caution-Caution-mailto:[email-masked]<mailto:[email-masked]> >

---

From: Sherif Mansour Farag <[email-masked]>
Date: Fri, 6 Nov 2015 00:12:04 +0000

I would like to treat device identification and software identification as two separate issues as well.

There are a few things I would like SCAM to answer for an enterprise:

What are the vulnerabilities in each endpoint components (OS/VMs/Containers/Services/Apps)?
What are the insecure misconfigurations on each end point components?
What are there indicators of a security incident on end point components?
What are the missing security defences on each end point?

The data model would need to take into account the fast pace of technology, as the different types of end points and layers in the technology continue to grow. 
However the attack vectors are finite so we can at least assume limited change in that scope.

There are a limited set of attack vectors (Network/Client Side/Local/Wireless/Physical). Ideally I would like to categorise issues by threat so I can also query by it.
Some of this information is collected in batches and so can be pulled, however when it comes to more real time events like security monitoring where alerts need to go out it feels like this data should be either pushed to the collector or the collector would need to continuously poll for updates (which isn't always efficient).

Additionally, the architecture needs to be designed for ease of integration with existing and new security solutions. I.e. it should be easy to write a feature for a scam collector to pull data.
Example, one of the reason for the success of NOSQL (aggregate/document based data stores) compared to OO data stores, is the addition of web-services between web apps and data stores. 
This allowed for the switch of datastore technologies with out the need to change anything on the web application layer (the web-services took care of that).  
________________________________________
From: Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]>
Sent: Thursday, November 05, 2015 9:15 PM
To: Gunnar Engelbach; Jessica Fitzgerald-McKay
Cc: Haynes, Dan; Adam Montville; Sherif Mansour Farag; Chris Inacio; Harrison, Timothy [USA]; [email-masked]
Subject: RE: [sacm] [External] Re: [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Thursday, November 05, 2015 4:09 PM
To: Jessica Fitzgerald-McKay
Cc: Haynes, Dan; Adam Montville; Sherif Mansour Farag; Wolfkiel, Joseph L CIV DISA ID (US); Chris Inacio; Harrison, Timothy [USA]; [email-masked]
Subject: Re: [sacm] [External] Re: [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

                                        Hi Jessica,

                                        Thanks,

                                        Tim

                                        Timothy Harrison

                                        Lead Technologist

                                        Mobile 717-372-5768

                                        ​Not pedantic at all!​

                                                Sherif Mansour

                                                Joseph L. Wolfkiel
                                                SCM Engineering Lead
                                                DISA ID52

                                                -----Original Message-----

                                                ----

---

From: Sherif Mansour Farag <[email-masked]>
Date: Fri, 6 Nov 2015 00:22:30 +0000

There are a few things I would like SACM to answer for an enterprise:

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Thursday, November 05, 2015 4:09 PM
To: Jessica Fitzgerald-McKay
Cc: Haynes, Dan; Adam Montville; Sherif Mansour Farag; Wolfkiel, Joseph L CIV DISA ID (US); Chris Inacio; Harrison, Timothy [USA]; [email-masked]
Subject: Re: [sacm] [External] Re: [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

                                        Hi Jessica,

                                        Thanks,

                                        Tim

                                        Timothy Harrison

                                        Lead Technologist

                                        Mobile 717-372-5768

                                        ​Not pedantic at all!​

                                                Sherif Mansour

                                                Joseph L. Wolfkiel
                                                SCM Engineering Lead
                                                DISA ID52

                                                -----Original Message-----

                                                ----

---

From: Chris Inacio <[email-masked]>
Date: Fri, 6 Nov 2015 09:22:29 +0000

I relatively new to SWID tags, but I poked a little.  But I have a question - how to SWID tags encapsulate configuration/build options, especially on open source software?  I didn’t check on the VM I installed a Linux SWID tag generator.  How would one use a SWID tag to know if a package is built and installed using openSSL vs. libsodium if those are configuration / build options?  (Hopefully it captures dependencies somehow - I know they can get pretty big.)

--
Chris Inacio
[email-masked]

> On Nov 6, 2015, at 3:34 AM, Jessica Fitzgerald-McKay <[email-masked]> wrote:
> 
> On Thu, Nov 5, 2015 at 1:29 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
>> ​Not pedantic at all!​   ​It's been a problem that has plagued our networks for far too long now, and must be tackled by this work group if we are going to solve our broader use cases.
>> ​
>>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 6 Nov 2015 13:29:19 +0000

Ultimately, we'll also want to know what mitigating controls are in place on a device or system.  For example, is AV installed, configured with the latest signatures and/or cloud lookup and enabled to scan (both on access and periodically) all files and directories?  Is a host firewall installed, enabled, and enforcing a known security policy?  Host IPS?  Data Loss Prevention Capability?  Application Whitelisting Capability? Etc.

Having said all that, we can only "know" that information if we have a unique, persistent identifier for devices to track the information against.  We will also need identifiers for templates in VDI environments to account for ephemeral VMs.

It's probably also necessary to acknowledge that the overlap between the two is when we track specific instances of installed software, in which case we need to have both a good device ID and a good software ID.  Since pretty much all the SACM use cases deal with identifying vulnerabilities and describing configurations on software instances, we ultimately have to bring the two together.  Assuming we follow common practice, I would expect the convergence to be tracked using software GUIDs.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: Sherif Mansour Farag [mailto:[email-masked]] 
Sent: Thursday, November 05, 2015 7:23 PM
To: Wolfkiel, Joseph L CIV DISA ID (US); Gunnar Engelbach; Jessica Fitzgerald-McKay
Cc: Haynes, Dan; Adam Montville; Chris Inacio; Harrison, Timothy [USA]; [email-masked]
Subject: Re: [sacm] [External] Re: [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Thursday, November 05, 2015 4:09 PM
To: Jessica Fitzgerald-McKay
Cc: Haynes, Dan; Adam Montville; Sherif Mansour Farag; Wolfkiel, Joseph L CIV DISA ID (US); Chris Inacio; Harrison, Timothy [USA]; [email-masked]
Subject: Re: [sacm] [External] Re: [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23

                                        Hi Jessica,

                                        Thanks,

                                        Tim

                                        Timothy Harrison

                                        Lead Technologist

                                        Mobile 717-372-5768

                                        ​Not pedantic at all!​

                                                Sherif Mansour

                                                Joseph L. Wolfkiel
                                                SCM Engineering Lead
                                                DISA ID52

                                                -----Original Message-----

                                                ----

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 10 Nov 2015 13:42:22 -0500

> evaluation are performed simultaneously.

Going even further off topic, but this is a point worth bringing up.

Separate collection from evaluation means knowing *what* to collect for 
each endpoint.  Take the very simple case of collecting the file version 
for advapi32.dll

Normally this file is located at C:\Windows\System32\advapi32.dll, however

1)  For any particular windows endpoint, the current running version of 
Windows might not be installed to the C drive.
2)  For any particular windows endpoint, the current running version of 
Windows might not be installed under the "Windows" directory
3)  Using this explicit path nets you the 32-bit version of the file on 
32-bit Windows OSs, but nets you the 64-bit version of the file on 
64-bit systems.

For this simple case, the first two can be addressed by changing the 
path reference to "%WINDIR%\system32\advapi32.dll", which creates the 
new requirement that collectors be able to resolve environment 
variables, but it doesn't address #3.

One of the lessons learned over the years in the OVAL/SCAP communities 
is that simple solutions like this are insufficient to cover all the 
needs.  Instead, OVAL has had to allow for logical expressions, string 
manipulation, reference to other collected artifacts, data type 
conversions, etc, in order to create the ability to collect the correct 
attribute from each endpoint.

In the conversations about the Information/Data models, I don't see 
allowance for this.

A couple possible ways to address it:

A) Custom content for each endpoint variation.
B) Collection becomes a conversation, not a single collection
C) Collection is done via a language which is executed at the point of 
collection

(A) I will strike right off as non-viable.
(B) Actually requires that the automated guidance be expressed in a 
directed language ala (C), so the difference between (B) and (C) is 
whether that language is executed at the point of collection or at a 
more centralized point.

---

From: Jerome Athias <[email-masked]>
Date: Fri, 13 Nov 2015 12:00:39 +0300

Yes and no...

SWID is not there* and will probably nether be. *not widely used and you
just can't enforce is use especially in the open source world and for
inhouse custom code/software/applications
(IMHO, just forget about SWID, we can't even wait decades for it)

CPE is ok, but not perfect
But, can only be used with some level of confidence with use of algorithms.
OWASP dependency-check is a good example

Identifiers, for devices can't, imho, be unique and definitive.
Hashing+versioning (a la CPE) could be investigated further
But, can only be used with some level of confidence with use of algorithms.

OVAL could do, IF based on a good model.
And I would suggest an adaptative model, that could be used now, and
perfected over time.

E.g.: SWID don't cover 'components' nor 'components of components' (I.e.
Libraries used to build a binary)
For devices, I would assume that you would care about each components of a
device (I.e.: each chip in the hardware of the components of the devices of
your machines that you have in a satellite)

My 2c

On Friday, 6 November 2015, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> wrote:

> If possible, I would like to treat device identification and software
> identification as two separate issues.  I've kind of given up on doing
> meaningful software identification and just allowed our users to use
> wildcard matching and complex queries to allow them to manually identify
> all the software names that mean the same thing.
>
> Joseph L. Wolfkiel
> SCM Engineering Lead
> DISA ID52
> [email-masked] <javascript:;>
>
>
>
> From: sacm [mailto:[email-masked] <javascript:;>] On Behalf Of
> Gunnar Engelbach
> Cc: Haynes, Dan; Adam Montville; Sherif Mansour Farag; Wolfkiel, Joseph L
> CIV DISA ID (US); Chris Inacio; Harrison, Timothy [USA]; [email-masked]
> <javascript:;>
> Oh, I completely agree that there will be times you need to do a scan for
> a particular endpoint attribute. I'm just saying, an endpoint self report
> of identity and software load will get you a long way for most use cases,
> appendix C in this internet draft: Caution-
> https://tools.ietf.org/html/draft-coffin-sacm-vuln-scenario-00 < Caution-
> https://tools.ietf.org/html/draft-coffin-sacm-vuln-scenario-00 > .
>
> customization.  Somewhere in this thread that I can't find now.  And that's
> a point I have to strongly disagree with -- expressing the evaluation
> content in a standard format is the most important thing to be
> standardized.  Otherwise we might as well go back to proprietary solutions,
> of which there are already a number out there.
>
> In order for automated security content to work properly (in this context)
> it needs two things:  to be able to unambiguously identify each attribute,
> and to be able to unambiguously interpret the value that is collected for
> that attribute.
>
> operating system.  Which is also the base scenario that must be supported
> because it's the one that is known to always be available.
>
> To the degree that a SWID is available and known at the time that content
> is being authored, that could be used as an alternate data source accounted
> for by the author, but other ways of identifying attributes and how they
> represent data (generated SWIDs, OVAL/NEA/SNMP, etc) means having to
> re-implement the same content for each.  And that's a non-starter.
>
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> > > wrote:
>
>
>
>
> approach.  If it was simply a matter of trying every benchmark against
> every endpoint to find which ones are applicable, that's a cross product
> that quickly becomes untenable.
>
> doing the actual evaluation using a data store.  And there's the thing:  in
> software is installed, an endpoints role changes, etc.  The actual source
> of those attributes don't matter (SWID vice directly from the OS, for
> example), just that there is a path from what is needed to evaluate the
> policy to what needs to be collected.
>
> attribute required by every policy, there's a check-and-egg problem.
> Knowing what attributes to collect depends on what policies apply to that
> endpoint.  Knowing what policies apply means already having done attribute
> them for this purpose.  Benchmarks could take advantage of SWID values to
> do their self-determination, but that only works if the benchmark is
> authored with knowledge of how data is represented in a SWID.  Further, I
> would not rely on a set of SWIDs to be the complete representation of the
> software installed on an endpoint, nor that the data in the SWID is an
> accurate reflection of the current state of that software on that endpoint.
>
>
>
>
>                 The requirements document lists collection and evaluation
> as separate SACM "tasks". This was done purposely, to enable the separation
> of collection and evaluation of endpoint posture data, and to avoid some of
> the implementation issues that come up when collection and evaluation are
> demonstration of why separating those tasks is important. It is unscalable
> to scan all your endpoints for applicable software each time a new
> vulnerability is announced. What makes a great deal more sense is to
> maintain a database with records of the software installed on each
> endpoint, then search that database for endpoints that reported running
> that vulnerable software. You are right that this will require an
> applicability language, and I fully support the idea of SACM developing
> this as part of a vulnerability assessment solution!
>
>
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>> > wrote:
>
>
>
>                         It's not just that the creation of the SWID tags
> (or any tagging system) needs to be consistent, but that value used in the
> tag needs to be one that is recognized at the point of usage.
>
>                         For the purpose of system identification, this is
> not a problem because the string is arbitrary -- it's just important that
> it be consistent.  Which could still happen even with a single generated
>                         For something like applicability testing, however,
> the actual collected value is important and must match.  Which only works
>                         What has been shown to work very reliably,
> however, is for assessment content to use the same collection and
> evaluation system to specify the attributes and values necessary to
> self-determine its own applicability.  A language like OVAL is flexible
> enough to take advantage of a SWID if it is available or otherwise use
> other attributes, but even then it would have to be a SWID whose values
> were known to the content author.
>
>
>
>
>                                 That depends on the tool they use the
> create the tag. Potentially, yes. We are looking at a decreasing set of
> products that do not drop a tag at the time of installation, so it's not a
>                                 More interestingly, an enterprise can
> ensure that SWID creation within their network create the same tag for the
> same product across their network. Think about it in terms of the
> vulnerability assessment use case: when a vulnerability is announced for
> SoftwareXYZ, customers A and B do not need to know how the other creates a
> SWID tag for SoftwareXYZ. They need to know how their network creates a tag
> for SoftwareXYZ, and to be able to locate the endpoints that have that tag.
>
>
>                                 I hope that folks interested in this topic
> will take another look at the Endpoint Compliance Internet Draft: Caution-
>                                 On Thu, Nov 5, 2015 at 1:20 PM, Harrison,
> Timothy [USA] <[email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>> > wrote:
>
>
>                                         Hi Jessica,
>
>
>
>                                         If customer ‘A’ creates a SWID tag
> during installation for a product and customer ‘B’, who has no visibility
> back to customer A, creates a SWID tag for the same piece of software
>                                          < Caution-
> http://www.boozallen.com/ > Caution-www.boozallen.com < Caution-
> http://www.boozallen.com >  <Caution-http://www.boozallen.com>
>
>
>
>                                         From: sacm [Caution-mailto:
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>> ] On Behalf Of Jessica
> Fitzgerald-McKay
>                                         To: Sherif Mansour Farag <
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>> >
> <javascript:;> < Caution-mailto:[email-masked] <javascript:;> >
> <Caution-mailto:[email-masked] <javascript:;>> >; Adam Montville <
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>> >; Gunnar Engelbach <
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>> >; Wolfkiel, Joseph L
> CIV DISA ID (US) <[email-masked] <javascript:;> <
> Caution-mailto:[email-masked] <javascript:;> >
> <Caution-mailto:[email-masked] <javascript:;>> >; Chris
> Inacio <[email-masked] <javascript:;> < Caution-mailto:[email-masked]
> <javascript:;> >  <Caution-mailto:[email-masked] <javascript:;>> >;
> [email-masked] <javascript:;> < Caution-mailto:[email-masked] <javascript:;>
> >  <Caution-mailto:[email-masked] <javascript:;>>
>                                         Subject: [External] Re: [sacm]
> [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23
>
>
>
>
>                                                 However even if a vendor
> sends their data in the correct model scam would require, there is also the
> issue that different vendors might send different values for the same e.g
> for OS you might get WinXp/Windows XP/Microsoft Windows XP etc...
>
>
>
>                                         ​The solution to this is to allow
> the software vendor to specify how their software will be identified. This
> is already happening with vendor adoption of SWID tags. The SWID tag can be
> created by the software vendor and included as a part of the software. Many
> vendors (including Microsoft) are doing this for licensing issues. If a
> vendor does not include a SWID tag with their software, an installer can
> create a tag at the time of installation, or freely-available open source
> software can create tags for products on enterprise endpoints (an ideal
> solution for older endpoints).
>
>
>                                                 This might seem a bit
> pedantic, but if you want to query how many windows XP machines are
> impacted by a specific security issue, you will not have a complete picture.
>
>
>
>                                         ​Not pedantic at all!​
>
>
>
>                                         ​ It's been a problem that has
> plagued our networks for far too long now, and must be tackled by this work
> group if we are going to solve our broader use cases.
>                                         ​
>
>
>                                                 It would be too
> prescriptive to state the value of of attribute X should look exactly as it
> does in the following config/registry/command output.
>
>
>
>                                                 From: sacm <
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>> > on behalf of Wolfkiel, Joseph L
> CIV DISA ID (US) <[email-masked] <javascript:;> <
> Caution-mailto:[email-masked] <javascript:;> >
> <Caution-mailto:[email-masked] <javascript:;>> >
>                                                 Sent: Thursday, November
> 05, 2015 1:23 PM
>                                                 To: Chris Inacio
>                                                 Cc: Gunnar Engelbach;
> Haynes, Dan; Adam Montville; [email-masked] <javascript:;> <
> Caution-mailto:[email-masked] <javascript:;> >
>                                                 Subject: Re: [sacm]
> [Non-DoD Source] Re: Endpoint ID Design Team Notes: 2015-10-23
>
>
>                                                 Without an algorithm, how
> do you justify or prioritize collecting identification attributes?  If you
> want multi-vendor interoperability, it seems like we have to specify, at
> some level, what attributes are expected to be collected, how to exchange
> them between tools, and some standard thing we think the tools will do with
> them to "match" identities.  Right?  Or is there some other vision?  Can
> you explain how you would see this working if there's no common baseline
> matching algorithm?
>
>                                                 I do agree that it seems
> reasonable to periodically update the attributes over time as we identify
> which attributes provide the highest confidence matches, followed by an
> update to the matching algorithm to incorporate the new capabilities.
>
>                                                 Joseph L. Wolfkiel
>                                                 SCM Engineering Lead
>                                                 DISA ID52
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>>
>
>
>
>                                                 From: Chris Inacio
> [Caution-mailto:[email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:[email-masked]
> <javascript:;>> ]
>                                                 Cc: Haynes, Dan; Adam
> Montville; Gunnar Engelbach; [email-masked] <javascript:;> <
> Caution-mailto:[email-masked] <javascript:;> >
>                                                 Subject: [Non-DoD Source]
> Re: [sacm] Endpoint ID Design Team Notes: 2015-10-23
>
>                                                 All active links contained
> in this email were disabled.  Please verify the identity of the sender, and
> confirm the authenticity of all links contained within the message prior to
> copying and pasting the address to a Web browser.
>
>
>
>
>                                                 ----
>
>
>
>                                                 I would be nervous about
> standardizing the algorithm.  I think an informational draft describing
> various algorithm methodologies and tradeoffs would be great to capture –
> but I’m nervous about setting “into stone” per se the algorithm.
> Especially as I believe the right way forward will be to have an IANA
> registry for data model elements, and as we add more data elements, that
> might really change the landscape.
>
>
>
>                                                 --
>                                                 Chris Inacio
>                                                 [email-masked]
> <javascript:;> < Caution-mailto:[email-masked] <javascript:;> >
> <Caution-mailto:[email-masked] <javascript:;>>
>
>
>
>                                                 > On Nov 2, 2015, at 10:10
> PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]
> <javascript:;> < Caution-mailto:[email-masked]
> <javascript:;> >  <Caution-mailto:[email-masked]
> <javascript:;>> > wrote:
>                                                 >
>                                                 > +1 here.  We're in the
> process of updating our matching algorithm now.
>                                                 >
>                                                 > Defining an algorithm
> will also inform the process of collecting a common set of data and being
> able to mediate it into a standardized format for comparison.
>                                                 >
>                                                 > We should also keep in
> mind that different SACM sensors will have differing abilities to establish
> and track device identities over time.  Agent-based sensors can use the ID
> of their deployed agents, which (in my opinion) are pretty robust.
> Over-the network active, authenticated scanners can try to retrieve some
> persistent, unique device attributes that can be used for identification.
> Passive or unauthenticated scanners will be limited to trying to identify
> devices based on information the device(s) use to identify themselves on
> the network, information that can be derived by observing traffic sent and
> received by a device, or information received from unauthenticated service
> calls or probes.
>                                                 >
>                                                 > It's my assumption that
> the point of doing endpoint identification is to be able to differentiate
> whether a device discovered by one sensor is or isn't the same device
> discovered by another or that information about a device described by a
> sensor at a point in time can be retrieved at a later point in time based
>                                                 > The "identification"
> described above is a different issue than doing device "population"
> identification, which would consider how to describe and target policies or
> data collection efforts at groups of devices that share some common set
> ofcharacteristics.
>                                                 >
>                                                 > Joseph L. Wolfkiel
>                                                 > SCM Engineering Lead
>                                                 > DISA ID52
>                                                 > Fort Meade DISA
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  <Caution-mailto:
> [email-masked] <javascript:;>>
>                                                 >
>                                                 >
>                                                 > -----Original
> Message-----
>                                                 > From: sacm
> [Caution-Caution-mailto:[email-masked] <javascript:;> <
> Caution-mailto:[email-masked] <javascript:;> > ] On Behalf Of
> Haynes, Dan
>                                                 > Sent: Monday, November
> 02, 2015 3:27 AM
>                                                 > To: Adam Montville;
> Gunnar Engelbach
>                                                 > Cc: [email-masked]
> <javascript:;> < Caution-mailto:[email-masked] <javascript:;> >
> <Caution-mailto:[email-masked] <javascript:;>>
>                                                 > Subject: Re: [sacm]
>                                                 > This email was sent from
> a non-Department of Defense email account, and contained active links. All
> links are disabled, and require you to copy and paste the address to a Web
> browser. Please verify the identity of the sender, and confirm authenticity
>                                                 > Thanks for the feedback
> Gunnar and Adam!  What do others think about this?
>                                                 >
>                                                 >
>                                                 >
>                                                 > Thanks,
>                                                 >
>                                                 > Danny
>                                                 >
>                                                 >
>                                                 >
>                                                 > From: Adam
> Montville[Caution-Caution-Caution-mailto:[email-masked]
> <javascript:;> < Caution-mailto:[email-masked] <javascript:;>
> > ]
>                                                 > Sent: Monday, October
> 26, 2015 8:59 PM
>                                                 > To: Gunnar Engelbach <
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> > >
>                                                 > Cc: Haynes, Dan <
> [email-masked] <javascript:;> < Caution-mailto:[email-masked]
> <javascript:;> >  <Caution-mailto:[email-masked] <javascript:;>> >;
> [email-masked] <javascript:;> < Caution-mailto:[email-masked] <javascript:;>
> >  <Caution-mailto:[email-masked] <javascript:;>>
>                                                 > Subject: Re: [sacm]
>                                                 >       On Oct 23, 2015,
> at 1:22 PM, Gunnar Engelbach <[email-masked]
> <javascript:;> < Caution-mailto:[email-masked]
> <javascript:;> >  < Caution-Caution-Caution-mailto:
> [email-masked] <javascript:;> < Caution-mailto:
> [email-masked] <javascript:;> >  > > wrote:
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >       Defining an
> algorithm would help with consistency in correlation outcomes between
> implementers.  However, it would need to be acknowledged that such an
> algorithm could not be expected to cover all scenarios, and that in some
> cases that consistency could just mean it was consistently incorrect.
>                                                 >
>                                                 >       As part of a
> standard, I'd like to see such an algorithm and have it cover as much
> variance as possible -- the whole endpoint identification thing does not
> have much worth as a standard if results are inconsistent/unpredictable
> across implementers.  At the same time implementers are going to be much
> quicker to respond to errors and changing technologies than a standards
> body and they need to be free to do so.
>                                                 >
>                                                 >       So I think this
> creates two needs:
>                                                 >
>                                                 >       1) The algorithm
> should not attempt to cover all variations, just as many as we have a high
>                                                 >       2) The ability to
> utilize the algorithm should be available on request, but not required to
> always be used.  For example, when a consumer is making a request from a
> provider, that request should have the ability to specify that correlation
>                                                 > These seem reasonable.
> We should consider algorithm agility as another need.
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >       --gun
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >       On 10/23/2015 1:33
> PM, Haynes, Dan wrote:
>                                                 >
>                                                 >               Hi
> Everyone,
>                                                 >
>                                                 >
>                                                 >               Here are
> the notes from today's Endpoint ID Design Team Meeting (EID-DT).
>                                                 >
>                                                 >
>                                                 >
>                                                 >               Attendees
>                                                 >
>                                                 >               .
>  Ron Colvin
>                                                 >
>                                                 >               .
>  Josh Stevens
>                                                 >
>                                                 >               .
>  Joe Wolfkiel
>                                                 >
>                                                 >               .
>  Danny Haynes
>                                                 >
>                                                 >
>                                                 >
>                                                 >               Note Well
>                                                 >
>                                                 >
>                                                 >
>                                                 >               Agenda
>                                                 >
>                                                 >               .
>  Task descriptions
>                                                 >
>                                                 >               .
>  Open issues from the last virtual interim meeting
>                                                 >
>                                                 >               .
>  Next steps
>                                                 >
>                                                 >
>                                                 >
>                                                 >               Materials
>                                                 >
>                                                 >               .
>                                                 >               .
>  First, the task descriptions document was discussed.  All the discussion
> and feedback around this was captured in Word comments in the document.  An
> updated version based on feedback and discussion, will be sent out prior to
> the next EID-DT meeting.
>                                                 >
>                                                 >
>                                                 >
>                                                 >               .
>  A question was asked about where we were at with the Architecture
> document.  It was explained that we have made a lot of good progress
> recently during the two calls after the virtual interim meeting and that
> notes for those meetings were captured in the GitHub issue trackers that
> were discussed.  It was also noted that if anyone had feedback on the
> Architecture that they should send it out to the group sooner rather than
> later.
>                                                 >
>                                                 >
>                                                 >
>                                                 >               .
>  There was also a question about the SACM Charter.  Specifically, in
> addition to specifying the different data fields associated with
> identifying endpoints, are their plans to standardize any business logic
> around them.  For example, an algorithm for matching devices using the data
> collected by two different sensors.  If the data collected by two sensors,
> using the algorithm, match then the data could be combined as it all
> represents the same endpoint.  It was noted that this is a real problem
> that they are facing in the field and that it might be good to have an
> industry standard around it.  Another example, is around defining
>                                                 > and running these
> databases.  It was noted that there are no explicit plans to create
> matching algorithms, etc. as of yet, but, that you could seem the matching
> possibly being part of a query language for interfacing with a repository
> or the information about the location of an endpoint or the sensitivity of
> the data on an endpoint being covered under the manually assigned data
> associated with an endpoint.  This is something the broader group may want
> to discuss further.
>                                                 >
>                                                 >
>                                                 >
>                                                 >               Action
> Items
>                                                 >
>                                                 >               .
>  Update tasks descriptions before next EID-DT meeting (Danny Haynes)
>                                                 >
>                                                 >               .
>  Contribute NetD data model  (Joe Wolfkiel).
>                                                 >
>                                                 >
>                                                 >
>                                                 >               Please let
> me know if I missed anything, got anything wrong, or if you have any
> questions.
>                                                 >
>                                                 >
>                                                 >
>                                                 >               Thanks,
>                                                 >
>                                                 >               Danny
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >
>                                                 >               sacm
> mailing list
> [email-masked] < Caution-mailto:[email-masked] >  <Caution-mailto:
> [email-masked]>  < Caution-Caution-Caution-mailto:[email-masked] <
> Caution-mailto:[email-masked] >  >
>                                                 >
>  Caution-Caution-Caution-https://www.ietf.org/mailman/listinfo/sacm <
> Caution-https://www.ietf.org/mailman/listinfo/sacm >  <Caution-
> https://www.ietf.org/mailman/listinfo/sacm>  < Caution-Caution-Caution-
> https://www.ietf.org/mailman/listinfo/sacm < Caution-
> https://www.ietf.org/mailman/listinfo/sacm >  <Caution-
> https://www.ietf.org/mailman/listinfo/sacm>  >
>                                                 >
>                                                 >
>

---

From: Jerome Athias <[email-masked]>
Date: Fri, 13 Nov 2015 14:37:40 +0300

With (hopefully) less typos than in my previous email...

FYI, the following and attached diagram are extracted from the Object
Management Group (OMG) effort sysa/2015-11-01:

"
Identification connects identifiers with the entity they identify.
Identifiers are all assumed to be values, that is they are immutable.
An entity may be assigned different identifiers over time and may have
many at any one time.

The base Identifier class identifies a set of entities and is not
assumed to be unique or to identify only one entity. For example, a
name is an identifier but many people could have the same name and a
person could have multiple names. Identifiers or the relation to an
entity may be contextual.

The class of Unique Identifiers is more typical of I.T. systems and
managed identifiers, such as driver's license numbers. A unique
identifier is assumed unique within exactly one Namespace.

Subtypes of Identifier may be specific to identifying particular kinds
of entities. For example, a Location Identifier (such as an address or
GPS coordinate) is specific to identifying locations.

Note that as with all concepts, identifiers are independent of
representation. Since names are so often textual, we also define a
representation of names - "Textual Name".
"

Artifacts are available here:

·         Specification Document (PDF):
http://www.threatrisk.org/spec/RevisedSubmission/Revised%20Operational%20Threat%20Risk%20Submission.pdf

·         Specification Document (.DOC):
http://www.threatrisk.org/spec/RevisedSubmission/Revised%20Operational%20Threat%20Risk%20Submission.doc

·         Specification .ZIP with all models:
http://www.threatrisk.org/spec/RevisedSubmission/Revised%20threat-risk%20Submission%20machine%20readable%20files.zip

·         Community portal: http://threatrisk.org/drupal/

2015-11-13 12:00 GMT+03:00 Jerome Athias <[email-masked]>:
> On Friday, 6 November 2015, Wolfkiel, Joseph L CIV DISA ID (US)
> <[email-masked]> wrote:
>>
>> wildcard matching and complex queries to allow them to manually identify all
>> the software names that mean the same thing.
>>
>> Joseph L. Wolfkiel
>> SCM Engineering Lead
>> DISA ID52
>> a particular endpoint attribute. I'm just saying, an endpoint self report of
>> Caution-https://tools.ietf.org/html/draft-coffin-sacm-vuln-scenario-00 <
>> Caution-https://tools.ietf.org/html/draft-coffin-sacm-vuln-scenario-00 > .
>>
>> reports from a SWID tag endpoint self-report stored in a CMDB, and then scan
>> for attributes as needed. Definitely increases the scalability of a SACM
>> vulnerability management solution.
>>
>>
>> content in a standard format is the most important thing to be standardized.
>> Otherwise we might as well go back to proprietary solutions, of which there
>> are already a number out there.
>>
>> approach.  If it was simply a matter of trying every benchmark against every
>> endpoint to find which ones are applicable, that's a cross product that
>> quickly becomes untenable.
>>
>> software is installed, an endpoints role changes, etc.  The actual source of
>> those attributes don't matter (SWID vice directly from the OS, for example),
>> just that there is a path from what is needed to evaluate the policy to what
>> needs to be collected.
>>
>> them for this purpose.  Benchmarks could take advantage of SWID values to do
>> their self-determination, but that only works if the benchmark is authored
>> with knowledge of how data is represented in a SWID.  Further, I would not
>> rely on a set of SWIDs to be the complete representation of the software
>> maintain a database with records of the software installed on each endpoint,
>> then search that database for endpoints that reported running that
>> vulnerable software. You are right that this will require an applicability
>> language, and I fully support the idea of SACM developing this as part of a
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> > wrote:
>>
>>
>>
>> not a problem because the string is arbitrary -- it's just important that it
>> be consistent.  Which could still happen even with a single generated SWID
>> because other systems might not be using SWIDs.
>>
>> when there is a single global known value.  And we're having this discussion
>> because that's not the case.
>>
>> however, is for assessment content to use the same collection and evaluation
>> system to specify the attributes and values necessary to self-determine its
>> own applicability.  A language like OVAL is flexible enough to take
>> advantage of a SWID if it is available or otherwise use other attributes,
>> but even then it would have to be a SWID whose values were known to the
>> content author.
>>
>>
>>
>>
>> will take another look at the Endpoint Compliance Internet Draft:
>> Caution-https://datatracker.ietf.org/doc/draft-fitzgeraldmckay-sacm-endpointcompliance/.
>> Timothy [USA] <[email-masked] <
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> > wrote:
>>
>>
>>                                         Hi Jessica,
>>
>>
>>
>> back to customer A, creates a SWID tag for the same piece of software during
>> Caution-http://www.boozallen.com/ > Caution-www.boozallen.com <
>> Caution-http://www.boozallen.com >  <Caution-http://www.boozallen.com>
>>
>>
>>
>>                                         From: sacm
>> [Caution-mailto:[email-masked] < Caution-mailto:[email-masked]
>> >  <Caution-mailto:[email-masked]> ] On Behalf Of Jessica
>> Fitzgerald-McKay
>>                                         To: Sherif Mansour Farag
>> <[email-masked] < Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> >
>> < Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]> >;
>> Adam Montville <[email-masked] <
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> >; Gunnar Engelbach
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> >; Wolfkiel, Joseph L CIV
>> DISA ID (US) <[email-masked] <
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> >; Chris Inacio
>> <[email-masked] < Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> >; [email-masked] <
>> Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]>
>>                                         The solution to this is to allow
>> pedantic, but if you want to query how many windows XP machines are impacted
>> by a specific security issue, you will not have a complete picture.
>>
>>
>>
>>                                         Not pedantic at all!
>>
>>
>>
>>                                         It's been a problem that has
>>                                         Agreed. That is why the SWID tag
>> format is useful here.
>>
>>
>>
>>
>>
>>                                                 Sherif Mansour
>>                                                 Enterprise Information
>> Security
>> <[email-masked] < Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> > on behalf of Wolfkiel, Joseph L CIV
>> DISA ID (US) <[email-masked] <
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> >
>>                                                 Sent: Thursday, November
>> 05, 2015 1:23 PM
>>                                                 To: Chris Inacio
>>                                                 Cc: Gunnar Engelbach;
>> Haynes, Dan; Adam Montville; [email-masked] < Caution-mailto:[email-masked] >
>>                                                 Subject: Re: [sacm]
>> them to "match" identities.  Right?  Or is there some other vision?  Can you
>> explain how you would see this working if there's no common baseline
>> matching algorithm?
>>
>>                                                 I do agree that it seems
>> [email-masked] <
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]>
>>
>>
>>
>> [Caution-mailto:[email-masked] < Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> ]
>> Montville; Gunnar Engelbach; [email-masked] < Caution-mailto:[email-masked] >
>> but I’m nervous about setting “into stone” per se the algorithm.  Especially
>> as I believe the right way forward will be to have an IANA registry for data
>> model elements, and as we add more data elements, that might really change
>> the landscape.
>>
>>
>>
>>                                                 --
>>                                                 Chris Inacio
>>                                                 [email-masked] <
>> Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]>
>>
>>
>>
>>                                                 > On Nov 2, 2015, at 10:10
>> PM, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked] <
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> > wrote:
>>                                                 >
>>                                                 > +1 here.  We're in the
>> of their deployed agents, which (in my opinion) are pretty robust.  Over-the
>> network active, authenticated scanners can try to retrieve some persistent,
>> unique device attributes that can be used for identification.  Passive or
>> unauthenticated scanners will be limited to trying to identify devices based
>> on information the device(s) use to identify themselves on the network,
>> information that can be derived by observing traffic sent and received by a
>> device, or information received from unauthenticated service calls or
>> probes.
>>                                                 >
>>                                                 > It's my assumption that
>> sensor at a point in time can be retrieved at a later point in time based on
>> some "identification" heuristic.
>>                                                 >
>>                                                 > The "identification"
>> [email-masked] <
>> Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]>
>>                                                 >
>>                                                 >
>>                                                 > -----Original
>> Message-----
>>                                                 > From: sacm
>> [Caution-Caution-mailto:[email-masked] <
>> Caution-mailto:[email-masked] > ] On Behalf Of Haynes, Dan
>>                                                 > Sent: Monday, November
>> 02, 2015 3:27 AM
>>                                                 > To: Adam Montville;
>> Gunnar Engelbach
>>                                                 > Cc: [email-masked] <
>> Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]>
>>                                                 > Subject: Re: [sacm]
>> Montville[Caution-Caution-Caution-mailto:[email-masked] <
>> Caution-mailto:[email-masked] > ]
>>                                                 > Sent: Monday, October
>> 26, 2015 8:59 PM
>>                                                 > To: Gunnar Engelbach
>> Caution-mailto:[email-masked] > >
>>                                                 > Cc: Haynes, Dan
>> <[email-masked] < Caution-mailto:[email-masked] >
>> <Caution-mailto:[email-masked]> >; [email-masked] <
>> Caution-mailto:[email-masked] >  <Caution-mailto:[email-masked]>
>>                                                 > Subject: Re: [sacm]
>> at 1:22 PM, Gunnar Engelbach <[email-masked] <
>> Caution-mailto:[email-masked] >  <
>> Caution-Caution-Caution-mailto:[email-masked] <
>> Caution-mailto:[email-masked] >  > > wrote:
>>                                                 >
>>                                                 >
>>                                                 >
>>                                                 >
>>                                                 >       Defining an
>> quicker to respond to errors and changing technologies than a standards body
>> and they need to be free to do so.
>>                                                 >
>>                                                 >       So I think this
>> creates two needs:
>>                                                 >
>>                                                 >       1) The algorithm
>> Slides from meeting (see attached)
>>                                                 >
>>                                                 >               .
>> Task descriptions (see attached).
>>                                                 >
>>                                                 >
>>                                                 >
>>                                                 >               Notes
>>                                                 >
>>                                                 >               .
>> First, the task descriptions document was discussed.  All the discussion and
>> feedback around this was captured in Word comments in the document.  An
>> A question was asked about where we were at with the Architecture document.
>> It was explained that we have made a lot of good progress recently during
>> the two calls after the virtual interim meeting and that notes for those
>> meetings were captured in the GitHub issue trackers that were discussed.  It
>> was also noted that if anyone had feedback on the Architecture that they
>> should send it out to the group sooner rather than later.
>>                                                 >
>>                                                 >
>>                                                 >
>>                                                 >               .
>> There was also a question about the SACM Charter.  Specifically, in addition
>> to specifying the different data fields associated with identifying
>> endpoints, are their plans to standardize any business logic around them.
>> For example, an algorithm for matching devices using the data collected by
>> two different sensors.  If the data collected by two sensors, using the
>> algorithm, match then the data could be combined as it all represents the
>> same endpoint.  It was noted that this is a real problem that they are
>> facing in the field and that it might be good to have an industry standard
>> around it.  Another example, is around defining populations such as "these
>> are all the devices owned by an organization", or "these are all the devices
>> in a single location".  There is also a question around how accurate can it
>> be (state, city, building, closet, etc.).  A last example is making
>> statements such as this applies to all servers running Windows 2012,
>> containing sensitive info!
>>                                                 > rmation,
>>                                                 > and running these
>> databases.  It was noted that there are no explicit plans to create matching
>> algorithms, etc. as of yet, but, that you could seem the matching possibly
>> being part of a query language for interfacing with a repository or the
>> information about the location of an endpoint or the sensitivity of the data
>> on an endpoint being covered under the manually assigned data associated
>> with an endpoint.  This is something the broader group may want to discuss
>> further.
>>                                                 >
>>                                                 >
>>                                                 >
>>                                                 >               Action
>> Items
>>                                                 >
>>                                                 >               .
>> <Caution-mailto:[email-masked]>  <
>> Caution-Caution-Caution-mailto:[email-masked] < Caution-mailto:[email-masked]
>> >  >
>>                                                 >
>> <Caution-https://www.ietf.org/mailman/listinfo/sacm>  <
>> <Caution-https://www.ietf.org/mailman/listinfo/sacm>  >
>>                                                 >
>>                                                 >
>>

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 13 Nov 2015 12:06:33 -0500

Very useful pointers, Jerome.  It's especially helpful
to see the OMG and CTI work being harmonized.

The note here also inherently raises the issue of
whether there are any other SACMites who participate in
CTI and how the two environments can be reconciled.
Ditto for other stovepipes, especially the 3GPP SA3 SCAS
equivalent that had 41 contributions into the Anaheim
meeting two weeks ago  Jess' efforts to bridge SACM
with the 20 Controls is a good start that needs to be
significantly expanded.

--tony

On 2015-11-13 6:37 AM, Jerome Athias wrote:
> ·         Community portal:http://threatrisk.org/drupal/
>
>
>
> 2015-11-13 12:00 GMT+03:00 Jerome Athias<[email-masked]>:
>> Yes and no...
>>
>>> CIV DISA ID (US); Chris Inacio; Harrison, Timothy [USA];[email-masked]
>>> [Caution-mailto:[email-masked]  <Caution-mailto:[email-masked]
>>> <[email-masked]  <Caution-mailto:[email-masked]  >
>>> <Caution-mailto:[email-masked]  ><Caution-mailto:[email-masked]>  >;
>>> <[email-masked]  <Caution-mailto:[email-masked]  >
>>> <Caution-mailto:[email-masked]>  >;[email-masked]  <
>>> Caution-mailto:[email-masked]  ><Caution-mailto:[email-masked]>
>>> <[email-masked]  <Caution-mailto:[email-masked]  >
>>> Haynes, Dan; Adam Montville;[email-masked]  <Caution-mailto:[email-masked]  >
>>>                                                  Subject: Re: [sacm]
>>> [Caution-mailto:[email-masked]  <Caution-mailto:[email-masked]  >
>>> Montville; Gunnar Engelbach;[email-masked]  <Caution-mailto:[email-masked]  >
>>> Caution-mailto:[email-masked]  ><Caution-mailto:[email-masked]>
>>>
>>>
>>>
>>>                                                  > On Nov 2, 2015, at 10:10
>>>                                                  > Cc:[email-masked]  <
>>> Caution-mailto:[email-masked]  ><Caution-mailto:[email-masked]>
>>>                                                  > Subject: Re: [sacm]
>>> <[email-masked]  <Caution-mailto:[email-masked]  >
>>> <Caution-mailto:[email-masked]>  >;[email-masked]  <
>>> Caution-mailto:[email-masked]  ><Caution-mailto:[email-masked]>
>>>                                                  > Subject: Re: [sacm]
>>> [email-masked]  <Caution-mailto:[email-masked]  >
>>> Caution-Caution-Caution-mailto:[email-masked]  <Caution-mailto:[email-masked]
>>>>   >
>>>                                                  >

-- 

________________________________ **

*Anthony Michael Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked]

+1 703 999 8270 <tel:+1%20703%20999%208270>

________________________________ **

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 13 Nov 2015 09:16:45 -0500

The note here Jerome also inherently raises the issue of
whether there are any other SACMites who participate in
CTI and how the two environments can be reconciled.
Ditto for other stovepipes, especially the 3GPP SA3 SCAS
equivalent that had 41 contributions into the Anaheim
meeting two weeks ago.  Or are some of these fora on
autopilot oblivious to the other "traffic"?

--tony

-- 

[email-masked] <mailto:[email-masked]>

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 13 Nov 2015 18:57:00 -0600

The complete thread from this message has been an interesting read. 
Here are some possible conclusions based on what I've read from the
entire conversation (in no particular order; some are potentially
obvious; there may be others).

* Endpoint identification is different from the notion of applicability.

* Asset management requires endpoint identification

* Vulnerability and configuration assessment depend on asset management

* Segregation of collection and evaluation adds requirements to asset
management: Capture information suitable for applicability

* Applicability is likely to require an applicability language, which
may, in part, rely on endpoint identification (SW and/or HW) elements

* Determining applicability will require accommodating a mix of
mechanisms (i.e. SWID, CPE, OVAL, or similar)

Also from the thread are some outstanding questions (there may be others):

* For Gunnar: Can you identify places in our use cases where SWIDs don't
(can't??) apply?

* Have we done enough work in the Endpoint ID design to start working on
the endpoint identification issue within the information model?

* What work needs to be done on making applicability determinations? 
(Seems that the foundation of this is being able to identify hardware
and software.)

* How do we deal with the "chicken and egg" problem brought about by
segregating evaluation from collection? (Gunnar raised this general
point, from which I infer that the asset management database will need
to be continually updated.)

I have a thought on that last question.  Because we're separating
evaluation from collection, and we have a chicken/egg problem, do we
need to stress over that?  Yes, there's the possibility for a "miss"
when an evaluation is performed on data stored in the CMDB/datastore,
but this is a problem that's been solved in other domains.  Consider
page files and what happens when an OS looks for a page in memory that
doesn't exist.  It goes out to disk to find it.  We could do something
similar with an option for the CMDB and/or the collector itself to
remember the missed request, so that it's not missed in the future. 
(We're doing this anyway with stale data, so it doesn't feel like a
stretch.)

Kind regards,

Adam

On 10/23/2015 12:33 PM, Haynes, Dan wrote:
>
> Hi Everyone,
>
>
> Here are the notes from today’s Endpoint ID Design Team Meeting (EID-DT).
>
>  
>
> *Attendees*
>
> ·         Ron Colvin
>
> ·         Josh Stevens
>
> ·         Joe Wolfkiel
>
> ·         Danny Haynes
>
>  
>
> *Note Well*
>
> * *
>
> *Agenda*
>
> ·         Task descriptions
>
> ·         Open issues from the last virtual interim meeting
>
> ·         Next steps
>
>  
>
> *Materials *
>
> ·         Slides from meeting (see attached)
>
> ·         Task descriptions (see attached). 
>
>  
>
> *Notes*
>
> ·         First, the task descriptions document was discussed.  All
> the discussion and feedback around this was captured in Word comments
> in the document.  An updated version based on feedback and discussion,
> ·         A question was asked about where we were at with the
> Architecture document.  It was explained that we have made a lot of
> meeting and that notes for those meetings were captured in the GitHub
> issue trackers that were discussed.  It was also noted that if anyone
> had feedback on the Architecture that they should send it out to the
> group sooner rather than later.
>
>  
>
> ·         There was also a question about the SACM Charter. 
> Specifically, in addition to specifying the different data fields
> associated with identifying endpoints, are their plans to standardize
> any business logic around them.  For example, an algorithm for
> matching devices using the data collected by two different sensors. 
> If the data collected by two sensors, using the algorithm, match then
> the data could be combined as it all represents the same endpoint.  It
> was noted that this is a real problem that they are facing in the
> field and that it might be good to have an industry standard around
> it.  Another example, is around defining populations such as “these
> are all the devices owned by an organization”, or “these are all the
> devices in a single location”.  There is also a question around how
> accurate can it be (state, city, building, closet, etc.).  A last
> example is making statements such as this applies to all servers
> running Windows 2012, containing sensitive information, and running
> these databases.  It was noted that there are no explicit plans to
> create matching algorithms, etc. as of yet, but, that you could seem
> the matching possibly being part of a query language for interfacing
> with a repository or the information about the location of an endpoint
> or the sensitivity of the data on an endpoint being covered under the
> manually assigned data associated with an endpoint.  This is something
> *Action Items*
> ·         Update tasks descriptions before next EID-DT meeting (Danny
> Haynes)**
>
> ·         Contribute NetD data model  (Joe Wolfkiel).**
>
> * *
>