Subject: Re: [sacm] Use Cases: Asset Management

From: Henk Birkholz <[email-masked]>
Date: Tue, 3 Sep 2013 14:23:14 +0200

Personally, I think this a good idea and I am very interested in the 
general opinion about this. Especially if this should or should not be 
in the scope of SACM.

On 08/29/2013 06:38 PM, Gunnar Engelbach wrote:
>
> 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?
>
>
>
> On 8/29/2013 12:12 PM, Henk Birkholz wrote:
>> 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.
>>
>> On 08/29/2013 05:17 PM, Gunnar Engelbach wrote:
>>>
>>>
>>> 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:
>>>> 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.
>>>>>>
>>>>>>> -----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
>>>>>>>
>>>>>>>
>>>>>>> Yes, the needs of SACM intersect with the realm of 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.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/28/2013 2:27 PM, Henk Birkholz wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> On 08/28/2013 08:00 PM, Gunnar Engelbach wrote:
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> sacm mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> sacm mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sacm mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>>>> _______________________________________________
>>>>>>> sacm mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>>
>>

---

From: Adam Montville <[email-masked]>
Date: Tue, 3 Sep 2013 14:24:06 +0000

This is a really good discussion to be having.  

Asset Management, as with many of the other terms we deal with, is a label that can have many different meanings depending on context.  The metadata needs associated with an asset will similarly change from context to context.  Security use cases will undoubtedly need many of the same data about an asset that an "asset management system" proper will need.  It will also, perhaps, need more.   There is definitely an interplay between disciplines here, and the sooner we recognize this and move forward knowing it, the better off we'll be.

The bottom line here is that what we are working on needs to interact with asset management systems of today, possibly influence their capabilities, or (where such influence is impossible) pick up the resulting slack.

Adam

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henk Birkholz
> Sent: Tuesday, September 03, 2013 5:24 AM
> To: Gunnar Engelbach
> Cc: Waltermire, David A.; [email-masked]
> Personally, I think this a good idea and I am very interested in the general
> opinion about this. Especially if this should or should not be in the scope of
> SACM.
> 
> > 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?
> >
> >
> >
> >> 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.
> >>
> >> infrastructure. Hence, some kind of asset management related
> >> information should be included, I think.
> >>
> >> 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.
> >>
> >>> 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.
> >>>
> >>>
> >>>
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>>>> Are you suggesting that we remove the asset management section
> >>>>>> from the use case draft? If not, what would you change?
> >>>>>
> >>>>>
> >>>>>
> >>>>> case, but certain parts of asset management are requirements for
> >>>>> SACM.
> >>>>> Specifically:
> >>>>>
> >>>>> applies to an endpoint
> >>>>> communicating between SACM nodes
> >>>>>
> >>>>> 3) We need to be able to generate a list of endpoints to perform
> >>>>> an assessment against -- call that discovery*
> >>>>>
> >>>>> 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.
> >>>>>>
> >>>>>>> Behalf Of Gunnar Engelbach
> >>>>>>> But, again, is standardizing asset management really a use case
> >>>>>>> for SACM?
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>>> would deploy a SACM system for the sole purpose of doing asset
> >>>>>>> management?
> >>>>>>
> >>>>>> believe we should, this capability could be used standalone
> >>>>>> without any further data collection.
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> 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.
> >>>>>>>>
> >>>>>>>>> with asset management, but is it really one of the goals of
> >>>>>>>>> SACM that we produce standards for creating an asset
> >>>>>>>>> management system?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>> 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
> >>>>>>>>>> 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?
> >>>>>>>>>> different lifecycle aspects related to Asset Management. Are
> >>>>>>>>>> these the best way
> >>>>>>> to
> >>>>>>>>>> not, why not? Do you have alternate text to contribute?
> >>>>>>>>>>
> >>>>>>>>>> characteristics to list?
> >>>>>>>>>> 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?
> >>>>>>>>>>
> >>>>>>>>>> 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: "Waltermire, David A." <[email-masked]>
Date: Tue, 3 Sep 2013 14:24:06 +0000

Good.  It appears like there is some agreement on the role of SACM specifications providing data to and getting data from asset management tools. Since we are at the use case stage, we should not be focused on what specifications we are going to create. Instead, we should be identifying what asset data (both human and machine oriented) is critical to SACM as an input to data collection and assessment, and what data can be provided to asset management tools based on the data collected from endpoints.

I'd like to bring this back to the text of the use cases document and my original questions on the asset management section (http://tools.ietf.org/html/draft-ietf-sacm-use-cases-00#section-4.1).

Based on the current text I still 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. Any text contributions/changes are encouraged and appreciated. I'll make edits to the document as we get some agreement on any changes that should be made.

Thanks,
Dave

> From: Henk Birkholz [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 8:23 AM
> To: Gunnar Engelbach

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 3 Sep 2013 15:10:04 +0000

+1.

This is the aspect that I find most compelling about the SACM work. We are providing a consolidated, standardized approach for endpoint data collection that can be used by multiple security and operational consumers at the same time to support different business processes. The same discussion we are having about the relationships to asset management also apply to configuration, vulnerability, license, and change management and many other areas. It would be nice to not revisit this discussion for each area. ;-)

The key to me is asking two questions for any given data domain:

1) Inputs: What data, both human- and machine-sourced, does a SACM-based solution need from other disciplines to collect and assess a specific aspect of endpoint posture?
2) Outputs: What data can SACM provide to other disciplines as an aspect of data collection and assessment?

IMHO, data interplay is a significant aspect of continuous monitoring that we are addressing in our current work through answering these questions. The key to getting through the use case draft development is to focus on what data is needed instead of what format or how it is exchanged. Formats and transports can be identified and developed at the appropriate time in the future.

Dave

> From: Adam Montville [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 10:24 AM
> To: Henk Birkholz; Gunnar Engelbach
> Subject: RE: [sacm] Use Cases: Asset Management
> 
> Asset Management, as with many of the other terms we deal with, is a label
> that can have many different meanings depending on context.  The
> metadata needs associated with an asset will similarly change from context
> to context.  Security use cases will undoubtedly need many of the same data
> about an asset that an "asset management system" proper will need.  It will
> also, perhaps, need more.   There is definitely an interplay between
> disciplines here, and the sooner we recognize this and move forward
> knowing it, the better off we'll be.
> 
> The bottom line here is that what we are working on needs to interact with
> asset management systems of today, possibly influence their capabilities, or
> (where such influence is impossible) pick up the resulting slack.
> 
> Adam
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Henk Birkholz
> > > Yes, some data collected in the process of doing security
> > > assessments would be useful to an asset management system, liveness
> > > being just one example.
> > >
> > >> 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.
> > >>
> > >> "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.
> > >>
> > >>>> 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.
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>> 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
> > >>>> 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.
> > >>>>
> > >>>>
> > >>>>> 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:
> > >>>>>
> > >>>>> Fleshing out all the requirements so that a SACM installation
> > >>>>> can be used as an asset management system seems to go well
> > >>>>> beyond
> > what
> > >>>>> 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.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> network, querying an asset management system, enumeration of
> > >>>>> live targets via IPv6 properties, and on and on.
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> More comments below.
> > >>>>>>
> > >>>>>>> But, again, is standardizing asset management really a use
> > >>>>>>> case for SACM?
> > >>>>>>
> > >>>>>> 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
> > >>>>>>>> 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.
> > >>>>>>>>
> > >>>>>>>>> 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?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> 3)We currently have the following sub-sections that
> > >>>>>>>>>> represent different lifecycle aspects related to Asset
> > >>>>>>>>>> Management. Are these the best way
> > >>>>>>> to
> > >>>>>>>>>> 4)Do you agree with the current text in each sub-section?
> > >>>>>>>>>> If not, why not? Do you have alternate text to contribute?
> > >>>>>>>>>>
> > >>>>>>>>>> c.Asset Representation Reconciliation - We need text to
> > >>>>>>>>>> flesh this section out. Any volunteers?
> > >>>>>>>>>>
> This message and attachments may contain confidential information. If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited. Please notify the sender immediately and permanently
> delete the message and any attachments.
> 
> . . .

---

From: "Whitlock, Stephen" <[email-masked]>
Date: Tue, 3 Sep 2013 15:25:35 +0000

+1 for Dave's summation below.

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Tuesday, September 03, 2013 8:10 AM
To: Adam Montville; Henk Birkholz; Gunnar Engelbach
Cc: [email-masked]
Subject: Re: [sacm] Use Cases: Asset Management

+1.

Dave

> Asset Management, as with many of the other terms we deal with, is a 
> label that can have many different meanings depending on context.  The 
> metadata needs associated with an asset will similarly change from 
> context to context.  Security use cases will undoubtedly need many of 
> the same data about an asset that an "asset management system" proper will need.  It will
> The bottom line here is that what we are working on needs to interact 
> with asset management systems of today, possibly influence their 
> capabilities, or (where such influence is impossible) pick up the resulting slack.
> 
> Adam
> 
> > general opinion about this. Especially if this should or should not 
> > be in the scope of SACM.
> >
> > > 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.
> > >
> > > 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?
> > >
> > >
> > >
> > >> meta-directories) that is aggregated in a Content Repository 
> > >> could be used as a basis to generate corresponding configuration 
> > >> for these
> system.
> > >>
> > >> 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.
> > >>
> > >>> So, you'd like to use a SACM implementation to monitor liveness 
> > >>> of network endpoints?
> > >>>
> > >>>> management/live-cycle process and would need a corresponding 
> > >>>> use case to present the required context, correct?
> > >>>>
> > >>>>>> Are you suggesting that we remove the asset management 
> > >>>>>> section from the use case draft? If not, what would you change?
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> use case, but certain parts of asset management are 
> > >>>>> requirements for SACM.
> > >>>>> Specifically:
> > >>>>>
> > >>>>> 3) We need to be able to generate a list of endpoints to 
> > >>>>> perform an assessment against -- call that discovery*
> > >>>>>
> > >>>>> 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
> > >>>>> 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.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 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
> > >>>>>> 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.
> > >>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>> 4.1.1 Asset Discovery, first paragraph:  "alowing" could 
> > >>>>>>>>> use another l.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> intersect with asset management, but is it really one of 
> > >>>>>>>>> the goals of SACM that we produce standards for creating 
> > >>>>>>>>> an asset management system?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> since the -05 version are listing in the change log 
> > >>>>>>>>>> within the document
> > >>>>>>>>>> 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
> > >>>>>>>>>> d.Asset Life Cycle - Is this section needed? If so, what 
> > >>>>>>>>>> do we want to say? Any volunteers willing to contribute text?
> > >>>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> This message and attachments may contain confidential information. If 
> it appears that this message was sent to you by mistake, any 
> retention, dissemination, distribution or copying of this message and 
> attachments is strictly prohibited. Please notify the sender 
> immediately and permanently delete the message and any attachments.
> 
> . . .

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 03 Sep 2013 13:36:00 -0400

To be clear, I completely agree that the needs of SACM include a subset 
of asset management.  What that intersection is needs to be defined as 
clearly as we can -- I just don't think the Use Cases document is the 
place for that, and certainly not under a use case that makes it sound 
like a SACM installation can be set up for the purpose of doing just 
asset management.

Stated more simply:  Asset Management is not a SACM use case.

 From my experience the intersection between asset management and 
security management exists to fulfill three needs:

1) Getting the complete and correct content from the Content Repository
2) Positively correlation of assets when communicating
3) Targeting assets for assessment

In a more direct response to Dave's question number one below, I like to 
break the data out into three categories for each asset:

1) Attributes
2) Role(s)
3) Relationships

The role determine things like which regulations apply, MAC (Mission 
Assurance Category), classification level, CIA (Confidentiality, 
Integrity, Availability) values, etc.

Relationships is information such as asset owner, data owner, physical 
location, network location, VM host, administrative contact, etc.

I don't expect to have much success in trying to create anything like a 
definitive list for any of these.  I'd rather start by recognizing that 
I can't be definitive up front and make it a requirement that the data 
format make the best attempt at allowing for that.

Likewise for question number two.  The output data can be any item 
collected from an asset in the process of evaluation, derived data such 
as time of collection, which benchmarks were found to apply, 
per-benchmark or per-rule score, whether or not the collection attempt 
was successful, and so on.  How much of this is meaningful or can even 
be inserted into an asset management system will vary widely from system 
to system.  We can try to devise a protocol that is flexible enough to 
handle a wide variety of data types but I don't think we stand a chance 
of trying to define what those data items are.

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 3 Sep 2013 20:39:38 +0000

Comments below.

> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 1:36 PM
> To: Waltermire, David A.
> Cc: Adam Montville; Henk Birkholz; [email-masked]
> To be clear, I completely agree that the needs of SACM include a subset of
> asset management.  What that intersection is needs to be defined as clearly
> as we can -- I just don't think the Use Cases document is the place for that,

My understanding of the use cases document is to inform areas of work for SACM. We are constraining the inclusion of use cases to be within or directly related to the current charter scope. The use cases are intended to inform the definition of requirements; both the use cases and requirements are intended to inform architectural proposals. If this is true and we don't define how SACM relates to asset management (or any other domain) in the use cases document, where do we define the relationship?

> and certainly not under a use case that makes it sound like a SACM
> installation can be set up for the purpose of doing just asset management.

If SACM supports some aspects of asset management, what is the harm in that? To say it a different way, if an asset management product vendor wants to use SACM capabilities as part of their asset management solution, why can't they? This doesn't stop any other vendor from using SACM capabilities for configuration or vulnerability management or anything else for which they find the specifications useful. I don't see a problem here.

> Stated more simply:  Asset Management is not a SACM use case.

I agree that SACM is not going to provide a complete asset management solution. That being said, it is clear that SACM can be part of an asset management solution. In my mind, correct me if I am completely off base, the following are SACM use cases:
- Detecting the presence of an endpoint on a network by way of that endpoint reporting something about its posture.
- Identifying an endpoint using network addressing and endpoint artifacts (e.g., device ids, hw/sw certs, CPU ids) as part of data collection.
- Collecting the hardware and software inventory of an endpoint.

These use cases, among others, can all be part of a future asset management solution. Most of this also supports other data domains, allowing data collection to serve multiple perspectives.

> 1) Getting the complete and correct content from the Content Repository

This is not captured under the asset management section.  Should it?  If so, what should we say?

> 2) Positively correlation of assets when communicating

This is section 4.1.6 and it needs to be fleshed out.  Anyone have any suggested text?

> 3) Targeting assets for assessment

Is this targeting of assessments based on asset characterizations and current posture? If so, this is not captured under the asset management section.  Should it be?  If so, what should we say?

I would add:

4) Identifying (and potentially provisioning or having a role in provisioning) new endpoints for management.

This is under section 4.1.2. The part about provisioning is not mentioned.

5) Collecting hardware and software inventory data for hardware/software asset management.

Collecting general posture information fits somewhat under section 4.1.5. This section needs some organization. Any suggestions?

> Assurance Category), classification level, CIA (Confidentiality, Integrity,
> Availability) values, etc.
>

Attributes, roles and relationships align with section 4.1.4. We don't explicitly call out the concept of relationships which I will add.

> format make the best attempt at allowing for that.

This is a good point.  I'll add a sentence about this.

> of trying to define what those data items are.

Good points, but we might be able to provide a flexible data model with some focus on basic primitives (e.g., hardware and software inventory, configurations, etc.) One important thing here is that assessment will likely need to be an optional step in feeding data to another system. There is nothing to stop an asset management system from directly requesting data to be collected, subscribing to some data channel, or getting data using some other mechanism without prior assessment.

> > This is the aspect that I find most compelling about the SACM work. We are
> providing a consolidated, standardized approach for endpoint data collection
> that can be used by multiple security and operational consumers at the same
> time to support different business processes. The same discussion we are
> having about the relationships to asset management also apply to
> configuration, vulnerability, license, and change management and many
> other areas. It would be nice to not revisit this discussion for each area. ;-)
> >
> > 1) Inputs: What data, both human- and machine-sourced, does a SACM-
> based solution need from other disciplines to collect and assess a specific
> aspect of endpoint posture?
> > IMHO, data interplay is a significant aspect of continuous monitoring that
> we are addressing in our current work through answering these questions.
> The key to getting through the use case draft development is to focus on
> what data is needed instead of what format or how it is exchanged. Formats
> and transports can be identified and developed at the appropriate time in
> the future.
> >
> > Dave
> >
> label
> context
> Behalf
> use
> section
> requirements
> event

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 03 Sep 2013 19:02:02 -0400

> Comments below.

And more below that.

> My understanding of the use cases document is to inform areas of work for SACM. We are constraining the inclusion of use cases to be within or directly related to the current charter scope. The use…

By having a section 4.1 Asset Management what you are saying is that one 
of the intended uses for a SACM deployment is for asset management.

Asset Management systems have needs that fall outside the scope of 
security automation.  We shouldn't be trying to reinvent that.

There is, however, and intersection between security automation and some 
asset management needs.  These are visible from the existing use cases. 
  But if that's not explicit enough a few sentences added to the 
existing use cases here and there can make that more obvious.

The example in 4.4.1, for instance, says "The analyst looks up the 
endpoint in the asset inventory database."  So, asset discovery is done 
manually in this case, using some inventory database which could be 
completely unrelated to the SACM implementation.

 From the very first paragraph of the Use Cases document:

"From these operational use cases, we can derive common functional 
capabilities and requirements..."

Using a SACM deployment as an asset management system is not, in my 
opinion, an "operational use case," but certain items related to asset 
management are SACM requirements, as are apparent from other use cases.

Or have I completely misunderstood the purpose of the use case document? 
  Which is entirely possible.

> If SACM supports some aspects of asset management, what is the harm in that? To say it a different way, if an asset management product vendor wants to use SACM capabilities as part of their asset m…

Absolutely, if a particular SACM implementation contains enough 
functionality that somebody also wants to use it as their asset 
management system, that's perfectly fine.  But it's not a use case.  I 
can also use ping and a notebook to do some level of asset management.

It's also possible (or should be) to deploy a SACM implementation that 
has no asset management capability of its own.  For example, if I wanted 
to go for the easiest implementation with the broadest market, I'd 
create a Windows-centric system where all of the asset management was 
done using the existing AD server.

> These use cases, among others, can all be part of a future asset management solution. Most of this also supports other data domains, allowing data collection to serve multiple perspectives.

It's possible to quibble with these as written, but that would be 
avoiding the point.

Yes, SACM will be aware of and generating per-asset information that 
*could* be a good complement to asset management systems, or other data 
domains.

But saying that one use case for SACM is as an asset management system 
and then deriving requirements from that use case so that it can be used 
that way just doesn't make any sense.

> Collecting general posture information fits somewhat under section 4.1.5. This section needs some organization. Any suggestions?

#4 and #5 are good complements to an asset management system and should 
be possible to do with a SACM implementation.  But neither are necessary 
for SACM to fulfill its role.

#5 in particular:  SACM collects software and possibly hardware 
information for the purpose of doing automated security assessments. 
Some or all of this data could also be useful for asset management, but 
the reverse is not necessarily true (that SACM can collect all the data 
necessary for a particular asset management system).  Granted, I could 
write content for the purpose of doing a complete collection of asset 
management items, but that would no longer be security content.

> Good points, but we might be able to provide a flexible data model with some focus on basic primitives (e.g., hardware and software inventory, configurations, etc.) One important thing here is that…

This is a very good point.  I've been primarily concerned with what a 
SACM implementation will need in order to fulfill its role, but the 
capabilities a SACM implementation will provide could be useful for many 
other purposes.

With that said, however, is there any need to write that into the 
requirements?  The standards we produce will be available to anybody 
else that wants to make use of them.

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 03 Sep 2013 19:13:56 -0400

Actually, one of the things I think is getting me and I haven't been 
able to articulate yet is the organization of the document.

The only use cases I see in the document are 3.1, 4.4.1, and 4.4.2.

Section 4 is labeled "Use Cases," but the first use case is outside of 
that section and the majority of the text reads like terminology and 
requirements.

What if section 3 was labeled "Use Cases" and contained what is 
currently 3.1, 4.4.1, and 4.4.2, plus any other use cases.  Section 4 
could then be the prose description of the requirements, referring back 
to individual use cases in section 3 for elucidation.

That retains the existing text, which is all good, and keeps with Dave 
Harrington's desire to not repeat requirements after each use case.

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 03 Sep 2013 21:14:52 -0400

> able to articulate yet is the organization of the document.

++

This was my exact comment to the list last week, but I am beginning to
think no one saw it as I haven't seen a reply.  I thought I might have
been the only one to think that the "use cases" read more like a list of
capabilities required by SACM.  They would, in my mind, only be use
cases if these are things SACM can be used to do (i.e., use SACM to do
asset management), but I do not believe that is the case.

Joe

>> My understanding of the use cases document is to inform areas of work
>> for SACM. We are constraining the inclusion of use cases to be within
>> or directly related to the current charter scope. The use cases are
>> intended to inform the definition of requirements; both the use cases
>> and requirements are intended to inform architectural proposals. If
>> this is true and we don't define how SACM relates to asset management
>> (or any other domain) in the use cases document, where do we define
>> the relationship?
>>
>> If SACM supports some aspects of asset management, what is the harm in
>> that? To say it a different way, if an asset management product vendor
>> wants to use SACM capabilities as part of their asset management
>> solution, why can't they? This doesn't stop any other vendor from
>> using SACM capabilities for configuration or vulnerability management
>> or anything else for which they find the specifications useful. I
>> don't see a problem here.
>>
>> I agree that SACM is not going to provide a complete asset management
>> solution. That being said, it is clear that SACM can be part of an
>> asset management solution. In my mind, correct me if I am completely
>> off base, the following are SACM use cases:
>> - Detecting the presence of an endpoint on a network by way of that
>> endpoint reporting something about its posture.
>> - Identifying an endpoint using network addressing and endpoint
>> artifacts (e.g., device ids, hw/sw certs, CPU ids) as part of data
>> collection.
>> These use cases, among others, can all be part of a future asset
>> management solution. Most of this also supports other data domains,
>> allowing data collection to serve multiple perspectives.
>>
>> Is this targeting of assessments based on asset characterizations and
>> current posture? If so, this is not captured under the asset
>> management section.  Should it be?  If so, what should we say?
>>
>> I would add:
>>
>> 4) Identifying (and potentially provisioning or having a role in
>> provisioning) new endpoints for management.
>>
>> Collecting general posture information fits somewhat under section
>> 4.1.5. This section needs some organization. Any suggestions?
>>
>> Attributes, roles and relationships align with section 4.1.4. We don't
>> explicitly call out the concept of relationships which I will add.
>>
>> Good points, but we might be able to provide a flexible data model
>> with some focus on basic primitives (e.g., hardware and software
>> inventory, configurations, etc.) One important thing here is that
>> assessment will likely need to be an optional step in feeding data to
>> another system. There is nothing to stop an asset management system
>> from directly requesting data to be collected, subscribing to some
>> data channel, or getting data using some other mechanism without prior
>> assessment.
>>
>>>
>>>
>>>
>>>> 2) Outputs: What data can SACM provide to other disciplines as an
>>>> aspect
>>> of data collection and assessment?
>>>>
>>>>> asset management systems of today, possibly influence their
>>>>> capabilities,
>>> or

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Adam Montville <[email-masked]>
Date: Fri, 6 Sep 2013 00:39:12 +0000

Dave Wrote:

I think there are too many sub-sections here, which is to say that I think we are probably crossing scope boundaries.

>From my perspective, an endpoint is an asset with network and composite contexts wrapped around it.  An endpoint is, at various points, reachable on some network.  An endpoint is, typically, a collection of tightly-coupled assets.  The base example is likely a desktop, server, laptop, or mobile device.  These things are composed of hardware and software assets, and are connected to a network at one point or another.

I'm also trying to keep in mind the two things our charter talks about (endpoint posture assessment and content repository interactions).

All that said...

Asset Identification and Characterization are important to our effort.  Ensuring that we can address the composite nature of assets is equally important, but I believe this to be inherent to Asset Characterization.

Asset Resources (described as a type of characterization) and Endpoint Components and Asset Composition (also described as a type of characterization) are redundant. 

I don't really understand the purpose of Asset Representation Reconciliation.  Does this mean translating the representation of assets between different domains?

Asset Life Cycle - we shouldn't be in this business.  We want to enable a secure asset management process, but we don't want to be the process.  

Finally, Asset Discovery...  I understand the need for discovery.  I'm not sure that we need to create the solution for it.  What I do believe is that we need to ensure that we can support what should happen when an asset is discovered and we are told about it.  So, when someone scripts an nmap scan and translates that into a format we speak, we should be able to do something with that data.  Similarly, if a sensor is created to mine DHCP requests or the DNS system, we should be able to receive data from that sensor.  We are not actively discovering assets, only using information provided by systems, which means that our Asset Identification and Asset Characterization methods need to be flexible enough to handle this.  

I guess this is all the way to say that I think the following would be sufficient use cases to flesh out as representative of our requirements:

1. Asset Identification
2. Asset Characterization

The others are either out of scope or redundant.

Adam

________________________________________
From: [email-masked] [[email-masked]] on behalf of Waltermire, David A. [[email-masked]]
Sent: Tuesday, September 03, 2013 7:24 AM
To: Henk Birkholz; Gunnar Engelbach
Cc: [email-masked]
Subject: Re: [sacm] Use Cases: Asset Management

Thanks,
Dave

...

. . .

---

From: Adam Montville <[email-masked]>
Date: Fri, 6 Sep 2013 01:57:42 +0000

> Waltermire, David A.
> Sent: Tuesday, September 03, 2013 7:25 AM
> Good.  It appears like there is some agreement on the role of SACM
> specifications providing data to and getting data from asset management
> tools. Since we are at the use case stage, we should not be focused on what
> specifications we are going to create. Instead, we should be identifying what
> asset data (both human and machine oriented) is critical to SACM as an input
> to data collection and assessment, and what data can be provided to asset
> management tools based on the data collected from endpoints.
> 
> I'd like to bring this back to the text of the use cases document and my
> original questions on the asset management section
> 2) Are there key terms that should be defined in the terminology draft? If so,
> what terms and what definition should be used?

Characteristic (in context of Asset Characteristics) - may be synonymous with attribute
System
Risk Management
Asset Information
Identifier (probably covered elsewhere, but we could reference)
Component (physical, logical)
Asset Management

> 3) We currently have the following sub-sections that represent different
> lifecycle aspects related to Asset Management. Are these the best way to

My previous note on this subject would keep only two: Asset Identification and Asset Characterization.

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

Asset Identification:

One sentence reads: "It is important to have stable mechanisms for identifying assets over time to allow asset information to be correlated."

I like stable, but I think we might want to consider unstable mechanisms as well.  If there's an unstable mechanism that exists, but it's a rich source of discovery information, for example, I'd prefer to be able to use that source now rather than wait for a stable representation to come about.  I might be misconstruing the use of the term "stable" though.

Also, there does not seem to be any mention of the different types of identification that we're going to have to consider.  Do I mean to identify all instances of Ubuntu 12 or *this particular* instance?  It may be warranted to negatively identify an asset - especially when reconciling discovered asset information against known asset information.

Asset Characterization:

Characteristic: a feature or quality belonging typically to a person, place, or thing and serving to identify it.  At least that's what Apple's dictionary (and Google's) says.  I think it's pretty close.  

I actually prefer the term "attribute": a quality or feature regarded as a characteristic or inherent part of someone or something.  An ontological description of "attribute" is: aspects, properties, features, characteristics, or parameters that objects (and classes) can have.

So, I think I'd be an advocate for trading "characteristic" for "attribute" as a start.

In the sentence, "This information is important to provide additional context for supporting management of assets using human and automated processes." I would strike "additional".

The -00 draft asks whether we need more examples.  I don't think so.  

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

Port(s) inbound/outbound

Assigned location for virtual devices (thinking of geographically dispersed data centers)

Specific asset classes will have different attributes we might want to list as well.  The network stack of an operating system will have IP addressing attributes, for example.

What is meant by the last item in the current list ("Location within network(s)")?  Network Addressing?

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

I don't believe the human/machine distinction is important here.

>     c. Asset Representation Reconciliation - We need text to flesh this section

I have to admit that I'm not quite sure what this is intended to mean.  I think I'm having trouble understanding what an "asset identification viewpoint" is.  Is that the viewpoint of a piece of software acting as an asset management system, the viewpoint of a system administrator, the viewpoint of an auditor, or perhaps the viewpoint of a different IETF area (i.e. apps)?  

The title might imply that we're talking about translating between domain-specific representations of an "asset."  

Can you clarify the intent of this section?

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

This section is not needed - reasons provided in a separate e-mail.

> Please let me know your thoughts on these questions. Any text
> contributions/changes are encouraged and appreciated. I'll make edits to the
> document as we get some agreement on any changes that should be made.
> 
> Thanks,
> Dave
> 
> 

. . .

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 05 Sep 2013 23:20:24 -0400

Adam, excellent.

I would add a number three to your list, though:  Asset Targeting.

Via some manner or another a list of one or more endpoints will be 
generated that are the target of the assessment, and getting that list 
into a SACM implementation is the start of the assessment process 
(ignoring for the moment the bottom-up event-driven model).

The details of what assets to target is a subset of Asset 
Identification, but will also need to include other information such as 
assessment type(s), allowance for network rate limiting, no-touch 
timespans, and so on.

On 9/5/2013 8:39 PM, Adam Montville wrote:
> This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
>
> . . .
>

---

From: Adam Montville <[email-masked]>
Date: Fri, 6 Sep 2013 13:56:24 +0000

> Sent: Thursday, September 05, 2013 8:20 PM
> To: Adam Montville
> Cc: Waltermire, David A.; Henk Birkholz; [email-masked]
> generated that are the target of the assessment, and getting that list into a
> SACM implementation is the start of the assessment process (ignoring for
> the moment the bottom-up event-driven model).
> 
> The details of what assets to target is a subset of Asset Identification, but will
> also need to include other information such as assessment type(s),
> allowance for network rate limiting, no-touch timespans, and so on.

I agree that targeted assets should be appropriately identified, and it seems like this is really a scoping issue when performing an assessment (whether ad hoc or based on recently collected information).

>From that perspective, targeting assets seems to be a use case better suited for endpoint assessment than it is for asset management.

> >  From my perspective, an endpoint is an asset with network and composite
> contexts wrapped around it.  An endpoint is, at various points, reachable on
> some network.  An endpoint is, typically, a collection of tightly-coupled
> assets.  The base example is likely a desktop, server, laptop, or mobile
> device.  These things are composed of hardware and software assets, and
> are connected to a network at one point or another.
> >
> > I'm also trying to keep in mind the two things our charter talks about
> (endpoint posture assessment and content repository interactions).
> >
> > All that said...
> >
> > Asset Identification and Characterization are important to our effort.
> Ensuring that we can address the composite nature of assets is equally
> important, but I believe this to be inherent to Asset Characterization.
> >
> > Asset Resources (described as a type of characterization) and Endpoint
> Components and Asset Composition (also described as a type of
> characterization) are redundant.
> >
> > I don't really understand the purpose of Asset Representation
> Reconciliation.  Does this mean translating the representation of assets
> between different domains?
> >
> > Asset Life Cycle - we shouldn't be in this business.  We want to enable a
> secure asset management process, but we don't want to be the process.
> >
> > Finally, Asset Discovery...  I understand the need for discovery.  I'm not
> sure that we need to create the solution for it.  What I do believe is that we
> need to ensure that we can support what should happen when an asset is
> discovered and we are told about it.  So, when someone scripts an nmap
> scan and translates that into a format we speak, we should be able to do
> something with that data.  Similarly, if a sensor is created to mine DHCP
> requests or the DNS system, we should be able to receive data from that
> sensor.  We are not actively discovering assets, only using information
> provided by systems, which means that our Asset Identification and Asset
> Characterization methods need to be flexible enough to handle this.
> >
> > I guess this is all the way to say that I think the following would be sufficient
> use cases to flesh out as representative of our requirements:
> >
> > 1. Asset Identification
> > From: [email-masked] [[email-masked]] on behalf of
> > Waltermire, David A. [[email-masked]]
> > 2) Are there key terms that should be defined in the terminology draft? If
> so, what terms and what definition should be used?
> >      b. Asset Resources - Should this be addressed under asset management
> or under data collection in a different section? Is the human- vs. machine-
> >      d. Asset Life Cycle - Is this section needed? If so, what do we want to

. . .

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 06 Sep 2013 13:16:08 -0400

>  From that perspective, targeting assets seems to be a use case better suited for endpoint assessment than it is for asset management.

Put that way, Asset Identification and Asset Characterization should 
also be under endpoint assessment use cases, not as a separate asset 
management use case.

There are certain things related to asset management that a SACM system 
needs to be able to do, but these are in service to the two items in the 
charter.

---

From: Chris Inacio <[email-masked]>
Date: Mon, 9 Sep 2013 03:26:37 +0000

I didn't give David's Use Case text a detailed reading (sorry Dave,) but reading through the comments and skimming the text I get the feeling that Dave's on the right track, and stating it from the wrong(?) point of view.

I think it should read something more along the lines of:

In order to establish an understanding of the security state of an organizational unit, the security system needs to be able to make use of various asset management data.  In order to correlate vulnerabilities present in the enterprise and assess the vulnerability impact, the "security system" (author: I have no idea what that is either) needs to be able to get hardware, software, ….

The security system may initiate an asset inquiry for updated asset information based on an alert from defensive monitoring systems or vulnerability bulletins, for example.  Such a request may be related to a new asset, requesting the asset management system to do a data refresh for an asset, or may instead ask for current information.

Then there are other things the security system might want to communicate with the asset management system, and we should cover those.

Does that capture the tension?  Does that make sense?

--
Chris Inacio
[email-masked]

On Sep 6, 2013, at 1:16 PM, Gunnar Engelbach <[email-masked]> wrote:

> Put that way, Asset Identification and Asset Characterization should also be under endpoint assessment use cases, not as a separate asset management use case.
> 
> There are certain things related to asset management that a SACM system needs to be able to do, but these are in service to the two items in the charter.
> 
> 
>> 
>> 
>> 
>>> 
>>> 
>>>

---

From: Adam Montville <[email-masked]>
Date: Mon, 9 Sep 2013 17:15:23 +0000

> Sent: Friday, September 06, 2013 10:16 AM
> To: Adam Montville

<snip>

> > I agree that targeted assets should be appropriately identified, and it
> seems like this is really a scoping issue when performing an assessment
> (whether ad hoc or based on recently collected information).
> >
> >  From that perspective, targeting assets seems to be a use case better
> suited for endpoint assessment than it is for asset management.
> 
> 
> Put that way, Asset Identification and Asset Characterization should also be
> under endpoint assessment use cases, not as a separate asset management
> use case.

I'm not sure I agree.  The reason I would promote these to a distinct set of use cases is because it transcends Endpoint Assessment.  As the WG progresses through the in-scope work of our current charter and as it (presumably) progresses through future work related to subsequent charters, appropriately identifying and characterizing assets will continue to be important.

Of course, this is all probably academic.  In my view, as long as the appropriate asset-related capabilities are captured, we're in good shape.  Whether they're promoted to a "higher level" of use case, or stuffed into Endpoint Assessment, really shouldn't matter that much.

. . .

---

From: Adam Montville <[email-masked]>
Date: Mon, 9 Sep 2013 17:19:44 +0000

> From: Chris Inacio [mailto:[email-masked]]
> Sent: Sunday, September 08, 2013 8:27 PM
> To: Gunnar Engelbach
> Cc: Adam Montville; Waltermire, David A.; [email-masked]; Henk Birkholz
> I didn't give David's Use Case text a detailed reading (sorry Dave,) but reading
> through the comments and skimming the text I get the feeling that Dave's on
> the right track, and stating it from the wrong(?) point of view.

What??  You didn't give it a through read!!??  ;-)

> In order to establish an understanding of the security state of an
> organizational unit, the security system needs to be able to make use of
> various asset management data.  In order to correlate vulnerabilities present
> in the enterprise and assess the vulnerability impact, the "security system"
> (author: I have no idea what that is either) needs to be able to get hardware,
> software, ....

I like the term "asset management data" in your sentence above.  It focuses attention on the fact that we are interested in the data, from a variety of sources and therefore in a variety of formats, relevant to a given asset rather than the process of managing said asset.

> 
> The security system may initiate an asset inquiry for updated asset
> information based on an alert from defensive monitoring systems or
> vulnerability bulletins, for example.  Such a request may be related to a new
> asset, requesting the asset management system to do a data refresh for an
> asset, or may instead ask for current information.
> 
> 
> 
> Then there are other things the security system might want to communicate
> with the asset management system, and we should cover those.

What are you thinking along these lines?

> On Sep 6, 2013, at 1:16 PM, Gunnar Engelbach
> <[email-masked]> wrote:
> 
> >
> >
> >>> generated that are the target of the assessment, and getting that
> >>> list into a SACM implementation is the start of the assessment
> >>> process (ignoring for the moment the bottom-up event-driven model).
> >>>
> >>> Identification, but will also need to include other information such
> >>> as assessment type(s), allowance for network rate limiting, no-touch
> timespans, and so on.
> >>
> >>> way to break up asset management into discrete use cases?
> >>>>      a. Asset Discovery
> >>>>      b. Asset Identification
> >>>> I think there are too many sub-sections here, which is to say that
> >>>> I think we
> >>> are probably crossing scope boundaries.
> >>>>
> >>> contexts wrapped around it.  An endpoint is, at various points,
> >>> reachable on some network.  An endpoint is, typically, a collection
> >>> of tightly-coupled assets.  The base example is likely a desktop,
> >>> server, laptop, or mobile device.  These things are composed of
> >>> hardware and software assets, and are connected to a network at one
> point or another.
> >>>>
> >>> Ensuring that we can address the composite nature of assets is
> >>> equally important, but I believe this to be inherent to Asset
> Characterization.
> >>>>
> >>> Reconciliation.  Does this mean translating the representation of
> >>> assets between different domains?
> >>>>
> >>> sure that we need to create the solution for it.  What I do believe
> >>> is that we need to ensure that we can support what should happen
> >>> when an asset is discovered and we are told about it.  So, when
> >>> someone scripts an nmap scan and translates that into a format we
> >>> speak, we should be able to do something with that data.  Similarly,
> >>> if a sensor is created to mine DHCP requests or the DNS system, we
> >>> should be able to receive data from that sensor.  We are not
> >>> actively discovering assets, only using information provided by
> >>> systems, which means that our Asset Identification and Asset
> >>> specifications providing data to and getting data from asset
> >>> management tools. Since we are at the use case stage, we should not
> >>> be focused on what specifications we are going to create. Instead,
> >>> we should be identifying what asset data (both human and machine
> >>> oriented) is critical to SACM as an input to data collection and
> >>> assessment, and what data can be provided to asset management tools
> based on the data collected from endpoints.
> >>>>
> >>>> 1) Is the current structure of this section acceptable? If not,
> >>>> what should be
> >>> done differently?
> >>> way to break up asset management into discrete use cases?
> >>>>      a. Asset Discovery
> >>>>      b. Asset Identification
> >>>>      a. Asset Characterization - Are there other important
> >>>> characteristics to
> >>> list?
> >>> 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
> >>> contributions/changes are encouraged and appreciated. I'll make
> >>> edits to the document as we get some agreement on any changes that
> should be made.
> >>>>
> >>>> Thanks,
> >>>> Dave
> >>>>
> >>>>
> >>>>> Personally, I think this a good idea and I am very interested in
> >>>>> the general opinion about this. Especially if this should or
> >>>>> should not be in the scope of SACM.
> >>>>>
> >>>>>> vendors to work out how to talk to asset management systems, or
> >>>>>> do we try to define a standard for that?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> You'd be better served using a network monitoring system that
> >>>>>>>> is built specifically for that purpose.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> missing adaption of the monitoring configuration and an
> >>>>>>>>> invalid alarm. Other reasons might result in a valid alarm.
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>> requirements must be based on a corresponding use case (is
> >>>>>>>>> that the case?), something appropriate is needed in section 4.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> 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:
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>>> From: [email-masked] [mailto:sacm-
> [email-masked]]
> >>> On
> >>>>>>>>>>> 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
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Now that you mention it, I found myself wondering of
> >>>>>>>>>>>>>> asset management
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>>> 1)Is the current structure of this section acceptable?
> >>>>>>>>>>>>>>> If not, what should be done differently?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> under data collection in a different section? Is the
> >>>>>>>>>>>>>>> human-
> >>> vs.
> >>>>>>>>>>>>>>> 6)Do you have any other general comments/questions
> on
> >>> this
> >>>>>>>>>>>>>>> section?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> changes
> >>> that
> >>> dissemination, distribution or copying of this message and

. . .

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 09 Sep 2013 15:16:41 -0400

> I'm not sure I agree.  The reason I would promote these to a distinct set of use cases is because it transcends Endpoint Assessment.  As the WG progresses through the in-scope work of our current c…

Endpoint Assessment and Content Repository Interaction are the only two 
items being addressed according to the charter.  Working on things that 
transcend that put us in danger of going out of scope.

But if you like we can go back to the full list in the original charter 
and be sure we're not boxing ourselves into a corner by just focusing on 
the current charter.

> Of course, this is all probably academic.  In my view, as long as the appropriate asset-related capabilities are captured, we're in good shape.  Whether they're promoted to a "higher level" of use…

Presently I think we have a decent agreement on what asset 
management-related data is needed for SACM.  My concern, however, is 
that by making asset management a separate use case there will be a 
tendency toward requirements creep.

I'm also trying to draw a line from the charter to the architectures, 
use cases, and requirements, so that by the time somebody is looking at 
individual requirements they can also see the derivation and 
justification for each.  The charter says we are doing endpoint 
assessment and content repository interaction.  The asset-related items 
we need are a subset of asset management that is in service to those two 
charter items.  Asset management as a separate use case just looks like 
something new that appeared out of nowhere.  Not being able to see what 
asset management is in service to makes it harder to be sure that what 
we are doing for asset management is complete enough for our needs 
without exceeding them.

With all that said, I think we've hashed this around more than enough 
for everybody to have an idea of both sides here.  I'd like to hear from 
a few more people to get an idea of what the group consensus is and move 
past this.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 9 Sep 2013 23:04:46 +0000

Hi,

Trying to catch up as I've been trying to discern from the thread the
direction especially for requirements.

I tend to agree with Gunnar, given that the charter is for us to focus on
"Šuse cases pertinent to the assessment of endpoint posture", I'm not sure
the full feature/expectations of an Asset Management system applies.
Same, for the applicability for Vulnerability Assessment, Assessment
Result Analysis and Content Management can only be scoped to our charter's
focus, e.g. Enabling these from the perspective of facilitating the
information relating to the endpoint posture assessments.  That is, I
think our use cases need to clarify that the scope for these applications
are bounded by obtaining endpoint posture only.

That said, I tried to capture what I think the intent is into a proposed
flow diagram that can be the start for an architecture as I've drawn in
the attached jpg file. I believe what is in scope is that:

- We are working with endpoints that are postured, per RFC 5209
- The evaluators that perform the posture assessment will hold
repositories for the evaluation and the rules by which they do the
evaluation (I don't think exposing the rules are in scope but the
distinction needs to be clarified)
- Share the evaluation results to applications such as the Security
Vulnerability assessment (application), etc.

The NEA documents provide a model for facilitating the assessments, but
this group will likely augment to the set of attributes defined in RFC
5792; similarly for RFC 5070 (IODEF) and others?  But my point is that we
will also need common terminology (at minimum) to ensure interoperability
for the information exchange.  Adam raises a good point in that there are
going to be many ways in which we will classify endpoints and assets, but
I think our intent is to agree and standardize on terminology and
protocols to ensure that they can be interoperable.

Can we confine "assets" to be those assets that can exist within an
endpoint since that's our bound, or is that still too broad?

I also think the scope of the transport from an (Posture) Evaluator to an
application (like the Vulnerability Assessor) needs to consider that:
- the two could be within the same internet domain or it may not
- A threat response application will likely want the information in
realtime versus an asset manager
(I believe only the red arrows in the attached figure are in scope, as
there are already standard protocols for the endpoint to Posture
Assessment links)

Comments?

	Nancy.

On 9/9/13 12:16 PM, "Gunnar Engelbach" <[email-masked]>
wrote:

>>>also be
>> I'm not sure I agree.  The reason I would promote these to a distinct
>>set of use cases is because it transcends Endpoint Assessment.  As the
>>WG progresses through the in-scope work of our current charter and as it
>>(presumably) progresses through future work related to subsequent
>>charters, appropriately identifying and characterizing assets will
>>continue to be important.
>
>> Of course, this is all probably academic.  In my view, as long as the
>>appropriate asset-related capabilities are captured, we're in good
>>shape.  Whether they're promoted to a "higher level" of use case, or
>>stuffed into Endpoint Assessment, really shouldn't matter that much.
>
>>it appears that this message was sent to you by mistake, any retention,
>>dissemination, distribution or copying of this message and attachments
>>is strictly prohibited. Please notify the sender immediately and
>>permanently delete the message and any attachments.
>>
>> . . .
>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 10 Sep 2013 12:35:37 -0400

Comments in-line:

> - We are working with endpoints that are postured, per RFC 5209

I'd rather not assume at this point that NEA is going to be the 
assessment solution. It makes sense to take advantage of existing 
standards as much as possible, but after a couple of reads through RFC 
5209 I don't think it's going to fulfill all of our needs. As one 
example, RFC 5209 explicitly says that anything where an RFC 
5209-compliant agent can't be installed is out of scope (such as 
printers, routers, switches, SCADA/medical equipment, and so on).

At the very least some of the NEA protocols/transports could be useful 
here. I'm just not convinced that NEA is enough to cover the full range 
of assessment activities that we need.

In both of our architectures, Dave and I broke out the assessment 
process into smaller components (collection, evaluation, controller) and 
I tried to show that these components could be combined in various ways 
to meet a wide variety of deployment needs.

> distinction needs to be clarified)

Physically having the content repository at the same location is not 
necessarily the case. The import thing is the ability to do a query to 
get the appropriate content -- the repository that query is done against 
might be a vendor-hosted repository on the Internet, a single repository 
within the organization's network, or a local repository that contains a 
subset of only that which is needed locally.

Similarly for results. They aren't necessarily stuck into a repository 
(they might simply be sent to a NAC/NAP system for immediate action but 
not stored), or they might be put into a non-local repository, or shared 
with multiple repositories (for example, full results saved to a 
security repository but a subset also shared with an asset management 
system).

> protocols to ensure that they can be interoperable.

One of the things we've learned over the years is that it's not enough 
to just say which endpoint attributes are to be collected, but to also 
define the logic steps to process the collected data. Doing this in a 
standardized and open manner means it can be reviewed by a range of 
experts and adjusted to produce the most reliable results. And perhaps 
more importantly it means that new content can be authored at any time 
and fed into the system with no software updates.

And additional requirement I would add is that the content MUST NOT be 
directly executable on any endpoint -- otherwise the content becomes an 
easy attack vector.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 11 Sep 2013 02:11:03 +0000

Hi Gunnar,

Please see further comments below:

>of assessment activities that we need.
[NCW] Yes, I did not mean to imply that NEA as is currently defined will
meet the current needs, but perhaps
It can serve as the starting point.  At the time of its charter, I do
believe that we were instantiating
Or focused mainly on human driven devices, but I think the definition and
intent of its general framework
Is extensible.

>to meet a wide variety of deployment needs.
[NCW]  I don't know that it is that different from what I depicted. The
collection imho are the
 Arrows that feed into the evaluation and then there's some repository
that drives the evaluation
 Which I called rules (that would be managed thru some other system, which
I'm not sure is in scope for this group).

>subset of only that which is needed locally.
[NCW] The arrows drawn in the figure are meant to be abstract, that is,
the evaluation process must store the assessed value into some repository.
 The "arrow" does not infer co-locality but rather the transport needed
(though again, I'm not as sure that, that should be in scope...) as I
interpret the bound of the charter to be the evaluator as the process that
communicates these values (wherever they may be stored).

>and fed into the system with no software updates.
[NCW] Sure, but my concern is that we are broadening the scope of our
charter too much at this point.

>directly executable on any endpoint -- otherwise the content becomes an
[NCW] Fair point.

---

From: Randy Turner <[email-masked]>
Date: Tue, 10 Sep 2013 23:12:15 -0400

In the early days of the NEA WG, I mentioned to Steve Hanna and on the NEA mailing list that the NEA technology was definitely applicable to the printing industry, and to other embedded networking appliances. RFC 5209 seems to "artificially" limit the applicability of NEA by specifically calling out devices like printers. It's a longstanding issue I've had with many IETF charters and applicability statements (going back to 1993) and their reluctance to expand the scope of good ideas beyond a router or traditional computing device. Things are slowly getting better on this front however.

The text in RFC 5209 is unfortunate, but there are a wide variety of networked devices (printers and other imaging peripherals as well ) are seriously considering implementing NEA clients, if they haven't already. I can't imagine this good work not being seriously considered for SACM (albeit with possible extensions).  It may not be a complete SACM solution, but it seems like a great tool to be included in the larger SACM toolbox.

Randy

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 11 Sep 2013 03:53:21 +0000

Randy,

The definition of "endpoint" in RFC 5209 is:

   Endpoint - Any computing device that can be connected to a network.
      Such devices normally are associated with a particular link layer
      address before joining the network and potentially an IP address
      once on the network.  This includes: laptops, desktops, servers,
      cell phones, or any device that may have an IP address.

That definition is definitely broad enough to include
most modern printers and imaging devices, as long as
they can be connected to a network. Also phones,
video cameras, thermostats, cars, etc.

The applicability statement in RFC 5209 doesn't say
that printers are out of scope. It mainly says that
RFC 5209 only applies to devices whose owners or users
"have established a clear expectation that [the device]
will comply with the policies of the owner and operator
of the network". I don't think that would generally
exclude printers. Did I miss something here?

I do regret the fact that the only occurrence of "printer"
in RFC 5209 is as an example of something that might
not support the NEA protocols but this was not intended
to mean that no printer would support the NEA protocols.
Rather, it was just a reflection of the state of the art
at the time. Endpoint assessment via native clients was
generally limited to PCs and Macs. No printers included
support for the protocols that predated the NEA RFCs.

In fact, I've been heartened by the steady support of
the hard copy industry for the NEA protocols over the
last few years.

Thanks,

Steve

> Randy Turner
> Sent: Tuesday, September 10, 2013 11:12 PM
> To: [email-masked]
> Subject: Re: [sacm] (and Arch/Flow) Re: Use Cases: Asset Management
> 
> 
> In the early days of the NEA WG, I mentioned to Steve Hanna and on the
> NEA mailing list that the NEA technology was definitely applicable to
> the printing industry, and to other embedded networking appliances. RFC
> 5209 seems to "artificially" limit the applicability of NEA by
> specifically calling out devices like printers. It's a longstanding
> issue I've had with many IETF charters and applicability statements
> (going back to 1993) and their reluctance to expand the scope of good
> ideas beyond a router or traditional computing device. Things are
> slowly getting better on this front however.
> 
> The text in RFC 5209 is unfortunate, but there are a wide variety of
> networked devices (printers and other imaging peripherals as well ) are
> seriously considering implementing NEA clients, if they haven't
> already. I can't imagine this good work not being seriously considered
> for SACM (albeit with possible extensions).  It may not be a complete
> SACM solution, but it seems like a great tool to be included in the
> larger SACM toolbox.
> 
> Randy
> 
> >>> I tend to agree with Gunnar, given that the charter is for us to
> focus
> >>> on
> >>> "Šuse cases pertinent to the assessment of endpoint posture", I'm
> not
> >>> sure
> >>> 5792; similarly for RFC 5070 (IODEF) and others?  But my point is
> that
> >>> we
> >>> for the information exchange.  Adam raises a good point in that
> there
> >>> are
> >>> going to be many ways in which we will classify endpoints and
> assets,
> >>> but
> >>> I also think the scope of the transport from an (Posture) Evaluator
> to
> >>> an

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 11 Sep 2013 01:12:29 -0400

> exclude printers. Did I miss something here?

My apologies if I misrepresented what is in RFC 5209.  The point I was 
trying to make is that NEA can only be used on devices that have an 
NEA-compliant agent installed.  And that leaves out a whole lotta endpoints.

Now, if it's acceptable to use NEA to communicate to a proxy which in 
turn is able to do collection from devices via some other method that 
those devices support, that may do the trick.

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 11 Sep 2013 01:51:22 -0400

Going back to the Waltermire architecture, collection is separate from 
evaluation and there are separate data flows for interacting with each.

I'd really like to stick close to that architecture because it offers a 
wide degree of flexibility but only needs a small number of data flows, 
such as to/from the evaluator and to/from the collector.  And I will 
repeat a previous assertion that we should *not* try to force a 
particular collection method, so in a single SACM implementation 
endpoint artifact collection can be happening via local API, WMI, 
Puppet, DCOM, SNMP, CMDB query, ... and possibly NEA.

This means that there can be a single evaluator for a large number of 
collectors, or an evaluator can be local to a collector.  It also means 
that collection can be done locally to the endpoint or externally to it.

Reading through RFC 5209 and 5792 I'm not convinced that it can request 
and return the type of data that we are looking for.  If there's anybody 
familiar with both NEA and OVAL and can confirm that the NEA Posture 
Attribute Protocol is capable of carrying the same detail as is in the 
OVAL System Characteristics element, that would be very useful.

---

From: Randy Turner <[email-masked]>
Date: Wed, 11 Sep 2013 02:51:14 -0400

Hi Steve,

Yes, I understand there is language in 5209 that doesn't preclude other devices besides desktops and servers. Consider my earlier comment an "instructural" comment to future authors about how easily applicability can become misconstrued when specific examples of devices are included or excluded, even as examples. For instance, in the endpoint definition, I would have excluded the last sentence.  

If you couldn't tell from my last email, I'm a big fan of NEA and would like to see it thrive :)

Thanks!
Randy

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 11 Sep 2013 10:32:40 +0200

Hello Gunnar,

comment is inline:

> Puppet, DCOM, SNMP, CMDB query, ... and possibly NEA.

I am very fond of the idea of highlighting common acquisition methods 
explicitly - without forcing a particular method.

The data flow for content retrieval to/from collector and evaluator 
requires an appropriate transport format (this is DF1, right?). Could 
this format also be used as a potential transport format that specifies 
how to talk with asset management systems (for endpoint artifact 
collection)?

>> the printing industry, and to other embedded networking appliances.
>> RFC 5209 seems to "artificially" limit the applicability of NEA by
>> networked devices (printers and other imaging peripherals as well )
>> are seriously considering implementing NEA clients, if they haven't

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 11 Sep 2013 11:11:34 -0400

> how to talk with asset management systems (for endpoint artifact

DF1 is communications with the content repository, DF4 would be a better 
fit for that use.

And the answer is possibly, in the case where the asset management 
system chooses to implement that part of the SACM standards.

More likely the SACM implementation will be dealing with an asset 
management system that does not use the SACM standards and will need to 
do translation.  That would be simplest to do at a single point, such as 
on the controller, but could also be done via a bridge:  something that 
is published to all components in the SACM implementation as 
understanding DF4, but on the back end is translating all interactions 
into what the asset management system understands.

Either approach also works for the case where the asset management 
system is initiating communications with the SACM system.

>>>>>> I also think the scope of the transport from an (Posture)
>>>>>> Evaluator to
>>>>>> an

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 11 Sep 2013 20:36:54 -0400

I'm going to try my hand at drawing pictures again to see if that's any 
help.  I'm also making a few assumptions about Dave Waltermire's 
original architecture, so if I get something wrong I hope he'll speak up.

These pictures start by focusing on collection and zooming out to show a 
couple of possible implementations.

Figure 1:  Collection.png
Shows three possible ways that endpoint attributes can be collected. 
The yellow boxes indicate a single endpoint, the green Collector boxes 
are software components that understand SACM collection/response data 
flows and implement some collection methodology matching the device(s) 
whose attributes are being collected.

   1) The Collector exists as an agent or service on the endpoint and 
uses local APIs to collect the requested attributes.

   2) The Collector uses database queries against the CMDB instance to 
fulfill attribute requests.

   3) The collector uses a variety of methods to fulfill attribute 
collections for multiple endpoints that are not on the same endpoint as 
the Collector.

Figure 2:  Assessment.png
The series of data interactions necessary to perform an assessment of a 
single endpoint.

   1) Based on the original Waltermire architecture.
   Benefits:
     a) Authentication information only needs to exist on the Controller
   Drawbacks:
     a) All interactions pass through the Controller.
     b) The scalability of the implementations is dependent on the 
performance of the Controller.
     c) More complex for Evaluator to do interactive assessments
     d) Evaluator cannot be integrated with collector
     e) Controller must have network visibility and authentication 
information for all components.

   2) Based on the original Engelbach architecture
   Benefits:
     a) Evaluator can interact with Collector to realize optimizations
     b) Evaluator can be integrated with Collector
   Drawbacks:
     a) Evaluator needs to be able to communicate with the Collector
     b) Evaluator needs to be able to authenticate with the Collector
     c)

   3) Hybrid
   Benefits:
     a) All benefits from above
   Drawbacks:
     a) Protocols need to support the ability to select proper path, 
making the protocols more complex

Figure 3:  SomeUsages.png
Some very basic examples of a SACM implementation doing assessments for 
a single endpoint.

   1) Traditional endpoint assessment with stored results
     1.1) An external trigger initiates an assessment of an endpoint (A).
     1.2) The Controller uses the data in the Datastore (G) to look up 
authentication information for the endpoint and passes that along with 
the assessment request details to the Evaluator (B).
     1.3) The Evaluator uses the uses the Endpoint information to 
request taxonomy information from the Collector on the endpoint (C), 
which responds with those attributes (D).
     1.4) The Evaluator uses that taxonomy information along with the 
information in the original request from the Controller to request the 
appropriate content from the Content Repository (E, F).
     1.5) The Evaluator uses the content to derive the minimal set of 
endpoint attributes needed to perform the assessment and makes that 
request (C).
     1.6) The Evaluator uses the Collector response (D) to do the 
assessment and returns the results to the Controller (G).
     1.7) The Controller puts the results in the Datastore (G)

   2) NAC/NAP connection with no stored results
     2.1) A mobile endpoint makes a VPN connection request (Red line).
     2.2) The NAC/NAP broker requests the results of the VPN connection 
assessment from the Controller (A)
     2.3) The Controller requests the VPN assessment content from the 
Content Repository (E,F)
     2.4) The Controller bundles the assessment content with a request 
for assessment from the Evaluator on the endpoint (B)
     2.5) The endpoint performs the assessment and returns the results (G)
     2.6) The Controller completes the original assessment request by 
returning the results to the NAC/NAP broker, which uses them to set the 
level of network access allowed to the endpoint.

   3) As number two, but the evaluation occurs inside the network rather 
than trust the assessment results from the mobile device.

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 12 Sep 2013 00:50:01 +0000

The only correction I have is that my architecture has the evaluator retrieving previously collected information from a data store or working with the controller to orchestrate new collection of the appropriate information from one or more collectors. I'd have to go back and check, but I believe I also allow the case where a collector can cache previously collected data, using that cache to return "new" collection data if the data is fresh enough and/or if the endpoint is not reachable.

Dave

> Sent: Wednesday, September 11, 2013 8:37 PM
> To: Nancy Cam-Winget (ncamwing)
> Cc: Adam Montville; Waltermire, David A.; [email-masked]
> Subject: Re: [sacm] (and Arch/Flow) Now with pictures!
> 
> 
> I'm going to try my hand at drawing pictures again to see if that's any help.
> I'm also making a few assumptions about Dave Waltermire's original
> architecture, so if I get something wrong I hope he'll speak up.
> 
> 
> The yellow boxes indicate a single endpoint, the green Collector boxes are
> software components that understand SACM collection/response data flows
> and implement some collection methodology matching the device(s) whose
> attributes are being collected.
> 
>    1) The Collector exists as an agent or service on the endpoint and uses local
> APIs to collect the requested attributes.
> 
>    2) The Collector uses database queries against the CMDB instance to fulfill
> attribute requests.
> 
>    3) The collector uses a variety of methods to fulfill attribute collections for
> multiple endpoints that are not on the same endpoint as the Collector.
> 
> 
> 
> Figure 2:  Assessment.png
>      e) Controller must have network visibility and authentication information
> for all components.
> 
> 
>      a) Protocols need to support the ability to select proper path, making the
> protocols more complex
> 
> 
> 
> 
> Figure 3:  SomeUsages.png

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 11 Sep 2013 23:34:03 -0400

I did greatly simplify things.  If I can scrape up some more time I'll 
draw more pictures showing more variations and increasing complexity.

Somebody please stop me if I'm headed down the wrong path.