The FRCS Design Cybersecurity Requirements are provided in the Unified Facility Criteria Cybersecurity of Facility-Related Control Systems 2016. The UFC was specifically written to provide guidance to the Architectural, Engineering, Construction, System Integrator and Vendor communities that design, construct, operate and support the DoD FRCS inventory. The following sections describe the major sections of the UFC.

This UFC provides criteria for the inclusion of cybersecurity in the design of control systems in order to address appropriate Risk Management Framework (RMF) security controls during design and subsequent construction.

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.

Note: This UFC is based on NIST SP 800-53 R4 and NIST SP 800-82 R2. As new versions of NIST publications are issued, guidance will be posted on the RMF Knowledge Service (https://rmfks.osd.mil) and will be included in updates to this UFC.

1-1 BACKGROUND.

A control system (CS) typically consists of networked digital controllers and a user interface which are used to monitor, and generally also to control equipment. There are many types of control systems ranging from building control systems to manufacturing control systems to weapon control systems, all with different names and terminology. Facility-related control systems are a subset of control systems that are used to monitor and control equipment and systems related to DoD real property facilities (e.g., building control systems, utility control systems, electronic security systems, and fire and life safety systems).

2-2 5-LEVEL CONTROL SYSTEM ARCHITECTURE.

The 5-Level control system architecture shown in Figure 2-1 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.

2.3 Platform Enclave. 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. More information on the Platform Enclave approach is in APPENDIX D.

The DoD does not procure most installation-wide control systems as an entire 5-Level system as depicted in Figure 2-1. Typically, some Field Control Systems (FCS; architecture Levels 0, 1 and 2 – see Figure 2-2) are procured with a front end, and over time additional FCS are procured. These additional FCS are integrated with the existing front end, and added to the authorization to operate for the existing system to expand the installation-wide system.

Note: The Platform Enclave (traditional IT Front-End) will typically be a CIO responsibility and budget line, while the Operational Architecture (traditional OT Back-End) will typically be a Installations and Environment responsibility and budget line.

Navy Platform Enclave and Operational Architecture

Air Force Platform Enclave and Operational Architecture

3-1 OVERVIEW.

The design of cybersecurity for facility-related control systems is a five step process. In some cases a specific step may be performed by someone other than the designer, but may still require input from the designer. Documentation of cybersecurity-related design decisions and input to others is described in CHAPTER 5.

In addition to requirements specific to Control Correlation Identifier (CCIs), design all control systems according to the minimum cybersecurity design requirements in CHAPTER 4 and cybersecurity requirements otherwise standard for the type of control system being designed.

3-1.1 Five Steps for Cybersecurity Design. The five steps for cybersecurity design are:

  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.
  2. Use the impact levels to select the proper list of controls from NIST SP 800-82.
  3. Using the DoD master Control Correlation Identifier (CCI) list, create a list of relevant CCIs based on the controls selected in Step 2.
  4. Categorize CCIs and identify CCIs that require input from the designer or are the designer’s responsibility.
  5. Include cybersecurity requirements in the project specifications and provide input to others as required.
CHAPTER 5 CYBERSECURITY DOCUMENTATION

This chapter describes cybersecurity documentation that is required as part of the control system design package. This documentation is in addition to the documentation required by the relevant control system design criteria.