Subject: [sacm] Remaining Use Cases Open Questions for F2F Discussion

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 4 Mar 2014 15:44:28 +0000

Please find the remaining 6 open questions from the use case -06 draft below. We need to get an editorial decision on changes related to these questions to wrap up the use case draft.

In the following I have documented each question (extracting it from the draft) and have proposed changes to address the questions/comments. If possible, please comment on these prior to the SACM WG meeting on Thursday. We will be discussing any contentious points. As always, we will confirm any consensus from the F2F meeting on the list afterward.

Thanks,

Dave

#1) Should section 2.1.2: Identify Endpoint Targets include authentication of the target?

Based on the current text, this appears to be using information that was previously

defined/collected. Perhaps it makes sense to add authentication to the previous building block

"Endpoint Discovery" for endpoints as they are discovered?

Add text to "Endpoint Discovery" to address authentication.

Old text:

To determine the current or historic presence of endpoints in the environment that are available

for posture assessment.

New text:

To determine the current or historic presence of endpoints in the environment that are available

for posture assessment. Endpoints are authenticated using appropriate mechanisms as they become

part of the environment.

#2) In section 2.1.2: Posture Attribute Identification: Are we missing a building block that

determines what previously collected data, if any, is suitable for evaluation and what data needs

to be actually collected?  Should a building block be identified that evaluates existing data to

determine if it is current enough for use in the evaluation or if current data should be collected

anyway according to a policy?

Suggest adding text to "Posture Attribute Identification" to address analysis of previously

collected data to determine what additional data, if any, to collect.

Old text:

Posture Attribute Identification:  Once the endpoint targets and component inventory is known, it

is then necessary to calculate what posture attributes are required to be collected to perform the

evaluation.  If this is driven by guidance, then the Data Query and/or Data Retrieval building

blocks (see section 2.1.1) may be used to acquire this data.

New text:

Posture Attribute Identification:  Once the endpoint targets and component inventory is known, it

is then necessary to calculate what posture attributes are required to be collected to perform the

evaluation. If existing stores of posture data are available, they are queried using the Data

Query building block (see section 2.1.1) to determine what previously collected posture data, if

any, is suitable for evaluation. Retrieved data is analyzed to determine if it is complete and

current enough for use in the evaluation. Any unsuitable or missing posture data is identified for

collection.

Guidance may be used to describe what sources of data should be queried, the conditions under

which data can be re-used, and what data must always be collected. The Data Query and/or Data

Retrieval building blocks (see section 2.1.1) may be used to acquire this guidance.

#3) In section 2.1.4: Posture Attribute Evaluation, what if data is unavailable or is not current

enough to support the evaluation? This could be caused if collection did not occur (for some

reason) and previous collection was too old.

Suggest adding a statement about error handling in the "Posture Attribute Evaluation" building

block. See below for edits.

#4) The end of section 2.1.4 states "Completion of this process represents a complete assessment

cycle as defined in Section 2." Since this indicates completion of the section 2 process, it would

be resonable for section 2.2 to follow. However, an additional use case section 2.1.5 follows.

Suggest integrating the 2.1.5 wording into section 2.1.4. See below for edits.

#5) Section 2.1.5 has been commented on as being duplicative of the previous use case in section

2.1.4 with the exception of the "Change Detection" building block.

Suggest integrating the 2.1.5 wording into section 2.1.4.

The following is updated text for 2.1.4 that addresses questions 3, 4, and 5 with the new text

marked in brackets:

2.1.4.  Posture Evaluation

   This use case describes the process of evaluating collected posture
   attribute values representing actual endpoint state against the
   expected state selected for the assessment.  This use case can be
   initiated by a variety of triggers including:

   1.  A posture change or significant event on the endpoint.

   2.  A network event (e.g., endpoint connects to a network/VPN,
       specific netflow is detected).

   3.  Due to a scheduled or ad hoc evaluation task.

   The building blocks of this use case are:

[new-#5:
   Collected Posture Change Detection:  An operator or application
         should have a mechanism to detect the availability of new or
         changes to existing posture attribute values.  The timeliness
         of detection may vary from immediate to on-demand.  Having the
         ability to filter what changes are detected will allow the
         operator to focus on the changes that are relevant to their use
         and will enable evaluation to occur dynamically based on
         detected changes.
]
   Posture Attribute Value Query:  If previously collected posture
         attribute values are needed, the appropriate data stores are
         queried to retrieve them.  If all posture attribute values are
         provided directly for evaluation, then this capability may not
         be needed.

   Evaluation Guidance Acquisition:  If guidance is required to drive
         the evaluation of posture attributes values, this capability is
         used to acquire this data from one or more security automation
         data stores.  Depending on the trigger, the specific guidance
         to acquire might be known.  If not, it may be necessary to
         determine the guidance to use based on the component inventory
         or other assessment criteria.  The Data Query and/or Data
         Retrieval building blocks (see section 2.1.1) may be used to
         acquire this guidance.

   Posture Attribute Evaluation:  The comparison of posture attribute
         values against their expected values as expressed in the
         specified guidance.  The result of this comparison is output as
         a set of posture evaluation results. [new-#3: If collected
         posture attribute values are unavailable or are out-of-date,
         error conditions will need to be expressed in place of specific
         posture evaluation results.]

   Completion of this process represents a complete assessment cycle as
   defined in Section 2.

[new-#5:
   While the focus of this use cases is around enabling the comparison
   of expected vs. actual state, the same building blocks can support
   other analysis techniques that apply to collected posture attribute
   data.
]

Section 2.1.5 will be deleted.

#6) In section 2.2.4, should we include other building block references?

Suggest making no changes as it looks like the current referenced building block adequately

covers the usage scenerio.

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 6 Mar 2014 01:47:18 +0000

Dave,

Here are my comments on these open questions:

Usually this is not possible. Either endpoints don't have credentials or there's no infrastructure for authenticating them (e.g. 802.1X). In your new text, I suggest changing "Endpoints are authenticated" to "Endpoints may be authenticated".

#2) 2.1.2 Posture Attribute Identification

I'm happy with your proposed new text.

#3-#5) 2.1.4 Posture Attribute Evaluation

I'm happy with these changes but suggest you change "new or changes to existing posture attribute values" to "new or changed posture attribute values".

#6) 2.2.4 Endpoint Information Analysis and Reporting

Agreed.

I'm sorry that I won't be able to join you in London. I'll read the minutes and participate by email. That's the IETF way!

Thanks,

Steve

From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Tuesday, March 04, 2014 10:44 AM
To: [email-masked]'
Subject: [sacm] Remaining Use Cases Open Questions for F2F Discussion

Thanks,

Dave

Old text:

for posture assessment.

New text:

part of the environment.

Old text:

New text:

collection.

marked in brackets:

[new-#5:

[new-#5: