ROICC – Norfolk Form Version 2025.09.12 Page 1 of 2

Design Revision 2M eProjects Work Order Number: 1785959

Construction Contract Number: N/A

Building: CA-7

Project Title: Building CA-7 Secure Space and Restroom Addition

Date: 21 August 2026

Design Revision Purpose

1. Response to PPIs

Specification Revisions

The following specifications, dated 8/21/2026, are added accompany this Design Revision:

DIVISION 25 – INTEGRATED AUTOMATION

25 05 11 – CYBERSECURITY FOR FACILITY- RELATED CONTROL SYSTEMS

Revised Price Proposal Form

Price Proposal Form has been updated. Line item 0002 and 0003 have been updated in response to PPIs Revised document has been added to this revision.

ROICC – Norfolk Form Version 2025.09.12 Page 2 of 2

Noted Revisions

Drawings:

Noted Revisions are not included in sheets & specification sections that have been added or re-issued.

Please make the following modifications to the drawing set:

On NAVFAC Drawing No. – 12948328 (HM101) Change Keynote 2 on sheet HM101 to read "REMOVE CREOSOTE TREATED (4x4) WOOD TIES BENEATH WOOD FLOOR COMPLETE. IF IT IS SUSPECTED THAT ADJACENT SOIL IS CONTAMINATED, TEST SOIL

WITH TCLP SAMPLING METHOD. REMOVE CONTAMINATED SOIL AS REQUIRED."

On NAVFAC Drawing No. – 12948373 (CU105) Note 13 – Change to Read “PROPOSED TIE IN CONNECTION TO GAS LINE MAIN. CONTRACTOR TO

COORDINATE WORK PROVIDE BY VIRGINIA NATURAL GAS (VNG)”

On NAVFAC Drawing No. – 12948434 (IN601) The floor finish for 122 Hall is to be LVT1 on the Finish legend.

On NAVFAC Drawing No. - 12948447 (P-601) Note 4 on the Plumbing Fixture Schedule is to be K-15583 in lieu of K-11583.

Specifications:

Noted Revisions are not included in sheets & specification sections that have been added or re-issued.

Please make the following modifications to the specifications:

DIVISION 04 – MASONRY

04 20 00 – UNIT MASONRY

Section 3.6.1.4 – Remove section as water penetration testing is not required.

DIVISION 08 – OPENINGS

08 71 00 – Door Hardware Section 2.3.10.3 – Remove this section as contractor is not responsible for card readers or keypads.

CA-7 Secure Space and Restroom Addition 1785959

SECTION 25 05 11

CYBERSECURITY FOR FACILITY-RELATED CONTROL SYSTEMS

08/24

PART 1 GENERAL

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

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.

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE)

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

SECTION 25 05 11 Page 1

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)

1.3 DEFINITIONS

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

1.3.3 Controller

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

1.3.4 Mission Space

Mission space is shown on the drawings, see sheet AE101 inside of secure

SECTION 25 05 11 Page 2 area boundary.

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

1.3.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.3.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.3.8 User Account Support Levels

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

1.3.8.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.3.8.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 only support role-based authentication.

SECTION 25 05 11 Page 3

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.3.8.3 NOT Supported

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

1.3.9 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.3.10 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.3.11 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.3.11.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 User Interface".

SECTION 25 05 11 Page 4

1.3.11.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.3.11.3 Types of User Interface (by capability)

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

1.3.11.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.3.11.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 other devices.

SECTION 25 05 11 Page 5

1.3.11.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.3.11.3.4 View-Only User Interface

See Read-Only User Interface

1.3.11.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.3.11.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.3.11.4.2 Privileged User Interface

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.

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.

SECTION 25 05 11 Page 6

1.3.12 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.3.13 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.4 ADMINISTRATIVE REQUIREMENTS

1.4.1 Points of Contact

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)

1.4.2 Coordination

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.

SECTION 25 05 11 Page 7

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.5 SUBMITTALS

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. Submit the following in accordance with Section 01 33 00 SUBMITTAL PROCEDURES:

SD-01 Preconstruction Submittals

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; G

Proposed STIG and SRG Applicability Report; G

Pre-Construction Control System Inventory Report; G

SD-02 Shop Drawings

Network Communication, Ports, Protocols and Services Report; G

Cybersecurity Network (Riser) Diagram; G

SD-03 Product Data

SECTION 25 05 11 Page 8

Control System Cybersecurity Documentation; G

SD-06 Test Reports

Wireless Communication Test Report; G

Control System Cybersecurity Testing Procedures; G

Control System Cybersecurity Testing Report; G

SD-07 Certificates

Software Licenses; G

SD-11 Closeout Submittals

Password Change Summary Report; G

Enclosure Keys; G

Software and Configuration Backups; 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; G

Final Control System Inventory Report; G

Integrity Verification Software; G

1.6 CYBERSECURITY DOCUMENTATION

{For Government Reference Only: This subpart (and its subparts) relates to PL-7; CCI-003071}

1.6.1 Proposed STIG and SRG Applicability Report

For each model of network connected or network infrastructure device, use the DISA SRG/STIG Applicability Guide and Collection Tool (available at https://public.cyber.mil/stigs/SCAP/ to identify applicable STIGs or SRGs and provide a report indicating applicable STIGs and SRGs for each model.

Provide the Proposed STIG and SRG Applicability Report concurrently with the Pre-Construction Control System Inventory Report.

1.6.2 Cybersecurity Interconnection Schedule

{For Government Reference Only: This subpart relates to CA-3(b), PL-8, SC-7(9), SC-7(11); CCI-000258, CCI-003072, CCI-003073, CCI-003075, SECTION 25 05 11 Page 9

CCI-002398, CCI-002399, CCI-002401, CCI-002402, CCI-002403. For MODERATE Impact systems, this subpart also relates to SC-7; CCI-001126, CCI-001109 }

Provide a completed Cybersecurity Interconnection Schedule documenting network connections between the installed system and other systems.

Provide the following information for each device directly communicating between systems: Device Identifier, Device Manufacturer, Device Description, Transport layer Protocol, Network Address, Port (if applicable), MAC (Layer 2) address (if applicable), Media, Application Protocol, Service (if applicable), Descriptive Purpose of communication.

For MODERATE Impact Systems: Also describe the impact of loss of the connection on the control system. If other control system Sections used on this project include submittals documenting this information, provide copies of those submittals to meet this requirement.

In addition to the requirements of Section 01 33 00 SUBMITTAL PROCEDURES, provide the Cybersecurity Interconnection Schedule as an editable Microsoft Excel file (a template Cybersecurity Interconnection Schedule in Excel format is available at https://www.wbdg.org/dod/ufgs/ufgs-25-05-11 .)

1.6.3 Network Communication, Ports, Protocols and Services Report

{For Government Reference Only: This subpart (and its subparts) relates to CA-9, PL-8; CCI-002102, CCI-002103, CCI-002104, CCI-002105, CCI-003072, CCI-003073, CCI-003075 and also the submittal requirements associated with CM-6, CM-7, including CM-7(3), CCI-000388. }

Provide a Network Communication, Ports, Protocols and Services Report.

For each networked device, document device identifier and the communication characteristics of the device including communication protocols, services used, encryption employed, and a general description of what information is communicated over the network. For each device using IP communication, document all TCP and UDP ports used. For each device using non-IP communication, document communication protocol and media used. If other control system Sections used on this project include submittals documenting this information, provide copies of those submittals to meet this requirement.

In addition to the requirements of Section 01 33 00 SUBMITTAL PROCEDURES, provide the Network Communication, Ports, Protocols and Services Report as an editable Microsoft Excel file.

1.6.4 Control System Inventory Reports

{For Government Reference Only: This subpart (and its subparts) relates to CM-8(a), SI-17, IA-3; CCI-000389, CCI-000392, CCI-000398, CCI-002773, CCI-002774, CCI-002775, CCI-000777, CCI-000778, CCI-001958}

Provide a Pre-Construction Control System Inventory Report report and a Final Control System Inventory Report, using the Inventory Spreadsheet listed under this Section at https://www.wbdg.org/dod/ufgs/ufgs-25-05-11 .

In the Control System Inventory Reports, document all networked devices, including network infrastructure devices. For each device provide all applicable information for which there is a field on the spreadsheet in accordance with the instructions on the spreadsheet.

In addition to the requirements of Section 01 33 00 SUBMITTAL PROCEDURES, provide the Control System Inventory Reports as editable Microsoft Excel files. Provide the Pre-Construction Control System Inventory Report

SECTION 25 05 11 Page 10 concurrently with the Proposed STIG and SRG Applicability Report

1.6.5 Software and Configuration Backups

{For Government Reference Only: This subpart (and its subparts) relates to CP-10; CCI-000550, CCI-000551, CCI-000552}

For each computer on which software is installed under this project, provide a recovery image of the final as-built computer . This image must allow for bare-metal restore such that restoration of the image is sufficient to restore system operation to the imaged state without the need for re-installation of software. If additional user permissions are required to meet this requirement, coordinate the creation of the image with the identified Government Computer Access Point of Contact.

For all controllers, provide a backup of the controller configuration and the source code for all loaded application programs (all software that is not common to every controller of the same manufacturer and model).

If any or all of these are provided under another Section, provide documentation indicating this and referencing those submittals.

1.6.6 Cybersecurity Network (Riser) Diagram

{For Government Reference Only: This subpart (and its subparts) relates to PL-2(a), PL-8; CCI-003051, CCI-003053, CCI-003072, CCI-003073, CCI-003075}

Provide a cybersecurity network (riser) diagram of the complete control system including all network and device hardware. For each device, include the device identifier, device type, and manufacturer. If the control system specifications require a riser diagram submittal, provide a copy of that submittal as the cybersecurity riser diagram. Otherwise, provide a riser diagram in one-line format.

1.6.7 STIG, SRG and Vendor Guide Compliance Result Report

For every component (device or software) with an applicable STIG or SRG in the Proposed STIG and SRG Applicability Report, document compliance with the STIG or SRG requirements.

a. For components which are scannable by the SCAP (security content automation protocol) tool (available online at https://public.cyber.mil/stigs/scap ), include the SCAP report and raw scan results in addition to the final, manually reviewed and revised, documentation of compliance with STIG and SRG requirements. Checklist files should not contain any findings with a Not Reviewed (NR) status after manual reviews.

b. For components which do not support automated scanning, a manual review using the General Purpose STIG option should be done. A completed Checklist file should not contain any findings with a Not Reviewed (NR) status after manual reviews

For every component (device or software) with manufacturer provided cybersecurity documentation, procedure, or method for secure configuration or installation, provide a report documenting how the component was

SECTION 25 05 11 Page 11 configured and any deviation from the manufacturer instructions.

1.6.8 Control System Cybersecurity Documentation

{For Government Reference Only: This subpart (and its subparts) relates to SA-5(a),SA-5(b),SA-5(c), SA-22(b); CCIs: CCI-003124, CCI-003125, CCI-003126, CCI-003127, CCI-003128, CCI-003129, CCI-003130, CCI-003131, CCI-003374}

Provide a Control System Cybersecurity Documentation submittal containing the indicated information for each device and software application.

1.6.8.1 Software Applications

For all software applications running on computers provide:

a. administrator documentation that describes secure configuration of the software {For Government Reference Only: relates to CCI-003124}

b. administrator documentation that describes secure installation of the software and software updates. {For Government Reference Only:

relates to CCI-003125}

c. administrator documentation that describes secure operation of the software {For Government Reference Only: relates to CCI-003124}

d. administrator documentation that describes effective use and maintenance of security functions or mechanisms for the software {For Government Reference Only: relates to CCI-003127}

e. administrator documentation that describes known vulnerabilities regarding configuration and use of administrative (i.e. privileged) functions for the software {For Government Reference Only: relates to

CCI-003128}

f. user documentation that describes user-accessible security functions or mechanisms in the software and how to effectively use those security functions or mechanisms {For Government Reference Only:

relates to CCI-003129}

g. user documentation that describes methods for user interaction which enables individuals to use the software in a more secure manner {For Government Reference Only: relates to CCI-003130}

h. user documentation that describes user responsibilities in maintaining the security of the software {For Government Reference Only: relates to CCI-003131}

1.6.8.2 For HVAC Control System Devices

1.6.8.2.1 HVAC Control System Devices FULLY Supporting User Accounts

For all HVAC Control System Devices which FULLY support user accounts, provide:

a. Documentation that describes secure configuration of the device {For Government Reference Only: relates to CCI-003124}

b. Documentation that describes secure operation of the device {For

SECTION 25 05 11 Page 12

Government Reference Only: relates to CCI-003124}

c. Documentation that describes effective use and maintenance of security functions or mechanisms for the device {For Government Reference Only: relates to CCI-003127}

d. Documentation that describes known vulnerabilities regarding configuration and use of administrative (i.e. privileged) functions for the device {For Government Reference Only: relates to CCI-003128}

e. Documentation that describes user-accessible security functions or mechanisms in the device and how to effectively use those security functions or mechanisms; or a specific indication that there are no user-accessible security functions or mechanisms in the device {For Government Reference Only: relates to CCI-003129}

f. Documentation that describes methods for user interaction which enables individuals to use the device in a more secure manner {For Government Reference Only: relates to CCI-003130}

1.6.8.2.2 All Other HVAC Control System Devices

For all HVAC Control System Devices which do not FULLY support user accounts, provide:

a. Documentation that describes secure configuration of the device; or a specific indication that there are no secure configuration steps that apply {For Government Reference Only: relates to CCI-003124}

b. Documentation that describes effective use and maintenance of security functions or mechanisms for the device; or a specific indication that there are no security functions or mechanisms in the device {For Government Reference Only: relates to CCI-003127}

c. For devices which include a user interface, documentation that describes methods for user interaction which enables individuals to use the device in a more secure manner {For Government Reference Only: relates to CCI-003130}

1.6.8.3 For Lighting Control System Devices

1.6.8.3.1 All Other Lighting Control System Devices

For all Lighting Control System Devices which do not FULLY support user accounts, provide:

a. Documentation that describes secure configuration of the device; or a specific indication that there are no secure configuration steps that apply {For Government Reference Only: relates to CCI-003124}

b. Documentation that describes effective use and maintenance of security functions or mechanisms for the device; or a specific indication that there are no security functions or mechanisms in the device {For Government Reference Only: relates to CCI-003127}

c. For devices which include a user interface, documentation that describes methods for user interaction which enables individuals to use the device in a more secure manner {For Government Reference Only: relates to CCI-003130}

SECTION 25 05 11 Page 13

1.6.8.4 Default Requirements for Control System Devices

For control system devices where Control System Cybersecurity Documentation requirements are not otherwise indicated in this Section, provide:

a. Documentation that describes secure configuration of the device {For Government Reference Only: relates to CCI-003124}

b. Documentation that describes secure installation of the device {For Government Reference Only: relates to CCI-003125}

c. Documentation that describes secure operation of the device {For Government Reference Only: relates to CCI-003124}

d. Documentation that describes effective use and maintenance of security functions or mechanisms for the device {For Government Reference Only: relates to CCI-003127}

e. Documentation that describes known vulnerabilities regarding configuration and use of administrative (i.e. privileged) functions for the device {For Government Reference Only: relates to CCI-003128}

f. Documentation that describes user-accessible security functions or mechanisms in the device and how to effectively use those security functions or mechanisms {For Government Reference Only: relates to

CCI-003129}

g. Documentation that describes methods for user interaction which enables individuals to use the device in a more secure manner {For Government Reference Only: relates to CCI-003130}

h. Documentation that describes user responsibilities in maintaining the security of the device {For Government Reference Only: relates to

CCI-003131}

i. Documentation of the published last date of support by the manufacturer or indication that a published date is not available.

{For Government Reference Only: relates to CCI-003374}

1.7 SOFTWARE LICENSING

{For Government Reference Only: This subpart (and its subparts) relates to SI-2(a), SI-2(c), SI-7(14); CCI-001227, CCI-002605, CCI-002737}

For all software provided that has not already been licensed to the government or project site, provide a license to the Government for a period of no less than 5 years, and the license must also include the following software updates:

a. Security and bug-fix patches issued by the software manufacturer.

b. Security patches to address any vulnerability identified in the National Vulnerability Database at http://nvd.nist.gov with a Common Vulnerability Scoring System (CVSS) severity rating of MEDIUM or higher.

Provide a single Software Licenses submittal with documentation of the

SECTION 25 05 11 Page 14 software licenses for all software provided

1.8 CYBERSECURITY DURING CONSTRUCTION

{For Government Reference Only: This subpart (and its subparts) relates to AC-18, CA-3; CCI-000258}

In addition to the control system cybersecurity requirements indicated in this section, meet following requirement throughout the construction process.

1.8.1 Contractor Computer Equipment

Contractor owned computers may be used for construction. Contractor computers connected to the control system, control system network, or a control system component at any point during construction must meet the following requirements:

1.8.1.1 Operating System

The operating system must be an operating system currently supported by the manufacturer of the operating system. The operating system must be current on security patches and operating system manufacturer required updates.

1.8.1.2 Anti-Malware Software

The computer must run anti-malware software from a reputable software manufacturer. Anti-malware software must be a version currently supported by the software manufacturer, must be current on all patches and updates, and must use the latest definitions file. Computers used on this project must perform a full antivirus scan at least once per day. Computers which have connected to any other network since the last full antivirus scan must perform a full antivirus scan prior to connection to the control system network or to the temporary contractor-installed IP network.

Perform an antivirus scan on all removable media (e.g., external hard drives, CDs, DVDs, USB flash drives) prior to connecting to the control system environment.

1.8.1.3 Passwords and Passphrases

The passwords and passphrases for computers, applications, and web-based applications supporting passwords must be changed from their default values. Passwords must be a minimum of eight characters with a minimum of one uppercase letter, one lowercase letter, one number and one special character.

1.8.1.4 User-Based Authentication

Each user must have a unique account; sharing of a single account between multiple users is prohibited.

1.8.1.5 Demonstration of Compliance

The Government has the right to require demonstration of computer compliance with these requirements at any time during the project.

SECTION 25 05 11 Page 15

1.8.1.6 Contractor Computer Cybersecurity Compliance Statements

Provide a single submittal containing completed Contractor Computer Cybersecurity Compliance Statements for each company using contractor owned computers. Contractor Computer Cybersecurity Compliance Statements must use the template published at https://www.wbdg.org/dod/ufgs/ufgs-25-05-11 . Each Statement must be signed by a cybersecurity representative for the relevant company.

1.8.2 Temporary IP Networks

Temporary contractor-installed IP networks may be used during construction. When used, temporary contractor-installed IP networks connected to the control system, control system network, or a control system component at any point during construction must meet the following requirements:

1.8.2.1 Network Boundaries and Connections

The network must not extend outside the project site and must not connect to any IP network other than those specifically provided or furnished for this project. Any and all access to the network from outside the project site is prohibited.

1.8.3 Government Access to Network

Government personnel must be allowed to have complete and immediate access to the network at any time in order to verify compliance with this specification.

1.8.4 Temporary Wireless IP Networks

In addition to the other requirements on temporary IP networks, temporary wireless IP (WiFi) networks, when permitted, must not interfere with existing wireless networks, must use WPA2 security and must not broadcast the network name (SSID). Network names (SSID) for wireless networks must be changed from their default values.

1.8.5 Passwords and Passphrases

The passwords and passphrases for all network devices and network access must be changed from their default values. Passwords must be a minimum 8 characters with a minimum of one uppercase letter, one lowercase letter, one number and one special character.

1.8.6 Contractor Temporary Network Cybersecurity Compliance Statements

Provide a single submittal containing completed Contractor Temporary Network Cybersecurity Compliance Statements for each company implementing a temporary IP network. Contractor Temporary Network Cybersecurity Compliance Statements must use the template published at https://www.wbdg.org/dod/ufgs/ufgs-25-05-11 . Each Statement must be signed by a cybersecurity representative for the relevant company. If no temporary IP networks will be used, provide a single copy of the Statement indicating this.

SECTION 25 05 11 Page 16

1.9 CYBERSECURITY DURING WARRANTY PERIOD

All work performed on the control system after acceptance must be performed using Government Furnished Equipment or equipment specifically and individually approved by the Government.

PART 2 PRODUCTS

All products used on this project must meet the indicated requirements, but not all products specified here will be required by every project.

2.1 ETHERNET SWITCH

Provide Open Systems Interconnection (OSI) Layer 2 Ethernet switches with the following capabilities, and with an interface to support switch configuration for these capabilities:

2.1.1 Required Functionality

Switches must:

a. Copper Ethernet ports must auto negotiate for 10, 100 and 1000 megabits-per-second links.

b. Be capable of implementing port level access control by MAC address and limit the number of MAC addresses to one MAC address per port.

c. For MODERATE Impact Systems, be capable of implementing per-port access control lists (ACLs) where the list can be filtered by source and destination IP addresses, and by source and destination UDP or TCP ports.

d. Support Remote Network Monitoring (RMON) Port Analysis in accordance with IETF RFC 2819

e. Configure target port and analysis port such that switch clones all target port traffic to analysis port.

f. Support authentication via RADIUS server (for management and 802.1x)

g. Support IEEE 802.1x network login.

2.1.2 Configuration Requirements

Switches must:

a. Support configuration save and restore.

b. Support both manual IP address assignment and acquisition of a dynamic IP address via Dynamic Host Configuration Protocol (DHCP).

c. Be capable of limiting access for configuration to one or more of: a web interface using HTTPS, a command line interface using SSH, or an SNMP connection using SNMP version 3 or later.

d. Support the ability to lock configuration capability to a dedicated management port.

SECTION 25 05 11 Page 17

2.2 DAISY CHAIN IP CONTROLLERS

Controllers used as Daisy Chain IP Controllers must be IP controllers with exactly two Ethernet network connections and basic built-in switch capabilities to allow implementation of an Ethernet network in a daisy chain architecture. Switches incorporated by Daisy Chain IP Controllers are not required to meet the requirements for Ethernet Switches as defined in this Section.

PART 3 EXECUTION

3.1 CYBERSECURITY HARDENING AND CONFIGURATION GUIDES

Install, configure, and harden all hardware and software furnished on this project in accordance with manufacturer provided documentation, procedures, or methods for secure configuration or installation. Do not implement specific hardening actions if that action would conflict with required functionality or another requirement of this Section.

3.2 NETWORK REQUIREMENTS

3.2.1 Information Flow Enforcement In MODERATE Impact Systems

{For Government Reference Only: This subpart (and its subparts) relate to

AC-4; CCI-001368, CCI-001414, CCI-001548, CCI-001549, CCI-001550,

CCI-001551}

Install and configure Ethernet switches to block all traffic on all ports not required by the control protocol.

3.2.2 Wireless and Wired Broadcast Communication for Fire Protection Systems

The use of wireless and wired broadcast communication for fire protection systems within a facility is prohibited. Wireless communication may be used to provide communication from the fire protection system in a facility to the central monitoring station. Communication between the fire protection system and the central monitoring station must be via FIPS 140-2 certified devices.

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

{For Government Reference Only: This subpart (and its subparts) relates to AC-18, AC-18(3); CCI-001438, CCI-001439, CCI-002323, CCI-001441, CCI-001449}

Unless explicitly authorized by the Government, do not use any wireless or wired broadcast communication.

3.2.3.1 Wireless and Wired Broadcast IP Communications

Do not install wireless or wired broadcast IP networks, including: do not install a wireless access point; do not install or configure an ad-hoc wireless network; do not install or configure a WiFi Direct communication.

When explicitly authorized by the Government, wireless IP communication may be used to communicate with an existing wireless network.

SECTION 25 05 11 Page 18

3.2.3.2 Non-IP Wireless Communication

For MODERATE Impact Systems: When non-IP wireless communication is explicitly authorized by the Government, the radios must meet NIST FIPS 140-2 Level 2.

3.2.3.3 Wireless and Wired Broadcast Communication Request

Provide a report documenting the proposed use of wireless or wired broadcast communication prior to device selection using the Wireless and Wired Broadcast Communication Request Schedule at https://www.wbdg.org/dod/ufgs/ufgs-25-05-11 . If there is no proposed use of wireless or wired broadcast communication, provide a document indicating this instead of the Request Schedule.

For each device proposed to use wireless or wired broadcast communication show: the device identifier, a description of the device, the location of the device, the device identifiers of other devices communicating with the device, the protocol used for communication, encryption type and strength. For wireless communication, also show: RF Frequency, Radiated Power in dBm (decibel with a milliwatt reference), free-space range, and the expected as-installed range.

3.2.3.4 Wireless Communication Testing

Conduct testing of wireless communication for all devices indicated on the approved Wireless and Wired Broadcast Communication Request as requiring testing.

To test wireless communication, test for wireless network reception at multiple points along the wireless test boundary in the vicinity of the wireless device, and record whether a network connection can be established at each point. The wireless test boundary is the building exterior walls. If wireless testing is required, provide a Wireless Communication Test Report documenting the testing points and results at each point for each wireless device.

] 3.2.4 Non-IP Control Networks

When control system specifications require particular communication protocols, use only those communication protocols and only as specified.

Do not implement any other communication protocol.

When control system specifications do not indicate requirements for communication protocols, use only those protocols required for operation of the system as specified.

3.2.5 IP Control Networks

{For Government Reference Only: This subpart relates to CM-6(a), CM-7(a), CM-7(b), CM-7(1)(b), SC-41; CCI-001588, CCI-000381, CCI-000380, CCI-000381, CCI-000382, CCI-001761, CCI-001762, CCI-002544, CCI-002545, CCI-002546. For Moderate Impact Systems, this subpart (and its subparts) also relates to SC-5(1), SC-5(2); CCI-001094 CCI-001095 }

IP Networks must be Ethernet networks and must use switches which are Ethernet Switches or Daisy Chain IP Controllers as defined in this Section. Do not use nonsecure functions, ports, protocols and services as defined in DODI 8551.01 unless those ports, protocols and services are

SECTION 25 05 11 Page 19 specifically required by the control system specifications or otherwise specifically authorized by the Government. Do not use ports, protocols and services that are not specified in the control system specifications or required for operation of the control system.

For MODERATE Impact Systems, unless explicitly authorized, do not use IP networks if the same control functionality is available through the use of non-IP networks.

3.2.5.1 IP Network Routers

Do not install any device that performs IP routing.

3.2.5.2 IP Devices With Multiple Ethernet Connections

Except for Ethernet Switches and Daisy Chain IP Controllers, devices must not have more than one Ethernet connection to IP networks unless doing so is required by the project specifications and the specific application is approved. If a device with Multiple Ethernet Connections to IP networks is required, provide a Multiple Ethernet Connection Device Request using the Multiple Ethernet Connection Device Request Template at https://www.wbdg.org/dod/ufgs/ufgs-25-05-11 to request approval for each device. If a device with Multiple Ethernet Connections to IP networks is not required, instead provide a document stating that no approval is being requested.

3.2.6 Cryptographic Protection

{For Government Reference Only: This subpart relates to IA-2(9), IA-3(1), SC-8, SC-13, SC-23(1), SC-23(3); CCI-001942, CCI-001959, CCI-001967, CCI-002418, CCI-002449, CCI-002450, CCI-001185, CCI-001188, CCI-001664.}

3.2.7 Device Identification and Authentication

{For Government Reference Only: This subpart (and its subparts) relates to IA-3; CCI-000777, CCI-000778, CCI-001958. For MODERATE Impact systems, this subpart (and its subparts) also relates to SC-23, SC-23(5);

CCI-001184, CCI-002470. }

All computers must support and implement IEEE 802.1x for device authentication to the network.

3.2.7.1 For HVAC Control System Devices

Devices using HTTP as a control protocol must use HTTPS instead.

3.2.7.2 For Lighting Control System Devices

Devices using HTTP as a control protocol must use HTTPS instead.

3.2.7.3 Default Requirements for Control System Devices

For control system…