Balisage Paper: Integrating Top-down and Bottom-up Cybersecurity Guidance using XML

Introduction

The Cybersecurity Framework CSF and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 SP800-53 are complementary cybersecurity guidance specifications. The Cybersecurity Framework helps practitioners raise awareness within an organization and communicate assessments and objectives to stakeholders. SP 800-53 provides a rigorous methodology for tailoring a comprehensive catalog of security controls to meet an organization’s risk management needs. The Cybersecurity Framework facilitates top-down decision-making, whereas NIST SP 800-53 enables a more bottom-up approach to managing cyber-risk.

Because the Cybersecurity Framework and NIST SP 800-53 are complementary, using the two together can provide a greater benefit than using either alone. But combining the top-down, mission-focused guidance in the Cybersecurity Framework with the bottom-up risk management guidance in NIST SP 800-53 is a challenge. Markup technologies can synthesize the security guidance from the Cybersecurity Framework and NIST SP 800-53 into a coherent whole.

This paper presents research demonstrating that software implemented entirely in the Extensible Markup Language (XML) XML can effectively make it easier for security professionals to use the Cybersecurity Framework and NIST SP 800-53 together. The research also suggests that the approach presented can be successful in solving the more general problem of developing a user interface (UI) to integrate and synthesize information from disparate sources, provided that the quantity of information and number of sources are small enough to not overwhelm limited computational or software development resources. In other words, this approach is intended to enable a developer whose day job does not primarily involve coding to write platform-independent software that is easy and inexpensive to deploy.

The rest of this paper proceeds as follows. Section 2 provides an overview of NIST SP 800-53 and the Cybersecurity Framework. Section 3 presents the technical approach: first in general terms applicable to any scenario involving integration of disparate guidance sources, and then as applied to the implementation discussed in Section 4. Section 4 introduces Baseline Tailor, a software application, implemented using the approach discussed in Section 3, that makes it easier for people to use the Cybersecurity Framework and NIST SP 800-53 security control catalog together. Section 5 presents an example usage scenario demonstrating how Baseline Tailor can help a security professional select the appropriate safeguards for restricting unauthorized access to an Industrial Control System (ICS). Section 6 summarizes some previous third-party research efforts that influenced this work. Section 7 concludes the paper.

Background: NIST SP 800-53 and the Cybersecurity Framework

NIST SP 800-53 provides guidance for selecting and tailoring security controls for information systems. The security controls defined in NIST SP 800-53 should be applied as part of a rigorous risk management process. NIST SP 800-53 organizes its catalog of security controls into eighteen families with each family representing a general security topic. A two-character identifier uniquely identifies the family. Each control has zero or more control enhancements, each of which adds additional functionality to or increases the strength of the control. The catalog specifies three security control baselines: for low, moderate, and high impact information systems. NIST recommends the baselines as starting points for security control selection. 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 baseline for the low impact level (or more succinctly, the low baseline) and tailor them as appropriate.

Table 1 shows the low, moderate, and high baselines for the first six controls in the Access Control (AC) 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 two rightmost columns denote control enhancements, which are declarations of security capability to increase the control's functionality and/or strength. For example, AC-2 (1), which identifies control enhancement (1) of AC-2 (Account Management), states a set of capabilities specific to automated system account management. These capabilities enhance the more general capabilities stated for AC-2, which apply to all types of account management. This paper discusses security control AC-2 in further detail in Section 4, where Figure 6 shows AC-2's XML representation in Baseline Tailor, and in the usage scenario in Section 5.

NIST SP 800-53 also contains 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) SP800-82 specifies an overlay for Industrial Control Systems, which are common in the utility, transportation, chemical, pharmaceutical, process, and durable goods manufacturing industries. An ICS is vulnerable to many of the same security threats that affect traditional information systems, yet has unique needs requiring additional guidance beyond that offered by NIST SP 800-53.

The Cybersecurity Framework provides a way for organizations to describe their current security posture and target state, and to communicate and assess progress toward meeting goals. The Cybersecurity Framework is organized in a hierarchical fashion, which allows for high-level as well as detailed descriptions of security outcomes. It can facilitate communication not only between different categories of stakeholders but also between different levels of management within an organization, for example, between a chief executive and cybersecurity professionals responsible for implementation. In addition, the Cybersecurity Framework links desired security outcomes to specific NIST SP 800-53 security controls, as well as to sections of other standards, guidelines, and best practices offering guidance on how to achieve desired cybersecurity outcomes. This paper focuses specifically on the links to NIST SP 800-53.

A major component of the Cybersecurity Framework is the Framework Core, a taxonomy of cybersecurity outcomes common across critical infrastructure sectors. The highest level of the Framework Core consists of five overarching cybersecurity functions: Identify, Protect, Detect, Respond, and Recover. Each function has a two-character identifier: ID for Identify, PR for Protect, DE for Detect, RS for Respond, and RC for Recover. Each function is subdivided into categories, which are high-level outcomes. Each category's identifier consists of its function identifier, followed by a period, followed by two more characters such that the category identifier uniquely identifies the category. Each category in turn contains a set of subcategories, which are specific lower-level outcomes that support the category’s higher-level outcome. Subcategories are identified numerically in a manner similar to that of security controls within a control family. Each subcategory has informative references providing guidance for achieving the subcategory’s outcome, including references to NIST SP 800-53 security control definitions. The NIST SP 800-53 informative references are essential for synthesizing the Cybersecurity Framework and NIST SP 800-53 guidance, as will be shown in Section 4.

Figure 1 shows the Framework Core functions and categories, with the Protect function's Access Control category (PR.AC) expanded to show all five of its subcategories. The Informative References column on the right only shows references to NIST SP 800-53. References to other standards, guidelines, and best practices are excluded because they are out of scope for this paper. As this column shows, the Cybersecurity Framework is less granular than NIST SP 800-53. References are to controls in their entirety, and do not distinguish between control enhancements or baselines.

Figure 1

Cybersecurity Framework Core with expansion of category PR.AC.

A Framework Profile is a subset of the outcomes in the Framework Core representing either an organization’s current or target security posture. The Cybersecurity Framework is not prescriptive with respect to how an organization should create a Profile, or how much information a Profile should include beyond an enumeration of the Framework Core subcategories it includes. However, the Cybersecurity Framework suggests that an organization consider basing a Profile on business drivers and an assessment of and tolerance for risk. The Baseline Tailor usage scenario discussed in Section 5 involves use of a Framework Profile to support the selection of NIST SP 800-53 security controls. This scenario specifically illustrates how a Framework Profile focusing on category PR.AC (Access Control) can support selection of security control AC-2 (Account Management).

An XML-based Integration Approach

For a general integration approach, applicable for other disciplines besides cybersecurity, consider a generic scenario where multiple information sources need to be combined such that the combined information can be efficiently viewed and manipulated using a common UI. These information sources may or may not be structured XML data. For example, they may be in the form of tables in a document, or as spreadsheets. These information sources can be thought of as Small Arcane Nontrivial Datasets Lubell2014. Although not large enough to justify a heavyweight, server-based database application, a Small Arcane Nontrivial Dataset is complex enough to benefit from specialized software for manipulation and access, and important enough to justify the development of such software. Let us further assume a requirement that any results of manipulating the data be presented to the user as structured XML. The following general approach for developing such software that meets the aforementioned requirements uses three XML technologies: XForms, Extensible Stylesheet Language Transformations (XSLT), and the XML Path Language (XPath).

XForms XForms, an XML application for specifying forms for the Web, is well-suited for implementing UIs for Small Arcane Nontrivial Datasets. XForms adopts the model-view-controller software pattern, making it a good fit for lightweight, data-driven applications. The XForms model consists of a set of instances and a set of bindings. The instances are well-formed XML documents, some static and some dynamic. The bindings define UI constraints, compute dynamic instance data values from other instance data, and manage the display of UI widgets. Because XForms is an XML language, XForms is a good choice for implementations where data is already available as XML, or when XML output is desired. XForms provides a platform-independent set of UI widgets, enabling the same XForms-valid source code to run in multiple browser environments and on multiple operating systems.

Since XForms requires model instances to be well-formed XML, the original information sources may need to be converted to XML from their native formats. XSLT XSLT is particularly well-suited for such a task, even if the source data is non-XML or semi-structured as is the case with Small Arcane Nontrivial Datasets that are spreadsheets or tabular data extracted from documents. If the source is poorly structured, a semi-automated approach combining XSLT with hand-editing may be needed. XSLT is also useful for making flat data hierarchical or vice versa. Additionally, XSLT can be used to create multiple alternatively-structured XForms instances in order to speed up UI operations (at the expense of memory requirements — a space-time tradeoff).

XForms and XSLT both depend on XPath XPath. XForms uses XPath for bindings within the model as well as for specifying interactions between the UI widgets and the model. XSLT uses the XPath data model and XPath's library of functions and operators.

Figure 2 shows a generic pipeline for producing static XForms model instances from native information sources. The pipeline uses XSLT to up-convert an unstructured or semi-structured information source into a well-formed, well-structured instance. XSLT is also used to create additional static instances optimized for specific UI operations.

Figure 2

Generic XML transformation pipeline to produce XForms static model instances.

In the event that the native information source is too poorly structured to support transformation without human intervention, the following semi-automated procedure for extracting tabular data from a semi-structured documentary source can be used:

Baseline Tailor Overview and Implementation

The generic recipe described in the previous section was applied to develop Baseline Tailor, a freely available and open source software tool specifically for users of the Cybersecurity Framework and NIST SP 800-53 security controls. The Baseline Tailor User Guide Lubell2016 describes this software, and multiple usage scenarios, in detail. Lubell2015 provides some implementation details, not discussed in this paper, that are specific to Baseline Tailor's UI for tailoring security controls. Section 5 describes a specific Baseline Tailor usage scenario: synthesizing into a coherent whole the security guidance from NIST SP 800-53, the Cybersecurity Framework, and the NIST SP 800-82 ICS overlay. Without Baseline Tailor, an individual wishing to use these specifications together would have to deal with three separate information sources, each organized differently. Baseline Tailor’s UI makes it easier to use the specifications together. Additionally, Baseline Tailor provides new information derived through integrating the disparate information sources – information not obvious from studying each specification in isolation.

A Baseline Tailor user utilizes the Cybersecurity Framework to determine an organization’s desired security posture, and then tailors an appropriate subset of SP 800-53 security controls needed to make that desire a reality. The Baseline Tailor UI lets users see how Cybersecurity Framework core functions, outcomes and SP 800-53 security controls all relate to one another. It also automatically enforces SP 800-53 tailoring rules. Additionally, the UI produces output in XML so results can be fed directly to other software tools to generate reports, share requirements, or establish assurance. Lubell2016 discusses Baseline Tailor's XML format for tailored controls, UI support for tailoring controls, and automated SP 800-53 enforcement in detail.

The Baseline Tailor UI, shown in Figure 3, has four tabs:

Figure 3

Cyber Framework Browser tab.

Figure 4 shows the transformation pipeline used to produce the Baseline Tailor XForms static model instances. This pipeline is a specialization of the pipeline in Figure 2. The pipeline transformed the following native information sources, enclosed by a coarsely dashed border in Figure 4:

The XSLT stylesheet core.xsl up-converted the semi-structured Framework Core data into a hierarchically structured XForms static instance core.xml. Baseline Tailor uses the data in core.xml to generate the Framework core function radio buttons, Category and Subcategory drop-down lists, and Informative References buttons shown in Figure 3.

The XSLT stylesheet families.xsl generated a static instance families.xml using the data in catalog.xml and core.xml. families.xml is optimized to facilitate retrieval of security controls belonging to a family, and adds for each security control the identifiers from core.xml identifying the Framework Core subcategories that reference the control. The subcategory identifiers are vital to Baseline Tailor for integrating the Cybersecurity Framework and NIST SP 800-53 guidance. Baseline Tailor uses the subcategory information in families.xml to generate the information shown in the Cross References tab. Figure 12 shows the Cross References tab after a user has requested the cross references for security control AC-2.

Figure 4

XML transformation pipeline used to produce Baseline Tailor XForms static model instances.

The XML shown in Figure 5 and Figure 6 illustrates how the Baseline Tailor XForms model represents security controls, subcategories, and their inter-relationships. Figure 5 shows how core.xml represents the category PR.AC (shown earlier as a table in Figure 1). Each category element has an id attribute and contains subcategory elements representing the category's subcategories. To reduce Figure 5's verbosity, only the subcategories with informative references to security control AC-2 — PR.AC-1 and PR.AC-4 — are shown in full detail.

<category id="PR.AC">
  <name>Access Control</name>
  <description>Access to assets…</description>
  <subcategory id="PR.AC-1">
    <description>Identities and credentials…</description>
    <sp800-53>
      <control>AC-2</control><family>IA</family>
    </sp800-53>
  </subcategory>
  <subcategory id="PR.AC-2">…</subcategory>
  <subcategory id="PR.AC-3">…</subcategory>
  <subcategory id="PR.AC-4">
    <description>Access permissions are…</description>
    <sp800-53>
      <control>AC-2</control><control>AC-3</control>
      <control>AC-5</control><control>AC-6</control>
      <control>AC-16</control>
    </sp800-53>
  </subcategory>
  <subcategory id="PR.AC-5">…</subcategory>
</category>

Figure 6 shows how families.xml represents security control AC-2. Baseline Tailor uses the family element's name attribute to populate the UI's Control family drop-down list, shown in Figure 9. After the user selects a family from the list, Baseline Tailor uses the control element’s number attribute and title element to populate the UI's Control drop-down list, shown in Figure 10. The default element represents a security control's baseline impact level (1 for low, 2 for moderate, 3 for high, and 4 if the control is not in one of the NIST SP 800-53 baselines). The priority element represents a security control's priority code. NIST SP 800-53 recommends that Priority 1 controls should be implemented first, followed by priority 2, and finally priority 3. Baseline tailor uses a control's default and priority sub-elements, in conjunction with the user's Baselines and Priorities checkbox selections (as shown in Figure 10), to determine whether to include the control in the Control drop-down list.

The control's subcategory elements reference all Framework Core subcategories that informatively reference the control. The number attributes provide these reverse references. The reverse references to PR.AC-1 and PR.AC-4 correspond to the informative references shown in Figure 5.

<family name="ACCESS CONTROL">
  <control number="AC-1">…</control>
  <control number="AC-2">
    <title>ACCOUNT MANAGEMENT</title>
    <default>1</default>
    <priority>1</priority>
    <subcategory number="PR.AC-1"/>
    <subcategory number="PR.AC-4"/>
    <subcategory number="DE.CM-1"/>
    <subcategory number="DE.CM-3"/>
  </control>
  …
</family>

Baseline Tailor Usage Scenario

The flowchart in Figure 7 shows a suggested workflow for the Baseline Tailor usage scenario of using a Framework Profile and NIST SP 800-82 to support selection of NIST SP 800-53 security controls. The user begins by creating a Profile containing a set of Framework Core subcategories needed to meet a cybersecurity requirement. Next, the user considers each of the Profile’s informative references. For each security control referenced, the user performs the following actions to determine how critical the security control is to achieving the Profile’s outcomes:

If the user deems the security control to be critical for meeting the cybersecurity requirement, the user then proceeds to tailor the security control. The user may apply the NIST SP 800-82 ICS overlay tailoring guidance, if applicable, as a starting point.

As a concrete example of the workflow in Figure 7, suppose a cybersecurity analyst wants to protect an ICS. The analyst decides to use Baseline Tailor to help determine which security controls should be selected and tailored for implementation. The analyst begins by choosing the Protect (PR) core function and Access Control (PR.AC) category in the Cyber Framework Browser tab (as shown in Figure 3). Using the Subcategory drop-down list, the analyst next looks at PR.AC’s five subcategories and decides to create a Profile containing all of them. To do so, the analyst switches to the Framework Profile tab and makes the checkbox selections shown in Figure 8. Baseline Tailor creates a simple XML representation of the Profile on the fly. The Profile, a dynamic XForms model instance, is used to generate (also on the fly) XML output shown in non-editable text field at the bottom of the figure. This XML may be copy-pasted into a third-party XML authoring tool.^[2]

Figure 7

Workflow synthesizing Framework Core, NIST SP 800-53, and NIST SP 800-82 guidance.

Figure 8

Framework Profile tab.

The analyst now switches to the Security Control Editor tab and checks a box restricting control choices to only those that are referenced by subcategories of PR.AC. As shown in Figure 9, the PR.AC subcategories reference only four of the eighteen NIST SP 800-53 control families. Now suppose the analyst selects ACCESS CONTROL from the “Control family” drop-down list, and then chooses “AC-2 – ACCOUNT MANAGEMENT” from the “Control” drop-down list populated with the subset of the Access Control family that the Profile references (Figure 10). The Security Control Editor tab now displays the UI for tailoring AC-2, the upper portion of which is shown in Figure 11.^[3]

Figure 9

Control families referenced by PR.AC subcategories.

Figure 10

Controls belonging to Access Control family that are referenced by PR.AC subcategories.

Figure 11

Security control AC-2.

At this point, the analyst wishes to determine security control AC-2’s criticality with respect to Framework Core category PR.AC. Clicking the “Framework Core Subcategories Referencing AC-2” button in Figure 9 switches to the Cross References tab, revealing that two of the five PR.AC subcategories – PR.AC-1 and PR.AC-4 – reference AC-2 (shown in Figure 12). Concluding that security control AC-2 should be selected for implementation, the analyst clicks the AC-2 button shown in the upper left of Figure 11 to look up AC-2’s definition in the NIST SP 800-53 online database. Items d, i, and k in the AC-2 Control Description (Figure 13) are relevant to category PR.AC. The analyst therefore decides to go ahead and tailor AC-2 for the ICS.

Figure 12

Subcategories referencing AC-2.

Figure 13

NIST SP 800-53 online database: AC-2 description.

The analyst now clicks on the button with the factory image in Figure 11, to the right of the AC-2 button, to view AC-2’s tailoring guidance in the NIST SP 800-82 ICS overlay. The overlay guidance (Figure 14) retains the same baseline allocation as NIST SP 800-53, but adds ICS-specific supplemental guidance suggesting compensating controls. Compensating controls are alternatives, for when the NIST SP 800-53 recommendations are not feasible, that provide comparable protection. The compensating controls mentioned in Figure 14 meet requirements specific to ICS. For example, an ICS may have limited network connectivity and only a small number of potential users, making physical security measures possibly more cost-effective than account management (where information processing overhead might impact performance). Using the NIST SP 800-82 guidance as a starting point, the analyst proceeds to tailor AC-2 using Baseline Tailor’s Security Control Editor tab.

Figure 14

NIST SP 800-82 ICS Overlay definition: AC-2.

To summarize, the scenario discussed in this section shows how a UI implemented solely with XML technologies can increase the utility of the Framework Core, NIST SP 800-53 database, and NIST SP 800-82 ICS overlay. Baseline Tailor not only provides a common UI bringing them all together, but also derives important inter-relationships. As the example showed, a Framework Profile can be used to limit the Security Control Editor tab’s “Control family” and “Control” drop-down choices to the subset of NIST SP 800-53 security controls likely to be most relevant to the Profile. In addition, the Cross References tab can be used as a metric for a security control’s importance with respect to the Framework Core.

Related Research

Previous research efforts in the areas of risk management, quality and comprehension of spreadsheet data, and the use of XPath for data integration influenced the approach described in this paper.

Linkov et al. Linkov studied existing risk-based guidance in the nuclear power regulation, nanotechnology, and cybersecurity fields. Defining risk as the product threat×vulnerability×consequence, they found that in all three cases a traditional bottom-up approach was insufficient for quantifying these three variables. Reasons why included uncertainty regarding emerging threats, lack of clear guidance for risk mitigation and determining risk tolerance, and a poor understanding of stakeholders' socio-political concerns. Linkov et al. concluded that a hybrid approach combining top-down decision making with bottom-up risk analysis can make it easier for organizations to determine and manage risk. With respect to cybersecurity, Linkov et. al observed that NIST's Guide for Conducting Risk Assessments SP800-30 recommends taking an organization's risk tolerance into account when assessing risk. The Framework Profile part of the Cybersecurity Framework helps in fulfilling this recommendation by providing a means for ensuring that an organization's cybersecurity strategy, risk tolerance, and mission/business objectives are all aligned.

Numerous research efforts focused on issues with spreadsheets as a means of representing and disseminating information, a common thread being the inability of spreadsheets to capture context. Context includes information such as why content was created and how it relates to other content OAIS. Durusau and Hunting Durusau, citing news reports of business calamities that were caused by errors in spreadsheet data, enumerated root causes of the errors and suggested that topic maps could help in providing the missing context information. Kohlhase et al. Kohlhase conducted experiments that confirmed lack of context information as a major cause of semantic misunderstandings of data in spreadsheets. Hung et al. Hung developed a spreadsheet-like formula language to map spreadsheet data to a target schema and implemented the language as an Excel plug-in. Cunha et al. Cunha2009a,Cunha2009b, employing methods for automatically detecting functional dependencies, developed and implemented formalized approaches for improving spreadsheet quality.

Recent advances in cloud computing and web technologies have motivated researchers to investigate XPath and XPath-based languages as a means for integration of information from distributed sources. Pedersen et al. Pedersen used XPath as part of a formal semantic foundation for on-the-fly multidimensional data integration. The formalism uses XPath combined with a subset of the Structured Query Language (SQL) Date. Rennau and Grün Rennau determined that XQuery XQuery is a highly useful integration language for heterogeneous information sources, with the caveat that enhancements to XQuery and related standards are needed to improve navigational abilities for some non-XML sources.

Concluding Remarks

This paper presented a technical approach employing XSLT and XForms for developing a UI that integrates information from multiple sources. The original information sources may or may not be XML, and the original presentation may be either top-down or bottom-up. The Baseline Tailor software application validates the technical approach, adding value for cybersecurity professionals wishing to use the Cybersecurity Framework and NIST SP 800-53 guidance together. The core.xml static XForms model instance that provides the information displayed in the Cyber Framework Browser tab (Figure 3) a useful contribution in its own right since the current edition of the Cybersecurity Framework lacks a structured XML representation of the Framework Core. The Baseline Tailor software application, core.xml, and related XML resources are available at http://www.nist.gov/el/msid/baselinetailor.cfm.

Interestingly, Baseline Tailor was originally conceived as software only for tailoring the SP 800-53 security controls. A later version added the ability to browse the Cybersecurity Framework Core, but did not support bidirectional traversal of links between subcategories and security controls. Full integration came later, after the author began working with a team developing a Framework Profile for manufacturing systems. To incorporate guidance from the NIST SP 800-53 security control catalog and NIST SP 800-82 ICS overlay into the Manufacturing Profile, the team frequently needed to trace backwards from security controls to subcategories. This was cumbersome using the tables in the Cybersecurity Framework and NIST SP 800-53 documents. Baseline Tailor's Cross References tab made the task much easier. The team's experience before versus after the Cross References tab was added to Baseline Tailor validates the hybrid approach to risk management advocated in Linkov.

A major limitation of the technical approach described in Section 3 is its reliance on hand-editing for semi-automated conversion of spreadsheet data to XML. It might be feasible to implement a more automated solution using the mapping language developed by Hung et al., or functional dependency detection methods from Cunha et al. A challenge with either automation approach would be getting spreadsheet authors to cooperate. A big attraction of spreadsheets as a medium for disseminating information is that authoring them is easy. Requiring authors to encode transformation logic as formulas or to think about functional dependencies makes spreadsheet production harder, although it may make life easier for spreadsheet consumers.

Acknowledgments

The author would like to thank KC Morris, Bob Lipman, Rick Candell, and the Balisage peer reviewers for their helpful comments on earlier drafts of this paper. Any remaining mistakes are the author's sole responsibility. Thanks are also due to the author's colleagues on NIST's Cybersecurity for Smart Manufacturing Systems project for their support and for many enlightening discussions.

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.