Attachment 13 - ufc_4_010_06_2023.pdf

UFC 4-010-06

10 October 2023

UNIFIED FACILITIES CRITERIA (UFC)

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED

CYBERSECURITY OF

FACILITY-RELATED

CONTROL SYSTEMS (FRCS)

This Page Intentionally Left Blank

UNIFIED FACILITIES CRITERIA (UFC)

CYBERSECURITY OF FACILITY-RELATED CONTROL SYSTEMS (FRCS)

Any copyrighted material included in this UFC is identified at its point of use.

Use of the copyrighted material apart from this UFC must have the permission of the copyright holder.

Indicate the Military Department Preparing Activity responsible for the document.

U.S. ARMY CORPS OF ENGINEERS

NAVAL FACILITIES ENGINEERING SYSTEMS COMMAND (Preparing Activity)

AIR FORCE CIVIL ENGINEER CENTER

Record of Changes (changes are indicated by \1\ ... /1/)

Change No. Date Location

This UFC supersedes UFC 4-010-06, dated September, 2016, with Change 1 dated January 2017.

FOREWORD

The Unified Facilities Criteria (UFC) system is prescribed by MIL-STD 3007 and provides planning, design, construction, sustainment, restoration, and modernization criteria, and applies to the Military Departments, the Defense Agencies, and the DoD Field Activities in accordance with USD (AT&L) Memorandum dated 29 May 2002. UFC will be used for all DoD projects and work for other customers where appropriate. All construction outside of the United States, its territories, and possessions is also governed by Status of Forces Agreements (SOFA), Host Nation Funded Construction Agreements (HNFA), and in some instances, Bilateral Infrastructure Agreements (BIA). Therefore, the acquisition team must ensure compliance with the most stringent of the UFC, the SOFA, the HNFA, and the BIA, as applicable.

UFC are living documents and will be periodically reviewed, updated, and made available to users as part of the Military Department’s responsibility for providing technical criteria for military construction. Headquarters, U.S. Army Corps of Engineers (HQUSACE), Naval Facilities Engineering Systems Command (NAVFAC), and Air Force Civil Engineer Center (AFCEC) are responsible for administration of the UFC system. Technical content of UFC is the responsibility of the cognizant DoD working group. Defense Agencies should contact the respective DoD Working Group for document interpretation and improvements. Recommended changes with supporting rationale may be sent to the respective DoD working group by submitting a Criteria Change Request (CCR) via the Internet site listed below.

UFC are effective upon issuance and are distributed only in electronic media from the following source:

• Whole Building Design Guide website https://www.wbdg.org/ffc/dod.

Refer to UFC 1-200-01, DoD Building Code, for implementation of new issuances on projects.

AUTHORIZED BY:

PETE G. PEREZ, P.E., SES

Chief, Engineering and Construction U.S. Army Corps of Engineers

R. S. SILVER, P.E.

Acting Chief Engineer and Assistant Commander, Design and Construction Naval Facilities Engineering Systems Command

DAVID H. DENTINO, SES

Deputy Director of Civil Engineers DCS/Logistics, Engineering & Force Protection (HAF/A4C) HQ United States Air Force

MICHAEL McANDREW, SES Deputy Assistant Secretary of Defense (Construction) Office of the Secretary of Defense http://www.wbdg.org/pdfs/ufc_implementation.pdf https://www.wbdg.org/ffc/dod i

TABLE OF CONTENTS

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND

1-1.1 Control System Definition

1-1.2 Facility-Related Control Systems

1-1.3 Risk Management Framework (RMF)

1-2 PURPOSE AND SCOPE

1-3 APPLICABILITY

1-4 GENERAL BUILDING REQUIREMENTS

1-5 ORGANIZATION

1-6 CYBERSECURITY POINTS OF CONTACT BY SERVICE

1-7 GLOSSARY

1-8 REFERENCES

CHAPTER 2 CONTROL SYSTEM CYBERSECURITY OVERVIEW

2-1 RISK MANAGEMENT FRAMEWORK OVERVIEW

2-1.1 Security Controls

2-1.2 RMF Goal

2-1.3 RMF Roles of the Designer and Control System Installer

2-1.4 Platform Information Technology

2-1.5 Inherited Security Controls

2-1.6 Applicability of RMF Security Controls to Design

2-2 5-LEVEL CONTROL SYSTEM ARCHITECTURE

2-2.1 Architecture Is a General Architecture

2-2.2 “Standard IT” Parts of the Control System

2-2.3 “Non-Standard IT” Parts of the Control System

2-2.4 Wireless Networks

2-2.5 Platform Enclave

2-3 CONTROL SYSTEM PROCUREMENT OVERVIEW

CHAPTER 3 APPLYING CYBERSECURITY IN DESIGN

3-1 OVERVIEW

3-1.1 Five Steps for Cybersecurity Design

3-1.2 Definition of “Organization”

3-1.3 Designer Coordination ii

3-2 STEP 1: DETERMINE CONTROL SYSTEM IMPACT RATING TO USE

FOR DESIGN

3-2.1 Obtaining Actual Impact Ratings

3-2.2 When Impact Ratings Aren’t Provided

3-2.3 Considerations for Reduction of Control System Impact

3-3 STEP 2A: DETERMINATION OF SECURITY CONTROLS

3-3.1 Overlay versus Baseline

3-3.2 Determining Initial Control Set Using an Overlay

3-3.3 Recommend Security Controls to Tailor Out (or In)

3-3.4 Additional Resources and Information for Step 2A

3-4 STEP 2B: IDENTIFICATION OF CONTROL CORRELATION

IDENTIFIERS

3-5 STEP 2C: CATEGORIZATION OF CONTROL CORRELATION

IDENTIFIERS BY RESPONSIBILITY

3-5.1 Identifiers by Responsibility

3-5.2 Additional Resources and Information For Step 2C

3-6 STEP 3: INCORPORATE CYBERSECURITY REQUIREMENTS

3-6.1 Addressing DoD Selected Values in CCIs

3-6.2 Other “Organization Defined Values” in CCIs

3-6.3 Requirement Definition and Implementation CCIs

3-6.4 Additional Resources and Information for Step 3

CHAPTER 4 MINIMUM CYBERSECURITY DESIGN REQUIREMENTS

4-1 DESIGN TO MINIMIZE FAILURE

4-1.1 Reduce Dependency on the Network

4-1.2 Reduce Extraneous Functionality

4-2 DESIGN TO MANAGE FAILURE

4-2.1 Design for Graceful Failure

4-2.2 Degraded Operation

4-2.3 Redundancy

4-2.4 Redundancy with independent control systems

4-3 DO NOT IMPLEMENT STANDARD IT FUNCTIONS

4-4 DO NOT PROVIDE REMOTE ACCESS

4-5 AVOID PROBLEMATIC NETWORKS

4-6 PROTECT THE CONTROL SYSTEM WITH PHYSICAL SECURITY

iii

4-7 PROTECT PRIVILEGED USER INTERFACES

4-8 EMPLOY PRINCIPALS OF DESIGN SIMPLICITY

4-8.1 Example: Using PLCs for HVAC Control

4-8.2 Consideration of Overall System Risk

4-9 CYBERSECURITY DURING CONSTRUCTION

4-10 ADDITIONAL REQUIREMENTS FOR MODERATE SYSTEMS

CHAPTER 5 CYBERSECURITY DOCUMENTATION

5-1 OVERVIEW

5-2 USE OF GUIDE SPECIFICATION

5-3 COORDINATION WITH OTHER DISCIPLINES

5-3.1 Determination of Points of Contact

5-3.2 UFGS Coordination Issues

5-4 REQUIREMENTS BY DESIGN PHASE

5-4.1 Basis of Design (10-15%)

5-4.2 Concept Design (30-35%)

5-4.3 Interim Design (50-65%)

5-4.4 Final Design (Unreviewed 100%)

5-4.5 Issued for Construction (Reviewed 100%)

APPENDIX A RISK MANAGEMENT FRAMEWORK (RMF) OVERVIEW

A-1 RMF OVERVIEW

A-2 RMF PROCESS

A-3 DEFINITION OF CONTROLS FROM NIST AND DODI 8510

A-3.1 Control Families

A-3.2 Control Elements and Enhancements

A-3.3 Control Correlation Identifiers

A-4 REQUIREMENT DEFINITION VS IMPLEMENTATION

A-4.1 CCIs Defining a Requirement

A-4.2 CCIs Requiring Implementing a Requirement

A-5 PLATFORM INFORMATION TECHNOLOGY

APPENDIX B PLATFORM ENCLAVE

B-1 PLATFORM ENCLAVE CONCEPT OVERVIEW

B-2 PLATFORM ENCLAVE USING TWO AUTHORIZATIONS

B-3 PLATFORM ENCLAVE BENEFITS

iv

B-4 ARMY PLATFORM ENCLAVE APPROACH

B-5 NAVY PLATFORM ENCLAVE APPROACH FOR BCS AND UCS

B-6 AIR FORCE PLATFORM ENCLAVE APPROACH

APPENDIX C 5-LEVEL CONTROL SYSTEM ARCHITECTURE

C-1 INTRODUCTION

C-2 5-LEVEL ARCHITECTURE OVERVIEW

C-3 LEVEL 0: SENSORS AND ACTUATORS

C-4 LEVEL 1: FIELD CONTROL SYSTEM (NON-IP)

C-5 LEVEL 2: FIELD CONTROL SYSTEM (IP)

C-6 LEVEL 3: FIELD POINT OF CONNECTION (FPOC)

C-7 LEVEL 4: CONTROL SYSTEM FRONT END AND CONTROL SYSTEM

IP NETWORK

C-8 LEVEL 5: EXTERNAL CONNECTION AND CONTROL SYSTEM

MANAGEMENT

C-9 ARCHITECTURE FREQUENTLY ASKED QUESTIONS (FAQ)

APPENDIX D CONSIDERATIONS IN DETERMINATION OF CONTROL SYSTEM

IMPACT RATINGS

D-1 BACKGROUND

D-1.1 Types of Security Breach

D-1.2 Impact Ratings

D-2 SYSTEM CATEGORIZATION AND DETERMINATION OF IMPACT

RATING

D-2.1 Compare to Similar to Systems

D-2.2 Methodical System Review

D-2.3 System categorization based on Facility-Related Control Systems (FRCS) Master List

D-2.4 NIST SP 800-60, Vol. II -Rev. 1, Information Types

D-2.5 Summary and required categorization rationale

APPENDIX E CYBERSECURITY CONSIDERATIONS FOR INTEGRATING CRITICAL

UTILITY OR BUILDING CONTROL SYSTEMS WITH NON-CRITICAL UMCS

E-1 INTRODUCTION

E-2 LIMIT OUTSIDE FUNCTIONALITY

E-3 FCS-UMCS CONNECTION METHODS

E-3.1 Hardware I/O Interface

E-3.2 Hardware Gateway Interface v

E-3.3 Firewall Interface

E-3.4 Data Diodes

E-4 OTHER CONSIDERATIONS

E-4.1 Local User Interfaces

E-4.2 Management of Risk

APPENDIX F IMPLEMENTATION GUIDANCE FOR SECURITY CONTROLS

F-1 INTRODUCTION

F-2 GENERAL GUIDANCE

F-2.1 Control System versus Standard IT System Terminology

F-2.2 DoD-Defined Values

F-2.3 Security Controls Which are “Automatically Met”

F-2.4 Security Controls Applicability by Architecture Level

F-2.5 Impact Level Applicability

F-3 GUIDANCE FOR INDIVIDUAL SECURITY CONTROLS

F-3.1 Access Control (AC) Control Family

F-3.2 Audit and Accountability (AU) Control Family

F-3.3 Security Assessment and Authorization (CA) Control Family

F-3.4 Configuration Management (CM) Control Family

F-3.5 Contingency Planning (CP) Control Family

F-3.6 Identification and Authorization (IA) Control Family

F-3.7 Incident Response (IR) Control Family

F-3.8 Maintenance (MA) Control Family

F-3.9 Media Protection (MP) Control Family

F-3.10 Physical and Environmental Protection (PE) Control Family

F-3.11 Planning (PL) Control Family

F-3.12 Program Management (PM) Control Family

F-3.13 Personnel Security (PS) Control Family

F-3.14 Risk Assessment (RA) Control Family

F-3.15 System and Services Acquisition (SA) Control Family

F-3.16 System and Communications Protection (SC) Control Family

F-3.17 System and Information Integrity (SI) Control Family

APPENDIX G CONTROL CORRELATION IDENTIFIER (CCI) TABLES

G-1 INTRODUCTION

vi

G-2 TABLE STRUCTURE AND CONTENT

G-3 CCI TABLE NOTES

G-3.1 Controls Inherited from Platform Enclave

G-3.2 CCIs in Multiple Tables

G-4 CCI TABLE DESCRIPTIONS

G-5 CCI TABLES

APPENDIX H GLOSSARY

H-1 ACRONYMS

H-1.1 General Acronyms

H-1.2 Security Control Family Acronyms

H-2 DEFINITION OF TERMS

APPENDIX I REFERENCES

FIGURES

Figure 2-1 5-Level Control System Architecture Figure 2-2 Control System Architecture Figure 3-1 Overview of Steps 2A through 3 Figure A-1 NIST Risk Management Framework Steps Figure A-2 NIST SP 800-53 Control AC-2 Figure B-1 Navy Platform Enclave and Operational Architecture Figure C-1 5-Level Control System Architecture Figure D-1 - FRCS Impact Determination Flowchart Part 1 Determining Mission

Impact Figure D-2 - FRCS Impact Determination Flowchart Part 2a Determining FRCS

Impact Based on Mission Impact Figure D-3 - FRCS Impact Determination Flowchart Part 2b Determining FRCS

Impact Based on Mission Impact Figure D-4 – Example FRCS Master List Entry UMCS Categorization Based on

Mission Criticality Figure E-1 Hardware I/O Interface Example

TABLES

Table 3-1 Overlay versus Baseline Table C-1 Level 0 Table C-2 Level 1 Table C-3 Level 2 Table C-4 Level 3 Table C-5 Level 4 Table C-6 Level 5 vii

Table F-1 Access Control (AC) Control Family Table F-2 Audit and Accountability (AU) Control Family Table F-3 Security Assessment and Authorization (CA) Control Family Table F-4 Configuration Management (CM) Control Family Table F-5 Contingency Planning (CP) Control Control Family Table F-6 Identification and Authorization (IA) Control Control Family Table F-7 Maintenance (MA) Control Control Family Table F-8 Media Protection (MP) Control Family Table F-9 Physical and Environmental Protection (PE) Control Family Table F-10 Planning (PL) Control Family Table F-11 Program Management (PM) Control Family Table F-12 Risk Assessment (RA) Control Family Table F-13 System and Services Acquisition (SA) Control Family Table F-14 System and Communications Protection (SC) Control Family Table F-15 System and Information Integrity (SI) Control Family Table G-1 Summary of CCIs for LOW and MODERATE Impact Systems Table G-2 CCIs Not Applicable to Control Systems (CS) Table G-3 CCIs Removed from LOW Impact Control Systems Baseline Table G-4 Designer CCIs for LOW and MODERATE Impact Control Systems Table G-5 Additional Designer CCIs for MODERATE Impact Control Systems ... 181 Table G-6 Platform Enclave CCIs for LOW and MODERATE Impact Control

Systems Table G-7 Additional Platform Enclave CCIs for MODERATE Impact Control

Systems viii

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND.

1-1.1 Control System Definition

Control systems are a combination of special purpose controlling devices (controllers), control components (e.g. electrical, mechanical or pneumatic sensors and actuators), and generally (but not always) network infrastructure (which may contain standard IT components) that act together upon underlying mechanical and/or electrical equipment to achieve an objective. A control system (CS) typically consists of sensors and actuators connected to networked digital controllers, includes a user interface, and is used to control and monitor equipment.

Some control systems are “monitor only” (they do not exercise control) but are still considered control systems.

1-1.2 Facility-Related Control Systems

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 (FRCS) are a subset of control systems that are used to monitor and control equipment and systems related to DoD real property facilities (for example, building control systems, utility control systems, electronic security systems, and fire and life safety systems).

1-1.3 Risk Management Framework (RMF)

The Risk Management Framework (RMF) is the DoD process for applying cybersecurity to information technology (IT), including control systems. The RMF categorizes systems by the impact the system can have on organizational mission using HIGH, MODERATE, and LOW impact levels. The RMF is further described in CHAPTER 2 and APPENDIX A.

1-2 PURPOSE AND SCOPE.

This UFC describes requirements for incorporating cybersecurity in the design of all facility-related control systems which include a network. This UFC covers the cybersecurity aspects of control system design, and the requirements of this UFC must be coordinated with the control system design and the criteria relevant to the control system. This UFC only covers aspects specific to control system design. Many projects have IT-specific components (such as IP network design security) which are not covered by this UFC; in those cases, the controls designer will need to coordinate with other disciplines. This UFC defines a process for identification of cybersecurity requirements based on the Risk Management Framework suitable for control systems of any impact rating and provides specific guidance suitable for control systems assigned LOW or MODERATE impact level.

This UFC covers the incorporation of cybersecurity concepts and requirements in support of the Risk Management Framework. This UFC does not implement the RMF and does not address anything beyond the design of the system. Use of this UFC does not result in an ATO under the RMF process but will provide a system that is more capable of receiving an ATO than a system not designed in accordance with this UFC.

1-3 APPLICABILITY.

This UFC applies to all planning, design and construction, renovation, and repair of new and existing facilities (both permanent and non-permanent) and installations that result in DoD real property assets which include a control system with a network, regardless of funding source (and regardless of network type). Restated another way, this UFC applies to any project with any control system that includes architecture levels, as defined in this UFC, of 1 or higher. While this UFC can assist with the design of any system, portions of it are applicable only to the design of LOW and MODERATE impact systems and HIGH Impact system will typically require additional customized requirements to achieve appropriate levels of cybersecurity. Design of such systems should be coordinated with the points of contact provided in Paragraph 1-6.

In defining specific requirements for LOW or MODERATE systems, this UFC assumes the control system is being implemented on a DoD Installation or other DoD site, which allows inheritance of some cybersecurity controls. Systems not being implemented on a DoD Installation may require additional requirements not included in this UFC.

1-4 GENERAL BUILDING REQUIREMENTS.

Comply with UFC 1-200-01, DoD Building Code (General Building Requirements). UFC 1-200-01 provides applicability of model building codes and government unique criteria for typical design disciplines and building systems, as well as for accessibility, antiterrorism, security, high performance and sustainability requirements, and safety.

Use this UFC in addition to UFC 1-200-01 and the UFCs and government criteria referenced therein.

1-5 ORGANIZATION.

CHAPTER 2 provides an overview of the RMF as it applies to control systems, control system architecture and the cybersecurity approach to control systems. CHAPTER 3 defines a 5-step approach to incorporating cybersecurity into the design of control systems. CHAPTER 4 defines minimum design requirements for control systems to be implemented in addition to the specific requirements identified through the 5-step process described in CHAPTER 3. CHAPTER 5 defines the submittal requirements for documenting cybersecurity aspects of control system design.

APPENDIX A provides an overview of the Risk Management Framework as it pertains to control systems. APPENDIX B provides additional detail on the Platform Enclave concept. APPENDIX C describes the 5-Level architecture for control systems.

APPENDIX D describes considerations in determination of control system impact ratings. APPENDIX E discusses considerations in the integration of critical building systems into a non-critical UMCS. APPENDIX F provides guidance for security control families, and individual security controls. APPENDIX G categorizes CCIs by impact and responsibility.

1-6 CYBERSECURITY POINTS OF CONTACT BY SERVICE.

Cybersecurity policies and approaches are evolving, and projects may have unique requirements. Assistance for control system cybersecurity design is available from the following Service organizations:

• Army, other than Civil Works: Control System Cybersecurity Mandatory Center of Expertise (CSC-MCX), Huntsville Engineering and Support Center (CSC-MCX@usace.army.mil)

• Army, Civil Works: HQUSACE Engineering and Construction Control System Community of Practice Leader (controlsystemcopleader@usace.army.mil).

• Navy (and Marine Corps): Naval Facilities Engineering Command, Command Information Office (CIO).

• Air Force (and Space Force): Air Force Civil Engineering Center (AFCEC) Operations Directorate, Tyndall Air Force Base. Support can be obtained via the reach-back center at AFCEC.RBC@us.af.mil. Note: All requests for support must be initiated by the Contracting Officer's Representative (COR) or, for government-designed projects, by the Project Lead.

1-7 GLOSSARY.

APPENDIX H contains acronyms, abbreviations, and definitions.

1-8 REFERENCES.

APPENDIX I contains a list of references used in this document. The publication date or revision of the code or standard is not always included in this document. Unless otherwise specified, the most recent edition of the referenced publication applies.

mailto:CSC-MCX@usace.army.mil mailto:controlsystemcopleader@usace.army.mil mailto:AFCEC.RBC@us.af.mil

CHAPTER 2 CONTROL SYSTEM CYBERSECURITY OVERVIEW

2-1 RISK MANAGEMENT FRAMEWORK OVERVIEW.

The risk assessment process, or Risk Management Framework (RMF), inventories the system components, identifies the System Owner (SO) and Authorizing Official (AO), and implements risk reduction measures. The Authorizing Official then evaluates the risk and either accepts the risk and issues an Authority to Operate (ATO) or denies the ATO. At this point, the system is allowed to operate and (if necessary) connect to DoD network infrastructure. Risk reduction measures include removal of network and wireless capabilities, documenting the system, and altering the system to limit capabilities.

APPENDIX A contains a more extensive summary of the RMF as it relates to this UFC.

It is highly recommended that readers unfamiliar with the RMF review APPENDIX A before incorporating cybersecurity requirements into control system design.

2-1.1 Security Controls.

The RMF relies on the implementation of security controls, where a control is a specific action taken to secure a system. Note that this usage of the word ‘control’ is different from control engineering or control systems engineering, which is the engineering discipline that applies control theory to design systems with desired behaviors. To provide clarity of usage, this UFC will use the term “security control” to refer to cybersecurity controls.

2-1.2 RMF Goal.

For FRCS, the goal of the RMF is to reduce and mitigate vulnerabilities until the risk to the mission supported by the FRCS is deemed acceptable by 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. The final decision of whether a level of risk is acceptable is made by the assigned government AO.

2-1.3 RMF Roles of the Designer and Control System Installer.

2-1.3.1 RMF Role of the Designer

The designer has one primary role and one secondary role in the RMF process. Their primary role is to identify security controls which can be addressed by the design (during project planning and design) and implement those security controls in the design. As a secondary role, the designer provides input into the risk analysis process by advising on the impact, or lack thereof, of applying security controls to the control system and by advising on how the control system does or does not impact supported missions.

For an example of the need for designer input, consider the mechanical design of an HVAC system. These systems are designed to specific criteria - design day environmental conditions - and those criteria are a compromise between a system that is oversized for most of its operation, and a system that is sometimes under-sized. The criteria are well-established, and the tradeoffs are understood and accepted.

Cybersecurity involves similar trade-offs but, unlike for HVAC design, the criteria are not well-established, and the AO must determine the balance point between an over-secure system (which will likely be more expensive, and harder to install, commission, and maintain) and a system that still has some residual risk. Evaluating this risk requires a detailed understanding of the control system functioning which the AO may not possess, necessitating input from the designer.

2-1.3.2 RMF Role of Control System Installer

The construction installer is – as with any other aspect of a construction project – responsible for meeting the specifications and requirements of the contract. They are not directly responsible for Cybersecurity. Given a proper design, meeting the specifications will provide for a proper implementation of Cybersecurity.

2-1.4 Platform Information Technology.

DoD Instructions 8500.01 and 8510.01 define the Risk Management Framework (RMF) for the DoD and establish a category for “special purpose” systems that are not traditional information technology or information systems, called Platform Information Technology (PIT) systems. These PIT systems, including control systems, use specifically tailored security controls sets and require the AO to have expertise in the system.

As further discussed in CHAPTER 3, the designer provides input into the determination of the control system impact rating by advising on the relationship between the control system and the mission supported and provides input on the security control selection by advising on the feasibility and potential impacts of applying a security control.

2-1.5 Inherited Security Controls.

An inherited security control is a security control that a system meets by virtue of someone else addressing it in such a way that it applies to the system. A control system will generally inherit security controls one of three ways: by existing within a physical security boundary, by being covered by policies and procedures already in place, or by connection to another system which addresses the security controls.

Since inheritance often requires the SO to coordinate with others, it’s critical to document all security controls the control system expects to inherit. During control system design, the designer must identify and document any security controls which are expected to be inherited.

2-1.5.1 Physical Security Inheritance Example.

DoD installations implement physical security to manage risk to an acceptable level.

For a control system on a DoD Installation, a security control requiring that members of the public not be allowed unrestricted physical access to components of a control system will be met by virtue of the control system existing within that physical security boundary. Although military installations are on occasion opened to the public for events such as boot camp graduations, the access is not unrestricted, and the level of access has been accepted by installation security. Since control systems are innately tied to and co-located with the physical systems they control, in most cases a control system will be able to inherit physical security from the installation or separately secured facilities.

2-1.5.2 Policy and Procedures Inheritance Example.

The DoD has policies in place governing many aspects of cybersecurity. A control system can therefore inherit a security control such as “the organization defines the frequency to review and update the current security planning policy”.

2-1.5.3 Connection to another System Inheritance Example.

When a control system connects to another system, such as an Installation-wide network, inheritance may not be automatic but may require an agreement between the SOs of the systems. Such an agreement would cover acceptable behavior of the control system and explicitly define the security controls that will be inherited from the other system.

2-1.6 Applicability of RMF Security Controls to Design.

Security controls cover a wide range of requirements, many of which must be addressed by someone outside the control system design process. For example, a security control1 that states “The organization protects the control system from unauthorized modification by members of the organization” is normally not addressed by the designer; but rather is addressed through policies and procedures put in place by the organization that owns and operates the control system.

2-1.6.1 Applicability of RMF Security Controls to Design of Critical Systems.

The determination of whether a security control should be applied at design can become particularly complex for more critical (higher impact) systems. While it may be sufficient for a LOW impact system to assume a particular security control is addressed by another entity, the designer of a HIGH impact system may need to explicitly address

1 This is not an actual security control, but rather an illustrative example using a fictitious control.

a security control to ensure it is being implemented properly, to apply it at a higher standard, or to provide tools to the responsible parties to assist their implementation of the security control. For example, while a security control stating2 “The organization protects the control system from unauthorized modification by members of the organization” might be addressed through policies and procedures for a LOW impact system, a higher impact system may require the designer to explicitly design in additional barriers to unauthorized modification, or to provide guidance to the organization concerning the importance of properly securing the control system against modification. In this case, however, it’s vital to consider the impact these restrictions may have on the ability to make necessary authorized changes. For this reason, designers of systems with HIGH mission impact should likely seek the assistance of a dedicated cybersecurity engineer. MODERATE systems may also require specialized attention depending on the circumstances of the design.

2-1.6.2 Applicability to Control Systems as Compared to IT Systems

Another issue to be considered in the design of critical systems is the potential gap between the strict requirements of the (IT-centric) RMF and what is practical in control system design. Consider, for example, a fire alarm system and the level of support a fire alarm panel will have for Personal Identity Verification (PIV, such as the DoD CAC) compared to the RMF requirements at the MODERATE level. As a practical matter, it’s likely impossible to install a fire alarm system that meets the PIV requirements of a MODERATE impact system.

In this case, insisting on RMF requirements “as written” is particularly problematic as it would prevent the procurement and installation of the system until the manufacturer develops a custom system and then obtains UL certification. In other cases, the designer could insist on the RMF-required functionality, driving the installing contractor to create custom solutions using specialized equipment, but this is rarely the best approach as it greatly increases the overall risk that the system will not function properly. The unique solutions required to meet these requirements will likely require controllers that are not designed for the purpose in which they are used, and the system will likely be installed by contractors with experience in securing systems but not in the specific functionality of the control system. Because of its non-standard nature the system is likely to be significantly more expensive and more difficult to install, test, operate and maintain, all of which reduce the overall reliability of the system.

2-1.6.3 Other Applicability Input

In addition to providing input on the impact the control system will have on the supported mission, designers may be required to provide input on the ability (or inability) of the control system to meet cybersecurity requirements. This assists the AO in defining and accepting requirements that address cybersecurity risks without introducing functional risks.

2 This is not an actual security control, but rather an illustrative example using a fictitious control.

2-2 5-LEVEL CONTROL SYSTEM ARCHITECTURE.

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 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 cannot be applied at all) to the portion that does not look like a standard IT system.

APPENDIX C provides a more in-depth description of the 5-Level control system architecture.

2-2.1 Architecture Is a General Architecture

This architecture is designed to highlight Cybersecurity aspects of the control system; it is not intended to be an exact depiction of a control system. A single control system may have multiple authorizations and the boundaries of these authorizations may not be easily depicted by the architecture itself. Other control systems with a single authorization might lack a system-wide network and – from an IT perspective – appear to be several distinct systems; these might not be easily depicted by a single architecture drawing. For example, an installation-wide fire protection system generally does not have a system-wide network; each building has a separate network, and the buildings are connected to a central monitoring station by radios and relay panels3.

A single system may be described by the architecture in multiple ways – a multi-building control system with a dedicated IP network connecting the buildings may be described as a single FCS consisting only of levels 0-2 with the entire IP network residing at level 2, or it could be described as using levels 0-4 with multiple Level 2 networks connecting to a Level 4 IP network through multiple FPOCs. Depending on the system functionality as well as the cybersecurity approach, either or both may be valid, and which is the more appropriate depiction of the system depends on the details of the system itself and must be determined on a case-by-case basis. Both fit within and can be described by the 5-level architecture, and the intent of the architecture is to provide a common lexicon for defining systems and not to confine systems to a set definition.

3 The use of relay panels breaks the system into a base-wide radio network and a collection of buildings, each with an independent network in it.

Figure 2-1 5-Level Control System Architecture

2-2.2 “Standard IT” Parts of the Control System.

The parts of the control system that most resemble a standard or traditional IT system are referred to as the “Standard IT” parts:

• The IP Network portion of Level 4 (Level 4N).

• The IP Network portion of Level 2 (Levels 2N and 2B).

• The field point of connection (FPOC) at Level 3.

• The computer hardware for both servers and workstations (Levels 2D, 4A, 4B)

• The computer OS and other standard packages (such as antivirus) for both servers and workstations (desktops and laptops) (Levels 2D, 4A, 4B). Note that this does not include control system software such as front-end packages or engineering tools, but it might include things like web servers and database engines used by the front end. While front end packages and engineering tools likely run on standard desktop operating systems and have many characteristics in common with standard IT applications, they may have unique features and applying cybersecurity to them may require special expertise.

• External connections and control system management at Level 5.

The cybersecurity for the “standard IT” parts of the control system are largely addressed using standard cybersecurity practices and are generally outside the scope of control system design and are not addressed by this UFC. The designer should coordinate with IT experts for cybersecurity of those portions of the control system. The designer must address the IP Network at Level 2N, which is generally procured and installed by the control system contractor, and the control system specific software used by the front end, which is generally not adequately covered by standard IT approaches.

2-2.3 “Non-Standard IT” Parts of the Control System.

What makes cybersecurity for a control system challenging are the parts of the control system that do not generally resemble a standard IT system: Level 0, Level 1, Level 2A, Level 2C and the control system applications at Level 2D, Level 4A and Level 4B.

These parts of the control system are referred to as the “non-standard IT” parts in order to differentiate them from the “standard IT” parts. Traditional cybersecurity tools and requirements such as vulnerability management alerts, bulletins, Secure Technical Implementation Guides (STIGs), Security Requirements Guides (SRGs), and DoD IT Policies are seldom applicable to these non-standard IT components, particularly to devices at Levels 0, 1 or 2. For example, a security control4 requiring the screen to be locked when the user leaves the computer is not applicable to devices that do not have a screen or support user login. Different levels of the architecture have different issues related to the application of standard cybersecurity tools and requirements.

Cybersecurity for these portions of the control system must be addressed by the control system designer.

2-2.3.1 Computers at Level 2

If front end computers are on the same dedicated IP network as the control system (generally within the same building as the control system) they are considered to be at Level 2 rather than Level 4. This is a common scenario in legacy systems, and is sometimes found in new installations, particularly for systems that are not interfaced to a base-wide front end or where (typically to meet availability requirements) the front end servers (Level 4A) must be placed on that building’s Level 2 network. However, when installing new computers as part of a project, the cybersecurity requirements are largely the same regardless of whether the computers are at Level 2 or Level 4.

2-2.3.2 Level 0 Components vs Systems

A common question that arises is: “How complex can a ‘thing’ be and still be considered a Level 0 device?” For example, consider a packaged backup power unit, with diesel engine, generator, and Automatic Transfer Switch (ATS). This unit has dozens of

4 For reference – security control AC-11 deals with session lock requirements.

sensors and actuators, multiple controllers, and an internal network connecting them all together. Since it is a packaged unit and procured as a single component, if the unit does not have a network interface to the rest of the system it could be considered a single Level 0 device, even if procured independently of any other control system.

Alternatively, the unit could be considered its own mini field control system.

Ultimately the decision on how best to address such units must be made in coordination with the SO and AO, but a general guideline is to consider packaged units with hardware interfaces to be Level 0 devices, and to consider built-up units connected with hardware interfaces to be separate FCS. Note that any device, no matter how “dumb,” is not a Level 0 component if it is connected to a network (has a network interface as opposed to simple binary and analog connections), so even a simple networked temperature sensor is not a Level 0 device.

2-2.3.2.1 As a Level 0 Component

A Level 0 device with an internal network - particularly if procured independently of any other control system -, might need to go through the RMF process – as a FRCS consisting of a single Level 0 device with a greatly reduced set of cybersecurity requirements. Or the AO could greatly simplify the process and accept the risk up front for a Level 0 device (albeit an expensive and complex Level 0 device).

2-2.3.2.2 As a Mini Field Control System

The unit could be considered its own mini field control system, which requires the internal components of the packaged unit be defined as well as the hardware (non-networked) interface between the backup power unit and the building system. This adds a lot of effort and documentation for very little benefit, and is almost never the right choice. Note that this may also cause a separate ATO for the unit to be required, significantly increasing the burden even further.

2-2.3.3 Describing Systems Using the 5-Level Architecture.

As stated previously, the 5-level architecture provides a common lexicon for defining systems and is not intended to confine systems to a set definition. The basic architecture drawings presented in this UFC generally describe a single system with a single authorization, or with two authorizations where one of them is a Platform Enclave.

Other control systems may require architecture drawings which depict systems using the 5-level architecture in various other ways. In some cases, the architecture may need to indicate additional authorization boundaries, and in others the architecture levels may be connected in ways not shown on the basic drawings in this UFC. For example:

• A base-wide fire reporting system where a system in a building is connected via radio to a base-wide central monitoring system at the main fire station. In this case, the building level system exists at Levels 0 – 2 and there is a Level 0 interface (relay panel) between it and a sitewide radio network. The radio network is (typically) a Level 1 (dedicated non-IP network) interface to a central front end and other Level 0 – 2 building level fire systems.

• A fire protection system where some subsystem (such as the releasing panel controlling a pre-action fire sprinkler system in a datacenter) has a higher cyber impact rating (say MODERATE) than the rest of the system (presumed to be LOW). In this case, the system may be authorized in two different ways:

• A single authorization covering the entire building fire protection system. Because the releasing panel has a MODERATE impact, the entire system would need to meet MODERATE requirements.

• Two separate authorizations: a) A small MODERATE authorization for the releasing panel, and b) A large LOW authorization for the remainder of the building. In this case, the two systems would need to have a cyber-secure separation between them; the easiest (but not only) way to achieve this this would be via an interposing relay panel.

• A MODERATE building control system needing integration into a base-wide LOW system. Again, there is a choice between either treating the base-wide system as a MODERATE system (a potentially very expensive solution) or having two authorizations – a MODERATE for the building and a LOW for the base-wide system. The tradeoff in this case is that the integration will need a high level of isolation and will likely be more expensive and provide much less functionality than the normal integration of a building into the base-wide system. This specific case is covered in more detail in APPENDIX E.

The key point here is that all FRCS can be described in terms of components at one or more of the 5 levels of this architecture.

2-2.4 Wireless Networks

Although not explicitly shown in the architecture, wireless networks may exist at Level 1, Level 2 or Level 4 of the architecture. Wireless networks require additional cybersecurity measures, and unless furnished by the project site must be carefully coordinated to ensure the use of wireless is approved and meets all the additional requirements.

2-2.5 Platform Enclave.

Many control systems are hosted within a network that is segmented from the general day-to-day business application (such as email, file servers) network either physically or virtually. This separate IT infrastructure environment dedicated to the delivery of common level services (for example, Active Directory Services, Assured Compliance Assessment Solution (ACAS) Services, Host Base Security System (HBSS) Services) to the FRCS is referred to as the Platform Enclave. In some cases, this Platform

Enclave will have a separate authorization from the control systems within the enclave.

The control systems will have their own authorization for their Operational Architecture which primarily covers the “non-standard IT” components of the system. In other cases, it is possible that a single authorization will be used for the entire system, both the enclave and the control 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 B.

2-3 CONTROL SYSTEM PROCUREMENT OVERVIEW.

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 - 2 as shown in Figure 2-2) are procured along with a front end for those systems. Over time additional FCS are procured; these new FCS are integrated with the existing front end and added to the authorization (ATO) for the existing system to expand the installation-wide system. When designing an FCS that will be added to an existing system, there may be cybersecurity requirements that are specific to the authorization of the existing system which must be incorporated into the FCS design.

Also note that the Level 3 FPOC and Level 4 IT infrastructure are usually provided by the site-wide IT support organization; they are not procured for (and are often not dedicated to) the control system. This UFC cannot address site-specific requirements;

when designing systems which will be added to an existing system authorization coordinate with the project site to obtain relevant requirements from the existing system.

Some control systems are procured to operate independently, with no integration to a larger system and without further significant expansion. Depending on the circumstances and architecture, treat these systems either as complete systems, containing all 4 or 5 Levels, or as a FCS (Level 0-2) with its own user interface at Levels 1 or 2. See Table C-3 in APPENDIX C for more information on the Level 2D computers.

Figure 2-2 Control System Architecture

CHAPTER 3 APPLYING CYBERSECURITY IN DESIGN

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:

Step 1: Identify the Confidentiality, Integrity, and Availability (C-I-A) impact levels (LOW, MODERATE, or HIGH) to use for the control system design.

Step 2A: Use the impact levels to select the proper list of controls from NIST SP 800-82.

Step 2B: Using the DoD master Control Correlation Identifier (CCI) list, create a list of relevant CCIs based on the controls selected in Step 2A.

Step 2C: Categorize CCIs and identify CCIs that require input from the designer or are the designer’s responsibility.

Step 3: Include cybersecurity requirements in the project specifications and provide input to others as required.

These steps are numbered in this way to align with the corresponding steps of the 7-step5 RMF Process. For example, Steps 2A, 2B, and 2C all occur at Step 2 of the RMF process, “Select Security Controls”. APPENDIX G contains tables covering Steps 2A, 2B and 2C for LOW and MODERATE systems, assuming the existence of a Platform Enclave. These tables, with additional information in a filterable format, are also available in Excel format on the RMF Knowledge Service (https://rmfks.osd.mil) and the use of that spreadsheet is highly recommended. This website is CAC-enabled;

designers without a CAC must request assistance from the Service if tables and information were not provided. Figure 3-1 below provides an overview of steps 2A through 3, and APPENDIX F provides additional guidance on the implementation of specific controls.

5 Formerly a six step process, the RMF has introduced a seventh step as “Step 0: Prepare” https://rmfks.osd.mil/

Figure 3-1 Overview of Steps 2A through 3

3-1.1.1 Beginning Mid-Process

These five steps fully define the Cybersecurity portion of the design process when starting with a “blank page”. Strictly speaking, Step 1 should be completed by the AO or SO, and in some cases, the asset owner or Service may also have defined the list of cybersecurity controls (they have completed Step 2A), or the list of CCIs (they have completed step 2B), or even the specific CCIs to be addressed by the designer (they have completed step 2C). In these cases, (as shown in Figure 3-1 above) begin the design process at the appropriate step using the information provided.

3-1.2 Definition of “Organization”.

Security controls often refer to the “organization” in identifying responsibilities and risk, making proper determination of “organization” critical to proper evaluation of impact.

For example, loss of heating, ventilating, and air-conditioning (HVAC) at the Houston franchise of a national hotel chain in August might be catastrophic to the local facility manager, but it is hardly a significant blow to the United States, or even to the hotel chain. Unless otherwise indicated, for the purposes of implementation of the RMF to control systems:

• For determining the impact level of a system, treat the “organization” as the relevant Service (Army, Navy, Air Force).

• For determining implementation requirements for specific controls, treat the “organization” as the Installation (garrison, post or base) or Region (for regional systems). Note that this doesn’t conflict with the above statement regarding the organization for determining impact, but rather indicates the portion of the Service that will have responsibility for implementation of the control.

3-1.3 Designer Coordination

• Meeting cybersecurity requirements may require substantial coordination between different design disciplines. Many systems will be unable to meet identification and authentication requirements for user interfaces and physical security is recommended as a compensating control. These requirements (such as “install controllers in locked enclosures”) will need to be coordinated with the physical security designer. Similarly, the use of insecure network protocols may require physical security to prevent unauthorized access to the network.

• In almost all cases, the control system is only as important as the controlled equipment. For example, an air handler controller is of no relevance if the air handler has failed for some simple mechanical reason. Some cyber requirements may suggest additional requirements on underlying equipment and coordination with those designers may be required.

• In many cases, good cybersecurity design is best accomplished via good control system design.