Lubell, Joshua. “Extending the Cybersecurity Digital Thread with XForms.” Presented at Balisage: The Markup Conference 2015, Washington, DC, August 11 - 14, 2015. In Proceedings of Balisage: The Markup Conference 2015. Balisage Series on Markup Technologies, vol. 15 (2015). https://doi.org/10.4242/BalisageVol15.Lubell01.
Balisage: The Markup Conference 2015 August 11 - 14, 2015
Balisage Paper: Extending the Cybersecurity Digital Thread with XForms
Joshua Lubell is a computer scientist in the NIST Engineering Laboratory's Systems
Integration Division. His interests include model-based engineering, cybersecurity,
cyber-physical systems, long-term preservation of digital data, information modeling,
and
XML and other markup technologies. He received the United States Department of Commerce
Silver Medal for his leadership in developing ISO 10303-203, a standard for representation
and exchange of computer-aided designs. He is also a Balisage local, residing in suburban
Maryland midway between North Bethesda and NIST's Gaithersburg campus.
Official contribution of the National Institute of Standards and Technology; not subject
to copyright in the United States.
Abstract
The digital thread for cybersecurity enables security technologies and data sources
to
interoperate. It consists of an integrated collection of languages, taxonomies, and
metrics
represented using the Extensible Markup Language (XML). A current gap in the cybersecurity
digital thread is the lack of good software for tailoring the security controls found
in
National Institute of Standards and Technology's (NIST) Special Publication (SP) 800-53,
and
exporting the result in a structured XML format. An application built using XForms
demonstrated success in providing a specialized user interface for tailoring security
controls, enforcing NIST SP 800-53 tailoring guidelines, and in generating XML content
suitable for automated processing by other cybersecurity tools.
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 National Vulnerability Database [7], a repository of
standards-based vulnerability data (managed by NIST and sponsored by the Department
of
Homeland Security).
A validation program [8] for establishing and certifying
conformance of software products to SCAP and its component standards.
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.
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.
Table 1
NIST SP 800-53 security control identifiers and family names.
ID
FAMILY
ID
FAMILY
AC
Access Control
MP
Media Protection
AT
Awareness and Training
PE
Physical and Environmental Protection
AU
Audit and Accountability
PL
Planning
CA
Security Assessment and Authorization
PS
Personnel Security
CM
Configuration Management
RA
Risk Assessment
CP
Contingency Planning
SA
System and Services Acquisition
IA
Identification and Authentication
SC
System and Communications Protection
IR
Incident Response
SI
System and Information Integrity
MA
Maintenance
PM
Program Management
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.
Table 2
Low, moderate, and high baselines for IA family.
ID
NAME
LOW
MODERATE
HIGH
IA-1
Identification and Authentication Policy and Procedures
IA-1
IA-1
IA-1
IA-2
Identification and Authentication (Organizational Users)
IA-2 (1) (12)
IA-2 (1) (2) (3) (8) (11) (12)
IA-2 (1) (2) (3) (4) (8) (9) (11) (12)
IA-3
Device Identification and Authentication
Not Selected
IA-3
IA-3
IA-4
Identifier Management
IA-4
IA-4
IA-4
IA-5
Authenticator Management
IA-5 (1) (11)
IA-5 (1) (2) (3) (11)
IA-5 (1) (2) (3) (11)
IA-6
Authenticator Feedback
IA-6
IA-6
IA-6
IA-7
Cryptographic Module Authentication
IA-7
IA-7
IA-7
IA-8
Identification and Authentication (Non-Organizational Users)
IA-8 (1) (2) (3) (4)
IA-8 (1) (2) (3) (4)
IA-8 (1) (2) (3) (4)
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:
A version of the security control catalog in a structured XML format.
An online UI for searching and browsing the catalog XML data.
A repository of checklists encoded in the Extensible Configuration Checklist
Description Format, an SCAP language for representing security checklists, benchmarks,
and other configuration recommendations [14].
A data feed mapping Common Configuration Enumeration values to relevant security
controls. Common Configuration Enumeration, an SCAP taxonomy, provides unique
identifiers for operating system and software security configurations.
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 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.
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:
Adding or removing controls or control enhancements in a baseline. SP 800-53
requires documenting the rationale for modifying the baseline.
Adding additional guidance to a control or control enhancement.
The primary goals of the UI are to:
Make it easy to create tailored baseline documentation.
Enforce constraints on tailoring operations, helping to ensure that the result
follows SP 800-53 guidelines.
Generate XML valid with respect to a schema for tailored controls that can be used
in conjunction with NIST SP 800-53 XML data, SCAP mappings, and other SCAP data to
achieve security automation.
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.
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 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 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.
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.
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:
The information system uniquely identifies and authenticates [Assignment:
organization-defined specific and/or types of devices] before establishing a [Selection
(one or more): local; remote; network] connection.
The description's assignment parameter allows the organization to specify devices
or device types to which IA-3 applies. The selection parameter lets the organizations
specify
which among local, remote, and/or network connections require device identification
and
authentication.
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.
Appendix A. RELAX-NG Schema for a Tailored Security Control
The following RELAX-NG schema specifies the syntax for XML generated by the XForms-authored
user interface. This schema does not enforce the constraints shown in
Figure 6 or Figure 7.
default namespace = ""
start =
## An entire tailored baseline.
element tailoredBaseline {
## Tailoring for a security control from the SP 800-53 catalog.
element tailoredControl {
## Name of the control's family.
element family { text },
## Justification for changing the baseline. If booleanFlag is
## true, then guidance should be provided as text content. If
## booleanFlag is false, then content should be ignored.
element rationale {
booleanFlag,
text
},
## Information specific to a control.
element control {
## Control identifier. Consists of two-letter abbreviation of
## family name + '-' + positive integer.
attribute number { xsd:NCName },
title,
\default,
impact,
## Additional supplemental guidance for a control. If
## booleanFlag is true, then guidance should be provided as
## text content. If booleanFlag is false, then content should
## be ignored.
element guidance {
booleanFlag,
text
}
},
## Information specific to a control enhancement.
element enhancement {
## Enhancement number. When combined with the enhancement's
## control number, uniquely identifies the control enhancement.
attribute number { xsd:integer },
title,
\default,
impact,
## Additional supplemental guidance for a control enhancement.
## If booleanFlag is true, then guidance should be provided as
## text content. If booleanFlag is false, then content should
## be ignored. Otherwise, booleanFlag cross-references the
## guidance of another control enhancement within the parent
## tailoredControl element.
element guidance {
(booleanFlag | posIntFlag),
text
}
}*
}+
}
## Title of a control or control enhancement.
title = element title { text }
\default =
## Baseline impact. 1 represents 'LOW', 2 represents 'MODERATE', 3
## represents 'HIGH', and 4 represents 'N/A' (not in a baseline).
element default {
attribute value { "1"|"2"|"3"|"4" }
}
impact =
## Tailored impact. 1 represents 'LOW', 2 represents 'MODERATE', 3
## represents 'HIGH', and 4 represents 'N/A' (not in a baseline).
element impact {
attribute value { "1"|"2"|"3"|"4" }
}
booleanFlag = attribute flag {xsd:boolean}
posIntFlag = attribute flag {xsd:positiveInteger}
References
[1] D. Wu, D. W. Rosen, L. Wang, and D. Schaefer,
Cloud-based design and manufacturing: A new paradigm in digital
manufacturing and design innovation, Computer-Aided Design, vol. 59, no. 0, pp.
1–14, Feb. 2015. doi:https://doi.org/10.1016/j.cad.2014.07.006.
[2] Feeney A, Frechette SP, Srinivasan V. A Portrait of an ISO STEP Tolerancing Standard as an Enabler of Smart
Manufacturing Systems. ASME. Journal of Computing and Information Science in
Engineering. 2015;15(2):021001-021001-5. doi:https://doi.org/10.1115/1.4029050.
[3] Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation,
26 November 2008. http://www.w3.org/TR/xml.
[6] S. Radack and R. Kuhn, Managing
Security: The Security Content Automation Protocol, IT Professional, vol. 13, no.
1, pp. 9–11, Feb. 2011. doi:https://doi.org/10.1109/MITP.2011.11.
[10] Joint Task Force Transformation Initiative,
Security and Privacy Controls for Federal Information Systems and
Organizations, NIST Special Publication 800-53, Revision 4, April 2013, doi:https://doi.org/10.6028/NIST.SP.800-53r4.
[11] R. Montesino and S. Fenz, Information Security Automation: How Far Can We Go? Availability, Reliability
and Security (ARES), 2011 Sixth International Conference on, pp. 280–285, Aug. 2011.
doi:https://doi.org/10.1109/ARES.2011.48.
[13] Keith Stouffer, Victoria Pillitteri, Suzanne
Lightman, Marshall Abrams, Adam Hahn, Guide to Industrial Control
Systems (ICS) Security, NIST Special Publication 800-82, Revision 2, May 2015.
doi:https://doi.org/10.6028/NIST.SP.800-82r2.
[14] D. Waltermire, C. Schmidt, K. Scarfone, N. Ziring.
Specification for the Extensible Configuration Checklist Description Format
(XCCDF) Version 1.2. NIST Interagency Report 7275 Revision 4. Sep. 2011. http://csrc.nist.gov/publications/PubsNISTIRs.html.
[18] Lubell, Joshua. XForms User
Interfaces for Small Arcane Nontrivial Datasets. Presented at Balisage: The
Markup Conference 2014, Washington, DC, August 5 - 8, 2014. In Proceedings of Balisage:
The
Markup Conference 2014. Balisage Series on Markup Technologies, vol. 13 (2014). doi:https://doi.org/10.4242/BalisageVol13.Lubell01.
[19] A. Mesbah and A. van Deursen, Migrating Multi-page Web Applications to Single-page AJAX Interfaces, Software
Maintenance and Reengineering, 2007. CSMR ’07. 11th European Conference on, pp. 181–190,
Mar.
2007, doi:https://doi.org/10.1109/CSMR.2007.33.
[20] ISO/IEC 19757-2:2008. Information technology —
Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation
— RELAX NG.
[26] Berjon, Robin. Mending Fences
and Saving Babies. Presented at Symposium on HTML5 and XML, Washington, DC,
August 4, 2014. In Proceedings of the Symposium on HTML5 and XML. Balisage Series
on Markup
Technologies, vol. 14 (2014). doi:https://doi.org/10.4242/BalisageVol14.Berjon01.
[27] National Institute of Standards and
Technology (NIST) and United States of America, Framework for Improving
Critical Infrastructure Cybersecurity, 2014. http://www.nist.gov/cyberframework.
[1] The Extensible Configuration Checklist Description Format, discussed in the next
section, represents the implementation of a tailored set of security
controls (Step 3 in Figure 1). This format provides mappings to
(untailored) NIST SP 800-53 security controls but, without an XML representation of
how
the controls are tailored, cannot provide complete traceability between Steps 2 and
3.
[2] This paper follows the NIST SP 800-82 convention of using ICS rather
than ICSs to denote more than one Industrial Control System.
[3]Figure 5 does not show control enhancement IA-3(2) because the current
version (Revision 4) of NIST SP 800-53 incorporates IS-3(2) into IA-3(1).
[4] The UI and underlying model assumes that inclusion in the low baseline implies
inclusion in the moderate baseline, and that inclusion in the moderate baseline implies
inclusion in the high baseline. NIST SP 800-53 security control CM-7 (Least Functionality)
violates this assumption. CM-7 has two mutually exclusive control enhancements, CM-7(4)
(Unauthorized Software: Blacklisting) and CM-7(5) (Unauthorized Software: Whitelisting),
that cannot both be present in the same baseline. The reason is that whitelisting
is a
stronger security measure than blacklisting, and thus it makes no sense to implement
blacklisting for a system where whitelisting has already been implemented. The UI
handles
CM-7 as a special case by enforcing a CM-7-specific constraint on allowable baseline
impact choices for CM-7(4) and CM-7(5). The constraint triggers an alert when the
two
enhancements are assigned the same baseline impact.
[5] See Figure 9 for an easier-to-read presentation of this
XML.
[6] And also the special constraint for CM-7 (see Footnote 4).
D. Wu, D. W. Rosen, L. Wang, and D. Schaefer,
Cloud-based design and manufacturing: A new paradigm in digital
manufacturing and design innovation, Computer-Aided Design, vol. 59, no. 0, pp.
1–14, Feb. 2015. doi:https://doi.org/10.1016/j.cad.2014.07.006.
Feeney A, Frechette SP, Srinivasan V. A Portrait of an ISO STEP Tolerancing Standard as an Enabler of Smart
Manufacturing Systems. ASME. Journal of Computing and Information Science in
Engineering. 2015;15(2):021001-021001-5. doi:https://doi.org/10.1115/1.4029050.
Stephen Quinn, Karen Scarfone, David Waltermire,
Guide to Adopting and Using the Security Content Automation Protocol
(SCAP) Version 1.2 (Draft), NIST Special Publication 800-117, Revision 1 (Draft),
January 2012. http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-117-Rev.%201.
S. Radack and R. Kuhn, Managing
Security: The Security Content Automation Protocol, IT Professional, vol. 13, no.
1, pp. 9–11, Feb. 2011. doi:https://doi.org/10.1109/MITP.2011.11.
Joint Task Force Transformation Initiative,
Security and Privacy Controls for Federal Information Systems and
Organizations, NIST Special Publication 800-53, Revision 4, April 2013, doi:https://doi.org/10.6028/NIST.SP.800-53r4.
R. Montesino and S. Fenz, Information Security Automation: How Far Can We Go? Availability, Reliability
and Security (ARES), 2011 Sixth International Conference on, pp. 280–285, Aug. 2011.
doi:https://doi.org/10.1109/ARES.2011.48.
Keith Stouffer, Victoria Pillitteri, Suzanne
Lightman, Marshall Abrams, Adam Hahn, Guide to Industrial Control
Systems (ICS) Security, NIST Special Publication 800-82, Revision 2, May 2015.
doi:https://doi.org/10.6028/NIST.SP.800-82r2.
D. Waltermire, C. Schmidt, K. Scarfone, N. Ziring.
Specification for the Extensible Configuration Checklist Description Format
(XCCDF) Version 1.2. NIST Interagency Report 7275 Revision 4. Sep. 2011. http://csrc.nist.gov/publications/PubsNISTIRs.html.
Lubell, Joshua. XForms User
Interfaces for Small Arcane Nontrivial Datasets. Presented at Balisage: The
Markup Conference 2014, Washington, DC, August 5 - 8, 2014. In Proceedings of Balisage:
The
Markup Conference 2014. Balisage Series on Markup Technologies, vol. 13 (2014). doi:https://doi.org/10.4242/BalisageVol13.Lubell01.
A. Mesbah and A. van Deursen, Migrating Multi-page Web Applications to Single-page AJAX Interfaces, Software
Maintenance and Reengineering, 2007. CSMR ’07. 11th European Conference on, pp. 181–190,
Mar.
2007, doi:https://doi.org/10.1109/CSMR.2007.33.
Richard Candell, Keith A. Stouffer, Dhananjay
Anand. A Cybersecurity Testbed for Industrial Control
Systems. Proceedings of the 2014 Process Control and Safety Symposium. Houston,
TX. October 6-9, 2014. http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915876.
Berjon, Robin. Mending Fences
and Saving Babies. Presented at Symposium on HTML5 and XML, Washington, DC,
August 4, 2014. In Proceedings of the Symposium on HTML5 and XML. Balisage Series
on Markup
Technologies, vol. 14 (2014). doi:https://doi.org/10.4242/BalisageVol14.Berjon01.
National Institute of Standards and
Technology (NIST) and United States of America, Framework for Improving
Critical Infrastructure Cybersecurity, 2014. http://www.nist.gov/cyberframework.
Author's keywords for this paper:
cybersecurity; XForms; security control; tailored baseline; overlay; SCAP; Security Content Automation Protocol; National Vulnerability Database; NVD; Small Arcane Nontrivial Dataset; Industrial Control System; NIST SP 800-53; NIST SP 800-82