Using Security Posture Assessment to Grant Access to Enterprise Network Resources
draft-ietf-sacm-use-cases-01

Security Automation and Continuous Monitoring WG           D. Waltermire
Internet-Draft                                                      NIST
Intended status: Informational                             D. Harrington
Expires: March 16, 2014                               Effective Software
                                                      September 12, 2013

Using Security Posture Assessment to Grant Access to Enterprise Network
                               Resources
                      draft-ietf-sacm-use-cases-01

Abstract

   This memo documents a sampling of use cases for securely aggregating
   configuration and operational data and assessing 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 assessing data relevant to security
   posture.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 16, 2014.

Copyright Notice

   Copyright (c) 2013 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

Waltermire & Harrington  Expires March 16, 2014                 [Page 1]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Endpoint Posture Assessment . . . . . . . . . . . . . . . . .   4
     3.1.  Definition and Publication of Automatable Configuration
           Guides  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Automated Checklist Verification  . . . . . . . . . . . .   6
     3.3.  Organizational Software Policy Compliance . . . . . . . .   7
     3.4.  Detection of Posture Deviations . . . . . . . . . . . . .   7
     3.5.  Others... . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Functional Capabilities . . . . . . . . . . . . . . . . . . .   7
     4.1.  Asset Identification  . . . . . . . . . . . . . . . . . .   8
       4.1.1.  Asset Class Identification  . . . . . . . . . . . . .   8
       4.1.2.  Asset Instance Identification . . . . . . . . . . . .   9
     4.2.  Asset Characterization  . . . . . . . . . . . . . . . . .  10
     4.3.  Deconfliction of Asset Identities . . . . . . . . . . . .  13
     4.4.  Asset Targeting . . . . . . . . . . . . . . . . . . . . .  13
     4.5.  Other Unedited Content  . . . . . . . . . . . . . . . . .  15
       4.5.1.  Endpoint Configuration Management . . . . . . . . . .  15
         4.5.1.1.  Organizing Configuration Metadata . . . . . . . .  15
         4.5.1.2.  Publishing Recommended Configuration Posture  . .  16
         4.5.1.3.  Defining Organizationally Expected Configuration
                   Posture . . . . . . . . . . . . . . . . . . . . .  16
         4.5.1.4.  Collecting Endpoint Configuration Posture . . . .  16
         4.5.1.5.  Comparing Expected and Actual Configuration
                   Posture . . . . . . . . . . . . . . . . . . . . .  16
         4.5.1.6.  Examining configuration of logical to physical
                   mappings  . . . . . . . . . . . . . . . . . . . .  17
         4.5.1.7.  Configuring Endpoint Interfaces . . . . . . . . .  17
       4.5.2.  Endpoint Posture Change Management  . . . . . . . . .  17
         4.5.2.1.  Defining and Exchanging Baselines . . . . . . . .  17
         4.5.2.2.  Detecting Unauthorized Changes  . . . . . . . . .  17
       4.5.3.  Security Vulnerability Management . . . . . . . . . .  18
         4.5.3.1.  Example - NIDS response . . . . . . . . . . . . .  18
         4.5.3.2.  Example - Historical vulnerability analysis . . .  19
         4.5.3.3.  Source Address Validation . . . . . . . . . . . .  19
       4.5.4.  Data Collection . . . . . . . . . . . . . . . . . . .  19
       4.5.5.  Assessment Result Analysis  . . . . . . . . . . . . .  20
       4.5.6.  Content Management  . . . . . . . . . . . . . . . . .  20
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21

Waltermire & Harrington  Expires March 16, 2014                 [Page 2]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   8.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  -00- to -01-  . . . . . . . . . . . . . . . . . . . . . .  21
     8.2.  draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-
           use-cases-00  . . . . . . . . . . . . . . . . . . . . . .  22
     8.3.  -04- to -05-  . . . . . . . . . . . . . . . . . . . . . .  23
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   Our goal with this document is to improve our agreement on which
   problems we're trying to solve.  We need to start with short, simple
   problem statements and discuss those by email and in person.  Once we
   agree on which problems we're trying to solve, we can move on to
   propose various solutions and decide which ones to use.

   This document describes example use cases for endpoint posture
   assessment for enterprises.  It provides a sampling of use cases for
   securely aggregating configuration and operational data and assessing
   that data to determine the security posture of individual endpoints,
   and, in the aggregate, the security posture of an enterprise.

   These use cases cross many IT security information domains.  From
   these operational use cases, we can derive common concepts, common
   information expressions, functional capabilities and requirements to
   guide development of vendor-neutral, interoperable standards for
   aggregating and assessing data relevant to security posture.

   Using this standard data, tools can analyze the state of endpoints,
   user activities and behaviour, and assess 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.

   It is expected that use cases for enterprises and for service
   providers will largely overlap, but there are additional
   complications for service providers, especially in handling
   information that crosses administrative domains.

Waltermire & Harrington  Expires March 16, 2014                 [Page 3]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   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.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Endpoint Posture Assessment

   Endpoint posture assessment involves orchestrating and performing
   data collection and analysis pertaining to 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 posture of a given endpoint;

   o  Making that posture available to the enterprise for further
      analysis and action; and

   o  Performing analysis to assess 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 content that is needed to drive data
   collection and analysis.

   The following is a typical success scenario for endpoint posture
   assessment:

   1.  Define a target endpoint to be assessed

   2.  Select acceptable state policies to apply to the defined target

   3.  Identify the endpoint being assessed

   4.  Collect posture attributes from the target

   5.  Communicate target identity and collected posture to external
       system for evaluation

Waltermire & Harrington  Expires March 16, 2014                 [Page 4]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   6.  Compare collected posture attributes from the target endpoint
       with expected state values as expressed in acceptable state
       policies

   The following subsections detail specific use cases for data
   collection, analysis, and related operations pertaining to the
   publication and use of supporting content.

3.1.  Definition and Publication of Automatable Configuration Guides

   QUESTION: This use case applies equally to vendors representing other
   endpoint types.  Should this be generalized to capture this notion?

   A network device vendor manufactures a number of enterprise grade
   routers and other network devices.  The also develop and maintain an
   operating system for these devices that enables end-user
   organizations to configure a number of security and operational
   settings for these devices.  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 devices intended function and what
   add-on hardware modules and software licenses are installed on the
   device.  To enable their customers to assess the security posture of
   their devices to ensure that all appropriate minimal security
   settings are enabled, they publish an automatable configuration
   checklist using a popular data format that defines what settings to
   check using a network management protocol and appropriate values for
   each setting.  They publish these guides to a public content
   repository that customers can query to retrieve applicable guides for
   their deployed enterprise network infrastructure endpoints.

   To support this use case, the following capabilities will be
   utilized:

   o  Asset Identification (see section 4.1) - Hardware and software
      class-level asset identities will be used to identify the
      applicable targets for each configuration guide and within the
      guide specialized targets for licensed features and hardware
      modules.

   o  Asset Characterization - Asset characteristics will be used to
      identify the target endpoint functions addressed by each
      configuration guide.

Waltermire & Harrington  Expires March 16, 2014                 [Page 5]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   o  Asset Targeting - Applicability expressions will be described
      using asset identification and characterization attributes to
      scope the checklist and specific groupings of configurations to
      associated hardware and software products, features, and asset
      functions.

   o  [TODO: Need to list other functions here as the sections
      stabilize.]

   QUESTION: Is providing traceability to functional capabilities
   useful?  If so, we need to replicate this for the other use cases.

3.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 insure
   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.

   Using the gathered software inventory data and associated asset
   management data indicating the organizational defined functions of
   each endpoint, they locate and query each vendors content repository
   for the appropriate checklists.  These checklists are cached locally
   to reduce the need to download the checklist multiple times.

   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 information from each
   endpoint.  Specific data is gathered based on the defined enterprise
   function and software inventory of each endpoint.  The data
   collection paths 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 in each
   applicable checklist.  Deficiencies are identified and reported to
   the appropriate endpoint operators for remedy.

Waltermire & Harrington  Expires March 16, 2014                 [Page 6]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

3.3.  Organizational Software Policy Compliance

   Example Corporation, in support of compliance requirements, has
   identified a number of secure baselines for different endpoint types
   that exist across their enterprise IT environment.  Determining which
   baseline applies to a given endpoint is based on the organizationally
   defined function of the device.

   Each baseline, defined using an automatable standardized data format,
   identifies the expected hardware, software and patch inventory, and
   software configuration item values for each endpoint type.  As part
   of their compliance activities, they require that all endpoints
   connecting to their network meet the appropriate baselines.  Each
   endpoint is checked to make sure it complies with the appropriate
   baseline whenever it connects to the network and at least once a day
   thereafter.  These daily compliance checks assess the posture of each
   endpoint and report on its compliance with the appropriate baseline.

   [TODO: Need to speak to how the baselines are identified for a given
   endpoint connecting to the network.]

3.4.  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 indicating any
   deviations 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.

3.5.  Others...

   Additional use cases will be identified as we work through other
   domains.

4.  Functional Capabilities

Waltermire & Harrington  Expires March 16, 2014                 [Page 7]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   The use cases defined in the previous section highlight various uses
   of endpoint posture assessment to support a variety of IT security
   business processes.  The following subsections address derived
   functional capabilities that are needed to support these use cases.

4.1.  Asset Identification

   Organizations manage a variety of assets within their enterprise
   including: endpoints, the hardware they are composed of, installed
   software, hardware/software licenses used, and configurations.
   Identifying assets is critical for managing information provided
   about and collected from endpoints.  In order to manage these assets
   over time it is necessary to uniquely identify them and to use this
   identification to express asset properties and to establish
   relationships between different assets.

   When possible, stable identification mechanisms should be used that
   will allow the asset to be identified over time enabling information
   pertaining to the asset to be correlated.  In some cases stable asset
   identifiers may not be available or they may change over time due to
   operational conditions.  For example, identifiers may be stable for
   the life of a hardware component.  In other cases (e.g., MAC
   addresses), the identifier may be mutable within software.  In an
   enterprise context it is often necessary to use multiple
   identification viewpoints for an asset to correlate data generated
   from endpoint, network, and human sources.  To deal with these
   scenarios, it is important to use multiple forms of asset
   identification concurrently to allow asset data to be deconflicted
   (see section Section 4.3.

   REQUIREMENT: Many standard and proprietary forms of asset
   identification exist today.  To provide adequate coverage, use of any
   identification mechanism, both standardized and proprietary, SHOULD
   be allowed.

   Object-oriented programming introduces two different concepts when
   dealing with data: classes and instances.  A class represents a data
   type which can be varied in a number of ways, while an instance
   represents a realized variation of a class.  This distinction can be
   applied to identifying assets as described in the following
   subsections.

4.1.1.  Asset Class Identification

Waltermire & Harrington  Expires March 16, 2014                 [Page 8]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   An asset class identifies a distinct type of asset.  Assets
   identified at the class level are useful for describing things that
   can be instantiated or duplicated.  Having the ability to associate
   data with asset classes enable common properties and relationships to
   be expressed that apply to all copies.

   Examples of class-level asset identities include:

   o  Software releases and patches - Identifiers that represent
      distinct software revision releases for firmware, operating
      systems, applications, software suites, and patches and other
      forms of software updates.

   o  Hardware components - Identifiers that distinguish specific parts
      and production runs for hardware devices and components.

   o  Organizational endpoint types - Identifiers that represent
      distinct endpoint configurations associated with a specific
      organizational IT function.

   o  Others? - Please suggest any additional examples on the list

   By identifying different types of assets at the class-level, common
   characteristics (see section 4.2) and content (see section 4.4) can
   be associated.  Using class identification it is possible to define
   relationships between assets and other data including: software
   dependencies, associated patches, supported hardware architectures,
   associated vulnerabilities, and related configuration items.

   In many object-oriented languages classes can exist in hierarchies.
   This enables association of data at different levels of abstraction.
   This is also a useful concept for asset identification.  For example,
   a class may exist for router endpoint types, with subclasses
   representing different vendor product releases.  This enables
   characteristics and content to be associated at various levels of
   abstraction reducing data management challenges.

   A variety of asset identification schemes exist for asset classes,
   including some that can be exposed within an operating environment
   for data collection.  These may include: part numbers and revisions
   for hardware and software product identifiers.  [TODO: We need
   examples of existing standardized asset class identification schemes?

   REQUIREMENT: When available these asset identifiers SHOULD be used to
   identify asset classes in collected and analyzed data.

4.1.2.  Asset Instance Identification

Waltermire & Harrington  Expires March 16, 2014                 [Page 9]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   An asset instance identifies a specific copy or variation of an asset
   identification class.  Identification of asset instances is necessary
   for expressing specific properties and relationships within an
   installed context.  For example a network interface card installed in
   a specific router in branch office's network closet, or a word
   processing application release installed on Bob's desktop.

   Identification of asset instances can be supported using a variety of
   identification schemes.  Hardware vendors often expose asset instance
   identification data to the operating system including: product tags,
   CPU identifiers, etc.  In some cases, such as for software, it may be
   necessary to express instance information as a relation to the
   installed device.  For example, using a software class identifier
   with a hardware identifier to establish the software instance on a
   specific endpoint.  Organizationally provided identifiers can also be
   used to identify assets such as those provided by hardware and
   software certificates, and other configurable identification sources.

   Accessing specific identifiers on an endpoint may require privileges
   on the device.  When identifying an endpoint from a network context,
   or if other forms of device identification are not available or
   access is not authorized, it may be necessary to identify an endpoint
   using network addressing information (e.g., MAC addresses, IP
   addresses).  If only network data is used, additional analysis will
   be needed to correlate an endpoint's identity across multiple
   connection sessions often resulting in partial confidence of the
   assets identity over time.

   Some existing standards support the identification of the hardware
   and the system software on a given endpoint.  For example, the
   SYSTEM-MIB [RFC1213] contains a description of the endpoint, an
   authoritative identifier of the type of endpoint assigned by the
   vendor of the endpoint, an administrative name for the endpoint, plus
   the endpoint's contact person, the location of the endpoint, system
   time, and an enumerator that identifies the layer of services
   provided by the endpoint.  The system description includes the
   vendor, product type, model number, OS version, and networking
   software version.

   Similar information is available via the YANG module ietf-system .
   This module includes data node definitions for system identification,
   time-of-day management, user management, DNS resolver configuration,
   and some protocol operations for system management.

4.2.  Asset Characterization

   TERM: Asset characterization is the process of defining attributes
   that describe properties of an identified asset.

Waltermire & Harrington  Expires March 16, 2014                [Page 10]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   Asset characterization provides additional context that is useful to
   support automated and human decision making as part of operational
   and security processes.  It is necessary to gather, organize, store,
   manage, and exchange a variety of different asset characteristics.
   Often this information helps to bridge automated and human-oriented
   processes.  To assess assets (managed and unmanaged), we need to
   understand the composition and relationships between different assets
   types.  We need the ability to properly characterize assets at the
   outset and over time.

   Managing endpoints, and the different types of assets that compose
   them, involves initially identifying and characterizing each asset.
   This information is important to provide additional context for
   supporting management of assets using human and automated processes.
   Characterization may include business context not otherwise related
   to security, but which may be used as information in support of
   security decision making.  For example, it may be possible to
   automate assessing that an endpoint is out of compliance with
   organizational configuration guidelines, but additional information
   is needed to determine who to notify to correct the configuration.
   Information provided by asset characterization will enable
   notifications to be sent, trouble tickets to be generated, or
   specific reports to be generated at a dashboard for a systems
   administrator.

   The following are examples of useful asset characteristics that may
   be provided:

   For asset classes:

   o  Information pertaining to the developer, manufacturer, and/or
      publisher of hardware and software

   o  The composition, dependencies, and function of hardware and
      software

   o  Production version

   o  Hardware characteristics and software operational requirements
      (e.g., processor architecture, memory, storage, network
      interfaces)

   o  Metadata identifying: product family, edition, licensing

   o  End-of-support dates

   For asset instances:

Waltermire & Harrington  Expires March 16, 2014                [Page 11]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   o  The business and operational context (e.g., required function/
      role, owning organization, responsible parties)

   o  The composition and relationship of its constituent and containing
      assets (e.g., installed hardware and software versions

   o  Assigned location for physical devices

   o  The current location within network(s)

   o  Current/historic operational state (e.g., running software,
      processes, user sessions)

   It can be important to characterize the components of an endpoint,
   including physical and logical components, and the relationships
   between the components, such as containment of components within
   other components, or mappings between logical entities and the
   physical entities used to instantiate them.  The information about
   the physical entities might include manufacturer-assigned serial
   number, manufacture date, an asset identifier for the component, and
   so.  Logical entities may be defined, and associated with the
   physical entities using a mapping table.

   Assets may be characterized based on data collected directly from
   endpoints (see section 4.5.4) or by data provided by humans.  While
   machnine-oriented sources of asset characterization data may be
   preferred, in many cases it is impractical or infeasible to collect
   specific asset details using technical data collection mechanisms.
   This is often true for asset characterization details that relate to
   the business, operational, or security context of the asset.  In
   these cases human data entry is required to provide the necessary
   data.

   Asset characterization data may be made available to tools from a
   variety of sources.  Asset data that is human-oriented and that
   infrequently changes may be provided as records in a content
   repository.  Other sources of asset characterization data may
   include: asset management, configuration management, and other
   enterprise data stores.

   Example standardized data models include the ENTITY-MIB [RFC6933] the
   Q-BRIDGE-MIB MIB [RFC4363] and the MIB for Virtual Machines
   Controlled by a Hypervisor .

   Another example is the HOST-RESOURCES-MIB [RFC2790].

   [QUESTION: Do we need to document more examples?.]

Waltermire & Harrington  Expires March 16, 2014                [Page 12]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   [QUESTION: Are these examples appropriate for this section?  They
   seem to be more about data collection.]

   [QUESTION: It's not clear if aspects of endpoint posture should be
   included in this category.  One way to look at asset characterization
   is that it is metadata that is provided by humans only.  Do we want
   to move concepts that pertain to posture collected from endpoints to
   a different sub-section?]

4.3.  Deconfliction of Asset Identities

   Different tools and data sources will use varying methods for asset
   identification.  These methods should be standardized as much as
   possible to reduce the need for deconfliction.  In reality, it will
   not be possible to standardize all forms of asset identification due
   to legacy, authorization, or network visibility concerns.  In these
   cases, multiple forms of asset identity will need to be collected to
   enable tools to perform correlation of provided asset identification
   data.

   For class-level asset identities, it may be necessary for vendors and
   end-user organizations to provide mapping data enabling translations
   between different representations.  Maintaining mappings between
   asset identification representations is often a labor-intensive,
   manual process that should be avoided by encouraging use of
   standardized asset identifiers.

   For instance-level asset identities, multiple forms of asset
   identification should be provided when collecting data from
   endpoints.  Algorithms can then be used to weight and reconcile
   different types asset identities, and collected characteristics to
   correlate new data collected with historic information pertaining to
   an asset and/or endpoint.  In many cases where insufficient
   identification information is available, it may only be possible to
   associate data collected from different points of view at a minimum
   level of confidence.

4.4.  Asset Targeting

   TERM: Asset targeting is the use of asset identification and
   categorization information to drive human-directed, automated
   decision making for data collection and analysis in support of
   endpoint posture assessment.

   Endpoints, and the assets that compose them, contain a wealth of
   posture information.  It is impractical to collect the full posture
   of all endpoints managed by and accessing resources within an
   organization.  To support practical assessment of endpoint posture,

Waltermire & Harrington  Expires March 16, 2014                [Page 13]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   it is necessary to collect specific posture information from
   endpoints based on an anticipated or actual need for the data.  This
   collection may be performed by polling the endpoint for specific
   posture information on an ad-hoc basis or at regular intervals, or by
   communicating to the endpoint what posture information it should
   monitor and provide when changes occur.  To support both methods, it
   will be necessary to associate what posture details need to be
   collected with asset identification and categorization information
   that describe what types of endpoints and assets that may provide
   these details.  Furthermore, it will be necessary to use asset
   identification and categorization information to identify what assets
   should be evaluated for specific assessments.

   When defining content that drives data collection and analysis
   activities, or that provides information that enriches analysis of
   collected data, the need exists to relate this data to identified
   assets or to categories of assets described by asset characteristics.
   These associations, often called "statements of applicability" are
   critical to exposing information for machine processing.

   Statements of applicability enable digital policies (e.g.,
   checklists, baselines, access control rules), data records (e.g.,
   vulnerability data, associations of patches to software) to be
   associated with asset, security, operational, and business contexts.
   Using these associations, applicable content can be queried in
   content repositories and made available at the points where the data
   needs to be used.  They also enable humans to query and (re)use
   content provided by other individuals in their organization, by
   vendors, and 3rd parties in constructing policies and configuring
   data collection and analysis tools.

   For example, in order to establish an understanding of the security
   state of endpoints managed by an organization, the security system
   needs to be able to make use of various asset management data.  It
   needs to:

   o  Determine what is the expected state for those endpoints.  To do
      this it will need to identify what expected state criteria is
      associated with the endpoint based on the identification and
      characterization of the endpoint, and any assets that compose the
      endpoint.

Waltermire & Harrington  Expires March 16, 2014                [Page 14]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   o  Once the criteria is identified, it will need to determine what
      actual state data is needed to feed the analysis.  This data will
      need to be retrieved from existing data stores and from the
      endpoints directly if necessary.  Data collection rules may be
      associated with specific asset identifiers or characteristics that
      indicate what data sources or collectors to use to acquire the
      data.

   o  Once the necessary actual state information is acquired, the
      evaluator may need additional content to perform the analysis.
      Based on the collected information, specific records will be
      queried from a content repository based on asset identifiers and
      characteristics.

   o  Finally, the appropriate assessment can be performed.

4.5.  Other Unedited Content

   The current editorial focus has been on the old asset management
   subsection.  The content in these subsections needs to be reworked
   next.

4.5.1.  Endpoint Configuration Management

   Organizations manage a variety of configurations within their
   enterprise including: endpoints, the hardware they are composed of,
   installed software, hardware/software licenses used, and
   configurations.

   Security configuration management (SCM) deals with the configuration
   of endpoints, including networking infrastructure devices and
   computing hosts.  Data will include installed hardware and software,
   its configuration, and its use on the endpoint.

   [TODO: While some configuration settings might not be considered
   security relevant, it is not always possible to draw a clear
   distinction between security and non-security settings (e.g., power
   saving features).  Do we want to make a distinction between security
   and non-security configuration settings?]

   The following list details some requisite Configuration Management
   capabilities:

   o  [todo]

4.5.1.1.  Organizing Configuration Metadata

Waltermire & Harrington  Expires March 16, 2014                [Page 15]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   Configuration metadata supports tooling helping organizations
   understand what configuration they should implement, using specific
   configuration values.

   Enable data repositories containing machine-readable representations
   of:

      Configuration scoring: Characterizations of the relative security
      value of discrete configuration settings and specific values

      Configuration dependencies (e.g., lists of settings, associated
      software, pre-requisite configurations)

      Control catalog mappings supporting compliance [todo: in scope?]

4.5.1.2.  Publishing Recommended Configuration Posture

   Provide a mechanism for vendors and organizations to exchange
   machine-oriented descriptions of recommended configuration setting
   for software products.  Enable organizations to apply recommended
   settings as expected configuration posture.  Enable association of
   data-driven collection instructions using appropriate formats.

4.5.1.3.  Defining Organizationally Expected Configuration Posture

   Provide a mechanism for organizations to define and exchange expected
   configuration posture including: authorized software and associated
   configuration settings.

   [TODO: Should software installation posture be defined separately?]

4.5.1.4.  Collecting Endpoint Configuration Posture

   Enable collection and exchange of actual configuration posture
   including: installed software and values for configured settings.

   [TODO: Should collecting software installation posture be defined
   separately?]

4.5.1.5.  Comparing Expected and Actual Configuration Posture

   Enable evaluation of actual configuration posture against expected
   configuration posture.  Generate a machine-oriented description of
   conformant and non-conformant posture including software inventory
   and configuration values.

   [TODO: Should collecting software installation posture be defined
   separately?]

Waltermire & Harrington  Expires March 16, 2014                [Page 16]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   [TODO: Examining software version configuration - Example - HOST-
   RESOURCES-MIB

4.5.1.6.  Examining configuration of logical to physical mappings

   [TODO: not sure what this is?  Is it in scope?]

   Example - ENTITY-MIB

4.5.1.7.  Configuring Endpoint Interfaces

   [TODO: not sure what this is?  Is it in scope?]

   Example - YANG module ietf-interfaces

4.5.2.  Endpoint Posture Change Management

   Organizations manage a variety of changes within their enterprise
   including: [todo]

   The following list details some requisite Change Management
   capabilities:

   o  [todo]

4.5.2.1.  Defining and Exchanging Baselines

   [todo]

4.5.2.2.  Detecting Unauthorized Changes

   [todo]

   [todo: figure out where these need to go]

4.5.2.2.1.  Endpoint Addressing Changes

   Example - DHCP addressing

4.5.2.2.2.  Service Authorization Changes

   Example - RADIUS network access

Waltermire & Harrington  Expires March 16, 2014                [Page 17]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

4.5.2.2.3.  Dynamic Resource Assignment Changes

   Example - NAT logging

4.5.2.2.4.  Security Authorization Status Changes

   Example - SYSLOG Authorization messages.  SYSLOG [RFC5424] includes
   facilities for security authorization messages.  These messages can
   be used to alert an analysts that an authorization attempt failed,
   and the analyst might choose to follow up and assess potential
   attacks on the relevant endpoint.

4.5.3.  Security Vulnerability Management

   Vulnerability management involves identifying the patch level of
   software installed on the device and the identification of insecure
   custom code (e.g. web vulnerabilities).  All vulnerabilities need to
   be addressed as part of a comprehensive risk management program,
   which is a superset of software vulnerabilities.  Thus, the
   capability of assessing non-software vulnerabilities applicable to
   the system is required.  Additionally, it may be necessary to support
   non-technical assessment of data relating to assets such as aspects
   related to operational and management controls.

   policy attribute collection

   The following list details some requisite Vulnerability Management
   capabilities:

   o  Collect the state of non-technical controls commonly called
      administrative controls (i.e. policy, process, procedure)

   o  Collect the state of technical controls including, but not
      necessarily limited to:

      *  Software inventory (e.g. operating system, applications,
         patches)

      *  Configuration settings

4.5.3.1.  Example - NIDS response

Waltermire & Harrington  Expires March 16, 2014                [Page 18]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   1.  An organization's Network Intrusion Detection System detects a
   suspect packet received by an endpoint and sends an alert to an
   analyst.  The analyst looks up the endpoint in the asset inventory
   database, looks up the configuration policy associated with that
   endpoint, and initiates an endpoint assessment of installed software
   and patches on the endpoint to determine if the endpoint is compliant
   with policy.

   The analyst reviews the results of the assessment and takes action
   according to organization policy and procedures.

4.5.3.2.  Example - Historical vulnerability analysis

   When a serious vulnerability or a zero-day attack is discovered, one
   of the first priorities in any organization is to determine which
   endpoints may have been affected and assess those endpoints to try to
   determine whether they were compromised.  Checking current endpoint
   state is not sufficient because an endpoint may have been temporarily
   compromised due to this vulnerability and then the infection may have
   removed itself.  In fact, the vulnerable software may have been
   removed or upgraded since the compromise took place.  And if the
   endpoint is still compromised, the malware on the endpoint may cause
   it to lie about its configuration.  In this environment, maintaining
   historical information about endpoint configuration is essential.
   Such information can be used to find endpoints that had the
   vulnerable software installed at some point in time.  Those endpoints
   can be checked for current or past indicators of compromise such as
   files or behavior linked to a known exploit for this vulnerability.
   Endpoints found to be vulnerable can be isolated to prevent infection
   while remediation is done.  Endpoints believed to be compromised can
   be isolated for analysis and to limit the spread of infection.

4.5.3.3.  Source Address Validation

   Source Address Validation Improvement methods were developed to
   prevent nodes attached to the same IP link from spoofing each other's
   IP addresses, so as to complement ingress filtering with finer-
   grained, standardized IP source address validation.  The framework
   document describes and motivates the design of the SAVI methods.
   Particular SAVI methods are described in other documents.

4.5.4.  Data Collection

   Central to any automated assessment solution is the ability to
   collect data from, or related to, an endpoint, such as the security
   state of the endpoint and its constituent assets.

Waltermire & Harrington  Expires March 16, 2014                [Page 19]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   So, is data collection a requirement or an architectural concept
   rather than a use case?

   QUESTION: Understand more about what is meant by non-software
   vulnerabilities

4.5.5.  Assessment Result Analysis

   The data collected needs to be analyzed for compliance to a standard
   stipulated by the enterprise.  Analysis methods may vary between
   enterprises, but commonly take a similar form.

   The following capabilities support the analysis of assessment
   results:

   o  Comparing actual state to expected state

   o  Scoring/weighting individual comparison results

   o  Relating specific comparisons to benchmark-level requirements

   o  Relating benchmark-level requirements to one or more control
      frameworks

4.5.6.  Content Management

   The capabilities required to support risk management state
   measurement will yield volumes of content.  The efficacy of risk
   management state measurement depends directly on the stability of the
   driving content, and, subsequently, the ability to change content
   according to enterprise needs.

   Capabilities supporting Content Management should provide the ability
   to create/define or modify content, as well as store and retrieve
   said content of at least the following types:

   o  Configuration checklists

   o  Assessment rules

   o  Data collection rules and methods

   o  Scoring models

   o  Vulnerability information

   o  Patch information

Waltermire & Harrington  Expires March 16, 2014                [Page 20]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   o  Asset characterization data and rules

   Note that the ability to modify content is in direct support of
   tailoring content for enterprise-specific needs.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   This memo documents, for Informational purposes, use cases for
   security automation.  While it is about security, it does not affect
   security.

7.  Acknowledgements

   The National Institute of Standards and Technology (NIST) and/or the
   MITRE Corporation have developed specifications under the general
   term "Security Automation" including languages, protocols,
   enumerations, and metrics.

   The authors would like to recognize and thank Adam Montville for his
   work on early edits of this draft.  Additionally, the authors would
   like to thank Kathleen Moriarty and Stephen Hanna for contributing
   text to this document.  The authors would also like to acknowledge
   the members of the SACM mailing list for their keen and insightful
   feedback on the concepts and text within this document.

8.  Change Log

8.1.  -00- to -01-

   o  Work on this revision has been focused on document content
      relating primarily to use of asset management data and functions.

   o  Made significant updates to section 3 including:

      *  Reworked introductory text.

      *  Replaced the single example with multiple use cases that focus
         on more discrete uses of asset management data to support
         hardware and software inventory, and configuration management
         use cases.

      *  For one of the use cases, added mapping to functional
         capabilities used.  If popular, this will be added to the other
         use cases as well.

Waltermire & Harrington  Expires March 16, 2014                [Page 21]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

      *  Additional use cases will be added in the next revision
         capturing additional discussion from the list.

   o  Made significant updates to section 4 including:

      *  Renamed the section heading from "Use Cases" to "Functional
         Capabilities" since use cases are covered in section 3.  This
         section now extrapolates specific functions that are needed to
         support the use cases.

      *  Started work to flatten the section, moving select subsections
         up from under asset management.

      *  Removed the subsections for: Asset Discovery, Endpoint
         Components and Asset Composition, Asset Resources, and Asset
         Life Cycle.

      *  Renamed the subsection "Asset Representation Reconciliation" to
         "Deconfliction of Asset Identities".

      *  Expanded the subsections for: Asset Identification, Asset
         Characterization, and Deconfliction of Asset Identities.

      *  Added a new subsection for Asset Targeting.

      *  Moved remaining sections to "Other Unedited Content" for future
         updating.

8.2.  draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00

   o  Transitioned from individual I/D to WG I/D based on WG consensus
      call.

   o  Fixed a number of spelling errors.  Thank you Erik!

   o  Added keywords to the front matter.

   o  Removed the terminology section from the draft.  Terms have been
      moved to: draft-dbh-sacm-terminology-00

   o  Removed requirements to be moved into a new I/D.

   o  Extracted the functionality from the examples and made the
      examples less prominent.

   o  Renamed "Functional Capabilities and Requirements" section to "Use
      Cases".

Waltermire & Harrington  Expires March 16, 2014                [Page 22]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

      *  Reorganized the "Asset Management" sub-section.  Added new text
         throughout.

         +  Renamed a few sub-section headings.

         +  Added text to the "Asset Characterization" sub-section.

   o  Renamed "Security Configuration Management" to "Endpoint
      Configuration Management".  Not sure if the "security" distinction
      is important.

      *  Added new sections, partially integrated existing content.

      *  Additional text is needed in all of the sub-sections.

   o  Changed "Security Change Management" to "Endpoint Posture Change
      Management".  Added new skeletal outline sections for future
      updates.

8.3.  -04- to -05-

   o  Are we including user activities and behavior in the scope of this
      work?  That seems to be layer 8 stuff, appropriate to an IDS/IPS
      application, not Internet stuff.

   o  I removed the references to what the WG will do because this
      belongs in the charter, not the (potentially long-lived) use cases
      document.  I removed mention of charter objectives because the
      charter may go through multiple iterations over time; there is a
      website for hosting the charter; this document is not the correct
      place for that discussion.

   o  I moved the discussion of NIST specifications to the
      acknowledgements section.

   o  Removed the portion of the introduction that describes the
      chapters; we have a table of concepts, and the existing text
      seemed redundant.

   o  Removed marketing claims, to focus on technical concepts and
      technical analysis, that would enable subsequent engineering
      effort.

   o  Removed (commented out in XML) UC2 and UC3, and eliminated some
      text that referred to these use cases.

   o  Modified IANA and Security Consideration sections.

Waltermire & Harrington  Expires March 16, 2014                [Page 23]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   o  Moved Terms to the front, so we can use them in the subsequent
      text.

   o  Removed the "Key Concepts" section, since the concepts of ORM and
      IRM were not otherwise mentioned in the document.  This would seem
      more appropriate to the arch doc rather than use cases.

   o  Removed role=editor from David Waltermire's info, since there are
      three editors on the document.  The editor is most important when
      one person writes the document that represents the work of
      multiple people.  When there are three editors, this role marking
      isn't necessary.

   o  Modified text to describe that this was specific to enterprises,
      and that it was expected to overlap with service provider use
      cases, and described the context of this scoped work within a
      larger context of policy enforcement, and verification.

   o  The document had asset management, but the charter mentioned
      asset, change, configuration, and vulnerability management, so I
      added sections for each of those categories.

   o  Added text to Introduction explaining goal of the document.

   o  Added sections on various example use cases for asset management,
      config management, change management, and vulnerability
      management.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
              for Network Management of TCP/IP-based internets:MIB-II",
              STD 17, RFC 1213, March 1991.

   [RFC2790]  Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
              2790, March 2000.

Waltermire & Harrington  Expires March 16, 2014                [Page 24]
Internet-DraftEnterprise Use Cases for Security AssessmentSeptember 2013

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC2922]  Bierman, A. and K. Jones, "Physical Topology MIB", RFC
              2922, September 2000.

   [RFC4363]  Levi, D. and D. Harrington, "Definitions of Managed
              Objects for Bridges with Traffic Classes, Multicast
              Filtering, and Virtual LAN Extensions", RFC 4363, January
              2006.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.

   [RFC6933]  Bierman, A., Romascanu, D., Quittek, J., and M.
              Chandramouli, "Entity MIB (Version 4)", RFC 6933, May
              2013.

Authors' Addresses

   David Waltermire
   National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, Maryland  20877
   USA

   Email: david.waltermire@nist.gov

   David Harrington
   Effective Software
   50 Harding Rd
   Portsmouth, NH  03801
   USA

   Email: ietfdbh@comcast.net

Waltermire & Harrington  Expires March 16, 2014                [Page 25]