Subject: [sacm] Endpoint Posture Assessment and Repository Protocols

From: "Adam W. Montville" <[email-masked]>
Date: Mon, 20 May 2013 09:45:56 -0700

In response to Dan's request for something we can throw against the wall...

Assessment of endpoint posture assessment entails...
the following general steps:

1. Identify and classify the asset to assess
2. Identify and/or retrieve configuration checks specific to the asset and enterprise policy.  A configuration check consists of the particular element to examine and the expected value of that element
3. Harvest the actual values of configuration elements as specified in the content identified and/or retrieved in step 2.
4. Compare the actual values of configuration elements against expected values

After this point, decisions can be made based on the "pass/fail" state of the configuration checks that have been made.

Repository protocols are needed to...
store, update, and retrieve configuration checks and other types of content required for posture assessment (see step 2 above).  A content repository is expected to house specific versions of checklists (i.e. benchmarks) may be required to satisfy different use cases (i.e. a NEA-specific use vs. a generally applicable assessment used during continuous monitoring).  In addition, content repositories are expected to store up-to-date dictionary of specific enumerations, such as those used for configuration element identifiers, asset classifications, vulnerability identifiers, and so on.

Hopefully this stokes some conversation on the list.

Adam

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 May 2013 11:02:33 +0000

Hi,

Any comments, questions, concerns about Adam's proposal? 

Just to remind - this was one of the clarification requests made by Sean (' explain what is entailed in the assessment of endpoint posture and why we need repository protocols.')

The second set of clarifications asked by Sean were about the relation with other work in the IETF 

> spt: Here's where I'd like some discussion about the NEA-based 
> protocols and how they can and can't be used, whether they are "the" 
> protocols and if not why not.
> 
>    NEA-based protocols provide ... but we're doing ...
> 
> spt: I'd also like to give some lip service to the MILE-based 
> protocols and how they'll fit in.  Even if it's that's for a later 
> stage I'd argue we need to include it now so that it's clear we're not 
> trying to overlap.
> 
>    MILE-based/like protocols/formats provide ... and will fit in
>    the overall SACM architecture ...
> 
> spt: Is there anything we can say about the existing management 
> protocols such as SNMP/NETCONF?
>

We need to answer these two issues. I am surprised with the lack of activity on the list. We will soon be losing any window of opportunity to charter the WG before Berlin. And we cannot ask for another BOF, we already had two!

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adam W. Montville
> Sent: Monday, May 20, 2013 7:46 PM
> To: [email-masked]
> Subject: [sacm] Endpoint Posture Assessment and Repository Protocols
> 
> 1. Identify and classify the asset to assess 2. Identify and/or retrieve
> configuration checks specific to the asset and enterprise policy.  A
> configuration check consists of the particular element to examine and
> the expected value of that element 3. Harvest the actual values of
> configuration elements as specified in the content identified and/or
> retrieved in step 2.
> After this point, decisions can be made based on the "pass/fail" state
> of the configuration checks that have been made.
> 
> 
> store, update, and retrieve configuration checks and other types of
> content required for posture assessment (see step 2 above).  A content
> repository is expected to house specific versions of checklists (i.e.
> benchmarks) may be required to satisfy different use cases (i.e. a NEA-
> specific use vs. a generally applicable assessment used during
> continuous monitoring).  In addition, content repositories are expected
> to store up-to-date dictionary of specific enumerations, such as those
> used for configuration element identifiers, asset classifications,
> vulnerability identifiers, and so on.
> 
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 23 May 2013 08:01:41 -0400

Hi,

Adam's suggestions look good to me.  I'll help on the complementary aspects of MILE formats and protocols. I'll try to shorten this description or others can chime in:

The MILE data formats provide a format to describe incident and threat related incident and indicator information.  SACM data formats provide ways to understand what assets are in your environment, do they meet policy requirements, and to understand the current configuration state.  The data exchanged in MILE, supplements the SACM data, to create situational awareness to better understand current threats and mitigation measures to those prioritized threats.  The combined data sets become a powerful tool to automate security with descriptions of assets and known vulnerabilities to those assets and configurations with an understanding of layered defenses.  Then injecting known threat information with mitigation options assists the organization in turing detailed security decisions into business level decisions.  The MILE protocols, RID and ROLIE, enable the exchange of structured data and are designed to carry any structured format.  While RID may be used in multiple sharing models and provides multiple communication flows (report, query, etc.) with the ability to enable peer-to-peer object level security, ROLIE provides a RESTful repository transport option with only the need for a browser on the client end, removing deployment barriers.

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Romascanu, Dan (Dan) [[email-masked]]
Sent: Thursday, May 23, 2013 7:02 AM
To: Adam W. Montville; [email-masked]
Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols

Hi,

Regards,

Dan

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 23 May 2013 08:05:21 -0400

Hi,

It's a little bit difficult to piece together where we are on the charter by
reading the archive.
The datatracker (datatracker.ietf.org) has a link for BOFs in the left menu,
and sacm is listed on their BOFs page.
The linked-to sacm page (http://datatracker.ietf.org/wg/sacm/charter/) is
titled the charter page, but there is no charter in the title bar.
Can we put a link to the current charter proposal, a link to the archive on
this page, and subscribe guidance on this page.
This might prompt wider participation and discussion.

If having it in the datatracker page makes it hard to update, can the
datatracker page provide a link to another website/wiki that is easier to
update, such as http://trac.tools.ietf.org/bof/trac/wiki/BofIETF86# ? Is the
charter included there the most current version?

Thanks,

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Romascanu, Dan (Dan)
Sent: Thursday, May 23, 2013 7:03 AM
To: Adam W. Montville; [email-masked]
Subject: Re: [sacm] Endpoint Posture Assessment and Repository Protocols

Hi,

Just to remind - this was one of the clarification requests made by Sean ('
explain what is entailed in the assessment of endpoint posture and why we
need repository protocols.')

The second set of clarifications asked by Sean were about the relation with
other work in the IETF 

> protocols such as SNMP/NETCONF?

We need to answer these two issues. I am surprised with the lack of activity
on the list. We will soon be losing any window of opportunity to charter the
WG before Berlin. And we cannot ask for another BOF, we already had two!

Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Adam W. Montville
> 1. Identify and classify the asset to assess 2. Identify and/or 
> retrieve configuration checks specific to the asset and enterprise 
> policy.  A configuration check consists of the particular element to 
> examine and the expected value of that element 3. Harvest the actual 
> values of configuration elements as specified in the content 
> identified and/or retrieved in step 2.
> benchmarks) may be required to satisfy different use cases (i.e. a 
> NEA- specific use vs. a generally applicable assessment used during 
> continuous monitoring).  In addition, content repositories are 
> expected to store up-to-date dictionary of specific enumerations, such 
> as those used for configuration element identifiers, asset 
> classifications, vulnerability identifiers, and so on.
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 May 2013 12:16:45 +0000

Hi, 

I will ask the secretariat to do all these. 

The latest charter proposal us AFAIK the one submitted in http://www.ietf.org/mail-archive/web/sacm/current/msg01080.html. 

Thanks and Regards,

Dan

> From: ietfdbh [mailto:[email-masked]]
> Sent: Thursday, May 23, 2013 3:05 PM
> To: Romascanu, Dan (Dan); [email-masked]; Sean Turner
> Subject: RE: [sacm] Endpoint Posture Assessment and Repository Protocols
> 
> Hi,
> 
> It's a little bit difficult to piece together where we are on the
> charter by reading the archive.
> The datatracker (datatracker.ietf.org) has a link for BOFs in the left
> menu, and sacm is listed on their BOFs page.
> The linked-to sacm page (http://datatracker.ietf.org/wg/sacm/charter/)
> is titled the charter page, but there is no charter in the title bar.
> Can we put a link to the current charter proposal, a link to the archive
> on this page, and subscribe guidance on this page.
> datatracker page provide a link to another website/wiki that is easier
> to update, such as http://trac.tools.ietf.org/bof/trac/wiki/BofIETF86# ?
> Is the charter included there the most current version?
> 
> Thanks,
> 
> David Harrington
> [email-masked]
> +1-603-828-1401
> explain what is entailed in the assessment of endpoint posture and why
> we need repository protocols.')
> 
> We need to answer these two issues. I am surprised with the lack of
> activity on the list. We will soon be losing any window of opportunity
> to charter the WG before Berlin. And we cannot ask for another BOF, we
> already had two!
> 
> Regards,
> 
> Dan
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 23 May 2013 10:53:32 -0400

Adam, this is a great start! A few points of feedback:

1) It is not clear if retrieving the asset's (endpoint's) software inventory is included in this description. It should be.  If this is considered to be configuration state then it is, but this should be made more clear.
2) There is no mention of method for the endpoint to self-publish its configuration state without the use of a checking language per se (e.g., SNMP, NETConf/YANG). I think we need a layered approach that enables state values to be reported regardless of the technical mechanism used and underlying checking mechanisms to be used to describe specific checking languages and results if needed or used.
3) Use of content in data collection should be an optional thing.  If content is needed to support underlying data collection, then it should be referenced and retrieved.  If the data collection engine is expressing state values using SWID, SNMP, or YANG, then content retrieval might not be needed.
4) Decisions may be made based on pass/fail evaluations or based on the actual state values that are collected.  Either approach should be allowed.

Thoughts?

Sincerely,
Dave

> Sent: Monday, May 20, 2013 12:46 PM
> To: [email-masked]
> configuration check consists of the particular element to examine and the
> expected value of that element 3. Harvest the actual values of configuration
> elements as specified in the content identified and/or retrieved in step 2.
> After this point, decisions can be made based on the "pass/fail" state of the
> configuration checks that have been made.
> 
> 
> store, update, and retrieve configuration checks and other types of content
> required for posture assessment (see step 2 above).  A content repository is
> expected to house specific versions of checklists (i.e. benchmarks) may be
> required to satisfy different use cases (i.e. a NEA-specific use vs. a generally
> applicable assessment used during continuous monitoring).  In addition,
> content repositories are expected to store up-to-date dictionary of specific
> enumerations, such as those used for configuration element identifiers,
> asset classifications, vulnerability identifiers, and so on.
> 
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 23 May 2013 10:58:45 -0400

I think we need to include text that speaks to using SACM to collect indicator information in support of MILE/IODEF exchanges. We should also discuss the opposite side of the coin, using SACM as a way to check if some indicators (e.g. file hashes) are present on existing endpoints based on information received by an organizations RID service.  IMHO, these are the killer applications for the combo in the near future.

Sincerely,
Dave

> Moriarty, Kathleen
> Sent: Thursday, May 23, 2013 8:02 AM
> To: Romascanu, Dan (Dan); Adam W. Montville; [email-masked]
> Adam's suggestions look good to me.  I'll help on the complementary aspects
> of MILE formats and protocols. I'll try to shorten this description or others can
> chime in:
> 
> The MILE data formats provide a format to describe incident and threat
> related incident and indicator information.  SACM data formats provide ways
> to understand what assets are in your environment, do they meet policy
> requirements, and to understand the current configuration state.  The data
> exchanged in MILE, supplements the SACM data, to create situational
> awareness to better understand current threats and mitigation measures to
> those prioritized threats.  The combined data sets become a powerful tool to
> automate security with descriptions of assets and known vulnerabilities to
> those assets and configurations with an understanding of layered defenses.
> Then injecting known threat information with mitigation options assists the
> organization in turing detailed security decisions into business level decisions.
> The MILE protocols, RID and ROLIE, enable the exchange of structured data
> and are designed to carry any structured format.  While RID may be used in
> multiple sharing mo  dels and provides multiple communication flows (report,
> query, etc.) with the ability to enable peer-to-peer object level security,
> ROLIE provides a RESTful repository transport option with only the need for a
> browser on the client end, removing deployment barriers.
> 
> 
> 
> 
> Thank you,
> Kathleen
> From: [email-masked] [[email-masked]] On Behalf Of
> Romascanu, Dan (Dan) [[email-masked]]

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 23 May 2013 11:03:11 -0400

One way the NEA protocols can be used is as the transport for data collected on the endpoint to enable it to be moved off the endpoint and to some external service or data repository for further analysis and action. It may also serve the purpose of carrying instructions to the endpoint for what data should be collected.

Thoughts?

Dave

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 23 May 2013 08:32:15 -0700

> 1) It is not clear if retrieving the asset's (endpoint's) software inventory is included in this description. It should be.  If this is considered to be configuration state then it is, but this sho…

It is.  The composite nature of "asset" is such that one asset can be installed on another and then becomes part of the "host" asset's configuration.  We can certainly update the language to make this clearer.

> 2) There is no mention of method for the endpoint to self-publish its configuration state without the use of a checking language per se (e.g., SNMP, NETConf/YANG). I think we need a layered approac…

To me, this is leaning toward a "how" things are going to be done rather than a description of what assessment means.  But, we can certainly update the language to reflect something like this.  This can be done by simply changing "retrieve" to "retrieve/receive" in the sentence in question (I think).

> 3) Use of content in data collection should be an optional thing.  If content is needed to support underlying data collection, then it should be referenced and retrieved.  If the data collection en…

I used the term "content" to represent the machine readable expression of assessment criteria.  Content is, in that light, always required (even in the self-reporting case the configuration information needs to be formatted in some way).  This is a point where we should probably become clearer on terminology.

> 4) Decisions may be made based on pass/fail evaluations or based on the actual state values that are collected.  Either approach should be allowed.

I'm not sure I understand the point that's being made here.  If I'm making a decision based on actual state values, I've passed some judgement on that value which either meets my criteria or does not meet my criteria.

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 23 May 2013 08:35:58 -0700

Is this really needed?  The mechanisms in SACM will be able to collect state information from an identified asset or class of assets.  Maybe it's obvious to me that the capability to collect asset state information could be used for a broader set of use cases than those defined in SACM (i.e. to support indicator information gathering).  

Given that abstract view, we could then simply state that any capability having a need to harvest state information from a given asset could benefit from using SACM formats/message exchanges and that this goes both ways.

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 23 May 2013 09:12:14 -0700

To re-write the requirements taking the feedback David has provided.  I have to say that this feels much clunkier and less clear to me than it did before.  Perhaps because I would prefer to see the steps presented in an "ideal case" or "exemplary case" scenario.  Rewriting based on the available feedback seems more like writing a spec than a charter.  

To address the "content" issue, I've removed the term.

Hopefully, this is going down the right path.  

Step 1:
[UNCHANGED] Identify and classify the asset to assess

Step 2:
[NEW]
Identify and/or retrieve configuration checks specific to the asset and enterprise policy.  A configuration check consists of the particular element, or configuration item, and the expected value of that element. In some cases, the element may be an identified asset class, such as software, in which case the expected value may be "installed" or "not installed."

[OLD]
Identify and/or retrieve configuration checks specific to the asset and enterprise policy.  A configuration check consists of the particular element to examine and the expected value of that element

Step 3:
[NEW]
Harvest the actual values of configuration elements as specified in the expression identified and/or retrieved in step 2.  At times, assets may self-report their configuration without a request for such reporting.

[OLD] Harvest the actual values of configuration elements as specified in the content identified and/or retrieved in step 2.

Step 4:
[NEW]
Compare the actual values of configuration elements against decision-making criteria.  Examples of such criteria might be "pass/fail," "installed/not installed," or something else.

[OLD]
Compare the actual values of configuration elements against expected values

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 24 May 2013 09:08:56 +0000

Yes, I would go with the formulation suggested by Adam. The idea is that we design or pick the mechanisms that meets the requirements for SACM, but the applicability can be broader, and if we can re-use pieces of solutions defined elsewhere (that meet the SACM needs) even better. 

Regards,

Dan

> From: Adam W. Montville [mailto:[email-masked]]
> Sent: Thursday, May 23, 2013 6:36 PM
> To: Waltermire, David A.
> Cc: Moriarty, Kathleen; Romascanu, Dan (Dan); [email-masked]
> Is this really needed?  The mechanisms in SACM will be able to collect
> state information from an identified asset or class of assets.  Maybe
> it's obvious to me that the capability to collect asset state
> information could be used for a broader set of use cases than those
> defined in SACM (i.e. to support indicator information gathering).
> 
> Given that abstract view, we could then simply state that any capability
> having a need to harvest state information from a given asset could
> benefit from using SACM formats/message exchanges and that this goes
> both ways.
> 
> 
> > I think we need to include text that speaks to using SACM to collect
> indicator information in support of MILE/IODEF exchanges. We should also
> discuss the opposite side of the coin, using SACM as a way to check if
> some indicators (e.g. file hashes) are present on existing endpoints
> based on information received by an organizations RID service.  IMHO,
> these are the killer applications for the combo in the near future.
> >
> > Sincerely,
> > Dave
> >
> >> Of Moriarty, Kathleen
> >> Adam's suggestions look good to me.  I'll help on the complementary
> >> aspects of MILE formats and protocols. I'll try to shorten this
> >> description or others can chime in:
> >>
> >> The MILE data formats provide a format to describe incident and
> >> threat related incident and indicator information.  SACM data formats
> >> provide ways to understand what assets are in your environment, do
> >> they meet policy requirements, and to understand the current
> >> configuration state.  The data exchanged in MILE, supplements the
> >> SACM data, to create situational awareness to better understand
> >> current threats and mitigation measures to those prioritized threats.
> >> The combined data sets become a powerful tool to automate security
> >> with descriptions of assets and known vulnerabilities to those assets
> and configurations with an understanding of layered defenses.
> >> Then injecting known threat information with mitigation options
> >> assists the organization in turing detailed security decisions into
> business level decisions.
> >> The MILE protocols, RID and ROLIE, enable the exchange of structured
> >> data and are designed to carry any structured format.  While RID may
> >> be used in multiple sharing mo  dels and provides multiple
> >> communication flows (report, query, etc.) with the ability to enable
> >> peer-to-peer object level security, ROLIE provides a RESTful
> >> repository transport option with only the need for a browser on the
> client end, removing deployment barriers.
> >>
> >>
> >>
> >>
> >> Thank you,
> >> Kathleen
> >> explain what is entailed in the assessment of endpoint posture and
> >> why we need repository protocols.')
> >>
> >>> stage I'd argue we need to include it now so that it's clear we're
> >>> not trying to overlap.
> >>>
> >> activity on the list. We will soon be losing any window of
> >> opportunity to charter the WG before Berlin. And we cannot ask for
> another BOF, we already had two!
> >>
> >> Regards,
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> After this point, decisions can be made based on the "pass/fail"
> >>> state of the configuration checks that have been made.
> >>>
> >>>
> >>> content required for posture assessment (see step 2 above).  A
> >>> content repository is expected to house specific versions of
> checklists (i.e.
> >>> expected to store up-to-date dictionary of specific enumerations,
> >>> such as those used for configuration element identifiers, asset

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 24 May 2013 15:48:04 -0400

Adam,

Comments are inline.

Thanks,
Dave

> Sent: Thursday, May 23, 2013 11:32 AM
> To: Waltermire, David A.
> Cc: [email-masked]
> > 1) It is not clear if retrieving the asset's (endpoint's) software inventory is
> included in this description. It should be.  If this is considered to be
> configuration state then it is, but this should be made more clear.
> 
> It is.  The composite nature of "asset" is such that one asset can be installed
> on another and then becomes part of the "host" asset's configuration.  We
> can certainly update the language to make this clearer.

While assets are compositional as you have stated, for management purposes it is often necessary to draw a box around collections of assets.  The term "endpoint" has been used in some of the drafts considered as part of this work as a term that provides such a grouping. My concern with using the term asset in the charter is that it means many different things to many different people.  I like the use of endpoint since we can point to the RFC 5209 for a definition. We had some discussion about using the terms "endpoint" and "posture" in the past.  I think we should stick with these terms for consistency and clarity.

> > 2) There is no mention of method for the endpoint to self-publish its
> configuration state without the use of a checking language per se (e.g.,
> SNMP, NETConf/YANG). I think we need a layered approach that enables
> state values to be reported regardless of the technical mechanism used and
> underlying checking mechanisms to be used to describe specific checking
> languages and results if needed or used.
> 
> To me, this is leaning toward a "how" things are going to be done rather than
> a description of what assessment means.  But, we can certainly update the
> language to reflect something like this.  This can be done by simply changing
> "retrieve" to "retrieve/receive" in the sentence in question (I think).

Step #2 from your original proposed text discusses identification and/or retrieval of configuration checks specific to the asset and enterprise policy. The term "check" is what I was most concerned about here as check to me has inherent meaning as a declaration of how to gather an aspect of device state (or endpoint posture). To me this also sounds like a "how" to perform data collection. What I am advocating for is separating the method of collecting the state from the method used to express and exchange the collected state. My concern is that your proposed wording for charter indicates that a check is "identified and/or retrieved" as part of endpoint posture assessment. If a check is not required or needed to perform this, such as in a SNMP or YANG scenario where the assessment engine has some built-in understanding of how to get the information, then the check will not be need to be identified and/or retrieved making step #2 optional.

> > 3) Use of content in data collection should be an optional thing.  If content
> is needed to support underlying data collection, then it should be referenced
> and retrieved.  If the data collection engine is expressing state values using
> SWID, SNMP, or YANG, then content retrieval might not be needed.
> 
> I used the term "content" to represent the machine readable expression of
> assessment criteria.  Content is, in that light, always required (even in the
> self-reporting case the configuration information needs to be formatted in
> some way).  This is a point where we should probably become clearer on
> terminology.

Same comments as above.  I guess a schema (or similar concept) may be needed to verify/validate the produced collected results, but it may not be necessary to retrieve content that drives the data collection (steps #2 and #3). Where content will likely be needed is in step #4 to support evaluation of the actual and expected values.  This content would define the expected values and any logic for evaluation pertaining to pass/fail or scoring methods.

> > 4) Decisions may be made based on pass/fail evaluations or based on the
> actual state values that are collected.  Either approach should be allowed.
> 
> I'm not sure I understand the point that's being made here.  If I'm making a
> decision based on actual state values, I've passed some judgement on that
> value which either meets my criteria or does not meet my criteria.

This is a good point; it all roughly the same kinds of decision logic.  What I was highlighting is that decisions may be made based on the raw collected data (if x setting = y value do z) or based on some derived information (if x asset/endpoint is not compliant with y policy do z). Both levels of decision logic are desirable, but to support both we need both raw data and derived information to be made available for analysis outside the endpoint. This is the important distinction.

> >> values of configuration elements as specified in the content identified
> and/or retrieved in step 2.
> >> checklists (i.e. benchmarks) may be required to satisfy different use
> >> cases (i.e. a NEA-specific use vs. a generally applicable assessment
> >> used during continuous monitoring).  In addition, content
> >> repositories are expected to store up-to-date dictionary of specific

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 24 May 2013 15:59:56 -0400

I couldn't agree more that the "plumbing" provided by SACM is useful in a variety of contexts, including but not limited to incident handling. From reading Sean's comments, my interpretation was that he was looking for more specifics about how MILE and SACM support each other from an architectural perspective.  While Kathleen's text is well written and speaks from a high-level about the synergy between the two efforts, it doesn't speak to how technologically the two efforts are related. I believe a few specific examples would help to clarify the relationship between the two efforts.

Sincerely,
Dave

> Sent: Thursday, May 23, 2013 11:36 AM
> To: Waltermire, David A.
> Is this really needed?  The mechanisms in SACM will be able to collect state
> information from an identified asset or class of assets.  Maybe it's obvious to
> me that the capability to collect asset state information could be used for a
> broader set of use cases than those defined in SACM (i.e. to support
> indicator information gathering).
> 
> having a need to harvest state information from a given asset could benefit
> from using SACM formats/message exchanges and that this goes both ways.
> 
> 
> discuss the opposite side of the coin, using SACM as a way to check if some
> indicators (e.g. file hashes) are present on existing endpoints based on
> information received by an organizations RID service.  IMHO, these are the
> killer applications for the combo in the near future.
> >
> > Sincerely,
> > Dave
> >
> >> with descriptions of assets and known vulnerabilities to those assets and
> configurations with an understanding of layered defenses.
> >> assists the organization in turing detailed security decisions into business
> level decisions.
> >> repository transport option with only the need for a browser on the client
> end, removing deployment barriers.
> >>
> >>
> >>
> >>
> >> Thank you,
> >> Kathleen
> >>> content repository is expected to house specific versions of checklists
> (i.e.

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 24 May 2013 16:53:12 -0400

How about this?

Endpoint Posture Assessment involves four distinct but related activities: 1) identification of the policies that need to be evaluated, 2) retrieval of policy content, 3) retrieval of existing or collection of current endpoint posture data that is relevant to the policies, and 4) evaluation of policies based on available endpoint posture data. The policies to be evaluated are identified and retrieved based on the evaluation context (e.g., compliance reporting, access control decision, indicator gathering). Endpoint posture is gathered from existing stores of data and/or by directly collecting posture data from the endpoint as needed. Policies are then evaluated based on available data supporting human- and machine-oriented decision making as appropriate to the evaluation context.

Endpoint posture is collected using the following method:

1) Relevant endpoints are identified and classified based on the targets of the policy/policies to be evaluated.
2) For each endpoint, determine what elements of posture information to collect based on the policy/policies to be evaluated.
3) For each element of endpoint posture data, identify the mechanism for data collection and what content is needed, if any, to support data collection.
4) Retrieve any content needed for data collection. Configuration checks pertaining to a particular posture element may be used to support data collection.
5) Harvest the actual values pertaining to posture elements identified in step 3 from the endpoint.
6) Report collected endpoint posture as identified in step 2. This will likely be done on an individual basis for each identified endpoint, requiring aggregation of data collected from multiple endpoints as needed based on the identified policy.

This approach to endpoint posture collection enables multiple policies to be evaluated based on a single data collection activity. Policies will be evaluated by comparing available endpoint posture data according to rules expressed in the policy. Typically, these rules will compare the actual value against an expected value or range for specific posture elements. In some cases, the posture element may pertain to software installation state, in which case the actual and expected values may be "installed" or "not installed." Evaluation of multiple posture elements may be combined using Boolean logic.

Some points may need additional clarification. Thoughts?

Dave

> Sent: Thursday, May 23, 2013 12:12 PM
> To: Waltermire, David A.
> Cc: [email-masked]
> To re-write the requirements taking the feedback David has provided.  I have
> to say that this feels much clunkier and less clear to me than it did before.
> Perhaps because I would prefer to see the steps presented in an "ideal case"
> or "exemplary case" scenario.  Rewriting based on the available feedback
> seems more like writing a spec than a charter.
> 
> Identify and/or retrieve configuration checks specific to the asset and
> enterprise policy.  A configuration check consists of the particular element, or
> configuration item, and the expected value of that element. In some cases,
> the element may be an identified asset class, such as software, in which case
> the expected value may be "installed" or "not installed."

Why is the expected value relevant here if the goal is to collect the current state?

> 
> [OLD]
> Identify and/or retrieve configuration checks specific to the asset and
> enterprise policy.  A configuration check consists of the particular element to
> examine and the expected value of that element
> 
> Step 3:
> [NEW]
> Harvest the actual values of configuration elements as specified in the
> expression identified and/or retrieved in step 2.  At times, assets may self-
> report their configuration without a request for such reporting.
> 
> [OLD] Harvest the actual values of configuration elements as specified in the
> content identified and/or retrieved in step 2.
> 
> Step 4:
> [NEW]
> Compare the actual values of configuration elements against decision-making
> criteria.  Examples of such criteria might be "pass/fail," "installed/not
> installed," or something else.
> 
> [OLD]
> > To me, this is leaning toward a "how" things are going to be done rather
> than a description of what assessment means.  But, we can certainly update
> the language to reflect something like this.  This can be done by simply
> changing "retrieve" to "retrieve/receive" in the sentence in question (I
> think).
> >
> >
> >>> checklists (i.e. benchmarks) may be required to satisfy different
> >>> use cases (i.e. a NEA-specific use vs. a generally applicable
> >>> assessment used during continuous monitoring).  In addition, content

---

From: John Field <[email-masked]>
Date: Fri, 24 May 2013 16:44:03 -0400

Had a busy week, and I'm just catching up on this thread...

I can't claim to have a comprehensive grasp of all the issues around
formulating the WG charter(s), but to Dave's previous point concerning the
architectural connection between MILE and SACM.... would it be helpful to
provide an illustrative use case of, say, SACM and MILE using ROLIE as a
way to traverse from an incident or indicator report, to a corresponding
benchmark?  Is that the sort of thing that would be helpful? If so, I can
pull together some words/example showing that use case.

Let me know if that would be useful.

Thanks,
John

On Fri, May 24, 2013 at 3:59 PM, Waltermire, David A. <
[email-masked]> wrote:

> I couldn't agree more that the "plumbing" provided by SACM is useful in a
> variety of contexts, including but not limited to incident handling. From
> reading Sean's comments, my interpretation was that he was looking for more
> specifics about how MILE and SACM support each other from an architectural
> perspective.  While Kathleen's text is well written and speaks from a
> high-level about the synergy between the two efforts, it doesn't speak to
> how technologically the two efforts are related. I believe a few specific
> examples would help to clarify the relationship between the two efforts.
>
> Sincerely,
> Dave
>
> state
> benefit
> some
> and
> business
> checklists

-- 

John P. Field | Security Architect | Pivotal

Direct: (908) 962-3394 | [email-masked]

**
*goPivotal.com <http://www.goPivotal.com>*

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 24 May 2013 14:08:58 -0700

David, this seems reasonable.  I have no objection to "endpoint" as a term here, and the steps look good.  Again, for a charter, I'm not sure that we need to go far beyond this level of detail, if at all.

Adam

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 24 May 2013 14:11:48 -0700

I'm not opposed to putting some architecturally related information in the charter, but I would not want to see the charter bloated with information that would otherwise be explained in the October 2013 and November 2013 milestones (initial submissions of SACM Architecture and an overview of related standards work, respectively).

John, I don't think anyone would object to your pulling some words together and sharing with the group.  That may well help determine where that information would belong.

Hope you all have a good weekend (Memorial Day for the USA-based folks on the list).

Adam

On May 24, 2013, at 1:44 PM, John Field <[email-masked]> wrote:

> I can't claim to have a comprehensive grasp of all the issues around formulating the WG charter(s), but to Dave's previous point concerning the architectural connection between MILE and SACM.... would it be helpful to provide an illustrative use case of, say, SACM and MILE using ROLIE as a way to traverse from an incident or indicator report, to a corresponding benchmark?  Is that the sort of thing that would be helpful? If so, I can pull together some words/example showing that use case.
> 
> On Fri, May 24, 2013 at 3:59 PM, Waltermire, David A. <[email-masked]> wrote:
> goPivotal.com

---

From: "ietfdbh" <[email-masked]>
Date: Sat, 25 May 2013 12:36:39 -0400

Hi,

I have a few comments regarding the charter proposed in
http://www.ietf.org/mail-archive/web/sacm/current/msg01080.html.

1) "The working group will, whenever reasonable and possible, reuse existing
protocols, mechanisms, information and data models. Of particular interest
to this working group are the security automation specifications supporting
asset, change, configuration, and vulnerability management."

The IETF doesn't currently have much in the way of "security automation
specifications"; that's why we're starting sacm.

I think our interest would be better worded as 
" Of  particular interest to this working group are existing industry
standards, preferably IETF standards, that could support 
  automation of asset, change, configuration, and vulnerability management."

2) "There are multiple categories of problems in the security automation
realm:"
This feels like it is saying the listed problems are specific to security
automation. They are not. 

" enabling interoperable data exchanges through standardized
protocols, defining expressions for particular domain concepts
(i.e. data formats), establishing a standards-based foundation
supporting the [...] exchange of [...] content
collections in content repositories, and enabling interoperability
through the development and use of standard interfaces and
communication protocols. Content based on rich and extensible data
standards and protocols will provide the authoritative instructions
needed by data-driven tools to enable the automated collection of
configuration and [state] data pertaining to enterprise
assets. Information produced by these tools will provide accurate and
timely situational awareness in support of organizational decision
making. " 

These "problems" are common to all network management, not just security
management.
These describe the same problems addressed by SNMP, IPFIX, NETCONF, SYSLOG,
NEA, MILE, and others.

 " - A standards-track document specifying a protocol and data
  format for retrieving configuration and policy information for
  driving data collection and analysis"

Operators are likely to not want a whole new management infrastructure just
for security management.
We shouldn't try to reinvent solutions to these generic problems; we already
have multiple protocols capable of retrieving configuration and policy
information for  driving data collection and analysis.
We should focus on security automation problems.
We could use an overall information  model [rfc3444] to identify those
security aspects that CAN be standardized.
We should provide advice on how to use existing protocols to address known
use-cases, and develop some data models related to automating security
assessments/configurations using existing management protocols. 

If, after we figure out what CAN be standardized, and how to utilize the
existing tools to execute such standardization, there are still problems
that existing tools cannot address, then we should consider developing new
protocols, languages, and data models.

3) I couldn't find a consistent definition for "curation" so maybe we need
to better specify what this means in the sacm context.

4) we should make sure relevant content from RFC3535 (IAB workshop on
management) gets considered in the requirements.

5) we should make sure the relevant content from rfc5706 gets considered in
the requirements.

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, May 23, 2013 8:17 AM
To: ietfdbh; [email-masked]; Sean Turner
Subject: RE: [sacm] Endpoint Posture Assessment and Repository Protocols

Hi, 

The latest charter proposal us AFAIK the one submitted in
http://www.ietf.org/mail-archive/web/sacm/current/msg01080.html. 

Thanks and Regards,

Dan

> Can we put a link to the current charter proposal, a link to the 
> archive on this page, and subscribe guidance on this page.
> Of Romascanu, Dan (Dan)
(i.e.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 26 May 2013 09:18:55 +0000

Hi David,

Thanks for the comments. 

See some responses in-line. 

Regards,

Dan

> Sent: Saturday, May 25, 2013 7:37 PM
> To: Romascanu, Dan (Dan); [email-masked]; 'Sean Turner'
> 1) "The working group will, whenever reasonable and possible, reuse
> existing protocols, mechanisms, information and data models. Of
> particular interest to this working group are the security automation
> specifications supporting asset, change, configuration, and
> vulnerability management."
> 
> I think our interest would be better worded as " Of  particular interest
> to this working group are existing industry standards, preferably IETF
> standards, that could support
[[DR]] OK. 

> This feels like it is saying the listed problems are specific to
> security automation. They are not.
> 
> " enabling interoperable data exchanges through standardized protocols,
> defining expressions for particular domain concepts (i.e. data formats),
> establishing a standards-based foundation supporting the [...] exchange
> of [...] content collections in content repositories, and enabling
> interoperability through the development and use of standard interfaces
> and communication protocols. Content based on rich and extensible data
> configuration and [state] data pertaining to enterprise assets.
> Information produced by these tools will provide accurate and timely
> situational awareness in support of organizational decision making. "
> 
> These describe the same problems addressed by SNMP, IPFIX, NETCONF,
> SYSLOG, NEA, MILE, and others.
> 
[[DR]] Yes, but this may not be clear to all participants in this effort, some of them new to the IETF, and less exposed to the discussions around the management protocols that happened during the last 10-15 years in OPS. This is why my preference is to be verbose on this issue in the charter.

> Operators are likely to not want a whole new management infrastructure
> just for security management.
> We shouldn't try to reinvent solutions to these generic problems; we
> already have multiple protocols capable of retrieving configuration and
> policy information for  driving data collection and analysis.
> We should provide advice on how to use existing protocols to address
> known use-cases, and develop some data models related to automating
> security assessments/configurations using existing management protocols.
> 
> that existing tools cannot address, then we should consider developing
> new protocols, languages, and data models.
> 
[[DR]] All true but specifying a protocol does not necessarily means 'specifying a new protocol' and we have wording about re-using or extending existing solutions whenever possible. 

> 3) I couldn't find a consistent definition for "curation" so maybe we
> need to better specify what this means in the sacm context.
>
[[DR]] yes, we can add a phrase that points to this, especially for the broader audiences mentioned above. 

> 5) we should make sure the relevant content from rfc5706 gets considered
> in the requirements.
> 
[[DR]] same.