In September 2016, the U.S. Department of Defense (DoD) published Unified Facilities Criteria (UFC) 4-010-06, Cybersecurity of Facility-Related Control Systems. UFC 4-010-06 is the first cybersecurity design guidance written for architects, engineers, integrators, and operators who plan, construct, and operate the wide array of control systems (e.g., building control, utility control, electronic security, fire and life safety) in DoD facilities. It outlines a risk-management framework (RMF) and is a key milestone of broader cybersecurity efforts of the Office of the Assistant Secretary of Defense for Energy, Installations, and Environment (EI&E).
Though UFC 4-010-06 was written for the DoD, it is applicable to the design of any organization’s control systems. A fundamental underlying principal of UFC 4-010-06 is “defense in depth”; using UFC 4-010-06 with the Department of Homeland Security (DHS) Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) series of publications bolsters the cybersecurity of control systems.
Background
UFC 4-010-06 was almost five years in the making, its development aided by the DoD’s replacement of the Defense Information Assurance Certification and Accreditation Process (DIACAP) with DoD Instruction (DoDI) 8500.01, Cybersecurity, and DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT), in 2014; National Institute of Standards and Technology (NIST) Special Publication (SP) 800-82, Guide to Industrial Control Systems (ICS) Security, in 2015; and several pilot and research-and-development projects (Figure 1).
DoDI 8500.01 and DoDI 8510.01 use “platform IT” (PIT) as an overarching term to describe non-information-technology (IT) networks and components (also often referred to as “operational technologies” [OT]):
Examples of platforms that may include PIT are: weapons systems, training simulators, diagnostic test and maintenance equipment, calibration equipment, equipment used in the research and development of weapons systems, medical devices and health information technologies, vehicles and alternative fueled vehicles (e.g., electric, bio-fuel, Liquid Natural Gas that contain car-computers), buildings and their associated control systems (building automation systems or building management systems, energy management system, fire and life safety, physical security, elevators, etc.), utility distribution systems (such as electric, water, waste water, natural gas and steam), telecommunications systems designed specifically for industrial control systems including supervisory control and data acquisition, direct digital control, programmable logic controllers, other control devices and advanced metering or sub-metering, including associated data transport mechanisms (e.g., data links, dedicated networks).
Highlights of UFC 4-010-06
Chapter 1. Chapter 1 of UFC 4-010-06 is an introduction to the organization of the document and service points of contact:
The RMF relies on the implementation of security controls, where a control is a specific action taken to secure a system. ... The goal of the RMF is to reduce and mitigate vulnerabilities until the risk is acceptable to the System Owner (SO) and Authorizing Official (AO). Under the RMF, risk reduction is not “all or nothing”, rather the security solution must reduce risk while considering the constraints of resources and mission requirements. For application of the RMF to control systems, the determination of cybersecurity risk reduction must also account for any additional risks to system functionality due to application of the security controls.
Chapter 2. Chapter 2 of UFC 4-010-06 is an overview of the RMF. A key element is a reference architecture and glossary DoD services and agencies can use to cybersecure legacy control systems while preparing for new control systems with new cyber capabilities:
Even though control systems are becoming more like standard IT systems, there remain major differences that must be recognized. The 5-Level control system architecture ... is a framework for describing the system architecture of any control system. This architecture allows distinctions to be made between portions of the control system that look like standard IT, and portions that do not look like standard IT. This is important as many security controls can be applied in the normal fashion to the portion of the control system that looks like a standard IT system, but cannot be applied without modification (or sometimes at all) to the portion that does not look like a standard IT system.
Figure 2 is the reference architecture, a slight modification of the ISA99, Industrial Automation and Control Systems Security, version and very similar to the ICS-CERT and SANS Institute architectures.
The reference architecture can be used to define the authorization boundary of the platform enclave (PE), or enclave or demilitarized zone:
Significant portions of the control system resemble a standard IT system which can be implemented in a standard manner for different control systems, regardless of the details of the control system itself. This has led to the creation of the Platform Enclave concept, which groups the “standard IT” portions of the control system, plus related standard policies and procedures, into an entity which can be handled separately from the rest of the control system. In some cases this Platform Enclave will be separately authorized and the overall control system will have two authorizations, one for the Platform Enclave and one for the Operational Architecture which primarily covers the “non-standard IT” components of the system. In other cases a single authorization will be used for the entire system. Even in cases where a single authorization is used, however, it’s helpful to identify and categorize the “standard IT” portions of the control system.
An organization adds its technical details to the reference architecture to describe its PE. The Navy PE (standard IT) and operational-architecture (non-IT) boundaries are shown in Figure 3.
The U.S. Army Corps of Engineers PE (Figure 4) illustrates the complexity of energy-transmission, energy-distribution, and microgrid connections.
Other organizations, such as the Defense Health Agency and the Defense Logistics Agency, are developing tailored reference architectures.
Chapter 3. Chapter 3, “Applying Cybersecurity in Design,” is the meat-and-potatoes portion of UFC 4-010-06, providing five steps for cybersecurity design:
Step 1: Based on the organizational mission and details of the control system, the System Owner (SO) and Authorizing Official (AO) determine the Confidentiality, Integrity, and Availability (C-I-A) impact levels (LOW, MODERATE, or HIGH) for the control system.
Step 2: Use the impact levels to select the proper list of controls from NIST SP 800-82.
Step 3: Using the DoD master Control Correlation Identifier (CCI) list, create a list of relevant CCIs based on the controls selected in Step 2.
Step 4: Categorize CCIs and identify CCIs that require input from the designer or are the designer’s responsibility.
Step 5: Include cybersecurity requirements in the project specifications and provide input to others as required.
Each of the CCIs in Step 3 falls into one or more of the following categories:
- DoD-defined: Either the DoD provides the “organization-selected” value or the DoD implementation guidance states the CCI has been met by existing policy or regulation.
- Designer: The designer provides either design specifications to cover a control-system requirement or input regarding the implementation or lack of feasibility of the CCI.
- Non-designer: The CCI is beyond the responsibility of the designer. Typically, it is the responsibility of the system owner.
- Impractical: The CCI is too impractical to be implemented fully in a control system, but can be implemented in part.
UFC 4-010-06 provides a complete list of CCIs, which number into the thousands. The first few times a designer has to go through it, the process of answering the RMF security control questions and identifying the associated CCI can be confusing and time-consuming. Over time, however, the learning curve straightens and the answers to the questions tend to focus on a specific vendor’s control system.
The DoD took the additional step of breaking down each control and control element into specific actions; each action is identified by a unique Control Correlation Identifier (CCI).
UFC 4-010-06 gives the example of a control that is broken down into 61 separate CCIs, with 11 distinct CCIs for one control enhancement alone.
Vendors are now answering the CCIs as part of their product development, with a goal to get their products onto the approved-products list and achieve a type-accreditation-and-reciprocity letter so an RMF authorization from one service/agency can be used for all.
Chapter 4. Chapter 4, “Minimum Cybersecurity Design Requirements,” provides four high-end objectives:
- Design to minimize failure—reduce dependence on the network for the execution of control strategies, and reduce extraneous functionality.
- Design to manage failure—design for graceful failure.
- Do not implement standard IT functions—control systems are special-purpose systems and must not be used as general computing resources.
- Do not provide remote access—only if required, remote access to the Level 4 network should be provided by the PE or the site IT organization.
Chapter 5. Chapter 5, “Cybersecurity Documentation,” provides cybersecurity documentation requirements for typical design-build or design-bid-build submittals, including:
- Basis of design.
- Concept-design submittal (10 to 15 percent).
- Design-development submittal (35 to 50 percent).
- Pre-final design submittal (90 percent).
- Final design submittal (100 percent).
Appendices. Appendices A through H provide references, a glossary, and explanatory materials.
Beyond UFC 4-010-06
In addition to UFC 4-010-06, a designer must be aware of other UFC, Unified Facilities Guide Specifications (UFGSs), and DoDIs. Technology continues to rapidly change, and the DoD must change with it.
DoDI 8530.01, Cybersecurity Activities Support to DoD Information Network Operations, implements the joint information environment (JIE) and recognizes the DoD Information Network includes DoD IT (e.g., DoD-owned or DoD-controlled information systems, PIT systems, IT products, and services) as defined in DoDI 8500.01 and control systems and industrial control systems as defined in NIST SP 800-82 owned or operated by or on behalf of DoD components. The intent and objective is to have DoD IT aligned to a network-operations security center (NOSC) with the integrated capability to conduct cybersecurity activities. Within the JIE, the NOSC connects to three types of nodes:
- Installation processing node (IPN)—a fixed DoD data center serving a single DoD installation with local services that cannot be (technically or economically) provided from a core data center (CDC). There will be only one IPN per DoD installation, but each IPN may have multiple enclaves to accommodate unique installation needs (e.g., joint bases).
- Special-purpose processing node—a fixed data center or data servers in a fixed facility supporting special-purpose functions that cannot or should not be supported by CDCs or IPNs because of their association with mission-specific infrastructure or equipment (e.g., meteorology, medical, modeling and simulation, test ranges, classrooms).
- Tactical processing node (TPN). TPNs provide services similar to those of fixed CDCs, but are optimized for tactical environments or deployable computing needs. TPNs can be connected to JIE networks, whether in garrison or deployed, in different ways (e.g., terrestrial fiber as opposed to satellite connectivity).
Figure 5 is a conceptual illustration of the emerging JIE, NOSC, nodes, and organizational control systems. Each functional organization is responsible for its PEs and performing the RMF for its IT and OT systems within the enclave.
Summary
As stated in UFC 4-010-06: “While the inclusion of cybersecurity during the design and construction of control systems will increase the cost of both design and construction, it is more cost-effective to implement these security controls starting at design than to implement them on a designed and installed system. Historically, control systems have not included these cybersecurity requirements, so the addition of these cybersecurity requirements will increase both cost and security. The increase in cost will be lower than the increase in cost of applying these requirements after design.”
Michael Chipley, PhD, GICSP, PMP, LEED AP, is a consultant to federal agencies and private-sector clients; contributor to National Institute of Standards and Technology (NIST) Special Publication (SP) 800-82 Revision 2 (R2), Guide to Industrial Control Systems (ICS) Security, and the Department of Homeland Security (DHS) Cyber Security Evaluation Tool (CSET); and creator of the National Institute of Building Sciences’ Cybersecurity for Building Control Systems Workshop Series. He can be contacted at [email protected]. Daryl Haegley, OCP, CCO, has been leading efforts to cybersecure U.S. Department of Defense (DoD) facility-related control systems; is a contributor to NIST SP 800-82 R2, DHS CSET, and Unified Facilities Criteria 4-010-06, Cybersecurity of Facility-Related Control Systems; and is a guest lecturer on cybersecuring DoD control systems for National Defense University and The Institute of World Politics. He can be reached at [email protected]. Eric J. Nickel, RCDD, GICSP, CPT, CEH, is a technical expert with over 19 years of experience in design-build project delivery of turnkey secure information-transport systems. He is the information-technology and infrastructure director for Chinook Systems Inc., a multidisciplinary facilities-engineering firm focused on life-cycle energy-security solutions. He can be reached at [email protected].
Did you find this article useful? Send comments and suggestions to Executive Editor Scott Arnold at [email protected].