GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7632

Internet Engineering Task Force (IETF) D. Waltermire Request for Comments: 7632 NIST Category: Informational D. Harrington ISSN: 2070-1721 Effective Software

                                                        September 2015
     Endpoint Security Posture Assessment: Enterprise Use Cases

Abstract

 This memo documents a sampling of use cases for securely aggregating
 configuration and operational data and evaluating that data to
 determine an organization's security posture.  From these operational
 use cases, we can derive common functional capabilities and
 requirements to guide development of vendor-neutral, interoperable
 standards for aggregating and evaluating data relevant to security
 posture.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7632.

Waltermire & Harrington Informational [Page 1] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

Copyright Notice

 Copyright (c) 2015 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Endpoint Posture Assessment . . . . . . . . . . . . . . . . .   4
   2.1.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.1.  Define, Publish, Query, and Retrieve Security
             Automation Data . . . . . . . . . . . . . . . . . . .   6
     2.1.2.  Endpoint Identification and Assessment Planning . . .   9
     2.1.3.  Endpoint Posture Attribute Value Collection . . . . .  11
     2.1.4.  Posture Attribute Evaluation  . . . . . . . . . . . .  11
   2.2.  Usage Scenarios . . . . . . . . . . . . . . . . . . . . .  13
     2.2.1.  Definition and Publication of Automatable
             Configuration Checklists  . . . . . . . . . . . . . .  13
     2.2.2.  Automated Checklist Verification  . . . . . . . . . .  14
     2.2.3.  Detection of Posture Deviations . . . . . . . . . . .  17
     2.2.4.  Endpoint Information Analysis and Reporting . . . . .  18
     2.2.5.  Asynchronous Compliance/Vulnerability Assessment at
             Ice Station Zebra . . . . . . . . . . . . . . . . . .  18
     2.2.6.  Identification and Retrieval of Guidance  . . . . . .  20
     2.2.7.  Guidance Change Detection . . . . . . . . . . . . . .  21
 3.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
 4.  Informative References  . . . . . . . . . . . . . . . . . . .  22
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

Waltermire & Harrington Informational [Page 2] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

1. Introduction

 This document describes the core set of use cases for endpoint
 posture assessment for enterprises.  It provides a discussion of
 these use cases and associated building-block capabilities.  The
 described use cases support:
 o  securely collecting and aggregating configuration and operational
    data, and
 o  evaluating that data to determine the security posture of
    individual endpoints.
 Additionally, this document describes a set of usage scenarios that
 provide examples for using the use cases and associated building
 blocks to address a variety of operational functions.
 These operational use cases and related usage scenarios cross many IT
 security domains.  The use cases enable the derivation of common:
 o  concepts that are expressed as building blocks in this document,
 o  characteristics to inform development of a requirements document,
 o  information concepts to inform development of an information model
    document, and
 o  functional capabilities to inform development of an architecture
    document.
 Together, these ideas will be used to guide development of vendor-
 neutral, interoperable standards for collecting, aggregating, and
 evaluating data relevant to security posture.
 Using this standard data, tools can analyze the state of endpoints as
 well as user activities and behaviour, and evaluate the security
 posture of an organization.  Common expression of information should
 enable interoperability between tools (whether customized,
 commercial, or freely available), and the ability to automate
 portions of security processes to gain efficiency, react to new
 threats in a timely manner, and free up security personnel to work on
 more advanced problems.
 The goal is to enable organizations to make informed decisions that
 support organizational objectives, to enforce policies for hardening
 systems, to prevent network misuse, to quantify business risk, and to
 collaborate with partners to identify and mitigate threats.

Waltermire & Harrington Informational [Page 3] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 It is expected that use cases for enterprises and for service
 providers will largely overlap.  When considering this overlap, there
 are additional complications for service providers, especially in
 handling information that crosses administrative domains.
 The output of endpoint posture assessment is expected to feed into
 additional processes, such as policy-based enforcement of acceptable
 state, verification and monitoring of security controls, and
 compliance to regulatory requirements.

2. Endpoint Posture Assessment

 Endpoint posture assessment involves orchestrating and performing
 data collection and evaluating the posture of a given endpoint.
 Typically, endpoint posture information is gathered and then
 published to appropriate data repositories to make collected
 information available for further analysis supporting organizational
 security processes.
 Endpoint posture assessment typically includes:
 o  collecting the attributes of a given endpoint;
 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
 acquire any supporting security automation data that is needed to
 drive and feed data collection and evaluation processes.
 The following is a typical workflow scenario for assessing endpoint
 posture:
 1.  Some type of trigger initiates the workflow.  For example, an
     operator or an application might trigger the process with a
     request, or the endpoint might trigger the process using an
     event-driven notification.
 2.  An operator/application selects one or more target endpoints to
     be assessed.
 3.  An operator/application selects which policies are applicable to
     the targets.

Waltermire & Harrington Informational [Page 4] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 4.  For each target:
     A.  The application determines which (sets of) posture attributes
         need to be collected for evaluation.  Implementations should
         be able to support (possibly mixed) sets of standardized and
         proprietary attributes.
     B.  The application might retrieve previously collected
         information from a cache or data store, such as a data store
         populated by an asset management system.
     C.  The application might establish communication with the
         target, mutually authenticate identities and authorizations,
         and collect posture attributes from the target.
     D.  The application might establish communication with one or
         more intermediaries or agents, which may be local or
         external.  When establishing connections with an intermediary
         or agent, the application can mutually authenticate their
         identities and determine authorizations, and collect posture
         attributes about the target from the intermediaries or
         agents.
     E.  The application communicates target identity and (sets of)
         collected attributes to an evaluator, which is possibly an
         external process or external system.
     F.  The evaluator compares the collected posture attributes with
         expected values as expressed in policies.
     G.  The evaluator reports the evaluation result for the requested
         assessment, in a standardized or proprietary format, such as
         a report, a log entry, a database entry, or a notification.

2.1. Use Cases

 The following subsections detail specific use cases for assessment
 planning, data collection, analysis, and related operations
 pertaining to the publication and use of supporting data.  Each use
 case is defined by a short summary containing a simple problem
 statement, followed by a discussion of related concepts, and a
 listing of associated building blocks that represent the capabilities
 needed to support the use case.  These use cases and building blocks
 identify separate units of functionality that may be supported by
 different components of an architectural model.

Waltermire & Harrington Informational [Page 5] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

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

 This use case describes the need for security automation data to be
 defined and published to one or more data stores, as well as queried
 and retrieved from these data stores for the explicit use of posture
 collection and evaluation.
 Security automation data is a general concept that refers to any data
 expression that may be generated and/or used as part of the process
 of collecting and evaluating endpoint posture.  Different types of
 security automation data will generally fall into one of three
 categories:
 Guidance:  Instructions and related metadata that guide the attribute
       collection and evaluation processes.  The purpose of this data
       is to allow implementations to be data-driven, thus enabling
       their behavior to be customized without requiring changes to
       deployed software.
       This type of data tends to change in units of months and days.
       In cases where assessments are made more dynamic, it may be
       necessary to handle changes in the scope of hours or minutes.
       This data will typically be provided by large organizations,
       product vendors, and some third parties.  Thus, it will tend to
       be shared across large enterprises and customer communities.
       In some cases, access may be controlled to specific
       authenticated users.  In other cases, the data may be provided
       broadly with little to no access control.
       This includes:
  • Listings of attribute identifiers for which values may be

collected and evaluated.

  • Lists of attributes that are to be collected along with

metadata that includes: when to collect a set of attributes

          based on a defined interval or event, the duration of
          collection, and how to go about collecting a set of
          attributes.
  • Guidance that specifies how old collected data can be when

used for evaluation.

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

Waltermire & Harrington Informational [Page 6] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

  • References to human-oriented data that provide technical,

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.
 Attribute Data:  Data collected through automated and manual
       mechanisms describing organizational and posture details
       pertaining to specific endpoints and the assets that they are
       composed of (e.g., hardware, software, accounts).  The purpose
       of this type of data is to characterize an endpoint (e.g.,
       endpoint type, organizationally expected function/role) and to
       provide actual and expected state data pertaining to one or
       more endpoints.  This data is used to determine what posture
       attributes to collect from which endpoints and to feed one or
       more evaluations.
       This type of data tends to change in units of days, minutes,
       and seconds, with posture attribute values typically changing
       more frequently than endpoint characterizations.  This data
       tends to be organizationally and endpoint specific, with
       specific operational groups of endpoints tending to exhibit
       similar attribute profiles.  Generally, this data will not be
       shared outside an organizational boundary and will require
       authentication with specific access controls.
       This includes:
  • Endpoint characterization data that describes the endpoint

type, organizationally expected function/role, etc.

  • Collected endpoint posture attribute values and related

context including: time of collection, tools used for

          collection, etc.
  • 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,
       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

Waltermire & Harrington Informational [Page 7] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

       around an assessment activity so that individual assessments
       can be grouped, evaluated, and reported in an enterprise
       context.
       This includes:
  • The identified set of endpoints for which an assessment

should be performed.

  • The identified set of posture attributes that need to be

collected from specific endpoints to perform an evaluation.

  • The resulting data generated by an evaluation process

including the context of what was assessed, what it was

          assessed against, what collected data was used, when it was
          collected, and when the evaluation was performed.
 The information model for security automation data must support a
 variety of different data types as described above, along with the
 associated metadata that is needed to support publication, query, and
 retrieval operations.  It is expected that multiple data models will
 be used to express specific data types requiring specialized or
 extensible security automation data repositories.  The different
 temporal characteristics, access patterns, and access control
 dimensions of each data type may also require different protocols and
 data models to be supported furthering the potential requirement for
 specialized data repositories.  See [RFC3444] for a description and
 discussion of distinctions between an information and data model.  It
 is likely that additional kinds of data will be identified through
 the process of defining requirements and an architectural model.
 Implementations supporting this building block will need to be
 extensible to accommodate the addition of new types of data, whether
 proprietary or (preferably) using a standard format.
 The building blocks of this use case are:
 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/or may create new data.  Data producers may
       develop data based on available standardized or proprietary
       data models, such as those used for network management and/or
       host management.

Waltermire & Harrington Informational [Page 8] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 Data Publication:  The capability to enable data producers to publish
       data to a security automation data store for further use.
       Published data may be made publicly available or access may be
       based on an authorization decision using authenticated
       credentials.  As a result, the visibility of specific security
       automation data to an operator or application may be public,
       enterprise-scoped, private, or controlled within any other
       scope.
 Data Query:  An operator or application should be able to query a
       security automation data store using a set of specified
       criteria.  The result of the query will be a listing matching
       the query.  The query result listing may contain publication
       metadata (e.g., create date, modified date, publisher, etc.)
       and/or the full data, a summary, snippet, or the location to
       retrieve the data.
 Data Retrieval:  A user, operator, or application acquires one or
       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.
 Data Change Detection:  An operator or application needs to know when
       security automation data they are interested in has been
       published to, updated in, or deleted from a security automation
       data store that they have been authorized to access.
 These building blocks are used to enable acquisition of various
 instances of security automation data based on specific data models
 that are used to drive assessment planning (see Section 2.1.2),
 posture attribute value collection (see Section 2.1.3), and posture
 evaluation (see Section 2.1.4).

2.1.2. Endpoint Identification and Assessment Planning

 This use case describes the process of discovering endpoints,
 understanding their composition, identifying the desired state to
 assess against, and calculating what posture attributes to collect to
 enable evaluation.  This process may be a set of manual, automated,
 or hybrid steps that are performed for each assessment.

Waltermire & Harrington Informational [Page 9] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 The building blocks of this use case are:
 Endpoint Discovery:  To determine the current or historic presence of
       endpoints in the environment that are available for posture
       assessment.  Endpoints are identified in support of discovery
       by using information previously obtained or using other
       collection mechanisms to gather identification and
       characterization data.  Previously obtained data may originate
       from sources such as network authentication exchanges.
 Endpoint Characterization:  The act of acquiring, through automated
       collection or manual input, and organizing attributes
       associated with an endpoint (e.g., type, organizationally
       expected function/role, hardware/software versions).
 Endpoint Target Identification:  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 characterized endpoint
       attributes.  Guidance describing the assessment to be performed
       may contain instructions or references used to determine the
       applicable assessment targets.  In this case, the Data Query
       and/or Data Retrieval building blocks (see Section 2.1.1) may
       be used to acquire this data.
 Endpoint Component Inventory:  To determine what applicable desired
       states should be assessed, it is first necessary to acquire the
       inventory of software, hardware, and accounts associated with
       the targeted endpoint(s).  If the assessment of the endpoint is
       not dependent on the these details, then this capability is not
       required for use in performing the assessment.  This process
       can be treated as a collection use case for specific posture
       attributes.  In this case, the building blocks for
       Endpoint Posture Attribute Value Collection (see Section 2.1.3)
       can be used.
 Posture Attribute Identification:  Once the endpoint targets and
       their associated asset inventory is known, it is then necessary
       to calculate what posture attributes are required to be
       collected to perform the desired evaluation.  When available,
       existing posture data is queried for suitability using the Data
       Query building block (see Section 2.1.1).  Such posture data is
       suitable if it is complete and current enough for use in the
       evaluation.  Any unsuitable posture data is identified for
       collection.

Waltermire & Harrington Informational [Page 10] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

       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.
 At this point, the set of posture attribute values to use for
 evaluation are known, and they can be collected if necessary (see
 Section 2.1.3).

2.1.3. Endpoint Posture Attribute Value Collection

 This use case describes the process of collecting a set of posture
 attribute values related to one or more endpoints.  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 [RFC3954] is detected).
 3.  a scheduled or ad hoc collection task.
 The building blocks of this use case are:
 Collection Guidance Acquisition:  If guidance is required to drive
       the collection 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 Value Collection:  The accumulation of posture
       attribute values.  This may be based on collection guidance
       that is associated with the posture attributes.
 Once the posture attribute values are collected, they may be
 persisted for later use or they may be immediately used for posture
 evaluation.

2.1.4. Posture Attribute Evaluation

 This use case represents the action of analyzing collected posture
 attribute values as part of an assessment.  The primary focus of this
 use case is to support evaluation of actual endpoint state against
 the expected state selected for the assessment.

Waltermire & Harrington Informational [Page 11] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 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 [RFC3954] is detected).
 3.  a scheduled or ad hoc evaluation task.
 The building blocks of this use case are:
 Collected Posture Change Detection:  An operator or application has a
       mechanism to detect the availability of new posture attribute
       values or changes to existing ones.  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 using the Data Query building block
       (see Section 2.1.1).  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.  Such results include
       metadata required to provide a level of assurance with respect
       to the posture attribute data and, therefore, evaluation
       results.  Examples of such metadata include provenance and or
       availability data.

Waltermire & Harrington Informational [Page 12] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 While the primary focus of this use case is around enabling the
 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).
 Completion of this process represents a complete assessment cycle as
 defined in Section 2.

2.2. Usage Scenarios

 In this section, we describe a number of usage scenarios that utilize
 aspects of endpoint posture assessment.  These are examples of common
 problems that can be solved with the building blocks defined above.

2.2.1. Definition and Publication of Automatable Configuration

      Checklists
 A vendor manufactures a number of specialized endpoint devices.  They
 also develop and maintain an operating system for these devices that
 enables end-user organizations to configure a number of security and
 operational settings.  As part of their customer support activities,
 they publish a number of secure configuration guides that provide
 minimum security guidelines for configuring their devices.
 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 device's intended function and what
 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 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 checklists to a public security
 automation data store that customers can query to retrieve applicable
 checklist(s) for their deployed specialized endpoint devices.
 Automatable configuration checklists 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.

Waltermire & Harrington Informational [Page 13] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 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.
 Data Retrieval  To retrieve specific guidance from a security
       automation data store for editing.
 While each building block can be used in a manual fashion by a human
 operator, it is also likely that these capabilities will be
 implemented together in some form of a guidance editor or generator
 application.

2.2.2. Automated Checklist Verification

 A financial services company operates a heterogeneous IT environment.
 In support of their risk management program, they utilize vendor-
 provided automatable security configuration checklists for each
 operating system and application used within their IT environment.
 Multiple checklists are used from different vendors to ensure
 adequate coverage of all IT assets.
 To identify what checklists are needed, they use automation to gather
 an inventory of the software versions utilized by all IT assets in
 the enterprise.  This data gathering will involve querying existing
 data stores of previously collected endpoint software inventory
 posture data and actively collecting data from reachable endpoints as
 needed, utilizing network and systems management protocols.
 Previously collected data may be provided by periodic data
 collection, network connection-driven data collection, or ongoing
 event-driven monitoring of endpoint posture changes.
 Appropriate checklists are queried, located, and downloaded from the
 relevant guidance data stores.  The specific data stores queried and
 the specifics of each query may be driven by data including:
 o  collected hardware and software inventory data, and
 o  associated asset characterization data that may indicate the
    organizationally defined functions of each endpoint.
 Checklists may be sourced from guidance data stores maintained by an
 application or OS vendor, an industry group, a regulatory authority,
 or directly by the enterprise.
 The retrieved guidance is cached locally to reduce the need to
 retrieve the data multiple times.

Waltermire & Harrington Informational [Page 14] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 Driven by the setting data provided in the checklist, a combination
 of existing configuration data stores and data collection methods are
 used to gather the appropriate posture attributes from (or pertaining
 to) each endpoint.  Specific posture attribute values are gathered
 based on the defined enterprise function and software inventory of
 each endpoint.  The collection mechanisms used to collect software
 inventory posture will be used again for this purpose.  Once the data
 is gathered, the actual state is evaluated against the expected state
 criteria defined in each applicable checklist.
 A checklist can be assessed as a whole, or a specific subset of the
 checklist can be assessed resulting in partial data collection and
 evaluation.
 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 (Security Automation and Continuous
 Monitoring) efforts.  Irrespective of specific applications, the
 availability, timeliness, and liveness of results are often of
 general concern.  Network latency and available bandwidth often
 create operational constraints that require trade-offs between these
 concerns and need to be considered.
 Uses of checklists and associated evaluation results may include, but
 are not limited to:
 o  Detecting endpoint posture deviations as part of a change
    management program to identify:
  • missing required patches,
  • unauthorized changes to hardware and software inventory, and
  • unauthorized changes to configuration items.
 o  Determining compliance with organizational policies governing
    endpoint posture.
 o  Informing configuration management, patch management, and
    vulnerability mitigation and remediation decisions.
 o  Searching for current and historic indicators of compromise.
 o  Detecting current and historic infection by malware and
    determining the scope of infection within an enterprise.

Waltermire & Harrington Informational [Page 15] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 o  Detecting performance, attack, and vulnerable conditions that
    warrant additional network diagnostics, monitoring, and analysis.
 o  Informing network access control decision-making for wired,
    wireless, or VPN connections.
 This usage scenario employs the following building blocks defined in
 Section 2.1.1 above:
 Endpoint Discovery:  The purpose of discovery is to determine the
       type of endpoint to be posture assessed.
 Endpoint Target Identification:  To identify what potential endpoint
       targets the checklist should apply to based on organizational
       policies.
 Endpoint Component Inventory:  Collecting and consuming the software
       and hardware inventory for the target endpoints.
 Posture Attribute Identification:  To determine what data needs to be
       collected to support evaluation, the checklist is evaluated
       against the component inventory and other endpoint metadata to
       determine the set of posture attribute values that are needed.
 Collection Guidance Acquisition:  Based on the identified posture
       attributes, the application will query appropriate security
       automation data stores to find the "applicable" collection
       guidance for each endpoint in question.
 Posture Attribute Value Collection:  For each endpoint, the values
       for the required posture attributes are collected.
 Posture Attribute Value Query:  If previously collected posture
       attribute values are used, they are queried from the
       appropriate data stores for the target endpoint(s).
 Evaluation Guidance Acquisition:  Any guidance that is needed to
       support evaluation is queried and retrieved.
 Posture Attribute Evaluation:  The resulting posture attribute values
       from previous collection processes are evaluated using the
       evaluation guidance to provide a set of posture results.

Waltermire & Harrington Informational [Page 16] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

2.2.3. Detection of Posture Deviations

 Example Corporation has established secure configuration baselines
 for each different type of endpoint within their enterprise
 including: network infrastructure, mobile, client, and server
 computing platforms.  These baselines define an approved list of
 hardware, software (i.e., operating system, applications, and
 patches), and associated required configurations.  When an endpoint
 connects to the network, the appropriate baseline configuration is
 communicated to the endpoint based on its location in the network,
 the expected function of the device, and other asset management data.
 It is checked for compliance with the baseline, and any deviations
 are indicated to the device's operators.  Once the baseline has been
 established, the endpoint is monitored for any change events
 pertaining to the baseline on an ongoing basis.  When a change occurs
 to posture defined in the baseline, updated posture information is
 exchanged, allowing operators to be notified and/or automated action
 to be taken.
 Like the Automated Checklist Verification usage scenario (see
 Section 2.2.2), this usage scenario supports assessment based on
 automatable checklists.  It differs from that scenario by monitoring
 for specific endpoint posture changes on an ongoing basis.  When the
 endpoint detects a posture change, an alert is generated identifying
 the specific changes in posture, thus allowing assessment of the
 delta to be performed instead of a full assessment as in the previous
 case.  This usage scenario employs the same building blocks as
 Automated Checklist Verification (see section 2.2.2).  It differs
 slightly in how it uses the following building blocks:
 Endpoint Component Inventory:  Additionally, changes to the hardware
       and software inventory are monitored, with changes causing
       alerts to be issued.
 Posture Attribute Value Collection:  After the initial assessment,
       posture attributes are monitored for changes.  If any of the
       selected posture attribute values change, an alert is issued.
 Posture Attribute Value Query:  The previous state of posture
       attributes are tracked, allowing changes to be detected.
 Posture Attribute Evaluation:  After the initial assessment, a
       partial evaluation is performed based on changes to specific
       posture attributes.
 This usage scenario highlights the need to query a data store to
 prepare a compliance report for a specific endpoint and also the need
 for a change in endpoint state to trigger Collection and Evaluation.

Waltermire & Harrington Informational [Page 17] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

2.2.4. Endpoint Information Analysis and Reporting

 Freed from the drudgery of manual endpoint compliance monitoring, one
 of the security administrators at Example Corporation notices (not
 using SACM standards) that five endpoints have been uploading lots of
 data to a suspicious server on the Internet.  The administrator
 queries data stores for specific endpoint posture to see what
 software is installed on those endpoints and finds that they all have
 a particular program installed.  She then queries the appropriate
 data stores to see which other endpoints have that program installed.
 All these endpoints are monitored carefully (not using SACM
 standards), which allows the administrator to detect that the other
 endpoints are also infected.
 This is just one example of the useful analysis that a skilled
 analyst can do using data stores of endpoint posture.
 This usage scenario employs the following building blocks defined in
 Section 2.1.1 above:
 Posture Attribute Value Query:  Previously collected posture
       attribute values for the target endpoint(s) are queried from
       the appropriate data stores using a standardized method.
 This usage scenario highlights the need to query a repository for
 attributes to see which attributes certain endpoints have in common.

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.
 During their extended expedition, they will need to show continued
 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.
 Prior to departure, they register all equipment with an asset
 management system owned by the university, which will also initiate
 and track assessments.
 On a periodic basis -- either after a maximum time delta or when the
 security automation data store has received a threshold level of new
 vulnerability definitions -- the university uses the information in

Waltermire & Harrington Informational [Page 18] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 the asset management system to put together a collection request for
 all of the deployed assets that encompasses the minimal set of
 artifacts necessary to evaluate all three security policies as well
 as vulnerability testing.
 In the case of new critical vulnerabilities, this collection request
 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 configuration
 management database (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 collection request is queued for the next window of connectivity.
 The deployed assets eventually receive the request, fulfill it, and
 queue the results for the next return opportunity.
 The collected artifacts eventually make it back to the university
 where the level of compliance and vulnerability exposed is calculated
 and asset characteristics are compared to what is in the asset
 management system for accuracy and completeness.
 Like the Automated Checklist Verification usage scenario (see section
 2.2.2), this usage scenario supports assessment based on checklists.
 It differs from that scenario in how guidance, collected posture
 attribute values, and evaluation results are exchanged due to
 bandwidth limitations and availability.  This usage scenario employs
 the same building blocks as Automated Checklist Verification (see
 section 2.2.2).  It differs slightly in how it uses the following
 building blocks:
 Endpoint Component Inventory:  It is likely that the component
       inventory will not change.  If it does, this information will
       need to be batched and transmitted during the next
       communication window.
 Collection Guidance Acquisition:  Due to intermittent communication
       windows and bandwidth constraints, changes to collection
       guidance will need to batched and transmitted during the next
       communication window.  Guidance will need to be cached locally
       to avoid the need for remote communications.

Waltermire & Harrington Informational [Page 19] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 Posture Attribute Value Collection:  The specific posture attribute
       values to be collected are identified remotely and batched for
       collection during the next communication window.  If a delay is
       introduced for collection to complete, results will need to be
       batched and transmitted.
 Posture Attribute Value Query:  Previously collected posture
       attribute values will be stored in a remote data store for use
       at the university.
 Evaluation Guidance Acquisition:  Due to intermittent communication
       windows and bandwidth constraints, changes to evaluation
       guidance will need to batched and transmitted during the next
       communication window.  Guidance will need to be cached locally
       to avoid the need for remote communications.
 Posture Attribute Evaluation:  Due to the caching of posture
       attribute values and evaluation guidance, evaluation may be
       performed at both the university campus as well as the
       satellite site.
 This usage scenario highlights the need to support low-bandwidth,
 intermittent, or high-latency links.

2.2.6. Identification and Retrieval of Guidance

 In preparation for performing an assessment, an operator or
 application will need to identify one or more security automation
 data stores that contain the guidance entries necessary to perform
 data collection and evaluation tasks.  The location of a given
 guidance entry will either be known a priori or known security
 automation data stores will need to be queried to retrieve applicable
 guidance.
 To query guidance it will be necessary to define a set of search
 criteria.  This criteria will often utilize a logical combination of
 publication metadata (e.g., publishing identity, create time,
 modification time) and criteria elements specific to the guidance
 data.  Once the criteria are defined, one or more security automation
 data stores will need to be queried, thus generating a result set.
 Depending on how the results are used, it may be desirable to return
 the matching guidance directly, a snippet of the guidance matching
 the query, or a resolvable location to retrieve the data at a later
 time.  The guidance matching the query will be restricted based on
 the authorized level of access allowed to the requester.

Waltermire & Harrington Informational [Page 20] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

 If the location of guidance is identified in the query result set,
 the guidance will be retrieved when needed using one or more data
 retrieval requests.  A variation on this approach would be to
 maintain a local cache of previously retrieved data.  In this case,
 only guidance that is determined to be stale by some measure will be
 retrieved from the remote data store.
 Alternately, guidance can be discovered by iterating over data
 published with a given context within a security automation data
 store.  Specific guidance can be selected and retrieved as needed.
 This usage scenario employs the following building blocks defined in
 Section 2.1.1 above:
 Data Query:  Enables an operator or application to query one or more
       security automation data stores for guidance using a set of
       specified criteria.
 Data Retrieval:  If data locations are returned in the query result
       set, then specific guidance entries can be retrieved and
       possibly cached locally.

2.2.7. Guidance Change Detection

 An operator or application may need to identify new, updated, or
 deleted guidance in a security automation data store for which they
 have been authorized to access.  This may be achieved by querying or
 iterating over guidance in a security automation data store, or
 through a notification mechanism that generates alerts when changes
 are made to a security automation data store.
 Once guidance changes have been determined, data collection and
 evaluation activities may be triggered.
 This usage scenario employs the following building blocks defined in
 Section 2.1.1 above:
 Data Change Detection:  Allows an operator or application to identify
       guidance changes in a security automation data store for which
       they have been authorized to access.
 Data Retrieval:  If data locations are provided by the change
       detection mechanism, then specific guidance entries can be
       retrieved and possibly cached locally.

Waltermire & Harrington Informational [Page 21] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

3. Security Considerations

 This memo documents, for informational purposes, use cases for
 security automation.  Specific security and privacy 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.
 One consideration for security automation is that a malicious actor
 could use the security automation infrastructure and related
 collected data to gain access to an item of interest.  This may
 include personal data, private keys, software and configuration state
 that can be used to inform an attack against the network and
 endpoints, and other sensitive information.  It is important that
 security and privacy considerations in the related documents indicate
 methods to both identify and prevent such activity.
 For consideration are 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.  For exchanged information, there should be a means
 to authenticate the origin of the information.  This is important
 where tracking the provenance of data is needed.  Also, for any
 systems that store information that could be used for unauthorized or
 malicious purposes, methods to identify and protect against
 unauthorized usage, inappropriate usage, and denial of service need
 to be considered.

4. Informative References

 [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
            Information Models and Data Models", RFC 3444,
            DOI 10.17487/RFC3444, January 2003,
            <http://www.rfc-editor.org/info/rfc3444>.
 [RFC3954]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
            Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
            <http://www.rfc-editor.org/info/rfc3954>.

Waltermire & Harrington Informational [Page 22] RFC 7632 Enterprise Use Cases for Sec Assessment September 2015

Acknowledgements

 Adam Montville edited early versions of this document.
 Kathleen Moriarty and Stephen Hanna contributed text describing the
 scope of the document.
 Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa
 Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and
 Aron Woland provided text about the use cases for various revisions
 of this document.

Authors' Addresses

 David Waltermire
 National Institute of Standards and Technology
 100 Bureau Drive
 Gaithersburg, Maryland  20877
 United States
 Email: david.waltermire@nist.gov
 David Harrington
 Effective Software
 16 Bayview Drive
 Westerly, Rhode Island  02891
 United States
 Email: ietfdbh@gmail.com

Waltermire & Harrington Informational [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7632.txt · Last modified: 2015/09/08 18:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki