Balisage Paper: A Document-based View of the Risk Management Framework

RMF Steps and High-level Workflow

Figure 1 illustrates how the seven RMF steps relate to one another and form a high-level workflow, with the caveat that steps are not always required to be followed in order. Also, although the connectors between steps are unidirectional, it is sometimes necessary to go backwards. For example, as discussed in section “Assess”, an assessment may trigger a re-implementation of security controls. The Prepare step's tasks lay the groundwork necessary to carry out the other RMF steps accurately and efficiently. Because the RMF process is iterative and adaptive, a task outcome from one of the six other steps may require revisiting one or more Prepare tasks.

Figure 1

Risk Management Framework steps JTFTI2018.

The six other RMF steps each serve the following purposes:

The RMF is process-oriented and task-oriented. It is not document-oriented, although many task inputs and outputs are documents. As such, RMF guidance is organized by steps and their tasks rather than organized by document. Therefore, RMF specifies document workflows implicitly rather than explicitly. Extracting an implicit document workflow involves analyzing task descriptions that mention the document or a subset of the document as a potential input or expected output.

System Security Plan and Sample Document Model

This paper studies the System Security Plan (SSP) and its associated workflow based on the RMF tasks most involved with producing it. The SSP is only one of several documents integral to the RMF process. However, SSPs cover a significant subset of RMF tasks and involve all seven RMF steps. The SSP documents the security requirements for an information system and describes the security controls in place or planned for meeting those requirements OMB. The system in an SSP may be an individual workstation or laptop, a server, or a networked device. Networked devices can include operational technology such as Internet of Things devices, 3D printers, digitally controlled machines, industrial switches, and programmable logic controllers. Alternatively, a system may be a logically grouped collection of computers and/or devices. Thus, a single SSP can apply to more than one computer or device.

The RMF uses prose text to describe the information required for an SSP but provides no machine-readable schema for automated syntactic validation of whether an SSP is complete. This paper uses the current draft form of the OSCAL architecture, which includes an SSP document model, as an alternative approach for supporting the RMF SSP documentation objectives and enabling automated validation.

The OSCAL GitHub repository includes, as an example, an Extensible Markup Language (XML) document valid with respect to this SSP model. This simple example represents the SSP of a partially-implemented system that provides enterprise logging and log auditing capabilities and uses controls from the SP 800-53 catalog. This paper's analysis of step-level workflows (section “Step-level Workflows”) uses this example as a means of showing how individual tasks within each RMF step affect the SSP contents. Figure 2 shows a high-level view of the example using a spreadsheet-like grid.

Figure 2

High-level OSCAL SSP document model example.

Some of the major SSP document model elements are defined as follows:

Key Participants

RMF Appendix D JTFTI2018 lists the roles and responsibilities of key participants in the risk management process. These include the following key participants primarily responsible for RMF tasks impacting the SSP.

For a small organization, one person might fulfill multiple roles. Conversely, a large organization could have multiple people filling a single role, for example, a team of Control Assessors. Also, some roles can be outsourced to third parties, such as Common Control Provider, Control Assessor, and System Owner (as in the case of a cloud-based service). Other roles, such as Authorizing Official, cannot be outsourced as they require executive-level accountability.

Step-level Workflows

The following subsections describe the SSP publishing workflow centered around each RMF step. A figure highlighting the RMF step illustrates each workflow. The highlighted RMF step has a bulleted list of the subset of RMF tasks for that step directly pertaining to the SSP. This bulleted list does not exist explicitly in SP 800-37 but is derived from the subset of expected outputs that involve SSP content authoring, SSP content review, or determination of SSP approval. The figure also shows key participants responsible for these tasks with dashed connectors pointing either to the RMF step or to a directional arrow leading to or from the step. A second figure indicates which portions of the SSP document model described in section “System Security Plan and Sample Document Model” get populated or modified in each workflow. The Categorize and Select publishing workflows (section “Categorize” and section “Select”) also include XML code illustrating how the component element enables traceability between control implementations, assets, business processes, and policies.

Prepare

Two Prepare tasks that result in modification to the SSP are Common Control Identification and Authorization Boundary determination. As shown in Figure 3, the Information Security Officer and Authorizing Official add content to the SSP. The Information Security Officer identifies common controls at the organizational level and documents their planned implementation. The Authorizing Official determines and documents a system's authorization boundary, using the system design documentation as input.

Figure 3

SSP interactions during Prepare step.

Figure 4 indicates the portions of the SSP document where new information is added, namely the authorization-boundary element and the portion of the control-implementation element pertaining to common control documentation. System design documentation comprises much of the input to the Authorization Boundary task. The RMF provides no guidance on this documentation's contents or structure but suggests that it includes a mix of prose and diagrams defining and identifying system elements, their interactions and the environment in which the system operates. Thus, authorization-boundary might reference a diagram showing an authorization boundary including the server and logging software with an environment of operation including client devices or services that write to or read from the log. control-implementation specifies any common controls inherited by the logging and auditing system. For example, if the system is located in a facility with physical access controls, control-implementation would include the physical access controls. The Select step-level workflow (section “Select”) includes an example of control-implementation XML markup that does not specify a common control, but rather is specific to the logging and auditing system.

Figure 4

Affected portions of SSP document.

Categorize

Two Categorize tasks that result in modification to the SSP are System Description and Security Categorization. As shown in Figure 5, the System Owner, Information Owner or Steward, and Authorizing Official bear primary responsibility for tasks impacting the SSP contents. The System Owner is primarily responsible for the System Description task and, together with the Information Owner or Steward, bears joint responsibility for the Security Categorization task. The Authorizing Official reviews the security categorization results and decides whether to approve the categorization. If approved, the RMF process proceeds with the Select step. Otherwise, the categorization process must be repeated.

As shown in Figure 6, the Categorize step populates a substantial portion of the SSP. The two tasks together create content for the system-implementation element and most of the system-characteristics element content except for its status and authorization-boundary sub-elements. system-information, a child element of system-characteristics not shown in Figure 6, lists a single information type: System and Network Monitoring. The specified impact of a loss of confidentiality, integrity, and availability is obtained by referencing NIST's Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories Stine, which provides a catalog of information types with suggested impacts.

Figure 5

SSP interactions during Categorize step.

Figure 6

Affected portions of SSP document.

system-implementation contains many descendant elements representing the system's components, assets, and roles responsible for these entities. The OSCAL SSP example defines several logging and auditing system components. These include the server software, the enterprise logging, monitoring, and alerting policy, the systems integration and inventory management processes, and the enterprise's configuration management guidance. In the interest of brevity, this paper only shows XML markup and content pertaining to the logging, monitoring, and alerting policy. The following XML defines the policy component, assigning it an identifier and assigning responsibility for maintaining the policy to the legal department.

<component id="component-logging-policy" component-type="policy">
    <prop name="version">2.1</prop>
    <prop name="last-modified-date">20181015</prop>
    <status state="operational"/>
    <responsible-role role-id="maintainer">
        <party-id>legal-department</party-id>
    </responsible-role>
</component>

The XML below defines the logging server asset as part of the system's asset inventory. The logging server is assigned an administrator and owner. implemented-component references a component implemented in a given system inventory item. Thus, the logging server implements both the server software and policy components.

<inventory-item id="inventory-logging-server" 
                asset-id="asset-id-logging-server">
    <responsible-party role-id="asset-administrator">
        <party-id>enterprise-asset-administrators</party-id>
    </responsible-party>
    <responsible-party role-id="asset-owner">
        <party-id>enterprise-asset-owners</party-id>
    </responsible-party>
    <implemented-component component-id="component-logging-server" 
                           use="runs-software"/>
    <implemented-component component-id="component-logging-policy" 
                           use="enforces-policy"/>
</inventory-item>

Select

The Select tasks that result in modification to the SSP (shown in Figure 7) are Control Selection, Tailoring, and Allocation and Documentation of Planned Control Implementations. The System Owner and Common Control Provider jointly bear primary responsibility for selecting and tailoring the system's security controls. The Security Architect and Information Security Officer are jointly responsible for control allocation. Allocation entails determining whether controls shall be system-specific, hybrid, or common, and then assigning the controls to the system elements (i.e., machine or environment in which the system operates) responsible for providing a security capability. The System Owner and Common Control Provider are responsible for documenting the controls and plans for their implementation in the SSP, as represented in the control-implementation element in Figure 8. import-profile contains a reference to common controls (such as the physical access controls mentioned in section “Prepare”) identified during the Prepare step.

Figure 7

SSP interactions during Select step.

Figure 8

Affected portions of SSP document.

control-implementation is updated to include additional controls needed to supplement the inherited common controls. The System Owner selects SP 800-53 control AU-1 (Audit and Accountability Policy and Procedures), whose control statement is shown in Figure 9. The italicized text inside brackets represents parameters. Selecting a SP 800-53 control requires inserting values for these parameters. Appendix A provides the AU-2 control statement as represented in OSCAL's SP 800-53 catalog model. As Appendix A shows, the OSCAL catalog model uses a part element to represent each of the nested list items in Figure 9. Each part has an @id attribute. Each of the three parameters is represented by a param element, also with an @id attribute.

Figure 9

The organization: Develops, documents, and disseminates to [organization-defined personnel or roles]: An audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and Procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls; and Reviews and updates the current: Audit and accountability policy [organization-defined frequency]; and Audit and accountability procedures [organization-defined frequency].

Security control AU-1: Audit and Accountability Policy and Procedures JTFTI2013.

The SSP documents the selection and planned implementation of AU-1 by associating each part of the control statement with the component that implements the part, assigning parameter values as needed. The following XML represents the planned implementation of list item b., sub-list item i. from Figure 9 (The organization … Reviews and updates the current … Audit and accountability policy [organization-defined frequency]).

<control-implementation>
    <implemented-requirement control-id="au-1">
      ...
      <statement statement-id="au-1_smt.b.1">
          <by-component component-id="component-logging-policy">
              <set-parameter param-id="au-1_prm_2">
                  <value>annually, and other times as necessary in 
response to regulatory or organizational changes</value>
              </set-parameter>
          </by-component>
      </statement>
      ...
   </implemented-requirement>
</control-implementation>

by-component references the component implementing this portion of the AU-1 statement. The organization-defined frequency parameter is assigned the value annually, and other times as necessary in response to regulatory or organizational changes.

Once the controls and their planned implementation are documented, the Authorizing Official reviews the SSP to determine if it is complete, consistent, and satisfies the system's security requirements. If approved, the RMF process proceeds with the Implement step. Otherwise, the Select step must be repeated.

Implement

As the final task culminating the Implement step, the System Owner and Common Control Provider update the SSP's control implementation information (shown in Figure 10) to reflect any differences between the actual control implementations and the planned implementation documentation produced in the Select step. Figure 11 shows that the update results in a modification to the SSP's control-implementation element as needed to reflect the actual implementation.

Figure 10

SSP interactions during Implement step.

Figure 11

Affected portions of SSP document.

Assess

During the Assess step (Figure 12), the System Owner and Common Control Provider update the SSP to reflect the state of the controls after the Control Assessor's initial assessment and any changes made in response to recommended Remediation Actions. If the assessment indicates controls were not properly implemented, the Implement step needs to be revisited. The assessment findings could also possibly trigger an update to a system-level or organization-wide risk assessment, requiring a return to the Prepare step.

As was the case for the Implement step (Figure 11), the Assess step's effect on the SSP document is limited to modification of the control-implementation element.

Figure 12

SSP interactions during Assess step.

Authorize

Following an analysis of risk from operating or using the system, the Authorizing Official determines whether the response to the risk is acceptable. The Risk Response is based on a review of the System Owner's and Common Control Provider's modification to the SSP (Figure 11), and of related documents such as assessment reports and Plan of Action and Milestones (defined in section “Cybersecurity System Risk Indicator (CSRI)”) for addressing any SSP deficiencies. These documents together comprise the Authorization Package. A determination that the Risk Response is unacceptable results in a return to the Implement step, as shown in Figure 13.

Figure 13

SSP interactions during Authorize step.

Monitor

There are three tasks in the Monitor step that can trigger updates to the SSP, as shown in Figure 14. They are System and Environment Changes, Authorization Package Updates, and System Disposal. Examples of system and environmental changes include machine elements such as hardware or software upgrades, human elements such as staff turnover, and environmental or physical elements such as physical access controls or relocation of the facility. These changes result in the System Owner or Common Control Provider updating system-information and system-implementation (as shown in Figure 15) and a return to the Categorize step. The Prepare step must be revisited as well if determined necessary by the Information Security Officer.

Figure 14

SSP interactions during Monitor step.

Figure 15

Affected portions of SSP document.

To achieve timely risk management, the System Owner and Common Control Provider update the SSP included in the Authorization Package in response to continuous monitoring results. These Authorization Package Updates, like System and Environment Changes, affect the RMF workflow and SSP contents as shown in Figure 14 and Figure 15, respectively.

System Disposal — removal of a system from operation — requires multiple actions (e.g., media sanitization, configuration management, record retention) for which the System Owner bears primary responsibility. These actions result in updating the status element in the SSP as shown in Figure 15.

A Publishing Perspective

The previous subsection analyzed the RMF workflows from an SSP document perspective. This subsection looks at the analysis results from the viewpoint of three activities central to SSP document publishing: authoring, reviewing, and updating. Authoring is the creation of new SSP document content. Reviewing is the evaluation of SSP content to determine whether it meets a set of criteria. Updating is the modification of existing SSP content in response to reviewer feedback, new implementation experience, or an environmental change. Table I summarizes the results of this publishing-focused analysis.

SSP authoring takes place mainly during Categorize and Select. As shown in section “Categorize” and section “Select”, most of the SSP content is created during these RMF steps, by the System Owner and — to the extent that the system leverages common controls — Common Control Provider. Some authoring also takes place during Prepare when the Information Security Officer identifies common controls and documents their planned implementation. The Authorizing Official documents the authorization boundary during Prepare, but this consists mostly of references to concepts from other documents such as system design documents and diagrams.

SSP reviewing occurs during most RMF steps, but especially during Assess and Authorize where reviewing is the central purpose of the step. The Authorizing Official is the chief reviewer of the RMF process and has the greatest authority and accountability. The Control Assessor and Information Security Officer have important reviewer roles as well. These three reviewers have differing and complementary qualifications. The Authorizing Official is a senior executive or business owner with an intimate understanding of organizational mission, budget constraints, and security and privacy risks. The Control Assessor is an information security expert with the detailed knowledge necessary to evaluate effectiveness of control implementations. The Information Security Officer has expertise spanning both security assurance and implementation and offers both an organization and systems perspective.

SSP updating occurs during Implement, Assess, and Monitor, with the System Owner and possibly the Common Control Provider bearing primary responsibility. Given that the System Owner and Common Control Provider also have outsized roles in SSP authoring, it follows that their requirements should be given top priority when developing SSP document schemas and editing tools.

This paper claimed in section “Introduction” that a document-centric analysis can lead to improved schemas and tools for the key participants in the RMF process. The analysis in section “Step-level Workflows” and subsequent analysis in this subsection support that claim by providing these takeaways:

Incentive-focused Document Workflow Analysis

A publishing workflow's success depends upon the actors involved being incentivized to work toward a common goal. In the case of RMF-based security assurance, there are two common scenarios. For United States federal agencies and their contractors, the System Owner, Information Security Officer, Authorizing Official, and other participants are all incentivized by FISMA to adhere to the RMF process. Non-federal companies and organizations have no FISMA requirement. However, the RMF's system life cycle approach ensures that security plans and implementations are mission-based and tied to business requirements. Therefore, even without a common incentive such as FISMA compliance, good systems engineering practices can result in mutually reinforcing incentives for those responsible for SSP development and development of other RMF document outputs.

Piez Piez20 studies workflow participant incentives in research journal publishing enterprises: an industry quite distinct from security assurance. There are some parallels in terms of roles (Author versus System Owner, Peer Reviewer versus Control Assessor, Journal Editor versus Authorizing Official) and process steps (Review versus Assess, Accept/Reject versus Authorize). However, there are significant differences in incentives. For example, security assurance strongly encourages identification and implementation of common controls wherever possible. Research articles submitted to journals, on the other hand, are required to have intellectual content that is mostly original. Even survey articles, where previously published work is highlighted, must contain a thorough and substantive analysis of the prior art.

Unlike security assurance, where deployment of declarative document markup technologies such as OSCAL is in its infancy, journal publishing workflows have been XML-enabled for a long time. However, as Piez points out, XML has achieved its greatest successes in post-production processes where authors and reviewers are not involved. Despite decades of XML implementation experience in the journal publishing world, most authors still submit papers in word processor formats, and many use spreadsheets for managing and responding to reviewer comments. Lessons learned regarding what works and what does not from the journal publishing industry could help markup technologists determine the implementation approaches most likely to be successful in automating and streamlining development of SSPs and other security assurance documents. However, implementers of security assurance publishing tools should be aware that incentives among security assurance workflow participants differ from the ecosystem of incentives that exist in the journal publishing world.

DITA

The Darwin Information Typing Architecture (DITA) OASIS, a standardized XML-based architecture for authoring, managing, reusing and transforming technical content, could provide the foundation for an interoperable set of tools to meet the needs of SSP authors, updaters, and reviewers. Unlike other declarative markup language frameworks, DITA supports the definition of element types that are specializations of other element types Kimber. Specializations inherit not only the syntactic structure of their base element type, but also the processing behavior. To understand the benefits of specialization in the context of the RMF process, suppose a DITA element type was defined for control catalogs, with specializations for SP 800-53, ISO 27001, and ISO/IEC 15408. Then a tool developer could leverage the same code implementing the generic catalog element type to support the RMF Select step for all three catalogs.

Although OSCAL has a generic catalog schema that can be extended to support other catalogs besides SP 800-53, OSCAL does not support specialization in the general sense. For example, the OSCAL control-implementation element's support for parameters (discussed in section “Select”) accommodates SP 800-53 but may not be needed for other catalogs. Therefore, control-implementation is over-specified for catalogs without control parameters. Conversely, consider a catalog whose controls have properties not pre-defined in OSCAL. control-implementation's content model can be extended using OSCAL's prop element to provide name-value pairs for these additional control properties. However, the OSCAL control-implementation element would then be under-specified without supplemental documentation for how OSCAL tools should handle the prop extensions. DITA's specialization mechanism provides a formal way to avoid over-specification and under-specification, explicitly separating general syntax and processing behavior from specialized syntax and processing behavior.

The DITA Open Toolkit DITA-OT, an output-producing processor that transforms input authored using DITA-conforming XML vocabularies into other formats, implements an extensible workflow for integrating DITA processing with other tasks. The DITA Open Toolkit could potentially be used for automating the authoring and review of SSPs and other documents in the RMF process. SCAP Composer Lubell19 Lubell20, a DITA Open Toolkit plug-in that contributes toward implementing the RMF System and Environment Changes task (see section “Monitor”), provides an example of applying DITA specialization and the DITA Open Toolkit's extensible workflow mechanism to solve a security assurance problem.

Cybersecurity System Risk Indicator (CSRI)

Wilbanks Wilbanks developed a methodology to measure system cybersecurity risk that suggests potential benefits of deploying declarative markup technologies in the security assurance space. Wilbanks's CSRI, used within the United States Department of Education's Federal Student Aid cybersecurity risk management program, employs a set of weighted risk factors to quantify a system's vulnerability to cyber threats. Many of these risk factors are computed by extracting relevant information from documents associated with the RMF process. For example, one highly weighted risk factor involves analyzing a system's Plan of Action and Milestones (POAM), a document created by the System Owner and Common Control Provider based on the Control Assessor's findings and recommendations. The POAM describes planned actions with due dates to correct deficiencies identified during the assessment. The CSRI's POAM risk factor score is based on the number of unmet milestones, their criticality, and aging (how many are overdue).

Because POAMs and other risk management-related documents are typically in word processor or spreadsheet formats, extracting the information needed to compute document-based CSRI risk factors is a time-consuming, manual process. If these documents were tagged in a declarative markup language, they would be more amenable to structured queries and optimized presentation of results. For example, a CSRI dashboard user interface that computes and displays risk factors could be efficiently implemented using low-cost and ubiquitous XML- or HTML5-based technologies.