Voice Video Services Policy Security Technical Implementation Guide

Media Gateway Control Protocol (MGCP) is a protocol that is used between Media Gateway Controllers (MGCs), Media Gateways (MGs), and other MGs to exchange sensitive gateway status and zone information as well as establish sessions via the MG. MGCP is a clear text human readable protocol. This information is critical in the setup and completion of voice calls from one VoIP zone to another VoIP zone or more typically from a VoIP zone to a TDM zone. If this information is poisoned or if collected and used by an unauthorized unscrupulous individual, the effects to the VoIP environment could be detrimental. Denial-of-service or fraudulent system use are only two of the potential compromises. As such, MGCP messages must be protected from eavesdropping, man in the middle, and replay attacks. To protect MGCP, Request for Comment (RFC) 2705 which defines MGCP outlines and recommends the use of IPsec for encryption and authentication between gateways. This recommendation primarily applies to the use of MGCP across unprotected WANs like the Internet. This extends to use on NIPRNet as well. A follow-on protocol defined jointly by the IETF in RFC 3435 and the ITU-T in Recommendation H.248.1 is MEGACO/H.248 which provides the same general functionality as MGCP. RFC 3435 also requires that H.248 packets be authenticated and/or encrypted using IPsec. Unfortunately there is not widespread support by MGCs and MGs for IPsec protection and therefore we must rely on external IPsec VPNs when traversing the WAN. When confined within the LAN, we can protect MGCP in a number of ways without IPsec.

VVoIP networks increasingly represent high-value targets for attacks and represent a greater risk to network security than most other network applications; hence, it is imperative that the voice network and supporting data networks be secured as tightly as possible to reduce the impact that an attack can have on either network. Segregating voice traffic from data traffic greatly enhances the security and availability of all services. Further subdivision of the voice and data networks can further enhance security. Achieving the ideal security posture for voice and data would require two physically separate and distinct networks (including cable plant), much as is the case with traditional voice and data technologies. Although this might be considered for the most demanding security environments, it works against the idea of convergence and the associated cost savings expected by having one network (and cable plant). Logical separation of VVoIP components and data components can be accomplished at both Layer 2 using Virtual Local Area Networks (VLANs) and Layer 3 using IP addressing. While these methods are not security mechanisms, they do provide a derived security benefit by easing management of filtering rules and obfuscating or hiding addresses and information that an attacker could use to facilitate an attack. Separation may also prevent an attack on one network from affecting the other. These methods make it harder for an attacker to be successful and help to provide a layered approach to VVoIP and network security. Segregating data from telephony by placing VVoIP servers and subscriber terminals on logically separate IP networks and logically separate Ethernet networks while controlling access to these VVoIP components through filters will help to ensure security and aid in protecting the VVoIP environment from external threats. In addition, further subdivision of those components is necessary to protect the telephony applications running across the infrastructure. Layer 3 address separation is the first layer in our layered defense approach to VVoIP security. It allows the use of switches, routers, and firewalls with their associated access control lists (ACL) and other processes, to control traffic between the components on the network. To provide address separation, best practices dictate that all like components be placed in like address ranges. Therefore VVoIP components (i.e., Gatekeepers, Call Managers, voice mail systems, IP Subscriber Terminals etc.) will be deployed within their own, separate private IP network, logical sub-network, or networks. The combination of logical data and voice segmentation via addressing and VLANs coupled with a switched and routed infrastructure strongly mitigates call eavesdropping and other attacks. In addition, limiting logical access to VVoIP components is necessary for protecting telephony applications running across the infrastructure. Separating data from telephony by placing VVoIP servers and subscriber terminals on logically separate IP networks while controlling access to these VVoIP components through IP filters will help to ensure security and aid in protecting the VVoIP environment.

An IPT system is built on an IP infrastructure based on layer 2 and layer 3 switches and routers, which comprise the network’s access and distribution layers respectively. The layer 2 switches found at the access layer provide high port density for both host and IP phone connectivity as well as layer 2 services such as QoS and VLAN membership. (It should also be mentioned that some access layer switches can also do layer 2 and 3 filtering.) Guidelines and requirements for securing access layer devices including any associated cross-connect hardware can be found in the Network Infrastructure STIG. Layer 2 network segregation is the second layer in our layered defense approach to VoIP security. Voice traffic must be isolated from data traffic using separate physical LANs or Virtual LANs. The combination of data and voice segregation and segmentation using VLANs along with a switched infrastructure strongly enhances the security posture of the system. This will also help to mitigate call eavesdropping and other attacks. VLAN technology has traditionally been an efficient way of grouping users into workgroups to share a specific network address space and broadcast domain regardless of their physical location on the network. Hosts within the same VLAN can communicate with other hosts in the same VLAN using layer-2 switching. To communicate with other VLANs, traffic must go through a layer 3 device where it can be filtered and routed. VLANs can offer significant benefits in a multi-service network by providing a convenient way of isolating VVoIP equipment and traffic from the data equipment and traffic. When VLANs are deployed, excessive broadcast and multicast packets present in the normal data traffic will not disrupt IPT services. As with data networks, IPT equipment and instruments should be logically grouped using multiple VLANs such that IP Phones share their VLANs only with other IP Phones, gateways with like gateways, and so on. Each type of VVoIP device would have mutually exclusive VLANs. This forces layer 3 routing and thereby enables all the filtering capabilities of the layer 3 devices. Additionally, each server type should have its own VLAN. Private server VLANs would prevent a compromised server from attacking another server on the same VLAN at layer two. Since all the devices on any given VLAN would have the same Layer 2 through 4 (at least) characteristics the filtering rules become easier to develop, deploy, and manage. Additionally, the implementation of VLANs helps to mitigate the risk of attacks sourced from the data VLANs such as virus driven DoS attack or packet sniffing. In addition, placing voice and data traffic into separate VLANs will reduce competition for the network and thus reduce latency (queue/wait time) for transmission services, which will reduce the possibility of denial of voice services. This also reduces the Ethernet broadcast domain thereby reducing network overhead. Since VoIP is very latency sensitive this segmentation approach is the most economical way to improve performance in an existing network infrastructure. This finding can be reduced to a cat III in the event the system minimally implements one VLAN for endpoints and one for the core equipment. This may not be a finding under certain circumstances such as in the case of a small footprint tactical system where there are a limited number of VVoIP instruments (i.e., 20). This package system must have been accredited via the appropriate test exercises and configured in accordance with the accreditation. This override is partially driven by the difficulty in supporting a complex configuration for these small systems in deployed environments. This Severity Override does not apply to strategic systems (i.e., systems implemented on a base or fixed DOD facility) or large relatively fixed tactical deployments.Information Assurance OfficerDCBP-1, DCPA-1, ECSC-1

Voice Video and Unified Mail services are high-availability systems that must be separated from all other traffic. Unnecessary services will degrade performance. The RTS traffic may have latency issues if the support services also provide for other data elements and servers. This could result in lag or drop outs during calls, or denial of service in extreme circumstances. The Defense Switched Network (DSN) STIG has been sunsetted. It is available on IASE in the Sunset Products page for telecommunications to be used for reference (https://iase.disa.mil/stigs/sunset/telecomm/Pages/index.aspx). The Voice Video Services Policy STIG, VVoIP STIG, Voice Video Endpoint SRG, and Voice Video Session Mgmt SRG contain the current guidance the DSN STIG covered. Additionally, the underlying OS, any attached database, and any applications providing ancillary functions must be assessed using the most appropriate guidance SRGs/STIGs.

Unified Mail services are subject to the guidance and requirements in the Voice VIdeo STIGs. Older voice mail systems/servers commonly use proprietary Oss, while newer ones often run on Windows or Linux. The Defense Switched Network (DSN) STIG has been sunsetted. It is available on IASE in the Sunset Products page for telecommunications to be used for reference (https://iase.disa.mil/stigs/sunset/telecomm/Pages/index.aspx). The Voice Video Services Policy STIG, VVoIP STIG, Voice Video Endpoint SRG, and Voice Video Session Mgmt SRG contain the current guidance the DSN STIG covered. Additionally, the underlying OS, any attached database, and any applications providing ancillary functions must be assessed using the most appropriate guidance SRGs/STIGs.

In traditional TDM phone systems, personal voicemail settings and greetings are accessed / configured by the subscriber/user on traditional voicemail servers via the traditional telephone. Control commands are dialed using the keypad and transmitted using Dial-Tone Multi-Frequency (DTMF) audio tones. The voice greetings are transmitted using normal audio as well. The audio can be analog or digital, which is encoded in whatever coding scheme is used by the local PBX. In IP based phone systems access to the voicemail server carries the same vulnerabilities as the IP voice communications carried by the system. As such access to voicemail for the purpose of creating greeting messages, retrieving voicemail, or adjusting personal settings, must be encrypted on the IP network. In part this is because anyone with a sniffer and access to the right LAN segment can acquire the subscriber’s account and password information. With this intercepted information a hacker could gain access to the subscribers voice mail account, intercept sensitive information, and/or perform other destructive actions. Once access to settings is achieved there the intruder could change greetings or possibly forward all voicemails received. Encryption of the voice message traffic as well as control from the phone’s dial-pad falls under the normal requirement for the encryption of VoIP signaling and media. In the event the subscriber’s personal settings are accessible via a “web” connection using a browser on the subscriber’s desktop or phone, the connection must use HTTPS and TLS minimally to protect the user’s logon credentials. Additionally, the voicemail system/server, which provides this service via a web server application, must be configured in accordance with the “private web server” requirements in the Web Server STIG/Checklist. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Application of features and potential call redirection by unauthorized users.Information Assurance Officer

Per other requirements, the network configuration information and settings on a VoIP instrument must be protected by a password or PIN. VVoIP endpoints do not typically provide automated PIN/password management. PINs that are not managed or required to be changed are most likely never changed, therefore they are easily compromised or guessed. Additionally as SA personnel change, the group passwords and PINs they know and use must be changed. As such, the organization must have and follow a policy and procedure for managing the passwords or PINs used to access the local VoIP phone network configurations. Such a SOP should address password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage. NOTE: Most instruments will only accept numerical input therefore a PIN is used. Some instruments may accept alpha characters for passwords. These factors help determine the password/PIN complexity that is achievable. NONEDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Loss of confidentiality. Password or PIN code compromise. As compromise is easier or more likely if PINs are not managed.Information Assurance Officer

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. This, however, could be done easier with older analog systems by tapping an existing analog line. With VoIP, 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, but 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, as well as a short time thereafter, to facilitate additions and troubleshooting. This applies to initial system setup and to any subsequent large redeployments or additions. Normal, day to day, “moves, adds, and changes” will require manual registration. Since, it may be possible for an unauthorized VoIP terminal to easily be added to the system 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 pre-authorized terminals. This feature would support VoIP terminals that are DAA 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 auto-detection/registration is permitted. This will also aid in C&A efforts. NONEUnauthorized use or abuse of the systemInformation Assurance Officer

Some VVoIP hardware endpoints and hardware based VTC endpoints have a second Ethernet port on the device to provide a connection to external devices such as a. This port is typically called a “PC Port”. This is done so that a can share a single network cable drop and LAN access switchport. The PC port can, in general, support any device requiring an Ethernet connection. In theory, a VoIP phone, a desktop VTC unit, and a workstation could be daisy chained on a single LAN drop. These PC ports are supported by an embedded three port Ethernet switch or a hub. Hubs cannot support VLANs and therefore cannot be used to daisy chain VVoIP endpoints and non VVoIP devices in DoD networks. A switch must be used because the VVoIP or VTC endpoint must be capable of maintaining the separation of the voice (VVoIP), data, VLANs as well as the VTC VLAN and PC Comm Client VLAN if present. For example the attached PC must not be able to directly access the phone’s or VTU’s configurations or communications traffic. VAN separation helps to prevent this. NOTE: the switch or endpoint will typically utilize 802.1Q trunking (VLAN tagging) but may use some other means to separate voice and data traffic. Typically when 802.1Q VLAN tagging is used, the phone firmware tags the VoIP packets while the embedded switch passes all packets without modification. This permits devices connected to the PC port to tag their packets and assign the proper VLAN to their traffic type. 802.1Q VLAN tagging enables the LAN to better maintain separation of the traffic and is therefore the preferred method. VVoIP 5700 NONEDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Loss of confidentiality. Degradation of the data and VoIP network segregation and associated problems.Physically disable or incapacitate the PC port so that it cannot be activated and used. Information Assurance Officer

Previous requirements in this STIG/Checklist define the need for dedicated VVoIP VLANs and IP subnets to provide the capability for VVoIP system access and traffic control. This control is implemented through the use of a properly designed set of ACLs on the LANs routing device(s) (router or layer-3 switch(s) capable of implementing ACLs) for each of the defined VLAN/subnets implemented. This requirement defines the ACLs that manage the flow of traffic between the various VVoIP VLAN/subnets. As a refresher, the VLAN/subnets are defined as follows: > Hardware Endpoints: multiple VLAN/subnets generally in parallel with data LAN VLANs the number of which is dependant on the size of the LAN and as required for the reduction of broadcast domains per good LAN design. For small networks there will be a minimum of one. > Software endpoints on workstations: multiples as with hardware endpoints. > VVoIP system core control equipment containing the LSC, endpoint configuration server, and DHCP server if used, etc > VVoIP system management VLAN which is separate from the general LAN management VLAN > Media gateways to the DSN and PSTN > Signaling gateways (SG) to the DSN > DoD WAN access VVoIP firewall (EBC) > Voicemail / Unified Messaging Servers. These may need to be accessible from both the voice and data VLANs. > UC servers such as those supporting IM/presence, “web” browser based conferencing, and directory services. These may need to be accessible from both the voice and data VLANs. NOTE: The VLAN/subnets and associated ACLs need only to be assigned / applied for devices that exist in the VVoIP system. The VLAN / ACL design may change depending upon the location and physical makeup of the VVoIP core equipment. An example of this is if a MG and SG reside on the same platform and both use the same Ethernet LAN connection(s) (and potentially the same or different IP address(s)), then separate VLANs are not needed for the MG and SG but the ACL protecting them may need to be adjusted accordingly. In general the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address / subnet, protocol type, and associated standard IP port for the protocol. In general the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system The “Procedure Guide: defines a nominal design for the ACLs for each VLAN interface. Validation that they are implemented will be done via a series of computing checks. Information Assurance Officer

There are several reasons why DSN voice traffic must use a locally implemented MG connected to a DSN service provider using the appropriate type of trunk based on the site’s need to support C2 communications, including: - VVoIP has the potential to significantly degrade the standard data enclave boundary protection when the data enclave firewall handles VVoIP traffic, unless specifically designed to. VVoIP must not traverse a standard data firewall except under certain circumstances. - For confidentiality, use of a MG eliminates the need for encryption on an IP WAN by placing the voice traffic on a traditional TDM network where the communications are more secure. Physical access to the wire or TDM switch is required to compromise TDM communication. - For availability and C2 support, VVoIP systems from different vendors may not be interoperable via IP. DoD’s efforts to develop interoperable standards with vendor assistance has reduced this risk. - The use of a MG converts each vendor’s implementation to a common interoperable system, the TDM DSN.

VVoIP systems and particularly voice telecommunications systems (that is to say phone systems) are considered critical infrastructure for communications, security, and life safety. As such they are considered mission critical and we have become accustomed to their high reliability and availability which is generally on the order of 5 nines. Many VVoIP systems are based on general-purpose operating systems such as Windows, Unix, LINUX as well as database and web server applications such as MS-SQL, Oracle, IIS, Tomcat, and others. Additionally, vendors of these systems usually customize or only use portions of the general-purpose operating systems and applications. Vendors also use and potentially customize open source software (OSS). Vulnerabilities are discovered every day in these general-purpose operating systems and applications by the community their original vendors. The vendors of these general-purpose systems and applications (such as Microsoft and others) routinely provide patches for their products to address bugs and vulnerabilities while other vendors and the OSS community provide upgraded versions of the software. These vulnerabilities and their mitigations usually appear in the DOD’s Information Assurance Vulnerability Management (IAVM) process as Information Assurance Vulnerability Alerts (IAVAs). The process mandates that these IAVAs be addressed in a specific time frame based on the severity of the issue. Many times the mandated “fix” is to apply the original vendors patch or to upgrade to the “fixed” version of the software that has the vulnerability. Due to the mission critical nature of our voice telecommunications systems, owners and operators must be cautioned against applying patches to their systems that are provided by the original vendor of the general-purpose operating systems and applications used in their systems as these may severely and adversely affect the operability of a portion of the system or may cause the system to crash. Significant down time could result which would amount to a self imposed denial of service. To prevent operability issues and downtime to the greatest extent possible, the VVoIP system vendor must first determine if the OEM vulnerability and mitigating patch is applicable to their system or a portion thereof, and then test the mitigation/patch to validate that it will not degrade the system or its security. The IPT / VoIP vendor may have to modify the OEM patch or produce their own patch before releasing it to their customers. Obtaining a vendor tested and vendor approved patch from the system vendor provides the greatest assurance that responding to an IAVA will not involve a negative impact on the system. To aid in this process, VVoIP system vendor must be advised of IAVAs that may apply to their systems. This is best accomplished by asking the vendor if the CVE or OEM patch number noted in the IAVA applies to your system and version of code. If so, they probably already have a tested and approved patch available for their customers. If not they will be alerted to the fact they need to provide one or test and approve the application of the OEM mitigation. Denial of Service. Patches that have not been approved and provided by a vendor and/or applied in conflict with vendor’s instructions can break features or disable the system.Information Assurance Officer

PC based communications applications rely on many different factors, but are dependant upon the platform on which they operate. A PC could be dedicated to a task, protected, and controlled such that it is highly available for mission critical applications and communications. However, a user’s general purpose PC or other computing device may not be highly available for mission critical communications, particularly if it is not dedicated to that task. This because it supports many applications and functions while being connected to a network through which any number of threats can come. Mission critical applications and communications are also negatively affected if the PC is powered off, busy with another process, the communications application is not loaded or running properly, or if the PC is compromised and/or is having operational problems. While a fixed desktop or tower PC may be kept in a powered on and network connected state most of the time, a portable PC (laptop) is much more likely to be powered off and disconnected from the network. There is more chance that the PC and communications application won’t work, or be available, when needed compared to a dedicated device such as purpose built hard phones or dedicated PCs. Power for operating the PCs is another consideration in our discussion of their support for assured services and mission critical systems, users, and locations. If there is no power in the user’s workspace, the PC will not function unless a backup power supply is provided. Thus may be provided using a battery based Uninterruptible Power Supply (UPS) or a backup generator. Either solution is very costly when providing backup power to the workspace for the PC, particularly for large numbers of users. Provisions for light and other environmental factors may also be necessary adding to cost. On the other hand, power is much more easily provided to a hardware based phone from the wiring closet using the LAN cabling. A UPS or generator will still be needed but in a centralized location reducing cost. Another factor is the robustness and reliability of the network to which the PC is connected. As noted above, DoD networks can and must be designed and controlled to provide the reliability and robustness needed to support assured service. This can work well for a dedicated communications endpoint but not necessarily for a PC communications application. This is because the PC will be connected to the portion of the LAN that carries normal data traffic by default. That is the portion of the LAN that can be compromised and degraded by various DoS attacks and other issues making it difficult for this portion of the LAN to provide assured service. The VoIP STIG defines some of the LAN requirements for the support of assured service, most notably the separation of the voice assets and traffic on the LAN from the data assets and traffic while maintaining a converged LAN architecture. Various solutions may also be available that can allow a PC to mitigate or manage these issues. These will be discussed later in the LAN use case section of this STIG. A remotely connected PC cannot be relied upon to support assured service if it is connected to a non-DoD network such as an Internet connected LAN or the internet itself. This is due to lack of DoD control over the network to which it is attached. While most non-DoD LANs and the Internet are relatively reliable and may be robust regarding bandwidth, there is no control over the conditions in, or the availability of, these networks, whether it is the LAN or WAN. Based on the factors noted in the previous paragraphs, PCs cannot provide the reliability and availability required for assured service when compared to the reliability and availability specifications for a LAN supporting assured service. These factors make it difficult to consider a user’s general purpose fixed, or portable, PC as being a stable platform for mission critical communications in an assured service sense, even though that is desired. All of these factors also affect non-assured service systems that provide life safety and emergency communications. In the future, PC and PC based communications application vendors may solve these problems and provide us with fully assured service capable PC based communications on a standard general purpose, general use platform at a reasonable cost. These issues do not, however, preclude a PC based communications application from attempting to place and receive priority communications sessions. A C2 user may use this type of end instrument for the origination of, or reception of routine and non-routine calls at their discretion, as long as a purpose built instrument or other backup communications system/device is also available for use as a backup communications method when necessary. This however, may not be feasible in all situations such as when using a portable PC outside of the normal workspace. NONEThe reliance of C2 and Special-C2 users on this method of communications for assured service communications when assured service failure is highly likely.Information Assurance OfficerInformation Assurance Manager

PC based communications applications rely on many different factors, but are dependant upon the platform on which they operate. A PC could be dedicated to a task, protected, and controlled such that it is highly available for mission critical applications and communications. However, a user’s general purpose PC or other computing device may not be highly available for mission critical communications, particularly if it is not dedicated to that task. This because it supports many applications and functions while being connected to a network through which any number of threats can come. Mission critical applications and communications are also negatively affected if the PC is powered off, busy with another process, the communications application is not loaded or is not running properly, or if the PC is compromised and/or is having operational problems. While a fixed desktop or tower PC may be kept in a powered on and network connected state most of the time, a portable PC (laptop) is much more likely to be powered off and disconnected from the network. There is more chance that the PC and communications application won’t work, or be available, when needed compared to a dedicated device such as purpose built hard phones or dedicated PCs. Power for PCs is another consideration in our discussion of their support for assured services and mission critical systems, users, and locations. If there is no power in the user’s workspace, the PC will not function unless a backup power supply is provided. Thus may be provided using a battery based Uninterruptible Power Supply (UPS) or a backup generator. Either solution is very costly when providing backup power to the workspace for the PC, particularly for large numbers of users. Provisions for light and other environmental factors may also be necessary adding to cost. On the other hand, power is much more easily provided to a hardware based phone from the wiring closet using the LAN cabling. A UPS or generator will still be needed but in a centralized location reducing cost. Another factor is the robustness and reliability of the network to which the PC is connected. As noted above, DoD networks can and must be designed and controlled to provide the reliability and robustness needed to support assured service. This can work well for a dedicated communications endpoint but not necessarily for a PC communications application. This is because the PC will be connected to the portion of the LAN that carries normal data traffic by default. That is the portion of the LAN that can be compromised and degraded by various DoS attacks and other issues making it difficult for this portion of the LAN to provide assured service. This STIG defines some of the LAN requirements for the support of assured service, most notably the separation of the voice assets and traffic on the LAN from the data assets and traffic while maintaining a converged LAN architecture. Various solutions may also be available that can allow a PC to mitigate or manage these issues. These will be discussed later in the LAN use case section of this STIG. A remotely connected PC cannot be relied upon to support assured service if it is connected to a non-DoD network such as an Internet connected LAN or the internet itself. This is due to lack of DoD control over the network to which it is attached. While most non-DoD LANs and the Internet are relatively reliable and may be robust regarding bandwidth, there is no control over the conditions in, or the availability of, these networks, whether it is the LAN or WAN. Based on the factors noted in the previous paragraphs, PCs cannot provide the reliability and availability required for assured service when compared to the reliability and availability specifications for a LAN supporting assured service. These factors make it difficult to consider a user’s general purpose fixed or portable PC as being a stable platform for mission critical communications in an assured service sense even though we desire it to be so. All of these factors also affect non-assured service systems that provide life safety and emergency communications. In the future, PC and PC based communications application vendors may solve these problems and provide us with fully assured service capable PC based communications on a standard general purpose, general use platform at a reasonable cost. These issues do not, however, preclude a PC based communications application from attempting to place and receive priority communications sessions. A C2 user may use this type of end instrument for the origination of, or reception of routine and non-routine calls at their discretion, as long as a purpose built instrument or other backup communications system/device is also available for use as a backup communications method when necessary. This however, may not be feasible in all situations such as when using a portable PC outside of the normal workspace. Note: Voice communications is the most critical communications service for C2 users. While VTC and collaboration is an important C2 tool, a telephone call is the minimal method needed to give and receive orders. Since a PC based application may not be available at all times, backup voice communications methods are needed. This could be accomplished in several ways. Minimally, in the normal workspace, there needs to be a hardware based telephone, either IP or otherwise, connected to a different portion of the network than the PC. While a hardware based IP phone could be associated with the PC, if the portion of the network serving the PC was the cause of the PC being inoperable for C2 communications, the phone might also not be available or operational. This is “not a finding” in the event the PC, PC communications application, and the network to which it is attached can be proven to provide the reliability and availability needed to support assured service communications. This would be approximately equal to that achieved using an ASLAN and purpose built hardware based endpoints. Applicability of this requirement can vary based on the specific use case and situation. For example, this is “not applicable” in the event a C2 user is in a situation where there is no need to place or receive priority calls. In a remote connectivity use case, a DoD provided PED, private cell phone or regular phone could serve as backup. Denial of service for a C2 or Special-C2 user resulting in the inability to place an assured service call.Information Assurance OfficerDesignated Approving AuthorityInformation Assurance Manager

Microphones used with VTC systems and devices are designed to be extremely sensitive such that people 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 canceling microphone may be required. A push to talk 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 for 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 since 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.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECND-1, ECSC-1

When communicating using a PC based voice, video, UC, or collaboration communications application, the user must protect the information displayed from being viewed by individuals that do not have a need-to-know for the information. This is of additional concern if the information is classified and the viewing party does not have proper clearance. This is also a vulnerability for hardware based communications endpoints that display visual information. The mitigation for this is to position the display such that it cannot be viewed by a passerby.NONEThe inadvertent and/or improper disclosure of sensitive or classified visual information.Information Assurance OfficerInformation Assurance Manager

Visual collaboration often requires the sharing or display of presentations, open documents, and white board information to one or more communicating endpoints. While the technology for doing this is different between hardware based VTC endpoints and PC based application endpoints, the vulnerability is the same. In both cases, the displayed information typically resides on a PC. While in presentation/sharing mode, care must be exercised so that the PC user does not inadvertently display and transmit information on their workstation which is not part of the communications session and not intended to be viewed by the other communicating parties. Users must be aware that anything they display on their PC monitor while presenting to a communications session may be displayed on the other communicating endpoints. This is particularly true when the PC video output is connected to a VTC CODEC since the information will be displayed on all of the conference monitors. This presentation/sharing feature could result in the disclosure of sensitive or classified information to individuals that do not have a validated need-to-know or have the proper clearance to view the information. Thus the presentation/sharing feature presents a vulnerability to other information displayed on the PC if the feature is misused. This is a problem when sharing (displaying) a PC desktop via any collaboration tool using any connection method. There is little that can be done to mitigate this vulnerability other than to develop policy and procedures to present to collaborative communications sessions. All users which perform this function must have awareness of the issues and be trained in the proper operational procedures. Such procedures may require that there be no non-session related documents or windows open or minimized on the PC while presenting or sharing. An additional requirement may be that the user may not permit others in a session to remotely control their PC. A SOP is needed that addresses mitigations for the vulnerabilities posed by PC data and presentation sharing. Such an SOP could include the following discussion. If a user needs to view non meeting related information while presenting to a conference, the PC external display port must be turned off or better yet, the cable disconnected. Dual monitor operation of the PC could mitigate this problem somewhat. The second monitor output would be connected to the CODEC which would serve as the second monitor. Using this method, any information may be viewed on the native PC monitor while the presentation can be displayed on the VTU presentation screen. NONEThe inadvertent and/or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.Information Assurance OfficerInformation Assurance ManagerOther

Visual collaboration often requires the sharing or display of presentations, open documents, and white board information to one or more communicating endpoints. While the technology for doing this is different between hardware based endpoints, and PC based application endpoints, the vulnerability is the same. In both cases, the displayed information typically resides on a PC. While in presentation/sharing mode, care must be exercised so that the PC user does not inadvertently display and transmit information on their workstation that is not part of the communications session and not intended to be viewed by the other communicating parties. Users must be aware that anything they display on their PC monitor while presenting to a communications session may be displayed on the other communicating endpoints. This is particularly true when the PC video output is connected to a VTC CODEC since the information is displayed on all of the conference monitors. This presentation/sharing feature could result in the disclosure of sensitive or classified information to individuals that do not have a validated need-to-know or have the proper clearance to view the information. Thus the presentation/sharing feature presents a vulnerability to other information displayed on the PC if the feature is misused. This is a problem when sharing (displaying) a PC desktop via any collaboration tool using any connection method. The mitigation for this vulnerability is to develop policy and procedures on how to securely present to collaborative communications sessions . All users that perform this function must have awareness of the issues and be trained in the proper operational procedures. Such procedures may require that there be no non-session related documents or windows open or minimized on the PC while presenting or sharing. An additional requirement may be that the user may not permit others in a session to remotely control their PC. A similar issue is that some PC based collaboration applications can permit a user to allow other session participants to remotely control their PC. Depending upon how this feature is implemented and limited, it could lead to undesired activities on the part of the person in control and possible compromise of information that is external to the collaboration session. This would be the case if such sharing or remote control provided access to the local hard drive and non session related applications or network drives accessible from the controlled PC. NONEThe inadvertent or improper disclosure of sensitive or classified information.Information Assurance OfficerInformation Assurance Manager

The VTC STIG discusses the possibility of undesired or improper viewing of and/or listening to activities and conversations in the vicinity of a hardware based VTC endpoint, whether it is a conference room system or an office based executive or desktop system. If this was to occur, there could be inadvertent disclosure of sensitive or classified information to individuals without the proper clearance or need-to-know. This vulnerability could occur if the endpoint was set to automatically answer a voice, VTC, or collaboration call with audio and video capabilities enabled, or if the endpoint was compromised and remotely controlled. The stated requirements and mitigations involve muting the microphone(s) and disabling or covering the camera(s). These or similar vulnerabilities could exist in PC based communications/collaboration applications due to an auto answer feature or compromised application or platform. As such, the simplest mitigation would be to only operate the software that accesses the microphone and camera when they are needed for communication. This does not work well for a unified communications application that is used to enhance our communications/collaboration capabilities since the application would be running most, if not all of the time when the PC is operating. In this case, the microphone could be muted and camera disabled in software as a mitigation. However, this also may not work well due to the possibility of the communications/collaboration application, microphone, or camera could be remotely activated if the platform or a communications application is compromised. In this case positive physical controls may be required. We must also rely on our defense in depth strategy for protecting our PC applications, including our communications applications, from compromise. Physical disablement such as unplugging from the PC, using a physical mute switch, or covering a camera could work if using external devices. However, this mitigation would not work for embedded microphones and cameras as is the trend in laptops and monitors today. While it may not be easily feasible to physically disable an embedded microphone, the lens of an embedded camera can be covered. NONEInadvertent disclosure of sensitive or classified information in aural or visual formInformation Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1

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. Our discussion here 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 which 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 utilize 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.Information Assurance OfficerInformation Assurance ManagerDCBP-1, DCCT-1, DCHW-1, EBCR-1, ECSC-1

While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be UC soft client accessories; these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in the topic of this section. Our discussion here 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 which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. 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 utilize 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.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1, PRTN-1

Users of PC based voice, video, UC, and collaboration communications applications must be aware of, and trained in, the various aspects of the application’s safe and proper use. They must also be aware of the application or service vulnerabilities and the mitigations for them. This awareness is supported by a combination of user training in the use of the application and any associated accessories as well as its limitations and vulnerabilities. Training is subsequently acknowledged through the signing of user agreements and bolstered by the distribution and utilization of user guides. NONEThe inadvertent and/or improper disclosure of sensitive or classified information.Information Assurance OfficerInformation Assurance Manager

User agreements must be accompanied with a combination of user training and user guides reinforcing the organization's policies and prohibitions for UC soft clients (voice, video, and collaboration communications software clients). The user agreement is required in the DoD and must contain site policy and acceptable use of information system assets. Users must read and sign the user agreement before receiving government-furnished hardware or software. This extends to gaining access to additional information systems, adding on applications, or receiving additional privileges. Policies must include acceptable use of the UC soft client application, UC soft client accessories, as well as web browsing, remote access, wireless use, and protection of controlled unclassified information (CUI). Minimally, the user agreement must be updated as privileges and additional applications are installed. User agreements must also be accompanied with user training and user guides that reinforce policies and provide additional relevant information.Information Assurance OfficerInformation Assurance Manager

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 user’s 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 since 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 that there will be no telephone available in the workspace if the PC is not powered on, or 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 work space as their only endpoint has several ramifications that must be considered. The following is a list of some of these: • 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 even 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 following: - 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 since 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 onto 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 C2 responsibilities, the IP equivalent of MLPP cannot function properly if 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 not functioning properly, they may not be able to reach the common use instrument depending upon 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 law suites for this eventuality. • The previous 2 items translate into the following: - The addition of common use hardware based instruments placed around the facility (for backup and emergency usage) along with the additionally required LAN cabling and access switch ports. While some may feel that this is not an IA issue, in reality it is since the discussion is truly 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. NONEThe inability to make an emergency or any call when the PC soft-phone/UC application is unavailable, particularly in an emergency situation. Information Assurance OfficerInformation Assurance Manager

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 upon 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.Information Assurance OfficerDesignated Approving AuthorityInformation Assurance Manager

This use case addresses situations whereby UC soft client applications on workstations are not the primary voice communications device in the work area. This means that 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 those 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) requirement that the Unified Capabilities (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.Information Assurance OfficerDesignated Approving AuthorityInformation Assurance Manager

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 make use of 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 unified communications 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, since 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: we have established that a network supporting a CTI application must be segregated from the enclave and that this can be accomplished by maintaining a closed network or a segregated and access controlled sub-enclave having appropriate boundary protection.Information Assurance OfficerInformation Assurance Manager

The primary reason for the implementation of the LAN architecture and security measures defined in this and other STIGs is to improve the survivability (availability) of the VVoIP communications service in whatever environment it is deployed. These measures are designed to protect the VVoIP service and infrastructure to the greatest extent possible in the event there is a compromise of an OS or application on a workstation or server attached to the data side of the LAN. If this occurs, the compromised platform could be used by an adversary to compromise the VVoIP communications or its supporting infrastructure. Such compromise can happen rather easily, particularly when a server is a web or application server or a workstation is used for web surfing or email. A secondary reason for the implementation of the LAN architecture and security measures defined is to help protect the confidentiality and integrity of the supported VVoIP communications. Based on these two reasons, the defined VVoIP architecture serves to segregate and hide the VVoIP communications and infrastructure (to the greatest extent possible on a converged LAN) from the data workstation users and associated platforms. While VVoIP systems deployed on a strategic B/C/P/S provide a combination of general business or administrative communications along with C2 communications, tactical deployments primarily support C2 communications. There is nowhere other than a tactical deployment that the availability, confidentiality, and integrity of a VVoIP communications service is as critical. Therefore the network supporting a tactical VVoIP communications system must follow the same guidelines as a network supporting a strategic VVoIP system or application. NOTE: Initial deployments may include as little as a half dozen workstations or as many as fifty. Once the initial deployment is in place, the network may grow and become relatively permanent as would be the case for a rear command or logistics center. NOTE: A shipboard LAN is minimally considered as a fixed tactical LAN but can also be considered as a Strategic LAN. This is because the installation is permanent within the confines of the mobile floating base. In other words, the base (AKA ship) moves without disrupting the LAN. This finding can be reduced to a CAT III in the event VVoIP 1930 is not a finding. VVoIP 1930 requires a benefit vs. risk analysis be performed and approval for reduced VVoIP IA configuration measures in highly mobile tactical LANs and systems supporting hardware or PC based voice, video, unified, and/or collaboration communications.Increased potential for the compromise of the VVoIP controllers, gateways, hardware based instruments, and other VVoIP infrastructure. Possible degradation of service on the hardware based phone system. Reduced availability, confidentiality, and integrity of the VVoIP service. Information Assurance OfficerInformation Assurance Manager

As discussed above, the network supporting a tactical VVoIP communications system must follow the same guidelines as a network supporting a strategic VVoIP system or application to help ensure the availability, confidentiality, and integrity of the communications service. An argument could be made that a tactical LAN and attached workstations might be less prone to compromise than a strategic LAN and its attached workstations therefore we do not need all these security measures for VoIP. This argument might be supported by the smaller size of a tactical LAN, particularly an initially deployed system, mission duration, and the ability to limit its usage to tactical applications. Unfortunately if the tactical LAN is connected to NIPRNet or the strategic LAN at the home base, it can still be compromised particularly if general web browsing is permitted and performed and email is used. Additionally, there is nowhere that C2 communications is more important than in the tactical LAN. Any decision to eliminate any of the protective measures for the C2 voice service that could negatively impact its reliability must be based in a risk assessment that weighs the benefits against the risks. Deployable packages that are designed to be initially deployed with a small footprint supporting or using PC soft-phones, which are then to be the basis of a larger network, must be configured, or be configurable, to support the separate VoIP and data zones as well as hardware based instruments and admission control for C2 communications as the deployed network and supported systems grow. The network will also include soft-phone protection zones as required in a strategic network if soft-phones are permitted to be used beyond the initial deployment. In general, larger relatively permanent tactical networks should be configured the same as a strategic network since similar vulnerabilities exist. As a result, if IA measures are to be relaxed for a highly mobile tactical network or deployable package, the reduction must be supported by an approved benefit vs. risk analysis. Approval must be given by the person or entity responsible for accepting the risk of operating the VVoIP system in a vulnerable manner. NOTE: This requirement does not apply to shipboard LANs since they are permanently installed. NONEIncreased potential for the compromise of the VVoIP controllers, gateways, hardware based instruments, and other VVoIP infrastructure. Possible degradation of service on the hardware based phone system. Reduced availability, confidentiality, and integrity of the VVoIP service. Information Assurance OfficerDesignated Approving AuthorityInformation Assurance Manager

Communications applications must be tested and subsequently certified and accredited for IA purposes. This includes the applications and any upgrades or patches. Since a UC soft client is typically supported by a larger VVoIP communications system, the security of the application will affect the security of the overall system. Therefore the C&A documentation for the UC soft client must be included in the C&A documentation for the overall VVoIP system. Subsequently the VVoIP system’s C&A documentation must be included in the C&A documentation for the LAN or enclave.Information Assurance OfficerInformation Assurance Manager

It is important that UC soft clients be tested and subsequently certified and accredited for IA purposes, to include upgrades or patches. Applications that have not been sufficiently vetted may introduce malware to the network or have security issues an adversary may manipulate.Information Assurance OfficerInformation Assurance Manager

It is important that UC soft clients be tested and subsequently certified and accredited for IA purposes, to include upgrades or patches. Applications that have not been sufficiently vetted may introduce malware to the network or have security issues an adversary may manipulate.Information Assurance OfficerInformation Assurance Manager

DoDI 8100.3 provides policy for the DoD that requires the testing and certification of telecommunications systems for Interoperability and Information Assurance (IA) while establishing an Approved Products List (APL) for certified and accredited products. Under Applicability and Scope, it states “This Instruction applies to the hardware or software for sending and receiving voice, data, or video signals across a network that provides customer voice, data, or video equipment access to the DSN, DRSN or PSTN.” Additional statements in this section expand this to most devices or systems that are associated with providing telecommunications service. The purpose of this testing is twofold. One aspect is to determine if a vendor’s product or system meets DoD functional requirements and that it can interoperate with established or existing DoD systems. The other aspect is to determine if the system can be configured to meet DoD IA requirements and operate at an acceptable level of risk. A product must be approved under both categories before listing on the APL. DoD components are required to fulfill their communications needs by only purchasing APL listed products, providing one of the listed products meets their needs. This means the APL must be consulted prior to purchasing a system or product. If no listed product meets the organization’s needs, they may sponsor a product for testing that does meet their needs. NOTE: The APL as created by this instruction was originally called the DSN APL and covered dial-up telecommunications systems or products providing unclassified communications. It has been expanded to cover additional types of approved products and has been renamed to the Unified Capabilities APL by the Office of the Assistant Secretary of Defense (OASD) for Networks and Information Integration (NII). Additional categories have been implemented for DRSN (classified communications) related systems/products and for IPv6 capable products. The APL can be found at http://jitc.fhu.disa.mil/apl/index.html. This APL is referred to as the DoD APL or UC APL. Tactical use cases or systems that do not provide access to the DSN, DRSN or PSTN which are private closed communications systems, may be accredited via the Information Support Plan (ISP) or Tailored Information Support Plan (TISP) process managed by the Office of the Secretary of Defense (OSD), Joint Staff J6I, and the Joint Interoperability Test Command (JITC) United States (US) Military Communications Electronics Board (USMCEB) Interoperability Test Panel (ITP). This policy applies directly to any PC communications application that provides voice communications services to and/or from the DSN, DRSN/VoSIP, or PSTN. This will most often be a soft-phone or unified communications application (with any associated accessories) that is associated with or supported by a DoD telephone system. The application may, or may not, provide additional communications services such as video, collaboration, or other unified communications services. This policy is extensible to other types of PC communications applications whose primary purpose may be VTC, IM, or collaboration, if the application or service provides interoperability with the DSN, DRSN/VoSIP, or PSTN typically through a gateway, or uses these systems for transport. NONEDe-certification of the supporting communications system or service.Information Assurance OfficerInformation Assurance Manager

One of the measures to protect UC soft clients and collaboration applications is to ensure the application originates from a reputable source. The source of these applications can vary depending upon the type of application. To protect DoD interests, the source of the application depends on the criticality of the communications method. One source for compromise of a communications application is the use of freeware or shareware applications. Communications applications that provide voice communications must be designed to properly interoperate with the VoIP system. These applications should be a standard product of the voice system vendor or a partner whose product is approved by this vendor. Some UC soft clients provide VTC and collaboration features and should be sourced from the voice system vendor. Applications providing VTC features that interoperate directly with a hardware based VTC system should be sourced from the VTC system’s vendor or a partner whose product is approved by this vendor. Other UC soft clients that provide collaboration services while also providing voice and video communications features must also be sourced from a major vendor in the business of providing collaboration systems or services. UC soft clients that provide multiple services such as IM, presence, voice, VTC, web conferencing, and so forth, may be integrated with the operating system, such as Microsoft’s Office Communications applications. Application sourcing can also be dependent on whether the application is to interoperate with hardware based communications system located and operated within an enclave or whether it is a system operated by an interagency or inter-base program. The vendor must be able to provide patches, upgrades or both to mitigate newly discovered vulnerabilities found in their product in a timely manner. Information Assurance OfficerInformation Assurance Manager

It is important that the PC Communications application is not modified during its delivery and installation. This can be a problem if the application is obtained from a source other than directly from it’s original developing vendor such as a third party download service. Any application that is not obtained from its original developing vendor could be modified to add some sort of malicious code that could affect the confidentiality, integrity, and availability of the communications supported by the application. Malicious code could also affect the platform on which the application is operated, the network to which the platform is attached, and the communications system with which the application operates. To mitigate this issue, it is highly recommended that vendors provide their applications in a digitally signed and hashed format such that the integrity of the application can be verified.NONECompromise of the supported communications or the supporting networkSystem AdministratorInformation Assurance Officer

Managing, mitigating, or eliminating a newly discovered vulnerably in a communications application is just as important as managing and mitigating the vulnerabilities of the platform supporting the application. PC communications applications must be patched or upgraded when a security related patch or upgrade is released by the vendor. While many vendors will release a patch to mitigate a vulnerability in an operating system or major application, other vendors will include the fix in a new version of the application. Multiple patches can also be rolled up into an upgrade. It is important to maintain the current patch and upgrade level of any communications applications installed on a PC. The purpose of this is to maintain the highest possible level of security for the application and the communications service(s) it provides.NONECompromise of the supported communications or the supporting network.Information Assurance Officer

PC voice, video, UC, and collaboration communications applications must not be operated in a manner that can compromise the platform if the application itself becomes compromised. One way to mitigate this possibility is to ensure that the application does not require administrative privileges to operate and that it is not operated with privileges that could be used to compromise the platform, other applications, or the network.NONECompromise of the supporting PC, attached network, and/or network resources.System AdministratorInformation Assurance Officer

During VVoIP endpoint registration with the session controller, a file is downloaded by the endpoint from the session manager containing specific configuration settings. This file contains the phone number assigned to the endpoint, the IP addresses for session management, the software menus specific to the system, the endpoint configuration password, the stored personal preferences and speed dial numbers, and other system operational information. These configuration settings can be updated by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded. The integrity of these files is critical to preventing compromise of the Unified Capabilities (UC) soft clients, the hardware endpoints, and the system itself. The best method for maintaining configuration file integrity is requiring they be digitally signed. This prevents man-in-the-middle attacks where the configuration file could be modified in transit or the source of the file spoofed. Digital signatures and the file integrity must also be validated before the configuration file is used.Reduce to a CAT III when vendor generated certificates are used instead of DoD PKI certificates.System AdministratorInformation Assurance Officer

All voice, video, UC, or collaboration communications endpoints must be configured to only associate with approved DoD controllers, gateways, and/or servers. While this is the norm for hardware based endpoints in a LAN, it is even more important for PC application based endpoints. Such endpoints must not accept service from just any available system. Such a system could actually be in a different organization than the one the application belongs to, depending upon how the application seeks out its controller/server. Peer-to-peer, or direct PC application-to-application communications are based on knowing the other endpoint’s IP address is not permitted. All communications applications must contact their designated session controller(s), gateway(s), or server(s) for authorization to operate. NOTE: This is the general rule for all communications types with the exception of point-to-point VTC sessions between hardware based VTC CODECs. An additional consideration is the reliability of a critical voice communications service and its continuity of operations. This is a prime concern for hardware based VoIP systems which are intended or are designed to provide assured service. Such critical systems must be supported by redundant controllers. If a soft-phone associated with such a system is to be reliable, it must be configured to interact with its primary controller(s) and at least one backup. NONECompromise of the supported communications or supporting PC.System AdministratorInformation Assurance Officer

DoD policies disallow general PC users from installing any unapproved application on their workstations or from attaching any unapproved or non-government furnished devices to them. Other DoD policies require users of GFE to limit their use to official business and not use them for personal business or other personal activities. Installation of VoIP and IM clients that associate themselves with, and connect to a public VoIP or IM service places the DoD system on which the client is installed at risk of, and provides an avenue for, its compromise and unauthorized access. Once compromised, the system could be used as a launching point for further compromise of the network or other DoD systems. Additionally, the use of these services also places the confidentiality of DoD information conveyed by them at risk. Such information could be sensitive or the collection of non-sensitive information over time could reveal sensitive information. Some services use standard ports 80 and 443 for web services which are generally never blocked. System AdministratorInformation Assurance Officer

The second mitigation for the vulnerability regarding personally installed apps and hardware is the administrative prevention of the installation of the applications in question by the PC user. This is generally handled by today’s policies and STIG requirements that are used to secure DoD workstations which limit the privileges of the workstation user. Users that are not given administrator rights on their workstations cannot install such applications. On the other hand, some users are given these rights. To cover those workstations on which the user can install software, the above policy must be enforced, and must be augmented by user awareness, training, and user agreements. The limitations of these IA controls are extensible to hardware devices that provide the same or similar functionality. Such a device is a stick phone, because it contains a client application. Such devices are available for commercial VoIP services such as Vonage and Skype. Another device that can be included under these guidelines is a PPG that connects a soft-phone to a traditional phone line permitting the uncontrolled bridging of voice networks. NONECompromise of the supporting PC, attached network, and/or network resourcesInformation Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1

DoDI 8550.1 Ports, Protocols, and Services Management (PPSM) is the DoD’s policy on IP Ports, Protocols, and Services (PPS). It controls the PPS that are permitted or approved to cross DoD network boundaries as well as mitigations for vulnerabilities inherent in the approved PPSs. Standard well known and registered IP ports and associated protocols and services are assessed for vulnerabilities and threats to the entire Global Information Grid (GIG) which includes the DISN backbone networks. The results are published in a Vulnerability Assessment (VA) report. Each port and protocol is given a rating of green, yellow, orange, or red associated with each of the 16 defined boundary types. Green means the protocol is relatively secure and is approved to cross the associated boundary without restrictions. Yellow means the protocol has issues that can be mitigated and it can be used if the required mitigations are used as noted in the VA. Red means that the protocol issues cannot be mitigated, is not secure, or approved, and in fact is banned when crossing that boundary. A new category is Orange which is the same as red except that the protocol is in use and cannot be removed from the network. It recognizes that the protocol exists on the network and is necessary but also mandates that new systems and applications must not be developed using this protocol whether it crosses a boundary or not. Some red and orange protocols have mitigations listed in their VA that must be used if the protocol is used during its remaining life. The information regarding the assessed ports and protocols and the defined boundaries is published in the PPS Assurance Categories Assignment List (CAL). See the Enclave and Network Infrastructure STIGS, the 8550.1, and the latest PPS CAL for a more complete discussion of this DoD program and policy. The PPSM information is available on the IASE and DKO/DoD IA Portal web sites. A portion of the DoDI 8550.1 PPS policy requires registration of those PPS that cross any of the boundaries defined by the policy that are “visible to DoD-managed components”. The following PPS registration requirement applies to all PPSs used by a Voice/Video/UC system to include the core infrastructure devices and its hardware based or PC application based endpoints whether or not a PPS crosses the IP based Enclave boundary to the DISN WAN or another enclave. The PPSM PMO is requiring internal PPSs to be registered in case they find their way to the DISN WAN.NONEDisconnection of the system or service.Information Assurance OfficerInformation Assurance Manager

Because vendors did not have interoperability, lacked end-to-end encryption, and did not provide assured service in support of Command and Control (C2) communications, VVoIP traffic originally was restricted to the local enclave. The DSN PMO, DISA Engineering, and Real Time Services (RTS) working group have been working to define network and system requirements to overcome the inherent obstacles in pursuit of a DISN wide interoperable assured service VVoIP or Voice Services network. VVoIP uses signaling protocols to set up and manage the communications session and the media transfer protocols carrying the communications. Both signaling and media protocols can be compromised when transmitted without encryption. To provide the assured service pre-emption and priority capabilities required for C2 telephone communications, DISA developed an extension to the SIP protocol called Assured Service SIP or AS-SIP. The common means of providing confidentiality and integrity for SIP signaling as well as providing session authentication is to encrypt it using TLS. The encryption algorithm, key strength, and key management processes are denied in the current version of the DoD Unified Capabilities Requirements (UCR) document available from the DISA voice Services PMO.

Because vendors did not have interoperability, lacked end-to-end encryption, and did not provide assured service in support of Command and Control (C2) communications, VVoIP traffic originally was restricted to the local enclave. The DSN PMO, DISA Engineering, and Real Time Services (RTS) working group have been working to define network and system requirements to overcome the inherent obstacles in pursuit of a DISN wide interoperable assured service VVoIP or Voice Services network. VVoIP uses signaling protocols to set up and manage the communications session and the media transfer protocols carrying the communications. Both signaling and media protocols can be compromised when transmitted without encryption. To provide the assured service pre-emption and priority capabilities required for C2 telephone communications, DISA developed an extension to the SIP protocol called Assured Service SIP or AS-SIP. The common means of providing confidentiality and integrity for SIP signaling as well as providing session authentication is to encrypt it using TLS. The encryption algorithm, key strength, and key management processes are denied in the current version of the DoD Unified Capabilities Requirements (UCR) document available from the DISA voice Services PMO.

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 of maintaining 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. As such this scenario has many benefits. Unfortunately, the reality of this implementation is that in order 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, 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 intra-site 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.Reduced to no finding when the site has a separate commercial phone system (dedicated PBX or discrete instruments) available for areas with long local service. Reduced to no finding when the site has with a separate DoD phone system (PBX or discrete instruments) with a network path that is geographically separate from the system under evaluation available for areas with long local service. Reduced to no finding when the site has backup VVoIP call control to maintain local internal and commercial service if network connectivity is severed from the remote centrally located session controller.

It is important that the vendor provided upgrades or patches are not modified during their delivery and installation. This can be a problem if the application is obtained from a source other than directly from it’s original developing vendor such as a third party download service. Any application that is not obtained from its original developing vendor could be modified to add some sort of malicious code that could affect the confidentiality, integrity, and availability of the communications supported by the application. Also malicious code could affect the platform on which the application is operated, the network to which the platform is attached, and the communications system with which the application operates. To mitigate this issue, it is highly recommended that vendors provide their applications, upgrades, or patches in a digitally signed and hashed format such that the integrity of the application can be verified.NoneCompromise of the supported communications or the supporting infrastructureSystem AdministratorInformation Assurance Officer

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 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%, C2 users is 99.997%, C2Routine only users (C2R) and non-C2 users is 99.9%. Similar availability and reliability through redundancy is needed to support routine user FES life-safety and security related communications. Reduced to CAT III when the LAN hardware does not directly support Special-C2 and C2 users. Information Assurance Officer

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 quickly 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%, C2 users is 99.997%, C2Routine only users (C2R) and non-C2 users is 99.9%. The physical paths 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. Reduced to CAT III when the LAN hardware does not directly support Special-C2 and C2 users. Information Assurance Officer

An uninterruptible power source for the LAN and VVoIP infrastructure is a necessity for the continued survivability, availability, and reliability of the VVoIP services. In traditional telecommunications systems the need for backup power is the same but it can be met generally at a single location, which is the phone switch location. The power required by the endpoints is generally provided by the phone switch to maintain basic dial tone services even though some “digital and feature phones require a local power supply. This is not possible in an IP/LAN based VVoIP network because the LAN infrastructure is geographically spread out to be within 100m cabling distance from each LAN endpoint. As such, the power, both primary and backup, must follow the NE to its location. Centrally located core equipment must also have a central uninterruptible power supply (UPS). The endpoints also need continuous power to maintain service. IP telephony endpoints require power to operate. This can be provided locally with a power brick (a small plug-in power adaptor/supply) and an AC outlet or can be provided by the LAN using Power Over Ethernet (POE) technologies. The UPS providing backup power to the LAN access switch can also provide backup power to the endpoint via POE if properly sized. If this is not the case, an individual UPS is required for each instrument supporting special C2 and C2 users of the proper capacity. Policy sets the minimum requirements for the backup power supplied to the VVoIP systems and the supporting LAN and VVoIP endpoints with emphasis on supporting C2 communications when primary power is lost. While this is a very valid case, it is also best practice, if not critical, to provide some level of backup power to the core systems, LAN, and endpoints that only support C2R and non-C2/admin users to support some level of reliable/survivable service, especially for emergency life-safety and security calls. NOTE: The requirement here for UPS support for C2R or Non-C2/admin users communications is negated in the event that such users have an alternate reliable means of communicating in such situations. Personal and potentially even government provided cell phones are not the answer since there are many locations in DoD facilities where they are prohibited and/or signal availability is unreliable. An alternative to this could be to put a policy and SOP into effect that requires such users to evacuate the facility to a location where the appropriate communications capability is available. The policy excerpts driving this requirement are as follows: From the UCR 5.3.1.7.5 Power Backup [Required: ASLAN – Conditional: Non-ASLAN] To meet CJCS requirements for assured services, equipment serving special C2 and C2 users must be provided with backup power. The ASLAN must meet the power requirements outlined at a minimum as follows: Special C2: The ASLAN must provide an 8-hour backup capability in the event of primary power loss to special C2 users. Any ASLAN product, Core, Distribution, or Access that supplies service to the special C2 user must have an 8-hour UPS. 2. C2: The ASLAN must provide 2 hour backup capability in the event of primary power loss to C2 users. Any ASLAN product, core, distribution or access, that supplies service to the C2 user must have a 2 hour uninterruptible power system (UPS). 3. C2(R) or Non-C2: C2(R) or non-C2 users may lose telephony service in the event of a power failure. NOTE: Backup Power (Environmental). The backup power system shall have the capacity to operate environmental systems needed to sustain continuous equipment operation. Power to the environmental systems may not need to be continuous. From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 with eight hours uninterrupted power supply. (b) Availability requirement for equipment/software serving C2 users is 0.99997 with two hours uninterrupted power supply. (c) Availability requirement for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2/admin users is 0.999 with no uninterrupted power supply. NOTE: While current DoD policy dictates that the VVoIP system as a whole only provide C2 and C2R users with specific durations of continued service during a power failure (as a cost saving measure), it is highly recommended that the entire system be provided some level of UPS. Traditional phone service is generally always available in a power failure since the endpoint or subscriber instrument is powered from the telephone switch. While there are exceptions to this regarding feature phones and some digital phones that need local power, for the most part all analog phones and others powered by the switch always work when local power is out. As noted above, VVoIP service is subject to disruption if power to the LAN infrastructure is disrupted. This can happen at various points since the LAN is a distributed (non-centralized) network. When implementing a VVoIP system without considering UPS power needs for the VVoIP controllers and endpoints as well as entire LAN, and supporting those needs with UPSs, we are reducing the availability of the telecommunications service that we are accustomed to. NoneReduced or no availability and denial-of-service. A high priority command and control or emergency life-safety/security call may not be able to be completed in a timely fashion or at all.Information Assurance Officer

Assigning static addresses to core VVoIP devices permits tighter control using ACLs on firewalls and routers to help in the protection of these devices.NoneInformation Assurance Officer

VVoIP core system devices and Time Division Multiplexer (TDM)-based telecom switches can be and in many cases are connected to multiple management networks. Such is the case when the system is managed by local SAs and systems via the local management VLAN or dedicated OOB management network and other SAs or systems manage or monitor the system via another network such as a remote MILDEP NOC, the DSN’s ADIMSS network, the RTS EMS, or the DISN DCN. A similar situation occurs in the DRSN with the ARDIMSS network. In some cases, these networks are interconnected such that both management networks have access to the same devices via a single management port. Each of these management networks is in reality a different enclave and as such, access and traffic between them must be filtered thus protecting each of the enclaves from compromise from one of the others. Enclaves are defined as a collection of computing environments connected by one or more internal networks under the control of a single authority and security policy, including personnel and physical security. Based on this definition, the local LAN enclave, remote MILDEP NOC, the DSN’s ADIMSS network, the RTS EMS, and the DISN DCN are different enclaves. Therefore, minimally, a firewall is required where these enclaves meet.Information Assurance Officer

The management interface on any system/device is its Achilles heel. Unauthorized access can lead to complete corruption of the system or device, causing the loss of availability (denial-of-service), integrity, and information or communications confidentiality. As such management interfaces and the management traffic they transmit or receive must be protected. The most effective method for providing this protection is to establish a separate dedicated network for the purpose of managing systems, devices, and network elements. Such a network is typically called an out-of-band (OOB) management network. Such networks can be expensive to establish depending on the geographical placement of the managed devices. This protection can also be afforded the management interfaces and traffic on the same network as the production traffic uses, but the process is more difficult and protection requirements more stringent. This method is called In-Band management. When using in-band management, the most effective method for providing management interface and traffic protection is to establish a separate dedicated management VLAN on the production network. Another method for protecting management traffic is the use of secure protocols and encryption. The Network Infrastructure STIG defines the requirements for both in-band and OOB management. In-band management is permitted for the typically geographically disbursed network elements using a dedicated management VLAN and logically separate management interfaces on each NE. In general the management of VVoIP core systems and devices must follow the NI STIG/checklist guidance. This means that these systems/devices can be managed via an OOB management network or an in –band VLAN. While this is the case, the this management access must be segregated from all other management VLANs on the network. The purpose of the separate VVoIP management VLAN or OOB network is to provide for separation of access in support of separation of duties between the data network or server SAs and the VVoIP system SAs. In some organizations these SAs are from different departments or just have different duties that don’t require that they have access to all devices on the network. The VVoIP management VLAN or OOB network may be accessed from the general LAN management VLAN/OOB network or other management VLANs or networks via a controlled ACL, gateway. A firewall may be needed if crossing enclave boundaries. Information Assurance OfficerDCBP-1, DCPA-1, DCSP-1, ECSC-1

VLAN and IP address segmentation enables access and traffic control for the VVoIP system components. Only the required protocols are to reach a given VVoIP device thereby protecting it from non-essential protocols. This protection is afforded on the LAN by implementing ACLs based on VLAN/subnet, protocol and in some instances specific IP addresses. While a firewall placed between the core equipment and endpoint VLANs might provide better protection for the core equipment as a whole, a router is best suited to control the varying traffic patterns between the various devices. Normally a large B/C/P/S will have a large LAN and one or more LSCs supporting a large VVoIP phone system. In this case, it is within normal network design parameters to employ routing devices at the core of the LAN within the enclave. As such, the VVoIP system’s core equipment would be connected to these routing devices or have one or more routing devices of its own. NOTE: It is recognized that small LANs and enclaves may not support VVoIP phone system core equipment as would be the case if they used a “managed service” or a remote LSC. In such a LAN the number of VLANs might be limited to one for data and one for VoIP. Also, a small LAN may not have a router at its core, potentially due to cost, thereby not having the capability of supporting multiple VVoIP VLANs. In this case, this requirement does not apply and all VVoIP endpoints and local VVoIP infrastructure equipment would be in a single VLAN. However, the use of a Layer 3 LAN switch instead of a dedicated router may be a cost effective method to meet this requirement for small LANs.Information Assurance OfficerDCBP-1, DCPA-1, DCSP-1, ECSC-1

There are several reasons why 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 need to 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 has to 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. We rely on these services being available when they are needed. Additionally, 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 of maintaining the ability to place calls to emergency services must be maintained. While the DoD voice networks are designed to be extremely reliable, such that COOP is supported, there is the potential that a site will be cut off from the DoD network. Based on this fact, each physical site must maintain local commercial phone service in the event the site is cut off. 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.

Documentation of the enclave / LAN configuration must include all VVoIP systems. If the current configuration cannot be determined then it is difficult to apply security policies effectively. Security is particularly important for VoIP technologies attached to the enclave network because these systems increase the potential for eavesdropping and other unauthorized access to network resources. Accurate network documentation is critical to maintaining the network and understanding its security posture, threats, and vulnerabilities. Baseline and C&A documentation is the vehicle by which the DAA receives security related information on the network for which he/she is personally responsible and accepts the security risk of operating the system. Additionally, When subscribing to DISN NIPRNet IP Voice Services (IPVS) or DISN SIPRNet IP Voice Services (IPVS) otherwise known as VoSIP, Or if the system connects to the DISN WAN for VVoIP transport between enclaves (such as in an Intranet), the enclave(s) must update their LAN / Enclave C&A and CAP documentation. The site must then seek an updated ATO/ATC or if necessary an IATO/IATC for the enclave’s connection to the DISN for VVoIP from the appropriate DISN CAP office (UCAO or CCAO). Without connection approval the site will not be included in the DISN Voice Services dial plan. NoneThe inability to effectively maintain the network or voice service and apply security policy and vulnerability mitigations. The inability for the DAA to understand the voice system’s and/or network’s security posture, threats, and vulnerabilities. The inability for the DAA to approve or accept the security risk of operating the systemInformation Assurance Officer

DISN IP based C2 Assured Service is about providing a highly available and reliable communications voice, video, and data service on a world wide scale that supports the command and control (C2) of military forces by all levels of command, from the lower echelons up to the president. While this is relatively easy for data transmission, this is not an easy task for voice and video communications, particularly when the state of the art for VoIP communications today has developed along different paths followed by each vendor. As such, VoIP communications has not been interoperable between different vendor’s systems or between these systems and the various VoIP services that are available today. The task is made more difficult by the fact that the transport medium, that is IP networks, are generally not designed to transport time sensitive communications. Information contained in packets is transported in a manner that ensures the information will get to its destination reliably, although not in a specific amount of time. This is not acceptable for packetized voice and video since lost or delayed packets affects intelligibility of the communications. An additional aspect of assured service voice communications is that of call or message priority. Some calls, that are high priority C2 calls, must be completed at the expense of lower priority or routine calls. DISA has worked to overcome these issues by working with the many vendors that provide telecommunications equipment to the DoD to develop a highly available, reliable, and interoperable IP based assured service voice and video communications network to meet the needs of its C2 customers. Additional DoD policy dictates that DISN services be used as the first choice for DoD components to fulfill their long haul communications needs. For dialup voice, video, and data services the Defense Switched Network (DSN) has fulfilled this role for sensitive but unclassified communications. Similarly the Defense RED Switched Network (DRSN) has fulfilled this role for multi-level classified voice communications. As DoD migrates to an all IP based DISN, the IP based voice services with the addition of video will fulfill this role into the future. A single vendor, classified, secret level, IP voice communications system has been implemented on SIPRNet which is currently called VoSIP. VoSIP stands for Voice over Secret (or secure) IP. This service and the supporting network are expected to provide assured service in the future. For the purpose of this document, assured voice/video communications services (classified or unclassified) on the DISN is designated as DISN IP Voice Services (IPVS). As such, if the VVoIP system within the enclave connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications between enclaves to any level of C2 user (Special C2, C2, C2(R)), the system must be integrated with (or subscribed to) the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service. NOTE: an exception might be given for private VVoIP communications systems implemented amongst a small community of interest to fulfill a validated mission requirement. NoneThe inability to make precedence or priority calls across the DISN in support of C2 assured service communications.Information Assurance Officer

DISA has developed the DISN IPVS to support C2 Assured Service reliability and availability. As such, the worldwide availability and effectiveness of this service is dependent upon the components of the overall system that are located in each interconnected enclave. These components must be interoperable and support the needed quality of service. Therefore, if the VVoIP system in an enclave is to utilize the DISN IPVS to communicate with other enclaves across the NIPRNet, the system must be designed with equipment that has specific capabilities. Additionally, the implementation of VVoIP across the enclave boundary must not degrade the security or protection of the enclave. The CE-R provides the following functionality: - Provides minimally four expedited forwarding queues (eight may be required in the future) - Places traffic within expedited forwarding queues based on the DSCP markings carried by the traffic - Routes AS-SIP-TLS packets and SRTP/SRTCP packets to the SBC function. (VVoIP firewall) - Routes all other traffic to the data firewall - Provides all of the filtering and security required by the Network Infrastructure STIGs Use of the DISN IPVS network requires the following equipment to assure interoperability across the DISN service: - At least one CE-R on which the DISN access circuits terminates - At least one Local Session Controller (LSC), Enterprise Session Controllers (ESC), or Multi-Function Soft Switch (MFSS) within the enclave for session management - A Session Border Controller (SBC) or data firewall having specific functionality as defined in the UCR will separate the CE-R from the LSC, ESC, and/or MFSS equipment. NOTE: Proper DSCP marking of VVoIP packets is required to provide appropriate QoS for C2 priority calls in support of Assured Service.

DISA has developed the DISN IPVS to support C2 Assured Service reliability and availability. As such, the worldwide availability and effectiveness of this service is dependent upon the components of the overall system that are located in each interconnected enclave. These components must be interoperable and support the needed quality of service. Therefore, if the VVoIP system in an enclave is to utilize the DISN IPVS to communicate with other enclaves across the NIPRNet, the system must be designed with equipment that has specific capabilities. Additionally, the implementation of VVoIP across the enclave boundary must not degrade the security or protection of the enclave. Use of the DISN IPVS network requires the following equipment to assure interoperability across the DISN service: - At least one Customer Edge Router (CE-R) on which the DISN access circuits terminates - At least one Local Session Controller (LSC), Enterprise Session Controllers (ESC), or Multi-Function Soft Switch (MFSS) within the enclave for session management - An SBC or data firewall having specific functionality as defined in the UCR will separate the CE-R from the LSC, ESC, and/or MFSS equipment

The purpose of the Internal Network IDS is to provide a backup for the enclave firewall(s) in the event they are compromised or mis-configured such that traffic which is normally blocked ends up being passed as well as to detect other malicious activity entering (or leaving) the enclave. As such the NIDS must be implemented in such a manner that it monitors all traffic flowing through the data and VVoIP firewalls. Minimally, it will detect improper data protocol traffic coming through the VVoIP firewall. While the NIDS will not be able to inspect the VVoIP signaling and bearer packet payload due to its encryption, it could detect anomalous behavior in the flow of these packets. Additionally, per the NI STIG, the NIDS is required to be a separate device from the firewall for reliability reasons. If the common firewall/IDS platform is compromised, both the firewall and IDS is vulnerable. NoneUnauthorized and undetected access or compromise of the enclave or the services it supportsInformation Assurance OfficerDCBP-1, ECSC-1

DISA has developed the DISN IPVS to support C2 Assured Service reliability and availability. As such, the worldwide availability and effectiveness of this service is dependent upon the components of the overall system that are located in each interconnected enclave. These components must be interoperable and support the needed quality of service. Therefore, if the VVoIP system in an enclave is to utilize the DISN IPVS to communicate with other enclaves across the NIPRNet, the system must be designed with equipment that has specific capabilities. Additionally, the implementation of VVoIP across the enclave boundary must not degrade the security or protection of the enclave. Use of the DISN IPVS network requires the following equipment to assure interoperability across the DISN service: - At least one Customer Edge Router (CE-R) on which the DISN access circuits terminates - At least one LSC, ESC, or MFSS within the enclave for session management - A Session Border Controller (SBC) or data firewall having specific functionality as defined in the UCR will separate the CE-R from the LSC, ESC, and/or MFSS equipment NOTE: For a large facility (site) the primary session controller should have a backup session controller geographically separate from it. This is also applicable to a facility/site using a MFSS. While the MFSS work in pairs in the backbone and are therefore redundant with regard to backbone services, their session controller functionality should also be redundant.

The DISN NIPRNet IPVS PMO has developed a method to provide Assured Service voice and video communications over the bandwidth constrained portion of the DISN. This method includes or supports providing precedence and priority capabilities for C2 users similar to the MLPP service provided by the traditional TDM based DSN. The enclave’s internal LAN is required to be designed to be non-blocking. That is it must provide ample bandwidth for all the traffic that it is expected to carry. This is controllable by DoD. On the other hand, the DISN Core is designed to have ample bandwidth and expandability to support what ever traffic the DoD enclaves throw at it. As such it is considered to be bandwidth rich. Due to issues surrounding the ability for an attached enclave to determine the bandwidth availability or congestion conditions within the core in real time, an assumption has to be made that the DISN Core is also non-blocking. The DISN Core bandwidth is also controllable by DoD. The portion of the overall DISN network that is bandwidth constrained is the TDM or optical OCx access circuits between the local enclave and the DISN Core. This is the portion of the network where we have the least control over bandwidth availability, primarily due to the cost of these circuits. The cost factor is an issue since many DISN access circuits must rely on commercial carriers for some portion of the overall circuit. This is typically the portion that delivers the DISN service to the B/C/P/S. Access circuit issues are less of an issue if the B/C/P/S also provides a home for one of the DISN Core SDNs. This is because a direct connection can be made between the CER and the SDN, however, the circuit capacity may still be an issue if the SDN is a small one that does not have an AR or PE. Due to the nature of digital transmission over these bandwidth constrained circuits, the quality and availability of the communications is degraded as these circuits become congested. “Data” packets can wait until processed without negatively affecting the delivery of a message. This is not the case for VVoIP due to its time sensitive nature (it is a real time service). If VVoIP packets have to wait for transmission, the quality of the call suffers. In IA terms, this relates to the availability of the service and quality communications. To overcome the bandwidth constraints inherent in WAN access circuits, an engineered bandwidth budget must be developed for each service (voice, video, and data) using the circuit. Voice and video budgets are developed in terms of call or session counts. For example, the UCR defines a voice call as follows: “One voice session budget unit shall be equivalent to 110 kilobits per second (kbps) of access circuit bandwidth independent of the EI codec used. This includes ITUT Recommendation G.711 encoding rate plus Internet Protocol Version 6 (IPv6) packet overhead plus ASLAN Ethernet overhead. IPv6 overhead, not IPv4 overhead, is used to determine bandwidth equivalents here.” NOTE: This budget is unidirectional and must be doubled for bi-directional communications sessions. NOTE: The VoIP budget covers the following types of services: Voice VoIP, FoIP, MoIP, or SCIP over IP calls The UCR also defines a video call as follows: “Since the bandwidth of a video session can vary [depending upon video resolution (ed)], video sessions will be budgeted in terms of video session units (VSUs). One VSU equals 500 kbps and bandwidth for video sessions will be allocated in multiples of VSUs. For example, the bandwidth allocated to video sessions may be 500 kbps, 1000 kbps, and 2500 kbps. Thus, a video session that requires 2500 kbps will be allocated five VSUs.” NOTE: This discussion, as it relates to video, is in regard to video sessions controlled by the LSC using AS-SIP for the signaling protocol. H.323 signaled video and/or VTC sessions must be considered separately and potentially have their own budget for access circuit bandwidth. NOTE: This budget (which also includes the audio component) is unidirectional and must be doubled for bi-directional communications sessions. When developing the bandwidth budgets, the engineer must determine how many simultaneous voice and video calls/sessions are to be supported by the access circuit based upon the unit per call defined in the UCR. The bandwidth budget to be reserved for voice is then calculated along with a budget for video. Next the engineer must determine what percentage of the overall access circuit bandwidth these reserved budgets should consume. The access circuit is then sized (ordered) to accommodate the needs. It is not recommended that IP voice and video capabilities be added to an existing circuit since this would mean the call/session counts would have to be restricted or the data budget would have to be squeezed. NOTE: Data traffic is permitted to surge into the voice and video budgets if the bandwidth is available; however the voice and video budgets are reserved and will be reclaimed if needed. Voice and video is not permitted to surge into the data budget since ASAC needs a fixed call count to be effective. NOTE: Instructions for determining voice call budgets for a DISN WAN access circuit can be found in the UCR section 5.3.3.11 Provisioning NoneReduced service availability and the inability to place a priority call Information Assurance Officer

Redundancy and dual homing is used within the DISN core to provide for continuity of operations (COOP) in the event a piece of equipment, circuit path, or even an entire service delivery node is lost. DoD policy also requires DoD enclaves that support C2 users for data services to be dual homed to the DISN core SDNs. This means that 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 need to be connected to two geographically diverse DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers. Depending upon the size of the SDN, one or both of the access circuits must be extended to another SDN containing the AR or PE. AR’s 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 so that there is more chance that assured service can be achieved. This need extends to assured service C2 VVoIP communications and is why we check it here.NoneReduced availability and the inability to complete a C2 call Information Assurance Officer

Providing dual homed access circuits from a 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 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. noneReduced availability and the inability to complete a C2 call

In previous requirements we discussed the need for redundant DISN Core access circuits between the enclave and the DISN SDNs. Another method for providing 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 man made. These threats range from storm damage (falling trees, floods, to being damaged or dug up by “the big yellow fiber-finder” (backhoe); to rampaging vehicles attacking utility poles; to malicious acts including war and terrorism. To overcome the physical threat, the redundant circuits should follow geographically diverse paths. NoneReduced availability and the inability to complete a C2 call Information Assurance OfficerDCBP-1, ECSC-1

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.Information Assurance OfficerEBCR-1

In addition to complying with the STIGs and VPN requirements for remotely connected PCs, there is an additional requirement for Unified Capabilities (UC) soft client and UC applications using the VPN. UC soft client and UC application traffic which must interact or communicate with systems and devices in the voice VLAN/protection zone must be routed to that zone while the other data and communications traffic is routed to the data zone. This is to be accomplished without degrading the separation of these two zones, or bridging them together. This can be accomplished in a number of ways depending upon the LAN and its boundary/VPN architecture.Information Assurance Officer

A voice video endpoint that provides a PC port typically breaks 802.1x LAN access control mechanisms. The cause is the network access switch port is enabled or authorized (and configured) when the voice video endpoint authenticates to the network and is authorized to operate. This may permit whatever is connected to the PC port to have access to the LAN even if it is not authorized or uses 802.1x. Therefore, the practice of daisy chaining devices on a single LAN drop protected by 802.1x must be prohibited unless certain mitigating circumstances exist or are configured. In the event a PC port is provided, the mitigation is to disable the port. However, the 802.1x implementation must install the configuration on the network access switch port required to support a voice video endpoint with a disabled PC port. This means the required configuration for the network access switch ports is to configure the appropriate VLAN for the voice video traffic and configure the unused VLAN for the disabled PC port.Information Assurance Officer

Limiting the number of registered MAC addresses on a switch access port can help prevent a CAM table overflow attack. This type of attack lets an attacker exploit the hardware and memory limitations of a switch. If there are enough entries stored in a CAM table before the expiration of other entries, no new entries can be accepted into the CAM table. An attacker will be able to flood the switch with mostly invalid MAC addresses until the CAM table’s resources have been depleted. When there are no more resources, the switch has no choice but to flood all ports within the VLAN with all incoming traffic. This happens because the switch cannot find the switch port number for a corresponding MAC address within the CAM table, allowing the switch to become a hub and traffic to be monitored. Many Voice Video Endpoints provide an extra Ethernet port called a PC port that permits the endpoint and another device to share the same LAN drop. A Voice Video Endpoint can be added to a LAN without having to run additional cable or activate additional LAN drops; allowing a single LAN drop to support both the PC and the Voice Video Endpoint. Another initiative where a single LAN drop is shared is hot desking, where several people are assigned to work at the same desk at different times, each with their own laptop computer. In this case, a different MAC address needs to be permitted for each laptop that is supposed to connect to the LAN drop in the workspace. Additionally, this workspace could contain a single phone used by all assignees and the PC port on it might be the connection for their laptop.

802.1x has the capability of configuring the network access switch port to assign a VLAN or apply filtering rules based upon the device that was just authenticated. This is done via the “success” message sent from the authentication server back to the authenticator. General VVoIP and video conferencing requirements dictate that traffic from these devices is to be separated from the general LAN traffic and workstations by VLAN and IP address separation or segregation. An implementation of 802.1x within the LAN must support this requirement. As such, the authentication server must provide the LAN switch with the proper VLAN configuration depending upon the device that is authenticated. For example, if all LAN ports are configured to use 802.1x LAN access control, and (as the typical case would be) are configured as disabled until a device authenticates, each port must support the authentication of a general workstation (a data device) or voice video endpoints. If a workstation authenticates, the switch port must be configured with the data VLAN. If a VVoIP endpoint authenticates, the switch port must be configured with the VVoIP VLAN. Video conference endpoints must be similarly configured. If a VVoIP endpoint that contains a PC port authenticates, the switch port must be configured with the VVoIP VLAN to receive the VVoIP traffic AND must be configured with the data VLAN to receive traffic from the PC port. Alternately, the switch port must be preconfigured for whatever device is expected to connect while in standby and implement the configuration when activated. The latter, however, is not how this is typically configured.Information Assurance Officer

The voice and video communications network provides an often overlooked pathway to spirit sensitive data out of an enterprise network without the likelihood of detection. Data exfiltration presents a huge vulnerability to any data that is stored within any enterprise and especially sensitive data. The DoD’s data is no less vulnerable. While predominantly an insider threat at this time, as EoIP technology progresses, the bad actors will find external methods to get at and exfiltrate our data through this covert channel that does not require insider activities. The traditional pathway to exploit this vulnerability is via a modem and the traditional voice network. The modem was invented to transfer data via the traditional telephone system. A modem can easily be connected to a phone line and a server or workstation (if not already embedded,), a outbound call can be made to an external computer’s modem, and data can flow easily, albeit slowly. To mitigate this threat, we institute both policy and technological mitigations such as specifically authorizing modem use; disabling an embedded modem while its host is connected to a computer network, and others. While modem usage for day-to-day data transfers and network access is dwindling at the enterprise level, many devices today still require the use of a modem. These are FAX machines, traditional secure telephones, and traditional secure VTC systems. As part of a layered defense against enterprise data exfiltration via a modem; detection, filtering, blocking, and call admission control mechanisms can be placed on traditional telephone switch trunks to detect unauthorized modem traffic and take appropriate action. Generally speaking, all modem traffic should be blocked with permissions established for pre-authorized devices on a specific line-by-line, case-by-case basis. Such technologies exist today. Today’s technology is taking us swiftly toward a converged IP based data and communications network called the Internet of Things (IoT). As this trend continues the many vulnerabilities and threats that we have been dealing with for years on our data networks are extended to our voice and video communications networks. The threat of sensitive enterprise data exfiltration via the data network is nothing new, and mitigations have been developed to address the various methods and exploits. However, little or nothing has been done to date to address the covert channel through our VoIP communications infrastructure whether connected to a traditional telephone network via a Media Gateway (MG), or to an IP WAN via a Session Border Controller (SBC), or Edge Border Controller (EBC). VVoIP aware firewalls generally address signaling issues and vulnerabilities, but do little to address those of the media streams. A data exfiltration exploit using the VVoIP network would look something like this. A trusted insider places a VoIP call from a compromised soft-phone on their workstation to a collection server outside the enterprise network. The call is processed and routed by the VoIP session manager as it would any voice call. The collection server answers the call as if it was a VoIP endpoint; e.g., using another compromised soft-phone. Once the connection is established, a file transfer can occur using the normal RTP streams established for the call as the transport medium. The data transfer is not detected because RTP or SRTP streams are generally not inspected. This is because of a general perception that payload anomalies are undetectable due to the random nature of encoded audio and video signals. SRTP encryption makes the payload inspection task even harder. This scenario easy to implement via IP end to-end-through one or more SBCs/EBCs without any data degradation. While it has been commonly thought that the transcoding performed in a MG would prevent such an exploit, such an exploit has been demonstrated using a pair of MGs resulting in only minor data degradation. Due to this fact, it is time to be concerned about data exfiltration via the VVoIP infrastructure and implement mitigations to prevent it.

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 US and other countries around the world. In the US, the FCC has mandated various aspects of providing enhanced F&ES communications and also relies upon state legislation to extend these rules. The Federal Communications Commission (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 specificity addressed in the systems call routing tables and potentially other system features. As such, 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 themselves. 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 which 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 2006Information Assurance OfficerInformation Assurance ManagerOther

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 are unable provide their location themselves. 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 Automatic Number Identification (ANI) information. The second step in the process is that this phone number must be correlated to a physical address or location. This is called Automatic Location Identification (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 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.Information Assurance OfficerInformation Assurance ManagerOther

Under 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 provide their location themselves. 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 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 Automatic Number Identification (ANI) information. The geographic location of the originating telephone is provided as Automatic Location Identification (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 may serve 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. As such 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 that the answering point can dial it directly. The number provided must not be that of an outbound trunk. Secondly, 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 cube 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. As such the PS_ALI database can quickly become inaccurate. 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.Information Assurance OfficerInformation Assurance ManagerOther

When calling the designated F&ES telephone number, the call must go through regardless of the state of other calls in the system. As such, emergency calls must be treated as a priority call by the system. For enterprise systems, the support for E911 by the Enterprise 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 systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.Information Assurance OfficerInformation Assurance Manager

Unified Capabilities (UC) users require different levels of capability depending upon 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) power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. As such, 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.Information Assurance OfficerInformation Assurance Manager

The availability of applications and services that are not necessary for the OAM&P of the VVoIP system’s devices and servers, running or not as well as the existence of their code, places them at risk of being attacked and these avenues exploited. As such they should be removed if possible or minimally disabled so they cannot run and be exploited. For VVoIP and UC servers and endpoints, remove the software for or minimally disable PPS that are not necessary for the operation or maintenance of the system. Limit production PPS to production interfaces and management PPS to the OAM&P interfaces. NoneInformation Assurance Officer

It is critical that the network time be synchronized across all network elements when troubleshooting network problems or investigating an incident. Each log entry is required to be time stamped. If time-stamps are not synchronised, it can be difficult or impossible to see in what order events occurred. Additionally legacy telecommunications systems require synchronized time. Network elements (NE). The Network Infrastructure STIG provides guidance for using NTP and implementing NTP servers within the enclave or LAN. A paraphrased summary of the basic requirements follows: > Implement two NTP servers in the LAN management network to act as the source of NTP information to the rest of the enclave/LAN. > Reference the two NTP servers to two different stratum 1 reference clocks via GPS or NIST WWVB. > Harden NTP servers in accordance with the applicable OS STIG. > Distribute NTP information to all LAN NEs via the management interface. This provides a protected environment for the distribution of network time. > All received and sent messages between NTP peers are authenticated. > Receive NTP messages from authorized sources based on their IP address. > All LAN NEs are configured to receive NTP messages from two NTP sources within the LAN such that one backs up the other. > Distribution of NOTE: This list is not complete and is provided as information only. Refer to the current Network Infrastructure STIG for all policy and requirements associated with NTP use and implementation in the LAN. The VVoIP system must be synchronized with the LAN time, minimally to support troubleshooting and incident response. Therefore the VVoIP system must be integrated into the LAN’S NTP system in accordance with the Network Infrastructure STIG NTP guidance. Its network time must not be synchronized with an independent source. Additionally, if the VVoIP system is synchronized with an independent source via the Internet, the VVoIP system becomes exposed to NTP exploits and attacks from the Internet. Implementing NTP within the VVoIP system will require the system/call controller to be configured to receive authenticated NTP messages from the two NTP server IP addresses via its management interface. This will require that permissions be granted between the VVoIP management VLAN and the LAN management VLAN such that NTP requests and responses can flow between the VVoIP system controller and the two NTP servers in the LAN management VLAN. If the VVoIP endpoints time is synchronized via NTP, the VVoIP controller will have to serve as their NTP server since the endpoints do not have access to the VVoIP or LAN management VLANs and should not be permitted such access. NoneInformation Assurance Officer

When VVoIP configuration files traverse a network in an unencrypted state, system information may be used by an adversary, which in the aggregate, may reveal sensitive data. When VVoIP traffic is passed in the clear it is open to sniffing attacks. This vulnerability exists whether the traffic is on a LAN or a WAN. End-to-end encryption of the configuration files mitigates this vulnerability. However, TFTP does not natively encrypt data. The Cisco TFTP implementation for VoIP systems uses encryption to both store and transfer configuration files. Refer to the “CISCO-UCM-TFTP” Vulnerability Analysis report provided by the Protocols, Ports, and Services management site for more details. DoD-to-DoD voice communications are generally considered to contain sensitive information. Local DoD enclaves connect to a DISN SDN via an access circuit. Unless the site is a host to a SDN, or close enough to it to be served by DoD owned facilities, some portion of the access circuit will utilize leased commercial facilities. Additionally, the DISN core network itself may traverse commercial services and facilities. Therefore, DoD voice and data traffic crossing the unclassified DISN must be encrypted.Downgrade to CAT 3 when vendor provided PKI or x.509 certs are used instead of DoD PKI.Information Assurance OfficerECSC-1

When VVoIP configuration files traverse a network in an unencrypted state, system information may be used by an adversary, which in the aggregate, may reveal sensitive data. When VVoIP traffic is passed in the clear it is open to sniffing attacks. This vulnerability exists whether the traffic is on a LAN or a WAN. Unencrypted and unsigned configuration files must be wrapped within an encrypted VPN to mitigate this risk. DoD-to-DoD voice communications are generally considered to contain sensitive information. Local DoD enclaves connect to a DISN SDN via an access circuit. Unless the site is a host to a SDN, or close enough to it to be served by DoD owned facilities, some portion of the access circuit will utilize leased commercial facilities. Additionally, the DISN core network itself may traverse commercial services and facilities. Therefore, DoD voice and data traffic crossing the unclassified DISN must be encrypted.Information Assurance OfficerECSC-1

Unified Capabilities (UC) users require different levels of capability depending upon 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 UPS power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. As such, 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.Information Assurance Officer

During VVoIP endpoint registration with the session controller, a file is downloaded by the endpoint from the session manager containing specific configuration settings. This file contains the phone number assigned to the endpoint, the IP addresses for session management, the software menus specific to the system, the endpoint configuration password, the stored personal preferences and speed dial numbers, and other system operational information. These configuration settings can be updated by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded. Unregulated automatic download of VVoIP endpoint configuration files during initial registration allows rogue endpoints to become part of the system. It also potentially allows human readable configuration files to be sent without encryption or digital signatures.

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 that the classified discussion is not overheard. - Secure Voice Video endpoints must be configured to prevent speaker enablement in the non-secure 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 that 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.