Subject: [sacm] Use Cases: Asset Management

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 27 Aug 2013 18:00:21 +0000

Last week I posted the WG draft version of the use cases document (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes since the -05 version are listing in the change log within the document (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8).

What I'd like to do next is focus the WGs attention on individual sections of the use case document for a week or two each to work on wrapping up the text and to develop overall consensus. Starting this week I would like to focus on section 4.1 Asset Management (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1). My hope is that this approach will lead us through development of the document before the next draft submission deadline.

Based on the current text I have the following questions:

1)      Is the current structure of this section acceptable? If not, what should be done differently?

2)      Are there key terms that should be defined in the terminology draft? If so, what terms and what definition should be used?

3)      We currently have the following sub-sections that represent different lifecycle aspects related to Asset Management. Are these the best way to break up asset management into discrete use cases?

a.       Asset Discovery

b.      Asset Identification

c.       Endpoint Components and Asset Composition

d.      Asset Characterization

e.      Asset Resources

f.        Asset Representation Reconciliation

g.       Asset Life Cycle

4)      Do you agree with the current text in each sub-section?  If not, why not? Do you have alternate text to contribute?

5)      Here are a few questions regarding some of the sub-sections:

a.       Asset Characterization - Are there other important characteristics to list?

b.      Asset Resources - Should this be addressed under asset management or under data collection in a different section? Is the human- vs. machine-collected distinction important here?

c.       Asset Representation Reconciliation - We need text to flesh this section out. Any volunteers?

d.      Asset Life Cycle - Is this section needed? If so, what do we want to say? Any volunteers willing to contribute text?

6)      Do you have any other general comments/questions on this section?

Please let me know your thoughts on these questions.  I'll make edits to the document as we agree on any changes that should be made.

Sincerely,
Dave

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 28 Aug 2013 14:00:56 -0400

4.1.1 Asset Discovery, first paragraph:  "alowing" could use another l.

Now that you mention it, I found myself wondering of asset management is 
really a SCAM use case.  Certainly the needs of SACM intersect with 
asset management, but is it really one of the goals of SACM that we 
produce standards for creating an asset management system?

On 8/27/2013 2:00 PM, Waltermire, David A. wrote:
> Last week I posted the WG draft version of the use cases document
> (http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases/). Changes
> since the -05 version are listing in the change log within the document
> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-8).
>
> What I’d like to do next is focus the WGs attention on individual
> sections of the use case document for a week or two each to work on
> wrapping up the text and to develop overall consensus. Starting this
> week I would like to focus on section 4.1 Asset Management
> (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1).
> My hope is that this approach will lead us through development of the
> document before the next draft submission deadline.
>
> 1)Is the current structure of this section acceptable? If not, what
> should be done differently?
>
> 2)Are there key terms that should be defined in the terminology draft?
> If so, what terms and what definition should be used?
>
> 3)We currently have the following sub-sections that represent different
> lifecycle aspects related to Asset Management. Are these the best way to
> break up asset management into discrete use cases?
>
> a.Asset Discovery
>
> b.Asset Identification
>
> c.Endpoint Components and Asset Composition
>
> d.Asset Characterization
>
> e.Asset Resources
>
> f.Asset Representation Reconciliation
>
> g.Asset Life Cycle
>
> 4)Do you agree with the current text in each sub-section?  If not, why
> not? Do you have alternate text to contribute?
>
> 5)Here are a few questions regarding some of the sub-sections:
>
> a.Asset Characterization – Are there other important characteristics to
> list?
>
> b.Asset Resources – Should this be addressed under asset management or
> under data collection in a different section? Is the human- vs.
> machine-collected distinction important here?
>
> c.Asset Representation Reconciliation – We need text to flesh this
> section out. Any volunteers?
>
> d.Asset Life Cycle – Is this section needed? If so, what do we want to
> say? Any volunteers willing to contribute text?
>
> 6)Do you have any other general comments/questions on this section?
>
> Please let me know your thoughts on these questions.  I’ll make edits to
> the document as we agree on any changes that should be made.
>
> Sincerely,
>
> Dave
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 28 Aug 2013 20:27:39 +0200

Information about assets provides the link/relationship between 
monitoring techniques, services, vulnerabilities, etc. While Asset 
Management is indeed a quite general term, it incorperates the 
acquisition and provision of asset information which is an important 
prerequisite in sacm, I think.

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 28 Aug 2013 14:50:20 -0400

Yes, the needs of SACM intersect with the realm of asset management. 
But, again, is standardizing asset management really a use case for SACM?

Putting it another way, is it reasonable to think that somebody would 
deploy a SACM system for the sole purpose of doing asset management?

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 28 Aug 2013 20:33:45 +0000

Gunnar,

Are you suggesting that we remove the asset management section from the use case draft? If not, what would you change?

More comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gunnar Engelbach
> Sent: Wednesday, August 28, 2013 2:50 PM
> To: Henk Birkholz
> Cc: [email-masked]
> Subject: Re: [sacm] Use Cases: Asset Management
> 
> 

Agreed. We need to focus use cases around this intersection.

> But, again, is standardizing asset management really a use case for SACM?

Strictly speaking, I would say no. But some aspects like asset discovery (identifying new endpoints that join a network), asset identification (relating collected data to assets), and asset representation reconciliation (sorting out different identification approaches) are aspects that we need to deal with as a matter of the SACM scope. Asset characterization is a bit more nuanced. I believe at minimum we need some capability to get data about an asset that sets an expectation of its intended posture. For example, we need to know something about what the intended function of the device is to understand how to evaluate its posture.

> Putting it another way, is it reasonable to think that somebody would deploy
> a SACM system for the sole purpose of doing asset management?

Possibly, but not likely. If we address asset discovery, which I believe we should, this capability could be used standalone without any further data collection. 

> >>> What I'd like to do next is focus the WGs attention on individual
> >>> a.Asset Characterization - Are there other important characteristics to
> >>> list?
> >>>
> >>> b.Asset Resources - Should this be addressed under asset management
> or
> >>> c.Asset Representation Reconciliation - We need text to flesh this
> >>> d.Asset Life Cycle - Is this section needed? If so, what do we want to
> >>> Please let me know your thoughts on these questions.  I'll make edits to

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 28 Aug 2013 18:11:19 -0400

I find the term "security automation" overly broad.
Personally I would have much preferred that the WG scope had been
dramatically smaller and  more focused.
But our charter includes asset management.
Given that that is what we have as a scope, then the intersection between
security management and asset management seems in scope.

>From an automated security management viewpoint, detecting that new nodes
(possibly unauthorized) have appeared in the network would appear to be
something important to automate for security purposes.
Being able to understand the asset components, resources, services and so
on, are important because they can impact the security of the asset and of
the network in which the asset operates.
Of course, I come from a network management background, and I think asset
management intersects with network management.
I think security management intersects with network management, for a number
of aspects including asset management.
I would like to see this WG not try to re-invent network management or asset
management because there happens to be some overlap with security
management.

David Harrington
[email-masked]
+1-603-828-1401
> Putting it another way, is it reasonable to think that somebody would
deploy

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 29 Aug 2013 12:43:52 +0200

Another specific part of asset management as a requirement for SACM is 
the differentiation between live-cycle related changes and error related 
changes in the infrastructure, I think.

Simple example: availability monitoring shows/raises a down-condition 
for a network endpoint. If the endpoint was removed due to the end of 
its live-cycle, this indicates a missing adaption of the monitoring 
configuration and an invalid alarm. Other reasons might result in a 
valid alarm.

This scenario is strongly related with the whole asset 
management/live-cycle process and would need a corresponding use case to 
present the required context, correct?

I agree with the opinion that nobody would deploy a SACM system for the 
sole purpose of doing asset management, and presenting asset management 
as a use case might be misleading somehow. Maybe the purpose of section 
4.1 as a use case is still too fuzzy? Or a more specific section/use 
case title could help? Essentially, if all requirements must be based on 
a corresponding use case (is that the case?), something appropriate is 
needed in section 4.

On 08/29/2013 04:47 AM, Gunnar Engelbach wrote:
>
>
> On 8/28/2013 4:33 PM, Waltermire, David A. wrote:
>> Gunnar,
>>
>> Are you suggesting that we remove the asset management section from
>> the use case draft? If not, what would you change?
>
>
>
> Yes.  I'm suggesting that, for SACM, asset management is not a use case,
> but certain parts of asset management are requirements for SACM.
> Specifically:
>
> 1) We need a taxonomy for determining what assessment content applies to
> an endpoint
>
> 2) We need to be able to identify a particular asset when communicating
> between SACM nodes
>
> 3) We need to be able to generate a list of endpoints to perform an
> assessment against -- call that discovery*
>
> And for the assessment model that is driven by change event notification
> pushed from endpoints, discovery is not needed.
>
>
> Fleshing out all the requirements so that a SACM installation can be
> used as an asset management system seems to go well beyond what is
> needed.  Given the near-ubiquity of existing asset management systems I
> think we should be more interested in interacting with those than trying
> to invent another one.
>
>
> Now, with all of that said, there are going to be cases where a SACM
> installation needs to include it's own asset management system. Allowing
> for that possibility, is it within scope of this working group to also
> define what that looks like, or can we take it as a given that such
> things exist?  I'd say that the furthest we want to go is to define our
> own standardized way for interacting with an asset management system
> that is just enough to fulfill the needs of SACM.
>
>
>
>
> * Discovery in this case is extremely broad.  It could be via manual
> user interaction, enumeration of an LDAP/AD server, event notification
> from a NAC system or DHCP server, ringing out a network, querying an
> asset management system, enumeration of live targets via IPv6
> properties, and on and on.
>
>
>>
>> More comments below.
>>
>> Strictly speaking, I would say no. But some aspects like asset
>> discovery (identifying new endpoints that join a network), asset
>> identification (relating collected data to assets), and asset
>> representation reconciliation (sorting out different identification
>> approaches) are aspects that we need to deal with as a matter of the
>> SACM scope. Asset characterization is a bit more nuanced. I believe at
>> minimum we need some capability to get data about an asset that sets
>> an expectation of its intended posture. For example, we need to know
>> something about what the intended function of the device is to
>> understand how to evaluate its posture.
>>
>> Possibly, but not likely. If we address asset discovery, which I
>> believe we should, this capability could be used standalone without
>> any further data collection.
>>
>>>
>>>
>>>
>>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 29 Aug 2013 11:17:04 -0400

So, you'd like to use a SACM implementation to monitor liveness of 
network endpoints?

Even if a SACM implementation included an asset management capability, I 
think it's not going to be ideal for performing this kind of function. 
You'd be better served using a network monitoring system that is built 
specifically for that purpose.

On 8/29/2013 6:43 AM, Henk Birkholz wrote:
>>>>>>> lifecycle aspects related to Asset Management. Are these the best
>>>>>>> way
>>>> to

---

From: "Aaron Woland (aawoland)" <[email-masked]>
Date: Thu, 29 Aug 2013 15:24:48 +0000

All,

Maybe I am way off on this, but I interpret this as SACM should provide a
way to communicate information about the endpoint liveliness from a
network monitoring tool to a security tool, but that sacm should not be a
tool that is monitoring this activity itself.

Am I off base?

Aaron

-- 
Regards,

Aaron T. Woland, CCIE #20113
Secure Access TME, SAMPG ciscoSystems, Inc.
Check out my Secure Network Access Blog
<http://www.networkworld.com/community/blog/26151> at Network World
Author:  Cisco ISE for BYOD and Secure Unified Access
<http://click.linksynergy.com/fs-bin/click?id=176dglGj6oU&offerid=145238.10
000263&type=1&subid=0>

On 8/29/13 11:17 AM, "Gunnar Engelbach" <[email-masked]>
wrote:

>>>>>>> Now that you mention it, I found myself wondering of asset
>>>>>>>management
>>>>> is

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 29 Aug 2013 18:12:27 +0200

Please excuse my brevity regarding the scenario example. Actual 
monitoring of liveness should be done with systems/senors built 
specifically for that purpose, of course.

I was thinking more in the direction of supporting (and in some places 
partially automating) the configuration of monitoring systems, SIEM 
systems and such. Asset information derived from existing infrastructure 
(e.g. via asset discovery or existing meta-directories) that is 
aggregated in a Content Repository could be used as a basis to generate 
corresponding configuration for these system.

SACM is a core mechanism to automatically distribute security-related 
metadata in order to enhance the awareness over the state of the 
infrastructure. Hence, some kind of asset management related information 
should be included, I think.

I understand the drawbacks of maybe bloating the scope of SACM with 
"things that are already there", but separating asset management and 
security automation seems to be even worse. This typical separation and 
reliance on asset management implementations that should already be 
there is maybe one of the significant problems SACM could really improve.

Also, I think the term asset management is still a bit fuzzy at the 
moment, and it might be confusing if presented as a use case.

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 29 Aug 2013 12:38:50 -0400

Sorry that I wasn't grasping your example.

Yes, some data collected in the process of doing security assessments 
would be useful to an asset management system, liveness being just one 
example.

When I suggested that we focus more on the ability to interact with 
existing asset management systems, that would be a two-way interaction.

Because of the diversity of asset management systems and their 
capabilities I don't see this as being a "MUST" requirement, but a "MAY."

A sentence or two can be added to many of the existing use cases 
describing this.

The question this brings up for me is:  do we leave it up to vendors to 
work out how to talk to asset management systems, or do we try to define 
a standard for that?