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.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-19547	VVoIP 5405 (LAN)	SV-21610r1_rule	EBBD-2 ECSC-1	Medium

Description
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.

Description

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.

STIG	Date
Voice/Video Services Policy STIG	2014-04-07

Details

Check Text ( 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.

Check Text ( 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 Text (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.

Fix Text (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.