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:
|
|
References a pre-defined set of security requirements, for example a baseline from SP 800-53. |
|
|
Indicates the system's overall information sensitivity categorization.
May be |
|
|
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. |
|
|
Specifies target levels of confidentiality, integrity, and availability for the system. |
|
|
Establishes a system's scope of protection. Authorization boundary determination is the act of specifying what the organization is directly responsible for protecting. |
|
|
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. |
|
|
Describes how the system implements a set of controls. For each control implemented, specifies the control's description and set of implemented requirements satisfied. |
|
|
Defines a part of an implemented system. A |
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:
|
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.