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

"Waltermire, David A." <> Mon, 23 March 2015 22:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2D9401B2AC3 for <>; Mon, 23 Mar 2015 15:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o8RBkYkyBzFd for <>; Mon, 23 Mar 2015 15:11:27 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F36E1B2AC6 for <>; Mon, 23 Mar 2015 15:11:26 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 23 Mar 2015 22:11:09 +0000
Received: from ([]) by ([]) with mapi id 15.01.0118.021; Mon, 23 Mar 2015 22:11:09 +0000
From: "Waltermire, David A." <>
To: Warren Kumari <>
Thread-Topic: [secdir] Secdir review of draft-ietf-sacm-use-cases
Thread-Index: AQHQYNZhacmgDj5e/0u1Lekv9TkIi50qp65w
Date: Mon, 23 Mar 2015 22:11:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
authentication-results:; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0366;
x-microsoft-antispam-prvs: <>
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(99286002)(40100003)(106116001)(19580395003)(19580405001)(66066001)(110136001)(92566002)(1720100001)(2656002)(77156002)(2900100001)(46102003)(102836002)(76176999)(76576001)(230783001)(15975445007)(86362001)(74316001)(2950100001)(62966003)(33656002)(87936001)(50986999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0366;; FPR:; SPF:None; MLV:sfv; LANG:en;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DM2PR09MB0366; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0366;
x-forefront-prvs: 05245CA661
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2015 22:11:09.3528 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0366
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-sacm-use-cases
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2015 22:11:31 -0000


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.


-----Original Message-----
From: secdir [] On Behalf Of Warren Kumari
Sent: Tuesday, March 17, 2015 1:18 PM
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.

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


   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


   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

[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

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

   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

   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.


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.

secdir mailing list