Subject: [sacm] Consensus on QUESTIONS in use-cases-5

From: David Harrington <[email-masked]>
Date: Sun, 2 Feb 2014 14:20:37 -0500

Hi,

Trying to get consensus on editing instructions for the use cases draft, so Dave and Dave can edit a final revision. This email is specifically focused on the QUESTIONS identified in the -05- draft, most of which were first raised in reviews of earlier revisions. Subsequent emails will focus on other requested changes, such as clarifying "content".

1) in 2.0
1.  Some type of trigger initiates the workflow.  For example, an
       operator or an application might trigger the process with a
       request, or the endpoint might trigger the process using an
       event-driven notification.

          QUESTION: Since this is about security automation, can we drop
          the User and just use Application?  Is there a better term to
          use here?  Once the policy is selected, the rest seems like
          something we definitely would want to automate, so I dropped
          the User part.

Unless there is strong objection, we will leave the text as is and remove the question.

2) in 2.0, 
        QUESTION: It was suggested that mentioning several common
              acquisition methods, such as local API, WMI, Puppet, DCOM,
              SNMP, CMDB query, and NEA, without forcing any specific
              method would be good.  I have concerns this could devolve
              into a "what about my favorite?" contest.  OTOH, the
              charter does specifically call for use of existing
              standards where applicable, so the use cases document
              might be a good neutral location for such information, and
              might force us to consider what types of external
              interfaces we might need to support when we consider the
              requirements.  It appears that the generic workflow
              sequence would be a good place to mention such common
              acquisition methods.

Consensus seems to be that this would be rathole to be avoided. We could recommend the use of standardized data models/information  models, but this really is a runtime/operational decision. I think we simply need to make sure the requirements recognize that any standardized process must be able to support either standardized or proprietary (or mixed) sets of attributes. I recommend we change the text to the following (or put a similar statement in the requirements draft).

A.  The application determines which (sets of) posture attributes
           need to be collected for evaluation. Implementations SHOULD be able to support (possibly mixed) sets of standardized and proprietary attributes.

3) In use-cases-05, section 2.0, 
       F.  The evaluator compares the collected posture attributes with
           expected values as expressed in policies.

              QUESTION: Evaluator generates a report or log or
              notification of some type?

There remains a question of whether this is part of the assessment process, but looking at it from the old IPO (input-processing-output) paradigm, or any data flow modeling I have dealt with, there should be some output as the result of the assessment process. The steps through F have no output specified, I think it important to mention that production of some type of output is expected as part of the process, but the type of output is not necessarily specified.

Unless there is strong objection, I recommend changing the question to bullet G:
G. The evaluator reports the result of the assessment, in a standardized or proprietary format, such as  a report or a log entry or a database entry or a notification. 

4) in 2.1.2,
Endpoint Discovery:  The purpose of discovery is to determine the
         type of endpoint to be posture assessed.

         QUESTION: Is it just the type?  Or is it to identify what
         endpoint instances to target for assessment using metadata such
         as the endpoint's organizationally expected type (e.g.,
         expected function/role, etc.)

If this is truly endpoint "discovery", then I think this building block discovers the whole set of endpoints it can see in the network - i.e., the whole set of endpoints that might be able to be assessed. 

In the next step (targeting), that building block selects a subset of the discovered set of endpoints, based on such things as type of endpoint, organizationally expected function/role, version, etc.

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 3 Feb 2014 17:37:45 +0000

Dave,

I'm happy with the resolutions that you suggested for these questions.

Thanks,

Steve

From: sacm [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Sunday, February 02, 2014 2:21 PM
To: [email-masked]
Cc: David Waltermire
Subject: [sacm] Consensus on QUESTIONS in use-cases-5

Hi,

1) in 2.0

          the User part.

2) in 2.0,

              acquisition methods.

4) in 2.1.2,

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 5 Feb 2014 17:29:09 +0000

The following questions were discussed at the SACM virtual meeting yesterday. The following was my recollection of the consensus on the call (marked with [DAW:]).

Please let us know ASAP about any strong objections or suggested modifications to the changes described below. We will incorporate the current consensus into an updated use cases draft (-06) to be posted on Friday, 2/14.

Thanks,
Dave

From: David Harrington [mailto:[email-masked]]
Sent: Sunday, February 02, 2014 2:21 PM
To: [email-masked]
Cc: Waltermire, David A.
Subject: Consensus on QUESTIONS in use-cases-5

Hi,

1) in 2.0

          the User part.

[DAW: The consensus was to leave the text as is and remove the question.]

2) in 2.0,

              acquisition methods.

[DAW: The consensus was to update the current text (for item A) to the following and to remove the question.]

[DAW: The consensus was to adopt the text below as a new item G and to remove the question.

G. The evaluator reports the evaluation result for the requested assessment, in a standardized or proprietary format, such as  a report, a log entry, a database entry, or a notification. ]

4) in 2.1.2,

[DAW: The discussion on the call resulted in the identification of two distinct concepts, Endpoint Discovery and Endpoint Characterization, that are needed to support the identification of what endpoints should be targeted for an assessment. Both of these concepts have been combined in the current "Endpoint Discovery" building block. There was agreement that these two aspects should be broken out into distinct building block items. I took the action to propose some new text. Please let us know if you have any objections or suggested changes to the following proposed change:

Endpoint Discovery: To determine the current or historic presence of endpoints in the environment that are available for posture assessment.

Endpoint Characterization: The act of acquiring, through automated collection or manual input, and organizing attributes associated with an endpoint (e.g., type, organizationally expected function/role, hardware/software versions) that can be used to evaluate organizational policies that determine what endpoints should be posture assessed.

Identify Endpoint Targets (slight modifications):  To identify what potential endpoint targets the checklist should apply to based on evaluating organizational policies against known endpoint attributes.]

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 05 Feb 2014 13:42:10 -0500

All of this looks good to me, with one additional comment near the bottom...

--gun

On 2/5/2014 12:29 PM, Waltermire, David A. wrote:
> The following questions were discussed at the SACM virtual meeting
> yesterday. The following was my recollection of the consensus on the
> call (marked with [DAW:]).
>
> Please let us know ASAP about any strong objections or suggested
> modifications to the changes described below. We will incorporate the
> current consensus into an updated use cases draft (-06) to be posted on
> Friday, 2/14.
>
> Thanks,
>
> Dave
>
> *From:*David Harrington [mailto:[email-masked]]
> *Sent:* Sunday, February 02, 2014 2:21 PM
> *To:* [email-masked]
> *Cc:* Waltermire, David A.
> *Subject:* Consensus on QUESTIONS in use-cases-5
>
> Hi,
>
> Trying to get consensus on editing instructions for the use cases draft,
> so Dave and Dave can edit a final revision. This email is specifically
> focused on the QUESTIONS identified in the -05- draft, most of which
> were first raised in reviews of earlier revisions. Subsequent emails
> will focus on other requested changes, such as clarifying "content".
>
> 1) in 2.0
>
> Consensus seems to be that this would be rathole to be avoided. We could
> recommend the use of standardized data models/information  models, but
> this really is a runtime/operational decision. I think we simply need to
> make sure the requirements recognize that any standardized process must
> be able to support either standardized or proprietary (or mixed) sets of
> attributes. I recommend we change the text to the following (or put a
> similar statement in the requirements draft).
>
> There remains a question of whether this is part of the assessment
> process, but looking at it from the old IPO (input-processing-output)
> paradigm, or any data flow modeling I have dealt with, there should be
> some output as the result of the assessment process. The steps through F
> have no output specified, I think it important to mention that
> production of some type of output is expected as part of the process,
> but the type of output is not necessarily specified.
>
> G. The evaluator reports the result of the assessment, in a standardized
> or proprietary format, such as  a report or a log entry or a database
> entry or a notification.
>
> G. The evaluator reports the evaluation result for the requested
> assessment, in a standardized or proprietary format, such as  a report,
> a log entry, a database entry, or a notification. ]
>
> 4) in 2.1.2,
>
> If this is truly endpoint "discovery", then I think this building block
> discovers the whole set of endpoints it can see in the network - i.e.,
> the whole set of endpoints that might be able to be assessed.
>
> In the next step (targeting), that building block selects a subset of
> the discovered set of endpoints, based on such things as type of
> endpoint, organizationally expected function/role, version, etc.
>
> [DAW: The discussion on the call resulted in the identification of two
> distinct concepts, Endpoint Discovery and Endpoint Characterization,
> that are needed to support the identification of what endpoints should
> be targeted for an assessment. Both of these concepts have been combined
> in the current “Endpoint Discovery” building block. There was agreement
> that these two aspects should be broken out into distinct building block
> items. I took the action to propose some new text. Please let us know if
> you have any objections or suggested changes to the following proposed
> change:
>
> Endpoint Discovery: To determine the current or historic presence of
> endpoints in the environment that are available for posture assessment.
>
> Endpoint Characterization: The act of acquiring, through automated
> collection or manual input, and organizing attributes associated with an
> endpoint (e.g., type, organizationally expected function/role,
> hardware/software versions) that can be used to evaluate organizational
> policies that determine what endpoints should be posture assessed.

Just end this definition at the end of the parenthetical expression, 
which also removes the need for the following "Identify Endpoint 
Targets" definition.

Classification is for both finding the appropriate content for an 
endpoint and for finding which endpoints content applies to.  Examples 
for both uses could be simply stated, if necessary.

>
> Identify Endpoint Targets (slight modifications):  To identify what
> potential endpoint targets the checklist should apply to based on
> evaluating organizational policies against known endpoint attributes.]
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 05 Feb 2014 17:59:58 -0500

Reducing DH's original message to another single item:

>             need to be collected for evaluation. Implementations SHOULD be able to support (possibly mixed) sets of standardized and proprietary attributes.

Apologies first if I've completely missed something.  I haven't been in 
a position to keep up with all SACM activity, but I haven't yet seen any 
differentiation between acquisition methods and the communication of the 
request/response withing SACM data flows.

If the data flows allow for the communication of a multitude of existing 
standards I think that would be counterproductive.

If SACM dataflows are just wrappers for a wide variety of 
existing/emerging standards, that puts a tremendous burden on every node 
to be able to understand each potential payload.

The payloads of SACM data flows should follow a single rigid pattern -- 
extensible in the sense that new data items can be requested/returned 
without needing software changes.

But collection can still occur via any appropriate mechanism as long as 
there is a collector that can do the translation.

And this would be self-selecting.  A particular collect implementation 
could be, for example, a SACM front-end for SNMP and would respond as 
the proxy for all legacy routers on the network in the same manner that 
a CMDB would.