| Security Automation and Continuous Monitoring WG | D.W. Waltermire |
| Internet-Draft | NIST |
| Intended status: Informational | D.B.H. Harrington |
| Expires: March 15, 2014 | Effective Software |
| September 11, 2013 |
Using Security Posture Assessment to Grant Access to Enterprise Network Resources
draft-ietf-sacm-use-cases-01
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.
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 15, 2014.
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 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.
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.
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.
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].
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:
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:
The following subsections detail specific use cases for data collection, analysis, and related operations pertaining to the publication and use of supporting content.
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:
QUESTION: Is providing traceability to functional capabilities useful? If so, we need to replicate this for the other use cases.
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.
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.]
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.
Additional use cases will be identified as we work through other domains.
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.
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.
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:
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.
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.
TERM: Asset characterization is the process of defining attributes that describe properties of an identified asset.
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:
For asset instances:
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?.]
[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?]
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.
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, 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:
The current editorial focus has been on the old asset management subsection. The content in these subsections needs to be reworked next.
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:
Configuration metadata supports tooling helping organizations understand what configuration they should implement, using specific configuration values.
Enable data repositories containing machine-readable representations of:
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.
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?]
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?]
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?]
[TODO: Examining software version configuration - Example - HOST-RESOURCES-MIB
[TODO: not sure what this is? Is it in scope?]
Example - ENTITY-MIB
[TODO: not sure what this is? Is it in scope?]
Example - YANG module ietf-interfaces
Organizations manage a variety of changes within their enterprise including: [todo]
The following list details some requisite Change Management capabilities:
[todo]
[todo]
[todo: figure out where these need to go]
Example - DHCP addressing
Example - RADIUS network access
Example - NAT logging
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.
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:
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.
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.
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.
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.
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
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:
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:
Note that the ability to modify content is in direct support of tailoring content for enterprise-specific needs.
This memo includes no request to IANA.
This memo documents, for Informational purposes, use cases for security automation. While it is about security, it does not affect security.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [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. |
| [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. |