Enterprise Voice, Video, and Messaging Policy Security Requirements Guide

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.