Balisage Paper: Extending the Cybersecurity Digital Thread with XForms

The Cybersecurity Digital Thread

We live in an age of digitization. One enterprise after another is using information technology to become more productive, improve quality, and drive down business costs. Data plays a central role in achieving the benefits of digitization. Digital data facilitates the authoring of information, information exchange between software applications, and automated data processing. Innovations have recently been evident in manufacturing, where information technology advances such as big data, service-oriented architectures, and networking have triggered a digital revolution [1]. Those leading efforts to digitize the manufacturing of complex products have coined the term digital thread to convey the data flow between engineering and business processes and across supply chains [2].

This paper's context is the digital thread for cybersecurity. Just as the design, production, and maintenance of modern industrial equipment, automobiles, airplanes, and power systems are data-intensive, so is the securing of an organization's information and information systems. The most technologically advanced manufacturing process is of limited use unless the system implementing the process can interpret and act upon input data created by other systems and lifecycle processes, and the manufacturing process can share its output data with entities that require it. Similarly, the most sophisticated encryption algorithm, intrusion detection software, or risk assessment tool cannot achieve its full potential without seamlessly interoperating with other security technologies and data sources.

A cybersecurity digital thread requires standardized languages, data formats, taxonomies, and metrics. As a result, the cybersecurity research, development, and user communities have created a variety of Extensible Markup Language (XML) [3] data representation and exchange standards for software weaknesses and vulnerabilities, naming conventions, system state, configuration checklists, asset identification, and severity measurement of software and configuration issues [4]. The National Institute of Standards and Technology (NIST) has developed an infrastructure, the Security Content Automation Protocol (SCAP - pronounced ess-cap) [5,6], for leveraging this array of information standards. In addition to technical guidance for how the individual information standards should be used together, this infrastructure includes:

The United States government defines cybersecurity as the protection or defense of global and local information networks and infrastructures, computer systems, and embedded processors and controllers from attack [9]. Cybersecurity is in essence a cyclical sequence of steps whose common goal is to manage the subset of cyber-risk relating to security concerns. Figure 1, adapted from NIST Special Publication (SP) 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, Revision 4 [10], gives a high-level overview of a cybersecurity risk management framework. Step 1 involves classifying information systems based on the consequences of a loss of confidentiality, integrity, or availability of information. Step 2 consists of choosing a set of security controls (safeguards) to mitigate the risks determined in Step 1. Step 3 is the implementation of the selected controls, either in software for those controls that are automatable, or through human effort. According to a 2011 study, only about 30% of the NIST SP 800-53 security controls are automatable [11]. Step 4 determines how effective the security controls are as implemented in Step 3. Step 5 is the act of management authorizing an information system's use (and accepting the inherent risk based on the set of implemented controls). Step 6 is the ongoing tracking of system changes that could affect security controls and their effectiveness.

Figure 1

Risk management framework.

SCAP is an enabler of the digital thread with respect to the risk management framework shown in Figure 1. SCAP data standards, the National Vulnerability Database, and SCAP-validated products can facilitate some, but not all, of the information flows between the six steps (the arrows in the figure) and also within each step. This paper focuses on a specific gap in the digital thread relating to Step 2 (SELECT Security Controls), namely the lack of good software for tailoring NIST SP 800-53 security controls and exporting the result in a structured XML format. This gap not only makes it more cumbersome to perform Step 2, but also impedes the flow of information from security controls selected in Step 2 to their implementations in Step 3 (and by transitivity to subsequent steps). The proposed solution simplifies the documentation of security control selections in a manner that both ensures compliance with NIST SP 800-53 and facilitates the flow of digital data to Steps 3 through 6 in the risk management framework.

The rest of the paper proceeds as follows. The next section discusses the NIST SP 800-53 security controls and how they are chosen to meet the needs of a particular set of requirements. That section provides an example showing an SCAP scenario where security content is mapped to security controls for traceability, but also highlights the lack of software tools for tailoring security controls and lack of an SCAP XML format for representing tailored controls^[1]. The section after that describes an implementation using XForms [12] of a user interface (UI) for selecting and tailoring security controls. This implementation generates XML representing how a control has been tailored, enabling the tailored control to be interoperable within the SCAP infrastructure. The paper concludes with highlights of some ongoing and future work.

Security Control Selection, Tailoring, and Overlays

NIST SP 800-53 provides a catalog of tailorable security controls organized into eighteen families shown in Table 1. SP 800-53 specifies three security control baselines: for low, moderate, and high impact information systems. Impact is determined in Step 1 of the risk management framework discussed in the previous section. The baselines are suggested defaults and serve as a starting point for Step 2 in the risk management framework. For example, an organization looking to select security controls for a low-impact system (where the consequences of compromised confidentiality, integrity, and availability of information are low) might begin with the controls in the SP 800-53 baseline for the low impact level (or more succinctly, the low baseline) and tailor them as appropriate.

An example of tailoring is adding a security control to an SP 800-53 baseline to meet organization-specific requirements. Consider security control IA-3 (Device Identification and Authentication) from the IA (Identification and Authentication) control family shown in Table 2. IA-3 pertains to identifying and authenticating devices before connecting to them, and is not included in the SP 800-53 low baseline. This default setting for IA-3 assumes that a low-impact system does not connect directly to devices external to the organization. But suppose the organization is securing an Industrial Control System (ICS), which is common in the utility, transportation, chemical, pharmaceutical, process, and durable goods manufacturing industries [13]. The organization may want to permit the ICS to connect directly to devices belonging to and authorized by business partners. To ensure that these devices are properly identified and authenticated, the organization adds IA-3 to the low baseline.

Table 2 shows the low, moderate, and high baselines for each control in the IA (Identification and Authentication) family. In most cases the moderate baseline is a superset of the low baseline, and the high baseline is a superset of the moderate baseline. The numbers in parentheses in the three rightmost columns denote control enhancements, which are declarations of security capability to increase the control's functionality and/or strength. For example, IA-5 (1), which identifies control enhancement (1) of IA-5 (Authenticator Management | Password-Based Authentication), states a set of capabilities specific to password-based authentication. These capabilities enhance the more general capabilities stated for IA-5, which apply to all types of authentication.

The National Vulnerability Database provides several tools to support use of the NIST SP 800-53 security control catalog and to enable integration of catalog information with SCAP content. These include:

One of the recommended uses of SCAP is for providing evidence of compliance with security requirements. The following example shows how the Common Configuration Enumeration mappings can be used together with an SCAP checklist to show traceability from a Windows 7 (see Disclaimer) system setting to a NIST SP 800-53 security control. Consider security control IA-4 (Identifier Management), which specifies a set of requirements for managing information system identifiers. Figure 2 shows a high-level view of the SCAP-enabled digital thread for this example. The Common Configuration Enumeration mappings (upper right) include a mapping from CCE-8654-6 to IA-4 in the National Vulnerability Database's security control catalog (lower right). CCE-8654-6 states that a specific Windows 7 system setting should be configured correctly. This system setting is Network access: Do not allow storage of passwords and credentials for network authentication. Its purpose is to minimize the risk of malware gaining access to cached passwords.

The box on the left in Figure 2 shows an Extensible Configuration Checklist Description Format document representing the United States Government Configuration Baseline [15], a checklist that federal agencies use to ensure their Windows 7 systems are configured according to government-wide requirements. The checklist contains both rules and Open Vulnerability and Assessment Language definitions representing system configuration information, assessing machine state, and reporting assessment results. The checklist rule uses the Open Vulnerability Assessment Language definition oval:gov.nist.usgcb.windowsseven:def:88 to automatically verify the correctness of the Windows system setting pertaining to CCE-8654-6. Thus, the Extensible Configuration Checklist Description Format rule together with the Common Configuration Enumeration mapping not only automates protection of a system against a vulnerability, but also asserts that doing so implements a requirement from security control IA-4.

Figure 2

High-level view of the digital thread as used to automate a security check required by IA-4.

Figure 3 and Figure 4 show portions of the SCAP XML representing the mapping from CCE-8654-6 to IA-4 and checklist rule from Figure 2. The scap-core:mapping element in Figure 3 associates CCE-8654-6 with IA-4. The xccdf:ident and xccdf:check elements in Figure 4 associate the rule with CCE-8654-6 and with Open Vulnerability Assessment Language definition oval:gov.nist.usgcb.windowsseven:def:88.

<entry xmlns="http://scap.nist.gov/schema/feed/configuration/0.1"
  xmlns:config="http://scap.nist.gov/schema/configuration/0.1"
  xmlns:scap-core="http://scap.nist.gov/schema/scap-core/0.3" 
  id="CCE-8654-6">
  <config:cce-id>CCE-8654-6</config:cce-id>
  <config:published-datetime>...</config:published-datetime>
  <config:last-modified-datetime>...</config:last-modified-datetime>
  <config:summary>...</config:summary>
  <scap-core:control-mappings>
    <scap-core:control-mapping system-id="http://csrc.nist.gov/..."
      source="http://nvd.nist.gov/" last-modified="...">
      <scap-core:mapping published="...">IA-4</scap-core:mapping>
    </scap-core:control-mapping>
  </scap-core:control-mappings>
</entry>      

<xccdf:Rule xmlns:xccdf="http://checklists.nist.gov/xccdf/1.2">
  <xccdf:title>Network access: Do not allow storage...</xccdf:title>
  <xccdf:description>This setting controls the...</xccdf:description>
  <xccdf:reference>...</xccdf:reference>
  <xccdf:ident system="http://cce.mitre.org">CCE-8654-6</xccdf:ident>
  <xccdf:check system="http://oval.mitre.org/...">...</xccdf:check>
</xccdf:Rule>

NIST SP 800-53 includes guidance for creating and documenting overlays to encourage the sharing of best security practices. An overlay is a set of control customizations applicable to a group of organizations with common security requirements. For example, NIST SP 800-82 (Guide to ICS Security) [13] includes an overlay. Among numerous other customizations, this ICS overlay specifies that security control IA-3 be added to the low baseline as discussed in the tailoring example presented earlier in this section. Due to the increased digitization in manufacturing mentioned in the previous section, ICS are^[2] adopting many characteristics of traditional information systems such as Internet connectivity and use of standard communication protocols. As a result, ICS are vulnerable to many of the same security threats that affect traditional information systems, yet ICS have unique needs requiring additional guidance beyond that offered by NIST SP 800-53.

One can deduce from Table 1 and Table 2 that the SP 800-53 security control catalog has an implicit structure to it. This structure is hierarchical, as controls belong to families, and controls can have enhancements. Both controls and enhancements have impacts. Additionally, the control catalog includes cross references between controls, and prose documentation, which may be associated with a control, or with one or more control enhancements. A tailored control, baseline, or overlay requires additional structure such as associations between a baseline and any revised impacts and added documentation justifying the need for tailoring.

An XML representation for the security control catalog is beneficial. A structured XML format facilitates operations such as navigating hierarchies, following cross references, and performing keyword searches. Additionally, the security control catalog XML can potentially be combined with the SCAP languages such as Extensible Configuration Checklist Description Format to make checklists more data-rich, or conversely to create a browsable control catalog showing the checklists, rules, Open Vulnerability Assessment Language definitions, and/or configuration settings associated with controls.

No SCAP XML format yet exists for representing tailored security control baselines or overlays, and good software support for tailoring controls is lacking. As a result, authoring a tailored control is cumbersome, and tailored baselines and overlays are presented to users in tabular formats that are suboptimal for browsing or using in software development. For example, the NIST SP 800-82 ICS overlay is documented as a series of tables in an appendix. Recently-developed United States Government tailored baselines for mobile devices [16] and cloud computing services [17] have been documented as spreadsheets. None of these three customizations of the SP 800-53 security control catalog are easy for cybersecurity practitioners to navigate or for software developers to implement in an SCAP context. To make matters worse, the ICS overlay and the two tailored baselines all use divergent documentation conventions. So, even if a software developer were to go to the trouble of implementing one of the three, implementing the others would require an undue amount of additional effort.

The ICS overlay and other adaptations of the SP 800-53 security control catalog all qualify as Small Arcane Nontrivial Datasets [18]. A Small Arcane Nontrivial Dataset is sufficiently complex to benefit from specialized software for authoring and access, and important enough to justify the development of such software. On the other hand, Small Arcane Nontrivial Datasets are too small to attract the attention of many software developers, and are certainly not big enough to justify developing a heavyweight, full-blown server-based database application. XForms, an XML application for specifying forms for the Web, is well-suited implementation technology for Small Arcane Nontrivial Datasets [18]. XForms adopts the model-view-controller software pattern, making it a good fit for single-page applications where UI components can be updated without server-side processing or page reloading [19]. Also, because XForms is an XML language, XForms is a good choice for implementations where data is already available as XML, as is the case with the SP 800-53 security control catalog.

An XForms-Authored Security Control Tailoring Application

This section describes a UI, created using XForms, supporting the following operations in accordance with NIST SP 800-53 tailoring guidelines:

The primary goals of the UI are to:

Figure 5 shows a screen capture of the UI before any tailoring has been initiated. The two pulldowns in the upper right hand corner are for choosing an individual control from a control family. The user has chosen security control IA-3 (Device Identification and Authentication) from the Identification and Authentication family. The checkboxes and buttons to the left are for restricting the choices in the control pulldown based on the NIST SP 800-53 default baseline impact and/or priority. In Figure 5, all controls from the NIST SP 800-53 catalog are available.

Figure 5

Security control IA-3 (Device Identification and Authentication).

The user's choice of IA-3 from the control pulldown list causes the UI to generate dynamically a table listing IA-3 with its control enhancements^[3]. The table format mimics that of the ICS overlay in NIST SP 800-82. The two leftmost columns contain the identifier and name for the control and each of its enhancements. To the right of the control name is a button that the user can click to look up the control in the National Vulnerability Database's online NIST SP 800-53 catalog. The third column has pulldown lists for tailoring the baseline impact levels. A pulldown value of LOW indicates the control or enhancement is included in all baselines. MODERATE indicates moderate and high baselines only. HIGH indicates high baseline only^[4]. N/A indicates the control or enhancement is excluded from all baselines. The values shown in Figure 5 are the defaults from the NIST SP 800-53 catalog, which includes IA-3 in the moderate and high baselines but not the low baseline, and excludes IA-3's enhancements from all three default baselines. The checkbox in the fourth column allows the user to provide additional supplemental guidance, beyond that given in NIST SP 800-53, for the control. The pulldown list for each enhancement allows the user to either (1) provide no additional supplemental guidance, (2) provide additional supplemental guidance, or (3) cross-reference supplemental guidance already added for another enhancement. The three rightmost columns show the baseline selections for IA-3 and its enhancements.

The UI displays appropriately worded alert messages if a user violates a tailoring constraint. For example, Figure 6 shows the result when attempting to add IA-3(1) to all baselines. This operation is illegal because it violates the constraint that an enhancement cannot be added to a baseline unless its parent control is added first. Thus, IA-3(1) cannot be added to the LOW baseline without first adding IA-3. Figure 7 shows the result when a control enhancement attempts to cross-reference another control enhancement, but the cross-referenced control enhancement lacks added supplemental guidance.

Figure 6

Violation of baseline impact constraint.

Figure 7

Violation of supplemental guidance cross-reference constraint.

Figure 8 shows the result after modifying IA-3's pulldown and checkbox values to match the tailoring provided in the NIST SP 800-82 ICS overlay. Changing IA-3's baseline impact from MODERATE to LOW results in Added appearing in the LOW column. Checking the box in the ADDED SUPPLEMENTAL GUIDANCE column generates a multiple line free form text field containing editable boilerplate text. Changing the baseline impact for control enhancements IA-3(1) and IA-3(4) from N/A to MODERATE results in Added appearing in the MODERATE and HIGH control baseline columns. Choosing YES from IA-3(1)' s ADDED SUPPLEMENTAL GUIDANCE pulldown list generates an editable text field for adding IA-3(1) supplemental guidance. Cross-referencing IA-3(1)'s added supplemental guidance from IA-(4) does not trigger an alert because IA-3(1)'s pulldown is set to YES. The non-editable text field on the lower left shows XML^[5] generated on the fly based on the pulldown and checkbox settings and editable text field contents.

Figure 8

IA-3 tailored for industrial control systems.

Figure 9 shows the result after the user replaces the boilerplate text in the editable text fields with actual ICS-specific supplemental guidance and rationale for altering the default baselines, and then copy-pastes the generated XML into a third-party XML editor application. To reduce verbosity, the ICS-specific text is shortened using ellipses. The RELAX NG [20] schema in Appendix A specifies the syntax of the XML representation of a tailored security control as generated by the UI. This schema can be used to validate the data shown in Figure 9. The schema can also be used as part of a larger schema for tailored baselines or overlays.

<tailoredControl>
  <family>IDENTIFICATION AND AUTHENTICATION</family>
  <rationale flag="true">ICS may exchange information...</rationale>
  <control number="IA-3">
    <title>DEVICE IDENTIFICATION AND AUTHENTICATION</title>
    <default value="2"/>
    <impact value="1"/>
    <guidance flag="true">The organization may permit...</guidance>
  </control>
  <enhancement number="1">
    <title>CRYPTOGRAPHIC BIDIRECTIONAL AUTHENTICATION</title>
    <default value="4"/>
    <impact value="2"/>
    <guidance flag="true">Configuration management for...</guidance>
  </enhancement>
  <enhancement number="4">
    <title>DEVICE ATTESTATION</title>
    <default value="4"/>
    <impact value="2"/>
    <guidance flag="1"/>
  </enhancement>
</tailoredControl>

The implementation's source code is all XML and is specified using a combination of XForms, Extensible Hypertext Markup Language (XHTML) [21], and Extensible Stylesheet Language Transformations (XSLT) [22]. The implementation uses XSLTForms [23], an XForms processor implemented using XSLT that runs natively in common Internet browser clients without the need for plugins. The main source document's model element contains a collection of instances and bindings as shown in Figure 10. A single dynamic instance represents the current state of the UI and is used for on-the-fly generation of the XML representation text field contents (shown in Figure 8 and Figure 9). The largest of the static instances represents the NIST SP 800-53 security control catalog. This instance consists of the raw catalog data from the National Vulnerability Database, with the detailed descriptions removed to reduce the file size. An XSLT stylesheet generates the data needed to populate the control family and control pulldown lists shown on the upper right of Figure 5. The control enhancement template instance provides the data format for expanding the dynamic instance (via XForms insert and setvalue elements) to represent all the control enhancements for the control selected from the control pulldown list. The impact mapping instance is essentially a table for determining the UI's LOW, MODERATE, and HIGH column text based on the selections in the UI's baseline impact column. The XML display stylesheet is an XSLT document that transforms the dynamic UI settings into the formatted and indented character data comprising the XML representation text field contents.

Figure 10

High-level view of the implementation's XForms model.

The bindings, specified using the XForms bind element, use the constraint property to define constraints such as those shown in Figure 6 and Figure 7^[6], the calculate property to compute UI data from other UI data, and the relevant property to manage the display of the editable rationale and guidance text fields. An example of computed data is the National Vulnerability Database URL that gets accessed when a user clicks on the NIST SP 800-53 button. The editable text fields are displayed only if a Boolean-typed flag attribute is true.

Concluding Remarks

This paper discussed the NIST SP 800-53 cybersecurity risk management framework, using the digital thread as a metaphor for cybersecurity automation. Although SCAP enables many aspects of this digital thread, a significant gap is the lack of a standardized XML format for representing tailored SP 800-53 security controls. Because tailored baselines and overlays are Small Arcane Nontrivial Datasets, there is a need for them to be part of the cybersecurity digital thread, but they are too small and arcane to attract commercial software developers. This paper presented a lightweight UI for tailoring controls, built with XForms. The UI generates structured XML output to be used in concert with existing SCAP languages and taxonomies. The UI also enforces some of the constraints SP 800-53 imposes on tailoring operations.

The UI discussed in the previous section, although demonstrably useful to developers of tailored baselines and overlays, has some limitations. One is the lack of an ability to import an existing tailored control. Such a feature would enable composability, for example performing additional tailoring on an existing overlay. A second limitation is lack of support for NIST SP 800-53 assignment and selection parameters, which allow organizations to define organization-specific values associated with controls. For example, the security control catalog's description for IA-3 is as follows:

In addition to addressing the limitations mentioned, two additional follow-on efforts are underway. The first is an SCAP implementation to be used in NIST's ICS cybersecurity testbed [24,25], whose goal is to measure ICS performance instrumented with security controls in accordance with NIST SP 800-53, NIST SP 800-82, and other national and international standards and guidelines. The SCAP implementation will use XML generated by the UI shown in the previous section to represent the SP 800-82 ICS overlay. Next is an investigation into alternatives to XForms for developing security control tailoring UIs. Recent advances in non-XML single-page application technologies show promise [26], although handling mixed content such as parameters embedded in descriptive text could be challenging.

The third potential follow-on task is to author a UI with XForms (or an alternate single-page application implementation method) for navigating the Core component of United States Government's Cybersecurity Framework [27]. The Framework Core provides a mapping from high-level security functions to outcomes, and from outcomes to existing standards, guidelines and best practices (including NIST SP 800-53 security controls). These mappings can be helpful in guiding the selection of security controls, and can also add useful provenance information to SCAP content. Although the Framework Core is available in a variety of formats (document, spreadsheet, runtime database executable), none of them are both easy to navigate and interoperable with other security automation tools.

Disclaimer

Mention of third-party or commercial products or services in this paper does not imply approval or endorsement by the National Institute of Standards and Technology, nor does it imply that such products or services are necessarily the best available for the purpose.