Facility-Related Control Systems (FRCS) are physical equipment-oriented technologies and systems that control plants and equipment.  They include devices that meet technical constraints and ensure physical system integrity, are event-driven, and frequently utilize real-time software applications or devices with embedded software.  These specialized systems are pervasive throughout DoD infrastructure and are required to meet numerous safety, performance, security, reliability, and operational requirements.

FRCS typically use Human Machine Interfaces (HMIs) to monitor processes as opposed to the Graphical User Interfaces used for Information Systems (IS).  Many current FRCS systems and subsystems are now a combination of FRCS and IS. In Figure 1, the top pictures show a typical supervisory control and data acquisition (SCADA) Human Machine Interface (HMI)/GUI at the electrical operator’s console, the electrical transmission system infrastructure, and the Remote Transmission Unit (RTU) in the field. The bottom pictures show the HVAC Human Machine Interface (HMI)/GUI at the building engineering operator’s console, a meter, and a building controller for a Utility Monitoring and Control System (UMCS).

 

Figure 1 – FRCS Human Machine Interfaces

FRCS differ significantly from traditional IS (administrative, mission support, and scientific data processing information systems) in that they use specialized software, hardware and protocols. FRCS are often integrated with mainstream organizational information systems to promote connectivity, efficiency, and remote access capabilities.  The “front end” portions of FRCS resemble traditional information systems in that they use the same commercially-available hardware and software components. While the majority of a FRCS system does not resemble a traditional information system (IS), the integration of the FRCS’s “front end” with IS introduces some of the same vulnerabilities that exist in current networked information systems.

FRCS typically have long life spans (in excess of 20 years) and it is common to have installed systems that are no longer supported by the vendor.  This introduces two issues: first, depending upon the relative age and isolation of the system, there may not be a patch or upgrade path for components of the system.  Second, attempting to patch the component or employing modern scanning methods might disrupt the system. FRCSs have experienced complete system shutdown when an intrusion detection system (IDS) or host-based scanning system (HBSS) scan is performed on an otherwise operational FRCS.  Thus, FRCS, updates should be delayed until a thorough analysis of deployment impact has been performed. This added effort will require advance planning and notification of parties involved, and will likely extend security update timelines and require flexibility in security control compliance measurement and enforcement.

While many baseline security controls can be applied to a FRCS, how and where they are implemented varies, primarily because of technical and operational constraints. Interconnections between FRCS and organizational networks and business systems expose FRCS to exploits and vulnerabilities. Any attempts to address these exploits and vulnerabilities must consider the constraints and requirements of the FRCS.

Networked FRCS

Networked FRCS are those systems which have multiple controllers and can have both traditional IP traffic at the Level 3 and up, and Ethernet IP and serial traffic at the lower levels as defined by the UFC 04-010-06 Cybersecurity of Facility-Related Control Systems Reference Architecture Figure 5.1. Depending on the age and type of FRCS, these FRCS MAY have the capability for remote monitoring; almost all 2005 and newer FRCS are IP and web based and typically as part of the vendor service level agreement, most require remote access to the system for maintenance.

There are two types of networked FRCS; Internally Networked (IN), also designated as Closed Restricted Networks (CRN), which have multiple components networked together, but does not have a network connection to anything that is not part of the control system; and FRCS that are Externally Networked (EN), where the control system has multiple component networked together, and does connect to a network that is not part of the control system, most commonly the NIPR, Commercial Carrier/Internet, or separate government backbone network such as DHA Med COI, Navy PSNet or the Air Force COINE.

If the FRCS is a EN (requires a connection to the DoDIN as defined by DoDI 8530.0), it will go through the full 6-step RMF process. If the FRCS is an IN/CRN, it can use the shorter Assess Only process. Both IN and EN FRCS will follow the DoD Control Systems Reference Architecture levels as defined by UFC 04-010-06 Cybersecurity of Facility-Related Control Systems. Organizations will use a tailored set of security controls to evaluate automated control systems consistent with the RMF Assess & Authorize process through the implementation of the applicable controls in NIST SP 800-82R2. 

Non-Networked FRCS

Non-networked FRCS are generally those that consist of a single controller, and do not have the capability for remote monitoring.

Platform Enclave and Operational Architecture ATO’s

DoD has developed the facilities RMF Enclave Boundary approach that provides Defense-In-Depth and which is composed of two distinct authorizations:

  • Platform Enclave (PE) is the traditional IT Front-End (Level 4 and above) provided by hosting service/agency – resourced and managed by CIO/IT
  • Operational Architectures (OA) are the traditional OT Back-End (Level 3 and below) networks, devices and components resourced and managed by Installations, Energy and Environment/Facilities

The IE and ESTCP offices can assist Project Teams to obtain PE integration and documentation to coordinate their OA RMF authorization.

Unified Facility Criteria 04-010-16 Appendix E 5-Level Control System Architecture
E-1 INTRODUCTION

As shown in Figure E-1, control systems are represented as a 5-Level architecture, where each level represents a collection of components that are logically grouped together by function and which generally share a cybersecurity approach. This architecture is defined as a general architecture suitable for a wide range of control systems, thus there are some key considerations when using it to describe a specific control system:

  • Not every implementation of a control system will make use of every level, or every type of component shown at a level.
  • The same device may reside in different levels, depending on its configuration. For example, some controllers may support different networks based on onboard switches, and thus the same device could reside in either Level 1 or Level 2.
  • In many cases, a device will fit multiple sub-levels within the same principal level, usually within Level 2. For example, a Level 2A controller may act as a Level 2C router to a Level 1 network beneath it.

This Appendix describes the 5-Level architecture for control systems and presents cybersecurity considerations for each level. Note that although there are actually more than five levels in the architecture shown in Figure E-1, it is commonly referred to as the “5-Level Control System Architecture”. This architecture applies to all control system types; while many of the example components or technologies included in this Appendix are based on building or utility control systems this is not meant to imply that this architecture is specific to these types of control systems.

 

Figure E-1 5-Level Control System Architecture

E-2 5-LEVEL ARCHITECTURE OVERVIEW

A brief description of each Level (from simple to complex devices) is:

Level 0. Non-networked devices which communicate using analog signals. These include (“dumb”) sensors and actuators as well as non-networked controllers (including their dedicated sensors and actuators). These communicate with Level 1 via hardware I/O (Analog and Binary signals).

Level 1. Networked controllers not on an IP network (e.g., BACnet MS/TP, RS-485 (e.g., DNP, Modbus), LonWorks TP/FT-10).

Level 2. Networked controllers on an IP network.

Level 3. The Field Point of Connection (FPOC), which is a connection between the field control system IP network at Level 2 and the Level 4 IP network.

Level 4. The site-wide IP network used for the control system, along with front end servers and workstations (desktops and laptops).

Level 5. Interfaces to “external” networks (IP networks other than the control system network).

Note that some levels contain sub-levels as indicated in Figure E-1.

The UFC FRCS level architecture is used to define the authorization boundary for FRCS systems and is a logical representation of the FRCS network.  The actual physical system can span many miles; for example, locks and dams, pipelines, and electric transmission and distribution systems can have many non-contiguous components.  Also, there are a number of protocols commonly used by FRCSs to allow the devices within the Layers to communicate both horizontally and vertically. Some of these protocols are:

  • LonWorks
  • BACnet
  • Modbus
  • DNP 3