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

From: Warren Kumari <[email-masked]>
Date: Tue, 17 Mar 2015 13:18:16 -0400

Be ye not afraid!

I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Summary: Ready with grammar nits.

Document reviewed:draft-ietf-sacm-use-cases-08.txt

Note: This is Endpoint Security Posture Assessment - Enterprise Use Cases
As a use case, it mainly provides justification for SACM work, and
example use cases. This is useful, but there is not much meat for a
security review.

One thing that the document could mention (although this could easily
be done in some other document) is that a malicious party could use
this collected data to help him figure out which end points are not as
well protected, and so make his reconnoissance  easier.

Nits and such:
The word "Optional" in Section 2.2.5. makes the nit checker confused
is in square brackets ( "[]" ) -- this makes the nit checker assume it
is a reference and so it complains. This can easily be ignored, but I
suspect other tools might also become confused - it may be a good idea
to wrap it in some other set of quating instead.

More nits:

1.  Introduction

 ....

   Togther these ideas will be used to guide development of vendor-

[O] Togther
[P] Together
[R] spelling

....
   It is expected that use cases for enterprises and for service
   providers will largely overlap, but there are additional

[O]  will largely overlap, but there are additional
[P] will largely overlap. But there are additional
[R] readability

2.  Endpoint Posture Assessment

  ....

   o  Making the attributes available for evaluation and action; and

   o  Verifying that the endpoint's posture is in compliance with
      enterprise standards and policy.

   As part of these activities it is often necessary to identify and

[O] As part of these activities it is often necessary
[P] As part of these activities, it is often necessary
[R] Readability

 ....

2.1.1.  Define, Publish, Query and Retrieve Security Automation Data

  ....
         *  Policies that define how to target and perform the
            evaluation of a set of attributes for different kinds or
            groups of endpoints and the assets they are composed of.  In
            some cases it may be desirable to maintain hierarchies of
            policies as well.

         *  References to human oriented-data that provide technical,

[O] human oriented-data
[P] human-oriented data
[R] correction

            organizational, and/or policy context.  This might include
            references to: best practices documents, legal guidance and
            legislation, and instructional materials related to the
            automation data in question.
.....

         *  Organizationally defined expected posture attribute values
            targeted to specific evaluation guidance and endpoint
            characteristics.  This allows a common set of guidance to be
            parameterized for use with different groups of endpoints.

   Processing Artifacts:  Data that is generated by and is specific to
[O] that is generated by and is specific to
[P] that is generated by, and is specific to,
[R] readability

         an individual assessment process.  This data may be used as
         part of the interactions between architectural components to
         drive and coordinate collection and evaluation activities.  Its
         lifespan will be bounded by the lifespan of the assessment.  It
         may also be exchanged and stored to provide historic context
         around an assessment activity so that individual assessments
         can be grouped, evaluated, and reported in an enterprise
         context.

  ....

   Data Definition:  Security automation data will guide and inform
         collection and evaluation processes.  This data may be designed
         by a variety of roles - application implementers may build
         security automation data into their applications;
         administrators may define guidance based on organizational
         policies; operators may define guidance and attribute data as
         needed for evaluation at runtime, and so on.  Data producers
         may choose to reuse data from existing stores of security
         automation data and may create new data.  Data producers may

[O]data and may create new data
[P] data and/or may create new data
[R] I think this is what is meant? Not sure if the "create new data"
would be from the existing stores of data.

         develop data based on available standardized or proprietary
         data models, such as those used for network management and/or
         host management.

  ...

   Data Retrieval:  An user, operator, or application acquires one or

[O] An user
[P] A user
[R] Grammar

         more specific security automation data entries.  The location
         of the data may be known a priori, or may be determined based
         on decisions made using information from a previous query.

2.1.4.  Posture Attribute Evaluation

  ...
   While the primary focus of this use cases is around enabling the

[O] this use cases
[P] this use case
[R] grammar

   comparison of expected vs. actual state, the same building blocks can
   support other analysis techniques that are applied to collected
   posture attribute data (e.g., trending, historic analysis).

 ...
2.2.1.  Definition and Publication of Automatable Configuration
        Checklists

 ...

   Each guide they produce applies to a specific model of device and
   version of the operating system and provides a number of specialized
   configurations depending on the devices intended function and what
[O] on the devices intended function
[P] on the device's intended function
[R] grammar (possessive, not plural)

   add-on hardware modules and software licenses are installed on the
   device.  To enable their customers to evaluate the security posture
   of their devices to ensure that all appropriate minimal security
   settings are enabled, they publish an automatable configuration
   checklists using a popular data format that defines what settings to
   collect using a network management protocol and appropriate values
   for each setting.  They publish these checklist to a public security

[O] these checklist to
[P] these checklists to
[R] grammar

   automation data store that customers can query to retrieve applicable
   checklist for their deployed specialized endpoint devices.

[O] checklist for their deployed
[P] checklist(s) for their deployed
[R] grammar

   Automatable configuration checklist could also come from sources
   other than a device vendor, such as industry groups or regulatory
   authorities, or enterprises could develop their own checklists.

   This usage scenario employs the following building blocks defined in
   Section 2.1.1 above:

   Data Definition:  To allow guidance to be defined using standardized
         or proprietary data models that will drive Collection and
         Evaluation.

[O] Collection and Evaluation.
[P] collection and evaluation.
[R] no reason to capitalize...

   Data Publication:  Providing a mechanism to publish created guidance
         to a security automation data store.

   Data Query:  To locate and select existing guidance that may be
         reused.

   ...
2.2.2.  Automated Checklist Verification

   ...
   The results of checklist evaluation are provided to appropriate
   operators and applications to drive additional business logic.
   Specific applications for checklist evaluation results are out-of-
   scope for current SACM efforts.  Irrespective of specific
   applications, the availability, timeliness, and liveness of results
   is often of general concern.  Network latency and available bandwidth
   often create operational constriants that require trade-offs between

[O] constriants
[P] contraints
[R] spelling

   these concerns and need to be considered.

   ...

   Posture Attribute Evaluation:  The resulting posture attribute values
         from previous Collection processes are evaluated using the

[O] Collection
[P] collection
[R] not sure why it's capitalized; maybe a typo?

         evaluation guidance to provide a set of posture results.

2.2.3.  Detection of Posture Deviations

  ...
  When a change occurs
   to posture defined in the baseline, updated posture information is
   exchanged allowing operators to be notified and/or automated action

[O] is exchanged allowing operators
[P] is exchanged, allowing operators
[R] grammar

   to be taken.

 ...

2.2.5.  Asynchronous Compliance/Vulnerability Assessment at Ice Station
        Zebra

   A university team receives a grant to do research at a government
   facility in the arctic.  The only network communications will be via
   an intermittent low-speed high-latency high-cost satellite link.

[O] intermittent low-speed high-latency high-cost
[P] intermittent, low speed, high latency, high cost
[R] grammar/readability

   During their extended expedition they will need to show continue

[O] During their extended expedition they will
[P] During their extended expedition, they will
[R] grammar

   compliance with the security policies of the university, the
   government, and the provider of the satellite network as well as keep
   current on vulnerability testing.  Interactive assessments are
   therefore not reliable, and since the researchers have very limited
   funding they need to minimize how much money they spend on network
   data.

....
   In the case of new critical vulnerabilities this collection request

[O] In the case of new critical vulnerabilities this collection request
[P] In the case of new critical vulnerabilities, this collection request
[R] grammar

   consists only of the artifacts necessary for those vulnerabilities
   and collection is only initiated for those assets that could
   potentially have a new vulnerability.

   [Optional] Asset artifacts are cached in a local CMDB.  When new
   vulnerabilities are reported to the security automation data store, a
   request to the live asset is only done if the artifacts in the CMDB
   are incomplete and/or not current enough.

...

   The collected artifacts eventually make it back to the university
   where the level of compliance and vulnerability expose is calculated

[O] level of compliance and vulnerability expose
[P] level of compliance and vulnerability exposed
[R] grammar

   and asset characteristics are compared to what is in the asset
   management system for accuracy and completeness.

...

4.  Security Considerations

   This memo documents, for Informational purposes, use cases for

[O] for Informational purposes
[P] for informational purposes
[R] not sure "informational" is capitalized.

   security automation.  Specific security considerations will be
   provided in related documents (e.g., requirements, architecture,
   information model, data model, protocol) as appropriate to the
   function described in each related document.

-------------
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 23 Mar 2015 22:11:09 +0000

Warren,

I have accepted and addressed all your nits and will be posting an updated draft with these changes soon.

You also pointed out that it would be valuable to mention in the security considerations "that a malicious party could use this collected data to help him figure out which end points are not as well protected, and so make his reconnaissance easier."

We have been working on the following text to address this issue:

One consideration for security automation is that a malicious actor could use the security automation infrastructure and related collected data to determine endpoint weaknesses to exploit.   It is important that security considerations in the related documents identify methods to both identify and prevent such activity.  Specifically, means for protecting the communications as well as the systems that store the information.  For communications between the varying SACM components there should be considerations for protecting the confidentiality,  data integrity and peer entity authentication.  Also, for any systems that store information that could be used for malicious purposes, methods to identify and protect against unauthorized usage, inappropriate usage and denial of service need to be considered.

Does this text address your concern?

If so, I'll post the updated draft containing this and the other requested changes.

Thanks,
Dave

-----Original Message-----
From: secdir [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Tuesday, March 17, 2015 1:18 PM
To: [email-masked]; [email-masked]
Subject: [secdir] Secdir review of draft-ietf-sacm-use-cases

Be ye not afraid!

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Note: This is Endpoint Security Posture Assessment - Enterprise Use Cases As a use case, it mainly provides justification for SACM work, and example use cases. This is useful, but there is not much meat for a security review.

One thing that the document could mention (although this could easily be done in some other document) is that a malicious party could use this collected data to help him figure out which end points are not as well protected, and so make his reconnoissance  easier.

Nits and such:
The word "Optional" in Section 2.2.5. makes the nit checker confused is in square brackets ( "[]" ) -- this makes the nit checker assume it is a reference and so it complains. This can easily be ignored, but I suspect other tools might also become confused - it may be a good idea to wrap it in some other set of quating instead.

More nits:

1.  Introduction

 ....

[O] Togther
[P] Together
[R] spelling

....

[O]  will largely overlap, but there are additional [P] will largely overlap. But there are additional [R] readability

  ....

[O] As part of these activities it is often necessary [P] As part of these activities, it is often necessary [R] Readability

 ....

  ....

[O] human oriented-data
[P] human-oriented data
[R] correction

   Processing Artifacts:  Data that is generated by and is specific to [O] that is generated by and is specific to [P] that is generated by, and is specific to, [R] readability

  ....

  ...

[O] An user
[P] A user
[R] Grammar

  ...

[O] this use cases
[P] this use case
[R] grammar

 ...

 ...

   Each guide they produce applies to a specific model of device and
   version of the operating system and provides a number of specialized
   configurations depending on the devices intended function and what [O] on the devices intended function [P] on the device's intended function [R] grammar (possessive, not plural)

[O] these checklist to
[P] these checklists to
[R] grammar

   ...

   ...

[O] constriants
[P] contraints
[R] spelling

   ...

[O] Collection
[P] collection

  ...
  When a change occurs

   to be taken.

 ...

[O] intermittent low-speed high-latency high-cost [P] intermittent, low speed, high latency, high cost [R] grammar/readability

[O] During their extended expedition they will [P] During their extended expedition, they will [R] grammar

....

[O] In the case of new critical vulnerabilities this collection request [P] In the case of new critical vulnerabilities, this collection request [R] grammar

...

[O] level of compliance and vulnerability expose [P] level of compliance and vulnerability exposed [R] grammar

...

-------------
W

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Mar 2015 19:52:10 -0500

On Monday, March 23, 2015, Waltermire, David A. <[email-masked]>
wrote:

> You also pointed out that it would be valuable to mention in the security
> considerations "that a malicious party could use this collected data to
> help him figure out which end points are not as well protected, and so make
> his reconnaissance easier."
>
> One consideration for security automation is that a malicious actor could
> use the security automation infrastructure and related collected data to
> determine endpoint weaknesses to exploit.   It is important that security
> considerations in the related documents identify methods to both identify
> and prevent such activity.  Specifically, means for protecting the
> communications as well as the systems that store the information.  For
> communications between the varying SACM components there should be
> considerations for protecting the confidentiality,  data integrity and peer
> entity authentication.  Also, for any systems that store information that
> could be used for malicious purposes, methods to identify and protect
> against unauthorized usage, inappropriate usage and denial of service need
> to be considered.
>

Yup.

Looks really good.
W

> From: secdir [mailto:[email-masked] <javascript:;>] On Behalf Of
> Warren Kumari
> To: [email-masked] <javascript:;>;
> [email-masked] <javascript:;>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> As a use case, it mainly provides justification for SACM work, and example
> use cases. This is useful, but there is not much meat for a security review.
>
> One thing that the document could mention (although this could easily be
> done in some other document) is that a malicious party could use this
> collected data to help him figure out which end points are not as well
> protected, and so make his reconnoissance  easier.
>
> Nits and such:
> The word "Optional" in Section 2.2.5. makes the nit checker confused is in
> square brackets ( "[]" ) -- this makes the nit checker assume it is a
> reference and so it complains. This can easily be ignored, but I suspect
> other tools might also become confused - it may be a good idea to wrap it
> in some other set of quating instead.
>
> More nits:
>
>
>
> 1.  Introduction
>
>  ....
>
> [O]  will largely overlap, but there are additional [P] will largely
> overlap. But there are additional [R] readability
>
>
>
> [O] As part of these activities it is often necessary [P] As part of these
> activities, it is often necessary [R] Readability
>
>  ....
>
>    Processing Artifacts:  Data that is generated by and is specific to [O]
> that is generated by and is specific to [P] that is generated by, and is
> specific to, [R] readability
>
>    configurations depending on the devices intended function and what [O]
> on the devices intended function [P] on the device's intended function [R]
> grammar (possessive, not plural)
>
> [O] intermittent low-speed high-latency high-cost [P] intermittent, low
> speed, high latency, high cost [R] grammar/readability
>
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
>
> [email-masked] <javascript:;>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf