How to cite this paper

Lubell, Joshua. “A Document-based View of the Risk Management Framework.” Presented at Balisage: The Markup Conference 2020, Washington, DC, July 27 - 31, 2020. In Proceedings of Balisage: The Markup Conference 2020. Balisage Series on Markup Technologies, vol. 25 (2020). https://doi.org/10.4242/BalisageVol25.Lubell01.

Balisage: The Markup Conference 2020
July 27 - 31, 2020

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

Joshua Lubell

Computer Scientist

National Institute of Standards and Technology

Joshua Lubell is a computer scientist whose work focuses on smart manufacturing systems cybersecurity. His XForms-based Baseline Tailor software tool for security control selection won a Government Computer News Dig IT award. Prior to his work in cybersecurity, he contributed to the development of ISO 10303, a standard for representation and exchange of computer-aided designs and other product model data, for which he received the United States Department of Commerce Silver Medal. He is also a Balisage hyper-local, residing in the heart of Rockville, Maryland.

Official contribution of the National Institute of Standards and Technology; not subject to copyright in the United States.

Abstract

Cybersecurity professionals know the Risk Management Framework (RMF) as a rigorous yet flexible process for managing security risk. But the RMF lacks a document focus, even though much of the process requires authoring, reviewing, revising, and accessing plans and reports. It is possible to build such a focus by looking more closely at these documents, starting with the System Security Plan and the roles of key participants responsible for it. Such a document- and role-centric view of the RMF process can lead the way toward more efficient and less error-prone security assurance.

Table of Contents

Introduction
RMF-derived System Security Plan Workflows
RMF Steps and High-level Workflow
System Security Plan and Sample Document Model
Key Participants
Step-level Workflows
Prepare
Categorize
Select
Implement
Assess
Authorize
Monitor
A Publishing Perspective
Related Work
Incentive-focused Document Workflow Analysis
DITA
Cybersecurity System Risk Indicator (CSRI)
Conclusion
Appendix A. OSCAL Representation of AU-1 Subset

Introduction

The National Institute of Technology's (NIST's) Risk Management Framework (RMF) JTFTI2018 defines a rigorous yet flexible process for managing security risk. Application of the RMF process provides the evidence needed to justify assurance that an information system is operating within acceptable risk tolerance. The United States Government's Federal Information Security Modernization Act (FISMA) mandates RMF use for federal agencies and their contractors, yet the RMF process is sufficiently flexible to be used by all sorts of organizations. For example, Graves et al. show how an additive manufacturing service provider can use the RMF to assess system security risk Graves .

The RMF lists the roles and responsibilities (summarized in section “Key Participants”) of those primarily responsible for managing an organization's risk. Yet it is up to the organization whether multiple people fill a single role, whether a single person fills multiple roles, or whether a role is outsourced. Such a decision is based on multiple factors, including size of the organization, its appetite for risk, budget constraints, regulatory requirements, and the consequences of a loss of confidentiality, integrity, or availability (CIA) of the information its systems store, process, or transmit. One extreme might be a large government agency or corporation with an entire department dedicated to information security risk management, with teams responsible for each role. The opposite extreme might be a family-run small business where all operational roles are filled by a single technology-savvy employee or outside service provider, and executive roles are filled by an owner, who consults with outside experts as needed. Regardless of whether the organization is large or small, public or private sector, or deals with information where a loss of CIA would be catastrophic to many people or few people, the RMF process establishes who is responsible and accountable for information security assurance.

Executing the RMF process requires preparation, modification, and review of a variety of documents. Although the RMF is structured and precise in describing its process, it describes these documents in an unstructured and disjointed manner. The documents are referenced in the context of the risk management tasks that involve them and of the people who are responsible for preparing, modifying, and reviewing them. But the RMF provides no schema or declarative markup vocabulary for these documents. It is therefore up to organizations using the RMF to provide document authoring guidance. Some organizations use spreadsheet or word processor document templates. Others use software tools such as the United States government's Cyber Security Evaluation Tool CSET, which uses a questionnaire-driven approach to produce a Security Assessment Report document.

However, these templates and tools are one-off efforts that do not interoperate. A document created using one of them cannot be easily imported into another. Also, a template or tool designed for one organization's document may be unusable for another organization. And while a template provides guidance on formatting and structure, it has only limited ability to validate a document's completeness or consistency. As a result, RMF users lack the good authoring and content management tools they need to efficiently edit, navigate, share, and evaluate the very documents that are central to system security assurance.

As an initial step toward remedying the lack of tool support, this paper demonstrates a way to derive from the RMF a more document-centric view of risk management. This envisioned document-based view supplements the existing RMF guidance by providing an alternative way of looking at security assurance that is less process-focused and more oriented toward publishing, i.e., document authoring and management. Such a document focus can facilitate the development of schemas, tools for authors, reviewers, and approvers, and content management systems to better support distribution and archiving of risk management information. Beneficiaries would be the people filling the risk management roles listed in section “Key Participants”. This paper does not attempt to define machine-readable document models for the RMF. That goal, which is too ambitious for a single paper (or single person for that matter) is a long-term goal of NIST's Open Security Controls Assessment Language (OSCAL) project OSCAL Piez19. However, the methodology this paper demonstrates could be useful to projects such as OSCAL as a means for ensuring that such document models are faithful to the RMF process-centric guidance.

But why choose NIST's RMF for this investigation when there are other frameworks for system security assurance such as the ISO 27000 ISO27000 and ISO/IEC 15408 ISO15408 families of International Standards? This paper chooses the RMF as its basis because the RMF is widely used within the federal government and voluntarily used outside the federal government. And the RMF does not exist in a vacuum. The RMF's system life cycle process and use of systems engineering terminology are derived from ISO/IEC15288 ISO15288, a systems engineering standard covering processes and life cycle stages Zemrowski. Also, some RMF tasks can be executed using NIST's Framework for Improving Critical Infrastructure Cybersecurity NIST, a voluntary risk-based management approach used widely in both private and public sectors internationally. Additionally, the RMF process is compatible with any of the standardized catalogs of security controls. A security control is a safeguard or countermeasure that protects the confidentiality, integrity, and availability of a system and its information. Although the RMF refers users to the NIST Special Publication (SP) 800-53 JTFTI2013 guidance for selection and tailoring of security controls, users not subject to FISMA are free to substitute security controls from ISO 27001 ISO27001, ISO/IEC 15408, or other sources.

This paper proceeds as follows. The next section provides a high-level introduction to the RMF process and illustrates a document-focused view of RMF focusing specifically on the System Security Plan — representative of the various documents involved in the RMF process — and its associated workflows. The third section discusses other relevant research and development contributions. The last section concludes the paper.

RMF-derived System Security Plan Workflows

The RMF defines a process that organizations can use to manage risk at both the enterprise-wide and system levels. The process is iterative and adaptive in response to new threats or changes to an organization's mission or business functions. The RMF process has a series of seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. Each step consists of multiple tasks. Each task has a set of potential inputs, some of which are expected outputs from other tasks. A task output that serves as an input to another task is often a document, although the RMF does not recommend specific document formats or schemas. These documents and the choreography between parties responsible for producing, reviewing, modifying, and consuming them constitute a set of workflows.

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:

Categorize

Describes the system and classifies the impact of loss of confidentiality, integrity, and availability of the information it stores, processes, and transmits.

Select

Chooses an initial set of controls for the system, tailoring them as needed to reduce the risk to an acceptable level.

Implement

Implements the controls and describes their deployment.

Assess

Determines whether the controls are implemented correctly and are fit for purpose.

Authorize

Determines whether the system is safe to operate or use based on acceptability of risk to operations, assets, and people. Authorization in this context is not to be confused with authorizing a user/process/device access to a system's resources. The former is a risk management function. The latter is a system function that should be subject to security controls enforcing identity management and access control policies.

Monitor

Continuously monitors the system and associated controls to assess control effectiveness, report changes to the system and its environment, assess risk and impact, and report security posture.

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:

import-profile

References a pre-defined set of security requirements, for example a baseline from SP 800-53.

security-sensitivity-level

Indicates the system's overall information sensitivity categorization. May be low, moderate, or high.

system-information

Describes all the information types the system stores, processes, or transmits, for example, historical logging and auditing information. Each description specifies the impact of a loss of confidentiality, integrity, and availability of the information type.

security-impact-level

Specifies target levels of confidentiality, integrity, and availability for the system.

authorization-boundary

Establishes a system's scope of protection. Authorization boundary determination is the act of specifying what the organization is directly responsible for protecting.

system-implementation

Specifies the types of users who interact with the system and their roles, the system's component parts, services (e.g., ports and protocols), interconnections, and inventory items.

control-implementation

Describes how the system implements a set of controls. For each control implemented, specifies the control's description and set of implemented requirements satisfied.

component

Defines a part of an implemented system. A component can be hardware, software, or a service, policy, process, or procedure. Although not shown in Figure 2, components are critical model elements in that they enable the expression of relationships between implemented controls, hardware and software assets, and policies and business processes.

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.

Information Security Officer

Oversees security responsibilities at the organizational level.

Authorizing Official

Assumes accountability for operating a system. May empower a designated representative to carry out many of the activities related to the execution of the RMF. However, only the Authorizing Official can determine whether the risk from the operation or use of the system is acceptable.

System Owner

Buys, develops, integrates, modifies, operates, maintains, and disposes of a system. Responsible for creating and maintaining the SSP.

Information Owner or Steward

Establishing the rules for appropriate use and protection of a specified type of information. A system may contain information from multiple information owners or stewards.

Common Control Provider

Implements, assesses, and monitors common controls. Common controls can be inherited by multiple systems, thus reducing the complexity and protection costs of an organization's IT infrastructure. For example, hardware token-based authentication, implemented enterprise-wide using Personal Identity Verification cards, is an example of a common control.

Security Architect

Ensures that the enterprise architecture addresses stakeholder protection needs and the corresponding system requirements necessary to protect organizational missions and business functions.

Control Assessor

Evaluates implemented controls to determine their effectiveness.

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:
  1. Develops, documents, and disseminates to [organization-defined personnel or roles]:

    1. An audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

    2. Procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls; and

  2. Reviews and updates the current:

    1. Audit and accountability policy [organization-defined frequency]; and

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

Table I

SSP authoring, reviewing, and updating throughout the RMF process.

Activity RMF Step Primary Responsibility
Authoring Prepare Information Security Officer, Authorizing Official
Categorize System Owner, Common Control Provider, Information Owner or Steward
Select System Owner, Common Control Provider, Security Architect, Information Security Officer
Reviewing Categorize, Select Authorizing Official
Assess Control Assessor
Authorize Authorizing Official
Monitor Information Security Officer
Updating Implement, Assess, Monitor System Owner, Common Control Provider

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:

  • Authoring schemas and editing tools should prioritize the needs of the System Owner and Common Control Provider. People fulfilling these roles may have technical knowledge about systems and/or controls for which they are responsible. They are less likely, however, to have risk management or security assurance expertise. Because these roles produce and maintain much of the SSP content, making their authoring and update tasks easier and less error-prone should result in better cybersecurity and cost savings to their organizations.

  • Solutions that automate review/update workflows have the challenges of accommodating not only reviewers, but also authors performing updates. Additionally, these solutions should be tailored to the differing needs and areas of expertise of the Authorizing Official, Control Assessor, Information Security Officer reviewer roles.

  • Since no single tool can fit the requirements of all key participants in the RMF process, interoperability standards are needed to support an ecosystem of tools. The proposed and evolving OSCAL document formats could meet this need. Another candidate is the Darwin Information Typing Architecture, discussed in section “DITA”.

Conclusion

This paper presented a new approach that supports the creation of the System Security Plan, a critical Risk Management Framework output. The new approach, based on an SSP document model defined using declarative markup and on the RMF roles primarily responsible for documenting the SSP, offers an alternative view into security assurance. By emphasizing roles and how they relate to SSP document elements, this alternative view provides a roadmap for implementers of standards and tools for authoring and accessing the information in SSP documents. The same approach used in this paper can be extended to other documents arising from the RMF process such as assessment reports and POAMs. With the research and development results discussed in section “Related Work”, the document and role-centric view of the RMF process can lead the way toward new standards and tools enabling more efficient and less error-prone security assurance.

But, to quote Piez20, the platform is not the capability. The best languages, schemas, and tools in the world are supplements — but not substitutes — for the expertise required to assess cyber-risk, the systems engineering skills needed to identify common controls or establish authorization boundaries, and the hardware, software, and people skills needed to implement security controls.

Appendix A. OSCAL Representation of AU-1 Subset

The following listing, extracted from the OSCAL SP 800-53 catalog, represents the AU-1 control statement shown in Figure 9.

<control class="SP800-53" id="au-1">
    <title>Audit and Accountability Policy and Procedures</title>
    <param id="au-1_prm_1">
        <label>organization-defined personnel or roles</label>
    </param>
    <param id="au-1_prm_2">
        <label>organization-defined frequency</label>
    </param>
    <param id="au-1_prm_3">
        <label>organization-defined frequency</label>
    </param>
    <prop name="label">AU-1</prop>
    <part id="au-1_smt" name="statement">
        <p>The organization:</p>
        <part id="au-1_smt.a" name="item">
            <prop name="label">a.</prop>
            <p>Develops, documents, and disseminates to 
<insert param-id="au-1_prm_1"/>:</p>
            <part id="au-1_smt.a.1" name="item">
                <prop name="label">1.</prop>
                <p>An audit and accountability policy that addresses 
purpose, scope, roles, responsibilities, management commitment, 
coordination among organizational entities, and compliance; and</p>
            </part>
            <part id="au-1_smt.a.2" name="item">
                <prop name="label">2.</prop>
                <p>Procedures to facilitate the implementation of 
the audit and accountability policy and associated audit and 
accountability controls; and</p></part></part>
        <part id="au-1_smt.b" name="item">
            <prop name="label">b.</prop>
            <p>Reviews and updates the current:</p>
            <part id="au-1_smt.b.1" name="item">
                <prop name="label">1.</prop>
                <p>Audit and accountability policy 
<insert param-id="au-1_prm_2"/>; and</p></part>
            <part id="au-1_smt.b.2" name="item">
                <prop name="label">2.</prop>
                <p>Audit and accountability procedures 
<insert param-id="au-1_prm_3"/>.</p></part></part></part></control>

References

[CSET] Downloading and Installing CSET. Accessed May 27, 2020. https://www.us-cert.gov/ics/Downloading-and-Installing-CSET.

[DITA-OT] DITA Open Toolkit. Accessed April 18, 2020. https://www.dita-ot.org/.

[Graves] Graves, Lynne M. G., Joshua Lubell, Wayne King, and Mark Yampolskiy. Characteristic Aspects of Additive Manufacturing Security From Security Awareness Perspectives. IEEE Access 7 (2019). doi:https://doi.org/10.1109/ACCESS.2019.2931738.

[ISO15288] ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes.

[ISO15408] ISO/IEC 15408-1:2009 Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model.

[ISO27000] ISO/IEC 27000:2018 Information technology — Security techniques — Information security management systems — Overview and vocabulary.

[ISO27001] ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems — Requirements.

[JTFTI2013] Joint Task Force Transformation Initiative. Security and Privacy Controls for Federal Information Systems and Organizations. National Institute of Standards and Technology, April 2013. doi:https://doi.org/10.6028/NIST.SP.800-53r4.

[JTFTI2018] Joint Task Force Transformation Initiative. Risk Management Framework for Information Systems and Organizations:: A System Life Cycle Approach for Security and Privacy. Gaithersburg, MD: National Institute of Standards and Technology, December 2018. doi:https://doi.org/10.6028/NIST.SP.800-37r2.

[Kimber] Kimber, Eliot. DITA for Practitioners Volume 1: Architecture and Technology. XMLPress, 2012.

[Lubell19] Lubell, Joshua. SCAP Composer: A DITA Open Toolkit Plug-in for Packaging Security Content. Presented at Balisage: The Markup Conference 2019, Washington, DC, July 30 - August 2, 2019. In Proceedings of Balisage: The Markup Conference 2019. Balisage Series on Markup Technologies, vol. 23 (2019). doi:https://doi.org/10.4242/BalisageVol23.Lubell01.

[Lubell20] Lubell, Joshua. SCAP Composer User Guide. National Institute of Standards and Technology, February 28, 2020. doi:https://doi.org/10.6028/NIST.IR.8290.

[NIST] National Institute of Standards and Technology. Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. Gaithersburg, MD: National Institute of Standards and Technology, 2018. doi:https://doi.org/10.6028/NIST.CSWP.02122014.

[OMB] Office of Management and Budget. Managing Information as a Strategic Resource, 2016. https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf.

[OASIS] Organization for the Advancement of Structured Information Standards. DITA Version 1.3 Specification, 2018. http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-part0-overview.html.

[OSCAL] OSCAL: the Open Security Controls Assessment Language. OSCAL. Accessed April 18, 2020. https://pages.nist.gov/OSCAL/.

[Piez19] Piez, Wendell. The Open Security Controls Assessment Language (OSCAL): Schema and Metaschema. Presented at Balisage: The Markup Conference 2019, Washington, DC, July 30 - August 2, 2019. In Proceedings of Balisage: The Markup Conference 2019. Balisage Series on Markup Technologies, vol. 23 (2019). doi:https://doi.org/10.4242/BalisageVol23.Piez01.

[Piez20] Piez, Wendell. Systems security assurance as (micro) publishing: Declarative markup for systems description and assessment. Presented at Balisage: The Markup Conference 2020, Washington, DC, July 28-31, 2020. In Proceedings of Balisage: The Markup Conference 2020. Balisage Series on Markup Technologies, vol. 25 (2020). doi:https://doi.org/10.4242/BalisageVol25.Piez01.

[Stine] Stine, Kevin, Rich Kissel, William C Barker, Annabelle Lee, and Jim Fahlsing. Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories. National Institute of Standards and Technology, August 2008. doi:https://doi.org/10.6028/NIST.SP.800-60v2r1.

[Wilbanks] Wilbanks, Linda. What's Your IT Risk Approach? IT Professional, Vol. 20, no. 4 (July 2018): 13–17. doi:https://doi.org/10.1109/MITP.2018.043141663.

[Zemrowski] Zemrowski, Kenneth M. NIST Bases Flagship Security Engineering Publication on ISO/IEC/IEEE 15288:2015. Computer 49 (2016): 3. doi:https://doi.org/10.1109/MC.2016.373.

×

Downloading and Installing CSET. Accessed May 27, 2020. https://www.us-cert.gov/ics/Downloading-and-Installing-CSET.

×

DITA Open Toolkit. Accessed April 18, 2020. https://www.dita-ot.org/.

×

Graves, Lynne M. G., Joshua Lubell, Wayne King, and Mark Yampolskiy. Characteristic Aspects of Additive Manufacturing Security From Security Awareness Perspectives. IEEE Access 7 (2019). doi:https://doi.org/10.1109/ACCESS.2019.2931738.

×

ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes.

×

ISO/IEC 15408-1:2009 Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model.

×

ISO/IEC 27000:2018 Information technology — Security techniques — Information security management systems — Overview and vocabulary.

×

ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems — Requirements.

×

Joint Task Force Transformation Initiative. Security and Privacy Controls for Federal Information Systems and Organizations. National Institute of Standards and Technology, April 2013. doi:https://doi.org/10.6028/NIST.SP.800-53r4.

×

Joint Task Force Transformation Initiative. Risk Management Framework for Information Systems and Organizations:: A System Life Cycle Approach for Security and Privacy. Gaithersburg, MD: National Institute of Standards and Technology, December 2018. doi:https://doi.org/10.6028/NIST.SP.800-37r2.

×

Kimber, Eliot. DITA for Practitioners Volume 1: Architecture and Technology. XMLPress, 2012.

×

Lubell, Joshua. SCAP Composer: A DITA Open Toolkit Plug-in for Packaging Security Content. Presented at Balisage: The Markup Conference 2019, Washington, DC, July 30 - August 2, 2019. In Proceedings of Balisage: The Markup Conference 2019. Balisage Series on Markup Technologies, vol. 23 (2019). doi:https://doi.org/10.4242/BalisageVol23.Lubell01.

×

Lubell, Joshua. SCAP Composer User Guide. National Institute of Standards and Technology, February 28, 2020. doi:https://doi.org/10.6028/NIST.IR.8290.

×

National Institute of Standards and Technology. Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. Gaithersburg, MD: National Institute of Standards and Technology, 2018. doi:https://doi.org/10.6028/NIST.CSWP.02122014.

×

Office of Management and Budget. Managing Information as a Strategic Resource, 2016. https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf.

×

Organization for the Advancement of Structured Information Standards. DITA Version 1.3 Specification, 2018. http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-part0-overview.html.

×

OSCAL: the Open Security Controls Assessment Language. OSCAL. Accessed April 18, 2020. https://pages.nist.gov/OSCAL/.

×

Piez, Wendell. The Open Security Controls Assessment Language (OSCAL): Schema and Metaschema. Presented at Balisage: The Markup Conference 2019, Washington, DC, July 30 - August 2, 2019. In Proceedings of Balisage: The Markup Conference 2019. Balisage Series on Markup Technologies, vol. 23 (2019). doi:https://doi.org/10.4242/BalisageVol23.Piez01.

×

Piez, Wendell. Systems security assurance as (micro) publishing: Declarative markup for systems description and assessment. Presented at Balisage: The Markup Conference 2020, Washington, DC, July 28-31, 2020. In Proceedings of Balisage: The Markup Conference 2020. Balisage Series on Markup Technologies, vol. 25 (2020). doi:https://doi.org/10.4242/BalisageVol25.Piez01.

×

Stine, Kevin, Rich Kissel, William C Barker, Annabelle Lee, and Jim Fahlsing. Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories. National Institute of Standards and Technology, August 2008. doi:https://doi.org/10.6028/NIST.SP.800-60v2r1.

×

Wilbanks, Linda. What's Your IT Risk Approach? IT Professional, Vol. 20, no. 4 (July 2018): 13–17. doi:https://doi.org/10.1109/MITP.2018.043141663.

×

Zemrowski, Kenneth M. NIST Bases Flagship Security Engineering Publication on ISO/IEC/IEEE 15288:2015. Computer 49 (2016): 3. doi:https://doi.org/10.1109/MC.2016.373.