In accordance with NIST Special Publication 800-53, organizations may define a set of security capabilities or privacy capabilities as a precursor to the security control or privacy control selection process. The concept of capability39 recognizes that the protection of information being processed, stored, or transmitted by information systems, seldom derives from a single security safeguard or countermeasure. In most cases, such protection results from the selection and implementation of a set of mutually reinforcing security controls and privacy controls. Each control contributes to the overall organization-defined capability—with some controls potentially contributing to a greater degree and other controls contributing to a lesser degree. For example, organizations may wish to define a capability for secure remote authentication. This capability can be achieved by the implementation of a set of security controls from Special Publication 800-53, Appendix F (i.e., IA-2[1], IA-2[2], IA-2[8], IA-2[9], and SC-8[1]).

Security and privacy capabilities can address a variety of areas that can include technical means, physical means, procedural means, or any combination thereof. By employing the capability concept, organizations can obtain greater visibility into and a better understanding of: (i) the relationships (i.e., dependencies) among controls; (ii) the effects of specific control failures on organization-defined capabilities; and (iii) the potential severity of control weaknesses or deficiencies. However, this approach may add complexity to assessments and necessitate root cause failure analysis when specific capabilities are affected by the failure of particular security or privacy controls in order to determine which control or controls are contributing to the failure. The greater the number of controls included in an organization-defined capability, the more difficult it may be to ascertain the root cause of failures. There may also be interactions among defined capabilities which may contribute to the complexity of assessments. If it is found that a control is neither contributing to a defined capability nor to the overall security of the system, the organization revisits RMF Step 2, tailoring the control set and documenting the rationale in the security plan.

Traditionally, assessments have been conducted on a control-by-control basis producing results that are characterized as pass (i.e., control satisfied) or fail (i.e., control not satisfied). However, the failure of a single control or in some cases, the failure of multiple controls, may not affect the overall security capability or privacy capability required by an organization. This is not to say that such controls are not contributing to the security or privacy of the system and/or organization (as defined by the security requirements and privacy requirements during the initiation phase of the system development life cycle), but rather that such controls may not be supporting the particular security capability or privacy capability. Furthermore, every implemented security control or privacy control may not necessarily support or need to support an organization-defined capability.

When organizations employ the concept of capabilities, both automated and manual assessments take into account all security controls and privacy controls that comprise the security or privacy capabilities. Assessors are aware of how the controls work together to provide such capabilities. In this way, when assessments identify a failure in a capability, a root cause analysis can be conducted to determine the specific control or controls that are responsible for the failure based on the established relationships among controls. Moreover, employing the broader capability construct allows organizations to assess the severity of vulnerabilities discovered in their systems and organizations and determine if the failure of a particular security control or privacy control (associated with a vulnerability) or the decision not to deploy a certain control during the initial tailoring process (RMF Select step), affects the overall capability needed for mission/business protection. For example, the failure of a security control deemed critical for a particular security capability may be assigned a higher severity rating than a failed control of lesser importance to the capability.

Ultimately, authorization decisions (i.e., risk acceptance decisions) are made based on the degree to which the desired security capabilities and privacy capabilities have been effectively achieved and are meeting the security requirements and privacy requirements defined by an organization. These risk-based decisions are directly related to organizational risk tolerance that is defined as part of an organization’s risk management strategy.