25 05 11.00.pdf

1005 Michael Rd Offce Renovation 210019

SECTION 25 05 11.00

CYBERSECURITY FOR FACILITY-RELATED CONTROL SYSTEMS - ISOLATED SYSTEMS

11/17

PART 1 GENERAL

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

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 http://iase.disa.mil/stigs/Pages/index.aspx . Not all control system components have applicable STIGs or SRGs.

Should any conflict exist between this section and related equipment specifications, the more secure option shall be required and coordinated with Camp Lejeune FRCS Office.

1.1 CONTROL SYSTEM APPLICABILITY

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

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

a. Elevators and Lift Stations (BCS-C/VTS)

b. Electrical Systems (BCS-ES)

c. Other Isolated Control Systems

1.1.1 CONTROL SYSTEM CLASSIFICATION

The C-I-A impact levels for the control system have been determined to be

LOW-LOW-LOW (L-L-L).

1.1.2 INTERCONNECTION

The C/VTS and ES control systems addressed by this specification will have no connection to other systems and function as isolated control systems.

SECTION 25 05 11.00 Page 1

1.2 RELATED REQUIREMENTS

All Sections containing facility-related control systems or control system components are related to the requirements of this Section. Review all specification sections to determine related requirements. Incorporate each of the requirements contained in this specification for systems specified in the following sections:

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

U.S. DEPARTMENT OF DEFENSE (DOD)

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

UFC 4-010-06 (2016; with Change 1, 2017) Cybersecurity of Facility-Related Control Systems

The specification 23 09 23.13 should also be used as an external refernce.

1.4 DEFINITIONS

1.4.1 Computer

As used in this Section, a computer is one of the following:

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

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

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

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

e. a device running a version of Apple iOS

1.4.2 Network Connected

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

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

1.4.3 User Account Support Levels

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

SECTION 25 05 11.00 Page 2

1.4.3.1 FULLY Supported

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

1.4.3.2 MINIMALLY Supported

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

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

1.4.3.3 NOT Supported

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

1.4.4 User Interface

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

1.4.4.1 Limited Local User Interface

A Limited Local User Interface is a user interface where the interaction is limited, fixed at the factory, and cannot be modified in the field.

The user must be physically at the device to interact with it.

Examples of Limited Local User Interface include thermostats.

1.4.4.2 Full Local User Interface

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

Examples of a Full Local User Interface include local applications on a computer .

1.4.4.3 Remote User Interface

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

Examples of Remote User Interfaces include web browsers.

1.4.5 C-I-A Impact Level

A reference to the security objectives of Confidentiality (C), Integrity (I), and Availability (A) associated with a control system. These values

SECTION 25 05 11.00 Page 3 are determined by the System Owner (SO) in conjunction with the Authorizing Official (AO). The potential impact levels for each security objective are LOW (L), MODERATE (M), and HIGH (H).

The determination of control system impact levels is a requirement of

UFC 4-010-06 .

1.4.6 Isolated Field Control Systems

A control system that does not share its signals, data, or telemetry with any system via communications; the system is completely self-contained.

The control system may employ IP and non-IP media and protocols for its own functionality.

1.5 ADMINISTRATIVE REQUIREMENTS

1.5.1 Coordination

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

a. If requesting permission for alternate account lock permissions, the Device Account Lock Exception Request must be approved prior to control system device selection and integration by the Camp Lejeune FRCS Office .

b. Wireless testing may be required as part of the control system testing. See requirements for the Wireless Communication Test Report submittal. c. 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 with the Camp Lejeune FRCS Office .

d. Cybersecurity testing support must be coordinated across control systems and with the project cybersecurity testing schedule.

e. Passwords must be coordinated with the Camp Lejeune FRCS Office .

f . If applicable, HTTP web server certificates must be obtained from the indicated contact for the project site.

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

1.6 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. Architect/Engineer approval is required for submittals marked with an "AE" designation. Submit the following in accordance with Section 01 33 00 SUBMITTAL PROCEDURES:

SD-01 Preconstruction Submittals

Qualifications ; G

SECTION 25 05 11.00 Page 4

Device Account Lock Exception Request ; G

Contractor Computer Cybersecurity Compliance Statements ; G

Contractor Temporary Network Cybersecurity Compliance Statements ; G

SD-02 Shop Drawings

Cybersecurity Riser Diagram ; G

Control System Inventory Report ; G

SD-03 Product Data

Control System Cybersecurity Documentation ; G

SD-06 Test Reports

Wireless Communication Test Report ; G SD-07 Certificates

Software Licenses ; GSD-11 Closeout Submittals

Password Summary Report ; G

Software Recovery And Reconstitution Images ; G

Device Audit Record Upload Software ; G

1.7 QUALITY CONTROL

1.7.1 Qualifications

1.7.1.1 Control System Cybersecurity Subject Matter Expert

The individual will oversee all work within this specification. This position requires that the individual currently meets Information Assurance Manager Level II Certification in accordance with DoDI 8570 Information Workforce Improvement Program.

Individuals for this position should have experience securing Marine Corps systems and with Risk Management Framework. Control System Experience is highly desirable.

Resumes should be submitted to the Government within 14 days after notice to proceed. All certifications to include computing environment must be in effect prior to beginning work.

Control System Cybersecurity Subject Matter Expert can serve across the contract.

1.8 CYBERSECURITY DOCUMENTATION

1.8.1 Cybersecurity Interconnection Schedule

{For Reference Only: This subpart (and its subparts) relates to CA-3(b)}

The control system(s) addressed by this specification will be isolated

SECTION 25 05 11.00 Page 5 unto themselves and do not connect or interface to any other system.

Therefore the contractor will not be required to provide a cybersecurity interconnection schedule.

1.8.2 Control System Inventory Report

{For Reference Only: This subpart (and its subparts) relates to CM-8(a), IA-3}

Provide a Control System Inventory report using the Inventory Spreadsheet listed under this Section at http://www.wbdg.org/ffc/dod/unified-facilities-guide-specifications-ufgs/forms-graphics-tables documenting all devices, including networked devices, network infrastructure devices, non-networked devices, input devices (e.g.

sensors) and output devices (e.g. actuators). For each device provide all applicable information for which there is a field on the spreadsheet in accordance with the instructions on the spreadsheet.

In addition to the requirements of Section 01 33 00 SUBMITTAL PROCEDURES, provide the Control System Inventory Report as an editable Microsoft Excel file.

1.8.3 Software Recovery and Reconstitution Images

For each control system device on which software is configured or installed under this project, provide a recovery image of the final as-built device . 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 Camp Lejeune FRCS Office .

1.8.4 Cybersecurity Riser Diagram

{For Reference Only: This subpart (and its subparts) relates to PL-2(a)}

Provide a cybersecurity riser diagram of the complete control system including all network and controller hardware. If the control system specifications require a riser diagram submittal, provide a copy of that submittal as the cybersecurity riser diagram. Otherwise, provide a riser diagram in one-line format overlayed on a facility schematic.

1.8.5 Control System Cybersecurity Documentation

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

1.8.5.1 Default Requirements for Control System Devices

For control system devices where Control System Cybersecurity Documentation requirements are not otherwise indicated in this Section, provide security baseline documentation (CA-5) using CCIs listed below :

a. Documentation that describes secure configuration of the device {for reference only: relates to CCI-003124}

b. Documentation that describes secure installation of the device {for

SECTION 25 05 11.00 Page 6 reference only: relates to CCI-003125}

c. Documentation that describes secure operation of the device {for reference only: relates to CCI-003124}

d. Documentation that describes effective use and maintenance of security functions or mechanisms for the device {for reference only: relates to

CCI-003127}

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

f. Documentation that describes user-accessible security functions or mechanisms in the device and how to effectively use those security functions or mechanisms {for reference only: relates to CCI-003129}

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

h. Documentation that describes user responsibilities in maintaining the security of the device {for reference only: relates to CCI-003131}

1.8.6 PLAN OF ACTION AND MILESTONES

{For Reference Only: This subpart (and its subparts) relates to CA-5(a), (b)}

Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system.

Update existing plan of action and milestones based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities should be completed by the Government as part of continuous monitoring.

1.8.7 Personnel and Access Agreement

{For Reference Only: This subpart (and its subparts) relates to PS-3, PS-4, PS-5, PS-6}

Screen individuals prior to authorizing access to the system; and

b. Rescreen individuals in accordance with organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of rescreening.

Upon termination of individual employment:

Disable system access within organization-defined time period

Terminate or revoke any authenticators and credentials associated with the individual

Conduct exit interviews that include a discussion of information security topics

Retrieve all security-related organizational system-related property

Retain access to organizational information and systems formerly

SECTION 25 05 11.00 Page 7 controlled by terminated individual

Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization.

Initiate transfer or reassignment actions within organization-defined time period following the formal transfer action. Modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer. Notify personnel or roles within organization-defined time period.

Develop and document access agreements for organizational systems.

Review and update the access agreements. Verify that individuals requiring access to organizational information and systems:

a. Sign appropriate access agreements prior to being granted access

b. Re-sign access agreements to maintain access to organizational systems when access agreements have been updated

1.8.8 Software, Firmware, and Information Integrity

{For Reference Only: This subpart (and its subparts) relates to SI-7}

Employ integrity verification tools to detect unauthorized changes to control system software, firmware, and information. Take appropriate actions determined by the system owner when unauthorized changes to the software, firmware, and information are detected.

1.9 SOFTWARE UPDATE LICENSING

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

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

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

Provide a single Software Licenses submittal with documentation of the software licenses for all software provided

1.10 CYBERSECURITY DURING CONSTRUCTION

{For Reference Only: This subpart (and its subparts) relates to SA-3}

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

1.10.1 Contractor Computer Equipment

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

SECTION 25 05 11.00 Page 8

1.10.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.10.1.2 Anti-Malware Software

The computer must run anti-malware software from a reputable software manufacturer. Anti-malware software must be a version currently supported by the software manufacturer, must be current on all patches and updates, and must use the latest definitions file. All computers used on this project must be scanned using the installed software at least once per day.

1.10.1.3 Passwords and Passphrases

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

1.10.1.4 Contractor Computer Cybersecurity Compliance Statements

Provide a single submittal containing completed Contractor Computer Cybersecurity Compliance Statements for each company using contractor owned computers. Contractor Computer Cybersecurity Compliance Statements must use the template published at http://www.wbdg.org/ffc/dod/unified-facilities-guide-specifications-ufgs/forms-graphics-tables Each Statement must be signed by a cybersecurity representative for the relevant company.

1.10.2 Temporary IP Networks

Temporary contractor-installed IP networks may be used during construction. When used, temporary contractor-installed IP networks must meet the following requirements:

1.10.2.1 Network Boundaries and Connections

The network must not extend outside the project site and must not connect to any IP network other than IP networks provided under this project or Government furnished IP networks provided for this purpose. Any and all network access from outside the project site is prohibited. Unused network access ports are to be disabled via the management console or command line when not in use.

1.10.3 Government Access to Network

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

1.10.4 Temporary Wireless IP Networks

Temporary Wireless connections are not allowed by default. The ISSM may approve wireless connections on a case-by-case basis. In addition to the

SECTION 25 05 11.00 Page 9 other requirements on temporary IP networks, temporary wireless IP (WiFi) networks must not interfere with existing wireless network and must use WPA2 security. Network names (SSID) for wireless networks must be changed from their default values.

According to DoD, USN, USMC policy there is no separation between temp or perm wireless connections.

1.10.5 Passwords and Passphrases

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

1.10.6 Contractor Temporary Network Cybersecurity Compliance Statements

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

1.10.7 Security Impact Analysis

{For Reference Only: This subpart (and its subparts) relates to CM-4}

If a change is being made while the system is being developed this change should first be analyzed to determine potential security and privacy impacts by the contractor prior to change implementation and the findings should be submitted to the Government.

1.10.8 Contingency Plan

{For Reference Only: This subpart (and its subparts) relates to CP-2}

Develop a contingency plan for the system that:

a. Identifies essential mission and business functions and associated contingency requirements

b. Provides recovery objectives, restoration priorities, and metrics

c. Addresses contingency roles, responsibilities, assigned individuals with contact information

d. Addresses maintaining essential mission and business functions despite a system disruption, compromise, or failure

e. Addresses eventual, full system restoration without deterioration of the controls originally planned and implemented

f. Addresses the sharing of contingency information

g. Is reviewed and approved by ISSM

Distribute copies of the contingency plan to ISSM. Coordinate contingency

SECTION 25 05 11.00 Page 10 planning activities with incident handling activities. Review the contingency plan for the system. Update the contingency plan to address changes to the organization, system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing. Communicate contingency plan changes to ISSM. Incorporate lessons learned from contingency plan testing, training, or actual contingency activities into contingency testing and training. Protect the contingency plan from unauthorized disclosure and modification.

1.11 CYBERSECURITY DURING WARRANTY PERIOD

All work performed on the control system after acceptance must be performed using Government Furnished Equipment . Access to systems and changes must be coordinated through Camp Lejeune FRCS Office and follow established change management procedures.

PART 2 PRODUCTS

(NOT USED)

PART 3 EXECUTION

3.1 ACCESS CONTROL REQUIREMENTS

3.1.1 User Accounts

{For Reference Only: This subpart (and its subparts) relate to AC-2(a)and

AC-3}

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

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

3.1.1.1 C/VTS and ES Control System Devices

a. Devices with full local user interfaces allowing modification of data must at least MINIMALLY support user accounts.

b. Devices with read-only full local user interfaces must at least MINIMALLY support user accounts.

3.1.1.2 Default Requirements for Control System Devices

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

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

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

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

SECTION 25 05 11.00 Page 11

3.1.2 Unsuccessful Logon Attempts

{For Reference Only: This subpart (and its subparts) relate AC-7 (a), AC-7 (b); CCI-000043, CCI-000044, CCI-001423, CCI-002236, CCI-002237, CCI-002238}

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

3.1.2.1 Devices MINIMALLY Supporting Accounts

Devices which MINIMALLY support accounts are not required to lock based on unsuccessful logon attempts.

3.1.2.2 Devices FULLY Supporting Accounts

Devices which FULLY support accounts must meet the following requirements. If a device cannot meet these requirements, document device capabilities to protect from subsequent unsuccessful logon attempts and propose alternate protections in a Device Account Lock Exception Request submittal. Do not implement alternate protection measures without explicit permission from the Camp Lejeune FRCS Office .

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

3.1.3 Wireless Access

Wireless networking is not authorized for this project as a default. D o not use any wireless communication unless approved by the ISSM which is done on a case-by-case basis . Any device with wireless communication capability is considered to be using wireless communication, regardless of whether or not the device is actively communicating wirelessly, except when wireless communication has been physically permanently disabled (such as through the removal of the wireless transceiver).

Wireless connections must follow all DoD, USN, and USMC requirements and be approved by the PWD ISSM.

3.1.3.1 Wireless IP Communications

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

3.1.3.2 Non-IP Wireless Communication

Non-IP Wireless networking is not authorized for this project.

3.1.3.3 Wireless Communication Testing

As part of Performance Verification Testing (PVT), conduct testing of wireless communication for all devices indicated on the approved Wireless Communication Request as requiring testing.

To test wireless communication, test for wireless network reception at multiple points along the wireless test boundary in the vicinity of the

SECTION 25 05 11.00 Page 12 wireless device, and record whether a network connection can be established at each point. The wireless test boundary is the building exterior walls. If wireless testing is required, provide a Wireless Communication Test Report documenting the testing points and results at each point for each wireless device. 3.1.4 Physical Access Authorizations and Control {For Reference Only: This subpart (and its subparts) relates to PE-2, PE-3}

Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides. Issue authorization credentials for facility access. Review the access list detailing authorized facility access by individuals at organization-defined frequency. Remove individuals from the facility access list when access is no longer required.

Enforce physical access authorizations at entry and exit points to the facility where the system resides by:

a. Verifying individual access authorizations before granting access to the facility

b. Controlling ingress and egress to the facility using physical access control systems or devices

Maintain physical access audit logs for entry or exit points. Control access to areas within the facility designated as publicly accessible by implementing the appropriate controls. Escort visitors and control visitor activity for organization-defined circumstnaces. Secure keys, combinations, and other physical access devices. Inventory physical access devices at organization-defined frequency. Change combinations and keys at organization-defined frequency and/or when keys are lost, combinations are compromised, or when individuals possessing the keys or combinations are transferred or terminated.

3.2 CYBERSECURITY AUDITING

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

{For Reference Only: This subpart (and its subparts) relates to AU-2(a),(c),(d), AU-3}

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

3.2.1.1 Default Requirements for Control System Devices

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

3.2.1.1.1 Devices Which FULLY Support Accounts

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

SECTION 25 05 11.00 Page 13

3.2.1.1.1.1 Audited Events

Configure each device to audit the following events:

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

a. Successful and unsuccessful logon attempts

b. Privileged activities or other system level access

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

d. Concurrent logons from different workstations

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

f. All kernel module load, unload, and restart

3.2.1.1.1.2 Audit Event Information To Record

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

a. what type of event occurred

b. when the event occurred

c. where the event occurred

d. the source of the event

e. the outcome of the event

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

3.2.1.1.2 Devices Which Do Not FULLY Support Accounts

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

3.2.2 Audit Storage Capacity and Audit Upload

{For Reference Only: This subpart (and its subparts) relates to AU-4;

CCI-001848, CCI-001849}

a. For devices that have STIG/SRGs related to audit storage capacity (CCI-001848 or CCI-001849) comply with the requirements of those STIG/SRGs.

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

3.2.2.1 Device Audit Record Upload Software

For each non-computer device required to audit events, provide, and

SECTION 25 05 11.00 Page 14 license to the Camp Lejeune FRCS Office , software implementing a secure mechanism of uploading audit records from the device to a computer and of exporting the uploaded audit records as a Microsoft Excel file or comma separated value text file. Where different devices use different software, provide software of each type required to upload audit logs from all devices.

Submit copies of device audit record upload software. If there are no non-computer devices requiring auditing, provide a document stating this in lieu of this submittal.

3.2.3 Time Stamps

3.2.3.1 C/VTS and ES Control System Devices

Devices generating audit records must have internal clocks capable of providing time with a resolution of 1 second. Clocks cannot drift more than 10 seconds per day. Configure the system so that each device generating audit records maintains accurate time to within 1 second.

3.2.3.2 Default Requirements for Control System Devices

For control system devices where Time Stamps requirements are not otherwise indicated in this Section: Devices generating audit records must have internal clocks capable of providing time with a resolution of 1 second. Clocks must not drift more than 10 seconds per day. Configure the system so that each device generating audit records maintains accurate time to within 1 second.

3.3 REQUIREMENTS FOR LEAST FUNCTIONALITY

{For Reference Only: This subpart (and its subparts), along with the network communication report submittal specified elsewhere in this section, relates to CM-7, CM-7 (1)(b)}

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

Do not provide devices with user interfaces where one was not required.

Do not use a networked sensor or actuator where a non-networked sensor or actuator would suffice.

3.3.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, or use any protocol on ports other than those specified.

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

SECTION 25 05 11.00 Page 15

3.3.1.1 Allowable Non-IP Control Protocols

3.3.1.1.1 Serial RS-232 and USB

For device configuration and troubleshooting only. That are allowable in a point-to-point configuration only.

3.3.2 IP Control Networks

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 Camp Lejeune FRCS Office . 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.3.3 Unspecified Protocol Approval

When unspecified communicaitions protocols are required for proper system operation submit to the Camp Lejeune FRCS Office for approval the protocol, port number if IP based, functional requirement, and cybersecurity conformance.

3.4 IDENTIFICATION AND AUTHENTICATION

3.4.1 User Identification and Authentication

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

IA-2,(1),(12) , IA-4 }

a. Devices that FULLY support accounts must uniquely identify and authenticate organizational users.

b. Devices which allow network access to privileged accounts must implement multifactor authentication for network access to privileged accounts.

3.4.1.1 C/VTS and ES Control System Devices

Isolated systems are not required to authenticate using Personal Identity Verification (PIV) credentials.

3.4.1.2 Default Requirements for Control System Devices

For control system devices where User Identification and Authentication requirements are not otherwise indicated in this Section, User Identification and Authentication for network access to privileged accounts must be implemented by accepting and electronically verify Personal Identity Verification (PIV) credentialsorinheriting identification and authentication from the operating system.

3.4.2 Authenticator Management

{For Reference Only: This subpart (and its subparts) relates to IA-5 (b),(c),(e),(g),(1),(11)}

SECTION 25 05 11.00 Page 16

3.4.2.1 Authentication Type

3.4.2.1.1 C/VTS and ES Control System Devices

Unless otherwise indicated:

a. Devices MINIMALLY supporting accounts must use password-based authentication.

3.4.2.1.2 Default Requirements for Control System Devices

For control system devices where Authentication Type requirements are not otherwise indicated in this Section:

a. Software which FULLY supports accounts and which runs on a computer must use password-based authentication or hardware token-based authentication.

b. Other devices which FULLY support accounts must use either password-based authentication or hardware token-based authentication.

c. Devices MINIMALLY supporting accounts must use either password-based authentication or hardware token-based authentication.

3.4.2.2 Password-Based Authentication Requirements

3.4.2.2.1 Passwords for Non-Computer Devices FULLY Supporting Accounts

All non-computer devices FULLY supporting accounts and supporting password-based authentication must enforce the following requirements:

a. Minimum password length of fifteen (15) ) characters

b. Password must contain at least one (1) uppercase character.

c. Password must contain at least one (1) lowercase character.

d. Password must contain at least one (1) numeric character.

e. Password must contain at least one (1) special character.

f. Password must have a maximum lifetime of sixty (60) days. When passwords expire, prompt users to change passwords. Do no lock accounts due to expired passwords.

g. Passwords must be cryptographically protected during storage and transmission.

3.4.2.2.2 Passwords for Devices Minimally Supporting Accounts

Devices minimally supporting accounts must support passwords with a minimum length of four (4) characters.

3.4.2.2.3 Password Configuration and Reporting

For all devices with a password, change the password from the default password. Coordinate selection of passwords with the Camp Lejeune FRCS Office . Do not use the same password for more than one device unless specifically instructed to do so. Provide a Password Summary Report

SECTION 25 05 11.00 Page 17 documenting the password for each device and describing the procedure to change the password for each device.

Do not provide the Password Summary Report in electronic format. Provide two hardcopies of the Password Summary Report, each copy in its own sealed envelope.

3.4.2.3 Hardware Token-Based Authentication Requirements

Devices supporting hardware token-based authentication must use Personal Identity Verification (PIV) credentials for the hardware token.

3.4.3 Device Identification and Authentication

{For Reference Only: This subpart (and its subparts) relates to IA-3}

3.4.3.1 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 HTTP as a control protocol must use HTTPS using a web server certificate obtained from the Government Trusted Agent instead.

3.4.4 Cryptographic Module Authentication

{For Reference Only: This subpart (and its subparts) relates to IA-7}

For devices that have STIG/SRGs related to cryptographic module authentication, comply with the requirements of those STIG/SRGs. At a minimum the contractor must use FIPS 140-2 VALIDATED cryptographic modules and be approved by the ISSM.

3.5 DURABILITY TO VULNERABILITY SCANNING

{For Reference Only: This subpart (and its subparts) relates to RA-5 (a),(b),(c),(d)}

All IP devices must be scannable, such that the device can be scanned by industry standard IP network scanning utilities without harm to the device, application, or functionality.

For control system devices other than computers:

3.5.1 C/VTS and ES Control System Devices Other Than Computers

Elevator and electrical control system devices other than computers are not required to respond to scans.

3.5.2 Default Requirements for Control System Devices

Non-computer control system devices where Durability to Vulnerability Scanning requirements are not otherwise indicated in this Section are not required to respond to scans.

SECTION 25 05 11.00 Page 18

3.6 SYSTEM AND COMMUNICATION PROTECTION

3.6.1 Denial of Service Protection, Process Isolation and Boundary Protection

{For Reference Only: This subpart (and its subparts) relates to SC-5}

To the greatest extent practical, implement control logic in non-computer hardware and without reliance on the network.

3.7 FIELD QUALITY CONTROL

3.7.1 Tests

In addition to testing and testing support required by other Sections, provide a minimum of eight (8) hours of technical support for cybersecurity testing of control systems.

-- End of Section --

SECTION 25 05 11.00 Page 19

1.11 CYBERSECURITY DURING WARRANTY PERIOD

3.1.4 Physical Access Authorizations

3.2.1.1.2 Devices Which Do Not FULLY Support Accounts

3.4.2.3 Hardware Token-Based Authentication Requirements

3.4.4 Cryptographic Module Authentication