G_SMART_GRID_REQUIREMENTS_v4.0_8-23-2019.pdf

September 2019

BLUF: SMART GRID Guam v4.0

· Finegayan

· Naval Base Guam

Buildings" which supersedes prior Figures and ICS Drawing.

Industrial Control Systems (ICS) Requirements for Military Construction (MILCON) Buildings

Attachments:

(1) Figure 1. ICS Requirements for MILCON dated 01/25/18

(2) Figure 2. ICS Cabinet Elevations (2 drawings)

A. Front and Rear View Rack Elevations dated 01/25/18 B. Side View Rack Elevation dated 01/25/18

Design Agent Responsibilities:

1. Refer to Attachment 1 (Figure 1. ICS Requirements for MILCON) to support the Building’s Advanced Metering Infrastructure (AMI) and Direct Digital Control (DDC) Systems. The specifics are provided in the notes titled ICS Requirements in Figure 1. The following summarizes the requirements:

12 strands of outside plant (OSP) single mode fiber from the Area Distribution Node (ADN) to the MILCON building reserved for ICS Systems. At Marine Corps Base Guam, Finegayan, these 12 strands are available at the nearest maintenance hole for connection that originates from the ADN.

ICS Cabinet in the Government Telecom Room (GTR): Cabinet requirements are provided in Figure 1. See Attachment 2 (Figures 2A and 2B ICS Cabinet Elevations) for the location of patch panels and equipment in the ICS Cabinet. ICS components will be installed in the upper half of the compartmented cabinet

24‐port Category 6 (CAT6) patch panels in the mechanical/utility room and the ICS cabinet

4‐port CAT6 data outlets from NEMA 4X enclosures with tamper switch (as required) terminated to CAT6 patch panel in the ICS cabinet. See Figure 1.

2. Section 26 27 14.00 20 Electricity Metering. Paragraph 2.1 Electricity Meters and Accessories.

Delete this paragraph in its entirety, and replace with the following: “Provide meter(s) and connect the meter(s) to the existing AMI DAS. The government will configure the meter(s), which must be compatible with the existing system, using existing software. The Contractor must ensure that the meter(s) are capable of transmitting the specified data to the DAS.”

Note to DOR: AMI Meters require both power and communications pathways. Ensure MILCON infrastructure in in place.

Customer Command Responsibilities:

1. Procurement of applicable ICS equipment listed in Tables 1‐4.

2. Install – Includes physical installation and grounding of equipment in ICS Cabinet.

3. Per OPNAVINST 11010.20H, ensure that Base Electronics System Engineering Plan

(BESEP) or System Engineering Plan (SEP) developers properly account for OSP and inside plant (ISP) ICS infrastructure requirements to provide a complete and usable system. [e.g. NAVFAC PAC CI as the MILCON Construction Agent will receive communications infrastructure requirements from Tenant/System owner C4I POC for inclusion into the Design‐Build Request for Proposal (RFP). The Tenant/C4I System owner also needs to account for the additional ISP and OSP needed for ICS.

NAVFACMAR CIO Responsibilities:

1. Pre‐Installation Test and Check‐Out (PITCO) equipment

2. Submit for Fleet Readiness Certification Board (FRCB) approval to install

3. Submit and obtain Risk Management Framework (RMF) Assessment and Authorization (A&A)

4. Submit Communication Service Request (CSR) for connectivity

5. Configure switches

12/03/2018

(SEE NOTE 2)

TO/FROM ADN

(SM FIBER)

GOVT TELECOM RM (GTR)

ETHERNET

SWITCH (DDC)

CAT6 (IP)

ETHERNET

SWITCH (AMI)

24‐PORT CAT6

PATCH PANEL

(SEE NOTE 4)

MEDIA

CONV

CONV

MECH/UTILITY RM

12 CAT6 (IP)

OM3

MULTIMODE

FIBER

(SEE NOTES

1 & 2)

24‐PORT CAT6

PATCH PANEL

4‐PORT

DATA OUTLET

CAT6

AMI ELECTRIC

METER

CAT6

(IP)

IP

IP

INTERFACE

DEVICE

BUILDING

DDC

CONTROLLER

(SEE NOTE 1)

(IP) CAT6 (IP)

ETHERMETER

GATEWAY

(ETHERMETER)

PWR SUPPLY

(120VAC/24VDC)

AMI WATER

1. PULSE OUTPUT ‐ DRY CONTACT,

SOLID STATE CONTACT OR OPEN

COLLECTOR

2. ABSOLUTE ENCODER TYPE

AMI ELECTRIC

AMI WATER

BATTERY OR PWR SUPPLY

(120VAC/24VDC)

INTERFACE

AMI METER WIRING DIAGRAM

BUILDING

CONTROLLER

RS‐232 (BACnet MS/TP)

RS‐232

DDC LAPTOP

(OPERATOR INTERFACE)

AIR FLOW

MONITOR

STATION

DDC

CONTROLLERS

VRV

INTERFACE

DDC

CONTROLLERS

EXHAUST

FANS

CONTROLLERS

ADDITIONAL DDC CONTROLLERS AS REQUIRED

LAPTOP AND DDC CONTROLLERS

FIGURE 1. ICS REQUIREMENTS FOR MILCON

NOTIONAL DRAWING

01/25/2018

ICS CABINET

(SEE NOTE 3)

NEMA 4X ENCLOSURE W/ TAMPER SWITCH

12‐CAT6 (IP)

NEMA 4X ENCLOSURE W/

TAMPER SWITCH

LEGEND:

MILCON requirements to support ICS

MILCON facility requirement

Provided by Customer Command

OSP SINGLE MODE FIBER

PATCH PANEL

[ 12 STRANDS OF OSP SINGLE MODE FIBER RESERVED FOR ICS]

ICS Requirements:

1. Media converters are required if AMI Electric Meter, Meter Gateway Device (EtherMeter) and/or DDC IP Controllers exceed the maximum allowed length of a CAT6 Ethernet cable of 90 meters between the data outlet and the patch panel. Examples are shown in “AMI Meter Wiring Diagram” & the MECH/UTILITY RM DDC Controllers.

2. Multimode fiber patch panels may be required if media converters are utilized (i.e., between the MECH/UTILITY RM and the GTR; between a Main Building GTR and an auxiliary building within a compound)

3. Cabinet:

− dual compartment with lockable front and rear doors − individually keyed − full‐height with 19" interior width cabinet (84"high x 24" wide x 36" deep) − front and rear vertical mounting rails per compartment − ground bus bar accessible by both compartments bonded to the telecommunications grounding system − Uninterruptible Power Supply (UPS)

Building UPS available:

− provide one 120VAC L5‐20R receptacle connected to a dedicated branch circuit per compartment with one 120VAC rack mounted power strip connected to L5‐20R receptacle (For critical facilities – provide two L5‐20R receptacles required on separate branch circuits per compartment with two power strips connected to each L5‐20R receptacles)

Standalone UPS (no Building UPS):

− provide one 120VAC L5‐20R receptacle connected to a dedicated branch circuit per compartment and a Standalone UPS with one 120VAC rack mounted power strip with 5‐20P connected to to the standalone UPS (For critical facilities: provide two power strips with 5‐20P per compartment connected to standalone UPS)

4. Install patch panel on front rails set back 6" from front of cabinet

COPPER GROUND BUSBAR

POWER STRIP

TWO COMPARTMENT

DIVIDER

RESERVED

FOR

JRM

FIGURE 2A. ICS CABINET ELEVATIONS

‐ FRONT & REAR VIEW

NOTES:

1) INSTALL ICS EQUIPMENT ON UPPER COMPARTMENT OF THE TWO COMPARTMENT CABINET

2) FOR OPTION:

A) BUILDING UPS ~ NON-CRITICAL FACILITY: PROVIDE ONE NEMA L5-20R ON A DEDICATED BRANCH CIRCUIT PER COMPARTMENT CONNECTED TO ONE 120VAC RACK MOUNTED POWER STRIP B) BUILDING UPS ~ CRITICAL FACILITY: PROVIDE TWO NEMA L5-20R ON SEPARATE DEDICATED BRANCH CIRCUITS PER COMPARTMENT CONNECTED TO ONE 120VAC RACK MOUNTED POWER STRIPS C) STANDALONE UPS ~ NON-CRITICAL FACILITY: PROVIDE ONE NEMA L5-20R ON A DEDICATED BRANCH CIRCUIT PER COMPARTMENT AND A STANDALONE UPS CONNECTED TO ONE 120VAC RACK MOUNTED NEMA 5-20P POWER STRIP D) STANDALONE UPS ~ CRITICAL FACILITY: PROVIDE ONE NEMA L5-20R ON A DEDICATED BRANCH CIRCUIT PER COMPARTMENT AND A STANDALONE UPS CONNECTED TO TWO 120VAC RACK MOUNTED NEMA 5-20P POWER STRIPS

3) STANDALONE UPS: APC SMT2200R2X106 (SMART-UPS 2200VA, RACK MOUNTED, 1980 WATTS, L5-20P INPUT, 8 0UTPUT CONNECTORS - 6 NEMA 5-15, 2 NEMA 5-20); OR EQUIVALENT

FRONT VIEW

REAR VIEW

* ADDITIONAL EQUIPMENT AS REQUIRED BY BUILDING ICS SYSTEM DESIGN * ADDITIONAL EQUIPMENT AS REQUIRED BY BUILDING ICS SYSTEM DESIGN * ADDITIONAL EQUIPMENT AS REQUIRED BY BUILDING ICS SYSTEM DESIGN * ADDITIONAL EQUIPMENT AS REQUIRED BY BUILDING ICS SYSTEM DESIGN

A) BUILDING UPS ~ NON-CRITICAL FACILITY B) BUILDING UPS ~ CRITICAL FACILITY C) STANDALONE UPS ~ NON-CRITICAL FACILITY D) STANDALONE UPS ~ CRITICAL FACILITY

BLANK

*MM SC FIBER PATCH PANEL

24-PORT CAT6 PP

*SHELF WITH

MEDIA CONVERTERS

AMI SWITCH

DDC SWITCH

STANDALONE UPS

FIGURE 2B. ICS CABINET ELEVATIONS

‐ SIDE VIEW

L5-20R RECEPACLE(S)

(INSTALL BETWEEN FRONT AND REAR MOUNTING RAILS)

HORIZONTAL COPPER

GROUND BUSBAR

HORIZONTAL

POWER STRIP(S)

FRONT MOUNTING RAILS

(6" FROM FRONT OF CABINET)

CAT6 PP

REAR MOUNTING RAILS

(~3" FROM REAR OF CABINET)

BOTTOM COMPARTMENT

CABLE RACEWAY

L5-20R RECEPACLE(S)

(INSTALL BETWEEN FRONT AND REAR MOUNTING RAILS)

REAR FRONT

COMPARTMENT DIVIDER

HORIZONTAL COPPER

GROUND BUSBAR

HORIZONTAL

POWER STRIP(S)

Background:

Purpose of Form: 1)

2) 3)

How this form will be used:

1)

2)

Initial C-I-A

REQUEST FOR CYBERSECURITY IMPACT ASSESSMENT

INSTRUCTIONS

NOTES:

Due to CIO receiving requests in non-standard formats, this form was created to enable CIO to provide a response in a timely fashion.

The "Initial" C-I-A serves as a notional baseline to be used for planning and development of projects using the "EIE PIT Control System Master List.xls" (RMF KS portal:

https://rmfks.osd.mil/rmf/General/IT/PlatformIT/EIEControlSystems/Pa ges/ default.aspx)

To contain only the information necessary to support the assessment/ designation.

To provide a standard format for requests.

To serve as a record of the initial designation.

The Project Designer/Manager should interface with the customer to discuss the purpose of the facility and to come up with a list of Control Systems being installed.

EX: HVAC, Generator-Stand Alone, Meter - AMI (Elect/Water), etc.

These Control System(s) will be listed in Part I of the form.

Information provided in Part I will serve as the initial input provided to CIO. CIO will then make the initial CIA recommendation for each Control System and fill in Part II.

Project Number:

Project Type:

Project Name:

Project Description:

Facility Number:

Facility Description:

Facility Type:

Customer/Command:

REQUESTOR POC:

DATE:

Part I. REQUESTOR PROVIDED INFORMATION:

ADMINISTRATIVE COMMUNICATIONS UTILITY NON-FACILITY/OTHER

List Control Systems: (example: HVAC, Generator-Stand Alone, Meter - AMI (Elect/Water), one per line)

REQUEST FOR CYBERSECURITY IMPACT ASSESSMENT

ONE (1) FORM PER FACILITY

Additional Comments:

Control System(s):

MILCON SRM OTHER:____________________________________________________________

Initial C-I-A RMF Plan Control System(s):

CIO POC:

DATE:

This initial C-I-A serves as a notional baseline to be used for planning and development of projects.

A final C-I-A determination for each system will be assigned during the RMF process.

Part II. CIO Cybersecurity Impact Assessment

Additional Comments:

X Assessor

USACE / NAVFAC / AFCEC / NASA UFGS-25 05 11 (November 2017)

Preparing Activity: USACE

UNIFIED FACILITIES GUIDE SPECIFICATIONS

References are in agreement with UMRL dated January 2018

SECTION 25 05 11

CYBERSECURITY FOR FACILITY-RELATED CONTROL SYSTEMS

NAVFAC PAC 09/18

NOTE: This guide specification covers the requirements for cybersecurity for facility-related control systems.

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

New UFGS 25 05 11 has been edited by CIO4 PAC to serve as a template and will be included in all projects as a "Government" issued section for AEs to include (not edit) in their project specs when provided with the Division 01 section for the projects. Should the MAR CIO or PWdesire to edit the spec they are invited to do so.

Requirements and activities in this section must be coordinated with the other relevant control specification sections.

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: Control System Cybersecurity Center of Expertise, Huntsville Engineering and Support Center

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

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

Marine Corps: Contact Navy POC for Marine Corps POC information

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

PART 1 GENERAL

This Section refers to Security Requirements Guide (SRGs) and Security Technical Implementation Guide (STIGs). STIGs and SRGs are are available online at the Information Assurance Support Environment (IASE) website at http://iase.disa.mil/stigs/Pages/index.aspx. Not all control system components have applicable STIGs or SRGs.

1.1 RELATED REQUIREMENTS

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.

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.

AMERICAN SOCIETY OF HEATING, REFRIGERATING AND AIR-CONDITIONING

ENGINEERS (ASHRAE)

ASHRAE 135 (2016; INT 1 2016; ERTA 1 2016) BACnet—A Data Communication Protocol for Building Automation and Control Networks

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE)

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

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST)

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

1.3.1 Computer

As used in this Section, 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 OS, where Android is considered separate from Linux

e. a device running a version of Apple iOS

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

Any device that supports wireless communication is network connected, regardless of whether the device is communicating using wireless.

1.3.3 User Account Support Levels

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

1.3.3.1 FULLY Supported

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

1.3.3.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 "user name and password" structure).

1.3.3.3 NOT Supported

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

1.3.4 User Interface

Generally, a user interface is hardware on a device allowing user interaction with that device via input (buttons, switches, sliders, keyboard, touch screen, etc.) and a screen. There are three types of user interfaces defined in this Section: Limited Local User Interface, Full Local User Interface and Remote User Interface. In this Section, when the term "User Interface" is used without specifying which type, it refers only to Full Local User Interface and Remote User Interface (NOT to Limited Local User Interface).

1.3.4.1 Limited Local User Interface

A Limited Local User Interface is a user interface where the interaction is limited, fixed at the factory, and cannot be modified in the field. The user must be physically at the device to interact with it.

Examples of Limited Local User Interface include thermostats.

1.3.4.2 Full Local User Interface

A Full Local User Interface is a user interface where the interaction and displays are field-configurable.

Examples of a Full Local User Interface include local applications on a computer and user interfaces to Variable Speed Drives.

1.3.4.3 Remote User Interface

A Remote User Interface is a user interface on a Client device allowing user interaction with a different Server device. The user need not be physically at the Server device to interact with it.

Examples of Remote User Interfaces include web browsers and Local Display Panels.

1.4 ADMINISTRATIVE REQUIREMENTS

1.4.1 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 communication, the Wireless Communication Request submittal must be approved prior to control system device selection and integration.

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

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

d. Wireless testing may be required as part of the control system testing. If wireless testing is required, provide a Wireless Communication Test Report documenting the testing points and results at each point for each wireless device.

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. 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, HTTP web server certificates must be obtained from the indicated contact for the project site.

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

1.5 SUBMITTALS

Government approval is required for submittals with a "G" designation;

submittals not having a "G" designation are for Contractor Quality Control approval. Submit the following in accordance with Section 01 33 00

SUBMITTAL PROCEDURES:

SD-01 Preconstruction Submittals

Wireless Communication Request; G

Device Account Lock Exception Request; G

Multiple IP Connection Device Request; G

Contractor Computer Cybersecurity Compliance Statements; G

Contractor Temporary Network Cybersecurity Compliance Statements; G

SD-02 Shop Drawings

User Interface Banner Schedule; G

Network Communication Report; G

Cybersecurity Riser Diagram; G

Control System Inventory Report; G

Cybersecurity Interconnection Schedule; G

SD-03 Product Data

Control System Cybersecurity Documentation; G

SD-06 Test Reports

Wireless Communication Test Report; G

SD-07 Certificates

Software Licenses; G

Cybersecurity Representative's Certification Of Qualifications; G

SD-11 Closeout Submittals

Password Summary Report; G

Software Recovery And Reconstitution Images; G

Device Audit Record Upload Software; G

1.6 QUALITY CONTROL

1.6.1 Cybersecurity Representative

Provide a Cybersecurity Representative as the key person to implement and manage the cybersecurity related control systems of the project. This individual must have a minimum of two years of cybersecurity control systems experience, including two projects of similar size and complexity.

Submit the Cybersecurity Representative's certification of qualifications no later than 60 calendar days after Notice to Proceed. Submit one hard copy and an electronic copy.

1.6.1.1 Duties

The Cybersecurity Representative must lead and oversee the cybersecurity control systems work specified herein and be the primary point of contact for the Government regarding the cybersecurity work.

1.6.1.2 Qualifications

The individual must have a minimum of two years with Risk Management Framework implementation experience and experience with Facility Related Control System cybersecurity implementation such as a control system related training or certification.

1.6.2 Cybersecurity Kickoff Meeting

Within 60 calendar days after contract award, the Cybersecurity Representative must schedule a Cybersecurity Kickoff Meeting with the Contracting Officer, system owner, system program manager, and Information Security Manager (ISSM). The meeting will be located at a specific time and place to be determined by the Contracting Officer.

1.7 CYBERSECURITY DOCUMENTATION

1.7.1 Cybersecurity Interconnection Schedule

Provide a completed Cybersecurity Interconnection Schedule documenting connections between the installed system and other systems. Provide the following information for each device communicating between systems: Device Identifier, 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 communication with other authorized systems also provide the Foreign Destination and POC for Destination. 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 http://www.wbdg.org/FFC/NAVGRAPH/graphtoc.pdf.)

1.7.2 Network Communication Report

Provide a network communication report. For each networked controller, document the communication characteristics of the controller including communication protocols, services used, and a general description of what information is communicated over the network. For each controller using IP, document all TCP and UDP ports 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 Report as an editable Microsoft Excel file.

1.7.3 Control System Inventory Report

Provide a Control System Inventory report using the Inventory Spreadsheet listed under this Section at http://www.wbdg.org/FFC/NAVGRAPH/graphtoc.pdf documenting all devices, including networked devices, network infrastructure devices, non-networked devices, input devices (e.g. sensors) and output devices (e.g. actuators). 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 Report as an editable Microsoft Excel file.

1.7.4 Software Recovery and Reconstitution Images

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.

1.7.5 Cybersecurity Riser Diagram

Provide a cybersecurity riser diagram of the complete control system including all network and controller hardware. 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 overlayed on a facility schematic.

1.7.6 Control System Cybersecurity Documentation

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

1.7.6.1 Software Applications

For all software applications running on computers provide:

a. administrator documentation that describes secure configuration of the software

b. administrator documentation that describes secure installation of the software

c. administrator documentation that describes secure operation of the software

d. administrator documentation that describes effective use and maintenance of security functions or mechanisms for the software

e. administrator documentation that describes known vulnerabilities regarding configuration and use of administrative (i.e. privileged) functions for the software

f. user documentation that describes user-accessible security functions or mechanisms in the software and how to effectively use those security functions or mechanisms

g. user documentation that describes methods for user interaction which enables individuals to use the software in a more secure manner

h. user documentation that describes user responsibilities in maintaining the security of the software

1.7.6.2 For HVAC Control System Devices

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

b. Documentation that describes secure operation of the device

c. Documentation that describes effective use and maintenance of security functions or mechanisms for the device

d. Documentation that describes known vulnerabilities regarding configuration and use of administrative (i.e. privileged) functions for the device

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

f. Documentation that describes methods for user interaction which enables individuals to use the device in a more secure manner

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

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

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

1.7.6.3 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

b. Documentation that describes secure installation of the device

c. Documentation that describes secure operation of the device

d. Documentation that describes effective use and maintenance of security functions or mechanisms for the device

e. Documentation that describes known vulnerabilities regarding configuration and use of administrative (i.e. privileged) functions for the device

f. Documentation that describes user-accessible security functions or mechanisms in the device and how to effectively use those security functions or mechanisms

g. Documentation that describes methods for user interaction which enables individuals to use the device in a more secure manner

h. Documentation that describes user responsibilities in maintaining the security of the device

1.8 SOFTWARE UPDATE LICENSING

In addition to all other licensing requirements, all software licensing must include licensing of the following software updates for a period of no less than 5 years:

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 software licenses for all software provided

1.9 CYBERSECURITY DURING CONSTRUCTION

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

1.9.1 Contractor Computer Equipment

Contractor owned computers may be used for construction. When used, contractor computers must meet the following requirements:

1.9.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.9.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. All computers used on this project must be scanned using the installed software at least once per day.

1.9.1.3 Passwords and Passphrases

The passwords and passphrases for all computers 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.9.1.4 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 http://www.wbdg.org/FFC/NAVGRAPH/graphtoc.pdf.

Each Statement must be signed by a cybersecurity representative for the relevant company.

1.9.2 Temporary IP Networks

Temporary contractor-installed IP networks may be used during construction.

When used, temporary contractor-installed IP networks must meet the following requirements:

1.9.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 IP networks provided under this project or Government furnished IP networks provided for this purpose. Any and all network access from outside the project site is prohibited.

1.9.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.9.4 Temporary Wireless IP Networks

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

1.9.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.9.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 http://www.wbdg.org/FFC/NAVGRAPH/graphtoc.pdf. 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.

1.10 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

Not used.

PART 3 EXECUTION

3.1 ACCESS CONTROL REQUIREMENTS

3.1.1 User Accounts

Any device supporting user accounts (either FULLY or MINIMALLY) must limit access to the device according to specified limitations for each account.

Install and configure any device having a STIG or SRG in accordance with that STIG or SRG.

Implement a warning banner on terminal interfaces that conforms to DoD warning banner guidelines. Configure each component of the product to operate using the principle of least privilege. This includes operating system permissions, file access, user accounts, application-to-application communications, and energy delivery system services.

Provide user accounts with configurable access and permissions associated with one or more organizationally defined user role(s), where roles are used. Provide a system administration mechanism for changing user(s') role (e.g., group) associations.

Configure the product such that when a session or interprocess communication is initiated from a less privileged application, access shall be limited and enforced at the more critical side. Provide a method for protecting against unauthorized privilege escalation.

Document options for defining access and security permissions, user accounts, and applications with associated roles. Configure these options, as specified.

Prevent unauthorized changes to the Basic Input/Output System (BIOS) and other firmware and document if not feasible, provide mitigation recommendations.

Verify and provide documentation for the procured product, attesting that unauthorized logging devices are not installed (e.g., key loggers, cameras, and microphones).

3.1.1.1 Computers

All computers must FULLY support user accounts.

3.1.1.2 For HVAC Control System Devices

Devices with web interfaces must either FULLY support user accounts or have their web interface disabled. Field devices with full local user interfaces allowing modification of data must at least MINIMALLY support user accounts.

3.1.1.3 Default Requirements for Control System Devices

For control system devices where User Account requirements are not otherwise indicated in this Section:

a. Devices with web interfaces must either FULLY support user accounts or have their web interface disabled.

b. Field devices with full local user interfaces allowing modification of data must FULLY support user accounts.

c. Field devices with read-only full local user interfaces must at least MINIMALLY support user accounts.

3.1.2 Account Management

Document all accounts (including, but not limited to, generic or default) that need to be active for proper operation of the product. Change default account settings to specific settings (e.g., length, complexity, history, and configurations) provided by government rep. Changed account information will not be published. All new account information will be provided by a protected mechanism. Remove or disable any accounts that are not needed for normal or maintenance operations of the energy delivery system.

Accounts for emergency operations shall be placed in a highly secure configuration and documentation on their configuration.

3.1.3 Unsuccessful Logon Attempts

Except for high availability user interfaces indicated as exempt, devices must meet the indicated requirements for handling unsuccessful logon attempts.

3.1.3.1 Devices MINIMALLY Supporting Accounts

Devices which MINIMALLY support accounts must lock the user input when three unsuccessful logon attempts and must support unlocking of the user input when unlocked by an administrator.

3.1.3.2 Devices FULLY Supporting Accounts

Devices which FULLY support accounts must meet the following requirements.

If a device cannot meet these requirements, document device capabilities to protect from subsequent unsuccessful logon attempts and propose alternate protections in a Device Account Lock Exception Request submittal. Do not implement alternate protection measures without explicit permission from the Government.

a. It must lock the user account when three unsuccessful logon attempts occur within a 15 minute interval.

b. Once an account is locked, the account must stay locked until unlocked by an administrator.

c. Once the indicated number of unsuccessful logon attempts occurs, delay further logon prompts by 5 seconds.

3.1.3.3 High Availability Interfaces Exempt from Unsuccessful Logon Attempts Requirements

Contact local ISSM and System Owner/Program Manager for requirements for high availability interfaces that are exempt from unsuccessful logon attempts. Work with local ISSM an local CIO to complete the following:

High Availability Interfaces Exempt from Unsuccessful Logon Attempts Requirements

User Interface Location Action to take in lieu of locking screen

3.1.4 System Use Notification

Web interfaces must display a warning banner meeting the requirements of

DTM 08-060.

Devices which are connected to a network and have a user interface must display a warning banner meeting the requirements of DTM 08-060 if capable of doing so. Devices which are connected to a network and have a user interface but are not capable of displaying a banner must have a permanently affixed label displaying an approved banner from DTM 08-060.Labels must be machine printed or engraved, plastic or metal, designed for permanent installation, must use a font no smaller than 14 point, and must provide a high contract between font and background colors.

3.1.4.1 User Interface Banner Schedule

Provide a User Interface Schedule using the format indicated showing each user interface provided and how the information banner requirement has been implemented for each user interface.

User Interface Schedule Format (with sample entries)

User Interface Description

User Interface Location

Type of User Interface

Banner Implementation

Sample 1 Room 1 Remote DTM 08-060 Banner "A" Displayed at Logon

Sample 2 Room 2 Limited Local DTM 08-060 Banner "B" on Affixed Label

Sample 3 Room 3 Full Local DTM 08-060 Banner "B" Displayed on Screen

3.1.5 Permitted Actions Without Identification or Authentication

The control system must require identification and authentication before allowing any actions by a user acting from a user interface which MINIMALLY or FULLY supports accounts.

3.1.6 Wireless Access

Unless explicitly authorized by the Government, do not use any wireless communication. Any device with wireless communication capability is considered to be using wireless communication, regardless of whether or not the device is actively communicating wirelessly, except when wireless communication has been physically permanently disabled (such as through the removal of the wireless transceiver). If wireless is approved, the Government will provide wireless requirements separately.

3.1.6.1 Wireless Communication Request

Provide a report documenting the proposed use of wireless communication prior to beginning construction using the Wireless Communication Request Schedule at http://www.wbdg.org/FFC/NAVGRAPH/graphtoc.pdf.

For each device proposed to use wireless 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, RF Frequency, Radiated Power in dBm (decibel with a milliwatt reference), free-space range, and the expected as-installed range.

3.2 CYBERSECURITY AUDITING

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

For devices that have STIG/SRGs related to audit events, content of audit records or audit generation, comply with the requirements of those STIG/SRGs.

3.2.1.1 Computers

For each computer, provide the capability to select audited events and the content of audit logs. Configure computers to audit the indicated events, and to record the indicated information for each auditable event

3.2.1.1.1 Audited Events

Configure each computer to audit the following events:

a. Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels)

a. Successful and unsuccessful logon attempts

b. Privileged activities or other system level access

c. Starting and ending time for user access to the system

d. Concurrent logons from different workstations

e. Successful and unsuccessful accesses to objects

f. All program initiations

g. All direct access to the information system

h. All account creations, modifications, disabling, and terminations

i. All kernel module load, unload, and restart

3.2.1.1.2 Audit Event Information To Record

Configure each computer to record, for each auditable event, the following information (where applicable to the event):

a. What type of event occurred

b. When the event occurred

c. Where the event occurred

d. The source of the event

e. The outcome of the event

f. The identity of any individuals or subjects associated with the event

3.2.1.2 For HVAC Control System Devices

3.2.1.2.1 HVAC Control System Devices FULLY Supporting User Accounts

For devices FULLY supporting accounts, provide the capability to select audited events, and the contents of audit logs. Configure devices to audit the following events:

a. Successful and unsuccessful logon attempts to the device

b. Starting and ending time for user access to the device

c. All account creations, modifications, disabling, and terminations

d. All device shutdown and startup

Configure the device to record for each event the following information (as applicable): the type of event, when the event occurred and the identity of any individuals or subjects associated with the event

3.2.1.2.2 Other HVAC Control System Devices

There are no requirements to perform auditing at HVAC field devices that do not FULLY support accounts.

3.2.1.3 Default Requirements for Control System Devices

For control system devices where Audit Events, Content of Audit Records, and Audit Generation are not otherwise indicated in this Section:

3.2.1.3.1 Devices Which FULLY Support Accounts

For each device which FULLY supports accounts, provide the capability to select audited events and the content of audit logs. Configure devices to audit the indicated events, and to record the indicated information for each auditable event

3.2.1.3.1.1 Audited Events

Configure each device to audit the following events:

a. Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels)

a. Successful and unsuccessful logon attempts

b. Privileged activities or other system level access

c. Starting and ending time for user access to the system

d. Concurrent logons from different workstations

e. All account creations, modifications, disabling, and terminations

f. All kernel module load, unload, and restart

3.2.1.3.1.2 Audit Event Information To Record

Configure each computer to record, for each auditable event, the following information (where applicable to the event):

a. what type of event occurred

b. when the event occurred

c. where the event occurred

d. the source of the event

e. the outcome of the event

f. the identity of any individuals or subjects associated with the event

3.2.1.3.2 Devices Which Do Not FULLY Support Accounts

For each Device which does not FULLY support accounts configure the device to audit all device shutdown and startup events and to record for each event the type of event and when the event occurred.

3.2.2 Audit Storage Capacity and Audit Upload

a. For devices that have STIG/SRGs related to audit storage capacity comply with the requirements of those STIG/SRGs.

b. For non-computer control system devices capable of generating audit records, provide 60 days worth of secure local storage, assuming 10 auditable events per day.

c. For computers, provide storage for audit records in conformance with applicable STIG/SRGs.

3.2.2.1 Device Audit Record Upload Software

For each non-computer device required to audit events, provide, and license to the Government, software implementing a secure mechanism of uploading audit records from the device to a computer and of exporting the uploaded audit records as a Microsoft Excel file or comma separated value text file. Where different devices use different software, provide software of each type required to upload audit logs from all devices.

Contact local ISSM and System Owner/Program Manager for device audit record upload software requirements. Submit copies of device audit record upload software. If there are no non-computer devices requiring auditing, provide a document stating this in lieu of this submittal.

3.2.3 Response to Audit Processing Failures

Front end computers associated with auditing must, in the case of a failure in the auditing system, notify Information Systems Security Manager (ISSM) or Information Systems Security Officer (ISSO) via e-mail. In case of an audit failure, if possible, continue to collect audit records by overwriting existing audit records.

3.2.4 Time Stamps

3.2.4.1 Computers

Computers generating audit records must have internal clocks capable of providing time with a resolution of 1 second. Clocks must not drift more than 10 seconds per day.

Configure the system so that each computer generating audit records maintains accurate time to within 1 second.

3.2.4.2 For HVAC Control System Devices

Time stamp requirements for HVAC Control Systems are as indicated in the HVAC Control System specifications.

3.2.4.3 Default Requirements for Control System Devices

For control system devices where Time Stamps requirements are not otherwise indicated in this Section: Devices generating audit records must have internal clocks capable of providing time with a resolution of 1 second.

Clocks must not drift more than 10 seconds per day. Configure the system so that each device generating audit records maintains accurate time to within 1 second.

3.3 REQUIREMENTS FOR LEAST FUNCTIONALITY

For devices that have a STIG or SRG related to Requirements for Least Functionality (such as configuration settings and port and device I/O access for least functionality), install and configure the device…