Attachment F - Compliance Matrix.xlsx
XLSX spreadsheet 36 KB Posted
- Solicitation number
- 70Z02320RAPB02300
About this file
This document outlines requirements for a Communication Management System (CMS) to be provided to the U.S. Coast Guard. The CMS must include a Red Switching System for classified traffic, a Black Switching System for unclassified traffic, Common End-User Terminals, and Communication Management Software. Together these will provide point-to-point connections for information flow between radios, modems, cryptographic equipment, and user terminals aboard U.S. Coast Guard Polar Security Cutters. The CMS will also remotely manage Exterior Communication System radios. The document specifies detailed technical and operational requirements for each CMS component and the system as a whole. It also establishes cybersecurity, networking, and other standards the CMS must meet to ensure compatibility with Coast Guard systems and compliance with applicable policies.
View the file
Other files
Show all 30
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
Sheet1
0.1 Polar Security Cutter
Communication Management System Technical Specification Compliance Matrix Offeror's Name Responses aren't required for rows that are shaded.
| Sort Column | Requirement | Complies with Technical Requirement | Does Not Comply with Technical Requirement | Offeror Comments, if any |
| 1 | 3. CMS TECHNICAL REQUIREMENTS. | |||
| 2 | 3.1. General. | |||
| 3 | 3.1.1. Human Factors Engineering. | |||
| 4 | 3.1.1.1. Reserved | |||
| 5 | 3.1.2. Reliability | |||
| 6 | 3.1.2.1. Reserved | |||
| 7 | 3.1.3. Physical Rack Requirements. | |||
| 8 | 3.1.3.1. All equipment, excepting the CEUTs, shall be mountable into an Electronic Industries Alliance (EIA) standard rack. | |||
| 9 | 3.2. Red and Black Switching System. | |||
| 10 | 3.2.1. The XCS shall have a Red Switching system for classified traffic and a Black Switching system for unclassified traffic; that provide point-to-point connections for information flow between radios, modems, cryptographic equipment, processing, and user terminals. | |||
| 11 | 3.2.2. The XCS Black Switching system shall establish interconnections of voice between Internal Voice Network equipment and XCS cryptographic equipment and radios | |||
| 12 | 3.2.3. The XCS Red and Black Switching System shall convert non-Voice over IP (VoIP) voice radio outputs to IP-based voice transmission formats. | |||
| 13 | 3.2.4. The RED and BLACK Switching System shall contain processors for hosting the Communications Management Software. | |||
| 16 | 3.2.5. The XCS Red Switching System shall have a Gigabit Ethernet interface for outputting IP- based voice protocols via an 802.3 Gigabit Ethernet connection to the Cutter’s CLASSLAN. | |||
| 17 | 3.2.6. The XCS Black Switching System shall have a Gigabit Ethernet interface for outputting IP- based voice protocols via an 802.3 Gigabit Ethernet to the Cutter’s UNCLASSLAN. | |||
| 18 | 3.2.7. Black Switches shall provide for at least 30 connections (total) for the following radio or equipment types: | |||
| 19 | 3.2.7.1. VHF - FM Tactical | |||
| 20 | 3.2.7.2. HF | |||
| 21 | 3.2.7.3. VHF - Amplitude Modulation (AM) | |||
| 22 | 3.2.7.4. Military UHF SATCOM | |||
| 23 | 3.2.7.5. Military UHF LOS | |||
| 24 | 3.2.7.6. Tactical UHF 400 MHz | |||
| 25 | 3.2.7.7. Tactical UHF 700/800 MHz | |||
| 26 | 3.2.7.8. Cryptologic equipment | |||
| 27 | 3.2.8. The Red and Black Switching System shall comply with Type 1 MIL-STD-167-1A vibration. | |||
| 28 | 3.2.9. Common End User Terminals. | |||
| 29 | 3.2.9.1. The CEUT shall serve as a terminal for voice communications aboard ship. | |||
| 30 | 3.2.9.2. The CEUTs shall interface with the Internal Voice Network for connectivity to the shipboard announcing systems, ships alarms, telephones, sound powered phones, and the STCS. | |||
| 31 | 3.2.9.3. The CEUT shall interface with the UNCLASSLAN and CLASSLAN for connectivity to the XCS audio channels that the terminal is authorized for connection. | |||
| 32 | 3.2.9.4. Radio Channel Monitoring. The CEUT shall be able to shall interface with the UNCLASSLAN and CLASSLAN for connectivity to receive any XCS audio channel that the terminal is authorized for connection. | |||
| 33 | 3.2.9.5. There shall be 30 CEUTs provided for the UNCLASSLAN. | |||
| 34 | 3.2.9.6. There shall be 3 CEUTs provided for the CLASSLAN. | |||
| 35 | 3.2.9.7. The CEUT shall be configured by the Communications Management Software. | |||
| 36 | 3.2.9.8. The CEUTs shall interface with the Communications Management Software through the Ship’s Networks. | |||
| 37 | 3.2.9.9. The CEUT shall be capable of connecting to both classified and unclassified networks at the same time. | |||
| 38 | 3.2.9.9.1. The Red CEUT shall be able to transmit and receive on classified networks. | |||
| 39 | 3.2.9.9.2. The Black CEUT shall be able to transmit and receive on unclassified networks. | |||
| 40 | 3.2.9.9.3. The CEUT shall operate in accordance with CNSSAM TEMPEST 01/13 Red and Black Installation Guidance. | |||
| 41 | 3.2.9.10. The CEUT shall capable of assigning any of its audio channels to an Assignable Loudspeaker. | |||
| 42 | 3.2.9.10.1. The CEUT shall be able to assign classified audio channels to classified assignable speakers, and unclassified audio channels to unclassified speakers. | |||
| 43 | 3.2.9.10.2. The CEUT shall not allow the operator to assign classified audio channels to unclassified speakers. | |||
| 44 | 3.2.9.10.3. The CEUT shall not allow the operator to assign unclassified audio channels to classified speakers. | |||
| 45 | 3.2.9.10.3.1. The CEUTs shall allow activating groups of the loudspeakers. | |||
| 46 | 3.2.9.10.3.1.1. The groups shall be labeled TOPSIDE, CREW, ENGINEERING SPACES, COMMAND AND CONTROL, and LOUDHAILER 6MC, respectively. | |||
| 47 | 3.2.9.10.3.2. Loudspeaker groups, group names, and assigned speakers shall be configurable. Reconfiguration of loudspeaker groups shall be via the Communications Management Software. | |||
| 48 | 3.2.9.10.4. CEUTs shall provide for independent or simultaneous operation of the designated speaker groups except for the loudhailer. | |||
| 49 | 3.2.9.11. The 1MC announcing circuit shall be accessible from any CEUT. | |||
| 50 | 3.2.9.12. The alarms shall be able to be activated from any CEUT. | |||
| 51 | 3.2.9.12.1. The CEUT shall be able to activate the General alarm, Chemical alarm, Collision alarm and Flight Crash alarm via the 1MC. | |||
| 52 | 3.2.9.13. The CEUT shall be capable of transmitting and receiving over sound powered telephone circuits via the Internal Voice Network. | |||
| 53 | 3.2.9.14. CEUT XCS Radio Interfaces. | |||
| 54 | 3.2.9.14.1. Each CEUT shall be capable of configuring and monitoring radio circuits. | |||
| 55 | 3.2.9.14.2. The CEUT shall be able to transmit over any XCS audio channel that it is authorized to connect to. | |||
| 56 | 3.2.9.14.3. Reserved | |||
| 57 | 3.2.9.14.4. The CEUT shall be able to monitor at least 10 XCS audio channels simultaneously. | |||
| 58 | 3.2.9.14.5. The CEUT shall be able to transmit and receive over the XCS HF radios. | |||
| 59 | 3.2.9.14.5.1. The CEUT shall be able to control the XCS HF radios. | |||
| 60 | 3.2.9.15. The CEUT shall be able to transmit and receive over the XCS VHF FM Tactical transceivers. | |||
| 61 | 3.2.9.15.1. The CEUT shall be able to control the XCS VHF FM Tactical transceivers. | |||
| 62 | 3.2.9.16. The CEUT shall be able to transmit and receive over the XCS VHF AM radio. 3.2.9.17.1.The CEUT shall be able to control the XCS VHF AM radio. | |||
| 63 | 3.2.9.17. The CEUT shall be able to transmit and receive over the XCS Tactical UHF 400 MHz transceivers. | |||
| 64 | 3.2.9.17.1. The CEUT shall be able to control the XCS Tactical UHF 400 MHz transceivers. | |||
| 65 | 3.2.9.18. The CEUT shall be able to transmit and receive over the XCS Tactical UHF 700/800 MHz transceivers. | |||
| 66 | 3.2.9.18.1. The CEUT shall be able to control the XCS Tactical UHF 700/800 MHz transceivers. | |||
| 67 | 3.2.9.19. The CEUT shall be able to transmit and receive over the XCS MIL UHF LOS radios. | |||
| 68 | 3.2.9.19.1. The CEUT shall be able to control the XCS MIL UHF LOS radios. | |||
| 69 | 3.2.9.20. The CEUT shall be able to transmit and receive over the XCS UHF MILSATCOM radios. | |||
| 70 | 3.2.9.20.1. The CEUT shall be able to control the XCS UHF MILSATCOM radios. | |||
| 71 | 3.2.9.21. The CEUT shall be able operate a radio’s squelch control remotely if the radio provides the feature. | |||
| 72 | 3.2.9.22. The CEUT shall have a volume control for the audio at the organic speaker or connected handset. | |||
| 73 | 3.2.9.23. The CEUT shall be configurable to monitor multiple (up to ten active) radio circuits simultaneously with less than 2 user actions for each radio circuit. | |||
| 74 | 3.2.9.24. The CEUT shall be capable of monitoring and controlling radio circuits simultaneously with less than two user actions. | |||
| 75 | 3.2.9.25. The CEUT shall have the requisite cross talk isolation (red/black) US Navy certification to control CLASSIFIED (secure) and UNCLASSIFIED (non-secure) radio circuits simultaneously in accordance with CNSSAM TEMPEST 01/13 Red/Black Installation Guidance. | |||
| 76 | 3.2.9.26. CEUT HMI Features | |||
| 77 | 3.2.9.26.1. Reserved | |||
| 78 | 3.2.9.26.2. The CEUT shall have either a touch panel or lighted key switches to select circuits and/or CEUT operations. | |||
| 79 | 3.2.9.26.3. The CEUT operator controls shall be operable by a gloved hand. | |||
| 80 | 3.2.9.26.4. The CEUT shall support operation and simultaneous monitoring by supervisor via a separate supervisor handset/headset. | |||
| 81 | 3.2.9.26.5. The CEUT shall have a foot switch jack for the Push to Talk (PTT) function. | |||
| 82 | 3.2.9.26.6. The CEUT shall have a PTT function in each handset/headset jack. | |||
| 83 | 3.2.9.26.6.1. The CEUT shall have remote side tone control for the selected controlled radio circuit. | |||
| 84 | 3.2.9.26.7. The CEUT shall have an internal speaker capable of audio volume from 0 decibels to 85 decibels. | |||
| 85 | 3.2.9.26.7.1. The CEUT shall have audio volume controls for each ear of the headset. | |||
| 86 | 3.2.9.26.7.2. The CEUT shall have audio volume controls for the internal speaker and assigned external speakers. | |||
| 87 | 3.2.9.26.8. The CEUT shall have a prominent visual indicator when a CLASSIFIED or UNCLASSIFIED circuit has been selected to operate. | |||
| 88 | 3.2.9.26.9. The CEUT’s visual display shall be readable from four (4) feet or the distance of the operator(s) using a corded handset or headset whichever is longer. | |||
| 89 | 3.2.9.26.10. The CEUT’s visual display brightness shall be adjustable by the operator. | |||
| 90 | 3.2.9.26.10.1. The screen brightness shall be adjustable to zero. | |||
| 91 | 3.2.9.26.10.2. The screen brightness control shall be via a physical control. | |||
| 92 | 3.2.9.26.11. The CEUT’s visual display shall be readable under different ambient light conditions from total darkness to bright sunlight. | |||
| 93 | 3.2.9.27. CEUT Physical Characteristics | |||
| 94 | 3.2.9.27.1. The CEUT shall have a compact size no greater than 12” high, 12” wide, and 8” deep. | |||
| 95 | 3.2.9.27.2. The basic CEUT enclosure shall be operable in relative humidity conditions of 0-95%, non-condensing. | |||
| 96 | 3.2.9.27.3. The CEUT shall be drip proof in accordance with MIL-DTL-2036E.Reserved | |||
| 97 | 3.2.9.27.4. The CEUT shall be operable in temperatures ranging from – 15 degrees Fahrenheit to +95 degrees Fahrenheit. This requirement may be met by an enclosure that mitigates the CEUT exposure to the environmental extremes. | |||
| 98 | 3.2.9.27.5. Reserved. | |||
| 99 | 3.2.9.27.6. The CEUT shall be configurable through Original Equipment Manufacturer (OEM) supplied accessories/kits for console mounting, bulkhead mounting, and for weather deck bulkhead mounting or in a watertight enclosure per the National Electrical Manufacturers Association (NEMA) publication NEMA 250-2014. | |||
| 100 | 3.2.9.27.7. The CEUT shall be powered by 24 Volt Direct Current (VDC). | |||
| 101 | 3.2.9.27.7.1. The CEUT shall comply with Type 1 MIL-STD-167-1 vibration. | |||
| 102 | 3.2.9.27.7.2. The CEUT shall comply with MIL-STD-461 for conducted and radiated susceptibility to electronic emissions. | |||
| 103 | 3.2.9.27.8. Computer-aided alarm activation interfaces shall consist of individual single- action operator controls to trigger and secure General Announcing (GA) alarm announcements, except the General alarm. | |||
| 104 | 3.2.9.27.9. The General alarm shall have a single-action operator control for alarm activation and automatically secure 15 seconds after activation. | |||
| 105 | 3.2.9.27.10. Computer-aided alarm activation interfaces shall prominently display each GA alarm. | |||
| 106 | 3.2.9.27.11. Alarm activation shall not exceed three discreet operator actions. | |||
| 107 | 3.2.9.27.12. The CEUTs shall provide GA alarm controls distinguishable and operational under dark space conditions. | |||
| 108 | 3.3. Software. | |||
| 109 | 3.3.1. Communications Management Software. | |||
| 110 | 3.3.1.1.1. The CMS shall have software applications to provide control of the XCS radios, the RED switching system, the BLACK Switching System, the CEUTs, and the Internal Voice Network. The control of the Internal Voice Network can use a compatible third party application. | |||
| 111 | 3.3.1.2. The Communications Management Software shall be user accessible from at least 15 distinct workstations that run Microsoft Windows 10. | |||
| 112 | 3.3.1.3. The Communications Management Software shall be simultaneously user accessible from at least 5 user workstations. | |||
| 113 | 3.3.1.4. User Accounts. | |||
| 114 | 3.3.1.4.1. User Accounts on the Communications Management Software shall have full access to the control and monitoring capabilities of the CMS | |||
| 115 | 3.3.1.4.2. User Accounts shall be unique to each user. | |||
| 116 | 3.3.1.4.3. User logins shall require two-factor authentication, utilizing Department of Defense (DOD) Public Key Infrastructure (PKI) with Common Access Cards (CACs). This may be accomplished in conjunction with the middleware software and certificates that DOD and the USCG currently use on their information systems. Login to the baseline Operating System via Two Factor Authentication shall not be considered acceptable credentials. | |||
| 117 | 3.3.1.5. The Communications Management Software shall allow only one workstation and one user to be in control at any given time. | |||
| 118 | 3.3.1.6. The Communications Management Software shall interface with the Internal Voice Network | |||
| 119 | 3.3.1.7. The Communications Management Software and CEUT shall allow for provisioning of phone numbers to CEUTs from the Internal Voice Network. | |||
| 120 | 3.3.1.8. The Communications Management Software shall direct the Black Switching System to provide Internal Voice Network access to unclassified radio voice channels. | |||
| 121 | 3.3.1.9. The Communications Management Software shall direct the Black Switching System to provide authorized CEUTs with access to unclassified radio voice channels. | |||
| 122 | 3.3.1.10. The Communications Management Software shall direct the Red Switching System to provide authorized CEUTs with access to classified radio voice channels. | |||
| 123 | 3.3.1.11. The Communications Management Software shall be capable of remotely configuring, managing, and monitoring the performance of XCS HF radios to the extent implemented in the radio’s remote-control features by its OEM. | |||
| 124 | 3.3.1.11.1. This shall include frequency selection, channel selection, output power, bandwidth, voice/data mode, modulation type, transmit inhibit, Automatic Link Establishment (ALE), radio performance (health) and squelch control. | |||
| 125 | 3.3.1.12. The Communications Management Software shall be capable of remotely configuring, managing, and monitoring the performance of XCS VHF FM radios to the extent implemented in the radio’s remote-control features by its OEM. | |||
| 126 | 3.3.1.12.1. This shall include frequency selection, channel selection, output power, modulation type, transmit inhibit, radio performance (health) and squelch control. | |||
| 127 | 3.3.1.13. The Communications Management Software shall be capable of remotely configuring, managing, and monitoring the performance of XCS UHF MILSATCOM radios to the extent implemented in the radio’s remote-control features by its OEM. | |||
| 128 | 3.3.1.13.1. This shall include frequency selection, channel selection, output power, bandwidth, voice/data mode, modulation type, DAMA configuration, transmit inhibit, encryption key selection, encryption zeroization, and radio performance (health). | |||
| 129 | 3.3.1.14. The Communications Management Software shall be capable of remotely configuring, managing, and monitoring the performance of XCS UHF LOS radios to the extent implemented in the radio’s remote-control features by its OEM. | |||
| 130 | 3.3.1.14.1. This shall include frequency selection, channel selection, output power, bandwidth, modulation type, transmit inhibit, encryption key selection, encryption zeroization, radio performance (health) and squelch control. | |||
| 131 | 3.3.1.15. The Communications Management Software shall be capable of remotely configuring, managing, and monitoring the performance of XCS VHF AM radios to the extent implemented in the radio’s remote-control features by its OEM. | |||
| 132 | 3.3.1.15.1. This shall include frequency selection, channel selection, output power, bandwidth, modulation type, transmit inhibit, radio performance (health) and squelch control. | |||
| 133 | 3.3.1.16. The Communications Management Software shall be capable of remotely configuring, managing, and monitoring the performance of XCS Tactical UHF 400 | |||
| 134 | 3.3.1.16.1. MHz radios to the extent implemented in the radio’s remote-control features by its OEM. | |||
| 135 | 3.3.1.16.2. This shall include frequency selection, channel selection, output power, bandwidth, modulation type, transmit inhibit, encryption key selection, encryption zeroization, radio performance (health) and squelch control. | |||
| 136 | 3.3.1.17. The Communications Management Software shall be capable of remotely configuring, managing, and monitoring the performance of XCS Tactical UHF 700/800 MHz radios to the extent implemented in the radio’s remote-control features by its OEM. | |||
| 137 | 3.3.1.17.1. This shall include frequency selection, channel selection, output power, bandwidth, modulation type, transmit inhibit, encryption key selection, encryption zeroization, radio performance (health) and squelch control. | |||
| 138 | 3.3.1.18. The Communications Management Software shall be capable of remotely controlling the XCS Switch System | |||
| 139 | 3.3.1.19. The Communications Management Software shall control the Voice Recorders to the extent of remote-control features by its OEM. | |||
| 140 | 3.3.1.20. The Communications Management Software shall configure the Voice Recorders to the extent of remote-control features by its OEM. | |||
| 141 | 3.3.1.21. Reserved. | |||
| 142 | 3.3.1.22. The Communications Management Software shall grant and restrict user access to features and functions based on role. | |||
| 143 | 3.3.1.23. The Communications Management Software shall provide the user with the ability to create Communications Plans, which are the specific configurations of all the XCS radios, Switching System channel assignments, CEUT configurations, and Voice Recorder configurations. | |||
| 144 | 3.3.1.24. The Communications Management Software shall provide the user with the ability to save Communications Plans | |||
| 145 | 3.3.1.25. The Communications Management Software shall provide the user with the ability to edit Communications Plans | |||
| 146 | 3.3.1.26. The Communications Management Software shall provide the user with the ability to delete Communications Plans | |||
| 147 | 3.3.1.27. The Communications Management Software shall provide the user with the ability to archive Communications Plans | |||
| 148 | 3.3.1.28. The Communications Management Software shall provide the user with the ability to restore Communications Plans | |||
| 149 | 3.3.1.29. The Communications Management Software shall provide the user with the ability to activate Communications Plans | |||
| 150 | 3.3.1.30. The Communications Management Software shall provide the user with the ability to save Communications Plans | |||
| 151 | 3.3.1.31. The Communications Management Software shall provide the user with the ability to modify an established circuit in the active Communications Plan | |||
| 152 | 3.3.1.32. The Communications Management Software shall provide the user with the ability to deactivate Communications Plans | |||
| 153 | 3.3.1.33. The Communications Management Software shall provide the user with the ability to display the equipment status (e.g. up, down/failed, off/disabled, and standby) of the XCS in a: | |||
| 154 | 3.3.1.33.1. Single view. | |||
| 155 | 3.3.1.33.2. Hierarchical view (e.g. HF, VHF, UHF). | |||
| 156 | 3.3.1.33.3. Circuit centric view (e.g. links, networks.) | |||
| 157 | 3.3.1.34. The Communications Management Software shall log changes to Communications Plans. | |||
| 158 | 3.3.1.35. The Communications Management Software shall log changes in equipment status. | |||
| 159 | 3.3.1.36. The Communications Management Software log entries shall include a time stamp. | |||
| 160 | 3.3.1.37. The Communications Management Software shall provide frequency management rules to prevent unauthorized or duplicate settings. | |||
| 161 | 3.3.1.38. The Communications Management Software shall monitor the performance (health) of the XCS radios and Communications Management Software major components as implemented by the radio and equipment OEMs. | |||
| 162 | 3.3.1.39. The Communications Management Software shall support IEEE 802.3 communication protocols through the hosting computer/server, and Operating Systems. | |||
| 163 | 3.3.1.39.1. The Communications Management Software HMI shall be user accessible from the Communications Management Software equipment rack(s). | |||
| 164 | 3.3.1.40. The Communications Management Software HMI shall run as an application on top of the operating system. | |||
| 165 | 3.3.1.40.1. The Communications Management Software HMI shall run on the Defense Information System Agency (DISA) Secure Host Baseline (SHB) version of Microsoft® Windows™ 10. | |||
| 166 | 3.3.1.41. Communications Management Software updates shall be capable of being installed in the field by the user. | |||
| 167 | 3.3.1.42. The Communications Management Software shall support reinstallation via third party imaging servers and software. | |||
| 168 | 3.4. Cybersecurity. | |||
| 169 | 3.4.1. This section contains additional requirements for an integrated approach to Cybersecurity and Information Systems Security, Assessment and Authorization (A&A), including applicable standards and policies, general identification of secure areas, personnel security, physical security, TEMPEST and Force Protection. | |||
| 170 | 3.4.2. The CMS shall employ physical, personnel, and procedural security features to provide protection adequate to handle, control, process, and store information utilizing the Risk Management Framework (RMF) defined in DODI 8510.01 for DoD Information Technology (IT). | |||
| 171 | 3.4.3. Definitions | |||
| 172 | 3.4.3.1. Classified Information Processing Systems (CLIPS) - Any system or equipment that processes information at a Collateral or SCI/SAP level. | |||
| 173 | 3.4.3.2. Collateral Information - Information identified as National Security Information (NSI) (CONFIDENTIAL through TOP SECRET information) under the provisions of Executive Order 13526 but which is not subject to enhanced security protection required for Special Access Program (SAP) or other compartmented information. | |||
| 174 | 3.4.3.3. Whitelisting - Methods used to control which devices are allowed to join a network. This term is also used to designate allowed software to be run on systems. | |||
| 175 | 3.4.3.4. Authentication - Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system. | |||
| 176 | 3.4.4. Policies and Standards. | |||
| 177 | 3.4.4.1. The following shall apply: | |||
| 178 | 3.4.4.2. COMDTINST M2241.6 (Series), U.S. Coast Guard TEMPEST Program. | |||
| 179 | 3.4.4.3. COMDTINST M5500.13 (Series), U.S. Coast Guard Security and Information Assurance (SIA) Manual. | |||
| 180 | 3.4.4.4. COMDTINST M5530.1 (Series), Physical Security and Force Protection Program. | |||
| 181 | 3.4.4.5. DoN CIO IA Pub 5239-22 Information Assurance Protected Distribution System. | |||
| 182 | 3.4.4.6. DoN CIO IA Pub 5239-31 Information Assurance Shipboard Red/Black Installation Publication. | |||
| 183 | 3.4.4.7. MIL-HDBK-419 Grounding, Bonding and Shielding for Common Longhaul/Tactical Communications Systems, Including Ground Based Communications-Electronics (C-E) Facilities and Equipment. | |||
| 184 | 3.4.4.8. CNSSAM 01/13 Red/Black Installation Guidance. | |||
| 185 | 3.4.4.9. NSTISSI 7003 Protective Distribution Systems (PDS). | |||
| 186 | 3.4.4.10. DoDI 8510.01 Risk Management Framework (RMF) for DOD Information Technology (IT). | |||
| 187 | 3.4.4.11. NSTISSI 7002 TEMPEST Glossary. | |||
| 188 | 3.4.4.12. Intelligence Community Directive (ICD) 503 Intelligence Community Information Technology Systems Security. | |||
| 189 | 3.4.4.13. Intelligence Community Directive (ICD) 705 Sensitive Compartmented Information Facilities. | |||
| 190 | 3.4.4.14. DOD 5200.08-R DOD PHYSICAL SECURITY PROGRAM. | |||
| 191 | 3.4.4.15. NIST SP 800-53 Rev4, Security and Privacy Controls for Federal Information Systems and Organizations. | |||
| 192 | 3.4.4.16. CJCSI 6211.02 Defense Information Systems Network (DISN) Responsibilities. | |||
| 193 | 3.4.4.17. EKMS-lB, EKMS Policy and Procedures for Navy Electronic Key Management Systems Tiers 2 & 3. | |||
| 194 | 3.4.4.18. DoDI 8540.01 Cross Domain Policy. | |||
| 195 | 3.4.5. The CMS shall be designed to provide only essential capabilities. | |||
| 196 | 3.4.6. The CMS shall use the principle of least privilege, allowing only authorized accesses for users or processes acting on behalf of users which are necessary to accomplish required system functions. | |||
| 197 | 3.4.7. Wireless access shall not be allowed. | |||
| 198 | 3.4.8. Wireless features for system hardware shall be physically and logically disabled. 3.4.9 Access Control. | |||
| 199 | 3.4.8.1. System hosts and network appliances shall be configured to prevent remote access from outside the system boundary. | |||
| 200 | 3.4.8.2. Systems shall provide the capability to uniquely identify and authenticate users. | |||
| 201 | 3.4.8.3. When a user is logged into the systems, a banner shall be displayed at the top of the screen indicating the user's name and role. | |||
| 202 | 3.4.8.4. During system login, the user shall be presented with the terms of use banner and prompted for consent before access is granted. | |||
| 203 | 3.4.8.4.1. The consent banner shall contain the following terms of use: “You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG authorized use only. Unauthorized access to this system is prohibited by Title 18 USC Section 1030. By using this IS (which includes any device attached to this IS), you consent to the following conditions: Information system usage may be monitored, recorded, and subject to audit. Unauthorized use of the information system is prohibited and subject to criminal and civil penalties; and Use of the information system indicates consent to monitoring and recording." | |||
| 204 | 3.4.8.4.2. The Administrator role shall have the ability to modify the terms of use banner. | |||
| 205 | 3.4.8.5. The systems banner shall display a logout message for 30 seconds following a user logout. | |||
| 206 | 3.4.8.6. The system shall lock user sessions after 5 minutes of inactivity. | |||
| 207 | 3.4.8.7. Users shall be logged out after 15 minutes of inactivity. | |||
| 208 | 3.4.8.8. Systems shall invalidate session identifiers upon user logout or other session termination. | |||
| 209 | 3.4.8.9. Systems shall enforce access restrictions and support auditing of the enforcement actions. | |||
| 210 | 3.4.8.10. Systems shall protect audit information from unauthorized access. | |||
| 211 | 3.4.8.11. The System shall provide users with the means to log out. | |||
| 212 | 3.4.8.11.1. When users log out a message confirming the logout shall be displayed. | |||
| 213 | 3.4.8.12. The system shall implement replay-resistant authentication mechanisms for network access to privileged accounts. | |||
| 214 | 3.4.8.13. The systems shall be configured to require multi-factor authentication for account access. | |||
| 215 | 3.4.8.14. Reserved. | |||
| 216 | 3.4.8.15. System hosts and network appliances shall be configured to prevent remote access from outside the system boundary. | |||
| 217 | 3.4.8.16. The Administrator role shall have full administrative rights throughout the host operating system. | |||
| 218 | 3.4.8.17. The system shall limit the number of invalid login attempts to three within a 15 minute period of time. | |||
| 219 | 3.4.8.18. After three invalid login attempts within a 15 minute period, systems shall implement a 5-second pause between login attempts. | |||
| 220 | 3.4.8.19. The system shall generate a unique session identifier for each session, and recognize only system-generated session identifiers. | |||
| 221 | 3.4.9. Account Management. | |||
| 222 | 3.4.9.1. The System shall allow for the creation of Emergency Administrator accounts. | |||
| 223 | 3.4.9.2. Emergency Administrator accounts shall never expire. | |||
| 224 | 3.4.9.3. Emergency Administrator accounts shall never be automatically disabled. | |||
| 225 | 3.4.9.4. Emergency Administrator accounts shall be marked as "Emergency Administrator Account" within the system. | |||
| 226 | 3.4.9.5. The Administrator role shall have the ability to configure the inactivity time period associated with automatically disabling accounts. | |||
| 227 | 3.4.9.6. Systems shall include a configurable password management system. | |||
| 228 | 3.4.9.7. The Administrator role shall be allowed to change password management system configuration settings. | |||
| 229 | 3.4.9.8. The system shall enforce the following default password complexity: | |||
| 230 | 3.4.9.9. Passwords shall be case-sensitive. | |||
| 231 | 3.4.9.9.1. Passwords shall have at least one upper-case letter. | |||
| 232 | 3.4.9.9.2. Passwords shall have at least one lower-case letter. | |||
| 233 | 3.4.9.9.3. Passwords shall have at least one number. | |||
| 234 | 3.4.9.9.4. Passwords shall have at least one special character. | |||
| 235 | 3.4.9.9.5. Password shall have a minimum password length of 15 characters. | |||
| 236 | 3.4.9.10. Systems shall enforce at least eight changed characters when new passwords are created. | |||
| 237 | 3.4.9.10.1. Systems shall be configured to prevent previous password re-use for a specified number of passwords. | |||
| 238 | 3.4.9.10.1.1. The system shall allow only the Administrator role to set the specified number of previous passwords that cannot be re-used. | |||
| 239 | 3.4.9.11. Systems shall require a temporary password to be immediately changed at first login. | |||
| 240 | 3.4.9.12. Systems shall cryptographically protect stored passwords. | |||
| 241 | 3.4.9.13. Systems shall cryptographically protect transmitted passwords. | |||
| 242 | 3.4.9.14. Passwords on system hardware shall be changed from the factory defaults. | |||
| 243 | 3.4.9.15. Unencrypted static authenticators shall not be embedded in applications or access scripts or stored on function keys. | |||
| 244 | 3.4.9.16. Systems shall prohibit the use of cached authenticators. | |||
| 245 | 3.4.9.17. Systems shall obscure feedback of authentication information during the user authentication process to protect the information from possible exploitation. | |||
| 246 | 3.4.10. System Configuration. | |||
| 247 | 3.4.10.1. Software control mechanisms shall be implemented on hosts to ensure only authorized, documented software is installed and/or executed. | |||
| 248 | 3.4.10.2. Systems shall implement whitelisting methods to deny-all, permit-by-exception for system communications and software configuration. | |||
| 249 | 3.4.10.2.1. System network appliances shall be configured to allow only communication required for the operation of the system. | |||
| 250 | 3.4.10.2.2. System hosts shall be configured to only allow communication and processes required for the operation of the system. | |||
| 251 | 3.4.10.3. Systems shall use authorized ports, protocols, and services (PPS) listed in the DoDi 8551.01 referenced Category Assignments List (CAL). DoDI 8551.01. | |||
| 252 | 3.4.10.3.1. Unused ports and services shall be disabled. | |||
| 253 | 3.4.10.4. Systems shall be configured to only use Static IP addresses. | |||
| 254 | 3.4.10.5. IP addresses shall be configurable by the Administrator. | |||
| 255 | 3.4.10.6. Systems shall be configured in accordance with the applicable Security Requirements Guides (SRGs) and Security Technical Implementation Guides (STIGs). | |||
| 256 | 3.4.10.7. Systems shall isolate security functions from non-security functions.Physical ports and input/output devices not required for system operation or maintenance shall be disabled. | |||
| 257 | 3.4.10.8. Unused software on system hardware shall be removed or disabled. | |||
| 258 | 3.4.10.9. Systems shall allow scanning and active monitoring by Defense Information Systems Agency (DISA) Host-Based Security System (HBSS) and by Assured Compliance Assessment Solution (ACAS) software. | |||
| 259 | 3.4.10.9.1. The System shall support these activities both locally from the same host, and remotely from another computing resource on the same network. | |||
| 260 | 3.4.10.10. Systems shall operate in a predictable manner when invalid inputs are received. | |||
| 261 | 3.4.10.11. Any unauthorized attempt to modify system configuration shall generate an alarm or alert. | |||
| 262 | 3.4.11. Verification | |||
| 263 | 3.4.11.1. Systems shall verify the integrity of the boot process of system hosts. | |||
| 264 | 3.4.11.2. Systems shall incorporate integrity verification of software components. | |||
| 265 | 3.4.11.2.1.1. In the event of a failure of a startup integrity check systems shall suspend the startup and display a warning message. | |||
| 266 | 3.4.11.3. The system shall include a means of detecting changes to the configuration baseline that occur in an unauthorized manner. | |||
| 267 | 3.4.11.3.1. Changes to the system baseline configuration shall result in a system alarm or alert, as applicable. | |||
| 268 | 3.4.11.4. Systems shall utilize integrity verification mechanisms to detect changes to host and network firmware components. | |||
| 269 | 3.4.11.4.1. Integrity check failures shall be alarmed. | |||
| 270 | 3.4.11.4.2. Validation shall include, but is not limited to, ensuring that inputs are within expected ranges and are using correct formats. | |||
| 271 | 3.4.12. Auditing | |||
| 272 | 3.4.12.1. The System shall support interfacing to and monitoring by a Security Information Event Management (SIEM) system. | |||
| 273 | 3.4.12.2. System hosts and applicable network appliances shall create audit records that contain event details to include event type, time, location, source, outcome, user and identity of any associated subjects, and additional fields as configured by the ISEA Administrator or Administrator. | |||
| 274 | 3.4.12.3. The systems shall prevent the deletion or alteration of audit log records, with the exception of overwriting old records when storage capacity is reached. | |||
| 275 | 3.4.12.4. The Administrator role shall have access to audit log records. | |||
| 276 | 3.4.12.5. At a minimum, systems shall maintain an audit log that records the following system events: | |||
| 277 | 3.4.12.5.1. Event type, time, location, source, outcome, user and identity of any associated subjects. | |||
| 278 | 3.4.12.5.2. Host operating system account creation, deletion, enabling, disabling, and modification events. | |||
| 279 | 3.4.12.5.3. User account changes. | |||
| 280 | 3.4.12.5.4. Successful and unsuccessful authentication and access attempts. | |||
| 281 | 3.4.12.5.5. Host startup and shutdown. | |||
| 282 | 3.4.12.5.6. Application startup and shutdown. | |||
| 283 | 3.4.12.5.7. Application failures. | |||
| 284 | 3.4.12.5.8. Changes from the qualified/certified baseline configuration, to include software, firmware, and runtime behavior. | |||
| 285 | 3.4.12.5.9. Privileged activities and system level access. | |||
| 286 | 3.4.12.5.10. File or object creation, access, deletion, and modification. | |||
| 287 | 3.4.12.5.11. Import or export of data. | |||
| 288 | 3.4.12.5.12. Events when system host firewall or network Access Control Lists (ACLs) block traffic. | |||
| 289 | 3.4.12.5.13. Integrity check verification failures for system software, firmware, and configuration. | |||
| 290 | 3.4.12.5.14. Any unauthorized attempt to modify system configuration. | |||
| 291 | 3.4.12.6. The audit information stored on systems hardware shall be protected from unauthorized access, deletion, or modification. | |||
| 292 | 3.4.12.7. Systems shall, at a minimum, store 270 days of system audit information. 3.4.15.7.1. When the storage limit is reached, the audit system shall overwrite the oldest information with the new records. | |||
| 293 | 3.4.12.8. Systems shall have the capability to backup audit data onto an external storage device /media in a comma separated values (CSV) format. | |||
| 294 | 3.4.12.8.1. Systems shall provide the capability to specify the date and time range for the data being exported up to including the entire set of available logs. | |||
| 295 | 3.4.12.9. Audit management and configuration of system components shall require an Administrator login, as applicable. | |||
| 296 | 3.4.12.10. The Administrator role shall have the system privileges required to select types of audited events. | |||
| 297 | 3.4.12.11. Host-Based Protection | |||
| 298 | 3.4.12.11.1. Hosts shall have host-based firewall mechanisms that allow only authorized network connections and communications. | |||
| 299 | 3.4.12.11.2. System hosts shall incorporate malicious code protection mechanisms. | |||
| 300 | 3.4.12.11.3. Malicious code protection mechanisms shall have the capability of being updated. | |||
| 301 | 3.4.12.11.4. Hosts shall prevent unauthorized additions, removals, and modifications to the underlying file system and critical files and directories. | |||
| 302 | 3.4.12.11.5. Hosts shall prevent the download of unauthorized mobile code. | |||
| 303 | 3.4.12.11.6. Hosts shall prevent the execution of unauthorized mobile code. | |||
| 304 | 3.4.12.11.7. Hosts shall prevent the automatic execution of mobile code that is not part of the system as designed. | |||
| 305 | 3.4.12.12. Recovery | |||
| 306 | 3.4.12.12.1. The system shall support recovery in the event of a cyber-security event or system failure. | |||
| 307 | 3.4.12.12.1.1. The Administrator role shall have the ability to perform actions required to accomplish system recovery. | |||
| 308 | 3.4.12.12.1.2. The Administrator account role shall have the ability to re-image system software. | |||
| 309 | 3.4.12.12.2. In the event of a loss and subsequent restoration of power, the system shall reboot all hosts and network appliances, restore communications, and take no other automatic actions. | |||
| 310 | 3.4.12.13. Physical Security | |||
| 311 | 3.4.12.13.1. Each of the CMS systems shall have an Administrator account type. | |||
| 312 | 3.4.12.13.2. The systems shall be configured to require multi-factor authentication for Administrator account access. | |||
| 313 | 3.4.12.13.3. Communications between Classified and Unclassified systems shall utilize a validated Cross Domain Solution (CDS) when available and appropriate, such as hosts managed by the Unified Cross Domain Services Management Office described in DoDI 8540.01. | |||
| 314 | 3.4.12.14. Account Management | |||
| 315 | 3.4.12.14.1. The system shall provide for an account management functionality. | |||
| 316 | 3.4.12.15. System Configuration | |||
| 317 | 3.4.12.15.1. The Administrator role shall be allowed to install, update, configure, and remove software. | |||
| 318 | 3.4.12.15.2. The network shall be constructed from components approved on DISA's DoD Information Network (DoDIN) Approved Products List (APL). | |||
| 319 | 3.5. Electromagnetic Environmental Effects (E3). | |||
| 320 | 3.5.1. Definitions | |||
| 321 | 3.5.1.1. Below Deck Areas - Areas in the ship that are surrounded by a metallic structure such as the hull or superstructure. | |||
| 322 | 3.5.1.2. Electromagnetic Environment (EME) - The resulting product of the power and time distribution , in various frequency ranges, of the radiated or conducted electromagnetic emissions levels which may be encountered by a military force, system, or platform in an intended operational environment | |||
| 323 | 3.5.1.3. Electromagnetic Interference (EMI) - Any electromagnetic disturbance which interrupts, obstructs, or otherwise degrades or limits the effective performance of electronics/electrical equipment. It can be induced intentionally, as in some forms of electronic warfare, or unintentionally, as a result of a spurious emissions and responses, intermodulation products, and the like. Additionally, EMI may be caused by atmospheric phenomena, such as lightning and precipitation static and non- telecommunication equipment, such as vehicles and industry machinery. | |||
| 324 | 3.5.1.4. Exposed Below Deck Areas - Areas within the ship that have large openings, which when open expose the equipment and cables in those spaces to the external electromagnetic environment. This can also include spaces that are surrounded by material that does not have at least as much shielding effectiveness as the structure. Examples of these areas may include the Pilothouse, hangar, boat bay, mooring stations, and intakes and uptake trunks. | |||
| 325 | 3.5.1.5. Grounding Effectiveness - The effectiveness of metallic penetrations bonded at the ship's hull to direct currents induced on these penetrations by topside EMI to the ship's ground. These metallic penetrations include pipes, waveguides, cables, and metal tubing. | |||
| 326 | 3.5.1.6. Shield/shielding - A metal barrier of solid, screen, or braid construction used to protect electronic components, wires, or cables from EM energy; or used to reduce the emission of EM energy from components, wires, or cabling. | |||
| 327 | 3.5.1.7. Shield grounding adapter (SGA) - A device that provides 360 degrees grounding of a cable shield at a metal connection box or shipboard point of entry (POE) such as a stuffing tube or kick-pipe. | |||
| 328 | 3.5.2. The CMS shall be electromagnetically compatible within itself such that system operational performance requirements are met. | |||
| 329 | 3.5.3. The CMS shall be designed, verified, and integrated to meet the requirements of MIL-STD- 461 and MIL-STD-464. The following equipment is exempt from MIL-STD-461 compliance verification testing: | |||
| 330 | 3.5.3.1. Equipment that was previously qualified with the applicable requirements of MIL-STD-464 and MIL-STD-461G or later. | |||
| 331 | 3.5.3.2. Equipment included in the Standard Electrical Symbol List, MIL-HDBK-290. 3.5.4.Grounding | |||
| 332 | 3.5.3.3. Equipment and cable installation, shielding, and grounding shall meet the requirements of MIL-STD-1310. | |||
| 333 | 3.5.3.4. Shield Grounding Adapters (SGAs), Assemblies, Back-shells and Conduit Systems. SGAs, shield ground assemblies, connector, EMI backshells, and conduit systems shall provide shielding without violating the structural integrity of the cable or conduit shields. SGAs, shield ground assemblies, back-shells, and conduit systems shall provide at least 60 dB of grounding effectiveness. | |||
| 334 | 3.5.4. Cables | |||
| 335 | 3.5.4.1. Shielded cable shall have a surface transfer impedance no greater than 100 milliohms/m from 100 kHz to 600 MHz. | |||
| 336 | 3.5.4.2. Add-on shielding, such as conduit and cable trunks, shall cover the entire length of unshielded cables. | |||
| 337 | 3.5.4.3. Cable shielding shall be grounded 360 degrees at connector backshells, connection boxes, fixtures, cable trunks, and at ship points of entry in accordance with MIL-STD-1310. | |||
| 338 | 3.6. Networking. | |||
| 339 | 3.6.1. CMS Network hosts and assets shall be capable of being internally interconnected via the ship’s unclassified LAN. | |||
| 340 | 3.6.2. CMS Network assets shall be managed and configured by the Unclassified Network’s Network Management System | |||
| 341 | 3.6.3. Network Media | |||
| 342 | 3.6.3.1. The cabling for switch-to-switch cabling shall be single mode optical fiber. | |||
| 343 | 3.6.3.2. Unless otherwise approved, single ferrule connectors shall be of the ST connector type per MIL• DTL-83522/16. ST-to-ST adapters shall be per MIL-DTL-83522/17. Multiple termini connectors shall be per MIL-PRF-28876 and use the MIL-PRF- 29504/14 and /15 type termini. | |||
| 344 | 3.6.3.3. Cables, connectors, and other fittings shall be in accordance with Defense Supply Center Columbus (DSCC• VQP) Fiber Optic (FO) Qualified Products List (QPL), FO Military Specification components. | |||
| 345 | 3.6.4. User Cable Requirements | |||
| 346 | 3.6.4.1. Where local cable for user connections is fiber optic cable, user connections shall be conventional fiber optic MIL-PRF-85045 cable. Unless otherwise approved, MIL-PRF-85045/17 and /18 thermoset type shall be used. | |||
| 347 | 3.6.4.2. Where copper Ethernet cabling is used, Shielded Twisted Pair (STP), Category 5e, shall be used. STP cables to be used for shipboard installation shall be inspected and tested in accordance with TIA/EIA-568 C.2. | |||
| 348 | 3.6.5. Fiber Optic Cable Installations | |||
| 349 | 3.6.5.1. Fiber optic safety precautions shall be in accordance with MIL-STD-2042. Light duty (single ferrule) connectors used to interconnect fiber optic cable shall be located within interconnection boxes or other equipment. Light duty (single ferrule). | |||
| 350 | 3.6.5.2. Connectors used for connection between fiber optic cable and other associated fiber optic components shall be located within the end user equipment console or panel. | |||
| 351 | 3.6.6. Network Topology | |||
| 352 | 3.6.6.1. Network Switches (If provided). | |||
| 353 | 3.6.6.1.1. The network switches shall offer integrated switching between the Backbone and User systems. The switch software and firmware shall be upgradeable. Switches shall deliver wire-speed throughput at every packet size. A minimum of two or 20% of the total ports in a switch, whichever is larger, shall be available for growth. Backbone switches shall have multiple power supplies such that the loss of a single power supply does not compromise the operation of the switch. | |||
| 354 | 3.6.6.2. Network Architecture | |||
| 355 | 3.6.6.2.1. The network's switch architecture shall have fault tolerant pathways between switches. | |||
| 356 | 3.6.6.2.2. The switches shall have fault tolerant connections both within the backbone and to the user connection environments. | |||
| 357 | 3.6.7. Network Protocols | |||
| 358 | 3.6.7.1. Network switches shall support multiple protocols and allow different system environments to operate in parallel. Integrated switching capability shall be used to implement a network service over the backbone and user networks. The switches shall support multiple protocol stacks, each with its own routing protocols, and allow these different environments to operate in parallel. The switches shall provide translation services between different protocols. | |||
| 359 | 3.6.7.2. Switches shall support the 7 layer Open Systems Interconnection (OSI) networking model. The wired network shall only support Ethernet (IEEE 802.3) as the Data Link Protocol (Layer 2). Networking equipment shall be IPv6 compliant and shall support legacy IPv4 systems. Commonly implemented approved and draft IETF RFCs shall be supported. | |||
| 360 | 3.6.7.3. Transport Protocols. Transport protocols are other protocols that the network transports for systems connected to the network. These protocols are defined by the system connecting to the network and shall be approved. Unless otherwise approved, proprietary protocols that are not defined by an international standard shall not be used. If approved for use, such proprietary protocols shall be documented in the applicable IDD. | |||
| 361 | 3.6.8. Reserved | |||
| 362 | 3.6.9. Network Fault Tolerances | |||
| 363 | 3.6.9.1. The network shall provide the following fault tolerant architectural features: | |||
| 364 | 3.6.9.1.1. Loss of a single switch shall not impair the function or operational capability of any other switch. | |||
| 365 | 3.6.9.1.2. Loss of a user’s physical port on a switch shall not impair the function of any other users connected to the network. | |||
| 366 | 3.6.9.1.3. Data rates shall degrade gracefully when the system is subjected to overloading beyond design data load or if excessive noise or other interference is introduced into the system. | |||
| 367 | 3.6.10. Network Management | |||
| 368 | 3.6.10.1. The CMS shall be compatible with the Unclassified Network Management System (NMS). | |||
| 369 | 3.6.10.2. Where sway braces are employed to afford stability under vibration, the braces shall provide flexibility to accommodate relative motions without overloading the equipment. This load shall be assumed to be acting at the center of gravity of the equipment. The use of sway braces shall not compromise isolation or resilient mounting of any equipment. | |||
| 370 | 3.7. Reserved | |||
| 371 | 3.8. Materials | |||
| 372 | 3.8.1. Prohibited Materials | |||
| 373 | 3.8.1.1. Magnesium and its alloys shall not be used. | |||
| 374 | 3.8.1.2. Lead shall not be used without approval. | |||
| 375 | 3.8.1.3. Lead graphite pencils shall not be used to mark uncoated aluminum. | |||
| 376 | 3.8.1.4. Materials used in any system, component or piece of equipment shall not contain asbestos, ceramic fibers, hexavalent chromium compounds, mercury or Polychloride Biphenyls (PCBs). | |||
| 377 | 3.8.1.5. Instruments, equipment, fittings, paint, insulation, adhesives, or other items containing material or components that would produce or generate noxious fumes at its operating temperature or at any temperature below 200 degrees F shall not be installed or applied in manned spaces. For paints and adhesives, this requirement applies after drying or curing is complete. | |||
| 378 | 3.8.2. Chemical, Electrical And Mechanical Properties | |||
| 379 | 3.8.2.1. Galvanically dissimilar metals shall not come in contact with each other. Galvanic corrosion shall be prevented by insulating dissimilar materials from each other with gaskets, washers, sleeves, and bushings or other insulating material. | |||
| 380 | 3.9. Human Systems Integration (HSI) | |||
| 381 | 3.9.1. General | |||
| 382 | 3.9.1.1. The system design shall incorporate Human Systems Integration processes to improve human performance, efficiency, and safety of the crew and ship, including support systems. | |||
| 383 | 3.9.2. Detail Requirements | |||
| 384 | 3.9.2.1. Human Engineering | |||
| 385 | 3.9.2.1.1. Equipment in the system shall be arranged and accessible such that operators can access internal components without removing the equipment itself or parts of the equipment. | |||
| 386 | 3.9.2.1.2. The system and equipment shall be within the physical and cognitive capabilities and limitations of the users to operate and maintain it in its operational environment. | |||
| 387 | 3.9.2.1.3. The systems shall incorporate system and personnel safety factors to minimize human error and prevent injury under normal, degraded, or emergency conditions and under adverse environments. | |||
| 388 | 3.10. Input Power | |||
| 389 | 3.10.1. Unless otherwise specified, AC powered equipment shall operate when connected to Type I power in accordance with MIL-STD-1399-300-1 and MIL-STD-1399-300-2. | |||
| 390 | 3.10.2. Equipment shall not be damaged as a consequence of emergency conditions in accordance with MIL-STD-1399-300 and MIL-STD-1399-680. | |||
| 3.10.3. The equipment shall meet the user equipment interface requirements in accordance with MILSTD-1399-300 and MIL-STD-1399-680. |
File details come from the government source that posted it. Updated .