View STIG - Voice/Video Services Policy STIG V3R4

a

The VVoIP system, its components, and/or changes to them are not included in the site’s enclave / LAN baseline documentation and Configuration & Accreditation documentation

Low - V-8223 - SV-8709r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1100 (GENERAL)

Vuln IDs

V-8223

Rule IDs

SV-8709r1_rule

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.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 OfficerDCHW-1

Checks: C-23599r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure the VVoIP and/or IP connected VTC system and its components as well as their upgrades and changes are included in the site’s enclave / LAN C&A documentation (e.g., the DIACAP Implementation Plan (DIP), System Identification Profile (SIP), Scorecard, etc.). NOTE: This requirement applies to or includes the existence or implementation of soft-phone applications or wireless VoIP (Wi-Fi or WiMAX) endpoints. > Review the baseline documentation and/or C&A documentation to verify that all VVoIP installations and/or modifications are included. Verify there is a procedure for approving changes to configuration. > Determine if soft-phone applications or wireless VoIP (Wi-Fi or WiMAX) endpoints are used or implemented within the network. Look for the appearance of these in the required documentation noted above.

Fix: F-7706r1_fix

Add all VoIP installations and/or modifications to the SSAA. Obtain DAA approval for the updated SSAA. Submit to the SRR team lead for validation and finding closure.

b

MGCP and/or H.248 (MEGACO) is not restricted/controlled on the LAN and/or protected on the WAN using encryption OR MGCP and/or H.248 (MEGACO) packets are not authenticated or filtered by source IP address.

Medium - V-8224 - SV-8710r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1405 (GENERAL)

Vuln IDs

V-8224

Rule IDs

SV-8710r1_rule

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. NoneDenial of Service, loss of confidentiality, and/or unauthorized access to network or voice system resources or services and the information they contain.Information Assurance OfficerECCT-1, ECSC-1

Checks: C-23703r1_chk

Interview the IAO and review/inspect site network/facilities diagrams and documentation to confirm compliance with the following requirement: In the event MGCP or MEGACO/H.248 is used to control Media Gateways (MGs) or other devices (e.g., endpoints), ensure the following: > The LSC/MGC and MG are located in the same protected LSC VLAN and ACLs are established on all VLAN egress points to block the MGCP or MEGACO/H.248 from exiting the VLAN; OR > the LSC/MGC and MG are located in adjacent protected VLANs and ACLs are established to permit MGCP or MEGACO/H.248 between the LSC/MGC and MG but block the MGCP or MEGACO/H.248 from exiting these VLANs; AND > In the event MGCP or MEGACO/H.248 is used to control a MG or a distributed set of MGs across a WAN, ensure an encrypted VPN is used to protect the MGCP traffic. > Additionally, ensure the source of MGCP or MEGACO/H.248 packets is authenticated to originate from a valid source and/or minimally filter acceptance on source IP address.

Fix: F-20185r1_fix

In the event MGCP or MEGACO/H.248 is used to control Media Gateways (MGs) or other devices (e.g., endpoints), ensure the following: > the LSC/MGC and MG are located in the same protected LSC VLAN and ACLs are established on all VLAN egress points to block the MGCP or MEGACO/H.248 from exiting the VLAN; OR > the LSC/MGC and MG are located in adjacent protected VLANs and ACLs are established to permit MGCP or MEGACO/H.248 between the LSC/MGC and MG but block the MGCP or MEGACO/H.248 from exiting these VLANs; AND > In the event MGCP or MEGACO/H.248 is used to control a MG or a distributed set of MGs across a WAN, ensure an encrypted VPN is used to protect the MGCP traffic. > Additionally, ensure the source of MGCP or MEGACO/H.248 packets is authenticated to originate from a valid source and/or minimally filter acceptance on source IP address.

b

Voice/Video Telecommunications infrastructure components (traditional TDM, VVoIP, or VTC) are not housed in secured or “controlled access” facilities with appropriate classification level or appropriate documented access control methods.

Medium - V-8225 - SV-8711r1_rule

RMF Control

Severity

Medium

CCI

Version

VVT/VTC 1000 (GENERAL)

Vuln IDs

V-8225

Rule IDs

SV-8711r1_rule

Controlling physical access to telecommunications infrastructure components is critical to assuring the reliability of the voice network and service delivery. Documenting or logging physical access to these components is critical to determine accountability for auditing purposes. Key control and access logs are a large part of this. Additionally, the facilities housing the telecommunications infrastructure must be certified at a classification level commensurate with the highest classification level of the information communicated by the system. NOTE: The infrastructure addressed here are components of traditional TDM, VVoIP, UC or VTC systems that support the communications endpoints. This includes “wiring closets” for traditional non IP based systems. NOTE: Physical access to the LAN infrastructure (which may also support VVoIP, UC, and VTCoIP services) is covered by a Network Infrastructure STIG requirement. This requirement does not directly address the physical security of the general LAN infrastructure, such as LAN routers and switches. NOTE: While this requirement is based on best practice and requirements for protecting classified information, it is also supported in part by DOD 5200.08-R, Physical Security Program, April 9, 2007 Incorporating change 1, 27 May 2009, Chapter 6, Security of Communications Facilities, section C6.2.4 which states: “Access shall be controlled at all communications facilities and only authorized personnel shall be allowed to enter. Facilities should be designated and posted as a minimum, a Controlled Area, as directed.” NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Physical access to systems by unauthorized personnel leaves the system components vulnerable to a multitude of attack vectors and/or accidental de-activation or disconnection.Information Assurance OfficerDCBP-1, ECSC-1

Checks: C-23525r1_chk

Perform a walk through of the facilities the IAO to validate compliance with the following requirement: Ensure all telecommunications infrastructure components (traditional TDM, VVoIP, UC or VTC) are housed in secured facilities with appropriate classification level and appropriate documented access control methods. NOTE: This does not apply to end instruments. Additionally ensure all facilities housing telecommunications infrastructure components are rated at or above the highest classification level of the information communicated. For example, VoSIP (VoIP on SIPRNet) infrastructure components must be housed in facilities rated at or above the secret level. NOTE: This DOES apply to end instruments. During the walk through inspection, visually confirm that telecommunications infrastructure (traditional TDM, VVoIP, UC or VTC specific network and server) components are installed in secured areas to include locked rooms, closets, and/or cabinets. Interview the IAO to determine how the distribution of keys to access the equipment is limited, controlled, and documented. Additionally, determine if access control procedures/documentation are/is being used and review the access logs for compliance. Finally; interview the IAO regarding the security classification of the facilities housing the telecommunications infrastructure components in relation to the highest classification level of the information communicated. This is a finding in the event of the following: > Any telecommunications infrastructure component is not housed in a secured facility (locked room or cabinet). > The facility access control procedures or its documentation is deficient. > Access to the facility is not logged or the procedures are not followed. > The facility classification of any facility housing telecommunications infrastructure components is rated below the highest classification level of the information communicated. NOTE: The infrastructure addressed here are components of traditional TDM, VVoIP, UC or VTC systems that support the communications endpoints. This includes “wiring closets” for traditional non IP based systems. NOTE: Physical access to the LAN infrastructure (which may also support VVoIP, UC, and VTCoIP services) is covered by a Network Infrastructure STIG requirement. This requirement does not directly address the physical security of the general LAN infrastructure, such as LAN routers and switches. NOTE: While this requirement is based on best practice and requirements for protecting classified information, it is also supported in part by DOD 5200.08-R, Physical Security Program, April 9, 2007 Incorporating change 1, 27 May 2009, Chapter 6, Security of Communications Facilities, section C6.2.4 which states: “Access shall be controlled at all communications facilities and only authorized personnel shall be allowed to enter. Facilities should be designated and posted as a minimum, a Controlled Area, as directed.”

Fix: F-20063r1_fix

Ensure all telecommunications infrastructure components are housed in secured facilities with appropriate classification level and appropriate documented access control methods. NOTE: This does not apply to end instruments. Additionally, ensure all facilities housing telecommunications infrastructure components are rated at or above the highest classification level of the information communicated. For example, VoSIP (VVoIP on SIPRNet) infrastructure components must be housed in facilities rated at or above the secret level. NOTE: This DOES apply to end instruments. Ensure that all equipment is installed in a locked room, closet, or cabinet. Ensure the distribution of keys to access the equipment is limited, controlled, and documented. Ensure access control procedures are implemented to ensure that physical access is documented such that an audit trail can be established if necessary. NOTE: The infrastructure addressed here are components of traditional TDM, VVoIP, UC or VTC systems that support the communications endpoints. This includes “wiring closets” for traditional non IP based systems. NOTE: Physical access to the LAN infrastructure (which may also support VVoIP, UC, and VTCoIP services) is covered by a Network Infrastructure STIG requirement. This requirement does not directly address the physical security of the general LAN infrastructure, such as LAN routers and switches. NOTE: While this requirement is based on best practice and requirements for protecting classified information, it is also supported in part by DOD 5200.08-R, Physical Security Program, April 9, 2007 Incorporating change 1, 27 May 2009, Chapter 6, Security of Communications Facilities, section C6.2.4 which states: “Access shall be controlled at all communications facilities and only authorized personnel shall be allowed to enter. Facilities should be designated and posted as a minimum, a Controlled Area, as directed.”

b

Different contiguous address blocks or ranges are NOT defined for the V-VoIP system within the LAN (Enclave) that is separate from the address blocks/ranges used by the rest of the LAN for non V-VoIP system devices thus allowing V-VoIP system traffic and access control using firewalls and router ACLs.

Medium - V-8227 - SV-8713r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5200 (LAN)

Vuln IDs

V-8227

Rule IDs

SV-8713r1_rule

VoIP 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 network(s) be secured as tightly as possible to reduce the impact that an attack can have on either network(s). 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 segregation of VoIP 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, in themselves, are not designed as 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 impacting the other. These methods make it harder for an attacker to be successful and help to provide a layered approach to VoIP and network security. Segregating data from telephony by placing VoIP servers and subscriber terminals on logically separate IP networks and logically separate Ethernet networks while controlling access to these VoIP components through filters will help to ensure security and aid in protecting the VoIP environment from external threats. In addition, further subdivision of those components is necessary to protect the telephony applications which are running across the infrastructure. Layer 3 address segregation is the first layer in our layered defense approach to VoIP security. It allows the use of switches, routers, and firewalls with their associated access lists and other processes, to control traffic between the components on the network. To provide address segregation, best practices dictate that all like components will be placed in like address ranges. Therefore VoIP 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 VoIP components is necessary for protecting telephony applications running across the infrastructure. Segregating data from telephony by placing VoIP servers and subscriber terminals on logically separate IP networks while controlling access to these VoIP components through IP filters will help to ensure security and aid in protecting the VoIP environment. NoneAccess to the VVoIP infrastructure or endpoints leading to unauthorized access, denial-of-service, compromise of communications confidentiality or integrity.Information Assurance OfficerDCBP-1, DCPA-1, ECSC-1

Checks: C-23790r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure (a) different, dedicated, address block(s) or range(s) are defined for the VVoIP system within the LAN (Enclave) that is separate from the address blocks/ranges used by the rest of the LAN for non VVoIP system devices thus allowing traffic and access control using firewalls and router ACLs. NOTE: the address range defined should be contiguous in order to simplify the development of the ACLs. NOTE: This is applicable to the following: > A closed unclassified LAN > An unclassified LAN connected to an unclassified WAN such as the NIPRNet or Internet > A closed classified LAN > A classified LAN connected to a classified WAN (such as the SIPRNet). NOTE: In the case of a classified WAN where network wide address based accountability or traceability is required by the network PMO, the PMO must provide a segregated, network wide address block(s) so that the attached classified LANs can meet this requirement. NOTE: The affected devices in this case are as follows: > VVoIP Call or session controllers; LSC / MFSS > Adjunct UC systems > Edge Boundary Controller (EBC) internal and external interfaces > Customer Edge (Premise) router internal interface to the VVoIP VLANs > VVoIP endpoints including for PCs that support multiple VLANs. NOTE: VVoIP Core systems including the EBC and CER must be statically addressed. DHCP may only be used for endpoint address assignment/configuration. Determine if a dedicated LAN address space has been designated for the VVoIP system that is segregated from the address space used for the general LAN and management VLANs. Note the defined address range(s) for use when reviewing the devices themselves.

Fix: F-7710r1_fix

Implement VoIP systems and components on a logically segregated and dedicated telephony (VoIP) network.

a

The dedicated VVoIP address range must use private (non-WAN routed) addresses identified in RFC 1918.

Low - V-8228 - SV-8714r2_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 5205 (LAN)

Vuln IDs

V-8228

Rule IDs

SV-8714r2_rule

RFC 1918 identifies and reserves the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) This conserves the available public address pool since more hosts need addresses than addresses exist. Network address translation (NAT) on the firewall or router at the enclave boundary provides one public WAN address and many private addresses on the LAN. The term private IP addresses in this sense means these address blocks are not routed or advertised across the Internet by international agreement. NIPRNet WAN addresses are publicly accessible and the PMO also follows RFC 1918 routing policy (meaning that these addresses are not routed). RFC 1918 addresses are routable within the LAN enclave. Sub-networks use a different major address range than is deployed on the local data network to further separate IPT from the data network. This will help to reduce the chances of voice traffic traversing outside the telephony network segment and vice versa for data traffic. The use of RFC 1918 IP address space, like the data VLANs, has the effect hiding the VVoIP components from the WAN, and making their addresses non-routable as a destination across the Internet (or NIPRNet). Deploying VVoIP Systems using RFC1918 address space enhances security of the VVoIP environment. If VVoIP systems are not deployed on private address space and if the address space is not properly configured, managed, and controlled, the VVoIP network could be accessed by unauthorized personnel resulting in security compromise of site information and resources.System AdministratorInformation Assurance OfficerDCBP-1, DCPA-1, ECSC-1

Checks: C-23791r4_chk

If the VVoIP system being assessesd resides on the SIPRNet, this check is not applicable. Interview the IAO to confirm compliance with the following requirement: The devices affected by this requirement include VVoIP call or session controllers (LSC, MFSS, etc.), adjunct UC systems, session border controllers (SBC), customer edge (Premise) router internal interfaces to VVoIP VLANs, and VVoIP endpoints (including for PCs that support multiple VLANs). Verify the dedicated VVoIP address range uses private addresses IAW RFC 1918. Otherwise, this is a finding. NOTE: This requirement is applicable to the following: - A closed unclassified LAN (including a LAN that someday connects to a WAN) - A unclassified LAN connected to a unclassified WAN such as NIPRNet or the Internet - A closed classified LAN (including a LAN that someday connects to a WAN) - A classified LAN connected to a classified WAN where network wide address based accountability or traceability is not required by the WAN PMO and the WAN is not configured route private addresses NOTE: This requirement is not applicable in situations where network wide address based accountability or traceability is required by the WAN PMO. For example, This is not applicable to DAA approved VoSIP systems residing on secured classified LANs that are connected to a classified WAN (such as the SIPRNet) where RFC 1918 addressing is not permissible for reasons of network wide accountability, traceability, and policy.

Fix: F-20237r2_fix

Configure the dedicated VVoIP address range to use private (non WAN routed) addresses IAW RFC 1918.

b

The VVoIP VLAN design for the supporting LAN does not provide the necessary segmentation of the VVoIP system and service from the other services on the LAN and/or between the VVoIP components such that access and traffic flow can be properly controlled.

Medium - V-8230 - SV-8716r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5500 (LAN)

Vuln IDs

V-8230

Rule IDs

SV-8716r1_rule

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 though 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 is a limited number of VoIP 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. Denial of Service, loss of confidentiality, and/or unauthorized access to network or voice system resources or services and the information they contain. The IPT / VoIP infrastructure would not be hidden and therefore would be easier to attack from the data network. Voice performance may also be degraded.Information Assurance OfficerDCBP-1, DCPA-1, ECSC-1

Checks: C-23801r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the VVoIP system and the supporting LAN are designed and implemented using multiple VLANs to segregate the VVoIP core equipment and endpoints and services from all other hosts and services (such as data and dedicated VTC) running on the LAN such that the security, QoS, and reliability of the VVoIP system/service is enhanced thus allowing VVoIP system traffic and access control using router ACLs. VLANs and subnets will be provided and equipment separated, for those devices that are implemented in the system, as follows: > Hardware Endpoints: multiple VLANs 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. > Media gateways (MG) to the DSN and PSTN. > Signaling gateways (SG) to the DSN. > DoD WAN access VVoIP firewall (EBC or other). > Voicemail / Unified Messaging Servers. These may need to be accessible from both the voice and data VLANs. > UC servers such as those supporting unified messaging, IM/presence, “web” browser based conferencing, and directory services. These may need to be accessible from both the voice and data VLANs. NOTE: Hardware based VTC endpoints that utilize LSC services for session control may reside in the VoIP endpoint VLAN(s). These may include desktop and “executive” or office based units. All other Hardware based VTC endpoints require their own dedicated network or VLAN. NOTE: Separate VLANs work in conjunction with the dedicated address space discussed earlier to provide the required effect. Each VLAN is configured with a subset of addresses (valid IP subnet) from the designated VVoIP address space NOTE: Per NI STIG requirements the NE’s default VLAN (VLAN 0 or 1) will not be used for any of the required VVoIP, data, or VTC VLANs. NOTE: ACLs are required between the various VLANs that will filter traffic between them based on what protocols and IP addresses are permitted to access or control the device(s) residing in the VLAN. Therefore it is expected that the LAN / VVoIP system design will include one or more routers or layer-3 switches as the intersection of all of these VLANs to access and traffic flow between them. This routing device will be configured with ACLs to only permit the functionally necessary traffic to flow between the various VLANs and the equipment they contain. NOTE: These VLANs may be replaced by direct connections to the VVoIP core routing device(s) so that the ACLs may be implemented on the physical interface to the device. This requires that such direct physical connections be given a discrete subnet. 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. This is a finding in the event the design or implementation of the VVoIP system and supporting LAN does not include the required VLANs and subnets based upon the equipment and services provided by or included in the VVoIP system. Size of the system or the number of users supported has no effect on the need for this segmentation. However under some circumstances such as in the case of a small deployable package the number of VLANs can be reduced based upon a benefit vs. risk assessment, DAA approval, and package C&A. NOTE: The existence of the required VLANs will be validated in subsequent computing checks. The purpose of this check is to determine if the system design and implementation plan includes consideration for VLAN segmentation.

Fix: F-7713r1_fix

Deploy VoIP systems and components on a dedicated VLAN structure that is separate from the data network VLAN structure. A minimum of one VLAN is required. More than one is highly recommended.

b

Servers supporting the VVoIP and UC/UM telephony environment are not dedicated to telephony (VVoIP, UC, or UM) applications or their support.

Medium - V-8247 - SV-8733r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1050 (GENERAL)

Vuln IDs

V-8247

Rule IDs

SV-8733r1_rule

For the purpose of this requirement a VVoIP, UC, or UM server is any server directly supporting the communications service. Unlike a regular PC or print server on the network VVoIP servers are “mission critical” to the operation of the VoIP system. Dedicating these critical servers to their task is one of the key steps in key in securing the VVoIP environment. Permitting critical servers to run non-critical applications can provide a means or a path whereby the server or the critical applications can be compromised. Additionally, by running non-critical applications not required for the operations or not related to the primary purpose of the server can degrade the performance of the server and thereby the reliability of the service provided. By not permitting non-critical applications to run on these servers the server is made more secure. Therefore, the securing of these voice processing and signaling platforms, to include their installed applications, is vital in protecting the VoIP environment from malicious attack. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. The DOD voice system may not be protected as required and may be vulnerable to attack or loss of availability due to non-VoIP related applications.Information Assurance OfficerECSC-1

Checks: C-23603r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure critical servers/devices supporting the VVoIP/UC/UM system are dedicated to only applications required to support operations. Interview the IAO and SA to determine the purpose and use of each server/device that comprises the VVoIP/UC/UM core infrastructure. Then determine each server/device can support or run any application other than what is required in support of its primary purpose. Such servers would be the LSC, without which the system will not operate, voicemail or unified mail servers, management servers, IM / presence servers, conference bridges, etc. Inspect each server/device’s software storage looking for its installed applications. This is a finding if applications are found that are not required to fulfill the server/device’s primary function. General purpose applications like browsers, word processors, etc., or other applications like development software or special purpose applications should not be found unless directly required for operations and support. Additionally, unnecessary portions of the operating system such as sub-applications or files and routines that are not required to support the telephony system should not be found. NOTE: VVoIP core infrastructure servers/devices include but may not be limited to the TDM telephone switches, local session controller (LSC), voicemail / unified mail system, interactive voice response system, media gateway, signaling gateway, management servers and workstations, conference bridges, IM/presence servers, etc.

Fix: F-20122r1_fix

Ensure critical servers/devices supporting the VVoIP/UC/UM system are dedicated to only applications required to support operations. Dedicate critical servers in the VVoIP/UC/UM core infrastructure to only run applications required for executing the primary function of the server/device and those required for its support. Additionally, remove all unnecessary portions of the operating system such as sub-applications or files and routines that are not required to support the telephony system.

a

All applicable STIGs have NOT been applied to the VVoIP / unified communications core infrastructure assets.

Low - V-8248 - SV-8734r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1030 (GENERAL)

Vuln IDs

V-8248

Rule IDs

SV-8734r1_rule

For the purpose of this requirement a VVoIP server is any server directly supporting the communications service. Unlike a regular PC or print server on the network VVoIP servers are “mission critical” to the operation of the VoIP system. Some vendors provide IP Telephony services on their own proprietary systems while others provided these services on standard UNIX, Linux, and Microsoft Windows based systems. They may also use general-purpose applications such as databases like MS-SQL or Oracle and/or employ web server technology like IIS or similar as well as open source software. Additionally, application security guidance may be applicable for the vendor's application that makes the server or device perform the functions, or the management, of the system. Hardening these general purpose applications and operating systems against the much inherent vulnerabilities found in them is critical to securing the VVoIP core infrastructure, to include their installed applications. Doing so is vital to protecting the VoIP environment from malicious attack. The specific VVoIP system server or device determines the applicability of any given STIG. UNIX and Microsoft Windows based systems. Most known vulnerabilities exist on UNIX and Windows based operating systems. They may also use general-purpose applications such as databases like MS-SQL or Oracle and/or employ web server technology like IIS or similar. Additionally, application security guidance may be applicable for the vendor's application that makes the server or device perform the functions, or the management, of the system. Therefore, the securing of these voice processing and signaling platforms, to include their installed applications, is vital in protecting the VoIP environment from malicious attack. The specific VoIP system server or device determines the applicability of any given STIG.NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. The DOD voice system may not be protected as required and may be vulnerable to attack or loss of availability due to a multitude of OS and application vulnerabilities.Information Assurance OfficerECSC-1

Checks: C-23615r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure that the VVoIP core infrastructure servers/devices have been secured and hardened in compliance with all applicable STIGs (i.e., UNIX, Microsoft Windows, database, web, etc.). Determine if the asset is based upon any of the general purpose technology (OS or application) for which there is a STIG or checklist. Obtain a copy of the applicable SRR or Self Assessment results and review for compliance. If SRR results are not available, then SRR a representative number of devices. This is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance. NOTE: If the server/device is purpose built to its function (potentially considered an appliance) using an embedded or stripped down version of a general purpose OS and/or if the device has limited I/O capabilities, it may be difficult to impossible to perform a normal review that would be done on a general purpose platform. In this case the best way to determines if the device is vulnerable is to perform a network scan on it. NOTE: VVoIP core infrastructure servers/devices include but may not be limited to the TDM telephone switches, local session controller (LSC), voicemail / unified mail system, interactive voice response system, media gateway, signaling gateway, management servers and workstations, conference bridges, IM/presence servers, etc.

Fix: F-7731r1_fix

Secure critical servers supporting the telephony environment. Apply all applicable STIGs (i.e., UNIX, Microsoft Windows, database, web, etc. UNIX, Win2k/NT, DSN, etc.) and ensure compliance with applicable STIG guidelines.

c

DoD-to-DoD VVoIP traffic traversing any publicly accessible wide area network (i.e. Internet, NIPRNet) must use FIPS 140-2 or NSA approved encryption.

High - V-8250 - SV-8736r2_rule

RMF Control

Severity

High

CCI

Version

VVoIP 1400 (GENERAL)

Vuln IDs

V-8250

Rule IDs

SV-8736r2_rule

When VVoIP connections are established across a publicly accessible WAN, all communications confidentiality and integrity can be lost. Information gleaned from signaling messages can be used to attack the system or for other nefarious reasons. If VVoIP traffic is passed in the clear it is open to sniffing attacks. This vulnerability exists whether the traffic is on a LAN/CAN or a MAN/WAN. Native end-to-end encryption of the signaling and media mitigates this vulnerability. As a secondary solution, mitigation can be accomplished at the link-level through the incorporation of encrypted VPN tunneling technology. Both solutions are applicable when the communicating endpoints are operated by the same organization or they reside in enclaves operated by the same organization and the endpoints and supporting systems are interoperable. As such, encryption of some approved form is required to protect DoD-to-DoD communications across a public network such as the Internet or a publicly accessible network such as the NIPRNet. While end-to-end application or protocol level encryption is preferred, tunneling unencrypted VVOIP signaling and media traffic using approved commercial grade (Type 3) site-to-site or client-to-site (remote access) VPN technologies mitigates the risk. The inherent type 1 site-to-site encryption employed afforded classified networks, such as the SIPRNet, also meets this requirement, although such networks are not public or publicly accessible as a rule. 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 OfficerEBRU-1, ECCT-1, ECSC-1

Checks: C-23685r2_chk

Interview the IAO to confirm compliance with the following requirement: Verify all DoD-to-DoD VVOIP signaling and media traffic traversing a public or publicly accessible WAN (i.e., Internet, NIPRNet) is encrypted, natively at the application or protocol level, or using network or data-link layer encryption (i.e., encrypted VPN or bulk link encryption) using FIPS 140-2 or NSA approved encryption. Otherwise this is a finding. NOTE: This requirement is applicable to the following: - Calls established between DoD endpoints within an extended enclave (single MILDEP organization using directly interoperable VoIP systems) - Calls established between DoD endpoints located in different enclaves operated by a single MILDEP organization using directly interoperable VoIP systems. - Calls established between DoD endpoints located in different enclaves operated by different MILDEP organizations whether using directly interoperable VoIP systems and endpoints or the systems are subscribers to the DISN IPVS using IPVS standard protocols. - Calls established between remote DoD endpoints located outside their home enclave and connecting across the Internet and/or NIPRNet. In this case, a remote access VPN is used. NOTE: At this time, this requirement is not applicable for calls established from DoD to commercial VoIP telephones via commercial ITSP services implemented as a replacement for TDM based PSTN access. This is because there is no encryption standard for end-to-end VoIP sessions to which all ITSPs and phone vendors have subscribed. Once a universal standard is adopted and implemented, or translation gateways are developed, this requirement could then be applied. Before encryption standards are adopted, the world must adopt interoperable signaling and media standards. At this time, Session Border Controllers can provide some translation services. Additional considerations are discussed in the section on ITSP services.

Fix: F-20178r2_fix

Configure all DoD-to-DoD VVOIP signaling and media traffic traversing a public or publicly accessible WAN network (i.e., Internet, NIPRNet) to use FIPS 140-2 or NSA approved encryption, either natively at the application or protocol level, or by using network or data-link layer encryption (i.e., encrypted VPN or bulk link encryption). The encryption of VVOIP signaling and media traffic may either use native end-to-end basis or tunnel it using site-to-site or client-to-site (remote access) VPN technologies or bulk link encryption.

a

The stand alone or IP connected Voice mail system/server is not secured to applicable OS and DSN STIG guidance.

Low - V-8253 - SV-8739r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1040 (GENERAL)

Vuln IDs

V-8253

Rule IDs

SV-8739r1_rule

Voice mail services are subject to the guidance and requirements in the DSN STIG. Older voice mail systems/servers commonly use proprietary OSs while newer ones can be designed to run on common general-purpose operating systems, such as, Microsoft Windows, UNIX or Linux. If this is the case, steps should be taken to ensure that these general-purpose operating systems are secured in accordance to the appropriate STIG. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Additionally, the corruption of data and/or unauthorized use of the supporting server.Information Assurance OfficerECSC-1

Checks: C-23617r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure all systems/servers hosting the Voice Mail Service are properly secured in accordance with the DSN STIG and applicable OS STIG (i.e., Windows, Unix, etc.). Determine if the Voice Mail system/servers are based upon a general purpose OS for which there is a STIG or checklist. Obtain a copy of the applicable OS and DSN SRR or Self Assessment results and review for compliance. If SRR results are not available, perform a review to determine if the STIGs have been applied. This is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance

Fix: F-20134r1_fix

Ensure all systems/servers hosting the Voice Mail Service are properly secured in accordance with the DSN STIG and applicable OS STIG (i.e., Windows, Unix, etc.). Secure all Voice Mail systems/servers supporting the telephony environment. Apply the DSN STIG and all applicable OS STIGs (i.e., UNIX, Microsoft Windows, etc.) and ensure compliance with applicable STIG guidelines.

b

IP connected Voice/Unified Mail servers have not been secured using all applicable general purpose application STIGs.

Medium - V-8254 - SV-8740r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1045 (GENERAL)

Vuln IDs

V-8254

Rule IDs

SV-8740r1_rule

Voice mail and Unified Mail services in a VoIP environment are available in several different configurations. For example, a legacy voice mail platform can connect to a VoIP gateway to provide voice mail services for VoIP users. In the same respect, a VoIP based voice mail platform can provide voice mail services to the legacy voice users and the VoIP users. In addition to providing traditional voice mail services, many VoIP voice mail systems are also capable of providing unified mail (integrated voice and electronic mail), or by interacting with existing email messaging systems. Voice mail services are commonly configured to run on common operating systems, such as, Microsoft Windows NT, Windows 2000, or Sun Solaris. Steps should be taken to ensure that these operating systems are secured in accordance to the appropriate STIG. Application services supporting the voice mail services should also be hardened. For example, MS SQL Server may be used to support subscriber accounts, or MS IIS may be used to allow subscribers to change their voice mail settings using an Internet Browser. Various VoIP solutions use various application services to provide Voice and voice mail support. Many of these applications can provide access to the VoIP environment via unsecured channels. This can happen through the abuse and use of enabled but unused services or through known un-patched vulnerabilities that exist on common application servers. All unused services are to be disabled and all application servers are to be secured using the applicable STIG guidance. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Additionally, the corruption of data and/or unauthorized use of the supporting server.Information Assurance OfficerECSC-1

Checks: C-23621r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: In the event a Voice Mail or Unified Mail server is VoIP enabled or connected to an IP network for user access to the Voice/Unified Mail service or for system management, ensure application services supporting the voice/unified mail service such as SQL, IIS, Apache, Oracle, Exchange, etc., are properly secured according to the appropriate STIGs. Determine if the Voice/Unified Mail servers are connected to an IP network. Then determine if it is based upon any of the general purpose application technologies for which there is a STIG or checklist. Note: compliance with these STIGs is in addition to compliance with the DSN and applicable OS STIGs as covered under VoIP 0330. Obtain a copy of the applicable SRR or Self Assessment results and review for compliance. If SRR results are not available, perform a review to determine if the STIGs have been applied This is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance

Fix: F-20136r1_fix

In the event a Voice Mail or Unified Mail server is VoIP enabled or connected to an IP network for user access to the Voice/Unified Mail service or for system management, ensure application services supporting the voice/unified mail service such as SQL, IIS, Apache, Oracle, Exchange, etc., are properly secured according to the appropriate STIGs Secure IP connected Voice/Unified Mail servers. Apply all applicable general purpose application STIGs (i.e., Database, Web, Application Services, e-mail, etc.) and ensure compliance with applicable STIG guidelines.

b

Access to personal voice mail settings by the subscriber via an IP connection is not secured via encryption and/or web” server on the voicemail system is not configured in accordance with the “private web server” requirements in the Web Server STIG/Checklist.

Medium - V-8255 - SV-8741r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1520 (GENERAL)

Vuln IDs

V-8255

Rule IDs

SV-8741r1_rule

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 OfficerEBRU-1, ECCT-1, ECSC-1

Checks: C-23710r1_chk

Interview the IAO to validate compliance with the following requirement: In the event voicemail subscribers can access their voicemail settings via an IP or “web” connection (in addition to having the standard normal capability from the phone via the dial pad), ensure the connection is encrypted using HTTPS with TLS. Additionally, ensure the web server on the voicemail system/server is configured in accordance with “private web server” requirements in the Web Services STIG/Checklist. NOTE: Web Services STIG/Checklist requirements include but are not limited to user CAC/PKI authentication Inspect the Web SRR results from the web server review performed on the web based personal settings interface to the voicemail system. If there is none, perform a Web SRR. This check is not intended to determine if the asset is in full compliance, it is only to determine if the applicable STIG has been applied. This is a finding in the event the voicemail system provides a web interface that is either not configured in accordance with the applicable Web STIG/Checklist requirements and/or it does not the web interface does not use HTTPS/TLS.

Fix: F-20188r1_fix

Configure the voicemail system web access to personal settings in accordance with the applicable private web server requirements in the Web STIG/Checklist and ensure web interface is configured to use HTTPS/TLS.

a

IP based VVoIP services over Wireless LAN (WLAN - Wi-Fi 802.11x) or Wireless MAN (WMAN - WiMAX 802.16) are being used without the applicable Wireless STIG/Checklist security guidance applied to the wireless service or endpoints in addition to the VoIP STIG/Checklist requirements.

Low - V-8256 - SV-8742r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1035 (GENERAL)

Vuln IDs

V-8256

Rule IDs

SV-8742r1_rule

The incorporation of wireless technology into the VVoIP environment or service elevates many existing VoIP concerns such as quality of service (QoS), network capacity, provisioning, architecture and not the least important, security. Many government entities are exploring mobile communication solutions that include wireless VoIP that can meet critical needs for interoperability and flexibility. This will soon expand to video and unified communications over wireless. IP based wireless voice services and devices (endpoints) initially used Wi-Fi (802.11(x)) wireless LAN (WLAN) technologies. These devices are still available today and are essentially a cordless phone that happens to use Wi-Fi. Today vendors are integrating 802.11(x) VoIP capabilities into cellular phones that can transition seamlessly between a cellular network and a WLAN. This means that a user can place a call using the WLAN in their office and then move out of range and transition to their cellular carrier’s network without losing the call. Such a transition can operate in the other direction as well. Other devices integrate Cellular and Wi-Fi with WiMAX (802.11(e)) capabilities providing similar transitions as well as enterprise grade presence, messaging, directories, email, etc. Additionally, SmartPhones can support VoIP softphone applications which utilize the smartphone’s native IP connectivity. Similarly SmartPhone supported connectivity can be over cellular, Wi-Fi, and/or WiMAX network. Using these capabilities over wireless technologies presents vulnerabilities to the communications carried and the VVoIP infrastructure. Confidentiality is one of the greatest concerns requiring encryption of the media and signaling as it is on a wired MAN/WAN or LAN per the VoIP STIG/Checklist but even more so. This encryption is in addition to the WLAN encryption required by the Wireless STIG/Checklist. Additionally, per the Wireless STIG/Checklist, the endpoints must authenticate to the WLAN before being granted access thus preventing rogue endpoints and other devices from accessing the network, while the endpoint must also register with the VVoIP controllers. Another great concern for using wireless VVoIP communications services is reliability and availability when using the technology for critical C2 communications. Being wireless, all of the usual issues with radio transmission and reception come into play. In the event a C2 call is initiated, it could be blocked at either the transmitting end or the receiving end. This could be because the spectrum or channels could be busy/overloaded, unavailable, or deliberately jammed by an adversary. As such, VVoIP services should not be relied upon for C2 communications. NOTE: If Wireless VoIP technology is deployed all the requirements in the VoIP STIG/Checklist as well as those contained in the Wireless STIG/Checklist are to be applied to the wireless VoIP environment. NoneInformation Assurance OfficerECSC-1, ECWN-1

Checks: C-23624r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: In the event IP based VVoIP (V-V) services are used over a Wireless LAN (WLAN - Wi-Fi 802.11x) or Wireless MAN (WMAN - WiMAX 802.16) connection, Ensure the applicable endpoint and service related requirements contained in the Wireless STIG/Checklist have been applied to the wireless VVoIP service and endpoints in addition to the applicable VoIP STIG/Checklist requirements. NOTE: If a wireless LAN exists, the WLAN must already be implemented and secured per the Wireless STIG. NOTE: If registering an IP based wireless VVoIP endpoint asset in the DISA VMS apply the following postures to ensure the applicable checks are assigned and reviewed. > If the wireless endpoint is a PDA or smartphone, ensure the following VMS condition has been applied "Computing –Network – Wireless - PDA/PED”. > If the phone uses WLAN, the following condition should be applied in VMS to the asset "Computing –Network – Wireless – wireless Client - Wireless LAN Client”. > If the phone uses WiMax, the following condition should be applied in VMS to the asset "Computing –Network – Wireless – wireless Client - WMAN Subscriber”. Determine if the site has implemented or supports IP based wireless (802.11x or 802.16) VVoIP endpoints. If so this implies that there is a supporting WLAN and any applicable requirements in the Wireless STIG apply to the wireless VVoIP endpoints and service in addition to those in this checklist. Obtain a copy of the Wireless SRR or Self Assessment results and review for compliance. If SRR results are not available, then perform a wireless SRR on a representative number of wireless VVoIP endpoints and on the service. Areas of primary concern are, but are not limited to the following: > Is the endpoint an approved endpoint? > Is the endpoint configured to support the required VoIP endpoint, registration, authentication, and media/signaling encryption requirements? > Is the endpoint configured to support the required WLAN access control, authentication, and encryption requirements? This is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance. Additionally, this check does not relate to the STIG compliance of the WLAN itself. However if the WLAN is not STIG compliant, then the wireless VVoIP endpoints and service it supports will not meet STIG requirements. Ergo this is a finding. NOTE: Wireless endpoints in this case are typically going to be handheld devices of some sort such as a dedicated VoIP only “cordless phone”, a cellular phone with dual cellular and Wi-Fi (possibly including WiMAX) capabilities, or a PDA/PED with a VoIP soft-phone installed. However, the endpoints could also be desk phones and some could also support Bluetooth headsets, which are also covered in the Wireless STIG/Checklist. NOTE: Wireless VVoIP service relates to the conveyance of the V-V traffic over the wireless LAN/MAN including related requirements for encryption and endpoint authentication. This requirement does not relate directly to the VVoIP infrastructure connected to a wired LAN that also happens to be using wireless transport.

Fix: F-7739r1_fix

Apply requirements contained in both the VoIP STIG and the Wireless STIG wherever VoIP over Wireless is used.

b

New or recently installed VVoIP systems, devices, and/or their software loads are NOT certified, accredited, and placed on the DoD Approved Products List per DODI 8100.3 and UCR OR existing systems DO NOT appear on the current APL or the “Retired APL” lists.

Medium - V-8257 - SV-8743r1_rule

RMF Control

Severity

Medium

CCI

Version

VVT 1115 (GENERAL)

Vuln IDs

V-8257

Rule IDs

SV-8743r1_rule

DoD Instruction 8100.3 governs DoD telecommunications, the Defense Switched Network (DSN), and the Defense RED Switched Network (DRSN), and requires that “Telecommunications switches (and associated software releases) leased, procured (whether systems or services), or operated by the DoD Components, and connected or planned for connection to the DSN or PSTN, shall be joint interoperability certified by the Defense Information Systems Agency (DISA), Joint Interoperability Test Command (JITC) and granted information assurance certification and accreditation by the Defense Information System Network (DISN) Designated Approval Authorities (DAAs).” DAA certification is obtained through the DISN Security Accreditation Working Group (DSAWG). DoDI 8100.3 also requires that the DoD use (or connect to the DISN) only devices that appear on the DoD Approved Products List (APL). Both IA and Interoperability certification requirements must be met for inclusion on the DoD APL. NOTE: The DoD APL was formerly referred to as the DSN APL. Any interconnected VVoIP system or device poses a potential security risk to the DISN and should not be connected until interoperability certification by the DISA Joint Interoperability Test Command (JITC) and Information Assurance Certification and Accreditation by the DSAWG is completed per the requirements of the DoDI 8100.3. This testing is required on two fronts to ensure that the system/device will interoperate with other DoD systems in support of C2 communications requirements and that it can be secured to within an acceptable level of risk. Once approved, and APL listed, DoD components may purchase and install the systems while following the deployment restrictions and configuration guidance developed during testing. NOTE: Through the publication of the UCR, the APL requirements are being extended by OSD/NII to cover all network elements and components that support converged Assured Service (C2) communications. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Loss of confidentiality Non-compliance with public law and DOD policy resulting in the possible disconnection of the VoIP system from the DSN and other legal action.Information Assurance OfficerEBCR-1

Checks: C-23596r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure that new or recently installed VVoIP systems, devices, and/or their software loads are certified, accredited, and placed on the DoD Approved Products List per DODI 8100.3 and UCR prior to obtaining an Authority to Connect (ATC). Further ensure that existing systems appear on the current APL or the retired product list. NOTE: upgrades to and new software loads for existing systems and devices must appear on the current APL.

Fix: F-20111r1_fix

Ensure that new or recently installed VVoIP systems, devices, and/or their software loads are certified, accredited, and placed on the DoD Approved Products List per DODI 8100.3 and UCR prior to obtaining an Authority to Connect (ATC). Further ensure that existing systems appear on the current APL or the retired list. NOTE: upgrades to and new software loads for existing systems and devices must appear on the current APL.

b

A policy/SOP is NOT in place OR NOT enforced to ensure that the VVoIP terminal (VoIP phone or instrument) configuration and display password/PIN is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage).

Medium - V-8288 - SV-8783r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1500 (GENERAL)

Vuln IDs

V-8288

Rule IDs

SV-8783r1_rule

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 OfficerECSC-1, IAIA-1, IAIA-2

Checks: C-23600r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure that a policy/SOP is in place and enforced to ensure that the IPT terminal (VoIP phone or instrument) configuration and display password/PIN is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage). Additionally investigate the enforcement of the SOP. This is a finding in the event there is no SOP addressing the concern here or the SOP does not adequately address the related DoD policies OR the policy/SOP is not enforced.

Fix: F-20116r1_fix

Ensure that a policy/SOP is in place and enforced to ensure that the IPT terminal (VoIP phone or instrument) configuration and display password/PIN is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage). Develop a policy/SOP and enforced it to ensure that the IPT terminal (VoIP phone or instrument) configuration and display password is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage)).

b

An inventory of authorized instruments is NOT documented or maintained in support of the detection of unauthorized instruments connected to the VoIP system.

Medium - V-8290 - SV-8785r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1505 (GENERAL)

Vuln IDs

V-8290

Rule IDs

SV-8785r1_rule

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 OfficerECSC-1

Checks: C-23627r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure that an inventory of authorized instruments is documented and maintained. Inspect the authorized instrument inventory. NOTE: This inventory will be separate from the inventory created within the Local Session Controller (LSC) from the listing of registered instruments. Authorized instruments must be added to this inventory before configuration in the LSC and instrument registration. The inventory may be offline or online on a separate server or workstation from the LSC (for example, the LSC management workstation). This is a finding if the inventory does not exist, does not appear to be up to date. Ask how this inventory is generated and where it is stored. This is a finding in the event it is located on the LSC.

Fix: F-20141r1_fix

Ensure that an inventory of authorized instruments is documented and maintained. NOTE: This inventory will be separate from the inventory created within the Local Session Controller (LSC) from the listing of registered instruments. Authorized instruments must be added to this inventory before configuration in the LSC and instrument registration. The inventory may be offline or online on a separate server or workstation from the LSC (for example, the LSC management workstation). Prepare and maintain an inventory / database of authorized VoIP instruments. Generate and store the inventory on a separate workstation or server from the LSC (for example, the LSC management workstation). Recommendation: Create the inventory in a format that can easily be compared through automation to the report of registered instruments from the LSC (if available). This will facilitate regular review of the inventory to detect unauthorized instruments and will make the IA review easier.

a

The VVoIP system DHCP server is not dedicated to the VVoIP system within the LAN.

Low - V-8294 - SV-8789r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 5210 (LAN)

Vuln IDs

V-8294

Rule IDs

SV-8789r1_rule

When using Dynamic Host Configuration Protocol (DHCP) for address assignment and host configuration, different DHCP scopes (different address space, subnets, and VLANs) must be used for voice components and data components. This is most easily and safely accomplished by providing a DHCP server that is dedicated to the VVoIP system endpoints. That is to say that a DHCP server serving VVoIP devices needs to be in the VVoIP domain i.e., same address space and VLAN(s). This alleviates the need to route DHCP requests into the data environment on the LAN which would degrade the separation of the VVoIP environment and the Data environment. NOTE: In the event a dedicated DHCP server for VVoIP endpoints is not implemented, the network (i.e., the router controlling access to and from the VVoIP endpoint VLANs) must route VVoIP endpoint DHCP requests directly to the DHCP server in such a manner that prevents traffic to flow between the VVoIP and data VLANs. Additionally the DHCP server must prevent such traffic flows while providing the VVoIP endpoints with proper VVoIP addresses and other information within the VVoIP address/subnet range (scope). NOTE: The best practice for endpoint address assignment is to manually assign addresses when authorizing the instrument by generating its configuration file. NONELoss of reliability; Possible assignment of IP addresses that are not dedicated to the VVoIP system; Degradation of the data and VVoIP network segregation.Information Assurance OfficerECSC-1

Checks: C-23793r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system is designed to use DHCP for initial VVoIP endpoint address assignment/configuration, ensure the design incorporates a different DHCP server than any that might be used for data components/hosts. Additionally ensure these servers reside in their respective voice or data address space and VLAN. NOTE: Soft-phones or VVoIP/UC applications residing on PC/workstations will, by default, utilize the IP information obtained by the workstation from the data DHCP server unless the workstation and soft-phone is capable of multiple VLANs and the soft-phone is assigned to the VVoIP VLAN. In case of the latter, the workstation or the soft-phone itself may obtain its IP information from the VVoIP DHCP server for use by the soft-phone or VVoIP application. Determine if, in the VVoIP system design, DHCP is used for VVoIP endpoint address assignment/configuration. If so, determine the location of the DHCP server and whether it is dedicated to the VVoIP system (separate from the data host DHCP server) and is deployed in the core VVoIP VLAN with an appropriate IP address within the dedicated VVoIP address space. This is a finding in the event DHCP is used for VVoIP endpoint address assignment/configuration and these conditions are not met. NOTE: It is recommended that the VVoIP DHCP server used as discussed in this requirement be implemented in the following order of preference: a dedicated device, part of the VVoIP call controller (LSC/MFSS) or other VVoIP related server; on an infrastructure router inside the enclave that is directly involved in the control of the VVoIP system or VLANs. NOTE: The Network Infrastructure STIG precludes the implementation of a DHCP server on a perimeter router.

Fix: F-20239r1_fix

If the VVoIP system design uses DHCP for VVoIP initial endpoint address assignment/configuration, ensure the design incorporates a different DHCP server than any that might be used for data components/hosts. Additionally ensure these servers reside in their respective voice or data address space and VLAN. NOTE: Soft-phones or VVoIP/UC applications residing on PC/workstations will, by default, utilize the IP information obtained by the workstation from the data DHCP server unless the workstation and soft-phone is capable of multiple VLANs and the soft-phone is assigned to the VVoIP VLAN. In case of the latter, the workstation or the soft-phone itself may obtain its IP information from the VVoIP DHCP server for use by the soft-phone or VVoIP application. NOTE: It is recommended that the VVoIP DHCP server used as discussed in this requirement be implemented in the following order of preference: a dedicated device, part of the VVoIP call controller (LSC/MFSS) or other VVoIP related server; on an infrastructure router inside the enclave that is directly involved in the control of the VVoIP system or VLANs. NOTE: The Network Infrastructure STIG precludes the implementation of a DHCP server on a perimeter router.

a

Customers of the DISN VoSIP service on ARE NOT utilizing address blocks assigned by the DRSN / VoSIP PMO.

Low - V-8295 - SV-8790r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 5215 (LAN)

Vuln IDs

V-8295

Rule IDs

SV-8790r1_rule

A previous requirement states the following: Ensure a different, dedicated, address blocks or ranges are defined for the VVoIP system within the LAN (Enclave) that is separate from the address blocks/ranges used by the rest of the LAN for non VVoIP system devices thus allowing traffic and access control using firewalls and router ACLs. NOTE: This is applicable to the following: > A classified LAN connected to a classified WAN (such as the SIPRNet). NOTE: In the case of a classified WAN where network wide address based accountability or traceability is required by the network PMO, the PMO must provide a segregated, network wide address block(s) so that the attached classified LANs can meet this requirement. DISA provides a world wide VoIP based voice communications service called the DISN Voice over Secret IP (VoSIP) service or just VoSIP for short. This service is managed by the DRSN PMO. This service also provides gateways into the DRSN. In support of the above requirement, the SIPRNet PMO has designated specific dedicated address ranges for use by the DISN VoSIP service and assigned these address blocks to the DRSN/VoSIP PMO for VoSIP address management and assignment. The VoSIP service provides VoIP based communications between VoIP systems within customer’s classified LANs (C-LANs) operating at the secret level while using the SIPRNet WAN for the inter-enclave (inter-LAN) transport. Additionally, the SIPRNet PMO requires network wide address based accountability or traceability based on assigned IP address. As such customer’s SIPRNet connected secret C-LANs utilize addresses assigned by the SIPRNet PMO. Therefore, customers of the DISN VoSIP service must use IP addresses assigned to them by the DRSN/VoSIP PMO when addressing the VoIP controllers and endpoints within their C-LANs. This is to maintain the segregation of the Voice and data environments on the customer’s secret C-LANs as required by this STIG. This also facilitates proper routing and flow control over the traffic between VoSIP addresses. NOTE: the DISN service is designated DISN Voice over Secret IP but uses an acronym (VoSIP) which also means Voice over Secure IP. Voice over Secure IP relates to any VoIP based service on a secure or classified IP network. NOTE: While the DISN VoSIP service is the preferred means to interconnect SIPRNet connected secret C-LANs for VoIP service, it is recognized that there may be a need for an organization to implement a VoIP based voice or video communications system within their organization or with close partners. In the event such a system has no need or potential need to communicate with other enclaves that use the DISN VoSIP service, they must utilize their own dedicated IP address space carved out of the address space assigned to their C-LANs by the SIPRNet PMO in accordance with the previously noted requirement. NONEDenial of service; Lack of interoperability with other VoSIP enclavesInformation Assurance OfficerDCBP-1, DCPA-1, ECSC-1

Checks: C-23794r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure customers of the DISN VoSIP service use IP addresses assigned to them by the DRSN/VoSIP PMO when defining the required dedicated address space for the VoIP controllers and endpoints within their secret C-LANs. NOTE: This is similarly applicable to other classified DISN services and customer’s C-LANs. NOTE: This is not a requirement in the event a VoIP based VVoIP communications system operated in a secret C-LAN has no need or potential need to use the worldwide DISN VoSIP service or have access the DRSN and communicate with other enclaves that do use the DISN service or have access the DRSN, they must utilize their own dedicated IP address space carved out of the address space assigned to their C-LANs by the SIPRNet PMO in accordance with the previously noted requirement. NOTE: This requirement does not directly apply to dedicated hardware based IP - VTC systems using the C-LAN and SIPRNet for transport although there may be similar requirements to address this technology in the future. Determine the following: Is the organization’s secret C-LAN connected to SIPRNet? Does the organization’s secret C-LAN support VVoIP communications (Not dedicated IP based VTC)? Does organization’s secret C-LAN VVoIP system interconnect with other enclaves using the DISN VoSIP service? What address blocks are dedicated to the VVoIP system on the C-LAN? Is there documented evidence that the DRSN/VoSIP PMO assigned these addresses to the organization or can such assignment be validated by other means? This is a finding in the event the organization’s secret C-LAN supports VVoIP communications (Not dedicated IP based VTC) AND is connected to SIPRNet AND uses the DISN VoSIP service BUT DOES NOT use the DRSN/VoSIP PMO assigned address blocks when addressing all of the VVoIP system components.

Fix: F-20240r1_fix

Ensure customers of the DISN VoSIP service use IP addresses assigned to them by the DRSN/VoSIP PMO when defining the required dedicated address space for the VoIP controllers and endpoints within their secret C-LANs. NOTE: This is similarly applicable to other classified DISN services and customer’s C-LANs. NOTE: This is not a requirement in the event a VoIP based VVoIP communications system operated in a secret C-LAN has no need or potential need to use the worldwide DISN VoSIP service or have access the DRSN and communicate with other enclaves that do use the DISN service or have access the DRSN, they must utilize their own dedicated IP address space carved out of the address space assigned to their C-LANs by the SIPRNet PMO in accordance with the previously noted requirement. NOTE: This requirement does not directly apply to dedicated hardware based IP - VTC systems using the C-LAN and SIPRNet for transport although there may be similar requirements to address this technology in the future. Obtain and assign IP addresses as provided by the DRSN PMO- VoSIP department when defining the required dedicated address space on the LAN.

a

The LAN supporting VVoIP services for special-C2 and C2 users is not designed or implemented as a DOD ASLAN in accordance with the current UCR and therefore cannot support assured service in support of C2 communications reliability and availability requirements.

Low - V-8302 - SV-8797r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 5105 (LAN)

Vuln IDs

V-8302

Rule IDs

SV-8797r1_rule

Voice services in support of C2 and Special C2 users are required to meet certain minimum requirements relating to reliability and survivability of the supporting infrastructure. These requirements are defined in the current CJCSI 6215.01x Policy for DoD Voice Networks With Real Time Services (RTS). Design requirements for networks supporting DOD IPT/VoIP implementations can be found in the Unified Capabilities Requirements (UCR) specification document. This document contains the design specifications for an Assured Services Local Area Network (ASLAN) which is required to support DOD IP based voice services. These specifications define LAN design requirements for redundancy of equipment and their interconnections as well as minimum requirements for bandwidth and backup power, including the maximum number of endpoints that can be affected by a single point of failure. Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. Policy excerpts are as follows: 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 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details.NONEReduced availability and reliability or 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 OfficerECSC-1

Checks: C-23781r1_chk

Interview the IAO and review site network/facilities diagrams and documentation to confirm compliance with the following requirement: In the event VVoIP services are provided by an IP based network to Special-C2 and C2 subscribers/users, ensure the network supporting VVoIP services (i.e., the underlying data network) is designed and implemented as an Assured Services Local Area Network (ASLAN) such that it will possess bandwidth, reliability, survivability, quality of service (QoS) and prioritization capabilities in accordance with the current Unified Capabilities Requirements (UCR) specifications. NOTE: This applies to all types of C2 users whether they have the need to originate precedence calls or not. C2 routine users may receive high priority calls therefore the LAN must support the capability. Determine the types of users or subscribers supported by the IP VVoIP services network. Refer to the Procedures Guide for the various user/subscriber type definitions to determine applicability of this requirement. This is a finding in the event the LAN is not designed as an ASLAN in support of its C2 and Special-C2 user’s availability and reliability requirements. The following is a list of the areas to be addressed by the design (validation will be addressed later): Specific attention should be given in the areas of: - Equipment reliability and redundancy - Connection redundancy above the access layer - Equipment robustness and bandwidth capability - Connection bandwidth capability - Access layer switch size / number of phones served - Single points of failure affecting service to greater than 96 instruments. - Backup power for all equipment. >> 2 hours for all equipment and instruments supporting C2 users >> 8 hours for all equipment and instruments supporting Special-C2 users Specific requirements or deficiencies will be investigated in subsequent checklist items. NOTE: The primary difference between this requirement and the general requirement checked earlier is that the availability and reliability requirements in support of C2 and Special-C2 users are higher than C2R, Non C2, and administrative users.

Fix: F-20217r1_fix

Ensure that the network supporting VVoIP services (i.e., the underlying data network) is designed and implemented as an Assured Services Local Area Network.(ASLAN) and will possess bandwidth, reliability, survivability, quality of service (QoS) and prioritization capabilities in accordance with the current Unified Capabilities Requirements (UCR) specifications Upgrade the LAN infrastructure as necessary to meet requirements of a DoD ASLAN supporting C2 users as specified in the UCR and CJCSI 6215.01x.

b

A hardware based VVoIP or VTC endpoint possesses or provides a “PC Port” but does not maintain the required VLAN separation through the implementation of an Ethernet switch (not a hub).

Medium - V-8306 - SV-8801r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5700 (LAN)

Vuln IDs

V-8306

Rule IDs

SV-8801r1_rule

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 OfficerDCPA-1, ECSC-1

Checks: C-23809r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure a VVoIP or VTC hardware endpoint possessing a “PC Port” is capable of maintaining voice/data VLAN separation via the use of an Ethernet switch and that it does not contain an Ethernet hub OR ensure the “PC Port” is physically disabled. Review VVoIP or VTC hardware endpoint specifications and documentation. This is a finding in the event the VVoIP or VTC hardware endpoint that provides PC port but cannot maintain voice/data VLAN separation.

Fix: F-20257r1_fix

Ensure a VVoIP or VTC hardware endpoint possessing a “PC Port” contains an Ethernet switch such that VLAN separation can be maintained and that it does not contain an Ethernet hub OR ensure the “PC Port” is physically disabled.

b

The VVoIP VLAN ACL design must document the control of VVoIP system access and traffic flow.

Medium - V-8323 - SV-8818r2_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5515 (LAN)

Vuln IDs

V-8323

Rule IDs

SV-8818r2_rule

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 OfficerDCPA-1, ECSC-1

Checks: C-23806r2_chk

Interview the IAO to confirm compliance with the following requirement: Verify a comprehensive VVoIP VLAN ACL design is developed for the supporting LAN such that VVoIP system access and traffic flow is properly controlled. The defined ACLs must use a deny-by-default configuration allowing only the protocols and traffic required to reach the device. The ACLs filter on VLAN, IP address, subnet, protocol type, and associated standard IP port for the protocol. The ACLs generally are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. 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 ACL design will change depending on the specifics of the VVoIP system implementation such as the components used and defined VLANs. The design documentation must be maintained for future review. If a comprehensive VVoIP VLAN ACL design for the supporting LAN properly controlling VVoIP system access and traffic flow is not in place, this is a finding.

Fix: F-20256r2_fix

Develop a comprehensive VVoIP VLAN ACL design for the supporting LAN that properly controls VVoIP system access and traffic flow. The design documentation must be maintained for future review.

c

The implementation of a VVoIP system in the local enclave and its connection to external networks degrades the enclave’s perimeter protection due to an inadequate design of the VVoIP boundary with those external networks.

High - V-8328 - SV-8823r1_rule

RMF Control

Severity

High

CCI

Version

VVoIP 1005 (GENERAL)

Vuln IDs

V-8328

Rule IDs

SV-8823r1_rule

VVoIP has the potential to significantly degrade the enclave boundary protection afforded by the required boundary firewall unless the firewall is designed to properly handle VVoIP traffic. The typical firewall used to protect an enclave that supports normal data traffic is not capable of properly handling or supporting real time communications (VVoIP). The following paragraphs will demonstrate this. VVoIP uses a signaling protocol and a media transfer protocol that require both inbound and outbound permissions be set for these protocols in order to provide the capability to place and receive calls to/from endpoints outside the enclave. More specifically, the signaling protocol typically uses one or more static TCP ports that must be open inbound at all times to receive calls. The media protocol; Real-time Transfer Protocol (RTP) and its companion protocol Real-time Transfer Control Protocol (RTCP) utilize randomly assigned UDP ports in the potential range of 1025-65535 with four IP ports required for every bi-directional voice session/call. The number of ports is expanded if video is added. The typical method of supporting VoIP through a standard data firewall is to open (or permit inbound) the signaling IP port(s) and a wide range of UDP ports for the RTP/RTCP media streams. While a typical data firewall can provide some protection from a VoIP implementation if the inbound permit statements are limited to specific limited address ranges (applicable in some situations), this is not possible if calls are to be permitted from any IP address on the Internet or NIPRNet that could be located anywhere in the world. Address segregation for VVoIP is generally not possible since the NIPRNet address space is disjointed (chopped up) and is spread across the overall public Internet (IPv4) address space. To support a worldwide IP enabled DSN, a typical data firewall would need to permit VVoIP signaling and media inbound from the entire registered IPv4 address space. One reason why this is the case is that an ACL developed to limit inbound enclave access to permit only NIPRNet addresses would require many permit statements such that the ACL itself could degrade firewall or router performance. As such, permitting VVoIP traffic across a standard data firewall opens gaping holes in the enclave’s perimeter protection. This is of particular concern when the WAN is the Internet or a DISN service that provides connection to the INTERNET such as the NIPRNet. On the other hand, a standard data firewall poses problems for VVoIP call/session completion if external public addressing is used with internal private (RFC 1918) addressing which requires the firewall to do NAT/NAPT. This is because the VVoIP endpoints need to know the IP address of the other endpoint and they signal their address within the signaling messages. The firewall changes the IP address of the packet during the NAT but does not change it in the signaling message causing a mismatch. The effect is that the call/session cannot be completed. NOTE: If the WAN is a “closed” system where the entire address space of the WAN and connected enclaves is managed by a “single system manager” (as is the case with DISN classified networks) a specific limited and segregated address space can be assigned for all VVoIP devices for use across the entire network. In this case, the risk to the enclave can be limited (although not eliminated) if a standard firewall is used with inbound permit statements that are based on the segregated IP address range. This protection can be further enhanced by limiting the UDP port range. An allowance has been made for such a situation; however, this may change in the future. Based on the above, If VVoIP is to traverse the enclave boundary; the firewall must be VVoIP aware or capable. A VVoIP aware/capable firewall provides the following minimal functions. > Interprets and understands the signaling protocol to determine the UDP ports that are negotiated for the RTP/RTCP media streams. > Dynamically opens the required UDP ports to permit the flow of the media (audio and video). > Performs stateful inspection on the UDP media packets to ensure the packets are part of the active call/session, while dropping all non session packets. > Closes the UDP ports when the end of the call/session is signaled OR after a period of session inactivity. In the event NAT is used across the enclave boundary, the VVoIP aware/capable firewall provides the following NAT functions: > Interprets and understands the signaling protocol to determine the IP addresses that are negotiated between the endpoints and adjusts the signaling messages in accordance with the local NAT/NAPT internal and external addresses. > Performs the NAT/NAPT address changes on the RTP/RTCP media packets as they traverse the boundary. In the event, the VVoIP enclave boundary provides access to and interoperability with a DISN IP based assured service voice service (such as the IP-DSN on NIPRNet), VVoIP aware/capable firewall must provide the following additional functions (Note: these are defined in the UCR): > Provides encryption services for the signaling protocol (AS-SIP uses TLS) > Provides authentication of the source of the signaling protocol packets and drops all unauthenticated packets. > Provides integrity validation of the signaling protocol packets and drops all invalid or modified packets. > Terminates the AS-SIP signaling session and checks the validity of the AS-SIP messages based on content and establishes a new signaling session for the next hop, thus performing an application level inspection of the signaling messages. > Communicates with Call controllers (LSCs and MFSSs) using AS-SIP/TLS > Interprets and understands the AS-SIP signaling protocol to provide the minimal and NAT functions noted above > Supports encrypted RTP/RTSP media streams. That is SRTP/SRTCP > Provides the capability to decrypt the media streams for inspection and recording. This supports monitoring/recording for CALEA and COMSEC monitoring purposes for calls that traverse the enclave boundary. > Performs intrusion and DoS detection with alarm capability for both the signaling and media. > Blocks all non VVoIP traffic whether destined for the VVoIP or data sub-enclaves. NOTE: While RTCP messages could be validated for content and format, the contents of RTP packets cannot due to the random nature of the audio and video data being transmitted. Delaying the RTCP packets for inspection or the SRTCP messages for decryption and inspection while passing the RTP/SRTP packets would cause disruption in the media flow and thereby negatively affect its quality. Additionally, the delay of the SRTP packets for decryption and inspection would have similar effects. Thus intrusion detection based on the media streams is almost impossible since attack profiles are generally unavailable. Based on this and to improve worldwide voice quality, the DSN/RTS PMO and the RTS WG has determined that the SRTP/SRTCP streams will be passed by the VVoIP firewall without inspecting the encrypted contents of the packets. NOTE: The VVoIP aware/capable firewall discussed here defines a set of functions that are unique to a VVoIP which are different from the set of functions required for data firewalls. The functions for data firewalls are defined in the Network Infrastructure STIG. While typically a single firewall will not be capable of supporting both sets of functions (which means a separate VVoIP firewall is needed in parallel to the data firewall) this requirement does not mean that a dedicated VVoIP firewall must be implemented in the event a single firewall is capable of implementing both sets of functions simultaneously. The primary task of the data firewall function is to protect the entire enclave. In doing so, it must perform its normal function of protecting the data sub-enclave while also blocking all VVoIP traffic destined for it via the data firewall. An exception could be made for this on a case by case basis if permissions are limited in scope as would be the case for VTC. All data traffic/protocols destined for the VVoIP sub-enclave must also be blocked unless specifically authorized to meet a mission need. Such a mission need might be for remote management of the VVoIP system from a NOC or user-to-site VPN, however, this traffic must would be routed to the VVoIP management VLAN(s) and not the VVoIP production VLANs. An additional consideration for passing VoIP across an enclave boundary is when there are different vendor’s VoIP systems deployed within the different enclaves connected to the WAN, and the various vendor’s systems are not interoperable or do not provide assured service outside the enclave, or the WAN cannot support QoS and assured service. In this case, interoperability and assured service must be preserved across the DSN or DISN voice network, whether traditional TDM or VoIP. Therefore, the VoIP system must connect to other enclaves via a traditional TDM based long haul network. Such a connection is made using a media gateway. Therefore, if the enclave VoIP system is not compatible with the IP enabled DSN as defined in the UCR thereby providing interoperability and assured service end-to-end across the DISN voice network, the system must employ a media gateway and connect to a traditional DSN switch. Additionally, unless specific requirements (discussed later) are met, all connections to the PSTN must be via a media gateway and an appropriate trunk (PRI or CAS). NONEThe enclave boundary protection is bypassed or degraded permitting unauthorized access to the LAN / Enclave.Information Assurance OfficerEBBD-1, EBBD-2, EBBD-3, ECSC-1

Checks: C-23854r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event a VVoIP system is deployed/implemented within the local enclave (LAN/CAN) AND the enclave accesses or connects to external networks (for example, another LAN or a WAN), ensure the enclave’s connection to the external network is designed to maintain the required enclave boundary protection for the data, VVoIP, and VTCoIP sub-enclaves (internal VLANS); maintains VLAN separation within the LAN/CAN; as well as support assured service interoperability between different vendor’s VVoIP systems implemented in different enclaves. NOTE: Connection to a WAN generally means a connection to a DISN service such as the NIPRNet or SIPRNet but might also refer to the Internet. Determine if the local enclave (LAN/CAN) connects to a WAN or if it reaches the WAN via a connection with another LAN/CAN/enclave as might be the case for a tenant of a larger BCPS (subtended enclave). If so, determine if the enclave’s boundary protection is designed/implemented to protect the VVoIP endpoints and infrastructure as well as the data enclave. > The data firewall function provides protection for the VVoIP sub-enclave (VLANs) and infrastructure as follows: >> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC >> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs. >> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations (local or in a remote NOC). >> Inspects (along with the IDS) all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose.) > The VVoIP firewall function Required if VVoIP is permitted on the WAN)provides protection for the VVoIP sub-enclave and the data sub-enclave as follows: >> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs >> Inspects all VVoIP traffic destined for the VVoIP production VLANs. >> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication of this is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html. > In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system). NOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements. NOTE: The following is here for informational purposes and is discussed in another requirement. > In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor’s VVoIP system does not directly interoperate with other vendor’s VVoIP systems AND the VVoIP system is connected to the DSN, the connection is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk).

Fix: F-20286r1_fix

In the event a VVoIP/UC system is deployed/implemented within the enclave AND the enclave accesses external networks, ensure the enclave’s connection to external networks is designed to maintain the required enclave boundary protection for both the data and voice/video sub-enclaves as well as separation within the LAN and to support interoperability between different vendor’s VVoIP/UC systems implemented in different enclaves. Design and implement the boundary protection to provide for the following: > The data firewall function provides protection for the VVoIP sub-enclave and infrastructure as follows: >> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols, etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC >> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs. >> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations. >> Inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose). The network IDS inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose). > The VVoIP firewall function provides protection for the VVoIP sub-enclave and the data sub-enclave as follows: >> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs. >> Inspects all VVoIP destined for the VVoIP production VLANs. >> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html. > In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor’s VVoIP system does not directly interoperate with other vendor’s VVoIP systems AND the VVoIP system is connected to the DSN; the connection to the DSN is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk) NOTE: this is covered under another requirement. > In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system). NOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements. In the event the enclave is part of a “closed” DISN classified network or an organizational intranet AND the PMO for the “closed” DISN classified network or an organizational intranet has designated a segregated IP address range for use by VVoIP systems, AND There is no dedicated VVoIP firewall function (as defined by the UCR) implemented, configure the system for the following: >> Utilizes the PMO designated VVoIP address space for the VVoIP system within the enclave. >> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on the PMO designated VVoIP address space. >> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on a limited range of UDP ports as needed for the particular vendor’s system implemented. NOTE: in the event the enclave is part of an organizational intranet, and there is no firewall at the local enclave perimeter, configure the perimeter/premise router to provide the required filtering and routing along with ensuring all inbound and outbound traffic enters the required dedicated circuit or encrypted VPN. Specific network requirements for organizational intranet design and implementation is beyond the scope of this document.

b

Without an applicable exception the site’s enclave boundary protection is not designed or implemented to route all voice traffic to/from a DSN number via a locally implemented Media Gateway (MG) connected to a DSN EO or MFSS using the appropriate type of trunk based on the site’s need to support C2 communications via the DSN.

Medium - V-8329 - SV-8824r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1010 (GENERAL)

Vuln IDs

V-8329

Rule IDs

SV-8824r1_rule

There are several reasons why voice traffic to/from the DSN must use a locally implemented Media Gateway (MG) connected to a DSN EO or MFSS via the appropriate type of trunk based on the site’s need to support C2 communications via the DSN if exceptions do not apply. These reasons are as follows: > VVoIP has the potential to significantly degrade the standard data enclave boundary protection afforded by the required data enclave firewall unless the firewall is designed to properly handle VVoIP traffic. Based on this degradation, VVoIP must not traverse a standard data firewall except under certain circumstances. > VVoIP aware/capable firewalls are being developed and few are deployed. > DoD must purchase and use VVoIP/UC devices and firewalls that meet UC requirements as defined in the UCR. > Confidentiality and integrity: Legacy (early) VoIP systems could not encrypt VoIP signaling or media to protect it for confidentiality and from various attacks while traversing a publicly accessible WAN (e.g., NIPRNet or Internet). This is changing due to the DoD’s efforts to develop interoperable VVoIP encryption standards with vendor assistance. The 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 in general even though they are not encrypted. Physical access to the wire or TDM switch is required to compromise TDM communication whereas compromise could be effected from anywhere on an IP network. > Availability and C2 support between sites via interoperability: VoIP systems from different vendors are typically not directly interoperable via IP. This is primarily due to the lack of fully defined standards leaving vendors to develop their own extensions to the available protocols in support of unique feature sets. This is changing due to the DoD’s efforts to develop interoperable usage of the standards with vendor assistance. The use of a MG converts each vendor’s implementation to a common interoperable system, the TDM DSN. NONEInability to communicate outside the enclave and/or significant degradation of the data enclave’s boundary protectionInformation Assurance OfficerEBBD-1, EBBD-2, EBBD-3, ECSC-1

Checks: C-23858r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure all local DSN access for intra DoD dialup services (voice, video, fax, data) to/from a VVoIP system within a site enclave and a DSN number is via a local Media Gateway (MG) and one or more T619A trunks for C2 enclaves (MLPP support) or one or more PRI or CAS trunks for NON-C2 enclaves with a IP-PBX-2 (NO MLPP support) to a DSN EO or MFS except as follows: • The VVoIP system within a site enclave is approved for DISN NIPRNet IP Voice Services (VS) (IP enabled DSN VoIP on NIPRNet). • The VVoIP system within a site enclave is subtended to a larger enclave and tethered (connected) to it via a direct cable, or a dedicated TDM or optical circuit (e.g., a T1, DS2, OCx ). (This connection would be typical of a GSU located in relative close proximity to its MOB. This would be similar to a MAN). • The enclave is part of an organizational Intranet whose enclaves (MOBs and GSUs and regional service/computing centers or server farms) are interconnected across the DISN using dedicated TDM or optical circuits or encrypted VPN tunnels, whether site-to-site or meshed. NOTE: organizational Intranets using encrypted site-to-site or meshed VPN tunnels across a DISN IP routed network must block local access to/from the DISN IP routed network (e.g., NIPRNet) at the VPN termination points unless a full boundary protection suite of equipment is implemented locally. NOTE: This does not apply to approved remote VoIP instruments or Soft Phones that connect to the VVoIP system enclave via an encrypted VPN and are therefore part of the enclave’s LAN. NOTE: TDM or optical circuits should be bulk encrypted if using a commercial provider to supply any portion of the complete circuit. This will most likely be the case for the “last mile” connection to a DISN SDN since DoD owned facilities do not touch most sites. Determine if the VVoIP system within the site enclave is connected to a DSN EO or MFS via a local (on site) Media Gateway (MG) and one or more T619A trunks for C2 enclaves (provides MLPP support) or one or more PRI or CAS trunks for NON-C2 enclaves with a IP-PBX-2 (NO MLPP support). Additionally, determine if the following exceptions apply: • Is the VVoIP system within the site enclave approved for DISN NIPRNet IP Voice Services (VS) (IP enabled DSN VoIP on NIPRNet)? • Is the VVoIP system within the site enclave subtended to a larger enclave and tethered (connected) to it via a direct cable, or a dedicated TDM or optical circuit (e.g., a T1, DS2, OCx )? (This connection is typical of a GSU located in relative close proximity to its MOB. This would be similar to a MAN.) • Is the enclave part of an organizational Intranet whose enclaves (MOBs and GSUs and regional service centers or server farms) are interconnected across the DISN using dedicated TDM or optical circuits or encrypted VPN tunnels, whether site-to-site or meshed? This is a finding in the event the site is not connected to the DSN via a MG located at the local site enclave as described above AND one of the exceptions is not applicable. NOTE: This requirement dictates that each site’s VoIP enclave has a local (on site) MG for connecting the site locally to a DSN EO or MFS. The DSN EO or MFS may be located at a remote site, in which case the TDM trunks will carry the voice traffic between the sites. This arrangement means that VoIP traffic does not have to traverse the enclave boundary with the WAN which is one of the reasons for the requirement.

Fix: F-20287r1_fix

Unless one of the following exceptions apply: • The VVoIP system within a site enclave is approved for DISN NIPRNet IP Voice Services (VS) (IP enabled DSN VoIP on NIPRNet). • The VVoIP system within a site enclave is subtended to a larger enclave and tethered (connected) to it via a direct cable, or a dedicated TDM or optical circuit (e.g., a T1, DS2, OCx ). (This connection would be typical of a GSU located in relative close proximity to its MOB. This would be similar to a MAN.) • The enclave is part of an organizational Intranet whose enclaves (MOBs and GSUs and regional service/computing centers or server farms) are interconnected across the DISN using dedicated TDM or optical circuits or encrypted VPN tunnels, whether site-to-site or meshed. Ensure all DSN access for intra DoD dialup services (voice, video, fax, data) to/from a VVoIP system within a site enclave and a DSN number is via a local (on site) Media Gateway (MG) and one or more T619A trunks for C2 enclaves (MLPP support) or one or more PRI or CAS trunks for NON-C2 enclaves with a IP-PBX-2 (NO MLPP support) to a DSN EO or MFS: NOTE: This does not apply to approved remote VoIP instruments or Soft Phones that connect to the VVoIP system enclave via an encrypted VPN and are therefore part of the enclave’s LAN. NOTE: TDM or optical circuits should be bulk encrypted if using a commercial provider to supply any portion of the complete circuit. This will most likely be the case for the “last mile” connection to a DISN SDN since DoD owned facilities do not touch most sites. NOTE: organizational Intranets using encrypted site-to-site or meshed VPN tunnels across a DISN IP routed network must block local access to/from the DISN IP routed network (e.g., NIPRNet) at the VPN termination points unless a full boundary protection suite of equipment is implemented locally.

b

Software patches for critical VoIP servers and other IPT devices DO NOT originate from the system manufacturer and are NOT applied in accordance with manufacturer’s instructions.

Medium - V-8349 - SV-8844r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1200 (GENERAL)

Vuln IDs

V-8349

Rule IDs

SV-8844r1_rule

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 OfficerECSC-1

Checks: C-23623r1_chk

Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure that software patches for critical, VVoIP servers and other related devices originate from or are approved by the system vendor/manufacturer and are applied in accordance with their instructions. Third party OEM upgrades/patches from general-purpose OS and application vendors or the OSS community are not to be applied without the system vendor’s approval and assurance that such application will not impact the system negatively. NOTE: This includes patches or mitigations required by IAVAs. IAVA vulnerabilities must be referred to the system vendor to determine applicability and a mitigation path.

Fix: F-20138r1_fix

Ensure that software patches for critical, VVoIP servers and other related devices originate from or are approved by the system vendor/manufacturer and are applied in accordance with their instructions. Third party OEM upgrades/patches from general-purpose OS and application vendors or the OSS community are not to be applied without the system vendor’s approval and assurance that such application will not impact the system negatively. Note: This includes patches or mitigations required by IAVAs. IAVA vulnerabilities must be referred to the system vendor to determine applicability and a mitigation path. Only Apply vendor-approved or vendor supplied patches. Correct site policy to require only vendor provided and approved patches are applied.

b

C2 and Special-C2 users are not aware of the assured service limitations of their PC based communications applications.

Medium - V-16070 - SV-17057r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1300 (GENERAL)

Vuln IDs

V-16070

Rule IDs

SV-17057r1_rule

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 ManagerECSC-1, PRTN-1

Checks: C-17113r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure C2 and special-C2 users are made aware of the potential for unreliability and reduced availability of PC based communications for assured service/C2 communications in the various situations in which they might use their PC for this purpose. The IAO will additionally ensure C2 and Special-C2 users are made aware of the need for, and availability of, backup communications methods are available and provided in these various situations. Additionally, interview a random sampling of C2 and special-C2 users to confirm their awareness. This is a finding in the event the users are unaware of the limitations of reliability and/or there is no attempt to make them aware.

Fix: F-16175r1_fix

Ensure C2 and Special-C2 users are made aware of the potential for unreliability and reduced availability of PC based communications for assured service/C2 communications in the various situations in which they might use their PC for this purpose. The IAO will additionally ensure C2 and Special-C2 users are made aware of the need for, and availability of, backup communications methods are available and provided in these various situations. Implement training for C2 and Special-C2 users to provide awareness of the potential for unreliability and reduced availability of PC based communications for assured service / C2 communications in the various situations in which they might use their PC for this purpose.

b

A C2 or Special-C2 user does not have a more reliable communications method in their normal or alternate fixed workspace than a PC based communications client.

Medium - V-16073 - SV-17060r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1205 (GENERAL)

Vuln IDs

V-16073

Rule IDs

SV-17060r1_rule

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 ManagerDCBP-1, ECSC-1

Checks: C-17115r1_chk

Interview the IAO and a sampling of C2 or Special-C2 users to determine if C2 or Special-C2 users are provided with a more reliable communications method than a PC based communications application in compliance with the following requirement: Within a C2 or Special-C2 user’s normal workspace (e.g., office) or alternate fixed workspace (e.g., quarters, alternate office), ensure C2 and Special-C2 users are provided with an alternate assured service communications device/system (e.g., hardware based IP or traditional telephone endpoint) is provided as backup to a PC based communications application (e.g., soft-phone) for their mission critical assured service (C2) voice communications needs if and when the PC or application fails or is unavailable. Note: Cell phones. PDA/PEDs, or other wireless devices are not considered reliable enough within a normal workspace to meet this requirement due to lack of reliable signal everywhere and their inability to be used in certain DoD environments. However these could be considered in a remote use case. NOTE: This is not intended to require the installation of assured service communications devices in alternate workspaces such as quarters unless there is a requirement for the C2 or Special-C2 user to place and receive C2 communications in that location. This is a finding if C2 or Special-C2 users are not provided with a more reliable communications method than a PC based communications application for their assured service needs.

Fix: F-16177r1_fix

Ensure C2 and Special-C2 users are provided with an alternate assured service communications device/system (e.g., hardware based IP or traditional telephone endpoint) is provided as backup to a PC based communications application (e.g., soft-phone) for their mission critical assured service (C2) voice communications needs Minimally provide C2 and Special-C2 users with a hardware based telephone and supporting infrastructure that can support reliable assured service communications within their normal or alternate workspaces.

c

Deficient Policy or SOP for VTC and PC camera operations regarding their ability to pickup and transmit sensitive or classified information in visual form.

High - V-16074 - SV-17061r2_rule

RMF Control

Severity

High

CCI

Version

VVoIP/VTC 1900 (GENERAL)

Vuln IDs

V-16074

Rule IDs

SV-17061r2_rule

Users of conference room or office based VTC systems and PC based communications applications that employ a camera must not inadvertently display information of a sensitive or classified nature that is not part of the communications session while the camera is active. This can happen if information in the form of charts, pictures, or maps are displayed on a wall within the viewing, or capture range of a camera. Any Pan, Tilt, and Zoom (PTZ) capabilities of the camera must be considered. One may consider visual information out of range, but it may be in range considering camera capabilities such as high definition, PTZ, and video enhancement possibilities for captured frames. Inadvertent display of classified information could also happen if the information is laying on a desk or table unprotected. NOTE: Vulnerability awareness and operational training will be provided to users of VTC and video/collaboration communications related camera(s) regarding these requirements. NOTE: This requirement is relevant no matter what the classification level of the session. In an IP environment the classification of VTC or PC communications is dependent upon the classification of the network to which the VTU or PC is attached and the classification of the facility in which it is located. While classified communications can occur at the same level of classification as the network and facility, communications having a lower classification or no classification (e.g., unclassified or FOUO) may also occur in the same environment. As such, sensitive or classified information that is not part of the communications session might be improperly disclosed without proper controls in place.NONEInformation Assurance OfficerInformation Assurance ManagerDCBP-1, ECND-1, ECSC-1

Checks: C-17117r3_chk

Interview the IAO to validate compliance with the following requirement: Ensure a policy and procedure is in place and enforced that addresses the operation of video/collaboration communications related cameras (e.g., webcams or VTC cameras) regarding their ability to inadvertently capture and transmit sensitive or classified information such that: - Conference room and office users do not display sensitive or classified information on walls that are within the view of the camera(s). - Conference room and office users do not place sensitive or classified information on a table or desk within the view of the camera(s) without proper protection (e.g., a proper cover). - Conference room and office users do not read or view sensitive or classified information at such an angle that the camera(s) could focus on it. NOTE: While covering such information mitigates disclosure when a camera is to be used, if the camera is activated unexpectedly or without taking action to cover the information prior to activating, the information can be compromised. The best practice is to not display it in view of the camera at all. NOTE: Vulnerability awareness and operational training will be provided to users of video/collaboration communications related camera(s) regarding these requirements. NOTE: This requirement is relevant no matter what the classification level of the session. In an IP environment the classification of PC communications is dependent upon the classification of the network to which the PC is attached, and the classification of the facility in which it is located. While classified communications can occur at the same level of classification as the network and facility, communications having a lower classification or no classification (e.g., unclassified or FOUO) may also occur in the same environment. As such, sensitive or classified information that is not part of the communications session might be improperly disclosed without proper controls in place. Inspect the applicable SOP. Inspect a random sampling of workspaces and conference rooms to determine compliance. Look for potentially sensitive information posted on the walls in view of the camera(s). Interview the IAO to determine how the SOP is enforced. Inspect user training materials and discuss practices to determine if information regarding the SOP is conveyed. Interview a random sampling of users to confirm their awareness of the SOP and related information. This is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details.

Fix: F-16179r1_fix

Ensure a policy and procedure is in place and enforced that addresses the operation of video/collaboration communications related cameras (e.g., webcams or VTC cameras) regarding their ability to inadvertently capture and transmit sensitive or classified information. Do not post potentially sensitive information posted on the walls in view of the camera(s). Produce an SOP that addresses the operation of video/collaboration communications related cameras (e.g., webcams or VTC cameras) regarding their ability to inadvertently capture and transmit sensitive or classified information such that: - Conference room and office users do not display sensitive or classified information on walls that are within the view of the camera(s). - Conference room and office users do not place sensitive or classified information on a table or desk within the view of the camera(s) without proper protection. (e.g., a proper cover). - Conference room and office users do not read or view sensitive or classified information at such an angle that the camera(s) could focus on it. NOTE: while covering such information mitigates disclosure when a camera is to be used, if the camera is activated unexpectedly or without taking action to cover the information prior to activating, the information can be compromised. Best practice is to not display it in view of the camera at all. Provide appropriate training such that users follow the SOP. Enforce user compliance with the SOP.

b

Deficient Policy or SOP regarding VTC, PC, and speakerphone microphone operations regarding their ability to pickup and transmit sensitive or classified information in aural form.

Medium - V-16076 - SV-17063r1_rule

RMF Control

Severity

Medium

CCI

Version

VVT/VTC 1905 (GENERAL)

Vuln IDs

V-16076

Rule IDs

SV-17063r1_rule

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(s) 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(s). 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 pickup sound that is not related to a given communications session. They could pickup 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 (e.g., cube). 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 a 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. NONEThe inadvertent transmission of sensitive or classified information within the pickup range of a microphone or broadcast range of a speaker used for audio communications resulting in the improper disclosure of sensitive or classified information.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECND-1, ECSC-1

Checks: C-17118r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure a policy and procedure is in place and enforced that addresses the placement and operation of hardware based voice and video communications devices and PC based voice, video, UC, and collaboration communications applications with regard to their audio pickup and broadcast capabilities in relation to the sensitivity of the information communicated. Operational policy and procedures are included in user training and guides. NOTE: This SOP should take into account the classification of the area where the VTU or PC supporting a PC based voice, video, UC, and collaboration communications applications is installed as well as the classification and need-to-know restraints of the information generally communicated via the facility or specific VTU. Along with those mentioned above, measures should be included such as closing office or conference room doors; muting of microphones before and after conference sessions, and during conference breaks; volume levels in open offices as well as muting the microphone when not speaking. Inspect the applicable SOP. Such an SOP should include policy on the use of headsets containing short range microphones and earphones in lieu of long range microphones and speakers in an open office environment. It should address the volume settings of speakers such that the session information is not heard by non-participants in a work area. It should also address the potential for the pickup of non-session related conversations in the work area. Inspect user training materials and discuss practices to determine if information regarding the SOP is conveyed. Interview a random sampling of users to confirm their awareness of the SOP and related information. This is a finding if the SOP or training is deficient.

Fix: F-16180r1_fix

Ensure a policy and procedure is in place and enforced that addresses the placement and operation of hardware based voice and video communications devices and PC based voice, video, UC, and collaboration communications applications with regard to their audio pickup and broadcast capabilities in relation to the sensitivity of the information communicated. Operational policy and procedures are included in user training and guides. Produce an SOP that addresses the operation of hardware based voice and video communications devices and PC based voice, video, UC, and collaboration communications applications with regard to their audio pickup and broadcast capabilities in relation to the sensitivity of the information communicated. Such an SOP could or should include policy on the use of headsets containing short range microphones and earphones in lieu of long range microphones and speakers in an open office environment. It could or should address the volume settings of speakers such that the session information is not heard by non-participants in a work area. It could or should also address the potential for the pickup of non-session related conversations in the work area. Provide appropriate training such that users follow the SOP. Enforce user compliance with the SOP.

b

Deficient Policy or SOP regarding PC communications video display positioning.

Medium - V-16077 - SV-17064r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP/VTC 1910 (GENERAL)

Vuln IDs

V-16077

Rule IDs

SV-17064r1_rule

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 ManagerPEDI-1

Checks: C-17120r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure a policy and procedure is in place and enforced that addresses the positioning of video displays associated with communications devices and PC based voice, video, UC, and collaboration communications applications with regard to the sensitivity of the information displayed and the ability of individuals, not part of the communications session, to view the display. Operational policy and procedures must be included in user training and guides. If video displays associated with communications devices and PC based voice, video, UC, and collaboration communications applications are used to display sensitive or classified information, interview the IAO and inspect the applicable SOP. The SOP should address the positioning of video displays associated with communications devices and PC based voice, video, UC, and collaboration communications applications with regard to the sensitivity of the information displayed and the ability of individuals, not part of the communications session, to view the display. Inspect a random sampling of workspaces and conference rooms to determine compliance. Look for displays that are viewable through a window or are viewable from common walkways or areas where non-participants can view the information. The lack of partitions or the use of short partitions separating workspaces can be an issue depending upon the sensitivity of the displayed information. Inspect user training materials and discuss practices to determine if information regarding the SOP is conveyed. Interview a random sampling of users to confirm their awareness of the SOP and related information. This is a finding if video displays associated with communications devices and PC based voice, video, UC, and collaboration communications applications that are used to display sensitive or classified information are easily viewable from locations outside the immediate user’s work area. This is also a finding if the SOP or training is deficient. NOTE: During a SRR, the review of this check may be coordinated with a traditional security reviewer if one is available so that duplication of effort is minimized. However, the similar/related traditional security check primarily addresses displays that are attached to classified systems which are displaying classified information, and not sensitive but unclassified information or privacy information.

Fix: F-16182r1_fix

Ensure a policy and procedure is in place and enforced that addresses the positioning of video displays associated with communications devices and PC based voice, video, UC, and collaboration communications applications with regard to the sensitivity of the information displayed and the ability of individuals, not part of the communications session, to view the display. Operational policy and procedures must be included in user training and guides. Produce an SOP that addresses the positioning of video displays associated with communications devices and PC based voice, video, UC, and collaboration communications applications with regard to the sensitivity of the information displayed and the ability of individuals, not part of the communications session, to view the display. Provide appropriate training such that users follow the SOP. Enforce user compliance with the SOP.

b

Deficient SOP or enforcement regarding presentation and application sharing via a PC or VTC.

Medium - V-16078 - SV-17065r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP/VTC 1915 (GENERAL)

Vuln IDs

V-16078

Rule IDs

SV-17065r1_rule

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 ManagerOtherDCBP-1, ECSC-1

Checks: C-17121r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure a policy and procedure is in place and enforced that addresses the proper implementation and use of the “Presentation and Sharing” features of collaboration applications and devices. This policy and SOP will be based on the specific application’s or device’s capabilities and will address mitigations for the possible inadvertent disclosure of information to conferees that have no need to see or have access to such information. Operational policy and procedures must be included in user training and guides. Interview the IAO and inspect the applicable SOP. The SOP should address the proper implementation and use of the “Presentation and Sharing” features of collaboration applications and devices. This policy and SOP will be based on the specific application’s or device’s capabilities and will address mitigations for the possible inadvertent disclosure of information to conferees that have no need to see or have access to. Inspect user training materials and discuss practices to determine if information regarding the SOP is conveyed. Interview a random sampling of users to confirm their awareness of the SOP and related information. This is a finding if the if the SOP or training is deficient.

Fix: F-16183r1_fix

Ensure a policy and procedure is in place and enforced that addresses the proper implementation and use of the “Presentation and Sharing” features of collaboration applications and devices. This policy and SOP will be based on the specific application’s or device’s capabilities and will address mitigations for the possible inadvertent disclosure of information to conferees that have no need to see or have access to such information. Operational policy and procedures must be included in user training and guides. Produce an SOP that addresses the proper implementation and use of the “Presentation and Sharing” features of collaboration applications and devices. This policy and SOP will be based on the specific application’s or device’s capabilities and will address mitigations for the possible inadvertent disclosure of information to conferees that have no need to see or have access to. Operational policy and procedures must be included in user training and guides. Provide appropriate training such that users follow the SOP. Enforce user compliance with the SOP

b

Deficient training for the secure operation of PC desktop, presentation, or application sharing capabilities of a collaboration tool.

Medium - V-16081 - SV-17069r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1310 (GENERAL)

Vuln IDs

V-16081

Rule IDs

SV-17069r1_rule

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 ManagerDCBP-1, ECSC-1

Checks: C-17124r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure users of PC based collaboration applications are trained to only share control of their PC or applications with other users that they are familiar with and/or can identify as trustworthy. Determine if training is provided such that users of PC based collaboration applications only share control of their PC or applications with other users with whom they are familiar with and/or can identify as trustworthy. Inspect training materials for related content. Interview a random sampling of users to determine if they are properly trained on this topic. This is a finding if the training or training materials are deficient.

Fix: F-16186r1_fix

Ensure users of PC based collaboration applications are trained to only share control of their PC or applications with other users that they are familiar with and/or can identify as trustworthy. Produce training materials and provide training such that users of PC based collaboration applications only share control of their PC or applications with other users with whom they are familiar with and/or can identify as trustworthy.

b

Audio pickup or video capture capabilities (microphones and cameras) are not disabled when not needed for active participation in a communications session.

Medium - V-16082 - SV-17070r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1735 (GENERAL)

Vuln IDs

V-16082

Rule IDs

SV-17070r1_rule

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

Checks: C-17125r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure audio and video pickup/capture capabilities of microphones and cameras associated with a PC are disabled or inhibited when not required for communications such that inadvertent disclosure of aural or visual information is prevented. Ensure that operational policy and procedures are included in user training and guides. Determine if the applicable training on the required operational procedures is provided. Inspect training materials. Interview a random sampling of users to determine if they are properly trained on this topic and actually perform the mitigating actions. Inspect a random sample of PCs that are not actively communicating to determine if the required mitigations are in place. NOTE: This requirement minimally involves muting the PC microphone and camera. If necessary, the camera lens must be covered, or the camera aimed at a blank wall to “mute” it. Ideally, the microphone and camera would be external devices and not embedded in the PC or an external monitor that could be disconnected from the PC when not needed. The external microphone and camera could remain connected to the PC if there was a positive physical disconnect or mute (shorting) switch for the microphone, and if the camera is disconnected by the switch or the camera lens is covered. This is a finding if any of the inspected items are deficient such that audio and video pickup/capture capabilities of microphones and cameras associated with a PC are not disabled or inhibited when not required for communications such that inadvertent disclosure of aural or visual information is prevented.

Fix: F-16187r1_fix

Ensure audio and video pickup/capture capabilities of microphones and cameras associated with a PC are disabled or inhibited when not required for communications such that inadvertent disclosure of aural or visual information is prevented. Ensure that operational policy and procedures are included in user training and guides. Produce training materials and provide training such that users of PC based collaboration applications disable their microphones and cameras when not participating in a collaboration session. This minimally involves muting the PC microphone and camera. If necessary, the camera lens must be covered, or the camera aimed at a blank wall to “mute” it. Ideally, the microphone and camera would be external devices and not embedded in the PC or an external monitor that could be disconnected from the PC when not needed. The external microphone and camera could remain connected to the PC if there was a positive physical disconnect or mute (shorting) switch for the microphone, and if the camera is disconnected by the switch or the camera lens is covered.

a

Deficient testing of, or lack of approval for, soft-phone accessories.

Low - V-16085 - SV-17073r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1745 (GENERAL)

Vuln IDs

V-16085

Rule IDs

SV-17073r1_rule

While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in this section. Our discussion here relates to, soft-phone 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 soft-phone 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 soft-phone 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 soft-phone 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 soft-phone application and supporting VoIP 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. PPGs can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones 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 soft-phone 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. NONESoft-phone accessories that provide a bridging capability of the VoIP and the PSTN can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. These can be legal issues for DoD. Information Assurance OfficerInformation Assurance ManagerDCBP-1, DCCT-1, DCHW-1, EBCR-1, ECSC-1

Checks: C-17128r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) capabilities are reviewed and their functionality tested or validated prior to approval, providing them to users, or implementing them. Ask IAO or IAM if the use of USB phones, USB ATAs, and PPGs is permitted and if they are provided to users. If so, determine if the devices have been reviewed and tested as necessary with regard to their network bridging capabilities. This is a finding if these devices are provided to users and they have not been properly reviewed and/or tested.

Fix: F-16190r1_fix

Ensure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) capabilities are reviewed and their functionality tested or validated prior to approval, providing them to users, or implementing them. Review and/or test of USB phones, USB ATAs, and PPGs for their network bridging capabilities. Do not use such devices if the capability exists except to fulfill a validated mission requirement.

a

Deficient user training regarding the use of personally provided soft-phone accessories.

Low - V-16086 - SV-17074r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1315 (GENERAL)

Vuln IDs

V-16086

Rule IDs

SV-17074r1_rule

While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone 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, soft-phone 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 soft-phone 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 soft-phone 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 soft-phone 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 soft-phone application and supporting VoIP 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 soft-phone 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. NONESoft-phone accessories that provide a bridging capability of the VoIP and the PSTN can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. These can be legal issues for DoD. Personally provided devices are uncontrolled with respect to bridging capabilities. Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1, PRTN-1

Checks: C-17129r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure personnel are trained not to employ personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones). This policy is to be acknowledged in user agreements and included in user training and user guides. Determine if training is provided to users about not employing personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones). Inspect user agreements for acknowledgement of this training. Interview a random sampling of users regarding their awareness of this subject. This is a finding if the training, training materials, or user awareness of the policy are deficient or if the policy is not addressed and acknowledged in signed user agreements.

Fix: F-16191r1_fix

Ensure personnel are trained not to employ personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones). This policy is to be acknowledged in user agreements and included in user training and user guides. Provide the appropriate user training such that they do not employ personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones); and require they sign user agreements that acknowledge the training and policy.

b

Voice networks are improperly bridged via a soft-phone accessory.

Medium - V-16087 - SV-17075r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1750 (GENERAL)

Vuln IDs

V-16087

Rule IDs

SV-17075r1_rule

While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in this section. Our discussion here relates to, soft-phone 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 soft-phone 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 soft-phone 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 soft-phone 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 soft-phone application and supporting VoIP 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 soft-phone 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. NONESoft-phone accessories that provide a bridging capability of the VoIP and the PSTN can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. These can be legal issues for DoD.Information Assurance OfficerInformation Assurance ManagerDCBP-1, DCCT-1, DCHW-1, EBCR-1, ECSC-1

Checks: C-17130r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability are not used on a DoD PC or network except to fulfill a validated and approved mission requirement. Determine if soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability to the PSTN are used on a DoD PC or network. If so, further determine if there is a validated and approved mission requirement for their use. Interview a random sampling of users regarding their use of this bridging capability. This is a finding if these devices are used and there is no validated mission requirement.

Fix: F-16192r1_fix

Ensure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability are not used on a DoD PC or network except to fulfill a validated and approved mission requirement. Discontinue the use of soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability unless there is a validated and approved mission requirement for their use.

b

Deficient user training regarding soft-phone accessory network bridging capabilities.

Medium - V-16088 - SV-17076r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1320 (GENERAL)

Vuln IDs

V-16088

Rule IDs

SV-17076r1_rule

While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone 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, soft-phone 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 soft-phone 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 soft-phone 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 soft-phone 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 soft-phone application and supporting VoIP 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 soft-phone 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. NONEThe improper bridging of a DoD VoIP network to the PSTN or other telephone network resulting in toll fraud, toll avoidance, or placing or receiving unauthorized calls. These can be legal issues for DoD.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1, PRTN-1

Checks: C-17131r1_chk

Interview the IAO to validate compliance with the following requirement: In the event a soft-phone accessory providing a network bridging capability is approved for use to fulfill a validated and approved mission requirement, the IAO will ensure personnel are properly trained in their implementation and proper use. This training is to be acknowledged in user agreements and included in user guides. Determine if soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability to a different network (e.g., the PSTN or DSN) are used on a DoD PC or network. If so, further determine if there is a validated and approved mission requirement for their use. Inspect training materials on this subject. Interview a random sampling of users regarding their knowledge of the proper usage of this bridging capability. Inspect user agreements for acknowledgement of this training. This is a finding if the training, training materials, or user awareness of the proper use policy are deficient or if the policy is not addressed and acknowledged in signed user agreements.

Fix: F-16193r1_fix

In the event a soft-phone accessory providing a network bridging capability is approved for use to fulfill a validated and approved mission requirement, the IAO will ensure personnel are properly trained in their implementation and proper use. This training is to be acknowledged in user agreements and included in user guides. Provide the appropriate user training and training materials such that users operate their soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging in an approved manner and require they sign user agreements that acknowledge the training and policy.

b

Deficient training or training materials addressing secure PC communications client application usage.

Medium - V-16089 - SV-17077r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1305 (GENERAL)

Vuln IDs

V-16089

Rule IDs

SV-17077r1_rule

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 ManagerDCBP-1, ECSC-1, PRTN-1

Checks: C-17132r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure training materials are developed and PC based voice, video, UC, and collaboration communications application users are trained in, and aware of, various aspects of the application’s safe and proper use as well as the application or service vulnerabilities. Training will include all items contained in user agreements and user guides. Ask the IAO about the training provided to users about the various aspects of the application’s safe and proper use as well as the application or service vulnerabilities. Inspect training materials for the content contained in user agreements. This is a finding if the training materials do not address the contents of the user agreements and the various aspects of the application’s safe and proper use as well as the application or service vulnerabilities.

Fix: F-16194r1_fix

Ensure training materials are developed and PC based voice, video, UC, and collaboration communications application users are trained in, and aware of, various aspects of the application’s safe and proper use as well as the application or service vulnerabilities. Training will include all items contained in user agreements and user guides. Develop training materials that address the contents of the user agreements and the various aspects of the application’s safe and proper use as well as the application or service vulnerabilities

b

An acceptable use policy or user agreement must be enforced for UC soft client users.

Medium - V-16090 - SV-17078r2_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1335

Vuln IDs

V-16090

Rule IDs

SV-17078r2_rule

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 ManagerECWM-1, PRRB-1

Checks: C-17133r2_chk

Interview the ISSO to validate compliance with the following requirement: Verify a user agreement is developed and enforced with users in accordance with DoD policies addressing the acceptable use of UC soft client applications and associated accessories minimally providing the following information: - Users must not install any application or agent, to include UC soft clients, VTC software, or IM client that connects to or uses a public VoIP or IM service for non-official business. - Users must not install any application or agent, to include UC soft clients, VTC software, or IM client that communicates peer-to-peer with other applications, agents, or personal phone gateways. - Users must not use a USB or Ethernet subscriber line interface card (SLIC) associated with a commercial VoIP service (such as magicJack) or a personal VoIP system in the DoD unless the SLIC is sanctioned and provided by a DoD component or organization. - Users must not use UC soft client accessories capable of bridging a DoD network or DoD application with another computer, phone network, or the PSTN. - Users must not use DoD-provided UC soft client while working in their normal DoD workspace without permission of the ISSO. - Users must receive a caution notice discussing the non-assured nature of UC soft client applications for C2 user awareness. - Users must receive instruction for the proper and safe use of webcams or built-in cameras when used in a classified environment to prevent viewing classified work or classified material over non-secure networks. - Users must receive instruction for the proper and safe use of speakerphones or built-in microphones when used in a classified environment to prevent hearing classified discussions over non-secure networks. - Users must receive instruction regarding the proper and safe use of presentation, document, and desktop sharing. Sites may modify the above items in accordance with local site policy. However, each item must be addressed in the user agreement. A user agreement may be a standalone document or a larger document addressing remote access or workstation use that enforces the acceptable use of UC soft client applications and accessories. Discuss the existence and enforcement of the UC soft client acceptable use policy. Inspect signed user agreements for compliance. If no acceptable use policy or related user agreement exists, this is a finding. If the acceptable use policy or related user agreement is deficient in content, this is a finding.

Fix: F-16195r2_fix

Develop and enforce a user agreement in accordance with DoD policies addressing the acceptable use of UC soft client applications and associated accessories minimally providing the following information: - Users must not install any application or agent, to include UC soft clients, VTC software, or IM client that connects to or uses a public VoIP or IM service for non-official business. - Users must not install any application or agent, to include UC soft clients, VTC software, or IM client that communicates peer-to-peer with other applications, agents, or personal phone gateways. - Users must not use a USB or Ethernet subscriber line interface card (SLIC) associated with a commercial VoIP service (such as magicJack) or a personal VoIP system in the DoD unless the SLIC is sanctioned and provided by a DoD component or organization. - Users must not use UC soft client accessories capable of bridging a DoD network or DoD application with another computer, phone network, or the PSTN. - Users must not use DoD-provided UC soft client while working in their normal DoD workspace without permission of the ISSO. - Users must receive a caution notice discussing the non-assured nature of UC soft client applications for C2 user awareness. - Users must receive instruction for the proper and safe use of webcams or built-in cameras when used in a classified environment to prevent viewing classified work or classified material over non-secure networks. - Users must receive instruction for the proper and safe use of speakerphones or built-in microphones when used in a classified environment to prevent hearing classified discussions over non-secure networks. - Users must receive instruction regarding the proper and safe use of presentation, document, and desktop sharing. Sites may modify the above items in accordance with local site policy. However, each item must be addressed in the user agreement. A user agreement may be a standalone document or a larger document addressing remote access or workstation use that enforces the acceptable use of UC soft client applications and accessories.

a

A user guide identifying the proper use of UC soft client applications must be provided to UC soft client users.

Low - V-16091 - SV-17079r2_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1330

Vuln IDs

V-16091

Rule IDs

SV-17079r2_rule

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 training and guides should also provide additional information such as how to operate the UC soft client and implement cybersecurity features as required. Other topics that should be contained in a user guide include the use of webcams and microphones with both UC soft clients and hardware end instruments when used in a classified environment or where classified discussions occur. The user guide must contain a discussion pertaining to the use of UC soft client applications for assured service C2 communications. Cautions regarding the potentially unreliable nature of these communications applications or methods must be included in user guides so that C2 users are aware of, and reminded of, the non-assured service nature of these communications methods. Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1, ECWM-1, PRTN-1

Checks: C-17134r2_chk

Interview the ISSO to validate compliance with the following requirement: Verify a user guide is developed and distributed to users of UC soft client applications minimally providing the following information: - Review the policies and restrictions agreed to when the user agreement was signed upon receiving the communications application. - Provide a caution notice discussing the non-assured nature of UC soft client applications for C2 user awareness. - Provide instruction for the proper and safe use of webcams or built-in cameras when used in a classified environment to prevent viewing classified work or classified material over non-secure networks. - Provide instruction for the proper and safe use of speakerphones or built-in microphones when used in a classified environment to prevent hearing classified discussions over non-secure networks. - Provide instruction regarding the proper and safe use of presentation, document, and desktop sharing. Inspect the user guide for the proper use of UC soft client and validate users received this guide by interviewing a random sampling of users. If the user guide is deficient in content or the guide is not provided to users, this is a finding.

Fix: F-16196r2_fix

Develop and distribute a user guide to users of UC soft client applications minimally providing the following information: - Review the policies and restrictions agreed to when the user agreement was signed upon receiving the communications application. - Provide a caution notice discussing the non-assured nature of UC soft client applications for C2 user awareness. - Provide instruction for the proper and safe use of webcams or built-in cameras when used in a classified environment to prevent viewing classified work or classified material over non-secure networks. - Provide instruction for the proper and safe use of speakerphones or built-in microphones when used in a classified environment to prevent hearing classified discussions over non-secure networks. - Provide instruction regarding the proper and safe use of presentation, document, and desktop sharing.

b

Deficient support for COOP or emergency and life safety communications when soft-phones are implemented as the primary voice endpoint in user’s workspace caused by deficient placement of physical hardware based phones near all such workspaces.

Medium - V-16094 - SV-17082r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1920 (GENERAL)

Vuln IDs

V-16094

Rule IDs

SV-17082r1_rule

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 ManagerDCBP-1, ECSC-1

Checks: C-17138r1_chk

Interview the IAO to validate compliance with the following requirement: In the event PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in the user’s workspace, the IAO will ensure hardware based telephone instruments, are installed within a short distance (e.g., 30 to 50 feet) of every workspace to be used for backup and emergency communications. Determine if PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in user’s workspaces. If so, inspect users work areas to determine if hardware based telephone instruments, are installed within a short distance (e.g., 30 to 50 feet) of every workspace to be used for backup and emergency communications. Cell phones, PDA/PEDs, or other wireless devices are not considered reliable enough to meet this requirement due to lack of reliable signal available everywhere and their inability to be used in certain DoD environments. This is a finding if these conditions are not met. NOTE: This requirement is satisfied by the implementation of hardwired hardware based telephone instruments using any telephony technology. That is, traditional analog, or digital instruments may be used or VoIP based instruments may be used. Such instruments may be part of the local site’s PBX or VoIP system, or may be served from the Local Exchange Carrier (LEC) or Competitive LEC (CLEC). Of additional concern when implementing backup/COOP or emergency telephones is power. Such phones should be remotely powered from a source that can provide backup power. Additionally, the dialing capabilities of backup/COOP or emergency may be limited to internal and/or emergency calls. This means that minimally, emergency services numbers must be reachable from these phones. PART2 manual Minimally select a random sample if not all of the implemented hard-phones and test them to ensure they are functional. This is a finding if non functional phones are found.

Fix: F-16199r1_fix

In the event PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in the user’s workspace, the IAO will ensure hardware based telephone instruments, are installed within a short distance (e.g., 30 to 50 feet) of every workspace to be used for backup and emergency communications. NOTE: This requirement is satisfied by the implementation of hardwired hardware based telephone instruments using any telephony technology. That is, traditional analog, or digital instruments may be used or VoIP based instruments may be used. Such instruments may be part of the local site’s PBX or VoIP system, or may be served from the Local Exchange Carrier (LEC) or Competitive LEC (CLEC). Of additional concern when implementing backup/COOP or emergency telephones is power. Such phones should be remotely powered from a source that can provide backup power. Additionally, the dialing capabilities of backup/COOP or emergency may be limited to internal and/or emergency calls. This means that minimally, emergency services numbers must be reachable from these phones.

b

No command or DAA approval exists for implementing soft-phones as the primary voice endpoint.

Medium - V-16095 - SV-17083r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1110 (GENERAL)

Vuln IDs

V-16095

Rule IDs

SV-17083r1_rule

The Designated Approving Authority (DAA) responsible for the implementation of a telephone system which primarily uses PC software applications for its endpoints must be made aware of the risks of operating such as system as well as the benefits. This is because the DAA must personally accept the risk of operating the system. In addition, the commander of an organization whose mission depends upon such a telephone system must also be made aware and provide their approval.NONEThe inability to make a call when the PC soft-phone/UC application is unavailable, particularly in an emergency situation.Information Assurance OfficerDesignated Approving AuthorityInformation Assurance ManagerDCBP-1, ECSC-1

Checks: C-17139r1_chk

In the event PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in the user’s workspace. That is, there is no PC independent telephone. Interview the IAO to validate compliance with the following requirement: Ensure the command structure as well as the DAA approves the implementation or transition in writing. Approval documentation will be maintained by the IAO for inspection by IA reviewers or auditors. Review written DAA and Command approval for the implementation of a telephone system which primarily uses PC software applications for its endpoints. This is a finding if such approvals are not provided.

Fix: F-16200r1_fix

Ensure the command structure as well as the DAA approves the implementation or transition in writing. Approval documentation will be maintained by the IAO for inspection by IA reviewers or auditors. Obtain the required written DAA and Command approval for the implementation of a telephone system which primarily uses PC software applications for its endpoints or install a hardware based wired telephone system.

b

No DAA approval for permitting limited numbers of soft-phones to operate in LAN.

Medium - V-16096 - SV-17084r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1720 (GENERAL)

Vuln IDs

V-16096

Rule IDs

SV-17084r1_rule

This use case addresses situations whereby the soft-phone/UC application and PC is not the primary voice communications “device” in the work area. This means that there is a validated mission need and the number of PC soft-phones 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 soft-phones required to meet specific mission requirements. UC applications that are ubiquitous in the LAN are addressed later, however, typically these work in association with a hardware based phone system, not in place of it. There are three possible scenarios for the use of limited numbers of soft-phones in the strategic LAN. We will discuss the first two in this section and the third in the next section. The first of these scenarios is providing support for soft-phones associated with a VoIP system in another enclave. This is a remote access scenario and must operate as they would in a normal telework/remote access use case. We will discuss this use case later, however, 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. NOTE: Approval for this scenario would also require approval for specific foreign (non-local) PC attachment to the local LAN. These topics are beyond the scope of this document. The second of these scenarios is providing support for soft-phones associated with a local VoIP system. It is preferred that PC soft-phones associated with the local VoIP system not be used in the LAN, at all, due to the difficulties they present to the protection of the local hardware based VoIP infrastructure. Under normal circumstances, due to the separation of the VoIP and data VLANs a PC soft-phone application (associated with the local VoIP system) should not be able to register with the VoIP controller and function when the PC is connected to the LAN. This is because the PC connects to a LAN access port assigned to the data VLAN(s) and traffic between the voice and data VLANs is blocked. Similarly, if the PC was to be connected to a LAN access port assigned to the VoIP VLAN(s), the soft-phone might work but the PC would not have its normal data connectivity or services. If PC soft-phones are to be used in the strategic LAN, except as noted in the section on discrete instrument replacement, their numbers should be limited to those that are essential to the mission and additional protections, as discussed later in this section, must be added to the LAN to maintain the protection of the VoIP infrastructure. Implementations of limited numbers of PC soft-phones along with the protections afforded them and the local VoIP infrastructure must be approved by the responsible DAA. NONEIncreased potential for the compromise of the VoIP controllers, gateways, hardware based instruments, and other VoIP infrastructure. Possible degradation of service on the hardware based phone system.Information Assurance OfficerDesignated Approving AuthorityInformation Assurance ManagerDCBP-1, ECSC-1

Checks: C-17140r1_chk

In the event that limited numbers of PC soft-phones are implemented in the strategic LAN, Interview the IAO to validate compliance with the following requirement: Ensure the responsible DAA approves the use of PC soft-phones in the strategic LAN along with the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure. Approval will be provided in writing and will be maintained by the IAO for inspection by IA reviewers or auditors. If limited numbers of PC soft-phones associated with the local VoIP system are to be implemented in the strategic LAN, a separate protection zone or VLAN structure must be implemented for them. The purpose of this VLAN is to provide a means whereby the PC can access the services it requires in both the data and VoIP VLANs while protecting the VoIP infrastructure and enhancing soft-phone reliability, performance, and security. Implementation of such a VLAN must not provide an access path as in a bridge, between the VoIP and data VLANs. Traffic must be filtered such that the soft-phone’s VoIP traffic is routed to the VoIP VLAN while all other traffic is routed to the data VLAN. This should happen at only one location such as a core router or firewall, however, the PC might be capable of this itself. NOTE: Limited numbers in this scenario means as few as possible, but may mean 25 or 30 percent of the overall PCs on the LAN. Beyond this percentage, the protections afforded by this implementation become limited or negated because of the large number of PCs in the soft-phone VLAN. 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 next in this document. Determine if limited numbers of PC soft-phones are permitted to operate or are implemented in the strategic LAN. If so, review the written DAA approval for the implementation/permission. This is a finding in the event limited numbers of PC soft-phones are to be implemented in the strategic LAN and there is no written DAA approval for the implementation and the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure.

Fix: F-16201r1_fix

Ensure the responsible DAA approves the use of PC soft-phones in the strategic LAN along with the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure. Approval will be provided in writing and will be maintained by the IAO for inspection by IA reviewers or auditors. In the event that limited numbers of PC soft-phones are to be implemented in the strategic LAN, obtain written approval from the responsible DAA along with approval for the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure. Alternately remove the PC soft-phones and/or UC applications from the LAN.

b

Deficient protection for a Call Center (or CTI) system that uses soft-phones.

Medium - V-16098 - SV-17086r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1025 (GENERAL)

Vuln IDs

V-16098

Rule IDs

SV-17086r1_rule

The third scenario in which limited numbers of PC soft-phones might be used in a strategic LAN is when they are associated with or are actually part of a Computer Telephony Integration (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 general business LAN and that this can be accomplished by maintaining a closed network or a segregated and access controlled sub-enclave having appropriate boundary protection. This is in support of DoDI 8500.2 IA control DCSP-1 regarding “Security Design and Configuration / Security Support Structure Partitioning” which states “The security support structure maintains separate execution domains as in address spaces, for each executing process by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions.” NONEThe compromise of the Call Center / CTI system resulting in denial of service or loss/compromise of sensitive informationInformation Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1

Checks: C-17142r1_chk

Interview the IAO to validate compliance with the following requirement: In the event a Call Center / CTI system/application (e.g., call center, helpdesk, operators console, E911 system, etc.) utilizing or incorporating PC based soft-phones are approved for use in the strategic LAN, ensure the following: - The supporting network is configured as a closed environment (enclave) or a segregated and access controlled sub-enclave having appropriate boundary protection between it and the local general business LAN or external WAN. - In the event the CTI application accesses resources outside this enclave and there is the potential of the application being compromised from external sources, the supporting network is configured to provide separate voice and data zones and maintains separation of voice and data traffic per the VoIP STIG if technically feasible (i.e., such separation does not break the CTI application or there is another compelling reason). - The supporting network enclave and boundary protection is configured in substantial compliance with the Enclave, Network Infrastructure, and VoIP STIGs. - The CTI application/enclave (e.g., a call center application) is supported by a dedicated VoIP controller. Inspect network drawings and perform a scan from outside the CTI system enclave to determine what traffic is permitted to flow between the CTI system and external network or VLANs. This is a finding in the event unnecessary traffic can pass.

Fix: F-16203r1_fix

In the event a Call Center / CTI system/application (e.g., call center, helpdesk, operators console, E911 system, etc.) utilizing or incorporating PC based soft-phones are approved for use in the strategic LAN, ensure the following: - The supporting network is configured as a closed environment (enclave) or a segregated and access controlled sub-enclave having appropriate boundary protection between it and the local general business LAN or external WAN. - In the event the CTI application accesses resources outside this enclave and there is the potential of the application being compromised from external sources, the supporting network is configured to provide separate voice and data zones and maintains separation of voice and data traffic per the VoIP STIG if technically feasible (i.e., such separation does not break the CTI application or there is another compelling reason). - The supporting network enclave and boundary protection is configured in substantial compliance with the Enclave, Network Infrastructure, and VoIP STIGs. - The CTI application/enclave (e.g., a call center application) is supported by a dedicated VoIP controller. Implement the proper Call Center / CTI system protection mechanisms segregating it into its own protected enclave and limit traffic into and out of this enclave.

b

The architecture and/or configuration of a permanent, semi-permanent, or fixed (not highly mobile) tactical LAN supporting IP based voice, video, unified, and/or collaboration communications is not adequate to protect the VVoIP services and infrastructure.

Medium - V-16099 - SV-17087r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1925 (GENERAL)

Vuln IDs

V-16099

Rule IDs

SV-17087r1_rule

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 ManagerDCBP-1, ECSC-1

Checks: C-17143r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure permanent, semi-permanent, or fixed (not highly mobile) tactical networks supporting IP based voice, video, unified, and/or collaboration communications are configured per the requirements for a strategic LAN supporting voice/video/UC services. Determine if the tactical LAN is supporting a fixed or generally non-moving base making it a fixed tactical LAN. If the fixed tactical network supports IP based voice, video, UC, and/or collaboration communications, determine if it is configured per the requirements for a strategic LAN. Inspect network diagrams and interview the IAO to determine compliance. This is a finding in the event the deployed tactical network is relatively permanent compared to a small highly mobile unit and the LAN is not configured as a strategic LAN for the support of supports IP based voice, video, UC, and/or collaboration communications as defined in this and other STIGs. NOTE: The factors determining whether a deployed tactical VVoIP system is subject to this requirement are varied. In general all VVoIP systems should be configured the same and such that the service and supporting infrastructure is protected. It is recognized that a small system operated out of a transit case in a tent, conex box, or a truck is highly mobile as opposed to a fixed installation in a building. While initially such a system can support a few users and remain highly mobile, as the number of users increases, the deployment becomes semi-permanent, or fixed (not highly mobile). 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. Small 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. 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.

Fix: F-16204r1_fix

Ensure permanent, semi-permanent, or fixed (not highly mobile) tactical networks supporting IP based voice, video, unified, and/or collaboration communications are configured per the requirements for a strategic LAN. Configure the fixed tactical LAN in accordance with the requirements for a strategic LAN that supports IP based voice, video, UC, and/or collaboration communications.

b

Deficient benefit vs. risk analysis and/or 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.

Medium - V-16101 - SV-17089r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1930 (GENERAL)

Vuln IDs

V-16101

Rule IDs

SV-17089r1_rule

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 ManagerDCBP-1, ECSC-1

Checks: C-17144r1_chk

Interview the IAO to validate compliance with the following requirement: In the event voice/video/UC IA configuration measures are reduced for highly mobile tactical networks (e.g., initial deployment packages) supporting hardware or PC based voice, video, unified, and/or collaboration communications, the IAO will ensure a benefit vs. risk analysis is performed, documented, and approved in the certification and accreditation of the system. NOTE: It is recognized that deployable packages for highly mobile tactical networks may only support PC based voice, video, UC, and/or collaboration communications applications. Such a network may not require separate zones for voice and data since all traffic will be in the data zone. Determine if IA configuration measures are reduced for highly mobile tactical networks (e.g., initial deployment packages) supporting hardware or PC based voice, video, UC, and/or collaboration communications. If so, inspect network diagrams and device configurations to determine the IA measures implemented. If the implemented IA measures are reduced from those required in a strategic or fixed tactical LAN, inspect the documented benefit vs. risk analysis used in the C&A process for the system. This is a finding if there is no benefit vs. risk analysis, or it is found to be deficient in some manner, such that the appropriate risk level was not used in the C&A of the system.

Fix: F-16205r1_fix

In the event voice/video/UC IA configuration measures are reduced for highly mobile tactical networks (e.g., initial deployment packages) supporting hardware or PC based voice, video, unified, and/or collaboration communications, perform and document a benefit vs. risk analysis for the reduced IA measures and update the C&A for the system.

b

PC communications application C&A documentation is not included in the C&A documentation for the supporting VVoIP system .

Medium - V-16106 - SV-17094r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1105 (GENERAL)

Vuln IDs

V-16106

Rule IDs

SV-17094r1_rule

Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. Since a PC VVoIP communications application 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 PC application 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/enclave. DoDI 8500.2 IA control DCCT-1 under “Security Design and Configuration / Compliance Testing” states “A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.” This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. NONEDe-certification of the supporting communications system or service.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1

Checks: C-17150r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC communications applications are certified and accredited in association with, or as part of, their supporting communications system or service. Inspect the C&A documentation of the communications system or service supporting a PC communications application. Look for the inclusion and IA of the PC communications application. If not included, this is a finding.

Fix: F-16211r1_fix

Ensure PC communications applications are certified and accredited in association with, or as part of, their supporting communications system or service. Include PC communications applications in the C&A of the supporting communications system or service. If PC communications applications are added after the supporting system is accredited, modify the system C&A documentation and update the “approvals to operate” (ATO) to include the added PC communications applications.

b

Deficient PC communications application testing prior to implementation.

Medium - V-16107 - SV-17095r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1125 (GENERAL)

Vuln IDs

V-16107

Rule IDs

SV-17095r1_rule

Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. DoDI 8500.2 IA control DCCT-1 under “Security Design and Configuration / Compliance Testing” states “A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.” This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. NONEDe-certification of the supporting communications system or service.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1

Checks: C-17151r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC communications applications are tested and approved prior to implementation. Determine if implemented PC communications applications were tested and approved prior to implementation. Review documentation relating to the testing and approval of the PC communications application(s) that are implemented. This is a finding if it is determined that PC communications applications were NOT tested and approved prior to implementation.

Fix: F-16212r1_fix

Ensure PC communications applications are tested and approved prior to implementation. Test PC communications applications for IA concerns and seek approval for their use prior to implementation. Document the testing and approval of PC communications application(s) before they are implemented. Maintain this documentation for auditors / inspectors.

b

Deficient testing or approval of PC communications application patches or upgrades.

Medium - V-16108 - SV-17096r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1130 (GENERAL)

Vuln IDs

V-16108

Rule IDs

SV-17096r1_rule

Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. DoDI 8500.2 IA control DCCT-1 under “Security Design and Configuration / Compliance Testing” states “A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.” This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. NONEDe-certification of the supporting communications system or service.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1

Checks: C-17221r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure upgrades and patches to communications systems supporting PC communications applications are tested and approved prior to implementation. Determine if upgrades and patches to communications systems supporting PC communications applications and PC communications applications are tested and approved prior to implementation. Review documentation relating to the testing of the patch or upgrade to the PC communications system and application(s) as verification. This is a finding if it is determined that upgrades and patches to systems supporting PC communications applications and/or the applications themselves were NOT tested and approved prior to implementation.

Fix: F-16214r1_fix

Ensure upgrades and patches to communications systems supporting PC communications applications are tested and approved prior to implementation. Test upgrades and patches to PC communications systems and applications for IA concerns and seek approval for their use prior to implementation. Document the testing and approval of the patch or upgrade to the PC communications system or application(s) before implementation. Maintain this documentation for auditors/inspectors.

b

A PC Communications Application is not tested for IA and Interoperability and are not listed on the DoD UC APL.

Medium - V-16109 - SV-17097r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1120 (GENERAL)

Vuln IDs

V-16109

Rule IDs

SV-17097r1_rule

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 ManagerDCBP-1, ECSC-1

Checks: C-17153r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC communications applications providing voice, data, or video communications interoperability with the DSN, DRSN/VoSIP, or PSTN, along with any associated accessories (e.g., USB phones, cameras, and USB ATAs), are interoperability and IA tested and placed on the Approved Products List (APL) prior to purchase, per DoDI 8100.3. NOTE : APL listing of soft-phone applications, and/or associated accessories, will be in association with, or part of, the listed VoIP telecommunications switch/system that supports the application. Other applications (VTC or collaboration) will be listed with their core service or system. NOTE: This is not a finding in the event a PC communications application implementation and/or supporting system is not associated with, interoperable with, or connected to DSN, DRSN/VoSIP, or PSTN and is never expected to be. NOTE: The DRSN is a custom and proprietary non-VoIP telephone system. It interoperates, to a degree, with a Defense Information System Network (DISN) VoIP telephone system/service on the Secret Internet Protocol Router Network (SIPRNet). This VoIP service is called VoSIP (see acronym discussion in the next note). The discussion/requirement here applies to PC communications application associated with VoSIP that ultimately can interoperate with DRSN endpoints. NOTE: NSA defines VoSIP as Voice over Secure IP or regular (un-encrypted or encrypted) VoIP over any secure or classified IP LAN (i.e., local C-LAN) or WAN (e.g., SIPRNet or JWICS). In general, VoSIP employs encryption at Layer 1/Layer 2 applied to links between un-encrypted classified enclaves. The use of the acronym VoSIP for the DISN service and for instantiations on DoD component’s classified LANs leads to confusion between the service and the intentional meaning of the acronym. NSA defines a similar acronym, SVoIP, meaning Secure VoIP. This refers to end-to-end NSA type-1 encrypted VoIP media and possibly signaling streams that can traverse a network having a lower classification. This is similar in concept to the secure voice service provided by a STU or STE as well as SCIP based devices. SCIP works at Layer 7 (application layer) and can use Type 1 or Type 3 encryption. It is not IP specific since it was developed for traditional fixed and mobile transport methods. Type 3 encryption of VoIP signaling and media is not SCIP. Unfortunately, the SVoIP acronym/term has also been corrupted by some organizations using it to refer to their implementation of VoIP on their classified LANs and the SIPRNet WAN. Inspect the APL testing report for the APL approved VoIP system supporting the PC communications application to determine if it was tested and approved along with the supporting communications system. NOTE: these applications are typically NOT listed separately on the APL. APL testing reports are available to DoD users of the product and reviewers via email from the Unified Capabilities Certification Office (UCCO) at ucco@disa.mil. It is highly recommended that requests for these reports are submitted and the report obtained before SRR trips commence. This is a finding if it is determined that the PC communications application was not tested and approved along with the supporting communications system.

Fix: F-16215r1_fix

Ensure PC communications applications providing voice, data, or video communications interoperability with the DSN, DRSN/VoSIP, or PSTN, along with any associated accessories (e.g., USB phones, cameras, and USB ATAs), are interoperability and IA tested and placed on the Approved Products List (APL) prior to purchase, per DoDI 8100.3. Only implement APL tested PC communications applications. If necessary contact the Unified Capabilities Certification Office (UCCO) to determine what course of action and testing submittals should be pursued.

b

Deficient PC Communications Application integrity or supportability.

Medium - V-16111 - SV-17099r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1705 (GENERAL)

Vuln IDs

V-16111

Rule IDs

SV-17099r1_rule

Another one of the measures in our defense in depth strategy to protect our PC based voice, video, UC, 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 of possible compromise of a communications application is the use of freeware or shareware applications. This issue is covered in DoDI 8500.2 IA control DCPD-1 regarding “Security Design and Configuration / Public Domain Software Controls” which states “Binary or machine executable public domain software products and other software products with limited or no warranty such as those commonly known as freeware or shareware are not used in DoD information systems unless they are necessary for mission accomplishment and there are no alternative IT solutions available. Such products are assessed for information assurance impacts, and approved for use by the DAA. The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the Government.” Communications applications that primarily provide voice communications such as a soft-phone need to be designed to properly interoperate directly with the hardware based voice (VoIP) communications system. These applications should be a standard product of the voice system vendor or a partner whose product is approved by this vendor. The voice system is the most critical of all of the communications systems discussed in this document. Communications applications that primarily provide VTC ‘like’ communications can come from several sources. Some soft-phone applications provide VTC and collaboration features and should be sourced from the voice system vendor as noted previously. Applications that primarily provide VTC features and need to 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. Communications applications that primarily 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. Unified communications applications that provide multiple services such as IM, presence, voice, VTC, web conferencing, and so forth, may also be a product of the PC’s operating system vendor as with Microsoft’s Office Communications applications. Application sourcing can also be dependant upon whether the application is to interoperate with a hardware based communications system located and operated within an enclave or whether it is a system operated by an interagency or inter-base program. This requirement is based on the fact that DoD components are required to use software and applications that are supported by a vendor that can maintain the security and integrity of the software or application. The vendor must be able to provide patches, upgrades or both to mitigate newly discovered vulnerabilities found in their product in a timely manner. NONECompromise of the supported communications or the supporting networkInformation Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1

Checks: C-17155r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and can provide support for the application to resolve operational and IA issues for DoD implementations. NOTE: The following are applicable sources: - Soft-phone and/or UC applications providing voice telephone services source from the enclave’s voice (VoIP) system vendor (or their approved partner). - Soft-VTC applications source from the enclave’s or program’s VTC system vendor (or their approved partner). - Collaboration applications source from the enclave’s or program’s Collaboration system/service vendor (or their approved partner). - The PC’s operating system vendor (e.g., Microsoft) providing the application is approved to interoperate with the primary systems above. - An AIS program that has sourced the application from an appropriate source and provided the necessary testing, certification, and accreditation. Determine the source of the PC voice, video, UC, and collaboration communications applications that are installed or are in use. Determine if freeware or shareware PC voice, video, UC, or collaboration communications applications are in use. Examples are applications from yahoo, MSN, Google, Skype and other third party applications downloadable from the internet via freeware and shareware distribution web sites. Inspect a random sample of PCs to determine what PC voice, video, UC, or collaboration communications applications are installed. This is a finding if the PC voice, video, UC, or collaboration communications applications are either freeware / shareware, or are not sourced from the original manufacturer of the supporting voice, video, UC, and collaboration system. The only PC voice, video, UC, or collaboration communications applications that should be used are those licensed products from major communications system vendors such as Cisco, Nortel, Avaya, Polycom, Tandberg, and so on, for which a clear support path is defined. This is to ensure PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and that support for the application can be provided to resolve operational and IA issues for DoD. NOTE: this is NOT a finding in the event the applications in question are shareware/freeware or are sourced from a third party other than a major communications system vendor AND they are necessary for mission accomplishment; there are no alternative IT solutions available; and the product has been assessed for information assurance impacts, and approved for use by the DAA in writing. If this is the case, inspect the DAA approval documentation to validate.

Fix: F-16217r1_fix

Ensure PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and can provide support for the application to resolve operational and IA issues for DoD implementations. Obtain PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and that can provide support for the application to resolve operational and IA issues for DoD implementations. NOTE: The following are applicable sources: - Soft-phone and/or UC applications providing voice telephone services source from the enclave’s voice (VoIP) system vendor (or their approved partner). - Soft-VTC applications source from the enclave’s or program’s VTC system vendor (or their approved partner). - Collaboration applications source from the enclave’s or program’s Collaboration system/service vendor (or their approved partner). - The PC’s operating system vendor (e.g., Microsoft) providing the application is approved to interoperate with the primary systems above. - An AIS program that has sourced the application from an appropriate source and provided the necessary testing, certification, and accreditation.

b

The integrity of a PC Communications Application, upgrade, or patch is not validated via digital signature before installation.

Medium - V-16112 - SV-17100r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1710 (GENERAL)

Vuln IDs

V-16112

Rule IDs

SV-17100r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-17156r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC voice, video, UC, or collaboration communications applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Determine if PC voice, video, UC, or collaboration communications applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Have the IAO or SA demonstrate the application and upgrade/patch integrity validation process. This is a finding if digital signatures are not validated before installation.

Fix: F-16218r1_fix

Ensure PC voice, video, UC, or collaboration communications applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Employ only those PC voice, video, UC, or collaboration communications applications, upgrades, and patches that are digitally signed by the vendor. Perform the appropriate digital signature validation process to validate application and upgrade/patch integrity before installation.

b

A PC communications application is not maintained at the current/latest approved patch or version/upgrade level.

Medium - V-16113 - SV-17101r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1700 (GENERAL)

Vuln IDs

V-16113

Rule IDs

SV-17101r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-17157r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC voice, video, UC, and/or collaboration communications applications are maintained at the current/latest approved patch or version/upgrade level. Determine if PC voice, video, UC, and/or collaboration communications applications are maintained at the current/latest approved patch or version/upgrade level. Consult with the vendor or their web site to determine if the version that is in use is the latest version that contains the latest IA mitigations. Determine if this version is the latest approved version.

Fix: F-16219r1_fix

Ensure PC voice, video, UC, and/or collaboration communications applications are maintained at the current/latest approved patch or version/upgrade level. Implement the current/latest approved patch or version/upgrade level to utilize the latest IA mitigations. If an outdated application version is no longer in use, un-install it. If the latest version is not approved, submit it for testing and approval to ensure the latest IA mitigations are available and used.

b

A PC communications application is operated with administrative or root level privileges.

Medium - V-16114 - SV-17102r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1715 (GENERAL)

Vuln IDs

V-16114

Rule IDs

SV-17102r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-17158r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC voice, video, UC, or collaboration communications applications do not require and/or are not configured to operate with administrative privileges. Determine if the installed PC voice, video, UC, or collaboration communications application(s) requires and/or is configured to operate with administrative privileges. Inspect a random sampling of PC voice, video, UC, or collaboration communications applications to determine if they are configured to operate with administrative privileges. This is a finding if a PC voice, video, UC, or collaboration communications application requires with administrative privileges to operate or if the application or platform is configured such that the application runs with administrative privileges. Even though a user has administrative privileges, the application should not inherit those privileges and should operate without them.

Fix: F-16220r1_fix

Ensure PC voice, video, UC, or collaboration communications applications do not require and/or are not configured to operate with administrative privileges. Configure the application and/or platform to not operate with administrative privileges or un-install it. Even though a user has administrative privileges, the application should not inherit those privileges and should operate without them.

b

The integrity of VVoIP endpoint configuration files downloaded by hardware or PC based VVoIP endpoints during endpoint registration are not validated using digital signatures.

Medium - V-16115 - SV-17103r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1935 (GENERAL)

Vuln IDs

V-16115

Rule IDs

SV-17103r1_rule

During VVoIP endpoint registration with the LSC, a file is downloaded by the endpoint from the LSC that contains specific configuration parameters needed by the endpoint to operate as needed to support its assigned user. This file contains the phone number assigned to the endpoint; the IP addresses (or URLs) of the LSC(s) with which the endpoint is associated; the software menus specific to the system; the password used to access the endpoint’s configuration; the user’s personal preferences and speed dial numbers; as well as other information critical to the operation of the endpoint. NOTE: Hardware based VVoIP endpoints are like diskless computers on the LAN which need to download an operating system and configurations before they can operate. The code necessary to download this OS is stored in ROM or Flash Memory and is called firmware. To varying degrees some, most, or all of the endpoint’s OS can be stored on the device as firmware. The more of the OS that is stored the device, the quicker it initializes. In any case, no matter how much of the OS is stored as firmware, each endpoint requires a customized configuration settings file to be downloaded that individualizes the endpoint to meet the needs of the user to which it is assigned. These configuration settings can be updated occasionally or regularly by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded. Many PC based communications applications are fully configured locally on the platform, however, in some cases they rely on a configuration file downloaded from the system with which they are associated. The integrity of these files is critical to preventing compromise of the PC application, hardware endpoint, and the system itself. The best method for maintaining the integrity of these files is to require that they digitally signed. This can prevent 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. NOTE: DoD PKI machine certificates are preferred for digital file signing, however, a vendor generated certificate would provide similar albeit not the same protection. LSCs and endpoints are to be assigned DoD machine certificates when the system operates as part of the DISN IPVS network. These certificates are also used for encryption purposes. VVoIP 1935/1936 DoD generated PKI certificates are the preferred certificates to be used in DoD operated systems. This includes machine certificates used as described in this requirement. While this is a CAT II finding if no certificate is used or no integrity validation is performed, this finding can be reduced to a CAT III in the event a vendor generated certificate is used. VVoIP Endpoint configuration files might be downloaded from an unauthorized server or the file might be corrupted or modified causing various unknown and indeterminate compromises. To mitigate issues regarding the integrity or confidentiality of the VVoIP endpoint configuration files or to provide a work around for a local policy preventing the use of the required file transfer protocols on the general business LAN, implement the following: > Disable automatic configuration file download on endpoint registration > Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated “Provisioning” LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN. System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1

Checks: C-17159r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC based or hardware based voice, video, UC, or collaboration communications endpoints or applications that require configurations to be downloaded from the system (LSC) with which they are associated, accepts only those configuration files that are digitally signed by the proper authority (e.g., using a DoD PKI certificate). Further ensure the digital signature and integrity of the file is validated before the endpoint uses the file. Ask the IAO and/or consult the vendor and/or the system documentation to determine if downloaded configuration files are digitally signed and that the digital signature is validated before the endpoint uses the file. This is a finding if either condition is not met. Additionally determine if the certificates used are DoD PKI machine certificates. This is a CAT III finding if DoD PKI certificates are not used but the integrity of the file is validated against a vendor generated certificate. This is not a finding in the event the following mitigations are employed: > Disable automatic configuration file download on endpoint registration > Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated “Provisioning” LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN. This will ensure the configuration file is sourced from the LSC eliminating the need for a file integrity check, and will limit its exposure eliminating the need to encrypt.

Fix: F-16221r1_fix

Ensure PC based or hardware based voice, video, UC, or collaboration communications endpoints or applications that require configurations to be downloaded from the system (LSC) with which they are associated, accepts only those configuration files that are digitally signed by the proper authority (e.g., using a DoD PKI certificate). Further ensure the digital signature and integrity of the file is validated before the endpoint uses the file. Configure PC based or hardware based endpoint configuration downloads to use digital signatures. Additionally configure the application to validate the digital signature and the integrity of the configuration file prior to using the file. Additionally configure the system to use DoD PKI certificates. OR Employ the following mitigations: > Disable automatic configuration file download on endpoint registration > Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated “Provisioning” LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN.

b

PC communications application server association is not properly limited.

Medium - V-16116 - SV-17104r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1805 (REMOTE)

Vuln IDs

V-16116

Rule IDs

SV-17104r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-17160r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC based voice, video, UC, or collaboration communications applications are configured such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups. Determine what the application’s permitted controllers, gateways, and/or servers including backups should be from the IAO. Review application configuration settings on a random sampling of PCs to determine if only the permitted controllers, gateways, and/or servers are configured. Further determine if users (not SAs) can reconfigure these settings. This is a finding if PC based voice, video, UC, or collaboration communications applications are NOT configured such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups or if general users (not SAs) can reconfigure the related settings.

Fix: F-16222r1_fix

Ensure PC based voice, video, UC, or collaboration communications applications are configured such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups. Configure PC based voice, video, UC, or collaboration communications applications such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups. Further ensure general application users cannot reconfigure these settings.

b

A non-approved public or commercial IM or IP telephony service or soft-client application is in use.

Medium - V-16117 - SV-17105r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1990 (GENERAL)

Vuln IDs

V-16117

Rule IDs

SV-17105r1_rule

Various DoD policies disallow general PC users from installing any non-approved application on their workstations or from attaching any non-approved or non-government furnished devices to them. Still other DoD policies require users of government furnished equipment (GFE) (i.e., DoD PCs/workstations) to limit their use to official business and not use them for personal business or other personal activities. Additionally, and more specific to this STIG, DoDI 8500.2 IA controls ECVI-1 and ECIM-1 to disallow general PC users from installing VoIP and IM clients that are intended to access public services for non-official, personal, use. An exception is made for the eventuality that such installations may be approved and performed by a DoD component for official business purposes. The IA controls state the following: • ECVI-1: “Voice over Internet Protocol (VoIP) traffic to and from workstation IP telephony clients that are independently configured by end users for personal use is prohibited within DoD information systems. Both inbound and outbound individually configured voice over IP traffic is blocked at the enclave boundary. NOTE: This does not include VoIP services that are configured by a DoD AIS application or enclave to perform an authorized and official function.” • ECIM-1: “Instant messaging traffic to and from instant messaging clients that are independently configured by end users and that interact with a public service provider is prohibited within DoD information systems. Both inbound and outbound public service instant messaging traffic is blocked at the enclave boundary. NOTE: This does not include IM services that are configured by a DoD AIS application or enclave to perform an authorized and official function.” NOTE: AIS in this case means Automated Information System and relates to an official program. The vulnerability is that 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. The mitigation of the vulnerabilities presented by these public services requires a two prong approach. The first is a technical approach, while the second is an administrative approach requiring user awareness, training, and agreements. A technical approach defined by the IA controls stipulates that traffic to and from public IM and VoIP services is to be blocked at the enclave boundary. It would be best if this were to occur at the NIPRNet Internet Access Points (IAPs), thus preventing such traffic from using the DISN, however this is not happening at this time since such blockage might also block other required services and the IAPs are not fully capable of such blockage at this time. This traffic must also be blocked at any Internet Service Provider (ISP) connection(s) to the enclave. NOTE: All ISP connections must be approved and operated under a waiver obtained from the Global Information Grid (GIG) waiver panel. It is the responsibility of the enclave to provide the required blocking since their firewalls and proxies are where the capability resides. To implement the mitigation, one might think that blocking specific IP addresses would be effective. This is not correct, however, since many of the public services have many IP addresses and servers, while they change their IP addresses regularly as a method of enhancing availability. Some of the public services have classically used non standard IP ports for their communications. Blocking these ports can be an effective measure in meeting the IA controls. Unfortunately, some of the public services are changing to use standard ports to get around the fact that many organizations block the nonstandard ports at their firewalls. The services are migrating to the standard ports 80 and 443 for web services which are generally never blocked. While the purpose of blocking these public services in the network is that this mitigation will prevent the application or service from functioning properly in the event one is installed. It is best to prevent the user from installing the client applications. This can be accomplished by limiting a user’s privileges on their PC such that they cannot install new software. This is typically done on many DoD PCs, however, some users require that ability. Also, unfortunately, just like the trend toward using standard ports, some services may function without a specific client by just using a web browser. This will most likely be the trend for the future. A seemingly more effective approach to blocking these public services or prevent their installation is to block them by their URL. This might be done at a proxy in the enclave boundary or on the PC itself by listing the URLs as un-trusted and setting the PC or proxy security or protection level such that un-trusted sites are blocked. NONECompromise of the supporting PC, attached network, and/or network resourcesSystem AdministratorInformation Assurance OfficerDCBP-1, ECSC-1

Checks: C-17161r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC based public or commercial IM and/or VoIP telephony services and/or supporting applications are unable to be used in the enclave in support of DoDI 8500.2 IA controls ECVI-1 and ECIM-1. NOTE: This requirement does not include IM and/or IP telephony services and/or supporting applications implemented by a DoD component and approved for use by the responsible DAA to fulfill a validated mission requirement. (e.g., DISA’s enterprise wide collaboration tools). NOTE: Examples of soft-clients and services to be disabled are, but are not limited to, the following: - Yahoo Messenger - America Online (AOL) Instant Messenger (AIM) - Microsoft Network (MSN) Messenger - Skype - Freshtel - Google Talk - Magic Jack (A hardware USB ATA and PC soft-client) - Soft clients associated with home telephone service from major PSTN carriers such as Verizon. AT&T, and Quest, major cable carriers such as Comcast and Cox, or competing VoIP carriers such as Vonage. Many others. Determine if Public or commercial IM or VoIP services are installed on PCs and/or are used. If installed, further determine if the application(s) are implemented by a DoD component and approved for use by the responsible DAA to fulfill a validated mission requirement. Inspect a random sample of PCs to determine if such applications are installed and which ones. This is a finding if such applications are installed whether used or not unless approved to fulfill a validated mission requirement or a non-approved application is installed beside an approved one.

Fix: F-16223r1_fix

Ensure PC based public or commercial IM and/or IP telephony services and/or supporting applications are unable to be used in the enclave in support of DoDI 8500.2 IA controls ECVI-1 and ECIM-1. Uninstall any and all applications associated with Public IM or VoIP services that have not been implemented by a DoD component and approved for use by the responsible DAA to fulfill a validated mission requirement. NOTE: This is typically handled by limiting user permissions to install software on their workstations or via policy or profile limitations enforced by HBSS.

b

Deficient user training regarding the use of non-approved applications and hardware.

Medium - V-16118 - SV-17106r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1325 (GENERAL)

Vuln IDs

V-16118

Rule IDs

SV-17106r1_rule

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

Checks: C-17162r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure: - Users are made aware and trained that even if their permissions allow, they are not to download and install IM and/or soft-phone applications on their DoD PCs that use or connect to public IM and/or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. - Users are made aware and trained that, they are not to attempt to use a stick phone on their DoD PC that associates itself or connects to a public IM or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. - Users are made aware and trained that, they are not to attempt to use a PPG on their DoD PC that associates itself with an installed soft-phone unless directed to do so by their DoD organization for the fulfillment of an official requirement. - The limitations in this requirement are listed in a signed user agreement. Note: DAA approval and possibly DISN DAA approval is required in the event IM and/or soft-phone applications, or stick phones that associate with or connect to a public IM or IP telephony service are to be implemented by a DoD component. Ask the IAO if the required user training is provided and if the items in the requirement are listed in a signed user agreement. Inspect user agreements for inclusion of the limitations and user acknowledgment. Additionally, interview a random sample of users to determine their awareness of these limitations. This is a finding if training is inadequate and users are unaware of the limitations and/or the limitations are not listed in signed user agreements.

Fix: F-16224r1_fix

Ensure users are trained as follows: - Users are made aware and trained that even if their permissions allow, they are not to download and install IM and/or soft-phone applications on their DoD PCs that use or connect to public IM and/or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. - Users are made aware and trained that, they are not to attempt to use a stick phone on their DoD PC that associates itself or connects to a public IM or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. - Users are made aware and trained that, they are not to attempt to use a PPG on their DoD PC that associates itself with an installed soft-phone unless directed to do so by their DoD organization for the fulfillment of an official requirement. Additionally ensure: - The limitations in this requirement are listed in a signed user agreement.

b

Deficient PPS registration of those PPSs used by a Voice/Video/UC system to include its core infrastructure devices and hardware based or PC application based endpoints.

Medium - V-16119 - SV-17107r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1020 (GENERAL)

Vuln IDs

V-16119

Rule IDs

SV-17107r1_rule

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 ManagerDCBP-1, DCPP-1, ECSC-1

Checks: C-17163r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure all IP Ports, Protocols, and Services (PPSs) used by a Voice/Video/UC system to include its core infrastructure devices and hardware-based or PC application-based endpoints are registered in the DoD Ports and Protocols Database in accordance with DoDI 8550.1. This applies to PPSs that remain within the enclave (“local PPS”) and those that cross the enclave boundary and/or any of the defined DoD boundaries. Determine the PPS used by all Voice/Video/UC system devices and endpoints (to include PC based endpoints) used at the site within the enclave and those that cross a boundary as well as the boundaries they cross where the network is exposed to them. Inspect the system documentation and if necessary contact the vendor. If necessary, use a sniffer to detect the protocols used. This would require operating all system functions or sniffing during a period of time when all functions are accessed. Inspect PPS registrations with regard to PPS used. This is a finding if all IP ports and protocols used by the Voice/Video/UC system to include its core infrastructure devices and its hardware based or PC application based endpoints are NOT registered in the DoD Ports and Protocols Database in accordance with DoDI 8550.1.

Fix: F-16225r1_fix

Ensure all IP Ports, Protocols, and Services (PPSs) used by a Voice/Video/UC system to include its core infrastructure devices and its hardware-based or PC application-based endpoints are registered in the DoD Ports and Protocols Database in accordance with DoDI 8550.1. This applies to PPSs that remain within the enclave (“local PPS”) and those that cross the enclave boundary and/or any of the defined DoD boundaries. Properly register all IP ports and protocols used by the Voice/Video/UC system to include its core infrastructure devices and hardware based or PC application based endpoints whether it crossed a boundary or not.

b

Deficient end-to-end interoperable confidentiality, integrity, and authentication for VVoIP session signaling per DISN IPVS Requirements.

Medium - V-19440 - SV-21491r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6165 (DISN-IPVS)

Vuln IDs

V-19440

Rule IDs

SV-21491r1_rule

Until recently VVoIP traffic has been restricted to the LAN/CAN within the enclave for most VVoIP systems. This is due to the lack of inter-vendor interoperability, end-to-end encryption, and the inability of VoIP to provide assured service in support of C2 communications reliability and priority requirements. The DSN PMO, DISA Engineering, and the 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. In doing so, specific choices had to be made amongst the various technological and vendor solutions to provide the capability. These choices were made with the full cooperation of a consortium of vendor engineers. The following requirement reflects one of these choices made to meet DoD “confidentiality of data in transit” requirements under the DoDI 8500.2 IA controls ECCT-1 and ECNK-1 as well as Federal Information Processing Standards (FIPS) and Internet Engineering Task Force (IETF) recommendations. NOTE: For the purpose of this document the DISN wide IP enabled DSN or RTS network will be referred to the DISN IP Voice Services network or DISN IPVS network. Real time IP communications (known as real time Services (RTS)) is comprised of signaling protocols which set up and manage the communications session and the media transfer protocols which carry the communications. Both signaling and media protocols and the resulting communications can be compromised when sent in the clear. One of the common means (per IETF recommendations) of initiating a RTS communications session across an IP network is to use Session Initiation Protocol (SIP). To provide the assured service pre-emption and priority capabilities required for C2 telephone communications, DISA developed an extension to the SIP protocol (with the assistance of interested vendors) which is 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 Transport Layer Security (TLS) as defined by the IETF recommendations. An additional factor to interoperability is the use of the same key management strategies at both ends of the session. 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. NOTE: the devices in a VVoIP system that are required to provide this protection are all those involved in session initiation from end-to-end. These are the End Instruments (EIs), Media Gateways (MGs), Local Session Controller (LSC), Soft-Switch (SS), Multi-Function Soft Switch (MFSS), and Edge Border Controllers (EBCs) (which is the DISN IPVS/UCN VVoIP firewall). noneDenial of Service - the inability to interoperate and complete a call across the DISN IPVS/UC network and lack of confidentiality or integrity for the communications.Information Assurance OfficerECCT-1, ECSC-1

Checks: C-23699r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event a VVoIP system provides assured, service sensitive but unclassified (SBU), or classified site-to-site communications and is integrated into a DISN IP Voice Services (VS) or Unified Capabilities (UC) network (DISN IPVS/UCN)(classified or unclassified); ensure all active participants in the signaling path provide hop-by-hop confidentiality, integrity, and authentication for signaling messages using TLS or IPSec. Implement the AES 128-bit algorithm or AES 256-bit algorithm as defined in the UCR. NOTE: The participants in question are the End Instruments (EIs), Media Gateways (MGs), Local Session Controller (LSC), Soft-Switch (SS), Multi-Function Soft Switch (MFSS), and Edge Border Controllers (EBCs) (which is the DISN IPVS VVoIP firewall). Additionally, ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS network.

Fix: F-20184r1_fix

When integrating a VVoIP system into an assured services classified or unclassified DISN IPVS/UC network: Ensure all active participants in the signaling path provide hop-by-hop confidentiality, integrity, and authentication for signaling messages using TLS or IPEec. Implement the AES 128-bit algorithm or AES 256-bit algorithm as defined in the UCR. NOTE: The participants in question are the End Instruments (EIs), Media Gateways (MGs), Local Session Controller (LSC), Soft-Switch (SS), Multi-Function Soft Switch (MFSS), Signaling Gateway (SG), and Edge Border Controllers (EBCs) (which is the DISN IPVS VVoIP firewall). Additionally ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS/UC network. Configure the VVoIP system components per the DoD APL IA deployment guide specific to the product being deployed.

b

Deficient end-to-end interoperable confidentiality and integrity for VVoIP session media streams per DISN IPVS requirements.

Medium - V-19441 - SV-21492r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6170 (DISN-IPVS)

Vuln IDs

V-19441

Rule IDs

SV-21492r1_rule

Until recently VVoIP traffic has been restricted to the LAN/CAN within the enclave for most VVoIP systems. This is due to the lack of inter-vendor interoperability, end-to-end encryption, and the inability of VoIP to provide assured service in support of C2 communications reliability and priority requirements. The DSN PMO, DISA Engineering, and the 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. In doing so, specific choices had to be made among the various technological and vendor solutions to provide the capability. These choices were made with the full cooperation of a consortium of vendor engineers. The following requirement reflects one of these choices made to meet DoD “confidentiality of data in transit” requirements under the DoDI 8500.2 IA controls ECCT-1 and ECNK-1 as well as Federal Information Processing Standards (FIPS) and Internet Engineering Task Force (IETF) recommendations. NOTE: For the purpose of this document the DISN wide IP enabled DSN or RTS network will be referred to the DISN IP Voice Services / Unified Capabilities (UC) Network or DISN IPVS/UCN or DISN IPVS/UC network. Real time IP communications (known as real time Services (RTS)) is comprised of signaling protocols which set up and manage the communications session and the media transfer protocols which carry the communications. Both signaling and media protocols and the resulting communications can be compromised when sent in the clear. The common means (per IETF recommendations) of transporting RTS media across an IP network is to use Real-time Transfer Protocol (RTP). The common means of providing confidentiality and integrity of the RTP streams is to apply a security profile to RTP called Secure Real-time Transfer Protocol (RTP). An additional factor to interoperability is the use of the same key management strategies at both ends of the session. 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. NOTE: The devices in a VVoIP system that are required to provide this protection are the End Instruments (EIs) and Media Gateways (MGs). These are the only devices in the end-to-end communications path that are required to have access to the unencrypted media stream. NoneDenial of Service - the inability to interoperate and complete a call across the DISN IPVS network and lack of confidentiality or integrity for the communicationsInformation Assurance OfficerECCT-1, ECSC-1

Checks: C-23701r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event a VVoIP system provides assured, service sensitive but unclassified (SBU), or classified site-to-site communications and is integrated into a DISN IP Voice Services (VS) or Unified Capabilities (UC) network (classified or unclassified); ensure End Instruments (EIs) and Media Gateways (MGs) provide end-to-end confidentiality for media streams using SRTP with AES_CM_128 as the default encryption algorithm or [as Required FY12] AES 256-bit algorithm as defined in the UCR. Additionally ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS network.

Fix: F-20295r1_fix

When integrating a VVoIP system into an assured services classified or unclassified DISN IPVS network, ensure End Instruments (EIs) and Media Gateways (MGs) provide end-to-end confidentiality for media streams using SRTP with AES_CM_128 as the default encryption algorithm or [as Required FY12] AES 256-bit algorithm as defined in the UCR. Additionally ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS network. Configure the VVoIP system components per the DoD APL IA deployment guide specific to the product being deployed.

a

The site’s V-VoIP system is NOT capable of maintaining call/session establishment capability such that it can minimally make local internal and local commercial network calls in the event the LSC or MFSS becomes unavailable to receive and act on EI signaling requests.

Low - V-19442 - SV-21493r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1210 (GENERAL)

Vuln IDs

V-19442

Rule IDs

SV-21493r1_rule

Voice phone services are critical to the effective operation of a business, an office, or in support or control of a 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 capability or ability to place calls to emergency services must be maintained. While the DoD voice and data networks are designed to be extremely reliable, such that continuity of operations (COOP) is supported, there is the potential that a site’s EIs will loose the availability to communicate or signal with the LSC or MFSS. Reality is that if signaling messages cannot reach a LSC or MFSS, calls cannot be established. This is an issue even though the LSC and MFSS are specified to provide 5 9s availability; there are many other factors that affect the availability of these central devices. Natural disasters or physical damage to the network connections and/or pathways are just some. The following are considerations for meeting this requirement: • Large sites and Intranets: •• Redundancy of platforms – Two or more LSC controllers clustered o Geographic diversity in locating the multiple LSCs within the site or Intranet • Small Sites (not dual homed): •• A single local subtended LSC may use a LSC to which it is subtended as the backup LSC for call control in the event the local LSC goes down. The best method for meeting this requirement on a large site is to implement redundancy for the LSC and the LSC portion of a MFSS. These redundant devices would then be located in redundant and geographically diverse facilities and connected to different parts of the LAN or CAN. This would mean that two core locations would be established within the site/enclave. LSCs and the LSC portion of a MFSS may be implemented on redundant platforms to meet the 5 9s availability requirements. Potentially these internally redundant devices might be able to be decomposed and located in the redundant facilities. Additional protections are needed for the communications between these decomposed elements. Additionally, each portion of the decomposed elements would need to be able to function on its own. In the event a site/enclave supports multiple tenants and one or more of these tenants have their own LSC, the main site could establish a COOP relationship with the tenant LSC and vise versa. An alternate method might be to establish a COOP relationship to a LSC or MFSS in another site or enclave. The issue with this arrangement is that the interconnection between sites is vulnerable and should be redundant with potentially COOP relationships with multiple LSCs at multiple sites. The best method for an Intranet served by a central LSC or MFSS is to place redundant LSCs in redundant and geographically diverse facilities which are then connected to different parts of the Intranet. Sites served by these LSCs should be dual homed using redundant circuits via geographically diverse paths. NoneThe inability to use the V-VoIP system to communicateInformation Assurance OfficerCOEF-1, DCBP-1, ECSC-1

Checks: C-23706r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure all sites possessing a LSC or MFSS are capable of maintaining call/session establishment capability such that it can minimally make local internal and local commercial network calls in the event the LSC or MFSS becomes unavailable to receive and act on EI signaling requests. Determine if the LSC or LSC portion of the MFSS has a backup call/session establishment capability such that it can minimally make local internal and local commercial network calls This is a finding in the event the primary LSC or LSC portion of the MFSS has no COOP relationship with another LSC in a redundant and geographically diverse facility. NOTE: The minimum capability for placement of precedence calls (line-side or to the DISN) is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.

Fix: F-20186r1_fix

Establish COOP capabilities for the primary LSC or LSC portion of the MFSS using redundant LSCs or COOP arrangements with other LSCs in redundant and geographically diverse facilities. NOTE: The minimum capability for placement of precedence calls (line-side or to the DISN)is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.

b

The local VVOIP system cannot place local intra-site or local commercial network calls in the event it is cut off from its remote, centrally located LSC.

Medium - V-19443 - SV-21494r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1215 (GENERAL)

Vuln IDs

V-19443

Rule IDs

SV-21494r1_rule

Voice phone services are critical to the effective operation of a business, an office, or in support or control of a 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 continuity of operations (COOP) is supported, there is the potential that a site will be cut off from the DoD network. Additionally, some site’s DoD VoIP phone systems are implemented without a local LSC. The LSC is located at some remote location and may serve several sites, both large and small. This scenario is sometimes called “long Local” service. Such an implementation can be used in regionalized organizational intranets and in MOBs with their tethered GSUs. 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 LSC over the DISN WAN connection, then the LSC has to signal the called instrument or MG 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 LSC. Based on this fact, and in support of maintaining viable local voice services in the event the site is cut off from its remote LSC, 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. NoneDenial of Service, Lack of availability, inability to communicate within the site or with external entities; the inability to place emergency calls. Information Assurance OfficerCOEF-1, DCBP-1, ECSC-1

Checks: C-23709r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the site has a VVOIP phone system which is implemented so that the endpoints are controlled by a LSC at a remote site, (e.g., implemented as “long Local” service), AND, the site does not have a separate commercial phone system (dedicated PBX, key system or discrete instruments) available, ensure the site has a backup VoIP call control capability such that it can minimally make local internal and local commercial network calls in the event the site is cut off from the remote LSC. That is, ensure the site has a backup VoIP call control capability such that normal or semi normal phone service is maintained in the event the site is cut off from the remote LSC; or ensure the site has an alternate phone system or instruments through which local commercial calls can be made. This is a finding in the event of the following: The VVoIP phone system is controlled by a remote LSC. AND The site does not have a local backup call control agent to maintain functionality of the VVoIP phones for both intra-site calls and external commercial network calls. AND The site does not have an alternate phone system for making external commercial network calls. NOTE: In general, reliance on DoD provided or personal cell phones does not meet this requirement due to the fact that good signal strength is not universal and reliable particularly in buildings and cell phones are not permitted everywhere in DoD facilities. This might, however, be a viable solution in some instances. NOTE: The minimum capability for placement of line-side precedence calls is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.

Fix: F-20187r1_fix

Ensure the site has a backup VoIP call control capability such that normal or semi normal phone service is maintained in the event the site is cut off from the remote LSC or ensure the site has an alternate phone system or instruments through which local commercial calls can be made. NOTE: The minimum capability for placement of line-side precedence calls is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.

b

The integrity of a vendor provided application, upgrade, or patch is not validated via digital signature before installation.

Medium - V-19482 - SV-21541r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1201 (GENERAL)

Vuln IDs

V-19482

Rule IDs

SV-21541r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-23772r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure VVoIP system applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Determine if VVoIP system applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Have the IAO or SA demonstrate the application and upgrade/patch integrity validation process. This is a finding if digital signatures are not validated before installation. NOTE: This requirement addresses applications, upgrades, and patches for the overall VVoIP system infrastructure. PC based applications, upgrades, and patches are addressed separately.

Fix: F-20210r1_fix

Ensure VVoIP system applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Employ only those VVoIP system applications, upgrades, and patches that are digitally signed by the vendor. Perform the appropriate digital signature validation process to validate application and upgrade/patch integrity before installation.

a

The confidentiality of endpoint configuration files downloaded by hardware based or PC based VVoIP endpoints during registration is not protected.

Low - V-19493 - SV-21552r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1936 (GENERAL)

Vuln IDs

V-19493

Rule IDs

SV-21552r1_rule

During VVoIP endpoint registration with the LSC, a file is downloaded by the endpoint from the LSC that contains specific configuration parameters needed by the endpoint to operate as needed to support its assigned user. This file contains the phone number assigned to the endpoint; the IP addresses (or URLs) of the LSC(s) with which the endpoint is associated; the software menus specific to the system; the user’s personal preferences and speed dial numbers; as well as other information critical to the operation of the endpoint. NOTE: Hardware based VVoIP endpoints are like diskless computers on the LAN which need to download an operating system and configurations before they can operate. The code necessary to download this OS is stored in ROM or Flash Memory and is called firmware. To varying degrees some, most, or all of the endpoint’s OS can be stored on the device as firmware. The more of the OS that is stored the device, the quicker it initializes. In any case, no matter how much of the OS is stored as firmware, each endpoint requires a customized configuration settings file to be downloaded that individualizes the endpoint to meet the needs of the user to which it is assigned. These configuration settings can be updated occasionally or regularly by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded. Many PC based communications applications are fully configured locally on the platform, however, in some cases they rely on a configuration file downloaded from the system with which they are associated. The confidentiality of these files is critical to preventing compromise of the PC application, hardware endpoint, and the system itself. Many vendors use configuration files of this sort that are a compact binary format that is only interpretable by the endpoint’s firmware or PD application. However, there is the potential that such files may be human readable as is XML code and most VVoIP signaling protocols. If the file is human readable, intelligence can be gathered by capturing the file while it is in transit. Additionally, the file is easier to understand and therefore makes it easier to modify it and then forward it to its destination. This facilitates man-in-the-middle attacks. The best method for maintaining the confidentiality of human readable files is to require that they be directly encrypted or downloaded over an encrypted channel. This can prevent man-in-the-middle attacks. Encryption of this file is also required if the file contains the password used to access the endpoint’s configuration information and settings menus. While encryption will also protect binary files, the threat is less due to the inability to easily read the information in the file without a program designed to interpret the binary code. As noted earlier, digital signatures and the file integrity must also be validated before the configuration file is used. NOTE: To satisfy the encryption requirement here, the file can be encrypted directly (preferred) or downloaded over an encrypted channel. (This is applicable to PC applications only) NOTE: Many of these configuration files are transferred using protocols such as BootP or TFTP which are designated “local management” per the DoD PPSM VAs for these protocols. These protocols are generally considered to be vulnerable due to their simplicity and lack of any security features. Per the DoD PPSM guidelines, a designation of “local management” means that PPSM recognizes the use of the protocol may be necessary within the LAN/enclave but it must remain within the LAN/enclave. This means that these protocols and therefore the configuration files transported by them must not traverse the WAN or enclave boundary unless protected by an encrypted VPN. As such, VVoIP endpoints that register with a LSC located in another LAN/enclave must do so via an encrypted site-to-site VPN between the enclaves or via an encrypted client-to-site VPN. VVoIP 1935/1936 NoneDisclosure of sensitive information about the VVoIP system or the user of the endpointTo mitigate issues regarding the integrity or confidentiality of the VVoIP endpoint configuration files or to provide a work around for a local policy preventing the use of the required file transfer protocols on the general business LAN, implement the following: > Disable automatic configuration file download on endpoint registration > Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated “Provisioning” LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN. DCBP-1, ECSC-1

Checks: C-23776r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure configuration files for hardware based and/or PC application based voice, video, UC, or collaboration communications endpoints downloaded during registration, are in a vendor specific binary format only interpretable by the vendor’s endpoints; or, if human readable; are encrypted; or, if downloaded across a WAN, are downloaded over an encrypted tunnel (VPN). Determine if the downloaded configuration files are binary or human readable. If they are human readable, verify that the files are directly encrypted. If not, and the endpoint in question is a PC communications application, determine if the file is downloaded over an encrypted channel such as a VPN. NOTE: Many of these configuration files are transferred using simple protocols such as BootP or TFTP which are designated “local management” per the PPSM VAs for these protocols. This means that these protocols and therefore the configuration files transported by them must not traverse the WAN or enclave boundary unless protected by an encrypted VPN. As such, VVoIP endpoints that register with a LSC located in another LAN/enclave, must do so via an encrypted site-to-site VPN between the enclaves or via an encrypted client-to-site VPN. NOTE: the segregation of VVoIP and data on the LAN provides some protection for these downloaded configuration files providing the transfer occurs within the LAN and not across a WAN. This becomes an issue for endpoints that register with an LSC in a remote enclave. This is a finding in the event of the following: > The downloaded configuration file is not in a vendor specific binary format only interpretable by the vendor’s endpoints OR the file is human readable and not natively encrypted. OR > The downloaded configuration file is transferred across a WAN but not transferred within an encrypted tunnel (VPN), (encrypted human readable or binary). This is not a finding in the event the following mitigations are employed: > Disable automatic configuration file download on endpoint registration. > Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated “Provisioning” LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN.

Fix: F-20214r1_fix

Ensure configuration files for hardware based and/or PC application based voice, video, UC, or collaboration communications endpoints downloaded during registration, are in a vendor specific binary format only interpretable by the vendor’s endpoints; or, if human readable; are encrypted; or, if downloaded across a WAN, are downloaded over an encrypted tunnel (VPN). In the event the system does not use a vendor specific binary format only interpretable by the vendor’s endpoints, configure the system to natively encrypt the endpoint configuration file. OR In the event the endpoint registers with a LSC in another enclave across a WAN, establish an encrypted tunnel between the enclave containing the LSC and the enclave containing the endpoint (site-to-site) or the endpoint itself (client-to-site). OR Employ the following mitigations: > Disable automatic configuration file download on endpoint registration > Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated “Provisioning” LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN.

a

The LAN supporting VVoIP services is not designed or implemented to provide enhanced availability and reliability above that of a traditional data LAN.

Low - V-19500 - SV-21562r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 5100 (LAN)

Vuln IDs

V-19500

Rule IDs

SV-21562r1_rule

• The traditional circuit switched telecommunications network is in general highly available highly and reliable on the order of 5 - 9s (99.999% uptime) reliability for the equipment and an aggregate of 2 to 3 9s for entire system and its provided services. This is achieved through a series of measures such as redundant hardware and network connectivity as well as backup power for the central switching equipment which also provides power for the subscriber instruments. • The traditional circuit switched telecommunications network supports routine communications, emergency communications, and high priority military command and control communications. Military telecommunications systems support various user types Special-C2, C2, C2-Routine (C2R), Non-C2, and administrative. C2 and Special-C2 users require higher levels of reliability and availability then do the rest. • As these services migrate from circuit switched technologies to packet switched IP based technologies, this reliability and support is expected to and must migrate with the service. • Similar measures are used to enhance the reliability and availability of VVoIP services on an IP network as are used in a circuit switched network. NOTE: from CJCSI 6215.01C Appendix A Enclosure C Availability requirement for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. While this also states that no uninterrupted power supply is required (as a cost savings), all equipment and instruments in a VVOIP system should be provided with backup power in support of emergency, security, and life safety related communications. Also from the UCR, 5.3.1.7.3.1 Voice Services 1. Voice IP subscribers do not exceed more than 25 percent of available bandwidth (in LAN equipment and links) 2. No single point of failure within the ASLAN can cause a voice service outage to more than 96 users. 5.3.1.7.3.3 Data Services The LAN will be engineered for a ratio of 25 percent voice, 25 percent video, and 50 percent data. Data traffic can burst up to the full link capacity if voice and video are not present. NoneReduced availability and reliability or 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.ECSC-1

Checks: C-23780r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure any LAN that supports VVoIP services is designed and implemented to provide enhanced reliability, availability, and bandwidth for those services. Review the network diagrams and design information to determine if the LAN is designed to provide the required enhanced reliability and availability for the supported VVoIP services. Specific attention should be given in the areas of: - Bandwidth and traffic engineering (25% voice, 25% video, 50% data) - No single points of failure affecting service to greater than 96 instruments. - Equipment reliability - Equipment redundancy above the access layer - Equipment robustness and bandwidth capability - Connection redundancy above the access layer - Connection bandwidth capability - Access layer switch size / number of phones served - Backup power for all equipment. NOTE: Voice bandwidth engineering is based on 102 kbps (each direction) for each IP call for IPv4 and 110.0 kbps for IPv6. Video bandwidth engineering is not so simple since when present, a single video stream can utilize 160kbps to 7.5Mbps in addition to any audio stream. See the UCR for details. This is a finding in the event the design is generally deficient in these areas. NOTE: this check is not intended to initiate an in depth analysis of the network design. If the LAN is not is not properly designed it should be easily discerned because many of the criteria will not be met unless the LAN was already designed for high reliability and availability before adding VVUC services. If VoIP is added to a basic LAN infrastructure that has not been properly designed, the service will not be reliable.

Fix: F-20216r1_fix

Ensure the LAN that supports VVoIP services is designed and implemented to provide enhanced reliability and availability for those services. Redesign and Upgrade the LAN infrastructure as necessary to meet requirements. Specific attention should be given in the areas of: - Bandwidth and traffic engineering (25% voice, 25% video, 50% data) - No single points of failure affecting service to greater than 96 instruments. - Equipment reliability - Equipment redundancy above the access layer - Equipment robustness and bandwidth capability - Connection redundancy above the access layer - Connection bandwidth capability - Access layer switch size / number of phones served - Backup power for all equipment. NOTE: Voice bandwidth engineering is based on 102 kbps (each direction) for each IP call for IPv4 and 110.0 kbps for IPv6. Video bandwidth engineering is not so simple since when present, a single video stream can utilize 160kbps to 7.5Mbps in addition to any audio stream. See the UCR for details.

b

The LAN hardware does not provide the required redundancy to support the availability/reliability needs of the C2 and Special C2 users of VVoIP services for command and control communications OR the needs of routine users for emergency life-safety and security related communications.

Medium - V-19514 - SV-21576r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5110 (LAN)

Vuln IDs

V-19514

Rule IDs

SV-21576r1_rule

Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. Policy excerpts are as follows: 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 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details. NOTE: In large LAN infrastructures, it is most likely that each network element in the core and distribution layers of the LAN will support in excess of 96 users whether they are C2 users or not. All users of VVUC services supported by the LAN deserve reliable communications, particularly in emergency situations. As such, these devices should possess the ability to fail-over to a redundant piece of hardware. At the network access layer (the layer where endpoints connect), this is more difficult. While redundant power supplies, backplanes, and processors can provide redundancy for a given NE, this is not possible for the portion of the NE to which the LAN drop cable attaches. Here there can be no automatic failover. The use of the 96 user figure at the access layer is in support of this requirement. Typically access layer modules or stand alone devices support 48 and fewer connections. So, while all access layer switches should have some form of internal redundancy, there is a point when this is not cost effective or possible. In this case, a failure must be mitigated by physically moving LAN drop connections to a hot-standby device or replacing the defective module. Also note that for a LAN that supports 96 or fewer VVUC users as a whole would mean that by policy omission redundancy is not required, it is best practice that redundancy exists in some manner and particularly at the core or that there is spare equipment available. NOTE: While the policy discusses availability and reliability, through LAN equipment redundancy for C2 and Special C2 users of VVUC services, similar availability and reliability through redundancy is needed in support of routine user emergency life-safety and security related communications. This finding carries a severity of Cat II if the NE directly supports a Special-C2 or C2 user. This finding carries a severity of Cat III if the NE only directly supports C2R, or Non-C2/admin users. NOTE: This is not applicable if the LAN as a whole supports 96 or fewer VVUC users. In the event the LAN as a whole supports more than 96 VVUC users, there will be some portion of the LAN infrastructure to which this will be applicable. These will typically the core elements as a minimum. Reduced availability and reliability or 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 OfficerECSC-1

Checks: C-23782r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure all ASLAN (and optionally Non-ASLAN) switching/routing platforms that support more than 96 telephony subscribers/instruments (C2 or not) are redundant in the following manner: 1. Dual Power Supplies. The platform shall provide a minimum of two power supplies each with the power capacity to support the entire chassis. Loss of a single power supply shall not cause any loss of ongoing functions within the chassis. 2. Dual Processors (Control Supervisors). The chassis shall support dual control processors. Failure of any one processor shall not cause loss of any ongoing functions within the chassis (e.g., no loss of active calls). 3. Termination Sparing. The chassis shall support a (N + 1) sparing capability for available 10/100Base-T modules used to terminate to an IP subscriber. 4. Redundancy Protocol. Routing equipment shall support a protocol that allows for dynamic rerouting. 5. Switch Fabric or Backplane Redundancy. Switching platforms within the ASLAN shall support a redundant (1 + 1) switching fabric or backplane. The second fabric’s backplane shall be in active standby so that failure of the first shall not cause loss of ongoing events within the switch. OR A secondary product is added to the ASLAN to provide redundancy to the primary product. AND A redundancy protocol is implemented such that the failover over to the secondary product must not result in any lost calls. Determine if the LAN supports Special-C2 or C2 users. If so, determine which part (or parts) of the LAN directly supports these users. Inspect the system design documentation and specifications of the LAN network elements. This is a finding in the event the LAN is not designed to provide the required redundant processors, power supplies, etc as noted above or there is no secondary product through which VVUC services can be routed. This finding carries a severity of Cat II if the NE directly supports a Special-C2 or C2 user. This finding carries a severity of Cat III if the NE only directly supports C2R, or Non-C2/admin users. NOTE: This is not applicable if the LAN as a whole supports 96 or fewer VVUC users. In the event the LAN as a whole supports more than 96 VVUC users, there will be some portion of the LAN infrastructure to which this will be applicable. These will typically the core elements as a minimum.

Fix: F-20226r1_fix

Ensure all ASLAN (and optionally Non-ASLAN) switching/routing platforms that support more than 96 telephony subscribers/instruments (C2 or not) are redundant in the following manner: 1. Dual Power Supplies. The platform shall provide a minimum of two power supplies each with the power capacity to support the entire chassis. Loss of a single power supply shall not cause any loss of ongoing functions within the chassis. 2. Dual Processors (Control Supervisors). The chassis shall support dual control processors. Failure of any one processor shall not cause loss of any ongoing functions within the chassis (e.g., no loss of active calls). 3. Termination Sparing. The chassis shall support a (N + 1) sparing capability for available 10/100Base-T modules used to terminate to an IP subscriber. 4. Redundancy Protocol. Routing equipment shall support a protocol that allows for dynamic rerouting. 5. Switch Fabric or Backplane Redundancy. Switching platforms within the ASLAN shall support a redundant (1 + 1) switching fabric or backplane. The second fabric’s backplane shall be in active standby so that failure of the first shall not cause loss of ongoing events within the switch. OR A secondary product is added to the ASLAN to provide redundancy to the primary product. AND A redundancy protocol is implemented such that the failover over to the secondary product must not result in any lost calls. Upgrade as needed. NOTE: While redundancy may not be required by policy for NEs that support 96 VVUC users or less, it is best practice to provide redundancy or maintain spares such that service can be restored in a timely manner in the event of a failure.

b

The design of the LAN supporting VVoIP services does not provide for the interconnection of LAN NEs with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above

Medium - V-19521 - SV-21583r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5115 (LAN)

Vuln IDs

V-19521

Rule IDs

SV-21583r1_rule

Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. The UCR in section 5.3.1.7.7.1 Single Product Redundancy states “In the event of a component failure in the network, all calls that are active shall not be disrupted (loss of existing connection requiring redialing) and the path through the network shall be restored within 5 seconds.” While the UCR is discussing hardware redundancy in this section it also discusses connectivity within the LAN as follows: 5.3.1.7.9 Survivability 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. For the ASLAN, survivability needs to be inherent in the design. The following guidelines are provided for the ASLAN: 1. Layer 3 Dynamic Rerouting. The ASLAN products that route (normally the Distribution and Core Layers) shall use routing protocols IAW the DISR to provide survivability. 2. Layer 2 Dynamic Rerouting. • Virtual Router Redundancy Protocol (VRRP) – RFCs 2787 and 3768. VRRP is able to provide redundancy to Layer 2 switches that lose connectivity to a Layer 3 router. The ASLAN shall employ VRRP to provide survivability to any product running Layer 2 (normally the Access Layer). These requirements translate into the need for redundant connections between all connected NEs within the LAN. As such this requires a single access layer or distribution layer NE to have two uplinks to the layer above. Additionally the physical paths these uplinks take should be physically diverse. Additionally, these paths should terminate in physically diverse locations (that is, different NEs in different locations) These measures represent best practices and should be utilized to support all VVUC users but are required for special-C2 and C2 users. The availability and reliability policy excerpts are repeated here in support of this requirement for convenience: 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 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details.NoneReduced availability and reliability or 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 OfficerDCBP-1, ECSC-1

Checks: C-23785r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the LAN supporting VVUC services is designed to interconnect all LAN NEs with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above. Additionally ensure that each uplink is designed to support the full bandwidth handled by the NE and the NE is capable of affecting a failover from one uplink to the other in the event of the failure of one. NOTE: This applies to access layer NEs connected to distribution layer NEs and distribution NEs connected to core layer NEs. Determine if the LAN supports Special-C2 or C2 users. If so, Determine which parts of the LAN support Special-C2 users, which parts support C2 users, and which parts support only C2R and Non-C2/admin users. Inspect the LAN design documentation, and as built schematics and physical cable routing diagrams to determine design compliance.

Fix: F-20229r1_fix

Ensure all LAN NEs supporting VVUC services are interconnected with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above. Additionally ensure that each uplink can support the full bandwidth handled by the NE and the appropriate routing protocol is configured to affect the failover from one uplink to the other in the event of the failure of one. NOTE: This applies to access layer NEs connected to distribution layer NEs and distribution NEs connected to core layer NEs. Run cable, upgrade, or reroute as necessary.

b

An uninterruptible power system (UPS) has not been designed or implemented to provide sufficient continuous backup power for the LAN Infrastructure, WAN boundary Infrastructure, VVoIP infrastructure, and/or VVoIP endpoints as required in support of special-C2 and C2 users system availability needs during a power outage OR sufficient backup power is not provided to C2-R or non-C2/admin user accessible endpoints, minimally in support of emergency life-safety and security calls.

Medium - V-19535 - SV-21597r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1220 (GENERAL)

Vuln IDs

V-19535

Rule IDs

SV-21597r1_rule

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 OfficerCOPS-2, DCBP-1, ECSC-1

Checks: C-23787r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure an uninterruptible power supply (battery at a minimum; plus optional generator) is provided for all parts of the VVoIP infrastructure (Core LSC/MFSS, adjunct systems providing critical services, EBC, CER, LAN NEs, and endpoints as follows: > All VVoIP system devices including voice endpoints and portions of the LAN that directly support any single special-C2 user are minimally provided 8 hours UPS. > All VVoIP system devices including voice endpoints and portions of the LAN that directly supports any single C2 user are minimally provided 2 hours UPS. > All VVoIP system devices including voice endpoints and portions of the LAN that supports C2R and non-C2/admin users (that is the balance of the VVoIP system) are provided some reasonable level (minimum 15 minutes / target 30 to 60 minutes) of UPS in support of emergency life-safety and security communications. > UPS systems supplying power to infrastructure that supports special-C2 and C2 users must also support environmental power (for example cooling power) such that equipment failures are prevented. This support may not need to be continuous but must be commensurate with the users supported (8 or 2hrs as appropriate). UPS. NOTE: UPS in support of C2R and non-C2/admin users’ endpoints is best provided using POE particularly if supporting the general population. (Probably more cost effective than a battery under every desk). While support of all such endpoints and infrastructure is desirable since this provides greater availability, the cost could become a negating factor. In this case, a portion of the regular endpoints or emergency use endpoints could be provided at strategic locations within the facility to fulfill the requirement to support emergency life-safety and security communications. Determine if the LAN supports Special-C2 or C2 users. If so, determine which part (or parts) of the LAN directly supports these users. Determine the method by which C2R and non-C2/admin users’ emergency life-safety and security communications are supported. This is a finding in the event, based on the interview; consideration has not been given to all aspects of backup power as described in the requirement. This finding carries a severity of Cat II if the requirements supporting a Special-C2 or C2 user are deficient. This finding carries a severity of Cat III if the requirements supporting C2R or Non-C2/admin users are deficient. 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.

Fix: F-20235r1_fix

Ensure an uninterruptible power supply (battery at a minimum; plus optional generator) is provided for all parts of the VVoIP infrastructure (Core LSC/MFSS, adjunct systems providing critical services, EBC, CER, LAN NEs, and endpoints as follows: > All devices including voice endpoints and portions of the LAN that directly support any single special-C2 user are minimally provided 8 hours UPS. > All devices including voice endpoints and portions of the LAN that directly supports any single C2 user are minimally provided 2 hours UPS. > All devices including voice endpoints and portions of the LAN that supports C2R and non-C2/admin users (that is the balance of the VVoIP system) are provided some reasonable level of UPS in support of emergency life-safety and security communications. > UPS systems supplying power to infrastructure that supports special-C2 and C2 users must also support environmental power (for example cooling power) such that equipment failures are prevented. This support may not need to be continuous but must be commensurate with the users supported (8 or 2hrs as appropriate). UPS NOTE: UPS in support of C2R and non-C2/admin users’ endpoints is best provided using POE particularly if supporting the general population. (Probably more cost effective than a battery under every desk). While support of all such endpoints and infrastructure is desirable since this provides greater availability, the cost could become a negating factor. In this case, a portion of the regular endpoints or emergency use endpoints could be provided at strategic locations within the facility to fulfill the requirement to support emergency life-safety and security communications. Install, upgrade, and maintain UPS systems as needed to meet the backup power requirements.

b

VVoIP core components are not assigned static addresses within the dedicated VVoIP address space

Medium - V-19545 - SV-21607r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5220 (LAN)

Vuln IDs

V-19545

Rule IDs

SV-21607r1_rule

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 OfficerDCBP-1, DCPA-1, ECSC-1

Checks: C-23792r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure static addresses are assigned to the VVoIP core components within the dedicated VVoIP address space.

Fix: F-20238r1_fix

Ensure static addresses are assigned to the VVoIP core components within the dedicated VVoIP address space. When defining the VVoIP system implementation plan and addressing scheme, assign static addresses to the VVoIP core components

b

The voice/video system management network is not designed or implemented to provide the proper bidirectional enclave boundary protection between the local management network and the DISN Voice Services (VS) management network.

Medium - V-19547 - SV-21610r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5405 (LAN)

Vuln IDs

V-19547

Rule IDs

SV-21610r1_rule

VVoIP core system devices and 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 on each. 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. This intra-enclave protection is required by DoD IA policy (DoDD 8500.1) which states: “defend the perimeters of enclaves; provide appropriate degrees of protection to all enclaves and computing environments.” More specifically DoDI 8500.2 IA controls EBBD-2 and EBBD-3 regarding Enclave Boundary Defense for sensitive and classified systems respectively state, in part, “Boundary defense mechanisms to include firewalls and network intrusion detection systems (IDS) are deployed at the enclave boundary to the wide area network, at layered or internal enclave boundaries, and at key points in the network, as required.” The key portion of these IA controls addressed here is the part that states “at layered or internal enclave boundaries, and at key points in the network, as required.” This is further qualified by the definition of an enclave which states in part: Enclave: 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 IA control EDDB-x is applicable and minimally a firewall is required where these enclaves meet. This requirement is generally applicable to VVoIP core system devices and TDM based telecom switches that are managed via multiple networks and specifically applicable to those where those systems and devices are managed via a single physical Ethernet/IP interface. As an example, if the ADIMSS and local SAs both manage a TDM switch or VVoIP system/device via a common pathway e.g., the local management VLAN or OOB management network, a firewall is required between the local network and the ADIMSS network. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Additionally the corruption of data and/or unauthorized use of the supporting server.Information Assurance OfficerEBBD-2, ECSC-1

Checks: C-23797r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP core system or the TDM based telecom switch is managed via a local voice management network (OOB or in-band VLAN) and a DISN management network (e.g., RTS EMS, ADIMSS, ARDIMSS, or DCN), AND these two networks are interconnected for the management of one or more devices via the same management interface, ensure proper enclave boundary protection mechanisms and deny-by-default ACLs are placed at the entry point of the DISN management network to the local management network to block unauthorized access from either network to the other. Additionally ensure the enclave boundary protection configuration only permits specific protocols to flow between specific pairs of IP addresses across the boundary as required for proper operation of the management mission. Validate the effectiveness of the boundary protection on an annual basis. NOTE: Per EDDB-x proper boundary protection is defined as a firewall and IDS. NOTE: All intrusion alerts or alarms generated by the IDS or firewall should be reported in real time to the service level NOC and/or CNDSP NOC associated with each enclave with potential additional reporting to a DISN level NOC such as a TNOSC or GNOSC. Determine who owns the enclave boundary protection device (e.g., a firewall) and therefore who is responsible for its configuration and management. This device could be owned and operated by the DISN management network or the local network. Or there could be two such devices owned and operated each entity. If there is a single boundary protection device, additionally determine if there is a MOA regarding the operation of the device such that the owner implements a configuration that not only protects the owner’s network but also protects the other’s network. Further validate that both parties have agreed to or signed the MOA. If there is no such MOA, the respective owners may need to implement their own devices.

Fix: F-20249r1_fix

In the event the VVoIP core system or the TDM based telecom switch is managed via a local voice management network (OOB or VLAN) and a DISN management network (e.g., RTS EMS, ADIMSS, ARDIMSS, or DCN), ensure proper enclave boundary protection mechanisms and ACLs are placed at the entry point of the DISN management network to the local management network to block unauthorized access from either network to the other. Additionally, ensure the enclave boundary protection configuration only permits specific protocols to flow between specific pairs of IP addresses across the boundary as required for proper operation of the management mission. Validate the effectiveness of the boundary protection on an annual basis. NOTE: Per EDDB-x proper boundary protection is defined as a firewall and IDS. NOTE: All intrusion alerts or alarms generated by the IDS or firewall should be reported in real time to the service level NOC and/or CNDSP NOC associated with each enclave with potential additional reporting to a DISN level NOC such as a TNOSC or GNOSC. If there is a single boundary protection device, additionally determine if there is a MOA regarding the operation of the device such that the owner implements a configuration that not only protects the owner’s network but also protects the other’s network. Further validate that both parties have agreed to (signed) the MOA. If there is no such MOA, the respective owners may need to implement their own devices. Implement ACLs that provide a deny-by-default posture such that only the specifically required protocol traffic between specific pairs of IP addresses is permitted across the boundary. More specifically, ACLs should be defined as follows: Inbound ACL: > Permit the specifically authorized and required protocol sourced from the IP address of the specifically authorized device on the DISN management network to reach the specific IP address of the managed device or required local management server. > Additional statements for each protocol and IP address pair. >Deny all other traffic. Outbound ACL: > Permit the specifically authorized and required protocol sourced from the specific IP address of the managed device or any required local management server to reach the specific IP address of the specifically authorized device on the DISN management network. > Additional statements for each protocol and IP address pair. >Deny all other traffic. The net result of this ACL is to permit authorized devices to communicate while blocking unauthorized access from the local management network and any attached workstations to the DISN management network and to block access from the DISN management network to all devices on the local management network other than the required managed devices or management servers. NOTE: An ACL statement is required for each IP address on the local management network that must communicate across the boundary to provide proper control. Defining ACLs to permit a subnet, while easiest, will not provide the proper control. This is supported by the previously started requirement that managed devices are all required to have static IP addresses. This requirement is extend to management servers and potentially to management workstations. Validate the effectiveness of the boundary protection ACLs on a regular basis and/or minimally on an annual basis by performing network vulnerability scans as follows: > Scan the entire DISN management network (e.g., RTS EMS, ADIMSS, ARDIMSS, or DCN), address space from an unused randomly selected IP address on the local management network. > Scan the entire local management network address space from an unused randomly selected IP address on the DISN management network. The expected result is no response from any host on either network. NOTE: While this scan is useful in determining if the boundary protection works by blocking access from a randomly selected IP address, a more effective test would be to perform the scan from a randomly selected management workstation. A different workstation should be selected each time the scan is performed.

b

The VVoIP system and LAN design does not provide the necessary segmentation and protection of the VVoIP system core device management traffic and interfaces such that role based access and traffic flow can be properly controlled.

Medium - V-19562 - SV-21626r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5505 (LAN)

Vuln IDs

V-19562

Rule IDs

SV-21626r1_rule

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. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Additionally the corruption of data and/or unauthorized use of the supporting server.Information Assurance OfficerDCBP-1, DCPA-1, DCSP-1, ECSC-1

Checks: C-23802r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure voice/video system (VVoIP system and/or TDM switch) management is segregated or separated from production traffic and other management traffic and such that access and traffic flow can be properly controlled and role based access is supported. NOTE: This can be implemented using a separate voice (VVoIP or TDM) system management VLAN or OOB network, the purpose of which is to provide for separation of access paths in support of separation of duties between the data network or server SAs and the VVoIP or TDM system SAs. This VLAN may be accessed from the general LAN management VLAN via a controlled ACL, gateway or firewall if needed. This is a finding in the event the VVoIP system and LAN is not designed to provide the necessary separation of the management traffic and interfaces or such separation is not implemented as described above or at all.

Fix: F-20254r1_fix

Implement a dedicated OOB network or closed virtual In-band network (VLAN) for the VVoIP system and connect the core device management interfaces to it in compliance with the following requirement: Ensure VVoIP system management is segregated or separated from production traffic and other management traffic and such that access and traffic flow can be properly controlled and role based access is supported. NOTE: 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. This VLAN may be accessed from the general LAN management VLAN via a controlled ACL, gateway or firewall if needed.

b

The VVoIP system and supporting LAN design does not contain one or more routing devices (router or layer-3 switch) or they are not implemented to provide support for required ACLs between the various required VVoIP VLANs.

Medium - V-19565 - SV-21629r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5510 (LAN)

Vuln IDs

V-19565

Rule IDs

SV-21629r1_rule

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. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. Additionally the corruption of data and/or unauthorized use of the supporting server.Information Assurance OfficerDCBP-1, DCPA-1, DCSP-1, ECSC-1

Checks: C-23804r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the LAN supports VVoIP system core or infrastructure equipment or multiple VVoIP VLANs, ensure the supporting LAN design contains one or more routing devices (router or layer 3 switch) to provide traffic control (support for required ACLs) between the various required VVoIP VLANs required for the core equipment. This device(s) should be as close to the VVoIP core equipment as possible. As such this is the intersection of these VLANs. NOTE: this does not have to be one device but could be several, particularly if the VVoIP equipment is split and geographically diverse in support of system survivability. NOTE: These devices may be (and typically will be) the core routing devices for the data LAN as well or may be dedicated to the VVoIP system.

Fix: F-20255r1_fix

Ensure the VVoIP system and supporting LAN design contains one or more routing devices (router or layer 3 switch) to provide traffic control (support for required ACLs) between the various required VVoIP VLANs. Install the required routing equipment as close to the VVoIP core equipment as is practical and apply the required ACLs.

b

The site’s enclave boundary protection is not designed or implemented to route all VoIP traffic to/from a commercial number via a locally implemented Media Gateway (MG) connected to a PSTN CO using a PRI or CAS trunk.

Medium - V-19592 - SV-21733r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1015 (GENERAL)

Vuln IDs

V-19592

Rule IDs

SV-21733r1_rule

There are several reasons why VVoIP system access to commercial voice services (i.e., the PSTN) must be via a Media Gateway if exceptions do not apply. These reasons are as follows: > Most high capacity local commercial voice service (more than a few individual lines) is delivered from the carrier via TDM trunks. This requires the conversion to VoIP via a media gateway. > The implementation or receipt of commercial VoIP service from an Internet Telephony Service Provider (ITSP), would require the implementation of an Internet Service Provider (ISP) connection or a connection into the service provider’s network via a VPN or dedicated TDM or optical circuit. In effect, a connection into the service provider’s network would provide a path to the Internet. These types of local connections provide a “back door” into the local network that can place the entire DISN or GIG at risk from exploitation and can circumnavigate the protections put in place by the operators of the DISN (DISA). 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. Specific requirements for the implementation of commercial VoIP service will be defined later. NOTE: The term “back door” as used here means an illicit or UN-approved connection and is not intended to have the same meaning as the term “backdoor connection”, as defined in RFC 2764, and used in the Network Infrastructure STIG. NOTE: 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. NOTE: The implementation of local ITSP connections to utilize commercial VoIP services at all BCPS would mean the implementation of an OSD / Gig Waiver Panel “approved ISP gateway” at each BCPS. This would amount to over 1000 direct connections between the Internet and the NIPRNet via the BCPS LAN. While these connections might be limited to VoIP only traffic, these would have the potential to be mis-configured in such a way that the connection provides an open “back door” for general access, Internet traffic, and attacks. This presents a huge risk to the DISN which is unacceptable. It is therefore highly unlikely that DoD will take such an approach and approve such connections. NoneUnauthorized access to a DoD network via a commercial VoIP service.Information Assurance OfficerEBBD-1, EBBD-2, EBBD-3, ECSC-1

Checks: C-23862r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure all VVoIP system access to/from commercial dialup services (voice, video, fax, data) is via a locally implemented Media Gateway (MG) using a PRI or CAS trunk to a PSTN CO except as follows: • The enclave is small and has one or more PSTN subscriber lines terminated on individual phones, a dedicated key system, or a PBX, all of which are separate from the DoD VVoIP system. • The enclave is small and has one or more Commercial/Public VoIP subscriber lines or trunks terminated on an IP/Ethernet network that is separate from the DoD NIPRNet accessible network. (NOTE: This situation requires OSD GIG Waiver Panel approval for the required ISP connection.) NOTE: Trunks that support SS7 signaling and SS7 based signaling between a DoD network and a non-DOD network is prohibited. Determine if the following exceptions apply: • Is the enclave small and does it have one or more PSTN subscriber lines terminated on individual phones, OR a dedicated key system, OR a dedicated PBX, all of which are separate from the DoD VVoIP system? • Is the enclave small and does it have one or more Commercial/Public VoIP subscriber lines or trunks terminated on an IP/Ethernet network that is separate from the DoD NIPRNet accessible network? This is a finding in the event the site is not connected to the PSTN via a MG located within the local site enclave as described above AND one of the exceptions is not applicable.

Fix: F-20290r1_fix

Ensure all VVoIP system access to/from commercial dialup services (voice, video, fax, data) is via a locally implemented Media Gateway (MG) using a PRI or CAS trunk to a PSTN CO except as follows: • The enclave is small and has one or more PSTN subscriber lines terminated on individual phones, a dedicated key system, or a PBX, all of which are separate from the DoD VVoIP system. • The enclave is small and has one or more Commercial/Public VoIP subscriber lines or trunks terminated on an IP/Ethernet network that is separate from the DoD NIPRNet accessible network. (NOTE: This situation requires OSD GIG Waiver Panel approval for the required ISP connection.) NOTE: Trunks that support SS7 signaling and SS7 based signaling between a DoD network and a non DOD network is prohibited.

b

Local commercial phone service has not been implemented in support of COOP and local emergency services calls in the event the site is cut off from the DISN phone networks whether they are TDM of IP based.

Medium - V-19593 - SV-21734r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1225 (GENERAL)

Vuln IDs

V-19593

Rule IDs

SV-21734r1_rule

Voice phone services are critical to the effective operation of a business, an office, or in support or control of a 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 continuity of operations (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 type and amount of local phone service required can also depend upon the size of the site. The following are some examples: > A large site or main operating base (MOB) could use PRI or CAS TDM trunks connected to the site’s PBX. The larger the site the more trunks are used. > A small site or geographically separate unit (GSU) attached to a MOB. >> May have a PBX and be served similar to a large site. >> May be served by several analog phone lines terminated on discrete instruments or a key system. NOTE: The use of locally delivered commercial VoIP service is prohibited. None The inability to make any calls in the event the DISN service is downInformation Assurance OfficerCOEF-1, DCBP-1, ECSC-1

Checks: C-23865r1_chk

Interview the IAO to confirm compliance with the following requirement: At each B/C/P/S, Ensure local analog or TDM commercial phone service is implemented in support of COOP for DoD calls and local emergency services. This applies to TDM or VVoIP systems conditionally as follows: • Via the sites local, on site, phone system/switch (TDM or VoIP) providing access to the local service from all work areas. • Via dedicated instruments (separate from the DoD site wide phone system) distributed throughout the facility and accessible within a short distance from every work area. NOTE: These dedicated instruments may be stand alone or may be part of a dedicated a key system, PBX, or VoIP network all of which are separate from the DoD VVoIP or TDM phone system. NOTE: The IA premise of this requirement is “availability” and COOP. The purpose of this requirement is to provide local commercial service in the event the site is cut off from the DSN or a main site to which the local site is subtended and tethered (e.g., a small site that has no local switch/LSC and relies on the main site’s switch/LSC for its calling capabilities. NOTE: This requirement supports calls to other DoD facilities in the event the DSN or DISN IP-VS connection is unavailable (i.e., some portion of the network is down preventing access) and is required in support of local emergency services calls. Determine if the site has local commercial phone service. This is a finding in the event the site has no local commercial phone service available. NOTE: This applies to all strategic BCPS, CONUS or OCONUS, large and small, main base (MOB), or tethered GSU, wherever “friendly” local phone service is available and there is a need to call commercial numbers that are local to the site. NOTE: This does not apply to tactical sites in a war zone where “friendly” local phone service is not available. It is recommended that local phone service be obtained if “friendly” service is available

Fix: F-20291r1_fix

Contract for and Install local commercial phone service commensurate with the size of the site and the following: Ensure local analog or TDM commercial phone service is implemented in support of COOP for DoD calls and local emergency services. This applies to TDM or VVoIP systems conditionally as follows: • Via the sites local, on site, phone system/switch (TDM or VoIP) providing access to the local service from all work areas. • Via dedicated instruments (separate from the DoD site wide phone system) distributed throughout the facility and accessible within a short distance from every work area. NOTE: These dedicated instruments may be stand alone or may be part of a dedicated a key system, PBX, or VoIP network all of which are separate from the DoD VVoIP or TDM phone system.

b

The VVoIP system connection to the DISN WAN, its components, and/or changes to them are not included in the site’s enclave / LAN baseline documentation and C&A documentation.

Medium - V-19594 - SV-21735r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6100 (DISN-IPVS)

Vuln IDs

V-19594

Rule IDs

SV-21735r1_rule

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 OfficerDCHW-1

Checks: C-23866r1_chk

Interview the IAO to validate compliance with the following requirement: In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves, ensure the VVoIP system’s WAN connection and boundary as well as its components including as their upgrades and changes are included in the site’s enclave / LAN C&A documentation (i.e., the DIACAP Implementation Plan (DIP), System Identification Profile (SIP), Scorecard, etc.). > Review the baseline documentation and/or C&A documentation to verify that the VVoIP WAN boundary and/or modifications are included. Verify there is a procedure for approving changes to configuration.

Fix: F-20292r1_fix

In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves, ensure the VVoIP system’s WAN connection and boundary as well as its components including as their upgrades and changes are included in the site’s enclave / LAN C&A documentation (i.e., the DIACAP Implementation Plan (DIP), System Identification Profile (SIP), Scorecard, etc). Add the VVoIP WAN boundary and/or its modifications to the site’s enclave / LAN baseline and C&A documentation Obtain DAA approval for the updated documentation. Submit to the SRR team lead for validation and finding closure.

b

The VVoIP system within the enclave is not subscribed to or integrated with the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service

Medium - V-19595 - SV-21736r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6105 (DISN-IPVS)

Vuln IDs

V-19595

Rule IDs

SV-21736r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-23867r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event 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)), ensure the system is integrated with (subscribed to) the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service (i.e., DISN NIPRNet IP Voice Services (IPVS) or DISN SIPRNet IP Voice Services (IPVS) otherwise known as VoSIP). NOTE: an exception is given for an enclave that is part of an Intranet if the intranet as a whole is subscribed to the appropriate DISN IPVS. NOTE: An exception is given for private VVoIP communications systems implemented amongst a small community of interest to fulfill a validated mission requirement. In this case, the system is essentially an intercom even though it might span enclave boundaries and the DISN. Determine if the system is used to provide assured service communications between enclaves to any level of C2 user (Special C2, C2, C2(R)). This is a finding in the event the VVoIP system within the enclave is connected to the DISN WAN for VVoIP transport but is not subscribes to or integrated with the DISN IPVS implemented on NIPRNet or SIPRNet. This is not a finding in the event the VVoIP system within the enclave is integrated with a service level Intranet or if it is implemented as a private communications system (e.g., intercom) implemented amongst a small community of interest to fulfill a validated mission requirement.

Fix: F-20293r1_fix

In the event 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)), ensure the system is integrated with (subscribed to) the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service (i.e., DISN NIPRNet IP Voice Services (IPVS) or DISN SIPRNet IP Voice Services (IPVS) otherwise known as VoSIP).

b

One or more DOD APL listed Customer Edge Routers (CER) are not implemented as the DISN access circuit termination point for the DISN NIPRNet IPVS

Medium - V-19596 - SV-21737r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6115 (DISN-IPVS)

Vuln IDs

V-19596

Rule IDs

SV-21737r1_rule

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 dependant 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 such that interoperability is assured across the DISN service: > One or more DOD APL listed Customer Edge Routers (CERs) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. NOTE: The CER is the enclave’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. > One or more DOD APL listed Local Session Controller’s (LSCs) or Multi-Function Soft Switch (MFSS) within the enclave for session control. These are the system control and signaling agents of the system. The LSC and MFSS are robust/reliable and provide admission control, and QOS features / capabilities as required by the UCR. The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (typically one per site) performs LSC functions for its site and provides signaling management for a regional set of LSCs. > Each LSC or MFSS and CER will be separated by a firewall or session border controller having specific functionality as defined in the UCR. This DoD specific device is called an Edge Boundary Controller (EBC). This may be a dedicated device or may be a functional part of the required data firewall. The use of these devices is critical to the success of the DISN IPVS’s mission. Additionally, The typical perimeter or premise router (as designated by the NI and Enclave STIGs) will most likely not be capable of supporting the needs of VVoIP entering the DISN WAN. This is because only newer routers are capable of dealing with service classes and expedited forwarding. This why the DISN IPVS PMO specifies the specific additional capabilities required of the perimeter or premise router to support the needs of the Assures Service network. The router designated by the DISN IPVS PMO that is needed to support the service is called the Customer Edge Router (CER). This terminology is consistent with the terminology used by the DISN CORE PMO and other WAN service providers. The CER provides the following functionality: > Provides minimally four expedited forwarding cues (eight may be required in the future) > Places traffic within expedited forwarding cues based on the DSCP markings carried by the traffic > Routes AS-SIP-TLS packets and SRTP/SRTCP packets to the EBC function. (VVoIP firewall) > Routes all other traffic to the data firewall > Provides all of the filtering and security required of a perimeter or premise router as required by the NI STIG. NOTE: Proper DSCP marking of VVoIP packets is required to provide appropriate QoS for C2 priority calls in support of Assured Service. NoneThe inability to make precedence or priority calls across the DISN in support of C2 assured service communications.Information Assurance OfficerDCBP-1, ECSC-1

Checks: C-23868r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system is subscribed to the DISN NIPRNet IP Voice Services (IPVS) network, ensure the system and enclave boundary is designed to include one or more DOD APL listed CER(s) (Perimeter Router) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. NOTE: The CER is the enclave’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. NOTE: If the DISN access circuits are dual homed, dual CERs should be implemented unless a single CER can provide uninterrupted (5 9s) connectivity to the DISN. NOTE: In the future this requirement may be applicable (with some modification) to the DISN SIPRNet IPVS (VoSIP) network when the PMO adopts the DISN NIPRNet IPVS architecture. Determine, through interview and/or physical inspection, the specific make, model, and OS version of the CER.

Fix: F-20294r1_fix

In the event the VVoIP system is subscribed to the DISN NIPRNet IP Voice Services (IPVS) network, ensure the system and enclave boundary is designed to include one or more DOD APL listed CER(s) (Perimeter Router) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. NOTE: The CER is the enclave’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. NOTE: If the DISN access circuits are dual homed, dual CERs should be implemented unless a single CER can provide uninterrupted (5 9s) connectivity to the DISN. NOTE: In the future this requirement may be applicable (with some modification) to the DISN SIPRNet IPVS (VoSIP) network when the PMO adopts the DISN NIPRNet IPVS architecture.

b

A DOD APL listed Edge Boundary Controller (EBC) is not implemented as the DISN NIPRNet boundary to maintain the required enclave boundary protection while permitting DISN IPVS traffic to pass.

Medium - V-19597 - SV-21738r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6120 (DISN-IPVS)

Vuln IDs

V-19597

Rule IDs

SV-21738r1_rule

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 dependant 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 such that interoperability is assured across the DISN service: > One or more DOD APL listed Customer Edge Routers (CERs) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. NOTE: The CER is the enclave’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. > One or more DOD APL listed Local Session Controller’s (LSCs) or Multi-Function Soft Switch (MFSS) within the enclave for session control. These are the system control and signaling agents of the system. The LSC and MFSS are robust/reliable and provide admission control, and QOS features / capabilities as required by the UCR. The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (typically one per site) performs LSC functions for its site and provides signaling management for a regional set of LSCs. > Each LSC or MFSS and CER will be separated by a firewall or session border controller having specific functionality as defined in the UCR. This DoD specific device is called an Edge Boundary Controller (EBC). This may be a dedicated device or may be a functional part of the required data firewall. The use of these devices is critical to the success of the DISN IPVS’s mission. NoneThe inability to make precedence or priority calls across the DISN in support of C2 assured service communicationsInformation Assurance OfficerDCBP-1, ECSC-1

Checks: C-23870r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system is subscribed to the DISN NIPRNet IP Voice Services (IPVS) network, ensure a DoD APL listed Edge Boundary Controller (EBC) is implemented at the enclave boundary between the CER and LSC/MFSS to maintain the required enclave boundary protection while permitting DISN IPVS traffic to pass. NOTE: This may be a dedicated device or may be part of the required data firewall. NOTE: In the future this requirement may be applicable (with some modification) to the DISN SIPRNet IPVS (VoSIP) network when the PMO adopts the DISN NIPRNet IPVS architecture. NOTE: The EBC functionality may be combined in one device with the required data firewall functionality. Determine, through interview and/or physical inspection, the specific make, model, and OS version of the EBC.

Fix: F-20296r1_fix

Ensure a DOD APL listed Edge Border Controller (EBC) is implemented at the enclave boundary between the CER and LSC/MFSS to maintain the required enclave boundary protection while permitting DISN IPVS traffic to pass. NOTE: The EBC functionality may be combined in one device with the required data firewall functionality. APL listed devices and software loads can be found at Access the DoD APL web site at http://jitc.fhu.disa.mil/tssi/apl.html.

b

The network IDS is not configured or implemented such that it can monitor the traffic to/from the required VVoIP firewall/EBC (function) as well as the traffic to/from the data firewall (function).

Medium - V-19598 - SV-21739r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6125 (DISN-IPVS)

Vuln IDs

V-19598

Rule IDs

SV-21739r1_rule

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

Checks: C-23872r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system within the enclave is interconnected with other VVoIP systems across the WAN, ensure the required internal Network IDS (NIDS) is implemented such that it monitors the traffic to/from both the data firewall (function) and the required VVoIP firewall/EBC (function). NOTE: This is applicable whether the VVoIP system is integrated with the DISN IPVS or not. This is a finding in the event the NIDS is not implemented such that it sees traffic from the VVoIP firewall (EBC or other) as well as the data firewall. NOTE: The NIDS monitoring the VVoIP firewall may be the same device that monitors the data firewall or it may be a separate device. In the event it is a separate device, it is subject to all Network Infrastructure STIG requirements to include CNDSP monitoring if applicable. NOTE: The Network Infrastructure STIG recognizes that many of today’s NIDS are also intrusion prevention devices. The NI STIG refers to the required NIDS as an Intrusion detection/Prevention System (IDPS).

Fix: F-20297r1_fix

In the event the VVoIP system within the enclave is interconnected with other VVoIP systems across the WAN, ensure the required internal Network IDS (NIDS) is implemented such that it monitors the traffic to/from both the data firewall (function) and the required VVoIP firewall/EBC (function). NOTE: This is applicable whether the VVoIP system is integrated with the DISN IPVS or not.

b

One or more DOD APL listed Local Session Controller’s (LSCs) or Multi-Function Soft Switch (MFSS) are not implemented within the enclave for DISN IPVS session control.

Medium - V-19599 - SV-21740r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6130 (DISN-IPVS)

Vuln IDs

V-19599

Rule IDs

SV-21740r1_rule

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 dependant 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 such that interoperability is assured across the DISN service: > One or more DOD APL listed Customer Edge Routers (CERs) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. NOTE: the CER is the enclave’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. > One or more DOD APL listed Local Session Controller’s (LSCs) or Multi-Function Soft Switch (MFSS) within the enclave for session control. These are the system control and signaling agents of the system. The LSC and MFSS are robust/reliable and provide admission control, and QOS features / capabilities as required by the UCR. The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (typically one per site) performs LSC functions for its site and provides signaling management for a regional set of LSCs. An MFSS is a backbone device and is only required at DISN IPVS PMO designated locations. > Each LSC or MFSS and CER will be separated by a firewall or session border controller having specific functionality as defined in the UCR. This DoD specific device is called a Edge Boundary Controller (EBC). This may be a dedicated device or may be a functional part of the required data firewall. The use of these devices is critical to the success of the DISN IPVS’s mission NOTE: As noted in the LAN section, on a large facility (site) the primary LSC should have a backup LSC that is geographically separate from it. This is also applicable to a facility/site that has a MFSS. While the MFSSs work in pairs in the backbone and are therefore redundant with regard to backbone services, their LSC functionality should also be redundant. NoneThe inability to make precedence or priority calls across teh DISN in support of C2 assured service communicationsInformation Assurance OfficerDCBP-1, ECSC-1

Checks: C-23875r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system within the enclave is integrated with the unclassified DISN IPVS network, ensure the system is designed to include one or more DOD APL listed LSCs or a MFSS for call/session control within the enclave. NOTE: The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (one per site and potentially a backup LSC) performs LSC functions for its site and provides signaling management for a regional set of LSCs. An MFSS is a backbone device and is only required at DISN IPVS PMO designated locations. NOTE: The LSC and MFSS are robust/reliable and provide admission control, and QoS features / capabilities as required by the UCR. NOTE: in the future this requirement may be applicable (with some modification) to the classified DISN IPVS network when the PMO adopts the unclassified DISN IPVS architecture. Determine, through interview and/or physical inspection, the specific make, model, and OS version of the LSCs and/or MFSS.

Fix: F-20298r1_fix

In the event the VVoIP system within the enclave is integrated with the unclassified or classified DISN IPVS network, ensure the system is designed to include one or more DOD APL listed LSCs or a MFSS for call/session control within the enclave. An MFSS is a backbone device and is only required at DISN IPVS PMO designated locations. APL listed devices and software loads can be found at Access the DoD APL web site at http://jitc.fhu.disa.mil/tssi/apl.html.

b

The DISN Core access circuit is NOT properly sized to accommodate the calculated Assured Service Admission Control (ASAC) budgets for AS voice and video calls/sessions OR the required budgets have not been calculated.

Medium - V-19600 - SV-21741r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6155 (DISN-IPVS)

Vuln IDs

V-19600

Rule IDs

SV-21741r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-23877r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure Session Admission Control (SAC) for the DISN Core access circuit(s) is supported by engineered bandwidth budgets for VoIP and Video calls/sessions in support of Assured Service. NOTE: SAC in support of Assured Service is also referred to as Assured Service Admission Control (ASAC) NOTE: The VoIP budget covers the following types of services: Voice VoIP, FoIP, MoIP, or SCIP over IP calls NOTE: Per call/session units are defined in the UCR and are unidirectional. They must be doubled to support bi-directional communications between users which is the typical phone call. This is a finding in the event there is no evidence that the required budgets have been calculated and/or the access circuit has not been sized accordingly.

Fix: F-20299r1_fix

In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure Session Admission Control (SAC) for the DISN Core access circuit(s) is supported by engineered bandwidth budgets for VoIP and Video calls/sessions in support of Assured Service. NOTE: SAC in support of Assured Service is also referred to as Assured Service Admission Control (ASAC) NOTE: The VoIP budget covers the following types of services: Voice VoIP, FoIP, MoIP, or SCIP over IP calls NOTE: Per call/session units are defined in the UCR and are unidirectional. They must be doubled to support bi-directional communications between users which is the typical phone call. 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

b

The enclave is NOT dual homed to two geographically diverse DISN SDNs and DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers.

Medium - V-19601 - SV-21742r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6135 (DISN-IPVS)

Vuln IDs

V-19601

Rule IDs

SV-21742r1_rule

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 OfficerDCBP-1, ECSC-1

Checks: C-23879r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure the enclave is dual homed to two geographically diverse DISN SDNs and DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers. NOTE: This means there are two DISN (or commercial) access circuits (many circuits will have a commercial component, typically the “last mile”) from the site/enclave to the DISN SDNs. NOTE: This assumes the site/enclave is NOT collocated with a DISN SDN such that a direct Ethernet or optical connection can be made. NOTE: If a site is located at a DISN SDN and is able to directly connect to the SDN using Ethernet or optical connections, the site may be able to rely on the dual homing of the SDN into the core. However, the site must still be homed to two geographically diverse ARs. This is dependant upon the size or type of the SDN. A large site directly connected to a smaller SDN will implement an access circuit to a geographically diverse SDN (i.e., another SDN in another location remote from the local SDN. This should not be one of the SDNs that to which the local SDN is homed. Determine if the site supports any level of C2 user. Determine how many access circuits are implemented and to what SDN they are homed. Additionally, determine the ARs or PEs to which the enclave is homed. This is a finding in the event the site is a C2 site and the DISN access circuits between the enclave’s WAN boundary and the DISN is not redundant and diverse as described in the requirement and notes. This is not a finding in the event the site does not support any level of C2 user.

Fix: F-20300r1_fix

In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure the enclave is dual homed to two geographically diverse DISN SDNs and DISN WAN Service (NIPRNet or SIPRNet) routers. NOTE: This means there are two DISN (or commercial) access circuits (many circuits will have a commercial component, typically the “last mile”) from the site/enclave to the DISN SDNs. NOTE: This assumes the site/enclave is NOT collocated with a DISN SDN such that a direct Ethernet or optical connection can be made.. NOTE: If a site is located at a DISN SDN and is able to directly connect to the SDN using Ethernet or optical connections, the site may be able to rely on the dual homing of the SDN into the core. However, the site must still be homed to two geographically diverse ARs. This is dependant upon the size or type of the SDN. A large site directly connected to a smaller SDN will implement an access circuit to a geographically diverse SDN (i.e., another SDN in another location remote from the local SDN. This should not be one of the SDNs that to which the local SDN is homed.

b

The dual homed DISN core access circuits are NOT implemented such that each one can support the full bandwidth engineered for the enclave plus additional bandwidth to support surge conditions in time of crisis.

Medium - V-19602 - SV-21743r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6140 (DISN-IPVS)

Vuln IDs

V-19602

Rule IDs

SV-21743r1_rule

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 DCBP-1, ECSC-1

Checks: C-23881r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event dual homed DISN core access circuits are implemented as required to serve the enclave, ensure each circuit has the same capacity such that one is able to support the entire engineered bandwidth needs of the enclave. NOTE: Each circuit must be engineered to include additional bandwidth to support higher levels of both data and VVoIP communications in time of crisis. Determine if the site is dual homed via dual access circuits. Determine the size of both access circuits. Determine the engineered bandwidth needs for the enclave connection to the WAN.

Fix: F-20301r1_fix

Ensure a bandwidth engineering study is performed to determine the WAN bandwidth needs for the site to include surge capacity. Ensure each redundant DISN Core access circuit has the same capacity such that one is able to support the entire engineered bandwidth needs of the enclave.

b

The required dual homed DISN Core or NIPRNet access circuits DO NOT follow geographically diverse paths from the CER(s) along the entire route to the geographically diverse SDNs.

Medium - V-19603 - SV-21744r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 6145 (DISN-IPVS)

Vuln IDs

V-19603

Rule IDs

SV-21744r1_rule

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

Checks: C-23883r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure the required dual homed DISN Core or NIPRNet access circuits follow geographically diverse paths from the CER(s) along the entire route to the geographically diverse SDNs. Each circuit will use different facilities such as cables, demarks, and digital cross connects in geographically diverse locations. NOTE: Geographic and facilities diversity will be maintained on-site and off-site. This is a finding in the event the required dual-homed circuits follow the same path or are close enough to be damaged by a single event. NOTE: The paths taken by the access circuits must remain significantly separate for their entire length such that a single point of failure is not created.

Fix: F-20302r1_fix

Ensure dual homed DISN Core or NIPRNet access circuits follow geographically diverse paths from the CER(s) along the entire route to the geographically diverse SDNs. Ensure each circuit uses different facilities such as cables, demarks, and digital cross connects in geographically diverse locations. Ensure geographic and facilities is maintained on-site and off-site. Ensure the paths taken by the access circuits remain significantly separate along their entire length such that a single point of failure is not created.

a

Dual sets of CER, EBC, and LSC are NOT implemented in geographically diverse locations within a site supporting large numbers of C2 users

Low - V-19604 - SV-21745r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 6150 (DISN-IPVS)

Vuln IDs

V-19604

Rule IDs

SV-21745r1_rule

The enhanced reliability and availability achieved by the implementation of redundancy and geographic diversity throughout the DISN Core along with the implementation of dual homed circuits via geographically diverse pathways and facilities is negated if both access circuits enter the enclave via the same facility containing a single (or dual) CER connected to a single (or dual) EBC. It does not matter how reliable, redundant, and robust the CER, EBC, and power supply is (required to be 5 – 9s reliable), the facility housing this equipment represents a single point of failure. While this may be deemed to not be an issue for a small number of C2 users, the more C2 supported by the system, the greater the issue because all communications would be cut off in the event the facility is lost or severely damaged. Even less severe eventualities may also severely limit the capability of the system to support reliable communications. The mitigation for this system wide vulnerability is to implement redundant facilities to which the geographically diverse pathways containing the dual homed access circuits can run and terminate on redundant, geographically separated sets of CERs, EBCs, and core LAN equipment. LSCs can also be separated in this manner. Understandably, the mitigation for this issue is costly and facilities housing critical communications infrastructure are not lost very often. However, the cost of mitigating this vulnerability must be weighed against the loss of critical communications, particularly in time of crisis. If the site supports large numbers of high level C2 users or special C2 users, the cost of losing communications may outweigh the cost of providing redundant facilities. Another aspect of the loss of communications is that access to emergency services via the communications system would also be lost. The more users affected by such a loss the more the potential need to place calls to emergency services. As such, all sites, large and small can benefit from the implementation of redundant facilities and equipment. NOTE: The threat to strategic facilities is far greater from natural causes than from damage due to acts of war or terrorism, but all threats need to be considered. On the other hand, tactical facilities naturally have a higher vulnerability to acts of war, which are raised on a par with or exceed the vulnerability posed my natural events. NoneLoss of or reduced availability and the inability to complete a C2 or emergency call in time of crisis and following. Information Assurance OfficerDCBP-1, ECSC-1

Checks: C-23886r1_chk

Inspect the redundant facilities and equipment to determine compliance with the requirement. This is a finding in the event dual sets of CER, EBC, and LSC are NOT implemented that are housed in redundant facilities in geographically diverse locations. NOTE: If it is determined, following a cost vs benefit study and risk analysis, that redundant facilities containing dual sets of CER, EBC, and LSC are not warranted, for the given site, this should be marked as a finding and the justification included in the POA&M such that the DAA is cognizant of and can accept the risk.

Fix: F-20303r1_fix

Ensure dual sets of CER, EBC, and LSC are implemented that are housed in redundant facilities in geographically diverse locations within the site such that if one of locations is lost or isolated from the network, communications service is maintained. NOTE: If a site has a MFSS, a backup LSC should be implemented in a geographically diverse location. If it is determined that meeting this requirement is not warranted as based upon a cost vs benefit study and risk analysis, take the finding and justify it such that the DAA is cognizant of and can accept the risk.

a

Regular documented testing of hardware based COOP/backup or emergency telephones is not performed in accordance with a documented test plan or related documentation is deficient or non existent.

Low - V-21506 - SV-23715r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1921 (GENERAL)

Vuln IDs

V-21506

Rule IDs

SV-23715r1_rule

Backup/COOP or emergency telephones are useless if they don’t work. Thus they need to be tested regularly to ensure their functionality, particularly if they are not used regularly. Regular use will detect non functionality issues quickly. If not regularly used, service can be disrupted and the phone rendered inoperable without detection until a situation arose requiring its use. There’s nothing worse than a non functional communications device in an emergency situation. As such, a regular testing plan for backup/COOP or emergency telephones must be developed and documented that includes a record of the tests performed. The records of the test should include such information as the instrument being tested, date and potentially the time the test was performed, the name of the person performing the test, and whether the phone is functional or not. Additional information should be added if the phone is found to be non-functional such as maintenance actions taken and when service was restored. The frequency of testing for each instrument is variable but should minimally be monthly. Weekly, daily, or randomly within a monthly cycle is better. Testing may be made the responsibility of the user(s) the instrument serves providing they document their tests. Testing should include the placement of a call. While testing for the presence of dial tone could be a minimal test, this may not be an accurate indicator that a call can be completed. NoneThe inability to make an emergency or any call in the event the COOP/backup/emergency telephone is nonfunctional.Information Assurance OfficerInformation Assurance ManagerSecurity ManagerDCBP-1

Checks: C-25737r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event hardware based instruments are implemented in a COOP capacity for backup or emergency communications, and such instruments are not regularly used, the IAO will ensure the functionality of these instruments by implementing and documenting a testing program which will include the documentation of the results of each test. NOTE: The frequency of testing for each instrument is variable but should minimally be monthly. Weekly, daily, or randomly within a monthly cycle is better. Testing may be made the responsibility of the user(s) the instrument serves providing they document their tests. The test could minimally involve determining if dial tone is present (unless generated within the phone as with some VoIP phones), but should include the placement of a call to an emergency number.

Fix: F-22295r1_fix

In the event hardware based instruments are implemented in a COOP capacity for backup or emergency communications, and such instruments are not regularly used, the IAO will ensure the functionality of these instruments by implementing and documenting a testing program which will include the documentation of the results of each test. NOTE: The frequency of testing for each instrument is variable but should minimally be monthly. Weekly, daily, or randomly within a monthly cycle is better. Testing may be made the responsibility of the user(s) the instrument serves providing they document their tests. The test could minimally involve determining if dial tone is present (unless generated within the phone as with some VoIP phones), but should include the placement of a call to an emergency number.

b

Mitigations against data exfiltration via the voice and/or video communications network/system have not been implemented

Medium - V-21507 - SV-23716r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 2200 (GENERAL)

Vuln IDs

V-21507

Rule IDs

SV-23716r1_rule

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 totally converged IP based data and communications network. This can be referred to as Everything over IP (EoIP). 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. Today we employ various mitigations that serve to inhibit data exfiltration exploits via VVoIP such as described above. These include but are not limited to the following: > Restricting what software can be installed on a server or workstation > Restricting what that software can do > Restricting user to data > Restricting machine and user access to the network via port security and user authentication > As well as others As an additional part of a layered defense against enterprise data exfiltration via the VVoIP network, is to place filters at the VVoIP network egress points, (that is at the MGs and at or within the SBCs/EBCs) that can detect data flows and other anomalies in a RTP/SRTP media stream. Today this is an emerging technology with initial capabilities available today. It is expected that this technology will more robust and mature in the not too distant future. NoneThe compromise of sensitive DoD information Information Assurance OfficerInformation Assurance ManagerDCBP-1

Checks: C-25739r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure mitigations are implemented against sensitive data exfiltration via IP based voice/video communications systems as follows: >Filter/monitor IP media traffic through Media Gateways (MGs), Session Border Controllers (SBCs), and Edge Border Controllers (EBCs) to detect and block/inhibit the exfiltration of sensitive DoD data from the network via VVoIP RTP/SRTP communications sessions. > Enable appropriate alarms and security event auditing/logging on these filters such that network security personnel and administrators can take appropriate action. Determine the following: > The type(s) of connections to external networks: >> Traditional switch trunks connected to a VVoIP system via a MG. >> A VVoIP system connected to an external IP WAN (DISN U-IPVS or ITSP) via a SBC or EBC. This is a finding in the event one or more of the following conditions exist: > Traditional switch trunks are connected to a VVoIP system via a MG without a RTP/SRTP data exfiltration filter between the MG and the VVoIP system endpoints. >> The VVoIP system is connected to an external IP WAN (DISN U-IPVS or ITSP) via a SBC or EBC without a RTP/SRTP data exfiltration filter within the SBC/EBC or between the SBC/EBC and the VVoIP system endpoints.

Fix: F-22296r1_fix

Implement mitigations against sensitive data exfiltration via IP based voice/video communications systems as follows: >Filter/monitor IP media traffic through Media Gateways (MGs), Session Border Controllers (SBCs), and Edge Border Controllers (EBCs) to detect and block/inhibit the exfiltration of sensitive DoD data from the network via VVoIP RTP/SRTP communications sessions. > Enable appropriate alarms and security event auditing/logging on these filters such that network security personnel and administrators can take appropriate action. Establish proactive monitoring as well as policy and procedure regarding incident response.

b

The site has not provided for Fire and Emergency Services (F&ES) telecommunications services (fire, police, medical, etc) and/or the telephone system does not support or is not configured to support enhanced emergency communications.

Medium - V-21508 - SV-23717r1_rule

RMF Control

Severity

Medium

CCI

Version

VVT 2000

Vuln IDs

V-21508

Rule IDs

SV-23717r1_rule

The inability to contact emergency services via the public telephone system and/or privately-owned Multi-Line Telephone Systems (MLTS) (such as PBXs and VoIP telephone systems) threatens life safety as well as facility protection and security. Emergency communications generally includes requests for fire, police, and/or medical assistance. In DoD, these communications can also include requests for Aircraft Rescue and Fire Fighting (ARFF), explosive ordnance disposal, and similar emergency situations. The inability of first responders to automatically locate the caller threatens life safety and facility protection or security. The ability to call an F&ES telephone number is called Basic F&ES Communications. The ability for the operator answering the emergency call to automatically determine the location of the caller and relay this information to the first responders is called Enhanced F&ES Communications. The ability to contact 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. Support for enhanced emergency services communications by private MLTS is left to state legislation. Several states have such legislation today while more states are on the way. Eventually, most, if not all, states will likely have such legislation. Additionally, with respect to the DoD, DoDI 6055.06, DoD Fire and Emergency Services (F&ES) Program, December 21, 2006, provides DoD policy regarding emergency services and emergency services communications. While much of this policy addresses fire protection in general and more specifically training, staffing, and equipment, it also provides for telecommunications support for fire, medical, and security emergencies, whether directly or by implication. Several items of interest for this and subsequent STIG requirements are as follows: > 5.8. The Combatant Commanders, through Chairman of the Joint Chiefs of Staff, shall ensure F&ES protection of personnel, equipment, and facilities. > 6.6. Telecommunication Capability. Implement around-the-clock capability to conduct dedicated F&ES communications. > E8.1 Telecommunication Capability; Maintain around-the-clock capability to conduct essential F&ES communications. > E8.1.2. The DoD Components shall implement the installation F&ES alarm and communication function where feasible. > E8.1.2.1. Consolidate with an established continuously manned emergency communications center for all emergency services. > E8.1.2.4. DoD F&ES communications and dispatch functions may be provided by municipal F&ES or other outside agencies when those agencies compare favorably with DoD standards and can meet the prescribed communications criteria. Private telephone systems, in general, provide a large portion of the required telecommunication capability. All DoD telecommunications systems are private MLTS. As such, ALL private MLTS, VoIP or traditional must support enhanced emergency services communications for the completion of emergency calls. Per DoDI 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 MLTS. PSTN LECs and CLECs must route calls to this number in a non-blocking priority manner. Examples of such numbers are as follows: > 911 in North America > 112 in the EU and UK > 000 in Australia In some cases countries use a separate code for Police vs Medical vs Fire. A rather comprehensive listing can be found at http://en.wikipedia.org/wiki/Emergency_telephone_number. Issues arise when an emergency call is originated through a private phone 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. This is an issue when providing emergency communications services as a best practice or in compliance with governmental mandate. 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 is generally mandated by the FCC and state legislation. It is today’s state of the art and its implementation is a best practice. The enhanced F&ES communications capability is enabled using Automatic Number Identification (ANI) and Automatic Location Identification (ALI) information. ANI provides the telephone number of the calling party and is generated by the telephone system/switch. ALI associates the calling party’s number (ANI information) with their address, or registered the address/location of the phone being used. ALI is provided by a database function. The database may be maintained within the telephone system/switch or externally. In many cases, the F&ES answering service system will use the ALI information to map the location of the calling phone. ALI information in the public sector is maintained by the telephone service providers and is generally based on billing records. This works fine for traditional phones that have a fixed location at the end of a telephone company wire. 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 MLTS. If a private MLTS is to support enhanced F&ES telecommunications, an ALI database must be instituted and maintained current as instruments and numbers move around a facility or site. While, in many cases, this may be a manual task, automated systems are being developed. NOTE: Notwithstanding system configuration and capabilities, the system must also remain fully functional, minimally for a reasonable time period, in the event primary power is lost. As such, both traditional PBXs and VVoIP systems along with their supporting LAN infrastructure must be provided with sufficient backup power. Specific requirements for voice communications system backup power are addressed in additional requirements. NoneLoss of life, loss of personal and/or facility safety or security, loss of the facility.Information Assurance OfficerInformation Assurance ManagerOtherDCBP-1

Checks: C-25742r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure the site provides for the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, and supports enhanced Fire and Emergency Services (F&ES) telecommunications as follows: > The site has implemented support for DoDI 6055.06 through local policies, procedures, staffing, and facilities; or agreements/contracts with external agencies. > The site’s telephone system supports enhanced F&ES emergency communications. > If the site’s telephone system is a private MLTS (VoIP or traditional), the system provides Automatic Number Identification (ANI) information to the emergency services answering point and a Phone Switch Automatic Location Identification (PS-ALI) database is established within the telephone system or externally, the information from which is accessible to the emergency services answering point. > The site maintains the PS-ALI database and keeps it current with all telephone adds/moves and number changes.

Fix: F-22297r1_fix

Ensure the site provides for the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, and supports enhanced Fire and Emergency Services (F&ES) telecommunications as follows: > The site has implemented support for DoDI 6055.06 through local policies, procedures, staffing, and facilities; or agreements/contracts with external agencies. > The site’s telephone system supports enhanced F&ES emergency communications. > If the site’s telephone system is a private MLTS (VoIP or traditional), the system provides Automatic Number Identification (ANI) information to the emergency services answering point and a Phone Switch Automatic Location Identification (PS-ALI) database is established within the telephone system or externally, the information from which is accessible to the emergency services answering point or call center. > The site maintains the PS-ALI database and keeps it current with all telephone adds/moves and number changes. Implement a fire and emergency services telecommunications system.

b

Unnecessary PPS have not been disabled or removed from VVoIP system devices or servers.

Medium - V-21521 - SV-23733r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1021 (GENERAL)

Vuln IDs

V-21521

Rule IDs

SV-23733r1_rule

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 OfficerDCBP-1

Checks: C-25777r1_chk

Interview the IAO to validate compliance with the following requirement: For VVoIP and UC servers and endpoints, ensure all PPS that are not necessary for the operation or maintenance of the system are disabled or the supporting software removed. Limit production PPS to production interfaces and management PPS to the OAM&P interfaces.

Fix: F-22312r1_fix

Disable all PPS on all VVoIP or UC system servers and sevices that are not required to support OAM&P in the specific VVoIP system implementation. Additionally, if possible, remove the software for the unnecessary PPS.

a

The VVoIP system DNS server is not dedicated to the VVoIP system within the LAN; or the VVoIP system DNS server freely interacts with other DNS servers outside the VVoIP system; or the VVoIP system information is published to the enterprise WAN or the Internet.

Low - V-21522 - SV-23734r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 5212 (LAN)

Vuln IDs

V-21522

Rule IDs

SV-23734r1_rule

In some cases a VVoIP endpoint will be configured with one or more URLs pointing to the locations of various servers with which they are associated such as their call controller. These URLs are translated to IP addresses by a DNS server. The use of URLS in this manner permits an endpoint to find the server it is looking for in the event the server’s IP address is changed. This also permits the endpoint to locate its assigned or home call controller from a remote location on a network that is not their home network. While all of this adds flexibility to the system and the endpoint’s location, it also exposes the endpoint and the home system to DNS vulnerabilities. Additionally, the home VVoIP system must expose critical IP address and domain information to the DNS system. If the DNS system is exposed to the DNS servers that support the enterprise data network or the Internet, this information and exposure of the system is, or may be, extended to the world. This provides information that can be used to attack or compromise the VVoIP system. When using DNS within a VVoIP system so that endpoints can find various servers in the network, the DNS server should be dedicated to the VVoIP system. Further more this DNS server should have limited or no interaction with the DNS server used by the data portion of the LAN/CAN or a publicly accessible DNS server. This will protect the VVoIP system’s DNS server from some of the vulnerabilities inherent in DNS servers that serve data endpoints and that are connected to the wider enterprise networks or the Internet. While the use of DNS adds IP addressing flexibility to a VVoIP system, it is not necessary to use it for systems within the local LAN. VVoIP servers and infrastructure devices are required to be statically addressed. Therefore the endpoints can be configured with these known IP addresses rather than URLs. A remote endpoint is required to connect to the home enclave via a VPN. It receives an internal LAN address and therefore becomes a part of the LAN and can directly reach its servers using their IP address. A URL is not required. The only time a URL might be required is in the event the endpoint is required to find a server such as a directory server that is somewhere on the WAN. This is the case in the VoSIP system on SIPRNet. Not using DNS in a VVoIP system eliminates its exposure to DNS vulnerabilities and attacks effected using information obtained from the DNS. NOTE: In the event a DNS server is implemented within the VVoIP system, the DNS STIG must be applied to the server. NoneInformation Assurance OfficerDCBP-1

Checks: C-25780r1_chk

Interview the IAO to validate compliance with the following requirement: In the event DNS is used in the VVoIP system, ensure the DNS server is dedicated to the VVoIP system and that any DNS server interaction with other DNS servers is limited. Additionally ensure internal system URLS and information is not published to the enterprise WAN or the Internet. Determine if: The VVoIP system DNS server is not dedicated to the VVoIP system within the LAN; OR The VVoIP system DNS server freely interacts with other DNS servers outside the VVoIP system; OR The VVoIP system information is published to the enterprise WAN or the Internet. This is a finding in the event one or more of these conditions exist.

Fix: F-22313r1_fix

Consider not using DNS for the VVoIP system unless it is required. In the event DNS is used in the VVoIP system, ensure the DNS server serving the VVoIP system is dedicated to the VVoIP system and that any DNS server interaction with other DNS servers is limited. Additionally ensure internal system URLS and information is not published to the enterprise WAN or the Internet. NOTE: In the event a DNS server is implemented within the VVoIP system, the DNS STIG must be applied to the server.

b

The VVoIP system time is not properly implemented and/or synched with the LAN’s NTP servers.

Medium - V-21523 - SV-23735r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 5250 (LAN)

Vuln IDs

V-21523

Rule IDs

SV-23735r1_rule

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 OfficerDCBP-1

Checks: C-25782r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure the VVoIP system’s time is synchronized with or receives its time from the two internal LAN NTP servers that are configured within the LAN management VLAN in accordance with the Network Infrastructure STIG. Further ensure the VVoIP endpoints receive their time from the VVoIP system controller. NOTE: The use and implementation of NTP within the VVoIP system must be implemented in accordance with the Network Infrastructure STIG NTP requirements and policies. This is a finding in the event these conditions are not met. Additionally determine how the endpoints time is synchronized. This is a finding in the event their time is not sourced from the VVoIP system controller via the VVoIP VLANs.

Fix: F-22314r1_fix

Implement NTP usage in the VVoIP system in accordance with the Network Infrastructure STIG policy and requirements. Ensure the VVoIP system’s time is synchronized with or receives its time from the two internal LAN NTP servers that are configured within the LAN management VLAN in accordance with the Network Infrastructure STIG. Further ensure the VVoIP endpoints receive their time from the VVoIP system controller. NOTE: 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.

b

VVoIP endpoint configuration files transferred via Cisco TFTP must be encrypted and signed using DoD PKI certificates.

Medium - V-47735 - SV-60611r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1410 (GENERAL)

Vuln IDs

V-47735

Rule IDs

SV-60611r1_rule

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

Checks: C-50233r2_chk

Interview the IAO to confirm compliance with the following requirement: Verify VVoIP endpoint configuration files transferred via Cisco TFTP are encrypted and signed using DoD PKI certificates. NOTE: This requirement is not applicable to systems that do not use Cisco TFTP.

Fix: F-51371r1_fix

Configure the VVoIP endpoint configuration files transferred via Cisco TFTP to be encrypted and signed using DoD PKI certificates. Refer to the “CISCO-UCM-TFTP” Vulnerability Analysis report provided by the Protocols, Ports, and Services management site for more details.

b

Unencrypted and unsigned VVoIP endpoint configuration files traversing the DISN must be protected within a VPN between enclaves.

Medium - V-47753 - SV-60629r1_rule

RMF Control

Severity

Medium

CCI

Version

VVoIP 1415 (GENERAL)

Vuln IDs

V-47753

Rule IDs

SV-60629r1_rule

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

Checks: C-50235r1_chk

Interview the IAO to confirm compliance with the following requirement: Verify VVoIP endpoint configuration files traversing the DISN must be protected within a VPN secured using FIPS 140-2 or NSA approved encryption between enclaves. The reviewer may downgrade to CAT 3 when vendor provided PKI or x.509 certs are used rather than DoD PKI certificates. NOTE: This requirement is not applicable to systems that use Cisco TFTP.

Fix: F-51379r1_fix

Configure the VVoIP endpoint configuration files traversing the DISN to be protected within a VPN secured using FIPS 140-2 or NSA approved encryption between enclaves.

a

VVoIP system components and UC soft clients must display the Standard Mandatory DoD Notice and Consent Banner exactly as specified prior to logon or initial access.

Low - V-54691 - SV-68937r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1340

Vuln IDs

V-54691

Rule IDs

SV-68937r1_rule

The operating system and remotely accessed information systems are required to display the DoD-approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. System use notification messages must be displayed when individuals log in to the information system. The approved DoD text must be used as specified in the DoD Instruction 8500.01 dated March 14, 2014.ECWM-1

Checks: C-55311r2_chk

Interview the ISSO to validate compliance with the following requirement: Verify all VVoIP system components and UC soft clients display the Standard Mandatory DoD Notice and Consent Banner prior to logon or initial access. If the displayed text is not exactly as specified in the DoD Instruction 8500.01 dated March 14, 2014, this is a finding. The text is posted on the IASE website: http://iase.disa.mil/Documents/unclass-consent_banner.zip

Fix: F-59547r2_fix

Configure all VVoIP system components and UC soft clients to display the Standard Mandatory DoD Notice and Consent Banner prior to logon or initial access.

a

VVoIP system components and UC soft clients Standard Mandatory DoD Notice and Consent Banner must be acknowledged by the user prior to logon or initial access.

Low - V-54693 - SV-68939r1_rule

RMF Control

Severity

Low

CCI

Version

VVoIP 1345

Vuln IDs

V-54693

Rule IDs

SV-68939r1_rule

The operating system and remotely accessed information systems are required to display the DoD-approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. System use notification messages must be displayed when individuals log in to the information system. The approved DoD text must be used as specified in the DoD Instruction 8500.01 dated March 14, 2014.

Checks: C-55313r3_chk

Interview the ISSO to validate compliance with the following requirement: Verify all VVoIP system components and UC soft clients retain the Standard Mandatory DoD Notice and Consent Banner on the screen until acknowledgement of the usage conditions by taking explicit actions to log on for further access.

Fix: F-59549r2_fix

Configure all VVoIP system components and UC soft clients to retain the Standard Mandatory DoD Notice and Consent Banner on the screen until acknowledgement of the usage conditions by taking explicit actions to log on for further access.

Voice/Video Services Policy STIG

Compare

View

Checks: C-23599r1_chk

Fix: F-7706r1_fix

Generate Mitigation Statement:

Checks: C-23703r1_chk

Fix: F-20185r1_fix

Generate Mitigation Statement:

Checks: C-23525r1_chk

Fix: F-20063r1_fix

Generate Mitigation Statement:

Checks: C-23790r1_chk

Fix: F-7710r1_fix

Generate Mitigation Statement:

Checks: C-23791r4_chk

Fix: F-20237r2_fix

Generate Mitigation Statement:

Checks: C-23801r1_chk

Fix: F-7713r1_fix

Generate Mitigation Statement:

Checks: C-23603r1_chk

Fix: F-20122r1_fix

Generate Mitigation Statement:

Checks: C-23615r1_chk

Fix: F-7731r1_fix

Generate Mitigation Statement:

Checks: C-23685r2_chk

Fix: F-20178r2_fix

Generate Mitigation Statement:

Checks: C-23617r1_chk

Fix: F-20134r1_fix

Generate Mitigation Statement:

Checks: C-23621r1_chk

Fix: F-20136r1_fix

Generate Mitigation Statement:

Checks: C-23710r1_chk

Fix: F-20188r1_fix

Generate Mitigation Statement:

Checks: C-23624r1_chk

Fix: F-7739r1_fix

Generate Mitigation Statement:

Checks: C-23596r1_chk

Fix: F-20111r1_fix

Generate Mitigation Statement:

Checks: C-23600r1_chk

Fix: F-20116r1_fix

Generate Mitigation Statement:

Checks: C-23627r1_chk

Fix: F-20141r1_fix

Generate Mitigation Statement:

Checks: C-23793r1_chk

Fix: F-20239r1_fix

Generate Mitigation Statement:

Checks: C-23794r1_chk

Fix: F-20240r1_fix

Generate Mitigation Statement:

Checks: C-23781r1_chk

Fix: F-20217r1_fix

Generate Mitigation Statement:

Checks: C-23809r1_chk

Fix: F-20257r1_fix

Generate Mitigation Statement:

Checks: C-23806r2_chk

Fix: F-20256r2_fix

Generate Mitigation Statement:

Checks: C-23854r1_chk

Fix: F-20286r1_fix

Generate Mitigation Statement:

Checks: C-23858r1_chk

Fix: F-20287r1_fix

Generate Mitigation Statement:

Checks: C-23623r1_chk

Fix: F-20138r1_fix

Generate Mitigation Statement:

Checks: C-17113r1_chk

Fix: F-16175r1_fix

Generate Mitigation Statement:

Checks: C-17115r1_chk

Fix: F-16177r1_fix