| Security Automation and Continuous Monitoring WG | D.W. Waltermire |
| Internet-Draft | NIST |
| Intended status: Informational | A.W.M. Montville |
| Expires: January 16, 2014 | TW |
| D.B.H. Harrington | |
| Effective Software | |
| July 15, 2013 |
Using Security Posture Assessment to Grant Access to Enterprise Network Resources
draft-waltermire-sacm-use-cases-05
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 January 16, 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 analyse 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.
assessment
asset
attribute
endpoint
posture
posture attributes
system resource
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 collecting information about the posture of a given endpoint. This 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:
In order to meet compliance requirements and ensure that corporate finance information is not revealed improperly, all computers in the finance department of Example Corporation are required to run only software contained on an approved list and to be configured to download and install software patches every night. Each computer is checked to make sure it complies with this policy whenever it connects to the network and at least once a day thereafter. These daily compliance checks assess the posture of each computer and report on its compliance with policy.
The capabilities in this section support assessing endpoint posture in an automated manner as described in Section Section 3.
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.
Managing endpoints and the different types of assets that compose them involves initially discovering and characterizing each asset instance, and then identify them in a common way. Characterization may take the form of logical characterization or security characterization, where logical characterization may include business context not otherwise related to security, but which may be used as information in support of decision making later in risk management.
Many network management systems detect the presence of assets in a subnet, such as an Ethernet subnet, by monitoring the MAC addresses bradcast within the subnet to determine who responds to broadcasts, and determing the location of the endpoint relative to a bridge. This information is useful for initally discovering and characterizing endpoints belonging to a particular type of network (e.g. Ethernet), and for detecting new nodes in the subnet. This type of information may be accessible by accessing ARP tables [RFC0826], Etherlike-MIB [RFC3535], the Link Layer Discovery Protocol MIB [RFC2922], the Interfaces MIB (IF-MIB) [RFC2863], the YANG module ietf-interfaces , and others.
Many network management systems periodically test for the presence of endpoints or interfaces in a network by broadcasting ICMP echo commands (pings) to a range of IP addresses and recording the addresses of nodes that respond. This helps discover the endpoints in the network, including endpoints that have suddenly appeared in a network tha are not authorized to be part of the network.
The SYSTEM-MIB [RFC1213] contains information to help characterize an endpoint, including 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 decription includes the vendor, product type, model number, OS version, and networking software version. This is a key MIB module mandated for all SNMP-managed endpoints.
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.
The ENTITY-MIB [RFC6933] contains information to describe the components of an endpoint, including physical and logical components, and the relationships between the components. The information about the physical entities includes manufacturer-assigned serial number, manufacture date, administratively-assigned AssetID, and UUID. Logical entities may be defined, and associated with the physical entities using a mapping table.
The HOST-RESOURCES-MIB [RFC2790] contains information to describe the resources of an endpoint, including storage, memory, installed software, running software, software versions, processes, user sessions, devices (processors, disks, printers, network interfaces, etc.). This MIB module also provides monitoring of performance and error states.
Managing endpoints and the different types of assets that compose them involves initially discovering and characterizing each asset instance, and then identify them in a common way. Characterization may take the form of logical characterization or security characterization, where logical characterization may include business context not otherwise related to security, but which may be used as information in support of decision making later in risk management.
Coverage involves understanding what and how many assets are under control. Assessing 80% of the enterprise assets is better than assessing 50% of the enterprise assets.
Getting asset details can be comparatively subtle - if an enterprise does not have a precise understanding of its assets, then all acquired data and consequent actions taken based on the data are considered suspect.
Assessing assets (managed and unmanaged) requires that we have visibility into the posture of endpoints, the ability to understand the composition and relationships between different assets types, and the ability to properly characterize them at the outset and over time.
The following list details some requisite Asset Management capabilities:
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.
The following list details some requisite Configuration Management capabilities:
Organizations manage a variety of changes within their enterprise including: [todo]
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.
[todo]
The following list details some requisite Change Management capabilities:
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
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 associtaed with that endpoint, and initates 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.
The following list details some requisite Vulnerability Management capabilities:
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.
The following assessment capabilities support SCM:
One or more data formats MUST be identified to describe instructions, data collection methods, to drive data collection (e.g. technical, interrogative).
One or more data formats MUST be identified to instruct what posture attributes need to be collected for a specific set of endpoints.
A method MUST be provided for retrieving data collection instructions from a remote host (see Section Section 4.7).
One or more data formats MUST be identified to capture the results of data collection.
A method of communicating data collection results to another system for further analysis MUST be identified.
TODO: Communicate, unambiguously and to the necessary level of detail**, the asset details between software components
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:
A method MUST be provided for selecting acceptable state policy, describing how to evaluate collected information, based on characteristics of the endpoint and organizational policy.
A method MUST be provided for comparing collected data to expected state values (test evaluation).
Any results produced by analysis processes MUST be capable of being transformed into a human-readable format.
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.
A protocol MUST be identified for retrieving SACM content from a content repository
A protocol MUST be identified for querying SACM content held in a content repository. The protocol MUST support querying content by applicability to asset characteristics.
A protocol MUST be identified for curating SACM content in a content repository. Note: This might be an area where we can limit the scope of work relative to the initial SACM charter.
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 thank Kathleen Moriarty and Stephen Hanna for contributing text to this document. The author 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. |