+---------------------------------------+  +-------------+
  |                                       |  |             |
  |     Operational Risk Management       |  |             |
  |                                       |  |             |
  +---------------------------------------+  |             |
                                             |             |
  +---------------------------------------+  |             |
  |                                       |  |             |
  |     Information Risk Management       |  |   Policy    |
  |                                       |  |   Process   |
  +---------------------------------------+  |   Procedure |
                                             |             |
  +---------------------------------------+  |             |
  |                                       |  |             |
  |     Control Frameworks                |  |             |
  |                                       |  |             |
  +---------------------------------------+  |             |
                                             |             |
  +---------------------------------------+  |             |
  |                                       |  |             |
  |     Controls                          |  |             |
  |                                       |  |             |
  +---------------------------------------+  +-------------+
        
        

Figure 1

The figure above provides some context for our focus area. Organizations of all sizes will have a more or less formal risk management program, depending upon their maturity and organization-specific needs. A small business with only a few employees may not have a formally recognized risk management program, but they still lock the doors at night. Typically, financial entities and governments sit at the other end of the spectrum with often large, laborious risk frameworks. The point is that all organizations practice, to some degree, Operational Risk Management (ORM). An Information Risk Management (IRM) program is most likely a constituent of ORM (another constituent might be Financial Risk Management). In the Information Risk Management domain, we often use control frameworks to provide guidance for organizations practicing ORM in an information context, and these control frameworks define a variety of controls.

From ORM, IRM, control frameworks, and the controls themselves, organizations derive a set of organization-specific policies, processes, and procedures. Such policies, processes, and procedures make use of a library of supporting information commonly stipulated by the organization (i.e. enterprise acceptable use policies), but often prescribed by external entities (i.e. Payment Card Industry Data Security Standards, Sarbanes-Oxley, or EU Data Privacy Directive). The focus of this document spans controls, certain aspects of policy, process, and procedure, and control frameworks.

3. Use Cases

This document addresses three use cases: Endpoint Posture Assessment, Enforcement of Acceptable State, Security Control Verification and Monitoring. Currently, the first use case, Endpoint Posture Assessment, is being pursued under the SACM charter. The additional use cases are included to provide broader context to this work and represents additional work that may be considered by SACM or another IETF working group in the future.

3.1. UC1: Endpoint Posture Assessment

The Endpoint Posture Assessment use case 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.

3.1.1. Goals

The primary goals of the endpoint Posture Assessment use case is:

• To collect the posture of a given endpoint;
• Make that posture available to the enterprise for further analysis and action; and
• To assess that the endpoint's posture is in compliance with enterprise standards and, therefore, ensure alignment with enterprise policy.

3.1.2. Main Success Scenario

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
6. Compare collected posture attributes from the target endpoint with expected state values as expressed in acceptable state policies

3.2. UC2: Enforcement of Acceptable State

Controlling access to a desired resource based on the compliance of an endpoint or user with enterprise policy.

3.2.1. Goal

Allow or deny access to a desired resource based on the compliance of an endpoint or user with enterprise policy.

3.2.2. Main Success Scenario

1. An entity (user on an endpoint or the endpoint itself) requests access to a given resource (i.e. network connection, service)
2. Assessment of endpoint posture is achieved using UC1: Endpoint Posture Assessment
3. Based on assessment results (i.e. compliance level with enterprise policy)
   1. Endpoint or user is allowed access to requested resource, or
   2. Endpoint or user is denied access to requested resource

3.3. UC3: Security Control Verification and Monitoring

This use case involves continuous (uninterrupted) and continual (periodic) monitoring of a set of target endpoints to determine the degree of compliance with acceptable state policies within an enterprise.

3.3.1. Goal

Continuous assessment of the implementation and effectiveness of security controls based on machine processable content.

3.3.2. Main Success Scenario

1. Define set of target endpoints to be assessed.
2. Select acceptable state policies to apply to set of target endpoints
3. Define assessment trigger based on either a
   1. Time period, or
   2. An event (e.g. endpoint, network, organizational).

4. Define result reporting/alerting criteria
5. Enable continuous assessment

4. Functional Capabilities and Requirements

In general, the activities of managing assets, configurations, and vulnerabilities are common between UC1, UC2, and UC3. UC2 uses these activities to either grant or deny an entity access to a requested resource. UC3 uses these activities in support of compliance measurement on a periodic basis.

At the most basic level, an enterprise needing to satisfy these use cases will need certain capabilities to be met. Specifically, we are talking about risk management capabilities. This is the central problem domain, so it makes sense to be able to convey information about technical and non-technical controls, benchmarks, control requirements, control frameworks and other concepts in a common way.

4.1. Capabilities Supporting UC1

The capabilities in this section support assessing endpoint posture in an automated manner as described in Section Section 3.1.

4.1.1. Asset Management

Organizations manage a variety of assets within their enterprise. Supporting the use cases in this document requires management of assets including: endpoints, the hardware they are composed of, installed software, hardware/software licenses used, and any appropriate configurations. Effective Asset Management is a critical foundation upon which all else in risk management is based. There are two important facets to asset management: 1) understanding coverage (what and how many assets are under control) and, 2) understanding specific asset details. Coverage is fairly straightforward - assessing 80% of the enterprise assets is better than assessing 50% of the enterprise assets. Getting asset details is 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.

4.1.1.1. Concepts

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

The following list details the requisite Asset Management capabilities:

• Discover assets in the enterprise
• For a given endpoint, understand the composition and relationship of its constituent assets
• Characterize assets according to security and non-security asset properties
• Identify and describe assets using a common vocabulary between implementations
• Reconcile asset representations originating from disparate tools
• Manage asset information throughout the asset's life cycle

4.1.1.2. Requirements

A method MUST be provided for identifying an endpoint (asset identification) as a unique entity within the enterprise.

• The endpoint identifier SHOULD be able to be determined in an automated manner.
• The endpoint identifier, as communicated between entities, SHOULD be held to a minimal size.

A method MUST be provided for defining an endpoint (asset classification) based on a set of organizationally relevant properties (e.g. organizational affiliation, criticality, function).

4.1.2. Data Collection

Related to managing the assets related to endpoints, and central to any automated assessment solution, is the ability to collect data from (or related to) an endpoint (some might call this "harvesting"). Of particular interest is data representing the security state of the endpoint and its constituent assets. The primary interest of the activities demanding data collection is centered on policy attribute collection related to installed hardware and software configuration items, and network device configuration items among others.

4.1.2.1. Concepts

There are many valid perspectives to take when considering required data collection capabilities. The nature of data collected relating to endpoints supports a variety of information domains including: security configuration management (SCM) and vulnerability management. SCM deals with the configuration of endpoints (infrastructure devices and computing hosts) including the software installed and in use on these devices. 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 in-scope 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.

The following assessment capabilities support SCM relative to a target asset:

• Collect the state of technical controls including, but not necessarily limited to:
  • Software inventory (e.g. operating system, applications, patches)
  • Configuration settings

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

4.1.2.2. Requirements

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 to include OPTIONAL instructions on describing what content must be run on the endpoint.
• A method MUST be provided to include OPTIONAL instructions that determine how to collect data supporting any particular test for that endpoint.

A method MUST be provided for retrieving data collection instructions from a remote host (see Section Section 4.1.4).

One or more data formats MUST be identified to capture the results of data collection.

• This expression MUST be capable of supporting the characterization of assets and any related configuration settings that together compose an endpoint.
  • A mechanism MUST be provided to identify the software and hardware asset instances that compose an endpoint.
    • An asset identifier SHOULD be able to be determined in an automated manner
    • An asset identifier, as communicated between entities, SHOULD be held to a minimal size.
    • An asset identifier SHOULD be able to represented in a simple unambiguous manner, such as a reference, so that its embedded use in places like applicability clauses for individual benchmark tests can be kept from making their usage unwieldy.

  • A mechanism MUST be provided to associate configuration settings values to the installed software.
  • A mechanism MUST be provided to identify additional collected posture attribute/value pairs related to an endpoint.

• A mechanism MUST be provided to identify the endpoint the results pertain to (see Section Section 4.1.1.
• A mechanism MUST be provided to associate the data collection method with the collected value.
• A mechanism MUST be provided to include provenance information describing what sensor of software collected the data.
• A mechanism MUST be provided to include entailment information, perhaps by reference, describing the methodology used to collect the data.

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

4.1.3. Assessment Result Analysis

At the most basic level, 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.

4.1.3.1. Concepts

The following capabilities support the analysis of assessment results:

• Comparing actual state to expected state
• Scoring/weighting individual comparison results
• Relating specific comparisons to benchmark-level requirements
• Relating benchmark-level requirements to one or more control frameworks

4.1.3.2. Requirements

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.

4.1.4. Content Management

It should be clear by now that 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.

4.1.4.1. Concepts

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:

• Configuration checklists
• Assessment rules
• Data collection rules and methods
• Scoring models
• Vulnerability information
• Patch information
• Asset characterization data and rules

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

4.1.4.2. Requirements

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.

• TODO: Determine what content can or must be run on the endpoint

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.

4.2. Capabilities Supporting UC2

UC2 is dependent upon UC1 and, therefore, includes all of the capabilities described in Section Section 4.1. UC2 describes the ability to make a resource access decision based on an assessment of the requesting system (either by the system itself or on behalf of a user operating that system). There are two chief capabilities required to meet the needs expressed in Section Section 3.2: Assessment Query and Transport, and Acceptable State Enforcement.

4.2.1. Assessment Query and Transport

Under certain circumstances, the system requesting access may be unknown, which can make querying the system problematic (consider a case where a system is connecting to the network and has no assessment software installed). Note that The Network Endpoint Assessment (NEA) protocols (PA-TNC [RFC5792], PB-TNC [RFC5793], PT-TLS [I-D.ietf-nea-pt-tls], and PT-EAP [I-D.ietf-nea-pt-eap]) may be used to query and transport the things to be measured.

4.2.2. Acceptable State Enforcement

Once the assessment has been performed a decision to allow or deny access to the requested resource can be made. Making this decision is a necessary but insufficient condition for enforcement of acceptable state, and an implementation must have the ability to actively allow or deny access to the requested resource. For example, network enforcement may be implemented with RADIUS [RFC2865] or DIAMETER [RFC6733].

4.3. Capabilities Supporting UC3

Recall that UC3 is dependent upon UC1 and therefore includes all of the capabilities described in Section 4.1. The difference in UC3 is the notion of when to assess rather than what to assess. Therefore, the capabilities described in this section are relevant only to the "when" and not to the "what."

4.3.1. Tasking and Scheduling

The ability to task and schedule assessments is requisite for any effective risk management program. Tasking refers to the ability to create a set of instructions to be conveyed at a later time via scheduling. Tasking, therefore, involves selecting a set of assessment criteria, assigning that set to a group of assets, and expressing that information in a manner that can be consumed by a collection tool. Scheduling comes into play when the enterprise determines when to perform a specific assessment task (or set of tasks). Scheduling may be expressed in a way that constrains tasks to execute only during defined periods, can be ad hoc, or may be triggered by the analysis of previous assessment results or events detected in the enterprise.

The following capabilities support Tasking and Scheduling:

• Selection of assessment criteria
• Defining in-scope assets (i.e. targeting)
• Defining periodic assessments for a given set of tasks
• Defining assessment triggers for a given set of tasks

4.3.2. Data Aggregation and Reporting

Assessment results are produced for every asset assessed, and these results must be reported not only individually, but in the aggregate, and in accordance with enterprise needs. Enterprises should be able to aggregate and report on the data their assessments produce in a number of different ways in order to support different levels of decision making. At times, security operations personnel may be interested in understanding where the most critical risks exist in their enterprise so as to focus their remediation efforts in the most effective way (in terms of cost and return). At other times, only aggregated scores will matter, as might be the case when reporting to an information security manager or other executive-level role.

It is not the position of these capabilities to provide explicit details about how reports should be formatted for presentation, but only what information they should contain for a particular purpose. Furthermore, it is quite easy to imagine the need for a capability providing extensibility to aggregation and reporting.

Aggregating assessment results by the following capabilities supports Data Aggregation and Reporting

• By asset characterization
• By assessment criteria
• By control framework
• By benchmark
• By other attributes/properties of assessment characteristics
• Extensible aggregation and reporting

5. IANA Considerations

This memo includes no request to IANA.

All drafts are required to have an IANA considerations section (see RFC 5226 [RFC5226] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

6. Security Considerations

All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide.

This section needs to be fleshed out to include concerns including:

• Authentication
• Authorization
• Endpoint and user identity management
• Encryption of communications
• Content signing and validation
• etc...

While not strictly a security concern, network bandwidth and similar communications requirements also need to be addressed.

7. Terms and Definitions

assessment

• Defined in [RFC5209] as "the process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy."
• Within this document the use of the term is expanded to support other uses of collected posture (e.g. reporting, network enforcement, vulnerability detection, license management). The phrase "set of capabilities on the endpoint" includes: hardware and software installed on the endpoint."

asset

• Defined in [RFC4949] as "a system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protect by a countermeasure, or (c) required for a system's mission.

attribute

• Defined in [RFC5209] as "data element including any requisite meta-data describing an observed, expected, or the operational status of an endpoint feature (e.g., anti-virus software is currently in use)."

endpoint

• Defined in [RFC5209] as "any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address."
• Network infrastructure devices (e.g. switches, routers, firewalls), which fit the definition, are also considered to be endpoints within this document.
• Based on the previous definition of an asset, an endpoint is a type of asset.

posture

• Defined in [RFC5209] as "configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy."
• This term is used within the scope of this document to represent the state information that is collected from an endpoint (e.g. software/hardware inventory, configuration settings).

posture attributes

• Defined in [RFC5209] as "attributes describing the configuration or status (posture) of a feature of the endpoint. For example, a Posture Attribute might describe the version of the operating system installed on the system."
• Within this document this term represents a specific assertion about endpoint state (e.g. configuration setting, installed software, hardware). The phrase "features of the endpoint" refers to installed software or software components.

system resource

• Defined in [RFC4949] as "data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment.

8. Acknowledgements

The author 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.

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

[RFC2865]	Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC3552]	Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC4949]	Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC5209]	Sangster, P., Khosravi, H., Mani, M., Narayan, K. and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5792]	Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[RFC5793]	Sahita, R., Hanna, S., Hurst, R. and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010.
[RFC6733]	Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[I-D.ietf-nea-pt-eap]	Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Internet-Draft draft-ietf-nea-pt-eap-06, December 2012.
[I-D.ietf-nea-pt-tls]	Sangster, P., Cam-Winget, N. and J. Salowey, "PT-TLS: A TLS-based Posture Transport (PT) Protocol", Internet-Draft draft-ietf-nea-pt-tls-08, October 2012.

Authors' Addresses