Subject: [sacm] Asset Identification

From: Adam Montville <[email-masked]>
Date: Tue, 26 Mar 2013 22:10:24 +0000

I've been doing some non-SACM related work that has a need for an asset model sort of like the one in the current Asset Identification draft.  The way the Asset Identification draft is worded relegates it for use only for the purpose of identification.  I'd like to split the Asset Identification draft into at least two separate documents, where one specifies the asset model and the other which builds on the first for the purpose of asset identification.

I think such a split is advantageous in a couple of ways, but the one that stands out is having the ability to align/absorb with other efforts more easily.

Thoughts?

Adam

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 26 Mar 2013 19:11:30 -0400

Hi Adam,

Standards are wonderful; everybody should have one?

Aligning/absorbing other efforts sounds like trying to define a standardized
bucket into which people can stuff their own proprietary data.

The problem is there is a lack of interoperability.

And multiple models will call for new standards for mapping between models .

Can you explain further how aligning/absorbing other efforts would create
better interoperability, and make the Internet run better?

Remember, we're doing this work within the IETF, and the primary concern is
making the Internet run better.

I've been doing IETF work for 20 years, and have seen lots of efforts to
align/absorb fail; I'd like to know why this one is different.

I'm concerned that trying to align/absorb efforts that have different goals
than IETF might slow/stall the process or lead to an unwieldy and unhelpful
kitchen-sink design.

Did you have specific efforts in mind for absorption? 

What are the goals of those efforts? How well do those goals align with IETF
goals?

Do the proponents of those efforts want their design to be absorbed into an
IETF design, even if doing so substantially changes the design?

Are the proponents willing to turn over change control of their design to
the IETF?

Have they published their designs in internet-drafts so the IETF can
consider whether it wants to align/absorb such a design?

If splitting into model+identification is adopted, does that mean each ID
would become a type/value differentiated union?

Are these different models from distinctly different communities with
established widely-deployed usage (such as telephone #s and IP addresses), 

or from proponents with an ID model that has no deployment yet?

If an ID model is already being used in standard protocol messages, will the
proponents revamp their messages to use the differentiated union?

You raise the concern that the asset identifier can only be used for
identification. What other use cases did you have in mind?

If we are defining an approach to standardize asset identification, why
would we want those other use cases considered as part of the requirements?

Can you provide some examples so we can better understand what you think we
should be striving for?

Thanks,

David Harrington

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

+1-603-828-1401

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Montville
Sent: Tuesday, March 26, 2013 6:10 PM
To: [email-masked]'
Subject: [sacm] Asset Identification

I've been doing some non-SACM related work that has a need for an asset
model sort of like the one in the current Asset Identification draft.  The
way the Asset Identification draft is worded relegates it for use only for
the purpose of identification.  I'd like to split the Asset Identification
draft into at least two separate documents, where one specifies the asset
model and the other which builds on the first for the purpose of asset
identification. 

I think such a split is advantageous in a couple of ways, but the one that
stands out is having the ability to align/absorb with other efforts more
easily.

Thoughts?

Adam

---

From: Adam Montville <[email-masked]>
Date: Wed, 27 Mar 2013 01:07:18 +0000

David,

You're clearly a wealth of information – glad to have had you respond.  Comments inline.

Adam

From: ietfdbh <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 26, 2013 4:11 PM
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sacm] Asset Identification

Hi Adam,

Aligning/absorbing other efforts sounds like trying to define a standardized bucket into which people can stuff their own proprietary data.
The problem is there is a lack of interoperability.
And multiple models will call for new standards for mapping between models …

What I'd like to avoid is multiple models. Sean Turner recommended, for example, looking at the NETMOD/NETCONF, SCIM, and other work related to "assets."  What I think we want to avoid is multiple models, and pulling the model presented in Asset Identification out into its own document may help achieve that.

Can you explain further how aligning/absorbing other efforts would create better interoperability, and make the Internet run better?

SACM is a little different than some of the other efforts at IETF.  We seek to make the Internet run safer, not necessarily "better."  As cryptographic hashing algorithms are fundamental to most of the security we realize today, asset description and identification is fundamental to securing our computing resources.

Remember, we’re doing this work within the IETF, and the primary concern is making the Internet run better.
I’ve been doing IETF work for 20 years, and have seen lots of efforts to align/absorb fail; I’d like to know why this one is different.
I’m concerned that trying to align/absorb efforts that have different goals than IETF might slow/stall the process or lead to an unwieldy and unhelpful kitchen-sink design.

First, absorption was a very poor choice of words on my part.  Consider it stricken from the record, if you would.  Perhaps leverage or use would have been better.  I don't see value in reinventing the wheel here.

I've looked a bit at the NETMOD YANG Data Model for System Management (draft-ietf-netmod-system-mgmt-05), not so much at SCIM yet.  That document has the concept of a "system" which has some attributes, including a container called "platform."  There are similarities between the NETMOD Data Model for System Management "platform" and the asset model presented in the Asset Identification specification.

It seems that would be better off ensuring that there's a clean relationship between the two perspectives.

What are the goals of those efforts? How well do those goals align with IETF goals?
Do the proponents of those efforts want their design to be absorbed into an IETF design, even if doing so substantially changes the design?

Reiterating: Absorption was the wrong word to use.

Are the proponents willing to turn over change control of their design to the IETF?

So far, I've been limiting comparisons to IETF Working Groups.

Have they published their designs in internet-drafts so the IETF can consider whether it wants to align/absorb such a design?

If splitting into model+identification is adopted, does that mean each ID would become a type/value differentiated union?
Are these different models from distinctly different communities with established widely-deployed usage (such as telephone #s and IP addresses),
or from proponents with an ID model that has no deployment yet?
If an ID model is already being used in standard protocol messages, will the proponents revamp their messages to use the differentiated union?

All great questions that would need answers if we were to decide to explore this route.  I'm simply asking whether anyone sees a benefit in doing so.

You raise the concern that the asset identifier can only be used for identification. What other use cases did you have in mind?

The work I've been doing is related to security metrics, and I'm looking at the ISO 27004 model.  There, they have something they call an "object" which is really more like an asset in our terms.  To represent a metric object (that thing from which attributes are harvested for measurement) in a generic manner, the description of the asset needs to be more encompassing than CPE can provide, but not as detailed as AI or SWID.  Remember that an asset can be a person, document, etc. - anything of value.  CPE and SWID do not cover these cases, and AI is not to be used for anything other than instance-level identification.

I hope that explains my motivation.

If we are defining an approach to standardize asset identification, why would we want those other use cases considered as part of the requirements?

I'm thinking that asset identification can happen with varying degrees of precision.

Can you provide some examples so we can better understand what you think we should be striving for?

Sure.  In one example in ISO 27004, a metric is described that requires harvesting attributes from a user database.  I would like to create some machine readable content that describes this in a manner generic enough for any enterprise environment, and then allow an end user to point the implementation to the appropriate user database.  It is only at that time that we have enough information to complete an AI, CPE, or SWID representation.

Maybe this isn't a great approach.  Perhaps it's possible to simply use AI intact to act as a placeholder until more complete information is available.

I'm also aware that the scenario I just described is probably out of scope for SACM.  But, I don't believe that should matter in making design decisions for the future.

Thanks,
David Harrington
[email-masked]<mailto:[email-masked]>
+1-603-828-1401
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, March 26, 2013 6:10 PM
To: [email-masked]<mailto:[email-masked]>'
Subject: [sacm] Asset Identification

Thoughts?

Adam

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 27 Mar 2013 12:57:08 -0400

I don't have a handle on what the effect of this would be, but in theory 
this sounds like a good idea.

 From the SACM perspective, would breaking AI in twain be a 
simplification?  That is, all things being equal, is it reasonable to 
assume that understanding and implementing the standards will be 
simplified by breaking it up rather than making it more difficult by 
having to use two documents?

Are there potential uses within SACM where just the asset model alone 
would be used without also needing the dependent asset identification part?

A yes to any of those questions would be reason to go ahead.

And if this change doesn't have a clear positive or negative impact on 
SACM but does have the potential for benefit outside of SACM, also a 
good reason.

--gun

On 3/26/2013 6:10 PM, Adam Montville wrote:
> model sort of like the one in the current Asset Identification draft.
>   The way the Asset Identification draft is worded relegates it for use
> only for the purpose of identification.  I'd like to split the Asset
> Identification draft into at least two separate documents, where one
> specifies the asset model and the other which builds on the first for
> the purpose of asset identification.
>
> I think such a split is advantageous in a couple of ways, but the one
> that stands out is having the ability to align/absorb with other efforts
> more easily.
>
> Thoughts?
>
> Adam
>
>
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 27 Mar 2013 17:44:25 +0000

>having to use two documents?

I don't know if "simple" is the axis we want to look at.  Useful may be a
better axis.

Then again, we're scoped to UC1, right, which is just endpoint posture
assessment, which makes arguing for a split *now* a difficult one.

>would be used without also needing the dependent asset identification

I'll answer this one with a question of my own: Is there any reason to
target a class of non-IT asset?  Say, target a class of human (I.e. those
fulfilling a particular role) or a class of data (I.e. cardholder data)...

I'm not sure we have a way to do this today, but, I'm also not sure of the
explicit need, let alone the need within SACM right now.

>SACM but does have the potential for benefit outside of SACM, also a

It might be a better idea to look at this in terms of harm rather than
good.  

What harm is there in splitting these apart?

It's a real question, not a rhetorical one.  Though making things more
modular seems useful on the surface.

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 27 Mar 2013 15:20:50 -0400

> I don't know if "simple" is the axis we want to look at.  Useful may be a

What it sounded like to me is that your proposal *would* increase 
utility without increasing complexity, and my questions were intended as 
an opportunity to confirm that.

But, in general, I think we need to keep a firm on simplicity.  If 
things are too complex they won't get implemented properly or won't be 
used at all.

> assessment, which makes arguing for a split *now* a difficult one.

If there's going to be a split it would be much better to do it sooner 
over later, so it's great that you brought this up now.

> explicit need, let alone the need within SACM right now.

Absolutely.  Human beings (or their roles), facilities, training 
policies, etc, aren't explicitly referenced, but they are very much part 
of the landscape.  If nothing else, the recent proposed additions to 
OCIL for enterprise support obviates this.

> modular seems useful on the surface.

The only possible harm I can see as a maybe is if splitting these makes 
it more difficult for a future newcomer to determine all the 
relationships necessary for implementation.  But then I also expect a 
document that details all the documents.

Which is to say, I'm not seeing a downside here.  But that's just me.

---

From: Adam Montville <[email-masked]>
Date: Wed, 27 Mar 2013 21:55:28 +0000

Thanks for the clarification, Gunnar.

I agree in that I don't see much of a downside here.

Any other comments?