Subject: [sacm] review of draft-ietf-sacm-use-cases-05

From: "David Harrington" <[email-masked]>
Date: Wed, 11 Dec 2013 19:52:53 -0500

Hi,

I reviewed -05- and it appears reasonably mature.
Can we move our focus from use cases to requirements and architecture?

I have a few comments on the -05- revision, all editorial in nature.

1) Does this document utilize terms that are defined/maintained in the
terminology doc? If so, we should have a section that points out where to
find the term definitions, and to reference the terminology draft.

2) Section 2.1.1: "for the explicit use of" - does this mean data gathered
by a network management system, for example, cannot be used to satisfy the
needs of sacm? Wouldn't the following be appropriate?
   This use case describes the need for content to be defined and
   published to a data store, as well as queried and retrieved from the
   data store for posture collection and evaluation.

3) I find it difficult to understand this text because "content" is such an
abstract word. What kind of content? Are we talking about things like
policies here? Or are we talking about gathered operational data? Or a
specification of a desired configuration?

4) This text talks about data models and information models. We should
reference RFC3444, which differentiates information model from data model.

5) "multiple information models will be supported to address" - address is
ambiguous here; do we mean address as in "address a problem", or as in "this
is the address where the value of this attribute can be found (such as an
OID for an SNMP object)"? Can we reword this?

6) the "Content Definition" section sounds like you're writing a charter for
work to be done by this WG. Part of the problem here is that we have gone
from active voice to passive voice, and have lost the "actors" involved. Who
will define content to drive collection? Who will evaluate existing stores
of content to find content to reuse? Who will develop content based on
available data models which may be standardized or proprietary?

I think changing this to active voice helps to identify some sentences that
don't actually say much, and could be condensed.
   Content Definition:  Defined content will drive collection and
         evaluation. < Content definers> may evaluate existing stores of
         content to find content to reuse and may create new
         content.  < Content definers>  may develop content based on
available data
         models which may be standardized or proprietary.

"Content" is "something that is contained" - not very descriptive. And we
have a number of different containers (repositories) in the tentative
architectures that have been discussed.
It seems to me we are talking about policies or rules here (and we may want
to limit this to SACM rules or SACM policies):
   Rule Definition:  SACM rules will drive collection and
         evaluation. Rules may be designed by a variety of roles -
application implementers may build SACM rules into their applications;
administrators may define SACM rules based on organizational policies;
operators may define SACM rules as needed for evaluation at runtime, and so
on. Rule definers may choose to reuse rules from existing stores of 
         rules and may create new
         rules.  Rule definers  may develop rules based on available
standardized or proprietary data
         models, such as those used for network management and/or host
management.

I realize that using the term "rules" or the term "policies" invites debate
about whether the term implies some special format. But our goal in this
document to to reach a common understanding of the problems we are trying to
solve. "content" seems so ambiguous as to be useless for achieving our goal
here.

7) Here is a case where the generic "actor" might be appropriate:
   Content Retrieval:  An actor (end-user, operator, administrator,
application) acquires one or more specific content
         entries.  The location of the
         content may be known a priori, or determined
         based on decisions made using information from a previous
         query.

8) in 2.1.2
   Endpoint Discovery:  The purpose of discovery is to determine the
         type of endpoint to be posture assessed.
How about:
   Endpoint Discovery:  The purpose of discovery is to determine the
         endpoint and how its posture should be assessed.

9)   Identify Endpoint Targets: should this step include authentication of
the target?

10) grammar:
   Identify Endpoint Targets  Determine the candidate endpoint target(s)
         against which to perform the assessment.  Depending on the
assessment
         trigger, a single endpoint or multiple
         endpoints may be targeted based on discovered endpoint
         metadata.  Content may describe the
         applicable targets for assessment.  In this case the Content
         Query and/or Content Retrieval building blocks (see section
         2.1.1) may be used to acquire this content.

11) Are these terms defined in terminology? Assessment, trigger, metadata

12) at very end of 2.1.4, "section Section 2"

13) at the very end of 2.1.4, 
   "Completion of this process represents a complete assessment cycle as
   defined in section Section 2."
Since this indicates completion of the section 2 process, I would expect
section 3 to follow.
But section continues with 2.1.5. 

14) "(see section 2.1.4 ..." there is no close quote.

15) I think the 2.1.5 use case is a subset of 2.1.4 use case, specifically,
the query of existing data is covered in   Posture Attribute Value Query,
condition 1. I think   Posture Attribute Value Query should be modified to
include the change detection, as part of establishing what needs to be
queried.

16) In 2.2.1, we changed guides to checklist; "these checklist" needs to be
plural.

17) "   Like the Automated Checklist Verification usage scenario (see
section
   2.2.2), this usage scenario supports assessment of checklists."
This should probably be "assessment based on checklists."

18) "a delta assessment" => "assessment of the delta"

19) in 2.2.5,   Posture Attribute Value Collection, why "in the same way"?
Maybe results could be handled in a different way.

20) I don't see "Search for signs of Infection", "Vulnerability Endpoint
Identification", "Compromised Endpoint Identification", and "Suspicious
Endpoint behavior", which were in -04-. They were moved into "Automated
Checklist Verification". But the original usage scenarios did not mention
checklists. Are we now limiting SACM to a checklist-driven approaches?

Do the authors of the text in -04- agree that their use cases/usage
scenarios are adequately captured in -05-?

21) 2.2.8 Others - Should "use cases" be "usage scenarios" here?

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