Appendix F UFGS 25 05 11.pdf

USACE / NAVFAC / AFCEC UFGS-25 05 11 (August 2024)

Preparing Activity: USACE Superseding UFGS-25 05 11 (May 2021)

UNIFIED FACILITIES GUIDE SPECIFICATIONS

References are in agreement with UMRL dated January 2025

SECTION TABLE OF CONTENTS

DIVISION 25 - INTEGRATED AUTOMATION

SECTION 25 05 11

CYBERSECURITY FOR FACILITY-RELATED CONTROL SYSTEMS

08/24

PART 1 GENERAL

1.1 CONTROL SYSTEM APPLICABILITY

1.2 RELATED REQUIREMENTS

1.3 REFERENCES

1.4 DEFINITIONS

1.4.1 Administrator Account

1.4.2 Computer

1.4.3 Controller

1.4.4 Mission Space

1.4.5 Network

1.4.6 Network Connected

1.4.6.1 Wireless Network Connected

1.4.7 Network Media

1.4.8 Network Segmentation

1.4.9 Operational Technology (OT)

1.4.10 User Account Support Levels

1.4.10.1 FULLY Supported

1.4.10.2 MINIMALLY Supported

1.4.10.3 NOT Supported

1.4.11 Manual Local Input

1.4.12 Card Reader

1.4.13 User Interface

1.4.13.1 Local User Interface

1.4.13.2 Remote User Interface

1.4.13.3 Types of User Interface (by capability)

1.4.13.3.1 Read-Only User Interface

1.4.13.3.2 Limited User Interface

1.4.13.3.3 Full User Interface

1.4.13.3.4 View-Only User Interface

1.4.13.4 Other User Interface Terminology

1.4.13.4.1 Writable User Interface

SECTION 25 05 11 Page 1

1.4.13.4.2 Privileged User Interface

1.4.14 Wireless Network

1.4.15 Wired Broadcast Network

1.5 ADMINISTRATIVE REQUIREMENTS

1.5.1 Points of Contact

1.5.2 Coordination

1.6 SUBMITTALS

1.7 ENCRYPTED SUBMITTAL REQUIREMENTS

1.8 QUALITY CONTROL

1.8.1 Regulatory Requirements

1.8.2 [Certifications][Qualifications]

1.8.3 Certifications

1.8.4 Pre-Construction Testing

1.9 DELIVERY, STORAGE, AND HANDLING

1.10 CYBERSECURITY DOCUMENTATION

1.10.1 Proposed STIG and SRG Applicability Report

1.10.2 Cybersecurity Interconnection Schedule (Encrypted)

1.10.3 Network Communication, Ports, Protocols and Services Report

1.10.4 Control System Inventory Reports

1.10.5 System Data Flow Diagram (Encrypted)

1.10.6 Software and Configuration Backups (Encrypted)

1.10.7 Cybersecurity Network (Riser) Diagram (Encrypted)

1.10.8 STIG, SRG and Vendor Guide Compliance Result Report

(Encrypted)

1.10.8.1 STIG, SRG and Vendor Guide Compliance Result Report

Deviations List

1.10.9 Control System Cybersecurity Documentation

1.10.9.1 Software Applications

1.10.9.2 For HVAC Control System Devices

1.10.9.2.1 HVAC Control System Devices FULLY Supporting User

Accounts

1.10.9.2.2 All Other HVAC Control System Devices

1.10.9.3 For Lighting Control System Devices

1.10.9.3.1 Lighting Control System Devices FULLY Supporting User

Accounts

1.10.9.3.2 All Other Lighting Control System Devices

1.10.9.4 [_____] Control System Devices

1.10.9.5 For USACE Civil Works Control System Devices

1.10.9.5.1 USACE Civil Works Control System Devices FULLY

Supporting User Accounts

1.10.9.5.2 All Other USACE Civil Works Control System Devices

1.10.9.6 Default Requirements for Control System Devices

1.11 SOFTWARE LICENSING

1.12 CYBERSECURITY DURING CONSTRUCTION

1.12.1 Contractor Computer Equipment

1.12.1.1 Operating System

1.12.1.2 Anti-Malware Software

1.12.1.3 Passwords and Passphrases

1.12.1.4 User-Based Authentication

1.12.1.5 Firewall

1.12.1.6 Encryption

1.12.1.7 Demonstration of Compliance

1.12.1.8 Contractor Computer Cybersecurity Compliance Statements

1.12.2 Temporary IP Networks

1.12.2.1 Network Boundaries and Connections

1.12.3 Government Access to Network

1.12.4 Temporary Wireless IP Networks

1.12.5 Passwords and Passphrases

1.12.6 Contractor Temporary Network Cybersecurity Compliance

SECTION 25 05 11 Page 2

Statements

1.13 CYBERSECURITY DURING WARRANTY PERIOD

PART 2 PRODUCTS

2.1 ETHERNET SWITCH

2.1.1 Required Functionality

2.1.2 Configuration Requirements

2.2 DAISY CHAIN IP CONTROLLERS

2.3 DATABASE AND WEB SERVER SOFTWARE FOR MODERATE IMPACT SYSTEMS

2.4 Lockable Enclosures with Padlock

PART 3 EXECUTION

3.1 CYBERSECURITY HARDENING AND CONFIGURATION GUIDES

3.2 NETWORK REQUIREMENTS

3.2.1 Information Flow Enforcement In MODERATE Impact Systems

3.2.2 Wireless and Wired Broadcast Communication for Fire Protection

Systems

3.2.3 Wireless and Wired Broadcast Communication for Systems Other than Fire Protection Systems

3.2.3.1 Wireless and Wired Broadcast IP Communications

3.2.3.2 Non-IP Wireless Communication

3.2.3.3 Wireless and Wired Broadcast Communication Request

3.2.3.4 Wireless Communication Testing

3.2.4 Non-IP Control Networks

3.2.5 IP Control Networks

3.2.5.1 IP Network Routers

3.2.5.2 IP Devices With Multiple Ethernet Connections

3.2.6 Cryptographic Protection

3.2.6.1 Additional Cryptographic Protection Requirements for USACE

Civil Works Systems

3.2.7 Device Identification and Authentication

3.2.7.1 For HVAC Control System Devices

3.2.7.2 For Lighting Control System Devices

3.2.7.3 [_____] Control System Devices

3.2.7.4 Default Requirements for Control System Devices

3.2.8 Cryptographic Module Authentication

3.2.9 Secure Network Design

3.2.10 OT Monitoring System (OTMS)

3.3 ACCESS CONTROL REQUIREMENTS

3.3.1 User Accounts

3.3.1.1 Computers

3.3.1.1.1 User Account Levels

3.3.1.2 Controllers

3.3.1.2.1 HVAC Control Systems

3.3.1.2.2 Lighting Control Systems

3.3.1.2.3 Electronic Security Systems (ESS)

3.3.1.2.4 Fire Protection Systems

3.3.1.2.5 USACE Civil Works Control Systems

3.3.1.2.6 [_____] Control Systems

3.3.1.2.7 Default Requirements for Other Control Systems

3.3.1.3 Additional User Account Expiration Requirements In

MODERATE Impact Systems:

3.3.1.3.1 For Control System Applications Running on Computers

3.3.1.3.2 For Other Control System Devices FULLY Supporting

Accounts

3.3.2 Unsuccessful Logon Attempts

3.3.2.1 Devices MINIMALLY Supporting Accounts

SECTION 25 05 11 Page 3

3.3.2.2 Devices FULLY Supporting Accounts

3.3.2.3 High Availability Interfaces Exempt from Unsuccessful

Logon Attempts Requirements

3.3.3 System Use Notification

3.3.3.1 System Use Notification for Remote User Interfaces

3.3.3.2 System Use Notification for Local User Interfaces

3.3.4 Session Lock and Session Termination Requirements In MODERATE

Impact Systems:

3.3.4.1 Session Termination

3.3.4.2 Session Lock

3.3.4.3 Session Lock and Termination for Computers

3.3.4.4 Session Lock and Termination for Controllers

3.3.4.5 Session Lock and Termination Exceptions

3.3.5 Permitted Actions Without Identification or Authentication

3.3.6 Physical Security in MODERATE Impact Systems

3.3.6.1 Physical Security for Media

3.3.6.1.1 Physical Security for Media Inside Mission Space

3.3.6.1.2 Physical Security for Media Outside Mission Space

3.3.6.1.3 Physical Security for Non-Network Media in Fire

Protection Systems

3.3.6.2 Physical Security for Devices

3.3.6.2.1 Physical Security for Devices in Fire Protection

Systems

3.3.6.3 Physical Security for User Interfaces

3.3.6.4 Additional Physical Security for Confidentiality of User

Interfaces and Printers

3.3.7 Enclosures

3.4 USER IDENTIFICATION AND AUTHENTICATION

3.4.1 User Identification and Authentication for All System Types

3.4.2 User Identification and Authentication for Specific System

Types

3.4.2.1 HVAC Control Systems Devices

3.4.2.2 Lighting Control Systems Devices

3.4.2.3 Electronic Security System Devices

3.4.2.4 [_____] Control System Devices

3.4.3 User Identification and Authentication for Specific Devices

3.4.3.1 [_____]

3.4.4 Implementation of Identification and Authorization Requirements

3.4.5 Password-Based Authentication Requirements

3.4.5.1 Passwords for Software and Applications Running on

Computers

3.4.5.2 Passwords for Controllers FULLY Supporting Accounts

3.4.5.3 Passwords for Remote Interfaces

3.4.5.4 Passwords for Devices Minimally Supporting Accounts

3.4.5.5 Password Configuration and Reporting

3.4.6 Authenticator Feedback

3.4.7 Implementation of PKI Infrastructure in Moderate Impact

Systems (Except USACE Civil Works Systems)

3.4.8 Implementation of PKI Infrastructure in USACE Civil Works

Systems

3.5 CYBERSECURITY AUDITING

3.5.1 Audit Events, Content of Audit Records, and Audit Generation

3.5.1.1 Computers

3.5.1.1.1 Audited Events

3.5.1.1.2 Audit Event Information To Record

3.5.1.2 For HVAC Control System Controllers

3.5.1.2.1 HVAC Control System Controllers FULLY Supporting User

Accounts

3.5.1.2.1.1 Audited Events

SECTION 25 05 11 Page 4

3.5.1.2.1.2 Audit Event Information To Record

3.5.1.2.2 Other HVAC Control System Controllers

3.5.1.3 For Lighting Control System Controller

3.5.1.3.1 Lighting Control System Controllers FULLY Supporting

User Accounts

3.5.1.3.1.1 Audited Events

3.5.1.3.1.2 Audit Event Information To Record

3.5.1.3.2 Other Lighting Control System Controllers

3.5.1.4 [_____] Control System Controllers

3.5.1.5 Default Requirements for Control System Controllers

3.5.1.5.1 Controllers Which FULLY Support Accounts

3.5.1.5.1.1 Audited Events

3.5.1.5.1.2 Audit Event Information To Record

3.5.1.5.2 Controllers Which Do Not FULLY Support Accounts

3.5.2 Audit Time Stamps

3.5.3 Auditing Front End Software

3.5.3.1 Import and Upload Requirements

3.5.3.2 Export Requirements

3.5.3.3 Notification Of Audit Failure in Devices in MODERATE

Impact Systems

3.5.3.4 Audit Reduction and Report Generation In MODERATE Impact

Systems

3.5.4 Audit Storage Capacity and Audit Upload

3.5.4.1 Audit Log Storage Notification In MODERATE Impact Systems

3.5.4.2 Device Audit Record Upload Software

3.5.5 Response to Audit Processing Failures

3.6 REQUIREMENTS FOR LEAST FUNCTIONALITY

3.6.1 Device Capabilities

3.6.2 Software

3.7 SYSTEM AND COMMUNICATION PROTECTION

3.7.1 Collaborative Computing

3.7.2 Denial of Service Protection and Application Partitioning In

MODERATE Impact Systems:

3.7.2.1 Network Reliance in MODERATE Impact HVAC Control Systems

3.7.2.2 Network Reliance in MODERATE Impact Lighting Control

Systems

3.7.2.3 Network Reliance in MODERATE Impact [_____] Control Systems

3.7.2.4 Default Requirements for MODERATE Impact Control Systems

3.7.3 Mobile Code In MODERATE Impact Systems:

3.7.4 Protection of Information at Rest In MODERATE Impact Systems:

3.7.5 Process Isolation and Boundary Protection in Moderate Impact

Fire Protection Systems

3.7.5.1 Radio Interfaces for Fire Protection Systems

3.7.5.2 Fire Suppression System Network Isolation

3.7.6 Application Separation

3.8 SAFE MODE AND FAIL SAFE OPERATION

3.9 SYSTEM MAINTENANCE TOOL SOFTWARE

3.10 DEVICE POWER

3.10.1 Device Behavior on Loss of Power In MODERATE Impact Systems:

3.11 VULNERABILITY SCANNING

3.11.1 Computers and Software Running on Computers

3.11.2 Controllers

3.12 VULNERABILITY ALERTS

3.13 FIPS 201-2 REQUIREMENT

3.14 BIOS/UEFI PROTECTION

3.15 SYSTEM AND INTEGRATION INTEGRITY

3.15.1 Malicious Code Protection

3.15.2 Software, Firmware, and Information Integrity In MODERATE

Impact Systems:

SECTION 25 05 11 Page 5

3.15.3 Information System Monitoring

3.16 CONTROL SYSTEM CYBERSECURITY TESTING

3.16.1 Control System Cybersecurity Testing Procedures

3.16.2 Control System Cybersecurity Testing Execution

3.16.3 Control System Cybersecurity Testing Report

3.17 FIELD QUALITY CONTROL, CYBERSECURITY VALIDATION SUPPORT

3.18 CYBERSECURITY TRAINING

-- End of Section Table of Contents --

SECTION 25 05 11 Page 6

USACE / NAVFAC / AFCEC UFGS-25 05 11 (August 2024)

Preparing Activity: USACE Superseding UFGS-25 05 11 (May 2021)

UNIFIED FACILITIES GUIDE SPECIFICATIONS

References are in agreement with UMRL dated January 2025

SECTION 25 05 11

CYBERSECURITY FOR FACILITY-RELATED CONTROL SYSTEMS

08/24

NOTE: This guide specification covers the requirements for cybersecurity for LOW and MODERATE impact facility-related control systems to meet the requirements of the Department of Defense Risk Management Framework (RMF).

Adhere to UFC 1-300-02 Unified Facilities Guide Specifications (UFGS) Format Standard when editing this guide specification or preparing new project specification sections. Edit this guide specification for project specific requirements by adding, deleting, or revising text. For bracketed items, choose applicable item(s) or insert appropriate information.

Remove information and requirements not required in respective project, whether or not brackets are present.

Comments, suggestions and recommended changes for this guide specification are welcome and should be as a Criteria Change Request (CCR).

Note: 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). This section includes Cybersecurity requirements to be included on every DoD project which includes a facility-related control system. This Section does not provide general requirements for a control system, nor are the requirements in this section sufficient to procure a control system. This section must be used in conjunction with another

SECTION 25 05 11 Page 7 controls system specification. For example, for a HVAC controls project, this section should be used in conjunction with Section 23 09 00 and related sections.

Requirements and activities in this section must be coordinated with the other relevant control specification sections. Requirements specific to Cybersecurity should be incorporated into this section, and requirements not specific to Cybersecurity should be included in the appropriate controls section.

This section includes requirements in support of the DoD Risk Management Framework (RMF) for implementing cybersecurity. Refer to UFC 4-010-06, Cybersecurity for Facility-Related Control Systems for requirements on incorporating cybersecurity into control system design and for general information on the RMF process as it applies to control systems.

Assistance for control system cybersecurity is available from the following Service organizations:

Army (other than USACE Civil Works):

Control System Cybersecurity Mandatory Center of Expertise (CSC-MCX), Huntsville Engineering and Support Center (CSC-MCX@usace.army.mil).

Navy (and Marine Corps):

Naval Facilities Engineering Systems Command, Command Information Office (CIO)

Air Force (and Space Force):

Air Force Civil Engineering Center (AFCEC) Operations Directorate, Tyndall Air Force Base

USACE Civil Works:

USACE Critical Infrastructure Cybersecurity Mandatory Center of Expertise (UCIC-MCX) (uciccybersecurity@usace.army.mil)

Note that all projects where USACE is the design-construction agent require coordination with the relevant cybersecurity MCX as well as all other relevant control system MCXs.

Since this Section covers a wide range of control systems, and those systems often have different capabilities and requirements, there are requirements identified in this Section which need extensive designer input or decisions.

Many designer selections in this Section will require coordination with the project site, System Owner, Authorizing Official or a subject matter expert in the specific control systems being

SECTION 25 05 11 Page 8 installed.

NOTE: This Guide Specification is for use on control systems having no impact rating higher than MODERATE. If the project includes systems with impact ratings of HIGH, this specification must be modified to include those additional requirements.

Systems of different types at the same impact level may have different requirements based on the specific needs and capabilities of the control system. This is addressed in this Guide Specification by indicating when requirements apply to a specific system type.

Systems of the same type may have different requirements. This may be due to those systems having different impact levels or due to system-specific requirements for systems at the same impact level.

If a project includes multiple systems, it's critical that it be clear which requirements apply to which systems. This can be done by a) using a single Section and specifying the applicability of requirements (indicating for each system what impact level and system type it is) or b) using multiple Sections. Which approach to employ depends on the needs of the project and the preferences of the specifier and project manager. If using multiple sections use the fourth level specification numbering to differentiate the Sections and indicate in each which systems the Section applies to, for example, one project may have:

1) Section 25 05 11.01 CYBERSECURITY FOR LOW IMPACT

HVAC CONTROL SYSTEMS

2) Section 25 05 11.02 CYBERSECURITY FOR LOW IMPACT

LIGHTING SYSTEMS

3) Section 25 05 11.03 CYBERSECURITY FOR MODERATE

IMPACT ELECTRONIC SECURITY SYSTEMS

4) Section 25 05 11.04 CYBERSECURITY FOR LOW IMPACT

CIVIL WORKS CONTROL SYSTEMS

(The fourth level numbering is not required to be sequential, as long as the mapping between the cybersecurity specification and the control system is clear. Some projects may wish to use fourth level numbering that matches the division they support (25 05 11.23 for HVAC (mechanical) for example).)

In accordance with UFC 4-010-06, for projects designed by or under contract to USACE use multiple specifications as described in this note, where each system has a corresponding cybersecurity section which is included with the section(s) specifying the

SECTION 25 05 11 Page 9 control system.

NOTE: This specification makes use of SpecsIntact Tailoring Options.

Services tailoring options:

Army Air Force

Impact Level tailoring options:

LOW Impact MODERATE Impact

Control system type tailoring options:

HVAC Control Systems Lighting Control Systems Electronic Security Systems (ESS) Fire Protection Systems USACE CW (for USACE Civil Works systems) Designer Specified Requirements Default Requirements

Currently, all text in Fire Protection tags is also within MODERATE Impact tags, and LOW Impact Fire Protection systems are addressed by the default requirements.

These tailoring options affect the subparts that are included throughout the specification to "break out" specific requirements. The "Default Requirements" tailoring option includes "generic" requirements that are intended to apply to a wide range of control systems. The "Designer Specified Requirements" tailoring option will include blank subparts for the specification of requirements, and is intended to be used when customizing requirements to a control system type for which there is no specific tailoring option and for which the "Default Requirements" are not applicable.

Include only tailoring options for the specifications to be addressed. Only include "Default Requirements" if the section is to cover a system not covered by one of the specific system type options AND the "Default Requirements" are adequate. Only include "Designer Specified Requirements" if the section is to cover a system not covered by one of the specific system type options, AND the "Default Requirements" are NOT adequate. When selecting "Designer Specified Requirements", requirements must be added throughout the specification.

PART 1 GENERAL

NOTE: As described in the paragraph below, this

SECTION 25 05 11 Page 10

Section includes text in curly braces ("{" and "}") indicating which cybersecurity control and control correlation identifier (CCI) the requirements of the subpart relate to. When editing this specification to incorporate requirements for other controls or CCIs or to remove requirements related to specific controls or CCIs, revise the list of controls and CCIs accordingly. DO NOT REMOVE THE TEXT IN CURLY BRACES in the final specification; this information is needed for reference during construction, commissioning and cybersecurity assessments.

NOTE: This subpart points the contractor to the locations of STIGs and SRGs, as this Section requires the contractor to meet available STIGs or SRGs. It's not necessary for the designer/specifier to review the STIGs or SRGs for applicability. The contractor is responsible for determining which STIGs or SRGs are applicable and for meeting the relevant requirements.

While most STIGs/SRGs do not require a CAC to access, FOUO STIGs/SRGs do. See the SRG-STIG Compilation Read-Me for more information -https://dl.dod.cyber.mil/wp-content/uploads/stigs/ pdf/U_STIG_Library-zip_Read-ME_v1-07.pdf

Many subparts in this Section contain text in curly braces ("{" and "}") indicating which cybersecurity control and control correlation identifier (CCI) the requirements of the subpart relate to. The text inside these curly braces is for Government reference only and enables coordination of the requirements of this Section with the RMF process throughout the design and construction process. Text in curly braces are not contractor requirements.

This Section refers to Security Requirements Guide (SRGs) and Security Technical Implementation Guide (STIGs). STIGs and SRGs are available online at the Information Assurance Support Environment (IASE) website at https://public.cyber.mil/stigs/downloads/ and an SRG/STIG Applicability Guide and Collection Tool is available at https://public.cyber.mil/stigs/ SCAP/. Not all control system components have applicable STIGs or SRGs.

The "Control Systems SRG" does not apply to work performed under this Section; all requirements within this section to apply applicable SRGs DO NOT include the "Control Systems SRG".

[1.1 CONTROL SYSTEM APPLICABILITY

NOTE: If multiple versions of this Section are used on a single project, keep this subpart and list all the systems to which this specific version of the Section applies.

There are multiple versions of this Section associated with this project.

Different versions have requirements applicable to different control systems. This specific Section applies only to the following control systems: [_____].

SECTION 25 05 11 Page 11

]1.2 RELATED REQUIREMENTS

This section does not contain sufficient requirements to procure a control system and must be used in conjunction with other Sections which specify control systems. This Section adds cybersecurity requirements to the control systems specified in other Sections, and as these requirements are conditioned on the control system being provided, there may be requirements in this Section that will not apply to this project. All Sections containing facility-related control systems or control system components are related to the requirements of this Section. Review all specification sections to determine related requirements.

In cases where a requirement is specified in both this Section and in another Section, the more stringent requirement must be met. In cases where a requirement in this Section conflicts with the requirements of another Section such that both requirements cannot be met at the same time, request direction from the [Contracting Officer][_____] to determine which requirement applies to the project.

1.3 REFERENCES

NOTE: This paragraph is used to list the publications cited in the text of the guide specification. The publications are referred to in the text by basic designation only and listed in this paragraph by organization, designation, date, and title.

Use the Reference Wizard's Check Reference feature when you add a RID outside of the Section's Reference Article to automatically place the reference in the Reference Article. Also use the Reference Wizard's Check Reference feature to update the issue dates.

References not used in the text will automatically be deleted from this section of the project specification when you choose to reconcile references in the publish print process.

The publications listed below form a part of this specification to the extent referenced. The publications are referred to within the text by the basic designation only.

AMERICAN SOCIETY OF HEATING, REFRIGERATING AND AIR-CONDITIONING

ENGINEERS (ASHRAE)

ASHRAE 135 (2020; Interpretation 1-8 2021; Errata 1-2 2021; Addenda CD 2021; Addenda BV-CE 2022;

Interpretation 9-12 2022; Interpretation 13-24 2023; Addenda BV-CF 2023; Errata 3 2023) BACnet—A Data Communication Protocol for Building Automation and Control Networks

SECTION 25 05 11 Page 12

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE)

IEEE 802.1x (2010) Local and Metropolitan Area Networks - Port Based Network Access Control

INTERNET ENGINEERING TASK FORCE (IETF)

IETF RFC 2819 (2000) Remote Network Monitoring (RMON) Management Information Base (MIB)

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST)

NIST FIPS 140-2 (2001) Security Requirements for Cryptographic Modules

NIST FIPS 201-2 (2013) Personal Identity Verification (PIV) of Federal Employees and Contractors

U.S. DEPARTMENT OF DEFENSE (DOD)

DODI 8551.01 (2014) Ports, Protocols, and Services Management (PPSM)

DTM 08-060 (2008) Policy on Use of Department of Defense (DoD) Information Systems - Standard Consent Banner and User Agreement

1.4 DEFINITIONS

1.4.1 Administrator Account

An administrator account is an account with full permissions to a device, application, or operating system, including the ability to create and modify other user accounts.

Note that the operating system Administrator Account may be different than Administrator Accounts for applications hosted on that operating system.

Also, most controllers will not have any support for accounts and will therefore not have an 'Administrator Account'.

1.4.2 Computer

A computer is one of the following:

a. a device running a non-embedded desktop or server version of Microsoft Windows

b. a device running a non-embedded version of MacOS

c. a device running a non-embedded version of Linux

d. a device running a version or derivative of the Android Operating System, where Android is considered separate from Linux

e. a device running a version of Apple iOS

Unless otherwise indicated or clear from context use of the word "device" in this Section includes computers.

SECTION 25 05 11 Page 13

1.4.3 Controller

NOTE: This subpart uses the USACE CW tailoring option to add IP Router.

A device other than a computer, IP Router, or Ethernet switch. For Fire Protection systems this includes fire alarm control panels, remote operating consoles, and remote annunciators.

1.4.4 Mission Space

NOTE: Define "Mission space" such that the contractor is able to determine when a network or device is outside of the mission area. Coordinate the definition of Mission Space with the physical security design and the security organization at the project site.

Select whether to leave the definition or to define mission space on a drawing.

[A device or media is in mission space if physical access to the device or media is controlled by the organization served by the device. For example, a variable air volume (VAV) box controller in a suspended ceiling is in mission space if the VAV box serves that room; an electrical switchgear in an electrical room or an air handling unit (AHU) in a mechanical room or on a rooftop may still be considered to be in mission space if the organization (mission) served by that switchgear or AHU controls access to the electrical room, mechanical room or rooftop.][Mission space is shown on the drawings.]

1.4.5 Network

A network is a group of two or more devices that can communicate using a network protocol. Network protocols must provide a method for addressing devices on the network; a communication method that does not provide an addressing scheme is not a networked form of communication. Devices that communicate using a method of communication that does not support device addressing are not using a network. Addresses may be other than IP addresses, and addressing may be at either Open Systems Interconnection (OSI) layer 2 or layer 3.

1.4.6 Network Connected

A component is network connected (or "connected to a network") only when the device has a network transceiver which is directly connected to the network and implements the network protocol. A device lacking a network transceiver (and accompanying protocol implementation) can never be considered network connected. Note that (unlike many IT definitions of "Network Connected") a device connected to a non-IP network is still considered network connected (an IP connection or IP address is not required for a device to be network connected).

SECTION 25 05 11 Page 14

1.4.6.1 Wireless Network Connected

Any device that supports wireless network communication is network connected to a wireless network, regardless of whether the device is communicating using wireless. Unless physically disabled, devices with wireless transceivers support wireless, it is not sufficient to disable the wireless in software.

1.4.7 Network Media

The thing that provides the communication channel between the devices on a network. Typically wire, but might include wireless, fiber optic, or even power line (some network protocols allow sending network signals over power wiring).

1.4.8 Network Segmentation

NOTE: This subpart is only included when the USACE CW tailoring option is selected.

Segmenting or segregating networks either by logical or physical methods.

Examples of logical methods include firewall zones, virtual local area networks (VLANs), or virtual private networks (VPNs). Physical separation is done by deploying additional hardware. Network segmentation is used for isolation of discrete functions or processes. Each network segment will have its own IP address space or subnet.

1.4.9 Operational Technology (OT)

NOTE: This subpart is only included when the USACE CW tailoring option is selected.

The hardware and software dedicated to detecting and/or causing changes in physical processes through direct monitoring and control of physical devices to accomplish a specific mission in real time.

1.4.10 User Account Support Levels

The support for user accounts is categorized in this Section as one of three levels:

1.4.10.1 FULLY Supported

Device supports configurable individual accounts. Accounts can be created, deleted, modified, etc. Privileges can be assigned to accounts.

These devices support user-based (as opposed to role-based) authentication.

1.4.10.2 MINIMALLY Supported

Device supports a small, fixed number of accounts (perhaps only one).

Accounts cannot be modified. A device with only a "User" and an "Administrator" account would fit this category. Similarly, a device with two PINs for logon - one for restricted and one for unrestricted rights would fit here (in other words, the accounts do not have to be the traditional "username and password" structure). These devices typically

SECTION 25 05 11 Page 15 only support role-based authentication.

Examples of devices which MINIMALLY support accounts are a) a variable frequency drive with a single account which requires a PIN for access to configuration; and b) a room lighting control touchpad interface that has a single account.

1.4.10.3 NOT Supported

Device does not support any Access Enforcement therefore the whole concept of "account" is meaningless.

1.4.11 Manual Local Input

Manual Local Inputs are system analog or binary inputs that are adjustable by a person but are, by intrinsic hardware design, very limited in potential capabilities. Manual Local Inputs do not have touch screens or full keyboards, but may have a few buttons or dials to allow input.

Manual Local Inputs do not have full graphic screens or dot-matrix displays, but may have simple lights (LEDs) or 7-segment displays. Manual Local Inputs do not have any sort of menu structure, each button has a single well-defined function.

Examples of Manual Local Inputs are H-O-A switches, simple thermostats, and disconnect switches.

1.4.12 Card Reader

A card reader is an input/output device whose primary function is to assist in two-factor authentication. A card reader must have an interface to read data from a card and may be able to write data to a card. A card reader may have a means (such as buttons, keypad, touchscreen, etc.) for a user to input a PIN or password, as well as a limited display.

1.4.13 User Interface

A User Interface (UI) is something other than a Manual Local Input or Card Reader that allows a person to interact with the system or device. Note that while a Card Reader is not by itself a User Interface, a User Interface may contain a Card Reader in order for it to authenticate its user. Within control systems, there are a wide range of User Interfaces.

Two important distinctions are 1) whether the user interface is Local or Remote, and 2) the effective capabilities of the User Interface to alter data, which is the "privilege" of the user interface (where effective privilege available to a specific user at a specific user interface is the combination of the greatest privilege offered by the user interface and the specific account the user is logged into).

1.4.13.1 Local User Interface

A Local User Interface is a user interface where the physical hardware the user interacts with (keyboard, buttons, display, etc.) is physically part of the device being affected. All of the relevant characteristics of the user interface are embodied within a single device.

Note that a Local UI may be able to access data in a different device, Local versus Remote in this context refers to the user interface itself;

the capability to access data in a different device is covered under "Full

SECTION 25 05 11 Page 16

User Interface".

1.4.13.2 Remote User Interface

A Remote User Interface implements a Client/Server model where the physical hardware the user interacts with (Client) is physically distinct from the device being affected (Server). Most or all of the security and functionality characteristics of the user interface are defined by the Server, not the Client. The Client and Server communicate via a network connection. A common example of a remote user interface is a web-based interface where the browser (client) is generally on different hardware than the web server (server). A Remote UI remains a Remote UI even if the user happens to be at a Client on the same hardware as the Server. What is important is that a) the Client may be on different hardware than the Server and b) the majority of the security and functional characteristics of the interface are defined at the Server.

Note that this definition of "remote" is consistent with that generally used in the control industry but is not aligned with the NIST 800-53 definition of "Remote", which refers to "outside the system". The term "Remote" here better aligns with the NIST 800-53 definition of "Network" (remote from within the system) Access.

1.4.13.3 Types of User Interface (by capability)

User interfaces are also categorized by their capabilities as being Read Only, Limited, or Full.

1.4.13.3.1 Read-Only User Interface

A Read Only User Interface (also referred to as a View-Only User Interface) is a user interface that only allows for reading data, it does not allow (have the capability to) modify data. A Read Only User Interface may be either Local or Remote. A User Interface that is configured to be Read Only (by some other means than the interface itself, such as using configuration software on a laptop) is a Read-Only Interface. Note a Read Only User Interface may have buttons (or touch screen, etc.) allowing the user to navigate through the presentation of data.

Examples of a Read Only User Interfaces are a) a publicly viewable "energy dashboard" showing weather data and energy usage within a building and b) digital wayfinding signage.

1.4.13.3.2 Limited User Interface

A Limited User Interface is a user interface that - by design - can only alter information local to the user interface. Note that the determination of "alter" includes only direct interactions, it explicitly excludes interactions that might occur as secondary effects. For example, an interface changing the flow setpoint in a pump controller is a direct interaction, the subsequent change in flow (as well as any subsequent downstream changes in valve position) are not direct interactions.

Two examples of LIMITED UIs are: a) a variable speed drive has a Limited Local User Interface which allows the user to change properties within the drive, but does not allow affecting things outside the drive; and b) a typical home WiFi Router has a Limited Remote User Interface which allows configuration of the Router, but does not allow direct interaction with

SECTION 25 05 11 Page 17 other devices.

1.4.13.3.3 Full User Interface

A Full User Interface can alter information in devices outside the device with the user interface. For example, a typical Local Display Panel is a Full Local User Interface while a browser-based front end is a Full Remote User Interface.

1.4.13.3.4 View-Only User Interface

See Read-Only User Interface

1.4.13.4 Other User Interface Terminology

In addition to defining whether a user interface is a Hardware Limited, Read-Only, Limited or Full, and whether it is Local or Remote, user interfaces are classified by whether they are writable or privileged.

1.4.13.4.1 Writable User Interface

Any User Interface that is not Read-Only is Writable. (Limited User Interfaces and Full User Interfaces are both writable user interfaces (as they are capable of changing a value)).

1.4.13.4.2 Privileged User Interface

NOTE: This subpart uses tailoring options for the lettered requirements. After selecting tailoring options edit the letters in this subpart accordingly.

A Privileged UI is a UI that has sufficient capabilities or functionality that it requires specific cybersecurity measures to be put in place to limit its unauthorized use. Ultimately, whether a specific user interface is considered a Privileged User Interface must be determined by usage.

Unless otherwise specified, user interfaces can be determined to be privileged or not using the following:

a. Read-Only User Interfaces are not privileged user interfaces.

b. User Interfaces that can inhibit or force the activation of a fire suppression system (e.g. such as for a pre-action or deluge system) are always privileged user interfaces. Other Full User interfaces for Fire Alarm Systems are privileged user interfaces as indicated and shown, or when another requirement of this Section establishes they are privileged. For all other systems, Full User Interfaces are privileged user interfaces.

c. User interfaces that allow for configuration of auditing or allows for modification or deletion of audit logs are privileged user interface.

d. User interfaces that allow for reprogramming a network connected device is a privileged user interface.

e. Writeable User Interfaces in Electronic Security Systems (ESS) are privileged user interfaces.

SECTION 25 05 11 Page 18

f. Except as specified above, a Limited User Interface must be determined to be privileged or not based on the specific capabilities and use case of the user interface. In general however, user interfaces that do not offer significant capabilities above and beyond those available at that location via other means (e.g. such as a disconnect switch, breaker, or hand-off-auto switch, or physical attack) are not privileged.

1.4.14 Wireless Network

Any network that communicates without using wires or fiber optics as the communication media. Wireless networks include: WiFi, Bluetooth, ZigBee, cellular, satellite, long and short wave radio, 2.4 GHz, free space optical, point-to-point laser, microwave, and IR.

1.4.15 Wired Broadcast Network

Wired Broadcast Networks are any network, such as powerline carrier networks and modem (wired telephony), that use wire-based technologies where there is not a clearly defined boundary for signal propagation.

1.5 ADMINISTRATIVE REQUIREMENTS

1.5.1 Points of Contact

NOTE: Indicate the appropriate point of contact (POC) for each POC.

Previous versions of this specification identified the Contracting Officer Representative (COR) as the POC. UFC 1-300-02, 2-3.7 states, "Use the term "Contracting Officer" \1\; do not use terms such as /1/ “Officer in Charge of Construction,” “Contracting Officer Representative ,” or “Government Representative.” The Contracting Officer (KO) will likely designate a representative, but this is an internal decision and not something the Contractors need to be apprised of.

Government Computer Access Point of Contact: To provide contractor user access to Government computers. Specifically, this POC may be required to arrange for elevated permissions to computers to create a backup disk image or install malware protection software.

HTTPS Certificate Point of Contact: To provide the contractor with web certificates.

Email Address Point of Contact: The POC who will provide the contractor with email addresses for the ISSM and application administrator for auditing.

Password Point of Contact: The POC who will either coordinate the selection of passwords with the contractor or who will indicate individuals to change the passwords in coordination with the contractor.

SECTION 25 05 11 Page 19

Mobile Code Point of Contact: The POC who will provide access to the mobile code repository. (This will generally be someone from the installation IT organization (for the Army, the NEC).)

PKI Infrastructure Point of Contact: The POC who will provide access to the PKI Infrastructure. If PKI is not required by PART 3 of this Section, remove this bracketed text. (This will generally be someone from the installation IT organization (for the Army, the NEC).)

These points of contact are used by name in the specification, and can be found by searching the document for the POC (using underlined text).

Not all projects will require all POCs. If unsure of the POC keep "The Contracting Office Representative (COR)" and the contractor will request as needed.

Coordinate with the following Points of Contact as indicated in this Section and as required. Not all projects will require coordination with all Points of Contact. When coordination is required and no Point of Contact is indicated, coordinate with the [Contracting Officer

(KO)][_____].

a. Government Computer Access Point of Contact: [Contracting Office

(KO)][_____]

b. HTTPS Certificate Point of Contact: [Contracting Officer (KO)][_____]

c. Email Address Point of Contact: [Contracting Officer (KO)][_____]

d. Password Point of Contact: [Contracting Officer (KO)][_____]

e. Mobile Code Point of Contact: [Contracting Officer (KO)][_____][

f. PKI Infrastructure Point of Contact: [Contracting Officer (KO)][_____]

1.5.2 Coordination

NOTE: This subpart deals with cybersecurity related coordination requirements for the contractor, and does not indicate coordination that must be done by the designer/specifier. In addition to the normal project coordination, authorization for wireless use, alternate account lock permissions and devices with multiple IP connections may be impacted by site (or Service) policies and need to be coordinated with the appropriate Government representatives before authorization is provided.

SECTION 25 05 11 Page 20

Coordinate the execution of this Section with the execution of all other Sections related to control systems as indicated in the paragraph RELATED REQUIREMENTS. Items that must be considered when coordinating project efforts include but are not limited to:

a. If requesting permission for wireless or wired broadcast communication, the Wireless and Wired Broadcast Communication Request submittal must be approved prior to control system device selection and installation.

b. If requesting permission for alternate account lock permissions, the Device Account Lock Exception Request must be approved prior to control system device selection and installation.

c. If requesting permission for the use of a device with multiple physical connections to IP networks, the Multiple IP Connection Device Request must be approved prior to control system device selection and installation.

d. Wireless testing may be required as part of the control system testing. See requirements for the Wireless Communication Test Report submittal.

e. If the Device Audit Record Upload Software is to be installed on a computer not being provided as part of the control system, coordination is required to identify the computer on which to install the software.

f. The Cybersecurity Interconnection Schedule must be coordinated with other work that will be interconnected to, and interconnections must be approved by the Government before relying on them for system functionality.

g. Cybersecurity testing support must be coordinated across control systems and with the Government cybersecurity testing schedule.

h. Passwords must be coordinated with the indicated contact for the project site.

i. If applicable, HTTPS web server certificates must be obtained from the indicated HTTPS Certificate Point of Contact.

j. Contractor Computer Cybersecurity Compliance Statements must be provided for each contractor using contractor owned computers.

1.6 SUBMITTALS

NOTE: Review Submittal Description (SD) definitions in Section 01 33 00 SUBMITTAL PROCEDURES and edit the following list, and corresponding submittal items in the text, to reflect only the submittals required for the project. The Guide Specification technical editors have classified those items that require Government approval, due to their complexity or criticality, with a "G." Generally, other submittal items can be reviewed by the Contractor's Quality Control System. Only add a "G" to an item, if the submittal is sufficiently important or

SECTION 25 05 11 Page 21 complex in context of the project.

For Army projects, fill in the empty brackets following the "G" classification, with a code of up to three characters to indicate the approving authority. Codes for Army projects using the Resident Management System (RMS) are: "AE" for Architect-Engineer; "DO" for District Office (Engineering Division or other organization in the District Office); "AO" for Area Office; "RO" for Resident Office; and "PO" for Project Office. Codes following the "G" typically are not used for Navy, and Air Force.

The "S" classification indicates submittals required as proof of compliance for sustainability Guiding Principles Validation or Third Party Certification and as described in Section 01 33 00 SUBMITTAL

PROCEDURES.

NOTE: All submittals in this Guide Specification require Government approval and must have a "G" designation.

Government review of submittals in this Section impact Cybersecurity, and must be coordinated with the appropriate Cybersecurity experts to ensure appropriate review and the identification of issues or concerns that may affect the cybersecurity posture of the system or the ability of the system to receive an RMF authorization.

NOTE: Throughout this subpart, the USACE CW Tailoring Option is used to add "(Encrypted)" after some submittal names.

Government approval is required for submittals with a "G" or "S" classification. Submittals not having a "G" or "S" classification are for Contractor Quality Control approval. Submittals not having a "G" or "S" classification are for information only. When used, a code following the "G" classification identifies the office that will review the submittal for the Government. Submit the following in accordance with Section

01 33 00 SUBMITTAL PROCEDURES:

SD-01 Preconstruction Submittals

NOTE: When the FIRE PROTECTION tailoring option is selected, the Wireless and Wired Broadcast Communication Request will be in brackets. If this specification is used ONLY for Fire Protection Systems remove the bracketed text. Otherwise keep it.

SECTION 25 05 11 Page 22

NOTE: When the USACE CW tailoring option is selected, the USACE OT/Control Systems Acceptable Use Policy (AUP) and Account Level Permissions List submittals are included.

[ Wireless and Wired Broadcast Communication Request; G, [_____]

] Device Account Lock Exception Request; G, [_____]

Multiple Ethernet Connection Device Request; G, [_____]

Contractor Computer Cybersecurity Compliance Statements; G, [_____]

Contractor Temporary Network Cybersecurity Compliance Statements; G, Cybersecurity Interconnection Schedule (Encrypted); G, [_____]

Protection of Information At Rest Proposal; G, [_____]

Proposed STIG and SRG Applicability Report; G, [_____]

Pre-Construction Control System Inventory Report (Encrypted); G, Contractor Personnel Certifications; G, [_____]

USACE OT/Control Systems Acceptable Use Policy (AUP); G, [_____]

Account Level Permissions List (Encrypted); G, [_____]

SD-02 Shop Drawings

NOTE: When the USACE CW tailoring option is selected, the System Data Flow Diagram submittal is included.

Network Communication, Ports, Protocols and Services Report; G[, Cybersecurity Network (Riser) Diagram (Encrypted); G, [_____]

System Data Flow Diagram (Encrypted); G, [_____]

SD-03 Product Data

NOTE: When the USACE CW tailoring option is selected, the Certificate Protection Status submittal is included.

Control System Cybersecurity Documentation; G, [_____]

Certificate Protection Status (Encrypted); G, [_____]

SECTION 25 05 11 Page 23

SD-06 Test Reports

NOTE: When the FIRE PROTECTION tailoring option is selected, the Wireless Communication Test Report will be in brackets. If this specification is used ONLY for Fire Protection Systems remove the bracketed text. Otherwise keep it.

[ Wireless Communication Test Report; G, [_____]

Control System Cybersecurity Testing Procedures; G, [_____]

Control System Cybersecurity Testing Report; G, [_____]

Antivirus/Antimalware Scan Results; G, [_____]

SD-07 Certificates

Software Licenses; G, [_____]

SD-11 Closeout Submittals

NOTE: In PART 3 of this Section there is a designer selection to indicate whether the contractor changes passwords or accompanies site personnel while they change passwords.

If requiring contractor to change passwords, keep "Confidential Password Report" and remove "Password Change Summary Report"

If requiring contractor to accompany site personnel to change passwords, keep "Password Change Summary Report" and remove "Confidential Password Report"

[ Confidential Password Report; G, [_____]

][ Password Change Summary Report; G, [_____]

] Enclosure Keys; G, [_____]

Software and Configuration Backups (Encrypted); G, [_____]

Auditing Front End Software; G, [_____]

Device Audit Record Upload Software; G, [_____]

System Maintenance Tool Software; G, [_____]

Control System Scanning Tools; G, [_____]

STIG, SRG and Vendor Guide Compliance Result Report (Encrypted); G, Final Control System Inventory Report (Encrypted); G, [_____]

SECTION 25 05 11 Page 24

Integrity Verification Software; G, [_____]

Vulnerability Resolution Report; G, [_____]

BIOS/UEFI Protection Password/Passphrase List (Encrypted); G,

1.7 ENCRYPTED SUBMITTAL REQUIREMENTS

NOTE: This subpart is only included when the USACE CW tailoring option is selected

Submittals with sensitive data are marked with "(encrypted)" and must be encrypted with NIST FIPS 140-2 compliant encryption methods with a password that meets the requirements under paragraph PASSWORDS.