Attachment 3 - PWS updated.pdf

11 September 2024

PERFORMANCE WORK STATEMENT (PWS)

FURNISH, REMOVE AND INSTALL FIRE NOTIFICATION SYSTEM

CAMP WARLORD FACILITIES

1. DISCRIPTION OF SERVICES

1.1. The contractor shall provide all qualified personnel, transportation, tools, equipment, materials and services required to furnish, remove and replace fire notification system in 13 facilities of Camp Warlord on Little Rock AFB, AR 72099. The contractor shall accomplish all services below to meet the requirements of this Performance Work Statement (PWS). Work shall be in compliance with all National Fire Protection Association guidelines, Federal, State and local regulations, codes and license requirements. Work shall be accomplished within 90 days of contract award date.

1.2. The Government will neither supervise contractor employees nor control the method by which the contractor performs the required tasks. It shall be the responsibility of the contractor to manage its employees and to guard against any actions that are of the nature of personal services or give the perception of personal services. If the contractor feels that any actions constitute, or are perceived to constitute personal services, it shall be the contractor’s responsibility to notify the Contracting Officer (CO) immediately. These services shall not be used to perform work of a policy/decision making or management nature, (e.g., inherently governmental functions). All decisions relative to programs supported by the contractor shall be the sole responsibility of the Government.

2. SAFETY AND REGULATORY REQUIREMENTS

2.1. Camp Warlord is a training camp. It comprises of 13 facilities, 1401, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 1414. Building 1401 will hold main fire alarm equipment (panels, etc.) and must communicate to all devices in 13 facilities. Contractor shall coordinate with government representative for access. Work shall be accomplished during the hours of 7am to 4pm, Monday-Friday excluding Federal Holidays. Escort will be provided by the facility user.

2.2. Pre-Install Requirements: Before services are commenced, the contractor shall inspect the work site and ascertain all information for the diligent performance of the service(s). The contractor shall notify the ordering agency of any conditions that prevent the suitable completion of these services to include operations that could endanger Government personnel or property and require appropriate abatement action. If the contractor discovers problems associated with the work after starting, he or she shall immediately notify the Contracting Officer (CO) for their approval if the work is to continue. Coordinate with the Government designated representative to have utilities/fire alarms etc…turned on or off during the competition of the task.

2.3. Disposal of waste: All waste disposals are the responsibility of the contractor to include any fees or permits. Recycling containers may be provided if needed for the operation.

Coordinate through your government representative or Contracting Officer Representative

(COR).

2.4. All work shall be accomplished in accordance with all UFGS 28 31 70, UFC 3-600-01, UFGS 25 05 11 and UFC 4-010-06. Contractor must use newest regulations regarding the installation and repair of fire notification systems.

3. WORK REQUIREMENTS

3.1. Drawings provided by the contractor. The capabilities of the cabins shall be to communicate with the main cabin (Bldg #1401) that shall then transmit to the local fire department in the event of an emergency. This is not a mass notification system. There is no sprinkler system. This project is a basic addressable fire alarm system repair and replacement. All the sleeping facilities must have a combination smoke carbon monoxide detector and a heat detector as part of the installation.

3.1.1. Contractor shall provide drawings according to UFGS 28 31 70. A QFPE is required. No additional personnel are needed except DFPE for final testing. Please use UFGS 28 31 70 for design requirements for fire alarm system.

3.1.2. Contractor shall show single-line fire alarm riser diagram. Each device on riser should be identified by type. Indicate connection of equipment.

3.1.3. This work includes designing and providing a new, complete, basic addressable fire alarm system as described herein and contract drawings. Include system wiring, raceways, pull boxes, control equipment, initiating devices, notification appliances, and other accessories and miscellaneous items required for a complete operational system even though each item is not specifically mentioned or described. Provide systems complete and ready for operation. Design and installation must comply with UFGS 25 05 11, UFC 4-010-06 and AFGM 2019-320-02.

3.2. Contractor must provide all materials, workmanship, installation, inspection, testing and equipment.

3.2.1. Provide all materials, equipment, and devices that have been tested by a nationally recognized testing laboratory and listed for fire protection service. Panel, BT-X Tranceiever, all wiring, detectors, addressable manual pull stations, addressable interface devices, etc. Select material from one manufacturer – FCI/Monaco, where possible, and not a combination of manufacturers, for any classification of materials. Material and equipment must be the standard products of a manufacturer regularly engaged in the manufacture of the products for at least 2 years prior to bid opening. No mass notification equipment needed. Please refer to UFGS 28 31 70.

3.2.2. Contractors must provide all new wiring. Do not reuse existing wire. Wiring must be solid copper cable in accordance with the manufacturer’s requirements. Please refer to UFGS 28 31 70.

3.2.3. Major components of equipment must have the manufacturer's name, address, type or style, model or serial number, catalog number, date of installation, installing Contractor's name and address, and the contract number provided on a new name plate permanently affixed to the item or equipment. Major components include, but are not limited to, the following:

3.2.3.1. FACU Nameplates must be etched metal or plastic, permanently attached by screws to control units or adjacent walls.

3.2.4. Keys and locks for equipment, control units and devices must be identical. Master all keys and locks to a single key as required by the Installation Fire Department.

3.2.5. Provide a typeset printed or typewritten instruction card mounted behind a glass cover in a stainless-steel frame. Install the instructions on the interior of the FACU. The card must show those steps to be taken by an operator when a signal is received as well as the functional operation of the system under all conditions, normal, alarm, supervisory, and trouble. The instructions and their mounting location must be approved by the Contracting Officer before being posted.

3.3. Fire alarm (FACU) control unit provided by the contractor.

3.3.1. Contractors must provide a complete fire alarm control unit (FACU) according to the

UFGS 28 31 70.

3.3.2. FACU must have a fully enclosed in a lockable steel cabinet as specified herein.

Operations required for testing or for normal care, maintenance, and use of the system must be performed from the front of the enclosure. If more than a single unit is required at a location to form a complete control unit, the unit cabinets must match exactly. The system must be capable of defining any module as an alarm module and report alarm trouble, loss of polling, or as a supervisory module, and reporting supervisory short, supervisory open or loss of polling such as valve supervisory switches, independent smoke detection systems, relays for output function actuation. Refer to UFGS 28 31 70.

3.3.3. Install control unit components in cabinets large enough to accommodate all components and also to allow ample gutter space for interconnection of control units as well as field wiring.

The cabinet must be a sturdy steel housing, complete with back box, hinged steel door with cylinder lock, and mounting provisions. Refer to UFGS 28 31 70.

3.3.4. Program capability via switches in a locked portion of the FACU to bypass the automatic notification appliance circuits features. Operation of this programmed action must indicate on the FACU display as a supervisory or trouble condition. Refer to UFGS 28 31 70.

3.3.5. Provide control units and control units that are fully field programmable for both input and output of control, initiation, notification, supervisory, and trouble functions. The system program configuration must be menu driven. System changes must be password protected. Any proprietary equipment and proprietary software needed by qualified technicians to implement future changes to the fire alarm system must be provided as part of this contract. Refer to UFGS 28 31 70.

3.3.6. Power and supervise each circuit such that a signal from one device does not prevent the receipt of signals from any other device. Initiating devices must be manually reset by switch from the FACU after the initiating device or devices have been restored to normal.

3.3.7. Contractor shall use UFGS 28 31 70 for all equipment and materials that must be provided.

3.4. Installation

3.4.1. Locate the FACU where indicated on the drawings. The FACU must be located in conditioned space. Conductor terminations must be labeled and a drawing containing conductor, their labels, their circuits, and their interconnection must be permanently mounted in the FACU.

Locate the document storage cabinet adjacent to the FACU unless the Contracting Officer directs otherwise.

3.4.2. When batteries will not fit in the FACU, locate battery cabinets below or adjacent to the FACU. Battery cabinets must be installed at an accessible location when standing at floor level.

Installing batteries above drop ceilings or in inaccessible locations is prohibited. Refer to UFGS 28 31 70.

3.4.3. Locate manual stations as required by NFPA 72 and install. Mount stations according to

UFGS 28 31 70.

3.4.4. Locate smoke and heat detectors. Remove existing detectors. Install combination smoke carbon monoxide detectors and heat detectors in sleeping facilities. Install one smoke detector above new fire alarm panel unit. Refer to the UFGS 28 31 70.

3.4.5. Contractor must install visual notification appliances. LED Exit Signs, Strobes, etc. Please refer to UFGS 28 31 70.

3.4.6. Provide ceiling bridges for ceiling-mounted appliances and tiles where needed. Ceiling bridges must be as recommended/required by the manufacturer of the ceiling-mounted notification appliance. Replace damaged ceiling tiles if needed. If no ceiling tiles, patch and paint. Match paint with current paint. Must be a smooth finish.

3.4.7. No blank covers. Patch and paint all holes and removal of devices. Match paint with current paint. Must be a smooth finish unless it’s a popcorn ceiling.

3.4.8. In unfinished areas (including areas above drop ceilings), paint all exposed electrical conduit (serving fire alarm equipment), fire alarm conduit, surface metal raceway, junction boxes and covers red. In finished areas, paint exposed electrical conduit (serving fire alarm equipment), fire alarm conduit, surface metal raceways, junction boxes, and electrical boxes to match adjacent finishes. Refer to UFGS 28 31 70.

3.4.9. Provide wiring that is installed in a neat and workman like manner and installed parallel with or at right angles to the sides and back of any box, enclosure, or cabinet. Protect all fire wall and smoke wall penetrations with a UL approved system. Conductors that are terminated, spliced, or otherwise interrupted in any enclosure, cabinet, mounting, or junction box must be connected to screw-type terminal blocks. Mark each terminal in accordance with the wiring diagrams of the system. The use of wire nuts or similar devices is prohibited. Wiring to conform with NFPA 70. Refer to UFGS 28 31 70.

3.5. Disconnection and removal of existing system.

3.5.1. Maintain existing fire alarm equipment fully operational until the new equipment has been tested and accepted by the Contracting Officer. As new equipment is installed, label it "NOT IN SERVICE" until the new equipment is accepted. Once the new system is completed, tested, and accepted by the Government, it must be placed in service and connected to the supervising station. Remove tags from new equipment and tag the existing equipment "NOT IN SERVICE" until removed from the building. No decommissioned equipment is permitted to be abandoned in place.

3.5.2. Salvage BT-X and return to the LRAFB.

3.5.3. Contractor shall use UFGS 28 31 70 for all disconnection and removal of existing system instructions.

3.6. Pre-Government Testing

3.6.1. Conduct inspections and tests to ensure that devices and circuits are functioning properly.

Tests must meet the requirements of paragraph entitled "Minimum System Tests" as required by NFPA 72. The contractor and an authorized representative from each supplier of equipment must be in attendance at the pre-Government testing to make necessary adjustments. After inspection and testing is complete, provide a signed Verification of Compliant Installation letter by the QFPE that the installation is complete, compliant with the specification and fully operable. The letter must include the names and titles of the witnesses to the pre-Government tests. Provide all completion documentation as required by NFPA 72 including all referenced annex sections and the test reports.

3.6.2. When the verification of compliant installation has been completed, submit a formal request for Government final test to the Contracting Officer's Representative (COR).

Government final testing will not be scheduled until the DFPE has received copies of the request for Government final testing and Verification of Compliant Installation letter with all required reports. Government final testing will not be performed until after the connections to the installation-wide fire reporting system and the installation-wide mass notification system have been completed and tested to confirm communications are fully functional. Submit request for test at least 15 calendar days prior to the requested test date.

3.6.3. If equipment worked on was found to be defective or non-compliant with contract requirements, perform corrective actions and repeat the tests. Tests must be conducted and repeated, if necessary, until the system has been demonstrated to comply with all contract requirements.

3.6.4. The tests must be performed in accordance with the approved test procedures in the presence of the DFPE. Furnish instruments and personnel required for the tests.

3.6.5. Contractor shall use UFGS 28 31 70 for all final testing requirements. REFER TO APPENDIX

4. GOVERNMENT FURNISHED EQUIPMENT

4.1. None

5. GENERAL REQUIREMENTS

5.1. Contractor personnel and vehicles must possess appropriate passes. These shall be obtained from Installation Security Forces Pass and ID at the Vehicle Inspection Center.

5.2. The Contractor is subject to all installation fire, safety, security, and traffic regulations.

5.3. The Government contracts on the understanding that the Contractor is complying with applicable laws concerning workplace safety.

5.4. The Contractor is subject to all citations and penalties for violation of applicable workplace safety laws. The burden of compliance rests with the Contractor. Enforcement of workplace safety laws is the responsibility of the agency specified in the applicable law.

5.5. The Contracting Officer may notify the Contractor of hazards in Contractor operations that endanger Government personnel or property and require appropriate action. This provision does not constitute assumption of liability for Occupational Safety and Health compliance on the part of the Government or negate other agency responsibility for enforcement of applicable laws.

5.6. Accident prevention principles must be thoroughly integrated into all operations. Unsafe conditions and practices, as identified by the designated representative, must be corrected immediately.

5.7. Contractor Employees: While on the installation, the contractor shall not employ persons for work on this contract if such employee is identified to the contractor by the Contracting Officer as a potential threat to the health, safety, security, general well-being or operational mission of the installation and its population. Contractor personnel shall present a neat appearance and be easily recognized as contractor employees. This may be accomplished by wearing distinctive clothing bearing the name of the organization or by wearing appropriate badges containing the organization's name and the employee's name. Contractor personnel must wear issued base identification cards at all times while on the installation.

5.8. Service contracts shall require contractor employees to identify themselves as contractor personnel by introducing themselves or being introduced as contractor personnel and displaying distinguishing badges or other visible identification for meetings with government personnel. In addition, contracts shall require contractor personnel to appropriately identify themselves as contractor employees in telephone conversations and in formal and informal written correspondence.

6.0. WARRANTY

6.1. Contractor shall guarantee all material, workmanship and labor from defects for a period of 12 months from the date of acceptance of the work. A warranty letter detailing the work accomplished per facility is required to be furnished to the government representative upon acceptance of the work.

7.0. APPENDIXES

Appendix A: Location Map of the Facilities.

Appendix B: Commander’s Environmental Policy Appendix C: UFGS 28 31 70 Appendix D: UFGS 25 05 11 Appendix E: UFC 4 010 06 Appendix F: UFC 3 600 01

UFC 4-010-06

10 October 2023

UNIFIED FACILITIES CRITERIA (UFC)

APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED

CYBERSECURITY OF

FACILITY-RELATED

CONTROL SYSTEMS (FRCS)

This Page Intentionally Left Blank

UNIFIED FACILITIES CRITERIA (UFC)

CYBERSECURITY OF FACILITY-RELATED CONTROL SYSTEMS (FRCS)

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

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

Indicate the Military Department Preparing Activity responsible for the document.

U.S. ARMY CORPS OF ENGINEERS

NAVAL FACILITIES ENGINEERING SYSTEMS COMMAND (Preparing Activity)

AIR FORCE CIVIL ENGINEER CENTER

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

Change No. Date Location

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

FOREWORD

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

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

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

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

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

AUTHORIZED BY:

PETE G. PEREZ, P.E., SES

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

R. S. SILVER, P.E.

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

DAVID H. DENTINO, SES

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

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

TABLE OF CONTENTS

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND

1-1.1 Control System Definition

1-1.2 Facility-Related Control Systems

1-1.3 Risk Management Framework (RMF)

1-2 PURPOSE AND SCOPE

1-3 APPLICABILITY

1-4 GENERAL BUILDING REQUIREMENTS

1-5 ORGANIZATION

1-6 CYBERSECURITY POINTS OF CONTACT BY SERVICE

1-7 GLOSSARY

1-8 REFERENCES

CHAPTER 2 CONTROL SYSTEM CYBERSECURITY OVERVIEW

2-1 RISK MANAGEMENT FRAMEWORK OVERVIEW

2-1.1 Security Controls

2-1.2 RMF Goal

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

2-1.4 Platform Information Technology

2-1.5 Inherited Security Controls

2-1.6 Applicability of RMF Security Controls to Design

2-2 5-LEVEL CONTROL SYSTEM ARCHITECTURE

2-2.1 Architecture Is a General Architecture

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

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

2-2.4 Wireless Networks

2-2.5 Platform Enclave

2-3 CONTROL SYSTEM PROCUREMENT OVERVIEW

CHAPTER 3 APPLYING CYBERSECURITY IN DESIGN

3-1 OVERVIEW

3-1.1 Five Steps for Cybersecurity Design

3-1.2 Definition of “Organization”

3-1.3 Designer Coordination ii

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

FOR DESIGN

3-2.1 Obtaining Actual Impact Ratings

3-2.2 When Impact Ratings Aren’t Provided

3-2.3 Considerations for Reduction of Control System Impact

3-3 STEP 2A: DETERMINATION OF SECURITY CONTROLS

3-3.1 Overlay versus Baseline

3-3.2 Determining Initial Control Set Using an Overlay

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

3-3.4 Additional Resources and Information for Step 2A

3-4 STEP 2B: IDENTIFICATION OF CONTROL CORRELATION

IDENTIFIERS

3-5 STEP 2C: CATEGORIZATION OF CONTROL CORRELATION

IDENTIFIERS BY RESPONSIBILITY

3-5.1 Identifiers by Responsibility

3-5.2 Additional Resources and Information For Step 2C

3-6 STEP 3: INCORPORATE CYBERSECURITY REQUIREMENTS

3-6.1 Addressing DoD Selected Values in CCIs

3-6.2 Other “Organization Defined Values” in CCIs

3-6.3 Requirement Definition and Implementation CCIs

3-6.4 Additional Resources and Information for Step 3

CHAPTER 4 MINIMUM CYBERSECURITY DESIGN REQUIREMENTS

4-1 DESIGN TO MINIMIZE FAILURE

4-1.1 Reduce Dependency on the Network

4-1.2 Reduce Extraneous Functionality

4-2 DESIGN TO MANAGE FAILURE

4-2.1 Design for Graceful Failure

4-2.2 Degraded Operation

4-2.3 Redundancy

4-2.4 Redundancy with independent control systems

4-3 DO NOT IMPLEMENT STANDARD IT FUNCTIONS

4-4 DO NOT PROVIDE REMOTE ACCESS

4-5 AVOID PROBLEMATIC NETWORKS

4-6 PROTECT THE CONTROL SYSTEM WITH PHYSICAL SECURITY

iii

4-7 PROTECT PRIVILEGED USER INTERFACES

4-8 EMPLOY PRINCIPALS OF DESIGN SIMPLICITY

4-8.1 Example: Using PLCs for HVAC Control

4-8.2 Consideration of Overall System Risk

4-9 CYBERSECURITY DURING CONSTRUCTION

4-10 ADDITIONAL REQUIREMENTS FOR MODERATE SYSTEMS

CHAPTER 5 CYBERSECURITY DOCUMENTATION

5-1 OVERVIEW

5-2 USE OF GUIDE SPECIFICATION

5-3 COORDINATION WITH OTHER DISCIPLINES

5-3.1 Determination of Points of Contact

5-3.2 UFGS Coordination Issues

5-4 REQUIREMENTS BY DESIGN PHASE

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

5-4.2 Concept Design (30-35%)

5-4.3 Interim Design (50-65%)

5-4.4 Final Design (Unreviewed 100%)

5-4.5 Issued for Construction (Reviewed 100%)

APPENDIX A RISK MANAGEMENT FRAMEWORK (RMF) OVERVIEW

A-1 RMF OVERVIEW

A-2 RMF PROCESS

A-3 DEFINITION OF CONTROLS FROM NIST AND DODI 8510

A-3.1 Control Families

A-3.2 Control Elements and Enhancements

A-3.3 Control Correlation Identifiers

A-4 REQUIREMENT DEFINITION VS IMPLEMENTATION

A-4.1 CCIs Defining a Requirement

A-4.2 CCIs Requiring Implementing a Requirement

A-5 PLATFORM INFORMATION TECHNOLOGY

APPENDIX B PLATFORM ENCLAVE

B-1 PLATFORM ENCLAVE CONCEPT OVERVIEW

B-2 PLATFORM ENCLAVE USING TWO AUTHORIZATIONS

B-3 PLATFORM ENCLAVE BENEFITS

iv

B-4 ARMY PLATFORM ENCLAVE APPROACH

B-5 NAVY PLATFORM ENCLAVE APPROACH FOR BCS AND UCS

B-6 AIR FORCE PLATFORM ENCLAVE APPROACH

APPENDIX C 5-LEVEL CONTROL SYSTEM ARCHITECTURE

C-1 INTRODUCTION

C-2 5-LEVEL ARCHITECTURE OVERVIEW

C-3 LEVEL 0: SENSORS AND ACTUATORS

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

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

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

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

IP NETWORK

C-8 LEVEL 5: EXTERNAL CONNECTION AND CONTROL SYSTEM

MANAGEMENT

C-9 ARCHITECTURE FREQUENTLY ASKED QUESTIONS (FAQ)

APPENDIX D CONSIDERATIONS IN DETERMINATION OF CONTROL SYSTEM

IMPACT RATINGS

D-1 BACKGROUND

D-1.1 Types of Security Breach

D-1.2 Impact Ratings

D-2 SYSTEM CATEGORIZATION AND DETERMINATION OF IMPACT

RATING

D-2.1 Compare to Similar to Systems

D-2.2 Methodical System Review

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

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

D-2.5 Summary and required categorization rationale

APPENDIX E CYBERSECURITY CONSIDERATIONS FOR INTEGRATING CRITICAL

UTILITY OR BUILDING CONTROL SYSTEMS WITH NON-CRITICAL UMCS

E-1 INTRODUCTION

E-2 LIMIT OUTSIDE FUNCTIONALITY

E-3 FCS-UMCS CONNECTION METHODS

E-3.1 Hardware I/O Interface

E-3.2 Hardware Gateway Interface v

E-3.3 Firewall Interface

E-3.4 Data Diodes

E-4 OTHER CONSIDERATIONS

E-4.1 Local User Interfaces

E-4.2 Management of Risk

APPENDIX F IMPLEMENTATION GUIDANCE FOR SECURITY CONTROLS

F-1 INTRODUCTION

F-2 GENERAL GUIDANCE

F-2.1 Control System versus Standard IT System Terminology

F-2.2 DoD-Defined Values

F-2.3 Security Controls Which are “Automatically Met”

F-2.4 Security Controls Applicability by Architecture Level

F-2.5 Impact Level Applicability

F-3 GUIDANCE FOR INDIVIDUAL SECURITY CONTROLS

F-3.1 Access Control (AC) Control Family

F-3.2 Audit and Accountability (AU) Control Family

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

F-3.4 Configuration Management (CM) Control Family

F-3.5 Contingency Planning (CP) Control Family

F-3.6 Identification and Authorization (IA) Control Family

F-3.7 Incident Response (IR) Control Family

F-3.8 Maintenance (MA) Control Family

F-3.9 Media Protection (MP) Control Family

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

F-3.11 Planning (PL) Control Family

F-3.12 Program Management (PM) Control Family

F-3.13 Personnel Security (PS) Control Family

F-3.14 Risk Assessment (RA) Control Family

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

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

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

APPENDIX G CONTROL CORRELATION IDENTIFIER (CCI) TABLES

G-1 INTRODUCTION

vi

G-2 TABLE STRUCTURE AND CONTENT

G-3 CCI TABLE NOTES

G-3.1 Controls Inherited from Platform Enclave

G-3.2 CCIs in Multiple Tables

G-4 CCI TABLE DESCRIPTIONS

G-5 CCI TABLES

APPENDIX H GLOSSARY

H-1 ACRONYMS

H-1.1 General Acronyms

H-1.2 Security Control Family Acronyms

H-2 DEFINITION OF TERMS

APPENDIX I REFERENCES

FIGURES

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

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

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

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

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

TABLES

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

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

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

Systems viii

CHAPTER 1 INTRODUCTION

1-1 BACKGROUND.

1-1.1 Control System Definition

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

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

1-1.2 Facility-Related Control Systems

There are many types of control systems ranging from building control systems to manufacturing control systems to weapon control systems, all with different names and terminology. Facility-Related Control Systems (FRCS) are a subset of control systems that are used to monitor and control equipment and systems related to DoD real property facilities (for example, building control systems, utility control systems, electronic security systems, and fire and life safety systems).

1-1.3 Risk Management Framework (RMF)

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

1-2 PURPOSE AND SCOPE.

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

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

1-3 APPLICABILITY.

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

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

1-4 GENERAL BUILDING REQUIREMENTS.

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

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

1-5 ORGANIZATION.

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

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

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

1-6 CYBERSECURITY POINTS OF CONTACT BY SERVICE.

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

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

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

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

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

1-7 GLOSSARY.

APPENDIX H contains acronyms, abbreviations, and definitions.

1-8 REFERENCES.

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

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

CHAPTER 2 CONTROL SYSTEM CYBERSECURITY OVERVIEW

2-1 RISK MANAGEMENT FRAMEWORK OVERVIEW.

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

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

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

2-1.1 Security Controls.

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

2-1.2 RMF Goal.

For FRCS, the goal of the RMF is to reduce and mitigate vulnerabilities until the risk to the mission supported by the FRCS is deemed acceptable by the System Owner (SO) and Authorizing Official (AO). Under the RMF, risk reduction is not "all or nothing", rather the security solution must reduce risk while considering the constraints of resources and mission requirements. For application of the RMF to control systems, the determination of cybersecurity risk reduction must also account for any additional risks to system functionality due to application of the security controls. The final decision of whether a level of risk is acceptable is made by the assigned government AO.

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

2-1.3.1 RMF Role of the Designer

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

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

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

2-1.3.2 RMF Role of Control System Installer

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

2-1.4 Platform Information Technology.

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

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

2-1.5 Inherited Security Controls.

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

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

2-1.5.1 Physical Security Inheritance Example.

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

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

2-1.5.2 Policy and Procedures Inheritance Example.

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

2-1.5.3 Connection to another System Inheritance Example.

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

2-1.6 Applicability of RMF Security Controls to Design.

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

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

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

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

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

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

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

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

2-1.6.3 Other Applicability Input

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

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

2-2 5-LEVEL CONTROL SYSTEM ARCHITECTURE.

Even though control systems are becoming more like standard IT systems, there remain major differences that must be recognized. The 5-Level control system architecture shown in Figure 2-1 is a framework for describing the system architecture of any control system. This architecture allows distinctions to be made between portions of the control system that look like standard IT, and portions that do not look like standard IT. This is important as many security controls can be applied in the normal fashion to the portion of the control system that looks like a standard IT system but cannot be applied without modification (or sometimes cannot be applied at all) to the portion that does not look like a standard IT system.

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

2-2.1 Architecture Is a General Architecture

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

A single system may be described by the architecture in multiple ways – a multi-building control system…