Skip to content
ATO Pathways
Log In
Overview
Search
Catalogs
SCAP
OSCAL
Catalogs
Profiles
Documents
References
Knowledge Base
Platform Documentation
Compliance Dictionary
Platform Changelog
About
Catalogs
XCCDF
Enterprise Voice, Video, and Messaging Policy Security Requirements Guide
Enterprise Voice, Video, and Messaging Policy Security Requirements Guide
An XCCDF Benchmark
Details
Profiles
Items
Prose
50 rules organized in 50 groups
SRG-VOIP-000100
1 Rule
<GroupDescription></GroupDescription>
The Enterprise Voice, Video, and Messaging Policy must define operations for VTC and endpoint cameras regarding the ability to pick up and transmit sensitive information.
High Severity
<VulnDiscussion>Users of conference room or office-based VTC systems and PC-based communications applications that employ a camera must not inadvertently display sensitive or classified information that is not part of the communications session while the camera is active. This can happen if information in the form of charts, pictures, or maps are displayed on a wall within the viewing or capture range of a camera. Any pan, tilt, and zoom (PTZ) capabilities of the camera must be considered. One may consider visual information out of range, but it may be in range considering camera capabilities such as high definition, PTZ, and video enhancement possibilities for captured frames. Inadvertent display of classified information could also happen if the information is lying on a desk or table unprotected. NOTES: - Vulnerability awareness and operational training will be provided to users of VTC and video/collaboration communications-related cameras regarding these requirements. - This requirement is relevant no matter what the classification level of the session. In an IP environment, the classification of VTC or PC communications depends on the classification of the network to which the VTU or PC is attached and the classification of the facility in which it is located. While classified communications can occur at the same level of classification as the network and facility, communications having a lower or no classification (e.g., unclassified or CUI) may also occur in the same environment. Therefore, sensitive or classified information that is not part of the communications session might be improperly disclosed without proper controls in place.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000110
1 Rule
<GroupDescription></GroupDescription>
The Enterprise Voice, Video, and Messaging Policy must define operations for endpoint microphones regarding the ability to pick up and transmit sensitive information.
Medium Severity
<VulnDiscussion>Microphones used with VTC systems and devices are designed to be extremely sensitive so the voice of anyone speaking anywhere within a conference room is picked up and amplified so they can be heard clearly and understood at the remote location on the call. This same sensitivity is included in VTUs that are used in office spaces. This has one disadvantage. The microphones can pick up sidebar conversations that have no relationship to the conference or call in progress. Likewise, in an open area, received conference audio can be broadcast to others in the area that are not part of the conference and possibly should not be exposed to the conference information for need-to-know reasons. Speakerphones exhibit a similar vulnerability. This is the same confidentiality vulnerability posed to audible sound information in the environment as discussed above, with the added twist that the conference audio is vulnerable to others in the environment. While this is more of an issue in environments where classified conversations normally occur, it is also an issue in any environment. This is of particularly concern in open work areas or open offices where multiple people work in near proximity. Users or operators of VTC systems of any type must take care regarding who can hear what is being said during a conference call and what unrelated conversations can be picked up by the sensitive microphone. Where a VTU is used by a single person in an open area, a partial mitigation for this could be the use of a headset with earphones and a microphone. While this would limit the ability of others to hear audio from the conference and could also limit the audio pickup of unrelated conversations, it may not be fully effective. In some instances, such as when a VTU is located in a SCIF, a Push-to-Talk (PTT) handset/headset may be required Microphones embedded in or connected to a communications endpoint, PC, or PC monitor can be sensitive enough to pick up sound that is not related to a given communications session. They could pick up nearby conversations and other sounds. This capability could compromise sensitive or classified information that is not related to the communications in progress. Speakers embedded in or connected to a communications endpoint or PC can be made loud enough to be heard across a room or in the next workspace. This capability could compromise sensitive or classified information that is being communicated during a session. Users must be aware of other conversations in the area and their sensitivity when using any communications endpoint (not only a PC-based voice, video, or collaboration communications application). This awareness must then translate into protecting or eliminating these other conversations. A short-range, reduced-gain, or noise-cancelling microphone may be required. A PTT microphone may also be required for classified areas. The microphone should be muted when the user is not speaking as both mitigation for this issue and proper etiquette when participating in a conference. The muting function should be performed using a positively controlled disconnect, shorting switch, or mechanism instead of a software-controlled mute function on the PC. Users must be aware of other people in the area that could hear what is being communicated. This is particularly an issue if the communicated information is sensitive or classified because the parties overhearing the information may not have proper clearance or a need-to-know. To mitigate this issue, a headset or speakers should be used and at a volume that only the user can hear.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000120
1 Rule
<GroupDescription></GroupDescription>
An IP-based VTC system implementing a single CODEC that supports conferences on multiple networks with different classification levels (i.e., unclassified, SECRET, TOP SECRET, TS-SCI) must support Periods Processing by being sanitized of all information while transitioning from one period/network to the next.
Medium Severity
<VulnDiscussion>All residual data (data unintentionally left behind on computer media) must be cleared before transitioning from one period/network to the next. Because the equipment is reused, nondestructive techniques are used. According to NIST Special Publication 800-88: Clearing information is a level of media sanitization that would protect the confidentiality of information against a robust keyboard attack. Simple deletion of items would not suffice for clearing. Clearing must not allow information to be retrieved by data, disk, or file recovery utilities. It must be resistant to keystroke recovery attempts executed from standard input devices and from data scavenging tools. For example, overwriting is an acceptable method for clearing media.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000130
1 Rule
<GroupDescription></GroupDescription>
An IP-based VTC system implementing a single CODEC that supports conferences on multiple networks with different classification levels (i.e., unclassified, SECRET, TOP SECRET, TS-SCI) must support Periods Processing by connecting the CODEC to one network at a time, matching the classification level of the session to the classification level of the network.
High Severity
<VulnDiscussion>Connecting to networks of different classifications simultaneously incurs the risk of data from a higher classification being released to a network of a lower classification, referred to as a "spill". It is imperative that networks of differing classification levels or with differing handling caveats not be interconnected at any time. Separation in a multinetwork VTC system is maintained by the use of an A/B, A/B/C, or A/B/C/D switch that meets requirements for channel isolation or by manual connection of the CODEC to one network at a time.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000140
1 Rule
<GroupDescription></GroupDescription>
An IP-based VTC system implementing a single CODEC that supports conferences on multiple networks with different classification levels (i.e., unclassified, SECRET, TOP SECRET, TS-SCI) must support Periods Processing sanitization by purging/clearing volatile memory within the CODEC by powering the CODEC off for a minimum of 60 seconds.
Medium Severity
<VulnDiscussion>Volatile memory requires power to maintain the stored information. It retains its contents while powered, but when power is interrupted, stored data is immediately lost. Dynamic random-access memory (DRAM) is a type of random-access memory that stores each bit of data in a separate capacitor within an integrated circuit. Because capacitors leak charge, data fades unless the capacitor charge is refreshed periodically. Static random-access memory (SRAM) has a different configuration from DRAM, which allows it to retain data longer when power is no longer applied (data remanence). Powering off the CODEC for 60 seconds is sufficient to discharge the capacitors and erase all data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000150
1 Rule
<GroupDescription></GroupDescription>
IP-based VTC systems implementing a single CODEC that support conferences on multiple networks with different classification levels must sanitize nonvolatile memory while transitioning between networks by overwriting all configurable parameters with null settings before reconfiguring the CODEC for connection to the next network.
Medium Severity
<VulnDiscussion>A factory reset is the software restoration of an electronic device to its original system state by erasing all information stored on the device to restore the device to its original factory or unconfigured settings. This erases all data, settings, and applications that were previously on the device. Factory reset may be used as part of the sanitization process. This requirement is satisfied by the use of either a properly configured automated configuration management system or an inherent sanitization capability of the unit. However, this requirement results in a CAT III finding if a manual procedure is used.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000160
1 Rule
<GroupDescription></GroupDescription>
The A/B, A/B/C, or A/B/C/D switch within an IP-based VTC system that supports conferences on multiple networks with different classification levels must be based on optical technologies to maintain electrical isolation between the various networks to which it connects.
Medium Severity
<VulnDiscussion>The A/B, A/B/C, or A/B/C/D switch is physically connected to multiple networks that have different classification levels. Copper-based switches provide minimal or no electrical isolation due to capacitance between the wires in the switch box and the switch contacts. This can permit information on one network to bleed or leak over to the other network, which can lead to the disclosure of classified information on a classified network to a network of lower classification. This must be prevented. Optical fiber is an insulator; thus, it carries no electrical current and generates no electromagnetic field, eliminating the capacitance issue. Therefore, it provides excellent electrical isolation between the networks to which it connects.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000170
1 Rule
<GroupDescription></GroupDescription>
An IP-based VTC system implementing a single CODEC that supports conferences on multiple networks with different classification levels must be implemented in such a way that configuration information for a network having a higher classification level is not disclosed to a network having a lower classification level.
Medium Severity
<VulnDiscussion>Connecting the CODEC to a network while it is being reconfigured could lead to the disclosure of sensitive configuration information for a network having a higher classification level to a network having a lower classification level. Ideally, the CODEC will be disconnected from any network while it is being reconfigured. However, the requirement can be met by using a procedure that purges the configuration for the currently connected network, power cycling the CODEC as required (for a minimum of 60 seconds per SRG-VOIP-000140) as the CODEC is switched to the next network, and then reconfiguring the CODEC for the next session.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000180
1 Rule
<GroupDescription></GroupDescription>
The A/B, A/B/C, or A/B/C/D switch used for network switching in IP-based VTC systems implementing a single CODEC that supports conferences on multiple networks with different classification levels must be Common Criteria certified.
Medium Severity
<VulnDiscussion>Common Criteria provides assurance that the process of specification, implementation, and evaluation of a computer security product has been conducted in a rigorous, standard, and repeatable manner at a level commensurate with the target environment for use. The Defense Security/Cybersecurity Authorization Working Group (DSAWG) mandated that the A/B, A/B/C, or A/B/C/D switches used in VTC systems implementing a single CODEC that supports conferences on multiple networks with different classification levels, where these networks are simultaneously and permanently connected to these networks, must receive NIAP approval in accordance with CNSSP #11. This was primarily due to the potential interconnection of separate networks designated as National Security Systems through the switch. This was a prerequisite to their approval of the multinetwork VTC system architecture. Therefore, the A/B, A/B/C, or A/B/C/D switch must be satisfactorily evaluated and validated in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000190
1 Rule
<GroupDescription></GroupDescription>
The A/B, A/B/C, or A/B/C/D switch used for network switching in IP-based VTC systems implementing a single CODEC that supports conferences on multiple networks with different classification levels must be TEMPEST certified.
Low Severity
<VulnDiscussion>Committee on National Security Systems Advisory Memorandum (CNSSAM) TEMPEST/01-13, RED/BLACK Installation Guidance, provides criteria for the installation of electronic equipment, cabling, and facility support for the processing of secure information. National policy requires that systems and facilities processing NSI must be reviewed by a Certified TEMPEST Technical Authority (CTTA) to achieve TEMPEST security. The RED/BLACK guidance contained in TEMPEST/01-13 will be considered by the CTTA along with other measures (e.g., TEMPEST Zoning, TEMPEST-suppressed equipment and shielding) to determine the most cost-effective countermeasures to achieve TEMPEST security. Only those RED/BLACK criteria specifically identified by the CTTA will be implemented.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000200
1 Rule
<GroupDescription></GroupDescription>
An IP-based VTC system implementing a single set of input/output devices (cameras, microphones, speakers, control system), an A/V switcher, and multiple CODECs connected to multiple IP networks with different classification levels must provide automatic mutually exclusive power control for the CODECs or their network connections so only one CODEC is powered on or one CODEC is connected to any network at any given time.
Medium Severity
<VulnDiscussion>If a VTC system is implemented using multiple CODECs, each connected to a network with a different classification level, along with an A/V switcher, a potential path exists through the CODECs and A/V switcher that could permit classified information to be exposed/released from one classified network to a network with a lower classification. Powering off the CODEC, at a minimum, will provide a level of isolation that will prevent active passage of data. However, the above solution could still provide an electrical leakage path between the networks whereby classified information could leak onto another network. To improve on the electrical isolation between networks and as an alternative to powering off the CODECs, an optical link using fiber optic to Ethernet media adaptors/converters/modems between the CODEC and each of the networks it serves could be implemented. In this case, the fiber optic media adaptors would be powered in a mutually exclusive manner. Mutually exclusive power means that only one CODEC or fiber optic adaptor can be powered at a time. Turning on one CODEC or fiber optic adaptor turns off power for all others.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000210
1 Rule
<GroupDescription></GroupDescription>
The implementation of an IP-based VTC system that supports conferences on multiple networks with different classification levels must maintain isolation between the networks to which it connects by implementing separation of equipment and cabling between the various networks with differing classification levels in accordance with CNSSAM TEMPEST/01-13, RED/BLACK Installation Guidance.
Medium Severity
<VulnDiscussion>Information leakage is the intentional or unintentional release of information to an untrusted environment from electromagnetic signals emanations. Security categories or classifications of information systems (with respect to confidentiality) and organizational security policies guide the selection of security controls employed to protect systems against information leakage due to electromagnetic signals emanations. The Committee on National Security Systems Advisory Memorandum (CNSSAM) TEMPEST/01-13, RED/BLACK Installation Guidance, provides criteria for the installation of electronic equipment, cabling, and facility support for the processing of secure information. The TEMPEST/01-13 requires that the facility housing the secure VTC equipment (i.e., the secure conference room) must meet the TEMPEST requirements for such rooms. The appropriate and required separations between RED and BLACK equipment and cables must be met. This includes cable routing inside equipment cabinets. Depending on the TEMPEST ZONE, the separation requirements are: - Minimum equipment separation - 50 cm or 1 m. - Minimum cable separation - 5 cm or 15 cm. National policy requires that systems and facilities processing NSI must be reviewed by a Certified TEMPEST Technical Authority (CTTA) to achieve TEMPEST security. The CTTA may require separate power sources for RED equipment and BLACK equipment.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000220
1 Rule
<GroupDescription></GroupDescription>
Video conferencing, Unified Capability (UC) soft client, and speakerphone speaker operations policy must prevent disclosure of sensitive or classified information over nonsecure systems.
Medium Severity
<VulnDiscussion>Speakers used with Voice Video systems and devices may be heard by people and microphones with no relationship to the conference or call in progress. In open areas, conference audio may be overheard by others in the area without a need-to-know. A policy must be in place and enforced regarding the placement and use of speakers connected to secure Voice Video systems (video conferencing, EVoIP, ECVoIP, etc.) and secure Voice Video endpoints (STU-III, STE, etc.) located in areas or rooms where classified meetings, conversations, or work normally occur. The policy must be in accordance with NSA and DCI guidance and address, at a minimum, the following: - Location if instruments must be limited to sole-use offices, conference rooms, and similar areas that afford sound attenuation. - Notification to all room occupants of the use of the speaker. - Notification to all room occupants for awareness of the classification of conversations taking place. - The room occupant assuming responsibility for taking the necessary precautions to ensure the classified discussion is not overheard. - Secure Voice Video endpoints must be configured to prevent speaker enablement in the nonsecure mode. Speakerphone use on secure telecommunications systems requires special consideration regarding placement and operating policy. NSA S412 approves the installation/enablement of speakerphones on National Secure Telephone Systems (NSTS) and STU-III/STE instruments. The intent of speakerphone approval rests with the room occupant assuming responsibility for taking the necessary precautions to ensure the classified discussion is not overheard by individuals outside the conversation who may not have a need-to-know for the information discussed and/or that the speakerphone will not pick up and transmit other classified conversations in the area that are not part of the call in progress.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000230
1 Rule
<GroupDescription></GroupDescription>
An inventory of authorized instruments must be documented and maintained in support of the detection of unauthorized instruments connected to the Enterprise Voice, Video, and Messaging system.
Medium Severity
<VulnDiscussion>Traditional telephone systems require physical wiring and/or switch configuration changes to add an instrument to the system. This makes it difficult for someone to add unauthorized digital instruments to the system. However, this could be done more easily with older analog systems by tapping an existing analog line. With Enterprise Voice, Video, and Messaging, this is no longer the case. Most IPT/VoIP systems employ an automatic means of detecting and registering a new instrument on the network with the call management server and then downloading its configuration to the instrument. This presents a vulnerability whereby unauthorized instruments could be added to the system or instruments could be moved without authorization. Such activity can happen anywhere there is an active network port or outlet. This is not only a configuration management problem. It could also allow theft of services or some other malicious attack. It is recognized however, that auto-registration is necessary during large deployments of VoIP terminals, and for a short time thereafter, to facilitate additions and troubleshooting. This applies to initial system setup and any subsequent large redeployments or additions. Normal, day-to-day moves, adds, and changes will require manual registration. Because it may be possible for an unauthorized VoIP terminal to be added to the system easily during auto-registration, the registration logs must be compared to the authorized terminal inventory. Alternately, the system could have a method of automatically registering only preauthorized terminals. This feature would support VoIP terminals that are AO approved for connection from multiple local or remote locations. It is critical to the security of the system that all IPT/VoIP end instruments be authorized to connect to and use the system. Only authorized instruments should be configured in the system controller and therefore allowed to operate. Unauthorized instruments could lead to system compromise or abuse. A manual inventory of authorized end instruments will aid in the detection of unauthorized instruments registered to the system, particularly during the period when autodetection/registration is permitted. This will also aid in certification and accreditation efforts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000240
1 Rule
<GroupDescription></GroupDescription>
Customers of the DISN VoSIP service must use address blocks assigned by the DRSN/VoSIP PMO.
Low Severity
<VulnDiscussion>Ensure different, dedicated, address blocks or ranges are defined for the VVoIP system within the LAN (Enclave) that are separate from the address blocks/ranges used by the rest of the LAN for non-VVoIP system devices, thus allowing traffic and access control using firewalls and router ACLs. NOTE: This is applicable to a classified LAN connected to a classified WAN (such as the SIPRNet). In the case of a classified WAN where networkwide address-based accountability or traceability is required by the network PMO, the PMO must provide segregated, networkwide address block(s) so the attached classified LANs can meet this requirement. DISA provides a worldwide VoIP-based voice communications service called the DISN Voice over Secret IP (VoSIP). This service is managed by the DRSN PMO. This service also provides gateways into the DRSN. In support of the above requirement, the SIPRNet PMO has designated specific dedicated address ranges for use by the DISN VoSIP service and assigned these address blocks to the DRSN/VoSIP PMO for VoSIP address management and assignment. The VoSIP service provides VoIP-based communications between VoIP systems within the customer's classified LANs (C-LANs) operating at the secret level while using the SIPRNet WAN for the inter-enclave (inter-LAN) transport. Additionally, the SIPRNet PMO requires networkwide address-based accountability or traceability based on assigned IP address. The customer's SIPRNet-connected secret C-LANs use addresses assigned by the SIPRNet PMO. Therefore, customers of the DISN VoSIP service must use IP addresses assigned to them by the DRSN/VoSIP PMO when addressing the VoIP controllers and endpoints within their C-LANs. This is to maintain the segregation of the voice and data environments on the customer's secret C-LANs as required by this SRG. This also facilitates proper routing and flow control over the traffic between VoSIP addresses. The DISN service is designated DISN Voice over Secret IP but uses an acronym (VoSIP), which also means Voice over Secure IP. Voice over Secure IP relates to any VoIP-based service on a secure or classified IP network. While the DISN VoSIP service is the preferred means to interconnect SIPRNet-connected secret C-LANs for VoIP service, there may be a need for an organization to implement a VoIP-based voice or video communications system within their organization or with close partners. If such a system has no need or potential need to communicate with other enclaves that use the DISN VoSIP service, they must use their own dedicated IP address space carved out of the address space assigned to their C-LANs by the SIPRNet PMO.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000250
1 Rule
<GroupDescription></GroupDescription>
Voice networks must not be bridged via a Unified Capability (UC) soft client accessory.
Medium Severity
<VulnDiscussion>While a headset, microphone, or webcam can be considered to be UC soft client accessories, these are also accessories for other collaboration and communications applications. This discussion relates to UC soft client-specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB-connected telephone instrument that associates itself with the UC soft client application running on the PC. It minimally provides a handset that includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. They should be operated accordingly. A USB ATA is a USB-connected device that associates itself with the UC soft client application and provides the ability to use a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the UC soft client while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone, providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the UC soft client application and supporting VVoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DOD network due to this bridging of networks. They can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB phones can contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DOD IP voice and data network and a public dial-up voice network. The use of any UC soft client accessory that provides a network bridging function poses both a legal and an IA threat to the DOD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. DECT 6.0 headsets provide wireless microphone and earphone use to a telephone device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000260
1 Rule
<GroupDescription></GroupDescription>
When soft-phones are implemented as the primary voice endpoint in the user's workspace, a policy must be defined to supplement with physical hardware-based phones near all such workspaces.
Medium Severity
<VulnDiscussion>This and several other requirements discuss the implementation of PC soft-phones or UC applications as the primary and only communications device in the user's workspace. While this degrades the protections afforded a hardware-based system, the trend is to use more and more PC-based communications applications due to their advanced features, collaborative benefits, and perceived reduced cost. This soft-phone use case results in the elimination of hardware-based telephones on users' desks in the workplace. This can be seen as, or result in, trading down (from a hardware-based system) with regard to availability, reliability, and quality of service because the data network is generally more susceptible to compromise from many sources inside and outside the local LAN, making the soft-phones more exposed to attack. This also means no telephone will be available in the workspace if the PC is not powered on, the application is not loaded, or the PC is not fully functional. While this is undesirable from an IA standpoint, a business case can be developed to support it. NOTE: The recommended relationship between PC soft-phone/UC applications and hardware-based endpoints in the normal work area is that the PC application should augment the functionality of, or be a backup to, the hardware-based instrument in the user's workspace. The implementation of PC soft-phones or UC applications in the user workspace as their only endpoint has several ramifications that must be considered. These include: - The PC becomes a single point of failure for communications services provided to a user in their workspace. A widespread problem, which affects many PCs or the network infrastructure, may disable all communications for many users at one time. Users may not have a means to report the failure without using an alternate communications system. A fast-spreading worm or power outage could create such a situation. While some may argue that "users can call on their cell phones", service may not be available, or their use may not be permitted in the facility. This translates into the loss of functionality and efficiency, as in lost time, due to the inability to communicate when the PC or soft-phone application is not running or functioning properly. - The protections afforded hardware-based endpoints by the use of the voice protection zone, such as VoIP VLAN(s) and others, are missing for soft-phones in a widespread use/implementation scenario and, depending on the implementation on the PC, may degrade the protections afforded hardware-based endpoints. Such is the case for all software-based communications endpoints because they are typically implemented on all PCs and therefore will be connected to the data VLANs. Assured service for voice traffic will be degraded from that obtained with hardware-based instruments connected in the voice protection zone. This translates into the following additional IA measures required to protect the VoIP infrastructure (e.g., a firewall between the VoIP and data VLANs): - The hardware-based endpoint is not available for use in parallel with, or in place of, the PC. This can be a problem if the PC is having performance or operational issues, is turned off, or is unavailable. Accessing help desk services requiring logging on to the PC to use the voice services and work on a problem could be a real challenge. Rebooting the PC to clear a problem would disconnect the call to the helpdesk. Accessing voice mail or answering the phone while the PC is booting is made impossible, reducing efficiency, particularly when the user starts their day. If the user has command and control (C2) responsibilities, the IP equivalent of MLPP cannot function properly if an application or PC is unavailable. Precedence calls will not be received by the user but will be transferred to their designated alternate answering point. - Emergency communications could be unavailable if the PC is not booted, the communications application is not running, or either is otherwise compromised. Voice communications must be readily available for life safety and medical reasons, as well as other facility security emergencies. A partial mitigation for this in a "soft-phone world" is to place common use hardware telephones within a short distance (e.g., 30 to 50 feet) of every workspace, which is an additional cost. This additional distance, however, could be an issue in a medical emergency where a worker might be alone in their workspace and their PC or voice communications application is not functioning properly. They may not be able to reach the common use instrument depending on the nature of the medical emergency. If the worker was suffering a heart attack or diabetic emergency, they could die. Business cases therefore need to include the cost of insurance and/or lawsuits for this eventuality. The previous two items translate into the following the addition of common-use hardware-based instruments placed around the facility (for backup and emergency use) along with the additionally required LAN cabling and access switch ports. While some may believe this is not an IA issue, it is because the discussion is about availability, which is one of the prime tenets of IA. Additionally, the VoIP controllers (i.e., the equipment that controls the telephone system) must be able to be accessed by the PC soft-phones while being protected as they would be in a normal VoIP system using hardware-based instruments. NOTE: Methods for permitting the necessary PC traffic to, from, and between the voice and data zones while protecting the voice zone will be discussed later in this document.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000270
1 Rule
<GroupDescription></GroupDescription>
Implementing Unified Capabilities (UC) soft clients as the primary voice endpoint must have authorizing official (AO) approval.
Medium Severity
<VulnDiscussion>The AO responsible for the implementation of a voice system that uses UC soft clients for its endpoints must be made aware of the risks and benefits. In addition, the commander of an organization whose mission depends on such a telephone system must also be made aware and provide approval. When UC soft clients are fielded as the primary endpoint, the risk of unavailability is high compared to dedicated instruments. Another major difficulty for UC soft clients deployed on laptops is providing accurate location information for emergency services. When emergency services are called from the laptop, if it is not at the location entered in the Automated Location Identification (ALI) database, emergency services may be dispatched to the wrong place.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000280
1 Rule
<GroupDescription></GroupDescription>
Deploying Unified Capabilities (UC) soft clients on DOD networks must have authorizing official (AO) approval.
Medium Severity
<VulnDiscussion>This use case addresses situations in which UC soft client applications on workstations are not the primary voice communications device in the work area. This means there is a validated mission need and the number of UC soft clients permitted to operate inside the LAN will be less than the number of hardware-based phones in the LAN. This number should be limited to UC soft clients required to meet specific mission requirements. There are scenarios for the use of limited numbers of UC soft clients in the strategic LAN. The first of these scenarios is providing support for UC soft clients associated with a VoIP system in another enclave. This is a remote access scenario and must operate as they would in a normal remote access use case. If this scenario is approved, special accommodations must be made in the local LAN to support users from a remote LAN and permit them to connect to their home enclave. This could include segregating them on a separate dedicated LAN with its own boundary protection or by implementing a dedicated VLAN protection zone while opening the enclave boundary to permit the remote connection. Voice/video and data must reside on separate VLANs for the protection of the voice infrastructure. However, recognizing that requiring a NIC to be configured to support voice/video and data VLANs is not a viable solution, voice and data traffic can coexist in the data VLAN when leaving the workstation. Based on the Unified Capabilities Requirements (UCR) that UC application tag its signaling and media traffic with the proper UCR-defined Differentiated Service Code Point (DSCP), the LAN access switch port can route the UC traffic to the voice/video VLAN. If the LAN access switch is not capable, then routing upstream must perform this. A separate NIC is not required to support VLANs for voice and video segmentation under UC.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000290
1 Rule
<GroupDescription></GroupDescription>
A Call Center or Computer Telephony Integration (CTI) system using soft clients must be segregated into a protected enclave and limit traffic traversing the boundary.
Medium Severity
<VulnDiscussion>UC soft clients may be used on a strategic LAN when associated with or part of a CTI application. Traditional computer telephony integration CTI encompasses the control of a telephone or telecommunications switch by a computer application. Interfaces have been developed to provide connection between the computer, typically a workstation, and the telephone or other terminal attached to the telephone switch, and possibly a special analog or TDM line going directly to the telephone switch. Applications are also developed to use these interfaces to integrate a data application with the telephone system. Sometimes the integration is as simple as being able to dial a number from the computer application, or it could provide full control of the switch as in the case of an operator's console. In these traditional scenarios, the voice stayed in a traditional telephone set and the data stayed on the computer with the exception of the control information. If the voice does enter the computer, it is sent directly to the sound card or converted to a sound file for storage and possible file transfer. The voice communication is not transmitted in real time via IP protocols. In contrast, modern-day CTI is changing in that today the voice communications and control is being transmitted using IP protocols, and the hardware interfaces and telephones are being replaced by computer applications. NOTE: The CTI systems discussed here are not Enterprise Voice, Video, and Messaging applications, although some of the features are similar. CTI systems generally have a special function and are not a general user application. These are typically Call Center or Help Desk applications. This type of CTI typically involves integration with a database application. In this scenario, where soft-phones are an integral part of the CTI system/application, implementation of separate voice and data zones could be detrimental to the proper functioning of the application. While separation requirements should be enforced if possible, they could be relaxed providing the general CTI requirement of treating the CTI system as an enclave is followed. A system such as this should have its own VoIP controller. If the system needs to communicate with systems outside the CTI system enclave, proper boundary protection must be provided. For example, because IP soft-phones are prevalent in today's call center/helpdesk systems, such a system would require the ability to place and receive phone calls from outside the CTI enclave. Calls might leave and enter the enclave via VoIP or a TDM media gateway. The workstations and call center agents may also need to email and access the web. NOTE: A network supporting a CTI application must be segregated from the enclave. This can be accomplished by maintaining a closed network or a segregated and access-controlled subenclave having appropriate boundary protection.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000300
1 Rule
<GroupDescription></GroupDescription>
The local Enterprise Voice, Video, and Messaging system must have the capability to place intrasite and local phone calls when network connectivity is severed from the remote centrally located session controller.
Medium Severity
<VulnDiscussion>Voice phone services are critical to the effective operation of a business, an office, or in support or control of a DOD mission. It is critical that phone service is available in the event of an emergency situation, such as a security breach or life safety event. The ability to place calls to emergency services must be maintained. DOD voice networks are designed to be extremely reliable and provide continuity of operations (COOP) support. However, the potential exists that a site may become severed from the DOD network. Some site's DOD VoIP phone systems are implemented without a local session controller. The session controller may be located remotely and serve several sites by providing long local service. This implementation scenario provides for central management of the overall phone system, saves in initial implementation cost, and saves in operating costs. Therefore, this scenario has many benefits. Unfortunately, to place a call between two endpoints within the local site or to place a call via the local commercial service connection, the initiating end instrument has to send its signal messages to the remote session controller over the DISN WAN connection, and then the session controller has to signal the called instrument or media gateway over the same WAN connection. Several messages are sent (back and forth) over the WAN connection before the two local endpoints can send their media streams directly between themselves. While the need to signal over the WAN connection can cause longer call setup time, which can be extended if there is congestion in the network, no call can be placed anywhere from the local site if it is cut off from its session controller. Based on this fact, and in support of maintaining viable local voice services in the event the site is cut off from its remote session controller, each physical site must maintain minimal local call control as a backup so that local intrasite and local commercial network calls can be placed. While this works to maintain local emergency service availability for security and life safety emergencies, it also provides the capability to make calls between DOD sites using the commercial network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000310
1 Rule
<GroupDescription></GroupDescription>
The LAN hardware supporting VVoIP services must provide redundancy to support command and control (C2) assured services and Fire and Emergency Services (FES) communications.
Medium Severity
<VulnDiscussion>Voice services in support of high-priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DOD VVoIP implementations are in the Unified Capabilities Requirements (UCR), specifying assured services supporting DOD IP-based voice services. The UCR defines LAN design requirements for redundancy of equipment and interconnections, minimum requirements for bandwidth, specifications for backup power, and the maximum number of endpoints tolerable by a single point of failure. Policy sets the minimum requirements for the availability and reliability of VVoIP systems: Special-C2 users is 99.999 percent, C2 users is 99.997 percent, and C2Routine only users (C2R) and non-C2 users are 99.9 percent. Similar availability and reliability through redundancy is needed to support routine user FES life-safety and security-related communications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000320
1 Rule
<GroupDescription></GroupDescription>
The LAN hardware supporting VVoIP services must provide physically diverse pathways for redundant links supporting command and control (C2) assured services and Fire and Emergency Services (FES) communications.
Medium Severity
<VulnDiscussion>Voice services in support of high-priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DOD VVoIP implementations are in the Unified Capabilities Requirements (UCR), specifying assured services supporting DOD IP-based voice services. Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering quickly from network failures and maintaining the required QoS for existing services. Policy sets the minimum requirements for the availability and reliability of VVoIP systems: Special-C2 users is 99.999 percent, C2 users is 99.997 percent, and C2Routine only users (C2R) and non-C2 users are 99.9 percent. The physical paths that uplinks take should be physically diverse and optimally terminate in physically diverse locations. The best practices should support all VVoIP users but are required for Special-C2 and C2 users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000330
1 Rule
<GroupDescription></GroupDescription>
The site's enclave boundary protection must route commercial VoIP traffic via a local Media Gateway (MG) connected to a commercial service provider using PRI, CAS, or POTS analog trunks.
Medium Severity
<VulnDiscussion>There are several reasons VVoIP system access to local voice services must use a locally implemented MG connected to commercial voice services, including: - The implementation or receipt of commercial VoIP service provides a path to the Internet. These "back doors" into the local network place the DISN at risk from exploitation. Such connections must be specifically approved under CJCSI 6211.02C and DODI 4640.14. Such connections must also meet the requirements in the Network Infrastructure STIG for an "Approved Gateway". This generally means that a full boundary architecture must be implemented. - A PRI or CAS trunk is required because the DSN is not permitted to exchange SS7 signaling with the PSTN. Doing so would place the DOD's SS7 network at risk. - Local access is necessary to support Fire and Emergency Services (FES) calls.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000340
1 Rule
<GroupDescription></GroupDescription>
Local commercial phone service must be provided in support of continuity of operations (COOP) and Fire and Emergency Services (FES) communications.
Medium Severity
<VulnDiscussion>Voice phone services are critical to the effective operation of the DOD mission. Phone service must be available an emergency, such as a security breach or life safety event. The ability to place calls to emergency services must be maintained. While the DOD voice networks are designed to be extremely reliable to support COOP, a site could be cut off from the DOD network. Therefore, each physical site must maintain local commercial phone service. While this works to maintain local emergency service availability for security and life safety emergencies, it also provides the capability to make calls between DOD sites using the commercial network. An additional, non-IA benefit is that this supports the ability to make local calls without having to pay toll charges to call a local number via some distant regional access point. Local phone service can be delivered in a number of ways, all of which meet this requirement, while some of them must meet additional requirements to secure them. Delivery options are as follows: - PRI or CAS TDM trunks. - Analog phone lines. The following are some examples: - A large site may use PRI, CAS, or POTS analog trunks connected to the site's PBX. - A small site or office attached to a large site. - May have a PBX and be served similar to a large site. - May be served by several analog phone lines terminated on Voice Video Endpoints.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000350
1 Rule
<GroupDescription></GroupDescription>
The enclave must be dual homed to two geographically diverse DISN SDNs and DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers.
Medium Severity
<VulnDiscussion>Redundancy and dual homing is used within the DISN core to provide for continuity of operations (COOP) if a piece of equipment, circuit path, or an entire service delivery node is lost. DOD policy also requires DOD enclaves that support command and control (C2) users for data services to be dual homed to the DISN core SDNs. This means there will be two physically separate access circuits from the enclave to two geographically diverse DISN SDNs. Once the access circuits arrive at the SDNs, the circuits must be connected to two geographically diverse DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers. Depending on the size of the SDN, one or both of the access circuits must be extended to another SDN containing the AR or PE. ARs are also dual homed to geographically diverse DISN PE routers. A single circuit provides far less redundancy and reliability than dual circuits This redundancy is required to increase the availability of the access to the DISN core to provide a greater chance of achieving assured service. This need extends to assured service C2 VVoIP communications and is why it is checked here.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000360
1 Rule
<GroupDescription></GroupDescription>
The dual homed DISN core access circuits must be implemented so that each one can support the full bandwidth engineered for the enclave plus additional bandwidth to support surge conditions in time of crisis.
Medium Severity
<VulnDiscussion>Providing dual-homed access circuits from a command and control (C2) enclave to the DISN core is useless unless both circuits provide the same capacity to include enough overhead to support surge conditions. If one circuit is lost due to equipment failure or facility damage, the other circuit must be able to carry the entire engineered load for a single circuit servicing the site. Additionally, the engineered capacity must take additional bandwidth into account to support higher levels of both data and VVoIP communications in time of crisis.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000370
1 Rule
<GroupDescription></GroupDescription>
The required dua- homed DISN Core or NIPRNet access circuits must follow geographically diverse paths from the CER(s) along the entire route to the geographically diverse SDNs.
Medium Severity
<VulnDiscussion>One way to provide the greatest reliability and availability for DISN services is to provide redundancy in the network pathways between the customer site and the redundant DISN SDNs. The DISN core network is designed to be highly reliable and available in support of the DOD mission. The most vulnerable part of the network is the access circuit from the enclave to the core and the path it takes from the SDN to the customer's site. Therefore, redundant access circuits should be provisioned. Physical pathways for communications network access circuits are vulnerable to physical disruption from a variety of threats, both natural and manmade. These threats range from storm damage (falling trees, floods) to being damaged through digging, downed utility poles, or malicious acts, including war and terrorism. To overcome the physical threat, the redundant circuits should follow geographically diverse paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000380
1 Rule
<GroupDescription></GroupDescription>
Critical network equipment must be redundant and in geographically diverse locations for a site supporting command and control (C2) users.
Low Severity
<VulnDiscussion>The enhanced reliability and availability achieved by the implementation of redundancy and geographic diversity throughout the DISN Core, along with the implementation of dual-homed circuits via geographically diverse pathways and facilities, is negated if both access circuits enter the enclave via the same facility containing a single Customer Edge Router (CER) connected to a single Session Border Controller (SBC). The reliability, redundancy, and robustness of the CER, SBC, and power source are subverted when the facility represents a single point of failure. For a small number of C2 users this may be less concerning, but with more C2 users supported by the system, the greater the issue. Even less severe eventualities may limit the capability of the system to support reliable communications. The mitigation for this systemwide vulnerability is to implement redundant facilities to which the geographically diverse pathways containing the dual-homed access circuits can run and terminate on redundant, geographically separated sets of CERs, SBCs, and core LAN equipment. Session controllers can also be separated in this manner. This mitigation is costly, and facilities housing critical communications infrastructure are not lost very often. However, the cost of mitigating this vulnerability must be weighed against the loss of critical communications, particularly in time of crisis. If the site supports large numbers of high-level C2 users or Special-C2 users, the cost of losing communications may outweigh the cost of providing redundant facilities. Another consideration should be that access to emergency services via the communications system would also be lost. The threat to strategic facilities is greater from natural causes than from damage due to acts of war or terrorism. However, all threats must be considered. Tactical facilities have a higher vulnerability to acts of war, on a par with or exceeding the vulnerability posed by natural events.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000390
1 Rule
<GroupDescription></GroupDescription>
Enclaves with commercial VoIP connections must be approved by the DODIN Waiver Panel and signed by DOD CIO for a permanent alternate connection to the Internet Telephony Service Provider (ITSP).
Medium Severity
<VulnDiscussion>The DOD requires the use of DISN services as the first choice to meet core communications needs. When additional services for SIP trunks are necessary, an ITSP may provide an "alternate connection", but this requires approval by the DODIN Waiver Panel and signature by the DOD CIO. Local ISP connections provide an internet pathway into the DISN, placing the DODIN directly at risk for exploitation. A local ISP connection can circumnavigate DOD protections of the DISN at its boundaries with the internet. Using commercial VoIP service from an ITSP requires the implementation of an internet service provider (ISP) connection, potentially providing a path to the internet. These types of connections must be approved and must meet the requirements in the Network Infrastructure STIG (NET0160) for an Internet Access Point (IAP). ITSP connections may provide SIP trunks terminating on a media gateway, which then provides TDM trunks or POTS lines to traditional non-VoIP PBX, key system, or individual end instrument. ITSP connections terminating in a separate LAN from the enclave's DOD LAN may support a separate VoIP system. This connection type might be used for a small site having a small VoIP system or a few discrete phones dedicated to commercial network calling. Additional guidance for the selection and procurement of telecommunications services is discussed in the DODI 8100.4 "DOD Unified Capabilities (UC)" dated 9 Dec 2010 and the DOD Unified Capabilities Requirements 2013 (UCR 2013) documents.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000400
1 Rule
<GroupDescription></GroupDescription>
The Fire and Emergency Services (FES) communications over a site's telephone system must be configured to support the Department of Defense Instruction (DODI) 6055.06 telecommunication capabilities.
Medium Severity
<VulnDiscussion>Emergency communications must include requests for fire, police, and medical assistance. In DOD, these communications can also include requests for Aircraft Rescue and Fire Fighting (ARFF), explosive ordnance disposal, and similar emergency situations specific to the military. The inability of first responders to automatically locate the caller threatens life safety and facility protection or security. Contacting emergency services via the public telephone system has been mandated for many years in the United States and other countries around the world. In the United States, the Federal Communications Commission (FCC) has mandated various aspects of providing enhanced FES communications and also relies on state legislation to extend these rules. The FCC rules primarily address public communications service providers, including traditional LEC and CLECs, mobile communications providers, and VoIP communications providers. DOD Instruction 6055.06, DOD Fire and Emergency Services (F&ES) Program, provides DOD policy regarding emergency services and emergency services communications. The document primarily discusses fire protection, with specific provisions for telecommunications support for fire, medical, and security emergencies. Private telephone systems, in general, provide a large portion of the required telecommunication capability. All DOD private telephone systems, VoIP or traditional, must support enhanced emergency services communications for the completion of emergency calls. Per DOD Instruction 6055.06, all sites must support, provide for, and implement F&ES telecommunications services. When implementing basic F&ES telecommunications services, each country or region designates a specific standard telephone number or prefix code to be dialed that can be easily remembered by the public. In some instances, while not best practice, organizations might designate an internal emergency number for use within their telephone system. Examples of such numbers are as follows: - 911 in North America. - 112 in the EU and UK. - 000 in Australia. Issues may arise when an emergency call is originated through a private telephone system, such as a traditional PBX or a VVoIP system. While the LEC or CLEC may properly route the call in a priority manner, the same may not be true for the private system unless specifically addressed in the systems call routing tables and potentially other system features. Therefore, the private system must be configured to properly handle emergency communications. Enhanced F&ES communications permits the answering station to automatically locate the caller. This is particularly helpful when the caller cannot provide their location. Enhanced F&ES communications are mandated by the FCC and state legislation. Current implementation is a best practice. The enhanced F&ES communications capability is enabled using Automatic Number Identification (ANI) and Phone Switch Automatic Location Identification (PS-ALI) information. ANI provides the telephone number of the calling party and is generated by the telephone system. PS-ALI associates the calling party's number (ANI information) with their location or registered address of the phone being used. PS-ALI is provided by a database maintained within the telephone system or externally. In many cases, the F&ES answering service system will use the PS-ALI information to map the location of the calling phone. VoIP phones, on the other hand, can be connected anywhere in the world and function. This is an issue for commercial VoIP services that is being addressed by the FCC. ALI information in the private sector must be handled by the owners/operators of private telephone system. When a private telephone system supports enhanced F&ES telecommunications, a PS-ALI database must be instituted, maintained, and kept current as endpoints and numbers move at a site. NOTE: For fire and emergency services, the requirements are for the site. The requirement must be met through the unclassified system. Classified systems at the site, because they only operate in secure areas without connection to public services, do not need to implement this requirement. References: DOD Instruction No. 6055.06, DOD Fire and Emergency Services (F&ES) Program, dated 21 Dec 2006</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000410
1 Rule
<GroupDescription></GroupDescription>
The Fire and Emergency Services (F&ES) communications over a site's private telephone system must provide the originating telephone number to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) or Automatic Location Identification (ALI) information.
Medium Severity
<VulnDiscussion>The implementation of Enhanced F&ES telecommunications services requires that the emergency services answering point or call center be able to automatically locate the calling party in the event they cannot provide their location. This is a two-part process. First the telephone system must be able to provide the answering station with the telephone number from which the emergency call originated. This is ANI information. Second, this phone number must be correlated to a physical address or location. This is called ALI information. ANI information comes from the telephone system controller. ALI information may come from an external database that associates the ANI information to the ALI information, or the telephone system controller may maintain the ALI database internally. If the ALI database is internal to the telephone system controller, emergency services answering point or call center only needs to receive ALI information, providing it contains the originating telephone number. For enterprise systems, the support for E911 by the enterprise Local Session Controller (LSC) (or any remote LSC construct) is governed by Federal Communications Commission (FCC) rules, as well as other federal, state, and local law. The design and implementation of all telephone system systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000420
1 Rule
<GroupDescription></GroupDescription>
The Fire and Emergency Services (F&ES) communications over a site's private telephone system must provide a direct callback telephone number and physical location of an F&ES caller to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) and extended Automatic Location Identification (ALI) information or access to an extended ALI database.
Medium Severity
<VulnDiscussion>Under Federal Communication Commission (FCC) rules and the laws of some states, the implementation of Enhanced F&ES telecommunications services requires that the emergency services answering point or call center must be automatically provided with enough location information so that emergency services personnel can locate the calling party within a specified radius at their exact location in the event they are unable to provide their location. This is a two-part process that is exacerbated if the call originates from a DOD telephone system. Some of the FCC rules and state laws address the telephone system issue. For enterprise systems, the support for E911 by the enterprise Local Session Controller (LSC) (or any remote LSC construct) is governed by FCC rules, as well as other federal, state, and local law. The design and implementation of all telephone system systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed. Public enhanced F&ES systems are implemented in conjunction with the local exchange carrier (LEC) using their central office switch (CO). When the designated F&ES number is dialed, the CO routes the call to the public F&ES answering point (PSAP) over special trunks that can provide the PSAP with the telephone number from which the emergency call originated and the geographic location of the originating telephone. The originating telephone number is provided as ANI information. The geographic location of the originating telephone is provided as ALI information. The ALI is generated from the ANI by looking up the ANI in a database. Typically, this function is performed by the LEC, and the ALI provided is the service delivery address for the telephone number. In some cases, the ALI information is housed in a database at the PSAP or a at a third-party provider such that the PSAP must make the "database dip" to identify the location of the caller. The information is regularly updated by the LEC based on new service deliveries and disconnections. This process does not go far enough if the originating telephone is behind (part of) a DOD telephone system. A DOD telephone system may serve a large building or multiple buildings in a campus setting. It may also serve small or large remote sites that are geographically distant from the main telephone system switch. As discussed above, the normal process provides the address where the LEC delivers its phone service for the calling number. While this address will serve to get emergency services personnel to the lobby of a building or the front gate of a campus, it will not provide the exact location of the caller. This is where the federal and state telephone system related requirements come in. Under these rules, a telephone system operator and the system itself must provide complete ANI and ALI information to the answering point such that emergency services personnel can easily locate the caller. The telephone system must provide the exact location of the originating telephone minimally within a reasonably small area of it. The location information provided for telephones behind a telephone system is called Phone Switch-ALI (PS-ALI). To implement this, the telephone system must first be able to provide the F&ES answering station with the telephone number from which the emergency call originated via ANI. If the answering point is outside the telephone system, the number provided must be the exact Direct Inward Dialing (DID) number of the telephone placing the call so the answering point can dial it directly. The number provided must not be that of an outbound trunk. This phone number must be correlated to its physical address or location within the facility via PS-ALI. To implement PS-ALI, the owner/operator of a telephone system is responsible for maintaining an up-to-date database containing the telephone number (DID number and/or extension number) and physical location of each telephone attached to the telephone system. This database is then used to provide the PS-ALI information to the ALI database(s) accessed by the F&ES answering point. In association with each telephone and telephone number in the telephone system, the PS-ALI information contained in the database includes the following: - The address of the site containing the telephone system unless provided to the answering point by the LEC as part of its ANI/ALI information. - The name (or number) of the building in which the telephone is located. - The address of the building in which the telephone is located. - The floor in the building on which the telephone is located. - The area or quadrant of the floor where the telephone is located. - The room or cubicle number where the telephone is located. Additional information should be provided to the F&ES answering point and emergency services personnel in the form of up-to-date facility maps and floor plans. The maintenance of facility maps, floor plans, and PS-ALI information to keep them up to date is critical to life safety and facility protection and security. This can be an onerous process in light of changes in the facility and moves, adds, and changes within the telephone system. Maintaining accurate location information is exacerbated in a VoIP telephone system due to the ability of an IP phone to change its physical location within the LAN (and possibly beyond) while keeping its telephone number without specific intervention from, or knowledge of, the telephone system operator. The PS_ALI database can quickly become inaccurate, which is a situation that could be life threatening. Automated systems can be used with a VoIP system and LAN to identify the general location of an IP phone within the facility based on the LAN switch and port to which the phone is connected. Once this information is obtained from the LAN, it is correlated with the documented location of the LAN switch and documented location of the outlet served by the switchport.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000430
1 Rule
<GroupDescription></GroupDescription>
The Fire and Emergency Services (F&ES) communications over a site's private telephone system must route emergency calls as a priority call in a nonblocking manner.
Medium Severity
<VulnDiscussion>When calling the designated F&ES telephone number, the call must go through regardless of the state of other calls in the system. Emergency calls must be treated as a priority call by the system. For enterprise systems, the support for E911 by the Enterprise Local Session Controller (LSC) (or any remote LSC construct) is governed by Federal Communication Commission (FCC) rules, as well as other federal, state, and local law. The design and implementation of all telephone systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000440
1 Rule
<GroupDescription></GroupDescription>
Eight hours of backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support Special-C2 users.
Medium Severity
<VulnDiscussion>Unified Capabilities (UC) users require different levels of capability depending on command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power. Interrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering uninterruptible power supply (UPS) needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. All elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000450
1 Rule
<GroupDescription></GroupDescription>
Two hours of backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support Immediate or Priority precedence C2 users.
Medium Severity
<VulnDiscussion>Unified Capabilities (UC) users require different levels of capability depending upon command and control (C2) needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power. Interrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering uninterruptible power supply (UPS) needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. All elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000460
1 Rule
<GroupDescription></GroupDescription>
Sufficient backup power must be provided for LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support non-command and control (C2) user accessible endpoints for emergency life safety and security calls.
Low Severity
<VulnDiscussion>Unified Capabilities (UC) users require different levels of capability depending on command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power. Interrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering uninterruptible power supply (UPS) system power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPSs, communications availability is reduced. All elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000470
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must filter inbound SIP and AS-SIP traffic based on the IP addresses of the internal Enterprise Session Controller (ESC), Local Session Controller (LSC), or Multifunction Soft Switch (MFSS).
Medium Severity
<VulnDiscussion>The SBC is in the VVoIP signaling between the LSC and MFSS. To limit exposure to compromise and denial of service, the SBC must only exchange signaling messages using the designated protocol (AS-SIP-TLS) with the LSC(s) within the enclave and the SBC fronting the MFSS (and its backup) to which the LSC is assigned. Similarly, an SBC fronting an MFSS must only exchange signaling messages with the MFSS and LSC(s) within the enclave and the SBCs fronting other MFSSs and the LSCs assigned to it. While the SBC is also required to authenticate the source and integrity of the signaling packets it receives, filtering on source IP address adds a layer of protection for the MFSS. This is also a backup measure in the event this filtering is not done on the CE-R. Internal to the enclave, filtering signaling traffic based on the IP address(es) of the LSC(s) within the enclave limits the ability of rogue Voice Video Endpoints attempting to establish calls or cause a denial of service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000480
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must be configured to terminate and decrypt inbound and outbound SIP and AS-SIP sessions to ensure proper management for the transition of the SRTP/SRTCP streams.
Medium Severity
<VulnDiscussion>The function of the SBC is to manage SIP and AS-SIP signaling messages. To perform its proper function in the enclave boundary, the SBC must decrypt and decode or understand the contents of SIP and AS-SIP messages. Additionally, the SBC can perform message validity checks and determine of an attack is being attempted. The SBC acts as an application-level proxy and firewall for the SIP and AS-SIP signaling messages.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000490
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must be configured to only process packets authenticated from an authorized source within the DISN IPVS network.
Medium Severity
<VulnDiscussion>The function of the SBC is to manage SIP and AS-SIP signaling messages. The SBC also authenticates SIP and AS-SIP signaling messages, ensuring they are from an authorized source. DOD policy dictates that authentication be performed using DOD PKI certificates. This also applies to network hosts and elements. SIP and AS-SIP are not secure protocols. The information passed during a call session is in human-readable plain text. To secure SIP and AS-SIP, TLS is used. TLS is PKI certificate-based and is used for AS-SIP message encryption, authentication, and integrity validation. NOTE: Authentication is provided by validating the sending appliance's public PKI certificate used to establish the TLS session. AS-SIP messages are not sent until the authenticated TLS session is established.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000500
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must be configured to only process signaling packets whose integrity is validated.
Medium Severity
<VulnDiscussion>The validation of signaling packet integrity is required to ensure the packet has not been altered in transit. Packets can be altered during uncontrollable network events, such as bit errors and packet truncation that would cause the packet to contain erroneous information. Packets containing detectable errors must not be processed. Packets can also be modified by a man-in-the-middle attack. The current Unified Capabilities Requirements (UCR) document specifies the hashing algorithm to be used during transmission.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000510
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must be configured to validate the structure and validity of SIP and AS-SIP messages so that malformed messages or messages containing errors are dropped before action is taken on the contents.
Low Severity
<VulnDiscussion>Malformed SIP and AS_SIP messages, as well as messages containing errors, could be an indication that an adversary is attempting some form of attack or denial of service. Such an attack is called fuzzing. Fuzzing is the deliberate sending of signaling messages that contain errors in an attempt to cause the target device to react in an inappropriate manner, such as failure that causes a denial of service or permitting traffic to pass that it would not normally permit. In some cases, a target can be flooded with fuzzed messages. The SBC must not act on any portion of a signaling message that contains errors. A malformed or erroneous message could be sent by the signaling partner and be properly hashed for integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000520
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must drop all SIP and AS-SIP packets except those secured with TLS.
Medium Severity
<VulnDiscussion>DISN NIPRNet IPVS PMO and the Unified Capabilities Requirements (UCR) require all session signaling across the DISN WAN and between the Local Session Controller (LSC) and EBC to be secured with TLS. The standard IANA assigned IP port for SIP protected by TLS (SIP-TLS) is 5061. DOD PPSM requires that protocols traversing the DISN and DOD enclave boundaries use the standard IP ports for the specific protocol. Because AS-SIP is a standardized extension of the SIP protocol and AS-SIP must be protected by TLS, AS-SIP-TLS must use IP port 5061. The VVoIP system may allow SIP and SRTP traffic encrypted and encapsulated using TLS on port 443 from cloud service providers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000530
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must be configured to manage IP port pinholes for the SRTP/SRTCP bearer streams based on the information in the SIP and AS-SIP messages.
Medium Severity
<VulnDiscussion>The function of the SBC is to manage SIP and AS-SIP signaling messages. The SBC also manages the SRTP/SRTCP bearer streams. The DISN IPVS PMO has determined that the SBC will pass the negotiated and encrypted SRTP/SRTCP bearer streams without decryption and inspection. This is because doing so will not provide a significant security benefit but would cause a significant delay with a resulting decrease in the quality of the communications. Encoded audio and video is difficult to impossible to determine if an attack is being perpetrated or if sensitive information is being improperly disclosed without reconstituting the analog audio and video signals and having a person listen and watch each communication. Due to the volume of communications, to do so would be nearly impossible.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000540
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) (or similar firewall type device) must perform stateful inspection and packet authentication for all VVoIP traffic (inbound and outbound) and deny all other packets.
High Severity
<VulnDiscussion>Once a pinhole is opened in the enclave boundary for a known session, the packets that are permitted to pass must be managed. If they are not properly managed, packets that are not part of a known session could traverse the pinhole, thereby giving unauthorized access to the enclave's LAN or connected hosts. One method for managing these packets is stateful packet inspection. This inspection minimally validates that the permitted packets are part of a known session. This is a relatively weak but somewhat effective firewall function. A better method is to authenticate the source of the packet as coming from a known and authorized source.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000550
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) (or similar firewall type device) must deny all packets traversing the enclave boundary (inbound or outbound) through the IP port pinholes opened for VVoIP sessions, except RTP/RTCP, SRTP/SRTCP, or other protocol/flow established by signaling messages.
High Severity
<VulnDiscussion>Once a pinhole is opened in the enclave boundary for a known session, the packets that are permitted to pass must be managed. If they are not properly managed, packets that are not part of a known session may traverse a pinhole, giving unauthorized access to the enclave's LAN or connected hosts. Another method for managing packets through a pinhole opened for a VVoIP session is to only permit packets to pass matching the expected protocol type, such as RTP/RTCP or SRTP/SRTCP. If only RTP/RTCP or SRTP/SRTCP packets are permitted to pass, this reduces the exposure presented to the enclave by the open pinhole. Additional flows or protocols may be permitted if specifically required for an approved function and establishment is signaled or controlled by the signaling protocol in use by the system. An example of this is the transmission of H.281 far end camera control messages for a video conferencing session. Using AS-SIP for signaling, a UDP-based 6.4kbps H.224 over RTP control channel over which the H.281 far end camera control messages are transmitted might be established along with the media streams. This additional flow would require additional pinholes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000560
1 Rule
<GroupDescription></GroupDescription>
The Session Border Controller (SBC) must be configured to notify system administrators and the information system security officer (ISSO) when attempts to cause a denial of service (DoS) or other suspicious events are detected.
Medium Severity
<VulnDiscussion>Action cannot be taken to thwart an attempted DOS or compromise if the system administrators responsible for the operation of the SBC and/or the network defense operators are not alerted to the occurrence in real time.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000570
1 Rule
<GroupDescription></GroupDescription>
The Enterprise Voice, Video, and Messaging system connecting with a DISN IPVS must be configured to signal with a backup Multifunction Soft Switch (MFSS) (or SS) if the primary cannot be reached.
Medium Severity
<VulnDiscussion>Redundancy of equipment and associations is used in an IP network to increase the availability of a system. Multiple MFSSs in the DISN NIPRNet IPVS network and multiple SSs in the DISN SIPRNet IPVS network have been implemented to provide networkwide redundancy of their functions. They are intended to work in pairs so that one can provide its backbone services to multiple LSCs that are configured to use one as a primary and the other as a backup. This is necessary to the maintenance of backbone functionality in the event there is a circuit (network path) failure, an MFSS or SS failure, or one of the sites housing an MFSS or SS is lost or the MFSS or SS becomes unavailable. Based on this, when establishing a call on the WAN, each LSC must be configured to signal with a backup MFSS or SS in the event it cannot reach its primary.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000580
1 Rule
<GroupDescription></GroupDescription>
The Multifunction Soft Switch (MFSS) must be configured to synchronize with at minimum a paired MFSS and/or others so that each may serve as a backup for the other when signaling with its assigned Local Session Controller (LSC), thus improving the reliability and survivability of the DISN IPVS network.
Medium Severity
<VulnDiscussion>MFSSs are critical to the operation of the DISN NIPRNet IPVS network. They broker the establishment of calls between enclaves. An MFSS provides the following functions: - Receives AS-SIP-TLS messages from other MFSSs and a specific set of regionally associated LSCs to act as a call routing manager across the backbone. - Sends AS-SIP-TLS messages to interrogate the ability of another MFSS or an LSC to receive a call, whether routine or priority. - Sends AS-SIP-TLS messages to manage the establishment of priority calls and the preemption of lower priority calls to LSCs and other MFSSs. - Once a "trunk side" session request is received, the MFSS determines if the destination is one of its assigned LSCs. If so, it interrogates that LSC to determine if it can receive the call. If so, it signals to establish the call. If the destination is not one of its LSCs, it signals with other MFSSs to locate the destination LSC and then the remote MFSS negotiates with its LSC. - Acts as a backup MFSS for LSCs assigned to other MFSSs as primary. An LSC must be able to signal with an MFSS to establish any call across the DISN WAN. LSCs do not interact directly with LSCs. This hierarchical arrangement is required in order to manage and establish priority calls and manage access circuit budgets. Each LSC must have a backup MFSS. In support of this function, MFSSs must be operated in pairs with all the information about its assigned LSCs replicated across the pair.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-VOIP-000590
1 Rule
<GroupDescription></GroupDescription>
A MAC Authentication Bypass policy must be implemented for 802.1x unsupported devices that connect to the Enterprise Voice, Video, and Messaging system.
Medium Severity
<VulnDiscussion>MAC Authentication Bypass (MAB) is not a sufficient stand-alone authentication mechanism for non-802.1x supplicant endpoints. Additional policy-based validation techniques must be developed to ensure that 802.1x exempted devices are properly tracked and controlled to prevent compromise of the underlying 802.1x system and allow unapproved devices to access the Enterprise Voice, Video, and Messaging system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>