Subject: [sacm] Notes from informal working session on the information model this afternoon

From: Lisa Lorenzin <[email-masked]>
Date: Wed, 6 Apr 2016 22:04:14 +0000

Hi all,

A group of SACM participants sat down after the WG F2F today to discuss open topics on the information model.  Here are the notes I took on the output of our discussion, which we hope will be useful in further development and reconciliation of the new individual I-M with the WG IM:

Participants:
Adam Montville
Danny Haynes
Dave Waltermire
David Somers-Harris
Chris Inacio
Henk Birkholz
Nancy Cam-Winget
Bill Munyan
Lisa Lorenzin

Notes:
*       Data at rest is not our problem
o       There will be a data store somewhere
o       Our job is not to define the schema of that data store
o       Our information model is the thing that enables mapping from data at rest (internal representation) to data in motion (interoperable thing on the wire)
*       Change "object" to "subject"
*       An IP address can be a subject, or it can be an attribute of a subject
o       If it's a subject, it can have attributes
o       It can be both at once (in other words, an IP address can both have attributes and be an attribute of an endpoint)
*       SACM statement
o       Content element is one subject + its subject metadata
o       Statement contains one or more content elements
o       Statement metadata is about a provider
o       Statement contains SACM content (subjects)
o       Content metadata is about that content
o       The purpose of a statement is so that provider metadata can be inherited by all the content in a statement, rather than having to repeat the provider metadata individually for each content element
o       Rather than having to carry it on the wire for each element
o       When the elements are stored, the statement metadata may need to be attached to each element for storage
o       If we're going to keep statements around, 4.3 SACM Statements should express this
*       A statement is a collection of subjects that have one or more attributes
o       The subject doesn't have to be identified
o       Maybe I don't know the data source
*       Is an attribute either identifying or not identifying?
o       Identifying = may be considered by a consumer as having identifying value
o       Attributes are not inherently identifying, but circumstantially
o        Subject has a set of attributes - some of those attributes are identifying attributes
o       Consumer can direct the provider what attributes are identifying through guidance (or not)
*       Can you relate subjects?
o       If I have a subject that is an endpoint, and other subjects are software on the endpoint
o       Yes, via metadata
o       Or via an attribute "installed-on"? Easier to store upfront for processing
*       Desirable to have a placeholder in the IM for metadata on an attribute or a subject
o       We don't have to want to define that identifier - left up to the SACM domain administrator
o       Metadata cardinality: multi-valued - zero or more identifiers in that placeholder
*       May be zero if nobody has assigned a unique identifier
*       May be one if the organization is really organized
*       May be more than one if the organization isn't
o       Huge problem of correlation of those identifiers across disparate SACM components
*       May be solved by stacking multiple identifiers - multi-valued
*       May be solved by some other correlation mechanism
*       That's the problem for the SACM domain administrator
*       Proposed design limitation on statements
o       Can only put subjects into the statement that are the same type
o       Statement about subjects observations can't contain subjects about directory entries
o       Purpose of limitation is to make sure the statement metadata is consistent
o       So if you want to talk about multiple types of subject, utter multiple statements

                                                        Regards,

                                                                Lisa

--
Lisa Lorenzin    /    Principal Solutions Architect
[email-masked]    /    919-384-7275

Pulse Secure    /    https://www.pulsesecure.net
Facebook: https://www.facebook.com/pulsesecure1
LinkedIn: https://www.linkedin.com/company/pulse-secure
Twitter: https://twitter.com/PulseSecure1

---

From: Adam Montville <[email-masked]>
Date: Thu, 7 Apr 2016 08:58:26 -0300

Thanks for sending this along, Lisa.  And, thanks to each of the participants.  I think we made good progress on proposing a path forward, which we’ll discuss in some detail during Friday’s session.

Kind regards,

Adam

> On Apr 6, 2016, at 7:04 PM, Lisa Lorenzin <[email-masked]> wrote:
> 
> Hi all,
> 
> Data at rest is not our problem
> There will be a data store somewhere
> Our job is not to define the schema of that data store
> Our information model is the thing that enables mapping from data at rest (internal representation) to data in motion (interoperable thing on the wire)
> Change "object" to "subject"
> An IP address can be a subject, or it can be an attribute of a subject
> If it's a subject, it can have attributes
> It can be both at once (in other words, an IP address can both have attributes and be an attribute of an endpoint)
> SACM statement
> Content element is one subject + its subject metadata
> Statement contains one or more content elements
> Statement metadata is about a provider
> Statement contains SACM content (subjects)
> Content metadata is about that content
> The purpose of a statement is so that provider metadata can be inherited by all the content in a statement, rather than having to repeat the provider metadata individually for each content element
> Rather than having to carry it on the wire for each element
> When the elements are stored, the statement metadata may need to be attached to each element for storage
> If we're going to keep statements around, 4.3 SACM Statements should express this
> A statement is a collection of subjects that have one or more attributes
> The subject doesn't have to be identified
> Maybe I don't know the data source
> Is an attribute either identifying or not identifying?
> Identifying = may be considered by a consumer as having identifying value
> Attributes are not inherently identifying, but circumstantially
> Subject has a set of attributes - some of those attributes are identifying attributes
> Consumer can direct the provider what attributes are identifying through guidance (or not)
> Can you relate subjects?
> If I have a subject that is an endpoint, and other subjects are software on the endpoint
> Yes, via metadata
> Or via an attribute "installed-on"? Easier to store upfront for processing
> Desirable to have a placeholder in the IM for metadata on an attribute or a subject
> We don't have to want to define that identifier - left up to the SACM domain administrator
> Metadata cardinality: multi-valued - zero or more identifiers in that placeholder
> May be zero if nobody has assigned a unique identifier
> May be one if the organization is really organized
> May be more than one if the organization isn't
> Huge problem of correlation of those identifiers across disparate SACM components
> May be solved by stacking multiple identifiers - multi-valued
> May be solved by some other correlation mechanism
> That's the problem for the SACM domain administrator
> Proposed design limitation on statements
> Can only put subjects into the statement that are the same type
> Statement about subjects observations can't contain subjects about directory entries
> Purpose of limitation is to make sure the statement metadata is consistent
> So if you want to talk about multiple types of subject, utter multiple statements
> 
>                                                         Regards,
> 
>                                                                 Lisa
> 
> 
> --
> [email-masked] <mailto:[email-masked]>    /    919-384-7275
> 
> Pulse Secure    /    https://www.pulsesecure.net <https://www.pulsesecure.net/>
> Facebook: https://www.facebook.com/pulsesecure1 <https://www.facebook.com/pulsesecure1>
> LinkedIn: https://www.linkedin.com/company/pulse-secure <https://www.linkedin.com/company/pulse-secure>
> Twitter: https://twitter.com/PulseSecure1 <https://twitter.com/PulseSecure1>
> 
> 
> 
> _______________________________________________
> sacm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: Chris Inacio <[email-masked]>
Date: Thu, 7 Apr 2016 14:24:21 +0000

> 	• Data at rest is not our problem
> 	• There will be a data store somewhere
> 	• Our job is not to define the schema of that data store
> 	• Our information model is the thing that enables mapping from data at rest (internal representation) to data in motion (interoperable thing on the wire)
> 	• Change "object" to "subject"
> 	• An IP address can be a subject, or it can be an attribute of a subject
> 	• If it's a subject, it can have attributes
> 	• It can be both at once (in other words, an IP address can both have attributes and be an attribute of an endpoint)
> 	• SACM statement
> 	• Content element is one subject + its subject metadata
> 	• Statement contains one or more content elements
> 	• Statement metadata is about a provider
> 	• Statement contains SACM content (subjects)
> 	• Content metadata is about that content
> 	• The purpose of a statement is so that provider metadata can be inherited by all the content in a statement, rather than having to repeat the provider metadata individually for each content element
> 	• Rather than having to carry it on the wire for each element
> 	• When the elements are stored, the statement metadata may need to be attached to each element for storage
> 	• If we're going to keep statements around, 4.3 SACM Statements should express this
> 	• A statement is a collection of subjects that have one or more attributes
> 	• The subject doesn't have to be identified
> 	• Maybe I don't know the data source
> 	• Is an attribute either identifying or not identifying?
> 	• Identifying = may be considered by a consumer as having identifying value
> 	• Attributes are not inherently identifying, but circumstantially 
> 	• Subject has a set of attributes - some of those attributes are identifying attributes
> 	• Consumer can direct the provider what attributes are identifying through guidance (or not)
> 	• Can you relate subjects?
> 	• If I have a subject that is an endpoint, and other subjects are software on the endpoint
> 	• Yes, via metadata 
> 	• Or via an attribute "installed-on"? Easier to store upfront for processing

UID statements:
> 	• Desirable to have a placeholder in the IM for metadata on an attribute or a subject
> 	• We don't have to want to define that identifier - left up to the SACM domain administrator
> 	• Metadata cardinality: multi-valued - zero or more identifiers in that placeholder

> 	• May be zero if nobody has assigned a unique identifier
> 	• May be one if the organization is really organized
> 	• May be more than one if the organization isn’t
(this all goes to my thought of this “type” being an arbitrary length octet array.)

> 	• Huge problem of correlation of those identifiers across disparate SACM components
> 	• May be solved by stacking multiple identifiers - multi-valued
> 	• May be solved by some other correlation mechanism
> 	• That's the problem for the SACM domain administrator

So I was thinking about this and Henk’s protestations on this front.  I do NOT want to change and say that we should implement (G)UID’s as a required part of the spec.  But I was thinking about interoperability some with respect to this, and I’m wondering if we specify a function point in the control plane.  In that control plane function point, a client may ask for a UID delegation – e.g. get a UID and something like OID’s, it can suffix its given UID locally (THIS IS A STRAW MAN HERE, NOT A FINISHED DESIGN/THOUGHT).

But, what it means for the server to give back that UID should be weakly defined.  And, I would say that maybe the server can defer completely and not even provide a UID.

My thought is that we should support having a UID in the info model, likely something like an arbitrary length of octets.  This can function as a “key” to associate observations back to assets.  If we should support a function point that allows the server to generate a “key”, and how that works - I think that’s a much harder question.  

But thinking forward, how would a client interoperate with a server from a different vendor related to this?  Obviously, you can design the server data store such that it correlates without needing a UID, but maybe we shouldn’t preclude the possibility of a system design with a UID as key.

(Yes, this is somewhat my goals of having my cake and eating it too.)

> 
> 	• Proposed design limitation on statements
> 	• Can only put subjects into the statement that are the same type
> 	• Statement about subjects observations can't contain subjects about directory entries
> 	• Purpose of limitation is to make sure the statement metadata is consistent
> 	• So if you want to talk about multiple types of subject, utter multiple statements
>  
>                                                         Regards,
>  
>                                                                 Lisa
>  
>  
> -- 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

--
Chris Inacio
[email-masked]

---

From: Adam Montville <[email-masked]>
Date: Thu, 7 Apr 2016 11:46:09 -0300

> On Apr 7, 2016, at 11:24 AM, Chris Inacio <[email-masked]> wrote:
> 
> 
> 
> 

The vulnerability scenario makes this statement: “Unique and persistent endpoint IDs are used to allow for endpoints to be tracked over time and between sensors as well as allow for proper counts of assets during inventories and other similar collections."

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

---

From: Chris Inacio <[email-masked]>
Date: Thu, 7 Apr 2016 23:03:42 +0000

--
Christopher Inacio
Technical Director
Security Automation
CERT / Software Engineering Institute
Carnegie Mellon University
[email-masked]<mailto:[email-masked]>
o: 412 268-3098
c: 412 726-7522
Sent from my mobile

On Apr 7, 2016, at 11:46 AM, Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 7, 2016, at 11:24 AM, Chris Inacio <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 6, 2016, at 7:04 PM, Lisa Lorenzin <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Participants:
Adam Montville
Danny Haynes
Dave Waltermire
David Somers-Harris
Chris Inacio
Henk Birkholz
Nancy Cam-Winget
Bill Munyan
Lisa Lorenzin

Notes:

UID statements:

It may state that, but I don't have a clue how to make it reality. I don't know of a NIDS that will conform.

                                                       Regards,

                                                               Lisa

--
Lisa Lorenzin    /    Principal Solutions Architect
[email-masked]<mailto:[email-masked]>    /    919-384-7275

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

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

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

---

From: Adam Montville <[email-masked]>
Date: Fri, 8 Apr 2016 18:32:26 -0300

> On Apr 7, 2016, at 8:03 PM, Chris Inacio <[email-masked]> wrote:
> 

I submitted a pull request to the vulnerability scenario repository, which embodies significant (IMO) improvements to the way the vulnerability scenario draft conveys the ideas it contains.  One of the improvements I made was to recognize that the scenario relies on an endpoint management capability (of some sort) in the ecosystem.

Provided the NIDS collaborates with such a capability, unique endpoint IDs seem feasible.