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

[Warren Kumari <[e-mail]>]

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

> 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?


Yup.

Looks really good.
W



>
> If so, I'll post the updated draft containing this and the other requested
> changes.
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: secdir [mailto:[e-mail] <javascript:;>] On Behalf Of
> Warren Kumari
> Sent: Tuesday, March 17, 2015 1:18 PM
> To: [e-mail] <javascript:;>;
> [e-mail] <javascript:;>
> 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
>          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
>
> _______________________________________________
> secdir mailing list
> [e-mail] <javascript:;>
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>


-- 
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