W912QR24R0015_Specs_Vol3-0000.pdf
PDF 3 MB Posted
- Solicitation number
- W912QR24R0015
About this file
This Request for Proposal (RFP) solicits bids for the design and construction of a collocated Area Maintenance Support Activity (AMSA) and Vehicle Maintenance Shop (VMS) at Camp Pendleton, California. The U.S. Army Corps of Engineers Engineering District Louisville seeks to award a firm fixed-price design-bid-build contract to construct a 15,000 square foot facility to support the U.S. Army Reserves. In addition to the main building, the project scope includes site work such as clearing, fencing, and utility connections. The facilities must be designed for a minimum 40-year lifespan and incorporate energy efficiencies. The RFP also requires the disposal and demolition of four existing buildings totaling 6,774 square feet. The contract duration is 900 calendar days from award.
View the file
Other files
Show all 13
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Solicitation For Area Maintenance Support Activity (AMSA), Camp Pendleton, CA
P2: 481866
Specifications - Vol. 3 of 3 (DIV 25 - 46) Certified Final Design
27 February 2024
W912QR24R0015
ARIMS: 200A Disposition: Maintain for 15yrs after construction.
W912QR24R0015_Specs_Vol3-0000
PN#: 89783, P2: 481866
Camp Pendleton Area Maintenance Support Activity (AMSA)
DOCUMENT PROJECT Page 1 Certified Final
PROJECT TABLE OF CONTENTS
DIVISION 00 - PROCUREMENT AND CONTRACTING REQUIREMENTS
00 10 00 SOLICITATION CONTRACT FORM
00 80 00.00 06 04/21 SPECIAL PROVISIONS
00 80 00.00 06 CONSTRUCTION
DIVISION 01 - GENERAL REQUIREMENTS
01 32 01.00 06 07/18 PROJECT SCHEDULE
01 33 00 08/18, CHG 4: 02/21 SUBMITTAL PROCEDURES
01 33 29.00 06 11/17 SUSTAINABILITY REPORTING
01 35 26.00 06 GOVERNMENT SAFETY REQUIREMENTS
01 42 00 02/19 SOURCES FOR REFERENCE PUBLICATIONS
01 45 00.15 10 11/16, CHG 2: 08/19 RESIDENT MANAGEMENT SYSTEM CONTRACTOR
MODE (RMS CM)
01 45 04.10 06 CONTRACTOR QUALITY CONTROL
01 45 35 11/20 SPECIAL INSPECTIONS
01 46 00.00 06 04/20 TOTAL BUILDING COMMISSIONING
01 50 00 11/20, CHG 2: 08/22 TEMPORARY CONSTRUCTION FACILITIES AND
CONTROLS
01 57 19.00 06 04/20 TEMPORARY ENVIRONMENTAL CONTROLS AND
PERMITS
01 74 19 02/19, CHG 3: 11/21 CONSTRUCTION WASTE MANAGEMENT AND
DISPOSAL
01 78 23 05/23 OPERATION AND MAINTENANCE DATA
01 91 19 05/23 BUILDING ENCLOSURE COMMISSIONING
DIVISION 02 - EXISTING CONDITIONS
02 41 00 08/22 DEMOLITION
02 81 00 11/18 TRANSPORTATION AND DISPOSAL OF
HAZARDOUS MATERIALS
02 82 00 11/18, CHG 1: 11/19 ASBESTOS REMEDIATION
02 83 00 11/18 LEAD REMEDIATION
02 84 16 11/22 HANDLING OF LIGHTING BALLASTS AND
LAMPS CONTAINING PCBs AND MERCURY
02 84 33 11/22 REMOVAL AND DISPOSAL OF
POLYCHLORINATED BIPHENYLS (PCBs)
DIVISION 03 - CONCRETE
03 30 00 02/19, CHG 4: 08/22 CAST-IN-PLACE CONCRETE
03 42 13.00 10 05/16 PLANT-PRECAST CONCRETE PRODUCTS FOR
BELOW GRADE CONSTRUCTION
03 45 00 05/16, CHG 2: 11/21 PRECAST ARCHITECTURAL CONCRETE
DIVISION 04 - MASONRY
04 20 00 11/15, CHG 2: 05/19 UNIT MASONRY
DIVISION 05 - METALS
05 05 20
05 05 23.16
05/22
08/18
POST-INSTALLED CONCRETE AND MASONRY
ANCHORS
STRUCTURAL WELDING
05 12 00 08/18, CHG 2: 05/21 STRUCTURAL STEEL
05 30 00 05/15, CHG 2: 08/18 STEEL DECKS
PROJECT SIGN DETAILS
DOCUMENT PROJECT Page 2
05 40 00 05/15, CHG 1: 08/18 COLD-FORMED METAL FRAMING
05 50 13 05/17, CHG 1: 08/18 MISCELLANEOUS METAL FABRICATIONS
05 51 33 02/16, CHG 2: 02/18 METAL LADDERS
05 52 00 02/18, CHG 1: 02/20 METAL RAILINGS
DIVISION 06 - WOOD, PLASTICS, AND COMPOSITES
06 10 00 08/16, CHG 2: 11/18 ROUGH CARPENTRY
06 41 16.00 10 08/10, CHG 1: 11/18 PLASTIC-LAMINATE-CLAD ARCHITECTURAL
CABI
NETS
06 61 16 08/20 SOLID SURFACING FABRICATIONS
DIVISION 07 - THERMAL AND MOISTURE PROTECTION
07 05 23 08/19 PRESSURE TESTING AN AIR BARRIER
SYSTEM FOR AIR TIGHTNESS
07 21 13 02/16, CHG 2: 08/20 BOARD AND BLOCK INSULATION
07 21 16 11/11, CHG 4: 08/18 MINERAL FIBER BLANKET INSULATION
07 22 00 02/16, CHG 3: 11/18 ROOF AND DECK INSULATION
07 27 10.00 10 08/19, CHG 1: 02/20 BUILDING AIR BARRIER SYSTEM
07 27 19.01 05/17, CHG 2: 08/20 SELF-ADHERING AIR BARRIERS
07 27 26 05/17, CHG 2: 08/20 FLUID-APPLIED MEMBRANE AIR BARRIERS
07 53 23 05/12, CHG 2: 08/18 ETHYLENE-PROPYLENE-DIENE-MONOMER
ROOFI
NG
07 60 00 05/17, CHG 2: 11/18 FLASHING AND SHEET METAL
07 84 00 05/10, CHG 1: 08/13 FIRESTOPPING
07 92 00 08/16, CHG 3: 11/18 JOINT SEALANTS
DIVISION 08 - OPENINGS
08 11 13 08/20 STEEL DOORS AND FRAMES
08 36 19 08/20 VERTICAL LIFT DOORS
08 51 13 05/19 ALUMINUM WINDOWS
08 71 00 02/16, CHG 4: 02/22 DOOR HARDWARE
08 81 00 05/19 GLAZING
08 91 00 08/20 METAL WALL LOUVERS
DIVISION 09 - FINISHES
09 22 00 02/10, CHG 2: 08/18 SUPPORTS FOR PLASTER AND GYPSUM BOARD
09 29 00 08/16, CHG 4: 02/20 GYPSUM BOARD
09 30 10 08/20 CERAMIC, QUARRY, AND GLASS TILING
09 51 00 08/20 ACOUSTICAL CEILINGS
09 65 00 08/10, CHG 3: 08/18 RESILIENT FLOORING
09 67 23.14 08/16, CHG 1: 08/18 CHEMICAL RESISTANT RESINOUS FLOORING
09 90 00 02/21 PAINTS AND COATINGS
DIVISION 10 - SPECIALTIES
10 11 00 08/20 VISUAL DISPLAY UNITS
10 14 00.20 08/20 INTERIOR SIGNAGE
10 21 13 08/20 TOILET COMPARTMENTS
10 26 00 08/20 WALL PROTECTION
10 28 13 08/20 TOILET ACCESSORIES
10 44 16 11/19 FIRE EXTINGUISHERS
10 51 13 05/11 PLASTIC LOCKERS
10 56 13 04/06 STEEL SHELVING
10 90 00.00 48 04/06 MISCELLANEOUS SPECIALTIES
(PARTIAL OMAR FUNDED)
DOCUMENT PROJECT Page 3
DIVISION 12 - FURNISHINGS
12 24 13 08/20 ROLLER WINDOW SHADES
12 48 00.00 48 11/04 WALK-OFF MAT
DIVISION 13 - SPECIAL CONSTRUCTION
13 34 19 08/20, CHG 1: 02/21 METAL BUILDING SYSTEMS
13 48 73 05/22 SEISMIC CONTROL FOR MISCELLANEOUS
EQUIPMENT
DIVISION 21 - FIRE SUPPRESSION
21 13 13 08/20 WET PIPE SPRINKLER SYSTEMS,
FIRE PROTECTION
DIVISION 22 - PLUMBING
22 00 00 11/15, CHG 4: 05/21 PLUMBING, GENERAL PURPOSE
22 05 48.00 20 04/06, CHG 1: 05/15 MECHANICAL SOUND, VIBRATION, AND
SEISMIC CONTROL
22 15 14.00 40 11/17 GENERAL SERVICE COMPRESSED-AIR
SYSTEMS, LOW PRESSURE
DIVISION 23 - HEATING, VENTILATING, AND AIR CONDITIONING (HVAC)
23 05 48.19 05/18, CHG 2: 08/20 SEISMIC BRACING FOR HVAC
23 05 93.00 06 08/16 TESTING, ADJUSTING, AND BALANCING
(TAB) OF HVAC
23 07 00 02/13, CHG 7: 05/20 THERMAL INSULATION FOR MECHANICAL
SYSTEMS
23 09 00 02/19, CHG 3: 05/21 INSTRUMENTATION AND CONTROL FOR HVAC
23 09 13 11/15, CHG 2: 05/21 INSTRUMENTATION AND CONTROL DEVICES
FOR HVAC
23 09 23.02 02/19, CHG 1: 02/20 BACNET DIRECT DIGITAL CONTROL FOR HVAC
AND OTHER BUILDING CONTROL SYSTEMS
23 11 14 04/06 VEHICLE FLUID PIPING AND EQUIPMENT
23 11 20 05/20 FACILITY GAS PIPING
23 23 00 08/21 REFRIGERANT PIPING
23 30 00 05/20, CHG 1: 02/22 HVAC AIR DISTRIBUTION
23 80 20.00 10 05/20 GAS-FIRED HEATING EQUIPMENT
23 81 00 05/18, CHG 1: 02/21 DECENTRALIZED UNITARY HVAC EQUIPMENT
DIVISION 25 - INTEGRATED AUTOMATION
25 05 11.01 05/21 CYBERSECURITY FOR HVAC
FACILITY-RELATED CONTROL SYSTEMS
25 05 11.02 05/21 CYBERSECURITY FOR FIRE LIFE SAFETY
FACILITY-RELATED CONTROL SYSTEMS
25 05 11.03 05/21 CYBERSECURITY FOR ELECTRICAL
FACILITY-RELATED CONTROL SYSTEMS
25 08 10 05/21 UTILITY MONITORING AND CONTROL SYSTEM
TESTING
25 10 10 02/19, CHG 1: 05/21 UTILITY MONITORING AND CONTROL SYSTEM
(UMCS) FRONT END AND INTEGRATION
DOCUMENT PROJECT Page 4
DIVISION 26 - ELECTRICAL
26 05 48.00 10 10/07 SEISMIC PROTECTION FOR ELECTRICAL
EQUIPMENT
26 08 00 11/22 APPARATUS INSPECTION AND TESTING
26 12 19.10 05/19, CHG 1: 11/19 THREE-PHASE, LIQUID-FILLED PAD-MOUNTED
TRANSFORMERS
26 20 00 08/19, CHG 3: 11/21 INTERIOR DISTRIBUTION SYSTEM
26 28 01.00 10 08/21 COORDINATED POWER SYSTEM PROTECTION
26 29 23 02/20, CHG 1: 05/21 ADJUSTABLE SPEED DRIVE (ASD) SYSTEMS
UNDER 600 VOLTS
26 41 00 11/13 LIGHTNING PROTECTION SYSTEM
26 51 00 05/20, CHG 2: 11/21 INTERIOR LIGHTING
26 56 00 08/21 EXTERIOR LIGHTING
DIVISION 27 - COMMUNICATIONS
27 05 28.36 48 04/20 CABLE TRAYS FOR COMMUNICATIONS SYSTEMS
27 10 00.00 48 10/20 BUILDING TELECOMMUNICATIONS CABLING
SYSTEM
DIVISION 28 - ELECTRONIC SAFETY AND SECURITY
28 13 00.00 48 01/11 Physical Access Control System
28 31 76 08/20 INTERIOR FIRE ALARM AND MASS
NOTIFICATION SYSTEM, ADDRESSABLE
DIVISION 31 - EARTHWORK
31 00 00.00 06 07/18 EARTHWORK
31 62 50 11/20, CHG 1: 05/22 DENSIFIED AGGREGATE PIERS
DIVISION 32 - EXTERIOR IMPROVEMENTS
32 01 19.61 11/19 SEALING OF JOINTS IN RIGID PAVEMENT
32 11 23 05/22 AGGREGATE BASE COURSE FOR FLEXIBLE
PAVING
32 12 13 05/17 BITUMINOUS TACK AND PRIME COATS
32 12 16.16 11/20 ROAD-MIX ASPHALT PAVING
32 13 13.06 05/20 PORTLAND CEMENT CONCRETE PAVEMENT FOR
ROADS AND SITE FACILITIES
32 15 00 05/17 AGGREGATE SURFACING
32 16 19 05/18 CONCRETE CURBS, GUTTERS AND SIDEWALKS
32 17 23 08/16, CHG 5: 11/18 PAVEMENT MARKINGS
32 31 13 11/21 CHAIN LINK FENCES AND GATES
DIVISION 33 - UTILITIES
33 11 00 02/18, CHG 1: 02/22 WATER UTILITY DISTRIBUTION PIPING
33 11 23 11/09, CHG 1: 08/17 NATURAL GAS AND LIQUID PETROLEUM PIPING
33 30 00 05/18 SANITARY SEWERAGE
33 71 02 08/21 UNDERGROUND ELECTRICAL DISTRIBUTION
33 82 00.00 48 04/20 TELECOMMUNICATIONS OUTSIDE PLANT (OSP)
DIVISION 41 - MATERIAL PROCESSING AND HANDLING EQUIPMENT
41 22 13.15 11/22, CHG 1: 02/23 BRIDGE CRANES, OVERHEAD ELECTRIC,
UNDER RUNNING TROLLEY
DOCUMENT PROJECT Page 5
DIVISION 46 - WATER AND WASTEWATER EQUIPMENT
46 25 14 02/11, CHG 1: 11/13 COALESCING OIL-WATER SEPARATORS
-- End of Project Table of Contents --
SECTION 25 05 11 .01
CYBERSECURITY FOR HVAC FACILITY-RELATED CONTROL SYSTEMS
05/21
PART 1 GENERAL
Many subparts in this Section contain text in curly braces ("{" and "}") indicating which cybersecurity control and control correlation identifier (CCI) the requirements of the subpart relate to. The text inside these curly braces is for Government reference only and enables coordination of the requirements of this Section with the RMF process throughout the design and construction process. Text in curly braces are not contractor requirements.
This Section refers to Security Requirements Guide (SRGs) and Security Technical Implementation Guide (STIGs). STIGs and SRGs are available online at the Information Assurance Support Environment (IASE) website at https://public.cyber.mil/stigs/downloads/ and an SRG/STIG Applicability Guide and Collection Tool is available at https://public.cyber.mil/stigs/SCAP/ . Not all control system components have applicable STIGs or SRGs. The "Control Systems SRG" does not apply to work performed under this Section; all requirements within this section to apply applicable SRGs DO NOT include the "Control Systems SRG".
1.1 RELATED REQUIREMENTS
This section does not contain sufficient requirements to procure a control system and must be used in conjunction with other Sections which specify control systems. This Section adds cybersecurity requirements to the control systems specified in other Sections, and as these requirements are conditioned on the control system being provided, there may be requirements in this Section that will not apply to this project. All Sections containing facility-related control systems or control system components are related to the requirements of this Section. Review all specification sections to determine related requirements.
In cases where a requirement is specified in both this Section and in another Section, the more stringent requirement must be met. In cases where a requirement in this Section conflicts with the requirements of another Section such that both requirements cannot be met at the same time, request direction from the Contracting Officer Representative to determine which requirement applies to the project.
1.2 REFERENCES
The publications listed below form a part of this specification to the extent referenced. The publications are referred to within the text by the basic designation only.
AMERICAN SOCIETY OF HEATING, REFRIGERATING AND AIR-CONDITIONING
ENGINEERS (ASHRAE)
ASHRAE 135 (2020; Interpretation 1-8 2021; Errata 1-2
SECTION 25 05 11.01 Page 1
2021; Addenda CD 2021; Addenda BV-CE 2022;
Interpretation 9-12 2022; Interpretation 13-17 2023; Addenda BV-CF 2023; Errata 3 2023) 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
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 Administrator Account
An administrator account is an account with full permissions to a device, application, or operating system, including the ability to create and modify other user accounts.
Note that the operating system Administrator Account may be different than Administrator Accounts for applications hosted on that operating system.
Also, most controllers will not have any support for accounts and will therefore not have an 'Aministrator Account'.
1.3.2 Computer
A computer is one of the following:
a. a device running a non-embedded desktop or server version of Microsoft Windows
b. a device running a non-embedded version of Linux
Unless otherwise indicated or clear from context use of the word "device" in this Section includes computers.
1.3.3 Mission Space
A device or media is in mission space if physical access to the device or media is controlled by the organization served by the device. For example, a VAV box controller in a suspended ceiling is in mission space if the VAV box serves that room; an electrical switchgear in an electrical room or an AHU in a mechanical room or on a rooftop may still be considered to be in mission space if the organization (mission) served by that switchgear or AHU controls access to the electrical room, mechanical room or rooftop.
SECTION 25 05 11.01 Page 2
1.3.4 Network
A network is a group of two or more devices that can communicate using a network protocol. Network protocols must provide a method for addressing devices on the network; a communication method that does not provide an addressing scheme is not a networked form of communication. Devices that communicate using a method of communication that does not support device addressing are not using a network.
1.3.5 Network Connected
A component is network connected (or "connected to a network") only when the device has a network transceiver which is directly connected to the network and implements the network protocol. A device lacking a network transceiver (and accompanying protocol implementation) can never be considered network connected. Note that (unlike many IT definitions of "Network Connected") a device connected to a non-IP network is still considered network connected (an IP connection or IP address is not required for a device to be network connected).
1.3.6 Network Media
The thing that provides the communication channel between the devices on a network. Typically wire, but might include wireless, fiber optic, or even power line (some network protocols allow sending network signals over power wiring).
1.3.7 User Account Support Levels
The support for user accounts is categorized in this Section as one of three levels:
1.3.7.1 FULLY Supported
Device supports configurable individual accounts. Accounts can be created, deleted, modified, etc. Privileges can be assigned to accounts.
These devices support user-based (as opposed to role-based) authentication.
1.3.7.2 MINIMALLY Supported
Device supports a small, fixed number of accounts (perhaps only one).
Accounts cannot be modified. A device with only a "User" and an "Administrator" account would fit this category. Similarly, a device with two PINs for logon - one for restricted and one for unrestricted rights would fit here (in other words, the accounts do not have to be the traditional "username and password" structure). These devices typically only support role-based authentication.
Examples of devices which MINIMALLY support accounts are a) a variable frequency drive with a single account which requires a PIN for access to configuration; and b) a room lighting control touchpad interface that has a single account.
1.3.7.3 NOT Supported
Device does not support any Access Enforcement therefore the whole concept of "account" is meaningless.
SECTION 25 05 11.01 Page 3
1.3.8 Manual Local Input
Manual Local Inputs are system analog or binary inputs that are adjustable by a person but are, by intrinsic hardware design, very limited in potential capabilities. Manual Local Inputs do not have touch screens or full keyboards, but may have a few buttons or dials to allow input.
Manual Local Inputs do not have full graphic screens or dot-matrix displays, but may have simple lights (LEDs) or 7-segment displays. Manual Local Inputs do not have any sort of menu structure, each button has a single well-defined function.
Examples of Manual Local Inputs are H-O-A switches, simple thermostats, and disconnect switches.
1.3.9 User Interface
A User Interface (UI) is something other than a Manual Local Input or Card Reader that allows a person to interact with the system or device. Note that while a Card Reader is not by itself a User Interface, a User Interface may contain a Card Reader in order for it to authenticate its user. Within control systems, there are a wide range of User Interfaces.
Two important distinctions are 1) whether the user interface is Local or Remote, and 2) the effective capabilities of the User Interface to alter data, which is the "privilege" of the user interface (where effective privilege available to a specific user at a specific user interface is the combination of the greatest privilege offered by the user interface and the specific account the user is logged into).
1.3.9.1 Local User Interface
A Local User Interface is a user interface where the physical hardware the user interacts with (keyboard, buttons, display, etc.) is physically part of the device being affected. All of the relevant characteristics of the user interface are embodied within a single device.
Note that a Local UI may be able to access data in a different device, Local versus Remote in this context refers to the user interface itself;
the capability to access data in a different device is covered under "Full User Interface".
1.3.9.2 Types of User Interface (by capability)
User interfaces are also categorized by their capabilities as being Read Only, Limited, or Full.
1.3.9.2.1 Read-Only User Interface
A Read Only User Interface (also referred to as a View-Only User Interface) is a user interface that only allows for reading data, it does not allow (have the capability to) modify data. A Read Only User Interface may be either Local or Remote. A User Interface that is configured to be Read Only (by some other means than the interface itself, such as using configuration software on a laptop) is a Read-Only Interface. Note a Read Only User Interface may have buttons (or touch screen, etc.) allowing the user to navigate through the presentation of data.
Examples of a Read Only User Interfaces are a) a publicly viewable "energy
SECTION 25 05 11.01 Page 4 dashboard" showing weather data and energy usage within a building and b) digital wayfinding signage.
1.3.9.2.2 Full User Interface
A Full User Interface can alter information in devices outside the device with the user interface. For example, a typical Local Display Panel is a Full Local User Interface while a browser-based front end is a Full Remote User Interface.
1.3.9.3 Other User Interface Terminology
1.3.9.3.1 Privileged User Interface
A Privileged UI is a UI that has sufficient capabilities or functionality that it requires specific cybersecurity measures to be put in place to limit its unauthorized use. Ultimately, whether a specific user interface is considered a Privileged User Interface must be determined by usage.
Unless otherwise specified, user interfaces can be determined to be privileged or not using the following:
a. Read-Only User Interfaces are not privileged user interfaces.
b. User interfaces that allow for configuration of auditing or allows for modification or deletion of audit logs are privileged user interface.
c. User interfaces that allow for reprogramming a network connected device is a privileged user interface.
1.4 ADMINISTRATIVE REQUIREMENTS
1.4.1 Points of Contact
Coordinate with the following Points of Contact as indicated in this Section and as required. Not all projects will require coordination with all Points of Contact. When coordination is required and no Point of Contact is indicated, coordinate with The Contracting Office Representative (COR).
a. Government Computer Access Point of Contact: The Contracting Office Representative (COR)
b. HTTPS Certificate Point of Contact: The Contracting Office Representative (COR)
c. Email Address Point of Contact: The Contracting Office Representative
(COR)
d. Password Point of Contact: The Contracting Office Representative (COR)
e. Mobile Code Point of Contact: The Contracting Office Representative
(COR)
f. PKI Infrastructure Point of Contact: The Contracting Office Representative (COR)
1.4.2 Coordination
Coordinate the execution of this Section with the execution of all other
SECTION 25 05 11.01 Page 5
Sections related to control systems as indicated in the paragraph RELATED REQUIREMENTS. Items that must be considered when coordinating project efforts include but are not limited to:
a. If requesting permission for wireless or wired broadcast communication, the Wireless and Wired Broadcast Communication Request submittal must be approved prior to control system device selection and installation.
b. If requesting permission for alternate account lock permissions, the Device Account Lock Exception Request must be approved prior to control system device selection and installation.
c. If requesting permission for the use of a device with multiple physical connections to IP networks, the Multiple IP Connection Device Request must be approved prior to control system device selection and installation.
d. Wireless testing may be required as part of the control system testing. See requirements for the Wireless Communication Test Report submittal.
e. If the Device Audit Record Upload Software is to be installed on a computer not being provided as part of the control system, coordination is required to identify the computer on which to install the software.
f. The Cybersecurity Interconnection Schedule must be coordinated with other work that will be interconnected to, and interconnections must be approved by the Government before relying on them for system functionality.
g. Cybersecurity testing support must be coordinated across control systems and with the Government cybersecurity testing schedule.
h. Passwords must be coordinated with the indicated contact for the project site.
i. If applicable, HTTPS web server certificates must be obtained from the indicated HTTPS Certificate Point of Contact.
j. Contractor Computer Cybersecurity Compliance Statements must be provided for each contractor using contractor owned computers.
1.5 SUBMITTALS
Government approval is required for submittals with a "G" or "S" classification. Submittals not having a "G" or "S" classification are for Contractor Quality Control approval. When used, a code following the "G" classification identifies the office that will review the submittal for the Government. Submit the following in accordance with Section 01 33 00
SUBMITTAL PROCEDURES:
SD-02 Shop Drawings
Network Communication Report ; G
Cybersecurity Riser Diagram ; G
SECTION 25 05 11.01 Page 6
SD-03 Product Data
Control System Cybersecurity Documentation ; G
SD-06 Test Reports
Control System Cybersecurity Testing Procedures ; G
Control System Cybersecurity Testing Report ; G
SD-11 Closeout Submittals
Enclosure Keys ; G
Software and Configuration Backups ; G
Auditing Front End Software ; G
Device Audit Record Upload Software ; G
System Maintenance Tool Software ; G
STIG, SRG and Vendor Guide Compliance Result Report ; G
1.6 CYBERSECURITY DOCUMENTATION
1.6.1 Network Communication Report
Provide a network communication report. For each networked device, document the communication characteristics of the device including communication protocols, services used, encryption employed, and a general description of what information is communicated over the network. For each device using IP, document all TCP and UDP ports used. For non-IP communications, document communication protocol and media used. If other control system Sections used on this project include submittals documenting this information, provide copies of those submittals to meet this requirement.
1.6.2 Software and Configuration Backups
For each computer on which software is installed under this project, provide a recovery image of the final as-built computer. This image must allow for bare-metal restore such that restoration of the image is sufficient to restore system operation to the imaged state without the need for re-installation of software. If additional user permissions are required to meet this requirement, coordinate the creation of the image with the identified Government Computer Access Point of Contact.
For all ethernet switches provide a backup of the switch configuration.
For all controllers, provide a backup of the controller configuration and the source code for all loaded application programs (all software that is not common to every controller of the same manufacturer and model).
If any or all of these are provided under another Section, provide documentation indicating this and referencing those submittals.
SECTION 25 05 11.01 Page 7
1.6.3 Cybersecurity Riser Diagram
Provide a cybersecurity riser diagram of the complete control system including all network and device 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.6.4 STIG, SRG and Vendor Guide Compliance Result Report
For every component (device or software) with an applicable STIG or SRG in the Proposed STIG and SRG Applicability Report, provide a result report documenting compliance with the STIG or SRG requirements. For components which are scannable by the SCAP (security content automation protocol) tool (available online at https://public.cyber.mil/stigs/scap ), provide the SCAP report and raw scan results.
For every component (device or software) with manufacturer provided cybersecurity documentation, procedure, or method for secure configuration or installation, provide a report documenting how the component was configured and any deviation from the manufacturer instructions.
1.6.5 Control System Cybersecurity Documentation
Provide a Control System Cybersecurity Documentation submittal containing the indicated information for each device and software application.
1.6.5.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
SECTION 25 05 11.01 Page 8
1.6.5.2 For HVAC Control System Devices
1.6.5.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.6.5.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.6.5.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
SECTION 25 05 11.01 Page 9 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.7 CYBERSECURITY DURING CONSTRUCTION
In addition to the control system cybersecurity requirements indicated in this section, meet following requirement throughout the construction process.
1.7.1 Contractor Computer Equipment
Contractor owned computers may be used for construction. Contractor computers connected to the control system, control system network, or a control system component at any point during construction must meet the following requirements:
1.7.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.7.1.2 Anti-Malware Software
The computer must run anti-malware software from a reputable software manufacturer. Anti-malware software must be a version currently supported by the software manufacturer, must be current on all patches and updates, and must use the latest definitions file. Computers used on this project must be scanned using the installed software at least once per day.
1.7.1.3 Passwords and Passphrases
The passwords and passphrases for computers, applications, and web-based applications supporting passwords must be changed from their default values. Passwords must be a minimum of eight characters with a minimum of one uppercase letter, one lowercase letter, one number and one special character.
1.7.1.4 User-Based Authentication
Each user must have a unique account; sharing of a single account between multiple users is prohibited.
1.7.1.5 Demonstration of Compliance
The Government has the right to require demonstration of computer compliance with these requirements at any time during the project.
SECTION 25 05 11.01 Page 10
1.7.2 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.7.3 Temporary Wireless IP Networks
In addition to the other requirements on temporary IP networks, temporary wireless IP (WiFi) networks, when permitted, must not interfere with existing wireless networks, must use WPA2 security and must not broadcast the network name (SSID). Network names (SSID) for wireless networks must be changed from their default values.
1.7.4 Passwords and Passphrases
The passwords and passphrases for all network devices and network access must be changed from their default values. Passwords must be a minimum 8 characters with a minimum of one uppercase letter, one lowercase letter, one number and one special character.
1.8 CYBERSECURITY DURING WARRANTY PERIOD
All work performed on the control system after acceptance must be performed using Government Furnished Equipment or equipment specifically and individually approved by the Government.
PART 2 PRODUCTS
All products used on this project must meet the indicated requirements, but not all products specified here will be required by every project.
2.1 ETHERNET SWITCH
Provide Open Systems Interconnection (OSI) Layer 2 Ethernet switches with the following capabilities, and with an interface to support switch configuration for these capabilities:
2.1.1 Required Functionality
Switches must:
a. Copper Ethernet ports must auto negotiate for 10, 100 and 1000 megabits-per-second links.
b. Be capable of implementing port level access control by MAC address and limit the number of MAC addresses to one MAC address per port.
c. For LOW Impact Systems, be capable of implementing per-port access control lists (ACLs) where the list can be filtered by source and destination IP addresses, and by source and destination UDP or TCP ports.
2.1.2 Configuration Requirements
Switches must:
a. Support configuration save and restore.
SECTION 25 05 11.01 Page 11
b. Support both manual IP address assignment and acquisition of a dynamic IP address via Dynamic Host Configuration Protocol (DHCP).
c. Be capable of limiting access for configuration to one or more of: a web interface using HTTPS, a command line interface using SSH, or an SNMP connection using SNMP version 3 or later.
2.2 DAISY CHAIN IP CONTROLLERS
Controllers used as Daisy Chain IP Controllers must be IP controllers with exactly two Ethernet network connections and basic built-in switch capabilities to allow implementation of an Ethernet network in a daisy chain architecture. Switches incorporated by Daisy Chain IP Controllers are not required to meet the requirements for Ethernet Switches as defined in this Section.
PART 3 EXECUTION
3.1 CYBERSECURITY HARDENING AND CONFIGURATION GUIDES
Install, configure, and harden all hardware and software furnished on this project in accordance with manufacturer provided documentation, procedures, or methods for secure configuration or installation. Do not implement specific hardening actions if that action would conflict with required functionality or another requirement of this Section.
3.2 NETWORK REQUIREMENTS
3.2.1 Non-IP Control Networks
When control system specifications require particular communication protocols, use only those communication protocols and only as specified.
Do not implement any other communication protocol.
When control system specifications do not indicate requirements for communication protocols, use only those protocols required for operation of the system as specified.
3.2.2 IP Control Networks
IP Networks must be Ethernet networks and must use switches which are Ethernet Switches or Daisy Chain IP Controllers as defined in this Section. Do not use nonsecure functions, ports, protocols and services as defined in DODI 8551.01 unless those ports, protocols and services are specifically required by the control system specifications or otherwise specifically authorized by the Government. Do not use ports, protocols and services that are not specified in the control system specifications or required for operation of the control system.
3.2.3 Cryptographic Protection
All remote user interfaces must use HTTPS for all traffic between the user interface client and user interface server.
3.2.4 Device Identification and Authentication
All computers must support IEEE 802.1x for device authentication to the network.
SECTION 25 05 11.01 Page 12
3.2.4.1 For HVAC Control System Devices
Devices using HTTP as a control protocol must use HTTPS instead. Devices using Ethernet must support IEEE 802.1x . Devices using BACnet must support network security as specified for BACnet Secure Connect in
ASHRAE 135.
3.2.4.2 Default Requirements for Control System Devices
For control system devices where Device Identification and Authentication requirements are not otherwise indicated in this Section: Devices using Ethernet must support IEEE 802.1x . Devices using HTTP as a control protocol must use HTTPS instead.
3.3 ACCESS CONTROL REQUIREMENTS
3.3.1 User Accounts
3.3.1.1 Controllers
3.3.1.1.1 HVAC Control Systems
User Interface Requirements for LOW Impact HVAC Control Systems
User Interface Type Access Control Requirement
Local Read Only (see note 1) None Required
Local Limited, Non-privileged [None Required][ MINIMALLY]
Local Limited, Privileged [ MINIMALLY][Physical Security]
Local Full MINIMALLY
Remote Read Only None Required
Remote Limited, Non-Privileged MINIMALLY
Remote Limited, Privileged
AND
Remote Full (see note 2)
FULLY
Notes:
1)Local Read Only User Interfaces are always Non-Privileged 2)Remote Full User Interfaces are always Privileged
3.3.1.1.2 Default Requirements for Other Control Systems
For control system devices where User Interface Requirements are not otherwise indicated in this Section, use the Default User Interface Requirements tables.
SECTION 25 05 11.01 Page 13
Default User Interface Requirements for LOW Impact Control Systems
User Interface Type Access Control Requirement
Local Read Only (see note 1) [None Required][ MINIMALLY]
Local Limited, Non-privileged [None Required][ MINIMALLY]
Local Limited, Privileged [ MINIMALLY][Physical Security]
Local Full [ MINIMALLY][FULLY]
Remote Read Only [None Required][ MINIMALLY]
Remote Limited, Non-Privileged MINIMALLY
Remote Limited, Privileged
AND
Remote Full (see note 2)
FULLY
Notes:
1)Local Re ad Only User Interfaces are always Non-Privileged 2)Remote Full User Interfaces are always Privileged
Default User Interface Requirements for MODERATE Impact Control Systems
User Interface Type Access Control Requirement (See note 3)
Local Read Only (see note 1) [None Required][ MINIMALLY]
Local Limited, Non-privileged [None Required][ MINIMALLY]
Local Limited, Privileged [ MINIMALLY and Physical Security ][FULLY]
3.3.2 Unsuccessful Logon Attempts
3.3.2.1 Devices MINIMALLY Supporting Accounts
For LOW Impact Systems: Devices which MINIMALLY (but not FULLY) support accounts must lock the user account after five consecutive failed login attempts and must unlock the user account after 15 minutes have elapsed without an unsuccessful login attempt or by a successful login to a separate administrator account.
3.3.2.2 Devices FULLY Supporting Accounts
Devices which FULLY support accounts must meet the following requirements.
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. If the account being locked is the sole administrator account on the device, the account must stay locked for 1 hour and then automatically unlock.
SECTION 25 05 11.01 Page 14
c. Once the indicated number of unsuccessful logon attempts occurs, delay further logon prompts by 5 seconds.
3.3.3 System Use Notification
3.3.3.1 System Use Notification for Remote User Interfaces
Remote user interfaces must display a warning banner meeting the requirements of DTM 08-060 on screen.
3.3.3.2 System Use Notification for Local User Interfaces
Devices which are connected to a network and have a local user interface must display a warning banner meeting the requirements of DTM 08-060 on the user interface screen if capable of doing so and must have a permanently affixed label with an approved banner from DTM 08-060 if unable to display the warning banner on the screen. Where it is impractical (perhaps due to device size) to affix the label to the device, affix the label to the device enclosure.
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 contrast between font and background colors.
3.3.4 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.3.5 Enclosures
Prior to final acceptance of the system, lock all lockable enclosures.
Submit an Enclosure Keys submittal with all copies of keys for all enclosures and a key inventory list documenting all keys. Label each key with the matching enclosure identifier.
3.4 USER IDENTIFICATION AND AUTHENTICATION
This subpart indicates requirements for specific methods of identification and authentication for users and user accounts. Where these requirements conflict apply the following order of precedence: 1) If present, Device Specific Requirements take precedence over any other requirements; and then 2) multifactor authentication requirements take precedence over password requirements.
3.4.1 User Identification and Authentication for All System Types
Unless otherwise indicated, all user interfaces supporting accounts (either FULLY or MINIMALLY) must implement Identification and Authorization via passwords.
For LOW Impact Systems: User interfaces provided by computer operating systems must implement multifactor authentication via PIV.
3.4.2 User Identification and Authentication for Specific System Types
System specific requirements are in addition to and supersede those
SECTION 25 05 11.01 Page 15 indicated for all system types. When no additional requirements are indicated for a specific system type the requirements for all systems still apply to that system type.
3.4.3 Implementation of Identification and Authorization Requirements
Identification and Authorization must be met by one of the following methods:
a. Direct implementation in the user interface.
b. For user interfaces on a computer: inheriting the Identification and Authorization from the computer operating system, either by the operating system limiting access to specific applications by user, or by the application itself having permissions based on the user logged into the computer.
c. For remote interfaces: an implementation shared between the remote user interface server and the remote user interface client. For example, a requirement for PIV authentication may be met on a remote user interface by a PIV reader on a web browser client which sends the authentication information via HTTPS to the remote server.
3.4.4 Password-Based Authentication Requirements
3.4.4.1 Passwords for Software and Applications Running on Computers
All software and applications running on computers supporting password-based authentication must enforce the following requirements:
a. Minimum password length of 12 characters
b. Password must contain at least one uppercase character.
c. Password must contain at least one lowercase character.
d. Password must contain at least one numeric character.
e. Password must contain at least one special character. The list of supported special characters must include at least 4 separate characters.
f. Password must have a minimum lifetime of 24 hours.
g. Password must have a maximum lifetime of 60 days. When passwords expire, prompt users to change passwords. Do not lock accounts due to expired passwords.
h. Password must differ from previous five passwords, where differ is defined as changing at least 50 percent of the characters (where location is significant, a character may be reused if it is in a different position).
i. Passwords must be cryptographically protected during storage and transmission.
3.4.4.2 Passwords for Controllers FULLY Supporting Accounts
All controllers FULLY supporting accounts and supporting password-based
SECTION 25 05 11.01 Page 16 authentication must enforce the following requirements:
a. Minimum password length of twelve (12) characters
b. Password must contain at least one uppercase character.
c. Password must contain at least one lowercase character.
d. Password must contain at least one numeric character.
e. Password must contain at least one special character. The list of supported special characters must include at least 4 separate characters.
f. Password must have a maximum lifetime of sixty (60) days. When passwords expire, prompt users to change passwords. Do not lock accounts due to expired passwords.
g. Password must differ from previous five (5) passwords, where differ is defined as changing at least fifty percent of the characters.
h. Passwords must be cryptographically protected during storage and transmission.
3.4.4.3 Passwords for Remote Interfaces
Passwords for connecting to a Remote User Interface supporting password-based authentication must enforce the following requirements:
a. Minimum password length of twelve (12) characters
b. Password must contain at least one uppercase character.
c. Password must contain at least one lowercase character.
d. Password must contain at least one numeric character.
e. Password must contain at least one special character. The list of supported special characters must include at least 4 separate characters.
f. Password must have a maximum lifetime of 60 days. When passwords expire, prompt users to change passwords. Do not lock accounts due to expired passwords.
g. Password must differ from previous five passwords, where differ is defined as changing at least 50 percent of the characters (where location is significant, a character may be reused if it is in a different position).
h. Passwords must be cryptographically protected during storage and transmission.
3.4.4.4 Passwords for Devices Minimally Supporting Accounts
Devices MINIMALLY supporting accounts must support passwords with a minimum length of four characters.
SECTION 25 05 11.01 Page 17
3.4.5 Authenticator Feedback
Devices must never show authentication information, including passwords, on a display. Devices that momentarily display a character as it is entered, and then obscure the character, are acceptable. For devices that have STIGs or SRGs related to obscuring of authenticator feedback (CCI-000206), comply with the requirements of those STIGS/SRGs.
3.5 CYBERSECURITY AUDITING
Where an auditing requirement exists for email notification, notify via email the application administrator and Information System Security Officer (ISSO) of the event. Coordinate with the Email Address Point of Contact for email addresses. If outgoing email is not available to the system, configure the system for these notifications for future support of outgoing email.
3.5.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.
If auditing requirements can be met using existing control system alarm or event capabilities, those existing capabilities may be used to meet these requirements.
3.5.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.5.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)
b. Successful and unsuccessful logon attempts
c. Successful logouts
d. Privileged activities or other system level access
e. Concurrent logons from different workstations
f. Successful and unsuccessful accesses to objects
g. All program initiations
h. All direct access to the information system
i. All account creations, modifications, disabling, and terminations.
j. All kernel module load, unload, and restart
SECTION 25 05 11.01 Page 18
3.5.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.5.1.2 For HVAC Control System Controllers
3.5.1.2.1 HVAC Control System Controllers FULLY Supporting User Accounts
For each controller which FULLY supports accounts, provide the capability to select audited events and the content of audit logs. Configure controllers to audit the indicated events, and to record the indicated information for each auditable event.
3.5.1.2.1.1 Audited Events
Configure each controller to audit the following events:
a. Successful and unsuccessful logon attempts to the controller
b. Successful logouts
3.5.1.2.1.2 Audit Event Information To Record
Configure each controller 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. the identity of any individuals or subjects associated with the event
3.5.1.2.2 Other HVAC Control System Controllers
There are no requirements to perform auditing at HVAC field controllers that do not FULLY support accounts.
3.5.1.3 For Lighting Control System Controller
3.5.1.3.1 Lighting Control System Controllers FULLY Supporting User Accounts
3.5.1.3.1.1 Audited Events
Configure each controller to audit the following events:
SECTION 25 05 11.01 Page 19
a. Successful and unsuccessful logon attempts to the controller
b. Successful logouts
3.5.1.3.1.2 Audit Event Information To Record
Configure each controller 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. the identity of any individuals or subjects associated with the event
3.5.1.4 Default Requirements for Control System Controllers
For control system controllers where Audit Events, Content of Audit Records, and Audit Generation are not otherwise indicated in this Section:
3.5.1.4.1 Controllers Which FULLY Support Accounts
For each controller which FULLY supports accounts, provide the capability to select audited events and the content of audit logs. Configure controllers to audit the indicated events, and to record the indicated information for each auditable event.
3.5.1.4.1.1 Audited Events
Configure each controller to audit the following events:
a. Successful and unsuccessful attempts to access,…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .