UFC 4_010_06_.pdf

UFC 4-010-06

19 September 2016

Change 1, 18 January 2017

UNIFIED FACILITIES CRITERIA (UFC)

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED

CYBERSECURITY OF

FACILITY-RELATED

CONTROL SYSTEMS

CYBERSECURITY OF FACILITY-RELATED CONTROL SYSTEMS

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.

U.S. ARMY CORPS OF ENGINEERS

NAVAL FACILITIES ENGINEERING COMMAND (Preparing Activity)

AIR FORCE CIVIL ENGINEER CENTER

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

Change No. Date Location 1 01/19/2017 Revised paragraphs 3-3, 3-6 (second bullet), 3-6.2, 4-3

(second to last bullet), and 5-2.2.2.

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 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 Services’ responsibility for providing technical criteria for military construction. Headquarters, U.S. Army Corps of Engineers (HQUSACE), Naval Facilities Engineering Command (NAVFAC), and Air Force Civil Engineer Center (AFCEC) are responsible for administration of the UFC system. Defense agencies should contact the preparing service for document interpretation and improvements. Technical content of UFC is the responsibility of the cognizant DoD working group. Recommended changes with supporting rationale should be sent to the respective service proponent office by the following electronic form: Criteria Change Request. The form is also accessible from the Internet sites listed below.

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

• Whole Building Design Guide web site http://dod.wbdg.org/.

Hard copies of UFC printed from electronic media should be checked against the current electronic version prior to use to ensure that they are current.

AUTHORIZED BY:

JAMES C. DALTON, P.E.

JOSEPH E. GOTT, P.E.

Chief, Engineering and Construction Chief Engineer U.S. Army Corps of Engineers Naval Facilities Engineering Command

EDWIN H. OSHIBA, SES, DAF

MICHAEL McANDREW

Deputy Director of Civil Engineers DASD (Facilities Investment and Management) DCS/Logistics, Engineering & Force Protection

Office of the Assistant Secretary of Defense (Energy, Installations, and Environment) http://www.wbdg.org/pdfs/ufc_implementation.pdf http://www.wbdg.org/ccb/browse_cat.php?o=29&c=4 http://dod.wbdg.org/

NEW DOCUMENT SUMMARY SHEET

Document: UFC 4-010-06, Cybersecurity of Facility-Related Control Systems

Superseding: None

Description: UFC 4-010-06 provides requirements for incorporating cybersecurity into the design of facility-related control systems.

Justification: DoDI 8500.01, Cybersecurity requires the implementation of a “multi- Leveled cybersecurity risk management process… as described in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-39 and the Committee on National Security Systems (CNSS) Policy 22.” It further requires the use of NIST SP 800-37, and a transition to CNSSI No. 1253 and NIST SP 800-53. For control systems, NIST SP 800-82 R2 Appendix G is used as the overlay under CNSSI No. 1253.

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.

Impact: 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.

Change 1, 18 January 2017 i

TABLE OF CONTENTS

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND

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 REFERENCES

1-8 GLOSSARY

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 Platform Information Technology

2-1.4 Inherited Security Controls

2-1.5 Applicability of RMF Security Controls to Design

2-2 5-LEVEL CONTROL SYSTEM ARCHITECTURE

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

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

2-2.3 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-2 STEP 1: DETERMINE CONTROL SYSTEM IMPACT RATING

3-3 STEP 2: DETERMINATION OF SECURITY CONTROLS

3-3.1 Recommend Security Controls to Tailor Out

3-4 STEP 3: IDENTIFICATION OF CONTROL CORRELATION

IDENTIFIERS

3-5 STEP 4: CATEGORIZATION OF CONTROL CORRELATION

IDENTIFIERS BY RESPONSIBILITY

3-6 STEP 5: INCORPORATE CYBERSECURITY REQUIREMENTS

Change 1, 18 January 2017 ii

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

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-3 DO NOT IMPLEMENT STANDARD IT FUNCTIONS

4-4 DO NOT PROVIDE REMOTE ACCESS

CHAPTER 5 CYBERSECURITY DOCUMENTATION

5-1 OVERVIEW

5-2 REQUIREMENTS BY DESIGN PHASE

5-2.1 Basis of Design

5-2.2 Design Submittals

APPENDIX A REFERENCES

APPENDIX B GLOSSARY

B-1 ACRONYMS

B-1.1 General Acronyms

B-1.2 Security Control Family Acronyms

B-2 DEFINITION OF TERMS

APPENDIX C RISK MANAGEMENT FRAMEWORK (RMF) OVERVIEW

C-1 RMF OVERVIEW

C-2 RMF PROCESS

C-3 DEFINITION OF CONTROLS FROM NIST AND DODI 8510

C-3.1 Control Families

C-3.2 Control Elements and Enhancements

C-3.3 Control Correlation Identifiers

C-4 REQUIREMENT DEFINITION VS IMPLEMENTATION

C-4.1 CCIs Defining a Requirement

Change 1, 18 January 2017 iii

C-4.2 CCIs Requiring Implementing a Requirement

C-5 PLATFORM INFORMATION TECHNOLOGY

APPENDIX D PLATFORM ENCLAVE

D-1 PLATFORM ENCLAVE CONCEPT OVERVIEW

D-2 PLATFORM ENCLAVE USING TWO AUTHORIZATIONS

D-3 PLATFORM ENCLAVE BENEFITS

D-4 ARMY PLATFORM ENCLAVE APPROACH

D-5 NAVY PLATFORM ENCLAVE APPROACH FOR BCS AND UCS

D-6 AIR FORCE PLATFORM ENCLAVE APPROACH

APPENDIX E 5-LEVEL CONTROL SYSTEM ARCHITECTURE

E-1 INTRODUCTION

E-2 5-LEVEL ARCHITECTURE OVERVIEW

E-3 LEVEL 0: SENSORS AND ACTUATORS

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

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

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

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

IP NETWORK

E-8 LEVEL 5: EXTERNAL CONNECTION AND CONTROL SYSTEM

MANAGEMENT

APPENDIX F CYBERSECURITY CONSIDERATIONS FOR INTEGRATING CRITICAL

UTILITY OR BUILDING CONTROL SYSTEMS WITH NON-CRITICAL UMCS

F-1 INTRODUCTION

F-2 LIMIT OUTSIDE FUNCTIONALITY

F-3 FCS-UMCS CONNECTION METHODS

F-3.1 Hardware I/O Interface

F-3.2 Hardware Gateway Interface

F-3.3 Firewall Interface

F-4 OTHER CONSIDERATIONS

F-4.1 Local User Interfaces

F-4.2 Management of Risk

APPENDIX G IMPLEMENTATION GUIDANCE FOR SECURITY CONTROLS

G-1 INTRODUCTION

G-2 GENERAL GUIDANCE

Change 1, 18 January 2017 iv

G-2.1 Control System versus Standard IT System Terminology

G-2.2 DoD-Defined Values

G-2.3 Security Controls Which are “Automatically Met”

G-2.4 Security Controls Applicability by Architecture Level

G-2.5 Impact Level Applicability

G-3 GUIDANCE FOR INDIVIDUAL SECURITY CONTROLS

G-3.1 Access Control (AC) Control Family

G-3.2 Audit and Accountability (AU) Control Family

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

G-3.4 Configuration Management (CM) Control Family

G-3.5 Contingency Planning (CP) Control Family

G-3.6 Identification and Authorization (IA) Control Family

G-3.7 Incident Response (IR) Control Family

G-3.8 Maintenance (MA) Control Family

G-3.9 Media Protection (MP) Control Family

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

G-3.11 Planning (PL) Control Family

G-3.12 Program Management (PM) Control Family

G-3.13 Personnel Security (PS) Control Family

G-3.14 Risk Assessment (RA) Control Family

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

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

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

APPENDIX H CONTROL CORRELATION IDENTIFIER (CCI) TABLES

H-1 INTRODUCTION

H-2 TABLE STRUCTURE AND CONTENT

H-3 CCI TABLE NOTES

H-3.1 Controls Inherited from Platform Enclave

H-3.2 CCIs in Multiple Tables

H-4 CCI TABLE DESCRIPTIONS

H-4.1 CCI Summary Table

H-4.2 CCI Not Applicable to Control Systems

H-4.3 CCIs Removed from LOW Impact Control System Baseline

Change 1, 18 January 2017 v

H-4.4 Designer CCIs

H-4.5 Platform Enclave CCIs

H-5 CCI TABLES

FIGURES

Figure 2-1 5-Level Control System Architecture Figure 2-2 Control System Architecture Figure C-3 NIST Risk Management Framework Steps Figure C-4 NIST SP 800-53 Control AC-2 Figure D-1 Navy and Air Force Platform Enclave and Operational Architecture Figure E-1 5-Level Control System Architecture Figure F-1 Hardware I/O Interface Example

TABLES

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

Change 1, 18 January 2017 vi

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

Change 1, 18 January 2017

CHAPTER 1 INTRODUCTION

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).

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 C.

1-2 PURPOSE AND SCOPE.

This UFC describes requirements for incorporating cybersecurity in the design of all facility-related control systems. It defines a process 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.

1-3 APPLICABILITY.

This UFC applies to all planning, design and construction, renovation, and repair of new and existing facilities and installations that result in DoD real property assets, regardless of funding source. MODERATE and HIGH impact systems generally require more expertise and attention to detail than a UFC can provide. Design of MODERATE or HIGH impact systems will typically require additional customized requirements to achieve appropriate levels of cybersecurity and 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. Systems not being implemented on a DoD Installation will require modifications to the requirements 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.

Change 1, 18 January 2017

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 C provides an overview of the Risk Management Framework as it pertains to control systems. 0 provides additional detail on the Platform Enclave concept.

APPENDIX E describes the 5-Level architecture for control systems. APPENDIX F discusses considerations in the integration of critical building systems into a non-critical UMCS. 0 provides guidance for security control families, and individual security controls. APPENDIX H 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 is available from the following Service organizations:

• Army: ICS Cybersecurity Center of Expertise, Huntsville Engineering and Support Center

• Navy: Naval Facilities Engineering Command, Command Information Office (CIO)

• Air Force: Civil Engineer Maintenance, Inspection, and Repair Team (CEMIRT) ICS Branch, Tyndall AFB

• Marine Corps: Contact Navy POC for Marine Corps POC information.

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 REFERENCES.

APPENDIX A 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. In general, when the publication date or revision is not included, the latest available issuance of the reference is used.

1-8 GLOSSARY.

APPENDIX B contains acronyms, abbreviations, and terms.

Change 1, 18 January 2017

CHAPTER 2 CONTROL SYSTEM CYBERSECURITY OVERVIEW

2-1 RISK MANAGEMENT FRAMEWORK OVERVIEW.

A summary of key aspects of the Risk Management Framework (RMF) as it applies to control system design is provided here. APPENDIX C 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 C 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.

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.

The decision of whether a level of risk is acceptable is made by the assigned government AO. 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.

2-1.3 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.

The selection of the set of security controls to implement for a given system is the responsibility of the AO. The designer provides input into security control selection by advising on the feasibility and potential impacts of applying a security control.

Change 1, 18 January 2017

2-1.4 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.4.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.4.2 Policy and Procedures Inheritance Example.

The DoD has polices 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.4.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.5 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

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

Change 1, 18 January 2017 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.5.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 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 stating “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 particular circumstances of the design.

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

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

Change 1, 18 January 2017

Figure 2-1 5-Level Control System Architecture

2-2.1 “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 (e.g., antivirus) for both servers and workstations (desktops and laptops) (Levels 2D, 4A, 4B).

• 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 must address the IP

Change 1, 18 January 2017

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.2 “Non-Standard IT” Parts of the Control System.

What makes cybersecurity for a control system challenging is 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) and DoD IT Policies are seldom applicable to these components, particularly to devices at Levels 0, 1 or 2. For example, a security control2 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 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 0.

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, 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. When designing a FCS that will be added to an existing system, there may be cybersecurity requirements specific to the authorization of the existing system which must be incorporated into the FCS design. This UFC cannot

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

Change 1, 18 January 2017 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 E-3 in APPENDIX E for more information on the Level 2D computers.

Figure 2-2 Control System Architecture

Change 1, 18 January 2017

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: 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.

APPENDIX H contains tables covering steps 2 – 4 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). This website is CAC-enabled; designers without a CAC must request assistance from the Service if tables and information were not provided. 0 provides additional guidance on the implementation of specific controls.

3-1.2 Definition of “Organization”.

Security controls often refer to the “organization” in identifying responsibilities and risk.

Unless otherwise indicated, for the purposes of implementation of the RMF to control systems:

Change 1, 18 January 2017

• For determining the impact level of a system, treat the “organization” as the relevant Service (e.g., 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-2 STEP 1: DETERMINE CONTROL SYSTEM IMPACT RATING.

The SO, with concurrence from the AO, determines the impact levels of the control system. The SO may seek assistance from the control system designer in defining the functionality of the control system, the information the control system contains, and the impact of failure of the control system. For the DoD, impact levels are determined based on the mission of the relevant Service and in many cases can use the mission criticality rating of the facility (mission support, mission essential, mission critical) as a starting point to determining control system impact. It’s also important to note that while a traditional information system generally prioritizes Confidentiality, then Integrity and lastly Availability, control systems usually prioritize Availability first, then Integrity and lastly Confidentiality.

If impact ratings aren’t provided, request them from the Service. If the Service is unable to provide impact ratings then request direction from the Service and follow one of two courses of action as directed:

1. Use the “starting” impact ratings for the control system type and facility rating (mission support, mission essential, mission critical) from the Control System Master List available at the RMF Knowledge Service website (https://rmfks.osd.mil).

2. Do not proceed with the design until C-I-A Impact ratings are provided.

3-3 STEP 2: DETERMINATION OF SECURITY CONTROLS.

When the list of relevant controls is not provided by the Service, determine a starting list of controls based on the Confidentiality (C), Integrity (I) and Availability (A) impact ratings (or C-I-A ratings) provided by the \1\Service/1/. The DoD uses NIST SP 800-82 as an overlay to determine the starting baseline security controls for control systems.

The RMF Knowledge Service (https://rmfks.osd.mil) contains guidance on determining controls from C-I-A ratings, including an Excel Spreadsheet that generates a control list based on the impact ratings and the NIST SP 800-82 guidance. This website is CAC-enabled; designers without a CAC must request assistance from the Service if tables and information were not provided.

Change 1, 18 January 2017

3-3.1 Recommend Security Controls to Tailor Out.

The standard security control baselines were developed for standard information systems and contain security controls that are entirely inapplicable to control systems (or other Platform Information Technology), or are prohibitive to implement due to technical or resource constraints. The RMF process allows these baselines to be tailored for the project by the removal or addition of specific controls. Review the list of controls and provide recommendations for controls to be tailored out from (or added to) the security control set as part of the cybersecurity documentation required by

CHAPTER 5.

Note this tailoring can either be applied at the security control level during Step 2 or at the CCI level during Step 3 of the design process. For a LOW Impact system, Table H- 2 and Table H-3 list recommended CCIs to be tailored out.

3-4 STEP 3: IDENTIFICATION OF CONTROL CORRELATION

IDENTIFIERS.

Using the list of security controls from Step 2, create the list of corresponding control correlation identifiers (CCIs). This list of CCIs provides the starting point for identifying cybersecurity requirements to be included in control system design. The complete CCI list is available at the RMF Knowledge Service website via the “Export All Assessment Procedures to Spreadsheet" link at:

https://rmfks.osd.mil/rmf/General/SecurityControls/Pages/ControlsExplorer.aspx. From the URL, select "All Control Families" from the "Choose Control Family" pull-down.

After the page re-populates with the controls, click on "Export Implementation Guidance and Assessment Procedures" to download the CCIs into Excel.

Note: This website is CAC-enabled; designers without a CAC must request the CCI list from the Service if it was not provided.

3-5 STEP 4: CATEGORIZATION OF CONTROL CORRELATION

IDENTIFIERS BY RESPONSIBILITY.

Categorize each CCI identified in Step 3 as one or more of the following categories:

• DoD-Defined: Either the DoD has provided a value for the “organization selected” values, or the DoD implementation guidance states that the CCI is already met by existing policy or regulation. These values are defined in the CCI list obtained from the RMF Knowledge Service. Note that definition or guidance provided may not be relevant for a control system – the organization definitions were determined from the perspective of a traditional information system, not for a control system.

• Designer: The designer has a role to address for this CCI. Either the designer needs to provide design specifications to cover a requirement for the control system itself, or the designer must provide input to others regarding the implementation or lack of feasibility of the CCI (typically https://rmfks.osd.mil/rmf/General/SecurityControls/Pages/ControlsExplorer.aspx

Change 1, 18 January 2017 because the CCI was written with an IT system, not a control system in mind).

• Non-Designer: The CCI is beyond the responsibility of the designer, and is the responsibility of someone else – typically the SO. This does not diminish the importance of these CCIs, but as these CCIs are not the responsibility of the designer they are beyond the scope of this UFC.

• Platform Enclave: The CCI contains a requirement which is expected to be implemented at the Platform Enclave and inherited by the control system, or is mostly implemented at the Platform Enclave but also needed within the field control system (in which case the CCI is also in the “Designer” category). For example, passwords are implemented at the Platform Enclave, but are also necessary at the control system user interface itself, local display panels and some controllers (those which support passwords). While implementation of the Platform Enclave is not the designer’s responsibility (a key point of the Platform Enclave is that it is a standard approach that can be implemented across multiple control systems), it’s important to document CCIs the control system expects to inherit from the Platform Enclave.

The Platform Enclave category is in many ways a special case of the Non- Designer category, as it indicates a CCI that is addressed by others.

• Impractical: The CCI is impractical to fully implement in a control system, but may be applied in a limited manner to at least some part of the control system. In most cases, these are CCIs that can be implemented at Level 4 of the architecture, but would be prohibitively difficult to implement at Levels 0, 1, or 2.

Many CCIs will be assigned multiple categories. For example a security control related to passwords would be categorized in both Platform Enclave and Designer categories as it must be addressed at the Level 4 computers as well as at Level 1 and Level 2. If the DoD has selected a minimum password length for use with this control which cannot be met by all devices, it would also be categorized as Impractical and the designer must document how the security control was implemented for devices unable to meet the DoD selected value.

3-6 STEP 5: INCORPORATE CYBERSECURITY REQUIREMENTS.

In addition to requirements specific to 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.

For each CCI identified as “designer”, address the CCI in one or more of the following three ways:

• Incorporate a design requirement in the specifications for the control system.

Change 1, 18 January 2017

• Select or identify required changes to standard CCI requirements which affect CCI implementation, such as the value of a specific parameter.

Note that approval or rejection of these values by the\1\Service (the AO or their designated representative)/1/ will impact control system design.

• Provide information about the design to others so they can implement a CCI. In particular, document CCIs that the system is expected to be inherited from another system or the Platform Enclave.

3-6.1 Addressing DoD Selected Values in CCIs.

Many CCIs have DoD standard values and are indicated in the Master CCI List as being automatically met or inherited based on the standard value. These CCIs have been derived from the general security controls in NIST SP 800-53, without regard to special consideration which might apply to a control system, such as the tailoring and supplemental guidance in NIST SP 800-82. Many of these CCIs cannot be applied to control systems using the approach identified by the DoD. In these cases, implement the CCI to the greatest extent practical, and document the incompatibilities.

3-6.2 Other “Organization Defined Values” in CCIs.

For CCIs which refer to “organization defined values” where the DoD has not defined value and one has not been provided, request appropriate values from the \1\Service. If the Service/1/ is unable to provide values, propose reasonable values and document the proposed value with rationale.

3-6.3 Requirement Definition and Implementation CCIs.

Often, one CCI defines a requirement, and a second requires the implementation of that requirement. A hypothetical example3 is:

• CCI #1 says “organization defines which components collect audit records”. The implementation guidance for this CCI says “this is automatically met because the DoD has defined the components as ‘all components’”.

• CCI #2 says “the information system collects audit records at the defined components”.

Together, these create an impossible requirement: if one accepts the definition in #1 (and that it’s “automatically met”), then the system fails to meet #2 because, for example, Level 0 sensors can’t collect audit records. In this case, both CCIs are “Designer” category; propose reasonable values for CCI #1, implement CCI #2 using this value and document the proposed values for CCI #1.

3 This example uses simplified fictitious CCIs for illustrative purposes. The AU family of security controls deals with audit logs.

Change 1, 18 January 2017

This Page Intentionally Left Blank

Change 1, 18 January 2017

CHAPTER 4 MINIMUM CYBERSECURITY DESIGN REQUIREMENTS

4-1 DESIGN TO MINIMIZE FAILURE.

4-1.1 Reduce Dependency on the Network.

Avoid dependence on the network for the execution of control strategies. For example, a backup generator should always start based on a local measurement of utility availability, and not require a network "START" command. When dependence on the network is unavoidable, isolate that portion of the network as much as possible so that non-local network outages do not affect the required portions of the network. When a user interface is absolutely required for the functioning of a control strategy, consider a local interface (local display panel) or a dedicated front end (Level 2 front end) physically co-located with the equipment.

In some cases, it may be necessary to take additional steps to protect critical functions from modification over the network, for example a controller where critical parameters are exposed to network manipulation based on the controller design. In these cases, design barriers to manipulation into the control network architecture itself. See APPENDIX F for one possible approach.

4-1.2 Reduce Extraneous Functionality

Since additional capabilities often result in additional vulnerabilities, a key cybersecurity concept is “least functionality”, which means not adding capabilities which are not specifically needed. Design control system systems to minimize additional functionality which may create vulnerabilities in the control system, including but not limited to:

• Consider mission requirements before implementing remote adjustment of system parameters which are not expected or required to change. For example, a critical air conditioner serving a data center, a critical command and control building, or a UPS room which needs to maintain space temperature at 65 degrees Fahrenheit, 24 hours a day, 365 days a year should not have a network configurable operating schedule or set-point.

• Advanced or complex control strategies often require increased sensor inputs and a greater level of maintenance. Use care when requiring these strategies as the increased complexity results in increased probability of failure if the system is not properly maintained or if any specific parameter is compromised.

4-2 DESIGN TO MANAGE FAILURE.

4-2.1 Design for Graceful Failure.

4-2.1.1 Control Systems without Subsystems.

For control systems controlling a single process or piece of equipment, coordinate with the equipment designer to determine any additional redundancy and failure

Change 1, 18 January 2017 requirements, and design the control system to match the requirements for the underlying equipment. In all cases design these systems to fail “safe” as defined by the criteria for the controlled system. For example, in cold climates, outside air intake dampers must fail closed based on the requirements of the heating, ventilation, and air conditioning UFC.

4-2.1.2 Control Systems with Independent Subsystems.

Many control systems are described as a single system but are actually composed of many (hundreds, even thousands) of essentially independent systems. A common example of this would be an installation-wide UMCS, where the air handler (AHU) controllers in one building have no dependence on the AHU in another building, and often no dependence on AHUs in the same building.

For control systems with independent subsystems, design each subsystem as required in paragraph 4-2.1.1, Control Systems without Subsystems, and also design the overall system such that loss of a single subsystem does not affect the operation of the rest of the system. Reduce information shared between subsystems and minimize dependence on the network. For subsystems which must rely on other subsystems define default (“fall back”) behavior in the event that the other subsystem fails.

4-2.2 Degraded Operation.

After a system fails to a safe state, it may need to resume operation in a degraded capacity using some automated or manual method, recognizing there may be risk in this operation but that risk is manageable and outweighed by mission requirements.

Based on mission requirements, consider requiring means for manual operation including both monitoring instrumentation (e.g., thermometers, pressure gauges, meters), and manual control devices (such as “hand-off-auto” switches and actuators with manual actuation capability).

4-2.3 Redundancy.

If the criticality of the mission requires redundancy in the design of the control system, then the system must be designed to function without external intervention, and especially without human intervention. Design control strategies such that spare units start automatically when running units shut down, or have all units run and share load.

Care must be taken when load-sharing to ensure that operators are notified when one unit of a redundant set fails since the remaining units will automatically pick up the load with no disruption in the load. Do not rely on an operator to start any backup unit; the odds of the operator not being available, or taking an incorrect action are too great.

Provide alarms to alert operators of failures.

4-3 DO NOT IMPLEMENT STANDARD IT FUNCTIONS.

As a type of Platform IT, control systems are special purpose systems and must not be used as general computing resources. In particular:

Change 1, 18 January 2017

• Do not share control system resources with other systems, particularly with non-PIT systems. Some exceptions such as separate virtual servers running on common hardware or shared Ethernet media with separate VLANs, may be permitted, but the overlap between control systems and other systems must be minimized.

• Do not allow control systems to provide, or share resources with, other applications that provide standard IT services. In particular, do not use control system components as Domain Name System (DNS) servers.

(DNS servers may be implemented within the “Platform Enclave” at Level 5, but that is beyond the scope of the control system designer’s responsibility and not addressed by this UFC.)

• Do not allow control systems to be publically accessible (i.e., they must require authentication prior to access).

• Prohibit the use of mobile code, except mobile code may be allowed at Level 4. Note that control systems may use mobile code technologies, Java in particular, within the control system, but must not download code without direct user approval.

• Do not use control system computers as standard computers for general applications.

• Do not implement Voice over Internet Protocol (VoIP) within the control system.

• Do not implement collaborative computing devices, technologies or protocols within the control system.

• Unless specifically authorized by the \1\Service/1/ and required by the project site, do not allow control system components to access non-mil IP address space. Do not allow control system components to access social media. (Note that access to non-mil IP address space is generally not needed, and when needed will generally be a function of the front end, not the field control system.)

• Do not allow control systems to receive email (note that at Level 4 they may need a method of sending email for notifications).

4-4 DO NOT PROVIDE REMOTE ACCESS.

Do not provide remote access to the control system. If required, remote access to the Level 4 network should be provided by the Platform Enclave or the site IT organization.

Coordinate remote access requirements with the project site IT organization and with the POCs listed in CHAPTER 1.

Change 1, 18 January 2017

Change 1, 18 January 2017

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.

5-1 OVERVIEW.

Cybersecurity documentation for control system design documents the security controls and…