VoiceVideo over Internet Protocol (VVoIP) STIG V3R9

b

Unified messaging and email text-to-speech features must be disabled because there is no PKI authentication and no access control to email.

Medium - V-19444 - SV-21495r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1755 (GENERAL)

Vuln IDs

V-19444

Rule IDs

SV-21495r2_rule

Unified messaging and email systems provide the capability to receive voicemails via email and in some cases, have emails read to the user via a text-to-speech feature when accessing the system from a telephone (dial-in). For DoD, this presents two issues or vulnerabilities. Access to voicemail from a telephone only requires the user’s telephone number and a PIN. The telephone number is the account or mailbox number on the voicemail system while the PIN is the user password for accessing the account. This is a rather weak authentication method. The first issue for DoD, is that DoD policy states that access to email requires PKI based authentication of the user before they are granted access to their email account. PKI certificates are required to decrypt encrypted email. PKI authentication is not available when using a standard telephone. While some organizations might implement PKI authenticated access to the site’s phone system, such a facility is not available via most DoD phone systems and certainly not via the PSTN. Additionally, while a non-PKI enabled text-to-speech feature would not be able to read encrypted email (which would be considered the most sensitive) the unencrypted email is still considered sensitive DoD information. The argument could be made that normal voicemail messages and regular telephone conversations can also contain sensitive information. However, there is typically more sensitive information in email. This does not apply to DoD issued PDA/PED devices that provide CAC authenticated access to email. Access to unified mail voicemail would be via PKI authenticated email service through which the user could listen to the voicemail. Text-to-speech conversion would be permitted in this case even though caution should be used when listening to any voicemail, particularly in a public place. The use of a wired earphone is highly recommended. The use of Bluetooth, DECT/DECT 6.0, and other RF wireless technologies for accessories must be approved.Information Assurance OfficerECSC-1

Checks: C-23713r2_chk

Interview the ISSO to validate compliance with the following requirement: In the event an email text-to-speech feature is employed or enabled in a unified messaging and email system, and accessed via the dial-in voicemail access method, ensure DoD PKI authentication is used to access the feature as is required for normal email access control. Otherwise, disable the text-to-speech feature as well as any other dial-up method that does not provide for PKI authentication for accessing email. Determine if the site has implemented a unified mail system where voicemail is delivered via the user’s email mailbox. This will normally imply that email could be available via normal voicemail access from a standard telephone and that the email is read to the user via a text-to-speech conversion feature. Inspect the configuration of the unified messaging and email server to determine if the text-to-speech feature is disabled. Alternately have the ISSO or SA demonstrate compliance with the requirement. If email is accessible via voicemail without PKI authentication, this is a finding. NOTE: Access to the email service must already be in compliance with DoD email access policy using PKI. Therefore, this requirement does not apply to accessing and listening to voicemail via the email service.

Fix: F-20189r2_fix

In the event an email text-to-speech feature is employed or enabled in a unified messaging system, and accessed via the dial-in voicemail access method, ensure PKI based authentication is used to access the feature as is required for normal email access control. Otherwise, disable the text-to-speech feature as well as any other dial-up method that does not provide for PKI authentication for accessing email. Disable the text-to-speech feature of a unified mail service.

b

The LSC permits the registration and operation of VoIP instruments that have not been previously configured and authorized. That is, auto-registration is not disabled if available

Medium - V-19445 - SV-21496r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1510 (GENERAL)

Vuln IDs

V-19445

Rule IDs

SV-21496r1_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 an unauthorized digital instrument 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. Some VoIP systems employ an automatic means of detecting and registering a new instrument on the network with the local session controller (LSC) and then downloading its configuration to the instrument. This feature is called ‘auto-registration’ and can be used to initially connect and test un-configured instruments. 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 instruments, 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, additions, and changes will require manual registration. Since, it may be possible for an unauthorized VoIP instrument 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 instruments that are DAA approved for connection from multiple local or remote locations. The Auto-registration feature provided in some VoIP systems creates various issues. In general, this feature allows any end instrument to function using a default configuration, as soon as it is plugged into the network without prior authorization and configuration by an SA. In general, this feature should never be used even in the limited situations mentioned in the requirement, since the SA loses control of the system. In this situation the SA may not know what phones are on the system, or where they are, and since phone numbers are usually assigned out of a pool, there is no SA control over the phone number assignments. Additionally, since end instruments can work as soon as they are plugged in, they could be used to abuse the phone system. NoneUnauthorized access to network or voice system resources or services and the information they contain. Potential system abuse.Information Assurance Officer

Checks: C-23714r1_chk

Interview the IAO to validate compliance with the following requirement: In the event the LSC provides an auto-registration feature whereby endpoints that have not been previously configured or authorized in the LSC are automatically registered and made functional, ensure that the feature is disabled. Alternately, In the event an instrument that has not been pre-configured in the LSC can register with the LSC, the LSC will only provide the phone with limited capabilities such as the ability to only call the local system operator’s console or another designated number, such as the security office. Calls to emergency services are permitted (and potentially required) in this case. NOTE: It may be desirable to use the alternate approach. NOTE: This does not apply to endpoints that are preconfigured in the LSC and/or in the instrument such that the endpoint is preauthorized. This means that pre-configuration or manual registration of VoIP terminals is used for normal day-to-day operations, troubleshooting and repairs, moves, additions, and changes. NOTE: While it is best practice to not use auto-registration at any time, there may be situations when its use is beneficial during initial system installation and checkout, or during any subsequent large redeployments and additions. In the event the feature is used in these situations, it must be disabled as soon as possible, not to exceed 5 days, and before the system is placed into service.

Fix: F-20190r1_fix

In the event whereby the LSC provides an auto-registration feature whereby endpoints that have not been previously configured or authorized in the LSC are automatically registered and made functional, ensure that the feature is disabled. Alternately, in the event an instrument that has not been pre-configured in the LSC can register with the LSC, the LSC will only provide the phone with limited capabilities such as the ability to only call the local system operator’s console, or other designated number such as the security office. Calls to emergency services are permitted (and potentially required) in this case. NOTE: It may be desirable to use the alternate approach. NOTE: This does not apply to endpoints that are preconfigured in the LSC and/or in the instrument such that the endpoint is preauthorized. This means that pre-configuration or manual registration of VoIP terminals is used for normal day-to-day operations, troubleshooting and repairs, moves, additions, and changes. NOTE: While it is best practice to not use auto-registration at any time, there may be situations when its use is beneficial during initial system installation and checkout or during any subsequent large redeployments or additions. In the event the feature is used in these situations, it must be disabled as soon as possible, not to exceed 5 days and before the system is placed into service. Disable the auto-registration feature on the LSC except as required for initial system deployment and checkout. In the event auto-registration is used initially, the log or report of authorized instruments from the LSC must be compared to the separate inventory of authorized instruments to detect any unauthorized or rogue instruments that may be connected to the network so that they can be found and removed.

b

UN-authorized VVoIP instruments are registered with the LSC and are operational

Medium - V-19446 - SV-21497r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1515 (GENERAL)

Vuln IDs

V-19446

Rule IDs

SV-21497r1_rule

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 abuse.NoneUnauthorized use or abuse of the systemInformation Assurance Officer

Checks: C-23716r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure the VVoIP system only registers pre-authorized (e.g., pre-configured) instruments or endpoints. NOTE: During auto-registration, This can be through an automated authorization process if available or by comparing the registration logs to the required and documented inventory of authorized instruments following any usage of auto-registration. NOTE: Preauthorization occurs when the endpoint is pre-configured or provisioned in the LSC. The endpoint may also require pre-configuration or authorization prior to, or during deployment. This is a finding if there are instruments registered with the LSC that are not authorized and/or that do not appear on the required inventory of authorized instruments.

Fix: F-20191r1_fix

Configure the system to only register authorized VVoIP instruments.

b

An Auto-answer feature is not properly disabled.

Medium - V-19624 - SV-21765r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP/VTC 1740 (GENERAL)

Vuln IDs

V-19624

Rule IDs

SV-21765r1_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 Officer

Checks: C-23917r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure auto-answer capabilities of any voice, video, VTC, UC, or collaboration applications are disabled in the event the application provides audio or video communications services such that the microphone and/or camera could be activated automatically when an incoming call is received. Note: This does not apply to text based communications such as IM that does not activate a microphone or camera. Have the IAO or SA demonstrate the operation of the PC communications client applications on PCs in the organization, to determine how they function with regard to the “auto-answer” feature, how the feature is configured, and if it is a user configurable setting. Inspect a random sample of PCs to determine if communication apps are configured in compliance. Place calls to all or minimally a random sample of PCs to determine if any of them automatically answers the call. Inspect SOPs and training materials to determine if this mitigation requirement is disseminated to users. Interview a random sampling of users to determine if they are properly trained on this topic. This is a finding if any PC application automatically answers a call, or if the application is configured to allow auto-answer, or if the application cannot be configured to disable auto-answer. If this feature/capability is user configurable, this is a finding in the event SOPs and training materials do not address the auto-answer feature such that it is not used. Additionally, this is a finding if users are unaware of the related training. This is not a finding if by default the application does not automatically answer calls and such a feature cannot be activated.

Fix: F-20328r1_fix

Ensure auto-answer capabilities of any voice, video, VTC, UC, or collaboration applications are disabled in the event the application provides audio or video communications services such that the microphone and/or camera could be activated automatically when an incoming call is received. Note: This does not apply to text based communications such as IM that does not activate a microphone or camera. If a PC communications client application provides an auto-answer feature/function configure the application to disable the feature. OR If the auto-answer feature/function is user configurable, develop an SOP and training materials and train users to not activate the feature. Enforce the SOP by randomly checking their compliance. OR If a PC communications client application provides an auto-answer feature/function that cannot be disabled, replace the application with one that does not have the feature or one that can be configured to disable it.

b

PC presentation or application sharing capabilities are not properly limited.

Medium - V-19625 - SV-21766r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1725 (GENERAL)

Vuln IDs

V-19625

Rule IDs

SV-21766r1_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 it creates 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 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 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. NONECompromise of the host PC and the information it contains or can reach through the network.Information Assurance Officer

Checks: C-23918r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC based collaboration application sharing and remote control features or capabilities do not provide unrestricted access to other (i.e., non-shared) applications, the local hard drive(s), or other drives accessible through the network. In other words, the collaboration application will not provide, or will be configured to not provide, full remote control of the host (i.e., shared) PC. Sharing capabilities will be limited to the collaboration application and other applications or documents (e.g., document based applications and documents launched by the host PC user) specifically shared by the host PC user. Inspect or have a SA demonstrate the configuration and capabilities of the collaboration tool with respect to its sharing capabilities. This is a finding if the following is not met: > PC based collaboration application sharing and remote control features or capabilities will not provide unrestricted access to other (i.e., non shared) applications, the local hard drive(s), or other drives accessible through the network. For example, the collaboration application will not provide, or will be configured to not provide, full remote control of the host (i.e., shared) PC. > Sharing capabilities will be limited to the collaboration application, and other applications or documents specifically shared by the host PC user. (e.g., document based applications and documents launched by the host PC user)

Fix: F-20329r1_fix

Ensure PC based collaboration application sharing and remote control features or capabilities do not provide unrestricted access to other (i.e., non-shared) applications, the local hard drive(s), or other drives accessible through the network. In other words, the collaboration application will not provide, or will be configured to not provide, full remote control of the host (i.e., shared) PC. Sharing capabilities will be limited to the collaboration application and other applications or documents (e.g., document based applications and documents launched by the host PC user) specifically shared by the host PC user. Configure PC collaboration applications of all forms to not provide full remote control access to the host PC. Limit access to the applications relevant to the collaboration session or the video display. Train users in proper operation of the sharing capabilities. If necessary, limit or deny access to collaboration applications that do not or cannot be configured to not provide full PC remote control as described above.

b

A PC Collaboration application does not identify all connected parties.

Medium - V-19626 - SV-21767r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1730 (GENERAL)

Vuln IDs

V-19626

Rule IDs

SV-21767r1_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 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 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. It is also imperative that a collaboration session participant know with whom he/she is communicating and sharing information and/or to whom they might give remote control access to their PC or shared application. This is so that the communicating individuals can have a trust relationship before sharing occurs. NoneThe inadvertent or improper disclosure of sensitive or classified information. Information Assurance Officer

Checks: C-23919r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure PC based collaboration applications identify all connected parties whether on a two party call or in a multiparty conference. Have the IAO or SA demonstrate that the PC based collaboration application identifies all connected parties such that a user can identify with whom information is shared or to whom application control is given.

Fix: F-20330r1_fix

Ensure PC based collaboration applications identify all connected parties whether on a two party call or in a multiparty conference. Configure the collaboration application to display the identity of all parties engaged in a session or use one that can be configured to do so.

b

Remote access VoIP must be routed to the VoIP VLAN.

Medium - V-19627 - SV-21768r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1800 (REMOTE)

Vuln IDs

V-19627

Rule IDs

SV-21768r2_rule

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

Checks: C-23920r2_chk

Interview the ISSO to validate compliance with the following requirement: Ensure traffic from a Unified Capabilities (UC) soft client, operated in a remote access scenario and using an encrypted VPN as required, is routed to the VoIP VLAN such that the separation of the voice and data zones is not degraded while all other traffic is routed to the data zone. Inspect network diagrams to determine if the boundary and remote access VLAN architecture properly routes VoIP traffic from the VPN to the voice VLANs while maintaining proper flow control and access between the data VLANs and the voice VLANs. If the boundary and remote access VLAN architecture does not properly route VoIP traffic from the VPN to the voice VLANs while maintaining proper flow control and access between the data VLANs and the voice VLANs, this is a finding.

Fix: F-20331r2_fix

Ensure traffic from a Unified Capabilities (UC) soft client, operated in a remote access scenario and using an encrypted VPN as required, is routed to the VoIP VLAN such that the separation of the voice and data zones is not degraded while all other traffic is routed to the data zone. Configure the enclave boundary and remote access VLAN architecture to properly route VoIP traffic from the VPN to the voice VLANs and maintain proper flow control and access between the data VLANs and the voice VLANs.

b

VVoIP component(s) are NOT addressed using the defined dedicated VVoIP system addresses

Medium - V-19628 - SV-21769r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5225 (LAN)

Vuln IDs

V-19628

Rule IDs

SV-21769r1_rule

The protection of the VVoIP system is enhanced by ensuring all VVoIP systems and components within the LAN (Enclave) are deployed using separate address blocks from the normal data address blocks. This is one of the required steps required to help protect the VVoIP infrastructure and services by allowing traffic and access control via firewalls and router ACLs. 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 Officer

Checks: C-23948r1_chk

Ensure all VVoIP systems and components within the LAN (Enclave) are deployed using the dedicated VVoIP address space defined in the VVoIP system design for the given network type. Inspect the VVoIP core equipment components (endpoints checked separately) to determine if they are addressed using the dedicated VVoIP address space defined in the VVoIP system design for the given network type. 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

Fix: F-20332r1_fix

Ensure all VVoIP systems and components within the LAN (Enclave) are deployed using the using the dedicated VVoIP address space defined in the VVoIP system design for the given network type. NOTE: This is applicable to the following: > A closed unclassified LAN > A unclassified LAN connected to a 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. Provide or use a dedicated address space for the VVoIP system that is segregated from the address space used for the general LAN, management VLANs, and other segregated services running on the LAN. Use this address space when configuring VVoIP VLANs and when assigning addresses to VVoIP endpoints and core equipment.

b

VVoIP core components use random address assignment via DHCP and are not statically addressed

Medium - V-19629 - SV-21770r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5230 (LAN)

Vuln IDs

V-19629

Rule IDs

SV-21770r1_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. NOTE: In the event DHCP is used for address assignment, ensure the DHCP server assigns the same address to the core VVoIP device each time one is requested.NoneThe inability to properly control traffic to/from and access to the VVoIP system core devices resulting in unauthorized access or denial of serviceInformation Assurance Officer

Checks: C-23951r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the VVoIP core components are statically addressed.

Fix: F-20333r1_fix

Ensure the VVoIP core components are statically addressed and do not use DHCP to obtain a randomly assigned address Do not use DHCP to assign IP addresses to V-VoIP core devices; Configure each device with a specific IP address OR If DHCP must be used, configure the DHCP server to provide the same IP address to each specific VVoIP system core device when requested

b

VVoIP endpoints must receive IP address assignment and configuration information from a DHCP server dedicated to the VVoIP system.

Medium - V-19630 - SV-21771r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5235 (LAN)

Vuln IDs

V-19630

Rule IDs

SV-21771r2_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. Optimally, the design would place a DHCP server dedicated to providing IP address and configuration information to the VVoIP endpoints separate from the IP address and configuration information to data hosts (workstations etc.). The DHCP server providing VVoIP devices should be in the V_VUC domain having the same address space and VLAN to prevent DHCP requests routed onto the data environment that degrade the separation of the VVoIP environment and the data environment. With centralized management of DHCP (and other services, such as DNS) this separation is obviously eliminated. DHCP requests and responses for voice must reside on a segregated VLAN. The best practice is to manually assign addresses when authorizing the instrument by generating its configuration file. 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).Information Assurance Officer

Checks: C-23954r2_chk

Interview the IAO to confirm compliance with the following requirement: For VVoIP system designed to use DHCP for VVoIP initial endpoint address assignment/configuration, Ensure the following: - The DHCP server provides addresses from the segregated VVoIP address space and associated configuration information to VVoIP endpoints exclusively. - In the event the DHCP server is not dedicated to VVoIP, ensure it does not provide data addresses and configuration information to the VVoIP endpoints and conversely does not provide VVoIP addresses and configuration information to the data endpoints (hosts or workstations). - In the event the DHCP server is not dedicated to VVoIP, ensure the DHCP server and associated network routing prevents traffic to flow between the VVoIP VLANs and data VLANs. Review VVoIP network design to determine the IP address the of VVoIP DHCP server. Alternately, determine the VLAN tag the VVoIP DHCP server uses or responds to or inspect the Ethernet port configuration of the LAN network equipment connected to the DHCP server to determine the VLAN assigned to the port. If the DHCP server’s IP address is not within the designated VVoIP VLAN structure or IP address range, this is a finding. Inspect the configuration of all DHCP servers within the enclave to determine their address scope(s), and placement within the network for the VVoIP, data, or other VLANs. If the DHCP server providing address and network configuration information to data components or hosts and also provides this information to VVoIP endpoints or other system components, this is a finding. Conversely, if a DHCP server providing address and network configuration information to VVoIP endpoints also provides VVoIP addresses and information to data components, hosts, or other non-VVoIP system components, this is a finding. NOTE: dedicated hardware IP-VTC endpoints that are integrated with the VVoIP system, (i.e., they establish calls/sessions by signaling with the VVoIP LSC) may utilize the services of the VVoIP DHCP server because they may reside in the VVoIP system of VLANs. Dedicated hardware IP-VTC endpoints that are not associated with the LSC are required to reside in their own system of VLANs and therefore should have their own DHCP server or, better yet, be statically addressed.

Fix: F-20334r2_fix

Configure the DHCP server supporting VVoIP endpoints to have different DHCP scopes used for VVoIP components, data components, and independent IP-VTC endpoints. Ensure these servers reside in their respective voice, VTC, or data address space and VLANs and the VVoIP endpoints (or independent IP-VTC endpoints) only receive address/configuration information from the DHCP server dedicated to them. Alternately, if a dedicated DHCP server is not implemented, ensure the DHCP server provides addresses from the segregated VVoIP address space and associated configuration information to VVoIP endpoints exclusively; ensure it does not provide data addresses and configuration information to the VVoIP endpoints and conversely does not provide VVoIP addresses and configuration information to the data endpoints (hosts or workstations); and ensure the DHCP server and associated network routing prevents traffic to flow between the VVoIP VLANs and data VLANs. NOTE: Dedicated hardware IP-VTC endpoints that are integrated with the VVoIP system, (i.e., they establish calls/sessions by signaling with the VVoIP LSC) may utilize the services of the VVoIP DHCP server because they may reside in the VVoIP system of VLANs. Dedicated hardware IP-VTC endpoints that are not associated with the LSC are required to reside in their own system of VLANs and therefore should have their own DHCP server or, better yet, be statically addressed.

b

A VVoIP core system/device or a traditional TDM based telecom switch is acting as a network router in that it does not block traffic between its attached management network interfaces(s) (one or more; logical or physical) and/or its production network interface(s) (logical or physical).

Medium - V-19631 - SV-21772r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5400 (LAN)

Vuln IDs

V-19631

Rule IDs

SV-21772r1_rule

Based on a previously stated requirement, a VVoIP system must have one or more production VLANs containing the VVoIP endpoints and a separate OOB management network or virtual management network (management VLAN). Also previously stated is the requirement that the LAN NEs maintain the separation between management network(s) and the production network VLANs by blocking traffic from passing between them. Maintaining this separation is also incumbent upon the managed devices that are connected to both the management and production VLANs. Individual VVoIP system core devices and traditional TDM based telecom switches connect to their production and management networks or VLANs in different ways. In some cases there are separate dedicated physical management and production interfaces. There may also be one or more physically separate management interfaces. On the other hand these interfaces may be logical or there may be some combination of logical and physical interfaces that support the required production and management traffic. In the event production and management connections use separate interfaces, whether logical or physical, the target/ managed device must not permit one network (physical or logical VLAN) to access another network through the device. That is, the device must not route IP traffic between logical or physical interfaces connected to different VLANs or physical networks that are part of a different logical security zone (protected VLAN) or physical network enclave. Permitting such routing permit a host on one network or VLAN to gain unauthorized access to a host on another network which can lead to complete corruption of the accessed system or device causing the, loss of availability (denial-of-service), integrity, and information or communications confidentiality. NOTE: While this specifically addresses a similar situation addressed in the Network Infrastructure STIG that essentially requires that the production side of a managed device must not be accessible from the management interface and vise versa, this requirement extends that requirement to multiple management interfaces. Many DSN switches and DISN IPVS system core devices are managed from the BCPS network and CCSA NOC via one interface and also monitored and potentially managed by the DISA ADIMSS or other NOC. These are separate enclaves which must be protected from inappropriate access between them. In some cases the connections from these enclaves to the managed devices are via separate interfaces on the managed devices. Ergo the requirement the managed device must not pass traffic between these interfaces. 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 Officer

Checks: C-23955r1_chk

Interview the IAO to confirm compliance with the following requirement: In the event a VVoIP core device or a traditional TDM circuit switch supports multiple management interfaces that are separate from the production interfaces (as required), ensure the device does not permit traffic to flow between these interfaces. This is a finding in the event any of the three domains can be reached and therefore potentially compromised from any of the others. NOTE: While this specifically addresses a similar situation found in the Network Infrastructure STIG, essentially it requires that the production side of a managed device must not be accessible from the management interface and vise versa, this requirement extends that requirement to multiple management interfaces. Many DSN switches and DISN IPVS system core devices are managed from the BCPS network and CCSA NOC via one interface and also monitored and potentially managed by the DISA ADIMSS or other NOC. These are separate enclaves which must be protected from inappropriate access between them. In some cases the connections from these enclaves to the managed devices are via separate interfaces on the managed devices. Ergo the requirement the managed device must not pass traffic between these interfaces.

Fix: F-20335r1_fix

Configure VVoIP core system/devices and traditional TDM based telecom switches to comply with the following: In the event a target system/device supports separate IP based production and management interfaces (logical or physical), or multiple management interfaces (logical or physical), connected to different networks or VLANs, ensure the target system/device does not rout IP traffic between the networks or VLANs attached / connected to these interfaces. NOTE: this also applies to traditional TDM based telecom switches that are managed via IP networks that connect to the switch via different ports no matter the type of connection (Ethernet or serial). The purpose of this requirement is to ensure that other devices connected to one side of the target device cannot be accessed or compromised through the target device via one of its other interfaces. Configure the target system/device to NOT route between multiple attached management networks and/or its production network whether physically different or only logically different by being connected to different VLANs. NOTE: While this specifically addresses a similar situation addressed in the Network Infrastructure STIG that essentially requires that the production side of a managed device must not be accessible from the management interface and vise versa, this requirement extends that requirement to multiple management interfaces. Many DSN switches and DISN IPVS system core devices are managed from the BCPS network and CCSA NOC via one interface and also monitored and potentially managed by the DISA ADIMSS or other NOC. These are separate enclaves which must be protected from inappropriate access between them. In some cases the connections from these enclaves to the managed devices are via separate interfaces on the managed devices. Ergo the requirement the managed device must not pass traffic between these interfaces.

b

Logical or physical interfaces must be configured on the VVoIP core routing devices for the VVoIP core equipment to support access and traffic control for the VVoIP system components.

Medium - V-19632 - SV-21773r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5520 (LAN)

Vuln IDs

V-19632

Rule IDs

SV-21773r2_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.Information Assurance OfficerECSC-1

Checks: C-23958r2_chk

Inspect the configurations of the VVoIP core routing devices to determine compliance with the following requirement: Ensure logical or physical interfaces (VLAN/subnets or direct connect physical interfaces with discrete subnets) are configured on the VVoIP core routing devices for the VVoIP core equipment as follows: - 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 (SBC or other). - Voicemail and Unified Messaging Servers, which may need to be accessible from both the voice and data VLANs. - UC servers supporting presence, web browser based conferencing, and directory services. These may need to be accessible from both the voice and data VLANs. Alternately, ensure the VVoIP core equipment employs direct connections with discrete subnets to the VVoIP core routing devices so that the ACLs may be implemented on the physical interface to the device instead of the logical interface to the VLAN. NOTE: If the device for which a VLAN/subnet is designated does not exist in the system, the VLAN is not required. These devices may be the core routing devices for the data LAN as well. If the logical or physical interfaces with discrete subnets have not been implemented against which the ACLs can be applied, this is a finding.

Fix: F-20336r2_fix

Ensure logical or physical interfaces (VLAN/subnets or direct connect physical interfaces with discrete subnets) are established/configured on the VVoIP core routing devices for the VVoIP core equipment as follows: - 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 (SBC or other). - Voicemail and Unified Messaging Servers, which may need to be accessible from both the voice and data VLANs. - UC servers supporting presence, web browser based conferencing, and directory services. These may need to be accessible from both the voice and data VLANs. Alternately, ensure the VVoIP core equipment employs direct connections with discrete subnets to the VVoIP core routing devices so that the ACLs may be implemented on the physical interface to the device instead of the logical interface to the VLAN. NOTE: If the device for which a VLAN/subnet is designated does not exist in the system, the VLAN is not required. These devices may be the core routing devices for the data LAN as well.

b

VVoIP VLANs must be implemented on this VVoIP hardware endpoints.

Medium - V-19633 - SV-21774r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5525 (LAN)

Vuln IDs

V-19633

Rule IDs

SV-21774r2_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. Information Assurance OfficerECSC-1

Checks: C-23959r2_chk

Inspect the configurations of the LAN devices supporting VVoIP hardware endpoints or their traffic to determine compliance with the following requirement: In the event the device supports VVoIP endpoints directly or indirectly, ensure the following VLANs are established and configured on this device. For hardware endpoints, confirm multiple VLANs generally in parallel with data LAN VLANs the number of which is dependent 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. If VVoIP VLANs are not implemented on VVoIP hardware endpoints, this is a finding.

Fix: F-20337r2_fix

In the event the device supports VVoIP hardware endpoints directly or indirectly, ensure the following VLANs are established and configured on this device. For hardware endpoints, configure multiple VLANs generally in parallel with data LAN VLANs the number of which is dependent 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.

b

VLANs established for the VVoIP system are NOT pruned from trunks and/or interfaces that are not required to carry the VVoIP traffic

Medium - V-19634 - SV-21775r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5530 (LAN)

Vuln IDs

V-19634

Rule IDs

SV-21775r1_rule

While VLANs facilitate access and traffic control for the VVoIP system components and enhanced QoS, they should only be implemented on the network elements that are needed to carry the traffic from the attached devices. LAN switches will typically learn the VLANs configured on an adjacent switch and configure it locally. As such a VLAN configured on one switch can be learned and configured on the entire LAN in a very short period of time. Too many learned VLANs and a NE can crash. Additionally, a VLAN that appears on NEs where it is not required to carry traffic, places the VLAN at risk of compromise by presenting many more points at which the VLAN might be accessed. Therefore the VLANs must be pruned from trunks and interfaces where the VLAN does not need to send traffic. A VLAN that supports a number of local VVoIP endpoints only needs to traverse the NEs in two paths to the core routing devices at the VVoIP core equipment, Any specific endpoint VLAN does not need to appear on every switch in the LAN unless it serves endpoints everywhere on the LAN. Likewise the VVoIP core equipment VLANs do not need to extend past the VVoIP core routing devices (routers or layer 3 switches. The endpoint VLANs come to the core, the core VLANs do not extend to the endpoints. As such all VLANs must be pruned from any trunk where its traffic does not need to go. 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-23960r1_chk

Inspect the configurations of the LAN devices supporting the VVoIP system on which the required VLANs are configured to determine compliance with the following requirement: Ensure VLANs established for the VVoIP system are pruned from trunks and/or interfaces that are not required to carry the traffic as follows: > VVoIP core equipment VLANs will not extend past the core routing devices that support the core equipment. These VLANs should not appear on distribution or access layer NEs in the LAN. > VVoIP endpoint VLANs established on access layer switches shall only appear on a primary uplink and a backup in addition to the access ports that are assigned to the local VVoIP VLAN. > VVoIP endpoint VLANs established on distribution layer switches shall only appear on a primary uplink and a backup that leads toward a routing device. If the distribution layer switch is a routing device, there may be other endpoint VLANs present and available for routing or a local VLAN may traverse a horizontal link if available to another distribution layer NE for routing. Typically however this routing should occur on the core routing devices rather than traversing horizontal links to be routed.

Fix: F-20338r1_fix

Ensure VLANs established for the VVoIP system are pruned from trunks and/or interfaces that are not required to carry the traffic as follows: > VVoIP core equipment VLANs will not extend past the core routing devices that support the core equipment. These VLANs should not appear on distribution or access layer NEs in the LAN. > VVoIP endpoint VLANs established on access layer switches shall only appear on a primary uplink and a backup in addition to the access ports that are assigned to the local VVoIP VLAN. > VVoIP endpoint VLANs established on distribution layer switches shall only appear on a primary uplink and a backup that leads toward a routing device. If the distribution layer switch is a routing device, there may be other endpoint VLANs present and available for routing or a local VLAN may traverse a horizontal link if available to another distribution layer NE for routing. Typically however this routing should occur on the core routing devices rather than traversing horizontal links to be routed.

b

A deny-by-default ACL for VVoIP endpoint VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design.

Medium - V-19635 - SV-21776r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5600

Vuln IDs

V-19635

Rule IDs

SV-21776r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.Information Assurance Officer

Checks: C-23961r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for VVoIP endpoint VLAN interfaces is implemented on VVoIP core routing devices. Ensure a deny-by-default ACL is implemented on all VVoIP endpoint (hardware and software) VLAN interfaces at the VVoIP core routing device to control traffic as follows: - Endpoint configuration and registration - Permit (only as required for proper functionality) the specific system required endpoint registration / configuration protocols/traffic (e.g., DHCP, BootP, TFTP, FTP, HTTP, DNS, etc.) to/from the core control equipment VLAN interfaces (VLAN/subnet). - Endpoint Signaling - Permit (only as required for proper functionality) the specific system required endpoint signaling protocols/traffic (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the core control equipment VLAN interfaces (VLAN/subnets). - Endpoint Directory - Permit (only as required for proper functionality) the specific system required endpoint directory access protocols (e.g., HTTP and/or potentially others) to/from the core control equipment VLAN interfaces. - Endpoint Media - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the Media Gateway VLAN interfaces (VLAN/subnets). - Endpoint Media - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the Voicemail/Unified Messaging VLAN interfaces (VLAN/subnets). - Endpoint Media - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from other endpoint VLAN interfaces (VLAN/subnets) wherever they intersect. - Deny all other traffic. End the ACL with a “deny all” statement. If a deny-by-default ACL for VVoIP endpoint VLAN interfaces is not implemented on VVoIP core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20339r2_fix

Implement and document a deny-by-default ACL for VVoIP endpoint VLAN interfaces on VVoIP core routing devices as defined in the VVoIP system ACL design as follows: - Endpoint configuration and registration - Permit (only as required for proper functionality) the specific system required endpoint registration / configuration protocols/traffic (e.g., DHCP, BootP, TFTP, FTP, HTTP, DNS, etc.) to/from the core control equipment VLAN interfaces (VLAN/subnet). - Endpoint Signaling - Permit (only as required for proper functionality) the specific system required endpoint signaling protocols/traffic (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the core control equipment VLAN interfaces (VLAN/subnets). - Endpoint Directory - Permit (only as required for proper functionality) the specific system required endpoint directory access protocols (e.g., HTTP and/or potentially others) to/from the core control equipment VLAN interfaces. - Endpoint Media - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the Media Gateway VLAN interfaces (VLAN/subnets). - Endpoint Media - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the Voicemail/Unified Messaging VLAN interfaces (VLAN/subnets). - Endpoint Media - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from other endpoint VLAN interfaces (VLAN/subnets) wherever they intersect. - Deny all other traffic. End the ACL with a “deny all” statement.

b

A deny-by-default ACL for all VVoIP endpoint VLAN interfaces must be implemented on VVoIP non-core routing devices as defined in the VVoIP system ACL design.

Medium - V-19636 - SV-21777r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5605

Vuln IDs

V-19636

Rule IDs

SV-21777r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.Information Assurance Officer

Checks: C-23964r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for all VVoIP endpoint VLAN interfaces is implemented on VVoIP non-core routing devices. Ensure a deny-by-default ACL is implemented on all VVoIP endpoint (hardware and software) VLAN interfaces on the VVoIP routing devices throughout the LAN that do not support the VVoIP system core equipment directly to control traffic as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from other endpoint VLAN interfaces (VLAN/subnets) wherever they intersect. - Deny all other traffic. End the ACL with a “deny all” statement. If a deny-by-default ACL for all VVoIP endpoint VLAN interfaces is not implemented on VVoIP non-core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20340r2_fix

Implement and document a deny-by-default ACL for all VVoIP endpoint VLAN interfaces on VVoIP non-core routing devices as defined in the VVoIP system ACL design as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from other endpoint VLAN interfaces (VLAN/subnets) wherever they intersect. - Deny all other traffic. End the ACL with a “deny all” statement. All other EI traffic at this level in the network remains confined to the VLAN and is passed to the routing device that manages EI access to the VVoIP core equipment/infrastructure. The purpose of permitting media traffic to be routed between VVoIP EI VLANs at this level is to reduce the loading of the core routing device and LAN NEs in between. This also enhances QoS within the LAN itself.

b

A deny-by-default ACL for session manager VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design.

Medium - V-19637 - SV-21778r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5610

Vuln IDs

V-19637

Rule IDs

SV-21778r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 send an alarm in response to inappropriate traffic and log the occurrence. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.Information Assurance Officer

Checks: C-23967r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for session manager VLAN interfaces is implemented on VVoIP core routing devices. Ensure a deny-by-default ACL is implemented on the VVoIP session manager VLAN interfaces on the VVoIP routing devices supporting the VVoIP system core equipment to control traffic as follows: - Endpoint configuration - Permit (only as required for proper functionality) the specific system required endpoint registration / configuration protocols/traffic (e.g., DHCP, BootP, TFTP, FTP, HTTP, DNS, etc.) to/from the endpoint VLAN interfaces (VLAN/subnets). - Endpoint signaling - Permit (only as required for proper functionality) the specific system required endpoint signaling protocols/traffic (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the endpoint VLAN interfaces (VLAN/subnets). - Endpoint directory - Permit (only as required for proper functionality) the specific system required endpoint directory access protocols (e.g., HTTP and/or potentially others) to/from the endpoint VLAN interfaces. - Media gateway - Permit (only as required for proper functionality) the specific system required signaling protocols used by the media gateway (e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP media gateway VLAN interfaces (VLAN/subnets). - Signaling gateway - Permit (only as required for proper functionality and the VLAN exists) the specific system required signaling protocols used by the signaling gateway (e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP signaling gateway VLAN interfaces (VLAN/subnets) - Session border controller - Permit (only as required for proper functionality and the VLAN exists) the specific signaling protocols used by the Edge Boundary Controller (AS-SIP) to/from the VVoIP session border controller VLAN interfaces (VLANs / subnet). - Customer edge router - Permit (only as required for proper functionality) the specific signaling or management protocols used to communicate with the Customer Edge (Premises / enclave perimeter) Router for NETOPS etc. (e.g., SNMP and potentially others) to/from the VVoIP data mgmt VLAN interfaces, OOB management LAN, or data network VLAN interfaces (VLANs / subnet) via data mgmt VLAN, OOB management LAN, or data network. - Voicemail/Unified messaging - Permit the specific signaling protocols used by the Voicemail/Unified Messaging servers (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the VVoIP Voicemail or Unified Messaging server VLAN interfaces (VLANs / subnet). - Unified capabilities - Permit (only as required for proper functionality and the VLAN exists) the specific signaling protocols used by any unified communications servers (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the VVoIP UC server VLAN interfaces (VLANs / subnet). - Permit Media protocols (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces, media gateway VLAN interfaces, and voicemail/unified messaging VLAN interfaces (VLAN/subnets). (Call control equipment does not typically process media therefore there is typically no need to permit this traffic and thereby provide a potential attack vector.) - Permit only those other protocols/traffic between specific VLANs, subnets, and devices as required for the system to properly function. - Deny all other traffic. End the ACL with a “deny all” statement. NOTE: The ACLs must mirror the ACLs imposed for access to/from each of the mating VLANs based on the protocols that VLAN accepts. If a deny-by-default ACL for session manager VLAN interfaces is not implemented on VVoIP core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20341r2_fix

Implement and document a deny-by-default ACL for session manager VLAN interfaces on VVoIP core routing devices as defined in the VVoIP system ACL design as follows: - Endpoint configuration - Permit (only as required for proper functionality) the specific system required endpoint registration / configuration protocols/traffic (e.g., DHCP, BootP, TFTP, FTP, HTTP, DNS, etc.) to/from the endpoint VLAN interfaces (VLAN/subnets). - Endpoint signaling - Permit (only as required for proper functionality) the specific system required endpoint signaling protocols/traffic (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the endpoint VLAN interfaces (VLAN/subnets). - Endpoint directory - Permit (only as required for proper functionality) the specific system required endpoint directory access protocols (e.g., HTTP and/or potentially others) to/from the endpoint VLAN interfaces. - Media gateway - Permit (only as required for proper functionality) the specific system required signaling protocols used by the media gateway (e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP media gateway VLAN interfaces (VLAN/subnets). - Signaling gateway - Permit (only as required for proper functionality and the VLAN exists) the specific system required signaling protocols used by the signaling gateway (e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP signaling gateway VLAN interfaces (VLAN/subnets) - Session border controller - Permit (only as required for proper functionality and the VLAN exists) the specific signaling protocols used by the Edge Boundary Controller (AS-SIP) to/from the VVoIP session border controller VLAN interfaces (VLANs / subnet). - Customer edge router - Permit (only as required for proper functionality) the specific signaling or management protocols used to communicate with the Customer Edge (Premises / enclave perimeter) Router for NETOPS etc. (e.g., SNMP and potentially others) to/from the VVoIP data mgmt VLAN interfaces, OOB management LAN, or data network VLAN interfaces (VLANs / subnet) via data mgmt VLAN, OOB management LAN, or data network. - Unified messaging - Permit the specific signaling protocols used by the Voicemail/Unified Messaging servers (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the VVoIP Voicemail or Unified Messaging server VLAN interfaces (VLANs / subnet). - Unified capabilities - Permit (only as required for proper functionality and the VLAN exists) the specific signaling protocols used by any unified communications servers (e.g., AS-SIP, H.323, vendor proprietary such as SCCP, UniStim, etc.) to/from the VVoIP UC server VLAN interfaces (VLANs / subnet). - Permit Media protocols (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces, media gateway VLAN interfaces, and voicemail/unified messaging VLAN interfaces (VLAN/subnets). (Call control equipment does not typically process media therefore there is typically no need to permit this traffic and thereby provide a potential attack vector.) - Permit only those other protocols/traffic between specific VLANs, subnets, and devices as required for the system to properly function. - Deny all other traffic. End the ACL with a “deny all” statement.

b

A deny-by-default ACL for media gateway VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design.

Medium - V-19638 - SV-21779r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5615

Vuln IDs

V-19638

Rule IDs

SV-21779r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.Information Assurance Officer

Checks: C-23970r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for media gateway VLAN interfaces is implemented on VVoIP core routing devices. Ensure a deny-by-default ACL is implemented on the VVoIP Media Gateway (MG) VLAN interfaces on the VVoIP routing devices supporting the VVoIP system core equipment to control traffic as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets). - Permit (only as required for proper functionality) the specific system required signaling protocols used by the media gateway ((e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement. If a deny-by-default ACL for media gateway VLAN interfaces is not implemented on VVoIP core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20342r2_fix

Implement and document a deny-by-default ACL for media gateway VLAN interfaces on VVoIP core routing devices as defined in the VVoIP system ACL design as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets) - Permit (only as required for proper functionality) the specific system required signaling protocols used by the media gateway ((e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement.

b

A deny-by-default ACL for signaling gateway VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design.

Medium - V-19639 - SV-21780r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5620

Vuln IDs

V-19639

Rule IDs

SV-21780r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.Information Assurance Officer

Checks: C-23973r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for signaling gateway VLAN interfaces is implemented on VVoIP core routing devices. Ensure a deny-by-default ACL is implemented on the VVoIP Signaling Gateway (SG) VLAN interfaces on the VVoIP routing devices supporting the VVoIP system core equipment to control traffic as follows: - Permit (only as required for proper functionality) the specific system required signaling protocols used by the Signaling Gateway ((e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement. If a deny-by-default ACL for signaling gateway VLAN interfaces is not implemented on VVoIP core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20343r2_fix

Implement and document a deny-by-default ACL for signaling gateway VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design as follows: - Permit (only as required for proper functionality) the specific system required signaling protocols used by the Signaling Gateway (e.g., MGCP, H.248, H.323, AS-SIP) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets) - Deny all other traffic. End the ACL with a “deny all” statement.

b

A deny-by-default ACL for session border VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design.

Medium - V-19640 - SV-21781r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5625

Vuln IDs

V-19640

Rule IDs

SV-21781r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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 .Information Assurance Officer

Checks: C-23976r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for session border VLAN interfaces is implemented on VVoIP core routing devices. Ensure a deny-by-default ACL is implemented on the VVoIP session border controller VLAN or firewall VLAN interfaces on the VVoIP routing devices supporting the VVoIP system core equipment to control traffic as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets). - Permit (only as required for proper functionality) the specific system required signaling protocols used by the session manager ((e.g., H.323, SIP, AS-SIP) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement. If a deny-by-default ACL for session border VLAN interfaces is not implemented on VVoIP core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20344r2_fix

Implement and document a deny-by-default ACL for session border VLAN interfaces on VVoIP core routing devices as defined in the VVoIP system ACL design as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets). - Permit (only as required for proper functionality) the specific system required signaling protocols used by the session manager ((e.g., H.323, SIP, AS-SIP) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement.

b

A deny-by-default ACL for voicemail and unified messaging servers VLAN interfaces must be implemented on core routing devices as defined in the VVoIP system ACL design.

Medium - V-19642 - SV-21783r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5635

Vuln IDs

V-19642

Rule IDs

SV-21783r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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. Information Assurance Officer

Checks: C-23982r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for voicemail and unified messaging servers VLAN interfaces must be implemented on core routing devices as defined in the VVoIP system ACL design. Ensure a deny-by-default ACL is implemented on the VVoIP Voicemail / Unified Messaging Servers VLAN interfaces on the VVoIP routing devices supporting the VVoIP system core equipment to control traffic as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets) (for depositing and retrieving VM from internal endpoints). - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the Media Gateway VLAN interfaces (VLAN/subnets) ((for depositing and retrieving VM from outside the enclave via a TDM network). - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the DoD WAN access VVoIP firewall (session border controller or other) VLAN interfaces (VLAN/subnets) (for depositing and retrieving VM from outside the enclave via an IP network). - Permit (only as required for proper functionality) the specific system required signaling protocols used by the Voicemail / Unified Messaging Servers (e.g., H.323, SIP, AS-SIP, proprietary) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets) (for session manager VM call setup/teardown). - Permit (only as required for proper functionality) the specific system required protocols used by a VM server to send email attachments (e.g., SMTP) to the user’s email server to/from the VVoIP general data user VLAN interfaces (VLAN/subnets) (for retrieving VM via email from a PC). - Permit (only as required for proper functionality) the specific system required protocols used by a user’s Unified Messaging client application on their PC (e.g., SMTP) to/from the VVoIP general data user VLAN interfaces (VLAN/subnets) (for retrieving email and VM from a PC in the event the VM server is also the user’s email server). - Deny all other traffic. End the ACL with a “deny all” statement. If a deny-by-default ACL for voicemail and unified messaging servers VLAN interfaces is not implemented on core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20346r2_fix

Implement and document a deny-by-default ACL for voicemail and unified messaging servers VLAN interfaces must be implemented on core routing devices as defined in the VVoIP system ACL design. as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets). - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the Media Gateway VLAN interfaces (VLAN/subnets). - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the DoD WAN access VVoIP firewall (session border controller or other) VLAN interfaces (VLAN/subnets). - Permit (only as required for proper functionality) the specific system required signaling protocols used by the Voicemail / Unified Messaging Servers (e.g., H.323, SIP, AS-SIP, proprietary) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Permit (only as required for proper functionality) the specific system required protocols used by a user’s Unified Messaging client application (e.g., SMTP) to/from the VVoIP general data user VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement.

b

A deny-by-default ACL for unified communications server VLAN interfaces must be implemented on core routing devices as defined in the VVoIP system ACL design.

Medium - V-19643 - SV-21784r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5640

Vuln IDs

V-19643

Rule IDs

SV-21784r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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 .Information Assurance Officer

Checks: C-23987r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for unified communications server VLAN interfaces is implemented on core routing devices. Ensure a deny-by-default ACL is implemented on the Unified Communications Servers VLAN interfaces on the VVoIP routing devices supporting the VVoIP system core equipment to control traffic as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets). - Permit (only as required for proper functionality) the specific system required signaling protocols used by the Unified Communications Servers (e.g., H.323, SIP, AS-SIP, proprietary, other) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement. If a deny-by-default ACL for unified communications server VLAN interfaces is not implemented on core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20347r2_fix

Implement and document a deny-by-default ACL for unified communications server VLAN interfaces on core routing devices as defined in the VVoIP system ACL design as follows: - Permit Media protocols/traffic (RTP/RTCP, SRTP/SRTCP) to/from the endpoint VLAN interfaces (VLAN/subnets). - Permit (only as required for proper functionality) the specific system required signaling protocols used by the Unified Communications Servers (e.g., H.323, SIP, AS-SIP, proprietary, other) to/from the VVoIP core control equipment VLAN interfaces (VLAN/subnets). - Deny all other traffic. End the ACL with a “deny all” statement.

b

A deny-by-default ACL for system management VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design.

Medium - V-19644 - SV-21785r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5645

Vuln IDs

V-19644

Rule IDs

SV-21785r2_rule

Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. 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 and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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. Information Assurance Officer

Checks: C-23988r2_chk

Review site documentation, especially the VVoIP system ACL design, to confirm a deny-by-default ACL for system management VLAN interfaces is implemented on VVoIP core routing devices. Ensure a deny-by-default ACL is implemented on the VVoIP system management VLAN interfaces on the VVoIP routing devices supporting the VVoIP system core equipment to control traffic as follows: - Deny access to the VVoIP system management VLAN from the VVoIP endpoint and core equipment production VLANs - Deny access to the VVoIP system management VLAN from the general data production VLANs - Deny general access to the VVoIP system management VLAN from the general LAN management VLAN and any other management VLAN - Permit access to the VVoIP system management VLAN from other management VLANs, NOC VPNs, and enterprise management/monitoring networks as specifically required to meet mission and NETOPS requirements. Such permissions will be based on the specific IP addresses (or limited address ranges) requiring access - Permit only those ports and protocols specifically required to meet mission and NETOPS requirements If a deny-by-default ACL for system management VLAN interfaces is not implemented on VVoIP core routing devices as defined in the VVoIP system ACL design, this is a finding.

Fix: F-20348r2_fix

Implement and document a deny-by-default ACL for system management VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design as follows: - Deny access to the VVoIP system management VLAN from the VVoIP endpoint and core equipment production VLANs - Deny access to the VVoIP system management VLAN from the general data production VLANs - Deny general access to the VVoIP system management VLAN from the general LAN management VLAN and any other management VLAN - Permit access to the VVoIP system management VLAN from other management VLANs, NOC VPNs, and enterprise management/monitoring networks as specifically required to meet mission and NETOPS requirements. Such permissions will be based on the specific IP addresses (or limited address ranges) requiring access - Permit only those ports and protocols specifically required to meet mission and NETOPS requirements

b

The implementation of Unified Mail services degrades the separation between the voice and data protection zones (VLANs).

Medium - V-19645 - SV-21786r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5560 (LAN)

Vuln IDs

V-19645

Rule IDs

SV-21786r1_rule

Voice mail services in a VoIP environment are available in several different configurations. A legacy voice mail platform can connect to a VoIP environment to provide voice mail services for VoIP users. In the same respect, a VoIP voice mail platform can provide voice mail services to the legacy voice users and the VoIP users. Some voice mail systems are also capable of providing unified mail by interacting with email messaging systems. Voicemails when recorded are converted to a .wav or similar digital audio file and sent to the email server as an attachment to an email. The subject line will typically contain the caller ID information if available. The email user can then open the attachment and listen to the voicemail on their PC or whatever device that provides properly authenticated access to the user’s email. Since the voicemail server must access the voice network (which, in a VoIP system is the VoIP VLAN system), and the data network (data VLANs) to send the email, caution and control must be exercised to not degrade the separation between the voice and data VLANs. Additionally, if the email server is part of or collocated with the voicemail server, user access to email must also not degrade the separation between the voice and data VLANs. Since this server may have 2 NICs and be connected to both voice and data VLANs, the server must not act as a bridge between the voice and data VLANs. 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 Officer

Checks: C-23991r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the implementation of a unified mail system does not degrade the separation and traffic filtering between the voice and data security zones or VLANs. This is a finding in the event the sending of voicemails to an email server or user access to email degrades the separation between the voice and data VLAN(s) such that the hosts or users on the data VLAN(s) have easy access to the VoIP instruments, traffic and infrastructure hosts on the VoIP VLAN(s).

Fix: F-20349r1_fix

Ensure the implementation of a unified mail system does not degrade the separation and traffic filtering between the voice and data security zones or VLANs. Configure unified mail services with access to both the data and voice VLANs to NOT bridge the two environments together.

b

The LAN Access switch port is NOT configured to place the VVoIP or VTC traffic in the proper VLAN (e.g., the port is NOT assigned to the proper VLAN) or the port does not assign the appropriate VLAN tag via some other method.

Medium - V-19646 - SV-21787r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5540 (LAN)

Vuln IDs

V-19646

Rule IDs

SV-21787r1_rule

Some VVoIP hardware endpoints and hardware based VTC endpoints contain a multi-port Ethernet switch to provide a connection on the endpoint for external devices such as a workstation (i.e., PC port). Additionally, some of these endpoints have the capability of defining the VLAN that their traffic will use via various methods but most typically by using 802.1Q trunking (VLAN tagging). However, some endpoints do not support VLAN assignment or cannot themselves maintain VLAN separation. In these cases, the responsibility of VLAN assignment and maintenance of VLAN separation falls to the LAN access switch (discrete NE or module in a larger NE) that supports the LAN cable drop to which the endpoint(s) is connected. Typically the LAN access switch port configurations contain a statement assigning the port to a specific VLAN. 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.Information Assurance Officer

Checks: C-23993r1_chk

If the VVoIP or VTC endpoints DO NOT provide a PC Port (and embedded Ethernet switch or hub), OR they do but cannot support VLAN separation (e.g., they have a hub) OR they cannot tag their traffic with the appropriate VLAN tag ((802.1Q). Inspect the configurations of the NE to determine compliance with the following requirement: In the event a LAN Access switch port supports a VVoIP or VTC endpoint that does not contain a multi-port Ethernet switch OR cannot maintain VLAN separation OR cannot provide an appropriate VLAN tag (802.1Q), ensure the LAN Access switch port is configured to place the VVoIP or VTC traffic in the proper VLAN (e.g., the port is assigned to the VLAN) or the port assigns the appropriate VLAN tag via some other method. Look at the LAN access port configurations to determine if the ports are assigned to the appropriate VLAN for the device it supports (VVoIP, VTC, Data, etc) Alternately, look for configuration settings that identify the type of traffic and assign the traffic or the port to the proper VLAN or add the appropriate VLAN tag. This is a finding if the initial condition is met and the LAN access ports are not configured as described.

Fix: F-20350r1_fix

In the event a LAN Access switch port supports a VVoIP or VTC endpoint that does not contain a multi-port Ethernet switch OR cannot maintain VLAN separation OR cannot provide an appropriate VLAN tag (802.1Q), ensure the LAN Access switch port is configured to place the VVoIP or VTC traffic in the proper VLAN (e.g., the port is assigned to the VLAN) or the port assigns the appropriate VLAN tag via some other method. Configure the LAN access ports such that they are assigned to the appropriate VLAN for the device it supports (VVoIP, VTC, Data, etc) Alternately Configure the LAN access ports to identify the type of traffic and assign the traffic or the port to the proper VLAN or add the appropriate VLAN tag.

b

The LAN access switch (discrete NE or module in a larger NE) is NOT capable of, or is NOT configured to; maintain the required VLAN separation for traffic originating from supported endpoints and DOES NOT route voice, VTC, PC communications client, and data traffic to their respective VLANs on the LAN.

Medium - V-19647 - SV-21788r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5535 (LAN)

Vuln IDs

V-19647

Rule IDs

SV-21788r1_rule

Some VVoIP hardware endpoints and hardware based VTC endpoints contain a multi-port Ethernet switch to provide a connection on the endpoint for external devices such as a workstation (i.e., PC port). This is done so that a PC and a workstation can share a single network cable drop and LAN access layer switch port. The PC port can, in general, support any device requiring an Ethernet connection. In theory, a VoIP phone, a desktop VTC unit could be daisy chained on a single LAN drop. These embedded multi-port Ethernet switches 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. The LAN access switch (discrete NE or module in a larger NE) must be capable of, and must be configured to, support the VLAN separation method used by the supported endpoints. The NE may perform this function in various ways as determined by the overall VVoIP system and LAN design. However, the typical (or preferred) method used by an endpoint to maintain VLAN separation is 802.1Q VLAN tagging. As such, the LAN access port and NE needs to support the receipt of tagged packets and handle them appropriately to also maintain VLAN separation. While the NE may retag the packets thereby reassigning the VLAN based on some defined rule, the NE may not strip the tags and mix all traffic together. Furthermore, The LAN access NE supporting LAN cable drops will typically have a VLAN defined for each service (VVoIP, VTC, Data, PC Comm. Client) supported by the endpoints connected to the NE. Traffic within the respective VLANs may flow between different physical ports on the NE but may not change VLANs in the process. This must be done by a routing device (discrete NE or module in a larger NE) and must be controlled by an appropriate ACL. The LAN access layer Ethernet switch may be combined in the same unit with the routing device as in the case of a layer-3 switch or a router containing an Ethernet switch module. 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.Information Assurance Officer

Checks: C-23995r1_chk

If the VVoIP or VTC endpoints supported by this NE provide a PC Port (has an embedded Ethernet switch), inspect the configurations of the NE to determine compliance with the following requirement: In the event the LAN access switch port supports a VVoIP or VTC endpoint with an embedded Ethernet switch, ensure the NE is capable of, and configured to, maintain the required VLAN separation from the endpoint and route voice, VTC, PC communications client, and data traffic to their respective VLANs on the LAN. NOTE: The NE may perform this function in various ways as determined by the overall VVoIP system and LAN design. However, the typical (or preferred) method used by an endpoint to maintain VLAN separation is 802.1Q VLAN tagging of the VVoIP traffic while letting PC port traffic pass unchanged. This permits both tagged and untagged traffic to come through the PC port. As such, the LAN access port and NE needs to support the receipt of tagged packets and handle them appropriately to also maintain VLAN separation. This may require the port be assigned to the data VLAN for the “default” traffic, while recognizing the VVoIP VLAN tag and then split the VVoIP traffic into its VLAN. While the NE may retag the packets thereby reassigning the VLAN based on some defined rule, the NE may not strip the tags and mix all traffic together. NOTE The LAN access layer Ethernet switch (discrete NE or module in a larger NE) supporting LAN cable drops will typically have a VLAN defined for each service (VVoIP, VTC, Data, PC Comm. Client) supported by the endpoints connected to the NE. Traffic within the respective VLANs may flow between different physical ports on the NE but may not change VLANs in the process. This must be done by a routing device (discrete NE or module in a larger NE) and must be controlled by an appropriate ACL. The LAN access layer Ethernet switch may be combined in the same unit with the routing device as in the case of a layer-3 switch or a router containing an Ethernet switch module.

Fix: F-20351r1_fix

In the event the LAN access switch port supports a VVoIP or VTC endpoint with an embedded Ethernet switch, ensure the NE is capable of, and configured to, maintain the required VLAN separation from the endpoint and route voice, VTC, PC communications client, and data traffic to their respective VLANs on the LAN. NOTE: The NE may perform this function in various ways as determined by the overall VVoIP system and LAN design. However, the typical (or preferred) method used by an endpoint to maintain VLAN separation is 802.1Q VLAN tagging. As such, the LAN access port and NE needs to support the receipt of tagged packets and handle them appropriately to also maintain VLAN separation. While the NE may retag the packets thereby reassigning the VLAN based on some defined rule, the NE may not strip the tags and mix all traffic together. NOTE: The LAN access layer Ethernet switch (discrete NE or module in a larger NE) supporting LAN cable drops will typically have a VLAN defined for each service (VVoIP, VTC, Data, PC Comm. Client) supported by the endpoints connected to the NE. Traffic within the respective VLANs may flow between different physical ports on the NE but may not change VLANs in the process. This must be done by a routing device (discrete NE or module in a larger NE) and must be controlled by an appropriate ACL. The LAN access layer Ethernet switch may be combined in the same unit with the routing device as in the case of a layer-3 switch or a router containing an Ethernet switch module.

b

LAN access switchports supporting VVoIP or VTC endpoints containing a PC port are configured in trunk mode, NOT in access mode or “802.1Q tagged access mode.”

Medium - V-19648 - SV-21789r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5545 (LAN)

Vuln IDs

V-19648

Rule IDs

SV-21789r1_rule

Policy regarding LAN access switchport mode has been established in the Network Infrastructure STIG by NET1416 which states “ensure trunking is disabled on all access ports (do not configure trunk on, desirable, non-negotiate, or auto—only off).” The reason for this is that a malicious user could affect a VLAN hopping attack. VLAN “hopping” occurs when a tagged frame destined for one VLAN is redirected to a different VLAN, threatening network security. The redirection can be initiated using two methods: “tagging attack” and “double encapsulation.” Frame tagging attacks allow a malicious user on a VLAN to get unauthorized access to another VLAN. For example, if a switch port’s trunk mode were configured as auto (enables a port to become a trunk if the connected switch it is negotiating trunking with has its state set to on or desirable) and were to receive a fake DTP packet specifying trunk on or desirable, it would become a trunk port and it could then start accepting traffic destined for all VLANs that belong to that trunk group. The attacker could start communicating with other VLANs through that compromised port—including the management VLAN. Insuring that trunk mode for any non-trunking port is configured as off can prevent this type of attack. Double encapsulation can be initiated by an attacker who has access to a switch port belonging to the native VLAN of the trunk port. Knowing the victim’s MAC address and with the victim attached to a different switch belonging to the same trunk group, thereby requiring the trunk link and frame tagging, the malicious user can begin the attack by sending frames with two sets of tags. The outer tag that is the attacker’s VLAN ID (probably the well known and omnipresent VLAN 1) is stripped off by the switch, and the inner tag that will have the victim’s VLAN ID is used by the switch as the next hop and sent out the trunk port. To ensure the integrity of the trunk link and prevent unauthorized access, the native VLAN of the trunk port should be changed from the default VLAN 1 to its own unique VLAN. NOTE: Trunk mode is typically used between LAN switches to extend defined VLANs across a network. This mode is used to interconnect LAN switches and routers with other LAN switches and routers to create a network across multiple NEs. Trunk mode generally requires each packet to be tagged with the VLAN ID that it belongs to. This tagging can follow the 802.1Q standard format or can use a vendor proprietary protocol such as Cisco’s ISL. Access mode on the other hand is used on a switchport that supports a connection to a LAN endpoint device. Typically single endpoint devices connected to a switchport send traffic that does not contain a VLAN tag. In this case, if a VLAN is defined for the endpoint, the switchport is statically assigned to a VLAN. As such, when a packet is received and sent out the “Trunk” the packet is tagged with the VLAN ID. Best practices dictate that the implementation of VVoIP on a network requires one or more VVoIP VLANs be established within the network. Therefore LAN access switchports that support VVoIP and VTC endpoints that do not tag or are capable but not configured to add a VLAN tag to their traffic must be statically assigned to the local VVoIP VLAN. VVoIP and VTC endpoints that do have the capability of adding the VLAN tag to their traffic typically use 802.1Q format and also typically support a PC port on the device. The PC port is added to the VVoIP or VTC endpoints since it reduces cabling and LAN infrastructure cost. Typically, VVoIP or VTC endpoints that support a PC port pass traffic from this port unchanged whether the traffic is tagged or not, while adding the VVoIP VLAN tag for the locally defined VVoIP VLAN to its VVoIP traffic. As such, a LAN access switchport must now support tagged and untagged traffic and keep the traffic separated. This is done by defining a default “data” VLAN (that is not the default VLAN on the NE such as VLAN 0 or 1) for the switchport in which untagged traffic is placed and defining a secondary VVoIP VLAN that matches the 802.1Q tag used for the VVoIP traffic. This method maintains the LAN access nature of the port even though it supports multiple VLANs while not requiring it to be configured as a trunk. 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.Information Assurance Officer

Checks: C-23997r1_chk

Inspect LAN access switchport configuration settings to confirm compliance with the following requirement: Ensure all LAN access switchports that support VVoIP and/or VTC endpoints containing a PC port are configured in access mode or “802.1Q tagged access mode” and NOT trunk mode. (e.g., “switchport mode access” NOT “switchport mode trunk”).

Fix: F-20352r1_fix

Ensure all LAN access switchports that support VVoIP and/or VTC endpoints containing a PC port are configured in access mode or “802.1Q tagged access mode” and NOT trunk mode. (e.g., “switchport mode access” NOT “switchport mode trunk”)

b

LAN access switchport supporting a VVoIP or VTC endpoint that does not, or is not configured to, apply 802.1Q VLAN tags to its traffic is NOT statically assigned to the appropriate local VVoIP or VTC VLAN.

Medium - V-19649 - SV-21790r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5550 (LAN)

Vuln IDs

V-19649

Rule IDs

SV-21790r1_rule

VVoIP or VTC endpoints that are not configured to or cannot provide a 802.1Q VLAN tag to its VVoIP traffic have no control over what VLAN their traffic ends up in, if any. Therefore the responsibility of placing VVoIP or VTC traffic in an appropriate VLAN for the type of traffic falls to the LAN switch. As such each switchport on a LAN NE that supports a VVoIP or VTC endpoint must place the traffic in the correct VLAN. This means that, in lieu of any other means to sort the traffic, each switchport must be statically assigned to the appropriate VLAN. NOTE: In some cases a LAN NE can use some other endpoint or traffic characteristic other than 802.1Q tagging to assign the traffic to the correct VLAN. 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 Officer

Checks: C-23998r1_chk

Inspect LAN access switchport configuration settings to confirm compliance with the following requirement: In the event a VVoIP or VTC endpoint does not, or is not configured to, apply 802.1Q VLAN tags to its VVoIP or VTC traffic, ensure the supporting LAN access switchport is statically assigned to the appropriate local VVoIP or VTC VLAN. This is not a finding in the event the LAN NE is configured to place the VVoIP or VTC traffic in the correct VLAN by some other method (e.g., MAC based). This is a finding in the event static VLAN assignment of the LAN access switchport is not configured to place the VVoIP VTC traffic in the correct VLAN in lieu of another method being configured. NOTE: While some LAN NEs have the capability of sorting traffic into VLANs based upon the protocol type, this method does not meet the intent of this requirement (i.e., the separation of VVoIP or VTC traffic to limit access to it and protect the system) since a PC could use similar protocols to those used by VVoIP or VTC endpoints for applications that are not associated with the VVoIP or VTC system which should therefore be kept separate. Using this method, the separation and resulting protection of the VVoIP or VTC system is diminished and a malicious user might be capable of using this to compromise the system.

Fix: F-20353r1_fix

In the event the VVoIP or VTC endpoint does not, or is not configured to, apply 802.1Q VLAN tags to its VVoIP traffic; and the switchport is not configured to place the VVoIP or VTC traffic in the correct VLAN by some other method (other than by protocol type) ensure the supporting LAN access switchport is statically assigned to the appropriate local VVoIP or VTC VLAN.

b

A LAN access switchport supports a VVoIP or VTC endpoint containing a PC port but is not configured with a default “data” VLAN to handle untagged PC port traffic and assign a secondary VVoIP or VTC VLAN to handle the tagged VVoIP or VTC traffic.

Medium - V-19650 - SV-21791r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5555 (LAN)

Vuln IDs

V-19650

Rule IDs

SV-21791r1_rule

Many VVoIP and VTC endpoints provide a PC port on the device. Doing so permits a PC to share the same LAN drop as a VoIP phone or desktop VTC endpoint. The net effect is reduced installation and maintenance cost for the LAN infrastructure. Endpoints that provide a PC port have an embedded Ethernet switch which is required to support the separation of the PC data traffic from the VVoIP and VTC traffic. This is primarily accomplished by the embedded Ethernet switch in the endpoint supporting VLANs. In support of this, many VVoIP and VTC endpoints have the capability of adding a VLAN tag to their traffic using the 802.1Q format. Typically the PC port traffic is passed to the LAN unchanged whether the traffic is tagged or not, while adding the VVoIP VLAN tag for the locally defined VVoIP VLAN to its VVoIP traffic. NOTE: this is a limitation of the switchport access mode. It seems that configuring more than a default and tagged VLAN on a switchport requires the port to be set as a trunk, which is not permissible based on NET1416. This causes a limitation in the number of devices and applications that can be supported by a single switchport and LAN drop. For example, a single switchport will support a single VoIP phone (w/ an embedded switch and PC port) which tags its traffic and a connected PC that does not. Similarly, a single switchport will support a single VTC endpoint (w/ an embedded switch and PC port) which tags its traffic and a connected PC that does not. Similarly, a single switchport will support a single PC that supports a soft phone and tags its VoIP traffic while not tagging its data traffic (per the PCCC STIG). A single port will not support a VoIP phone and a VTC endpoint and a PC on a single drop unless the VTC endpoint also tags its VTC traffic with the VoIP VLAN. If a PC with a compliant soft phone is connected, it must also tag its traffic with the single VoIP VLAN tag. NOTE: Traffic to/from a VTC endpoint may use the same VLAN as the VVoIP phone system. Some exceptions may apply. NOTE: Do not use the default VLAN for the switch which is generally VLAN 1. This is used for LAN control traffic. No traffic or interface is permitted to be assigned to the switches’ default VLAN. 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 Officer

Checks: C-23999r1_chk

Inspect LAN access switchport configuration settings to confirm compliance with the following requirement: In the event a LAN access switchport supports a VVoIP or VTC endpoint containing a PC port assign the switchport to a default “data” VLAN to handle untagged PC port traffic and assign a secondary VVoIP or VTC VLAN to handle the tagged VVoIP or VTC traffic. NOTE: 802.1Q format is typically used for VLAN tagging in this application. While this is the standard method, this requirement is not intended to preclude other methods to affect the required behavior. This is a finding in the event a LAN access switchport that supports a VVoIP or VTC endpoint containing a PC port is not configured with two VLANs, one that is a default “data” VLAN to handle untagged PC port traffic and a secondary VVoIP or VTC VLAN to handle the tagged VVoIP or VTC traffic. NOTE: Do not use the default VLAN for the switch which is generally VLAN 1. This is used for LAN control traffic. No traffic or interface is permitted to be assigned to the switches’ default VLAN.

Fix: F-20354r1_fix

In the event a LAN access switchport supports a VVoIP or VTC endpoint containing a PC port configure the switchport to assign a “default” “data” VLAN to handle untagged PC port traffic and assign a secondary VVoIP or VTC VLAN to handle the tagged VVoIP or VTC traffic. NOTE: 802.1Q format is typically used for VLAN tagging in this application. While this is the standard method, this requirement is not intended to preclude other methods to affect the required behavior. NOTE: Do not use the default VLAN for the switch which is generally VLAN 1. This is used for LAN control traffic. No traffic or interface is permitted to be assigned to the switches’ default VLAN.

b

When 802.1x is implemented and the VVoIP or VTC endpoint PC ports are disabled, the network access switch port must be configured to support a disabled PC port by configuring PC port traffic to the unused VLAN.

Medium - V-19651 - SV-21792r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5320

Vuln IDs

V-19651

Rule IDs

SV-21792r2_rule

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

Checks: C-24000r2_chk

If the VVoIP or VTC endpoints do not contain a PC port, this is not applicable. Review site documentation to confirm that when 802.1x is implemented and the VVoIP or VTC endpoint PC ports are disabled, the network access switch port is configured to support a disabled PC port by configuring PC port traffic to the unused VLAN. If 802.1x is implemented, the VVoIP or VTC endpoint PC ports are disabled, and the network access switch port is not configured to support a disabled PC port by configuring PC port traffic to the unused VLAN, this is a finding. The VVoIP or VTC endpoint network access switch port normally is configured with a VVoIP VLAN for the VVoIP traffic. This is IAW and supports the NI STIG requirement NET1435.

Fix: F-20355r2_fix

Implement and document that when 802.1x is implemented and the VVoIP or VTC endpoint PC ports are disabled, the network access switch port is configured to support a disabled PC port by sending PC port traffic to the unused VLAN. Do not statically assign the switch port to the VVoIP or VTC VLAN.

b

The appropriate number of pre-authorized MAC addresses must be statically assigned for the pre-authorized VVoIP and VTC endpoints to include daisy chained devices or the maximum number of MAC addresses dynamically learned on each access switch port must be limited to the minimum number of supported devices authorized to connect.

Medium - V-19652 - SV-21793r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5300

Vuln IDs

V-19652

Rule IDs

SV-21793r2_rule

Use of port security is required on network access switch ports. One method is MAC-based port security limiting the number of devices that can connect from an endpoint to a network access switch port. Allowing too many MAC addresses on a switch port could allow a hub or switch to be inserted into the voice VLAN port or PC/data port on a VVoIP or VTC endpoint, which allows additional unauthorized devices or workstations to be connected. VVoIP and VTC endpoints in the workspace where installed are provisioned with enough LAN drops to support the number of devices to be used in the workspace. This also requires that each LAN drop that is to be used must be connected to a network access switch port. The best practice is to limit the devices permitted to connect to any given LAN drop/switch port combination to one. The two methods do this are static mapping and MAC based port security. Static mapping the MAC address of a pre-authorized device into the configuration of the network access switch port requires manual configuration. The MAC based port security, also known as sticky-MAC, in which the MAC address of the first device to connect to the switch port is learned and added to the configuration. This becomes the authorized device. Sticky-MAC requires care be exercised regarding what device is connected to a port for the first time. In both cases an alarm will be generated if an unauthorized device is connected. Many VVoIP or VTC endpoints provide an extra Ethernet port called a PC port that permits the endpoint and another device to share the same LAN drop. This has several advantages. First, a VVoIP or VTC endpoint can be added to a LAN without having to run additional cable or activate additional LAN drops. It is possible to share a single LAN drop with a VVoIP endpoint, a desktop VTC endpoint, and computer. Another initiative where a single LAN drop is shared is hot desking, where several people are assigned to work at the same desk at different times, each with their own laptop computer. In this case, a different MAC address needs to be permitted for each laptop that is supposed to connect to the LAN drop in the workspace. Additionally, this workspace could contain a single phone used by all assignees and the PC port on it might be the connection for their laptop. Information Assurance Officer

Checks: C-24003r2_chk

Review site documentation to confirm the appropriate number of pre-authorized MAC addresses must be statically assigned for the pre-authorized VVoIP and VTC endpoints to include daisy chained devices. If static assignment is not implemented, the maximum number of MAC addresses dynamically learned on each access switch port must be limited to the minimum number of supported devices authorized to connect. If static assignment is not implemented and dynamic learning is not limited, this is a finding. The dynamic MAC based port security used for port security where MAC addresses are learned configuration settings must be as follows: - A LAN switch port supporting a single authorized VVoIP or VTC endpoint is configured for a learned maximum of one. The PC port must be disabled, if present. - A LAN switch port supporting an authorized VVoIP or VTC endpoint providing a PC port connecting a computer is configured for a learned maximum of three dynamically learned addresses. While there are two authorized devices permitted to connect, the endpoint address may be learned twice in association with the data VLAN and the VVoIP or VTC VLAN. - When a VVoIP endpoint, VTC endpoint, and a computer are daisy chained on one LAN drop and switch port, the switch port is configured for a learned maximum of five dynamically learned addresses. This is because both the VVoIP and VTC endpoints will typically be assigned to the VVoIP VLAN due to switch port mode configuration limitations and both endpoints may be learned twice in association with the data VLAN and the VVoIP or VTC VLAN. If the switch port supports a third VLAN in access mode, additional MAC addresses may be learned by the multiple VLANs thereby requiring the maximum to be set higher but only if absolutely necessary. When dynamic MAC assignment is implemented, if the maximum number of MAC addresses dynamically learned on each access switch port is not limited to the minimum number of supported devices authorized to connect, this is a finding. The static mapping of MAC addresses used for port security configuration settings must be as follows: - A LAN switch port supporting a single authorized VVoIP or VTC endpoint is configured with one MAC address. The PC port must be disabled, if present. - A LAN switch port supporting an authorized VVoIP or VTC endpoint providing a PC port connecting a computer is configured with two MAC addresses. - When a VVoIP endpoint, VTC endpoint, and computer are daisy chained on one LAN drop and switch port, the switch port is configured with the three corresponding MAC addresses. When static MAC assignment is implemented, if the appropriate numbers of pre-authorized MAC addresses are not statically assigned for the pre-authorized VVoIP and VTC endpoints to include daisy chained devices, this is a finding. If static assignment is not implemented and dynamic learning is not limited as directed, this is a finding.

Fix: F-20356r2_fix

Implement and document the appropriate number of pre-authorized MAC addresses are statically assigned for the pre-authorized VVoIP and VTC endpoints to include daisy chained devices or the maximum number of MAC addresses dynamically learned on each access switch port are limited to the minimum number of supported devices authorized to connect. When dynamic MAC based port security are used for port security where MAC addresses are learned configuration settings must be as follows: - A LAN switch port supporting a single authorized VVoIP or VTC endpoint is configured for a learned maximum of one. The PC port must be disabled, if present. - A LAN switch port supporting an authorized VVoIP or VTC endpoint providing a PC port connecting a computer is configured for a learned maximum of three dynamically learned addresses. - When a VVoIP endpoint, VTC endpoint, and a computer are daisy chained on one LAN drop and switch port, the switch port is configured for a learned maximum of five dynamically learned addresses. When static mapping of MAC addresses are used for port security configuration settings must be as follows: - A LAN switch port supporting a single authorized VVoIP or VTC endpoint is configured with one MAC address. The PC port must be disabled, if present. - A LAN switch port supporting an authorized VVoIP or VTC endpoint providing a PC port connecting a computer is configured with two MAC addresses. - When a VVoIP endpoint, VTC endpoint, and computer are daisy chained on one LAN drop and switch port, the switch port is configured with the three corresponding MAC addresses.

b

VVoIP and VTC endpoints must integrate into the implemented 802.1x network access control system.

Medium - V-19653 - SV-21794r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5305

Vuln IDs

V-19653

Rule IDs

SV-21794r2_rule

IEEE 802.1x is a protocol used to control access to LAN services via a network access switch port or wireless access point that requires a device or user to authenticate to the network element and become authorized by the authentication server before accessing the network. This standard is used to activate the network access switch port limiting traffic to a specific VLAN or install traffic filters. This method is more secure and capable than using basic MAC based port security. It is required to be used in certain circumstances by the Network Infrastructure STIG. When 802.1x is used, all devices connecting to the LAN are required to use 802.1x.Information Assurance Officer

Checks: C-24004r2_chk

Review site documentation to confirm the VVoIP and VTC endpoints integrate into the implemented 802.1x network access control system. When the network access control implementation uses 802.1x and the network access switch ports are configured as 802.1x authenticators, ensure the VVoIP and VTC endpoints integrate into the 802.1x access control system. If the VVoIP and VTC endpoints do not integrate into the implemented 802.1x network access control system, this is a finding. If 802.1x is used within the LAN but one or more VVoIP or VTC endpoints are not configured as 802.1x supplicants whether the endpoints support 802.1x or not, this is a finding.

Fix: F-20357r2_fix

Implement and document the VVoIP and VTC endpoints integrated into the implemented 802.1x network access control system.

b

The 802.1x authentication server must place VVoIP and VTC traffic in the correct VLAN when authorizing LAN access for VVoIP and VTC endpoints.

Medium - V-19654 - SV-21795r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5310

Vuln IDs

V-19654

Rule IDs

SV-21795r2_rule

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

Checks: C-24006r2_chk

Review site documentation to confirm the 802.1x authentication server places VVoIP and VTC traffic in the correct VLAN when authorizing LAN access for VVoIP and VTC endpoints. When the network access control implementation uses 802.1x and the network access switch ports are configured as 802.1x authenticators, ensure the VVoIP and VTC endpoints integrate into the 802.1x access control system. If the 802.1x authentication server does not place data, VVoIP, and VTC traffic in the correct VLANs when authorizing LAN access for VVoIP and VTC endpoints, this is a finding. An example follows: If all LAN ports are configured to use 802.1x LAN access control (as the typical case would be), and are configured as disabled until a device authenticates, each port must support the authentication of a general workstation (a data device) or a VVoIP endpoint, or a VTC endpoint. If a work station authenticates, the switch port must be configured with the data VLAN. If a VVoIP endpoint authenticates, the switch port must be configured with the VVoIP VLAN. If a VTC endpoint authenticates, the switch port must be configured with the VTC VLAN. When a VVoIP endpoint that contains a PC port authenticates, the switch port must be configured with the VVoIP VLAN to receive the VVoIP traffic AND must be configured with the data VLAN to receive traffic from the PC port. When a VVoIP or VTC endpoint provides a PC port, and the PC port is disabled (as required) because the 802.1x implementation cannot control LAN access via the PC port once the endpoint is authorized, the required configuration for the network access switch ports is to configure the appropriate VLAN for the VVoIP or VTC traffic (as required) as well as configuring the “unused” VLAN for the disabled PC port (as required).

Fix: F-20358r2_fix

Implement and document the 802.1x authentication server places data, VVoIP, and VTC traffic in the correct VLANs when authorizing LAN access for VVoIP and VTC endpoints.

b

When 802.1x is implemented and VVoIP or VTC endpoints provide a PC port, the PC port must be an 802.1x authenticator, or be disabled.

Medium - V-19655 - SV-21796r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5315

Vuln IDs

V-19655

Rule IDs

SV-21796r2_rule

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

Checks: C-24008r2_chk

If the VVoIP or VTC endpoints do not contain a PC port, this is not applicable. Review site documentation to confirm that when 802.1x is implemented on the LAN and the VVoIP or VTC endpoints provide a PC port, the PC port is an 802.1x authenticator, or be disabled. If when 802.1x is implemented on the LAN and the VVoIP or VTC endpoints provide a PC port and the PC port is an 802.1x authenticator, this is not a finding. If the PC port is disabled, this is not a finding. If the VVoIP or VTC endpoint PC port and the network access switch port in combination act as an 802.1x authenticator and the 802.1x system provides control over the LAN access gained through the endpoint’s PC port, this is not a finding. Otherwise, this is a finding.

Fix: F-20359r2_fix

Implement and document that when 802.1x is implemented and VVoIP or VTC endpoints provide a PC port, one of the following options must be in place: - The PC port is configured as an 802.1x authenticator - The PC port and the network access switch port in combination act as an 802.1x authenticator - The PC port is disabled

a

VVoIP endpoints or instruments permit the display of network IP configuration information and/or permit adjustment of network settings without the use of a non-default PIN/password.

Low - V-19656 - SV-21797r1_rule

RMF Control

Severity

L

CCI

Version

VVoIP 1600 (GENERAL)

Vuln IDs

V-19656

Rule IDs

SV-21797r1_rule

Many VVoIP endpoints have the capability of setting and/or displaying configuration settings in the instrument itself. While this makes it convenient to configure and troubleshoot at the desktop, it presents a vulnerability whereby, a user or anybody in the area can obtain information such as the IP addresses and URLs of system components. This obtained information could be used to facilitate an attack on the system by would be hackers or attackers. Therefore these devices should be considered a target to be defended against such individuals that would collect voice network information for illicit purposes. To help prevent against information gathering by the unscrupulous, measures must be taken to protect this information. Programming IP Phones not to display network information (i.e. IP address, subnet mask, gateway, LCC addresses or URLs, etc.), without entering a password or PIN code, should be considered as another layer of security in protecting the VoIP environment. Additionally, such a PIN/password should not be a well know or default “magic key sequence.” Such a PIN/password should only be available at initial setup of the instrument. While this PIN/password will most likely be a group PIN/password (not meeting DoD password/auditing policy under IAGA-1) they should not be permanently stored on the instrument, they should instead be centrally managed. The instrument should query the Local Session Controller (LSC) to validate the PIN/Password (or minimally) should be changeable from the LSC as a function of the endpoint configuration. Instrument configuration PIN/passwords should be managed in accordance with normal DoD password policy such as being changed on a regular basis and when compromised or when an SA leaves the organization. NoneDenial of Service and/or unauthorized access to network or voice system resources or services and the information they contain. System or server attack based on information gathered from end instruments.Information Assurance Officer

Checks: C-24011r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure VVoIP endpoints or instruments cannot be configured at the terminal and do not display network/terminal configuration information on their display without the use of a PIN/password.

Fix: F-20360r1_fix

Ensure VVoIP endpoints or instruments cannot be configured at the terminal and do not display network/terminal configuration information on their display without the use of a PIN/password. Configure VVoIP endpoints or instruments to NOT display voice network information without the entry of a password or a PIN code.

b

The VVoIP endpoint’s configuration and/or configuration-display PIN/passwords DO NOT authenticate remotely to the Local session Controller (LSC) or minimally are not centrally controlled by the LSC.

Medium - V-19657 - SV-21798r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1605 (GENERAL)

Vuln IDs

V-19657

Rule IDs

SV-21798r1_rule

Many VVoIP endpoints have the capability of setting and/or displaying configuration settings in the instrument itself. While this makes it convenient to configure and troubleshoot at the desktop, it presents a vulnerability whereby, a user (or anybody in the area) can obtain information such as the IP addresses and URLs of system components that could in turn be used to facilitate an attack on the system by hackers or attackers. Therefore these devices should be considered a target to be defended against such individuals that would collect voice network information for illicit purposes. To help prevent against information gathering by the unscrupulous, measures must be taken to protect this information. Programming IP Phones to not display network information (i.e. IP address, subnet mask, gateway, LCC addresses or URLs, etc.), without entering a password or PIN code, should be considered as another layer of security in protecting the VoIP environment. Additionally, such a PIN/password should not be a well know or default “magic key sequence.” Such a PIN/password should only be available at initial setup of the instrument. While this PIN/password will most likely be group PIN/password (not meeting DoD password/auditing policy under IAGA-1) they should not be permanently stored on the instrument. Instead, they should be centrally managed. The instrument should query the Local Session Controller (LSC) to validate the PIN/Password, or minimally, should be changeable from the LSC as a function of the endpoint configuration. Instrument configuration PIN/passwords should be managed in accordance with normal DoD password policy. For example, the PIN/password needs to be changed on a regular basis. This finding can be reduced to a CAT III in the event The VVoIP endpoint’s configuration and/or configuration-display PIN/passwords does not remotely authenticate BUT IS centrally manageable / changeable from the LSC.Denial 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 they are not centrally managed since Password or PIN codes stored on the terminals or end instruments will most likely never be changed.Information Assurance Officer

Checks: C-24013r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure that the VVoIP endpoint’s configuration/configuration-display/configuration PIN/passwords authenticate remotely to, or are centrally manageable and changeable from, the system controller (Local Session Controller (LSC)). Determine if the VVoIP endpoint’s configuration/configuration-display/configuration PIN/passwords can be centrally managed and changed from the LSC

Fix: F-20361r1_fix

Ensure that the VVoIP endpoint’s configuration/configuration-display/configuration PIN/passwords authenticate remotely to, or are centrally manageable and changeable from, the system controller (Local Session Controller (LSC)). Configure the system to remotely authenticate VVoIP endpoint’s configuration and configuration-display PIN/passwords or minimally centrally manage these PIN/passwords from the LSC.

b

A VVoIP or VTC hardware endpoint possessing a “PC Port” is not configured to block access to the endpoint configuration and communications traffic from the attached PC

Medium - V-19658 - SV-21799r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5705 (LAN)

Vuln IDs

V-19658

Rule IDs

SV-21799r1_rule

VVoIP or VTC hardware endpoint possessing a “PC Port” can provide an easy avenue to access and compromise the endpoint configuration and communications traffic. Through such unauthorized access an attacker could also compromise the core of the VVoIP or VTC system or gain information for an attack from another vector. As such, VVoIP or VTC hardware endpoint must block access to its configuration and communications traffic from the PC port.None Denial 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.Information Assurance Officer

Checks: C-24015r1_chk

Potential active tests: Open a browser on an attached test PC (the normal PC may not be capable of performing the tests). Attempt to connect to the IP address of the phone. Attempt to ping the endpoint IP address. Open a sniffer program and attempt to capture traffic to/from the phone. None of these should attempts be successful. Perform a network scan of the VoIP address space from the PC port. The VVoIP endpoints should not show up in the results.

Fix: F-20362r1_fix

In the event a VVoIP or VTC hardware endpoint provides a “PC Port” Ensure all VVoIP or VTC hardware endpoints possessing a “PC Port” is configured to block access to the endpoint configuration and communications traffic from the attached PC or other device. Alternately ensure, if the endpoint cannot maintain this separation, the “PC Port” is disabled. In the event the endpoint contains an Ethernet hub, the PC port may need to be physically disabled (blocked) if it cannot be electronically disabled. 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. Generally, do not implement VVoIP or VTC hardware endpoints that have an embedded Ethernet hub instead of a switch since a hub cannot support VLAN separation and drastic measures may be needed to disable the PC port.

b

A VVoIP or VTC hardware endpoint possessing a “PC Port” does not tag its communications traffic using 802.1Q VLAN tagging or the PC port is not disabled.

Medium - V-19659 - SV-21800r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5710 (LAN)

Vuln IDs

V-19659

Rule IDs

SV-21800r1_rule

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 frames/packets while the embedded switch passes all frames/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.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.Information Assurance Officer

Checks: C-24018r1_chk

If the VVoIP or VTC endpoints provide a PC Port (and embedded Ethernet switch), inspect the configurations of the endpoints and/or their configuration settings on the LSC to determine compliance with the following requirement: In the event A VVoIP or VTC hardware endpoint possesses a “PC Port,” ensure the VVoIP packets are tagged with the correct local VVoIP endpoint VLAN ID while passing all traffic entering the PC port unchanged so that these packets are automatically placed in the correct VLAN by the access layer switch. Alternately ensure, if the endpoint cannot maintain this separation, the “PC Port” is disabled. In the event the endpoint contains an Ethernet hub, the PC port may need to be physically disabled (blocked) if it cannot be electronically disabled.

Fix: F-20363r1_fix

In the event A VVoIP or VTC hardware endpoint possesses a “PC Port”, configure the VVoIP or VTC endpoint to tag its Ethernet frames with the correct local VVoIP endpoint 802.1Q VLAN ID while passing all traffic entering the PC port to the LAN port unchanged so that these packets are automatically placed in the correct VLAN by the access layer switch. Alternately ensure, if the endpoint cannot maintain this separation, the “PC Port” is disabled. In the event the endpoint contains an Ethernet hub, the PC port may need to be physically disabled (blocked) if it cannot be electronically disabled.

a

A VVoIP or VTC endpoint that provides a PC data Port is not configured to disable the PC port (or the port is not physically blocked from use) if a PC or other device is not normally attached

Low - V-19660 - SV-21801r1_rule

RMF Control

Severity

L

CCI

Version

VVoIP 5715 (LAN)

Vuln IDs

V-19660

Rule IDs

SV-21801r1_rule

Many IP hardware phones provide a separate data port for the connection of a PC to the phone so that only a single cable is required to provide data and voice connectivity to the end users desktop. Additionally, some IP hardware phones are only capable of providing basic layer 2 connectivity, acting like a hub and combining the data and voice network segments. While other IP phones offer enhanced Layer 2 connectivity providing the option to use VLAN technology, to place the phone and the data traffic on two different VLANs. To ensure logical separation of voice and data in order to maintain the security of the VoIP environment, only layer 2 enhanced or VLAN capable phones should be considered for use. Many attacks on DOD computer systems are launched from within the network by dissatisfied or disgruntled employees, therefore, it is imperative that any active IP Phone data ports be disabled the same as unused physical ports on a network switch. If unauthorized personnel gain access to the VoIP or data environment through an unsecured data port, they could cause disruptions, denial of service conditions, or access sensitive information. Disabling data ports on IP Phones prevents this type of unauthorized and unwanted activity. NOTE: It is not typical that the PC port will be used on all endpoints. For example, phones and VTC units in offices typically might be used, while phones in common areas such as a lobby, hallway, or kitchen, etc. will not. Phones and VTC units in conference rooms may or may not, depending upon site policy. In general, these PC ports are the most vulnerable to unauthorized use, and therefore should be disabled until actually required to be used by an authorized LAN user. The specific vulnerability addressed here is unauthorized access to the LAN and/or the endpoints’ configuration and communications traffic. VVoIP 5715 This finding can be reduced to a Cat III in the event an endpoint’s PC port is not disabled in software via a configuration setting, but the LAN access switch port is configured to only provide service to the specific MAC address of the endpoint. This is because the EI’s configuration and/or communications traffic would be vulnerable via the PC port.Denial of Service, loss of confidentiality, and/or unauthorized access to network or voice system resources or services and the information they contain. Numerous potential impacts are made available by vulnerabilities associated with unauthorized access to the network.Partial Mitigation: Configure the LAN access switch port that supports the endpoint for MAC based port security using the MAC of the approved endpoint. Does not prevent access to the endpoint itself.Information Assurance Officer

Checks: C-24020r1_chk

Interview the IAO to determine if the VVoIP or VTC endpoints provide a PC Port. Further determine the following: Is the port is regularly used on most endpoints? Which endpoints and PC ports are NOT used? NOTE: It is not typical that the PC port will be used on all endpoints. For example, phones and VTC units in offices typically might be used, while phones in common areas such as a lobby, hallway, or kitchen, etc. will not. Phones and VTC units in conference rooms may or may not, depending upon site policy. In general, though, these PC ports are the most vulnerable to unauthorized use and therefore should be disabled until actually required to be used by an authorized LAN user. Ensure all VVoIP or VTC endpoints that provide a PC Port are configured to disable the PC data port if a PC or other device is not normally attached.

Fix: F-20364r1_fix

Ensure all VVoIP or VTC endpoints that provide a PC Port are configured to disable the PC data port if a PC or other device is not normally attached. NOTE: A partial mitigation to the vulnerability addressed here is to configure the LAN access switch ports for MAC based port security and configuring it to only accept connections from the specific MAN address of the connected approved endpoint

c

The data network boundary must block all traffic destined to or sourced from VVoIP VLAN IP address space and VLANs except specifically permitted media and signaling traffic.

High - V-19661 - SV-21802r3_rule

RMF Control

Severity

H

CCI

Version

VVoIP 6200

Vuln IDs

V-19661

Rule IDs

SV-21802r3_rule

The typical data firewall does not adequately protect the enclave when permitting VVoIP to traverse the boundary. Furthermore, this firewall breaks VVoIP call completion, particularly if NAT is implemented. To properly protect the enclave when implementing VVoIP across the boundary, there are a specific set of processes and protections required, referred to as the VVoIP firewall function. These are separate from the data firewall processes and protections. The data firewall function plays a part in the protection of the VVoIP sub-enclave within the LAN, while the VVoIP firewall function protects the entire enclave while permitting the VVoIP system to function properly.Information Assurance Officer

Checks: C-24027r3_chk

Review site documentation to confirm the data network boundary protects the VVoIP VLANS by blocking all but specifically permitted traffic destined to or sourced from the Voice VLAN IP address space and VLANs. The data firewall configuration must block all traffic destined to or sourced from VVoIP VLANs and address space, except as follows: - VVoIP signaling, media, and registration protocols to and from a remote endpoint via a properly authenticated VPN tunnel. When an SBC is not in use, traffic is blocked from the data VLANs and routed to the VVoIP VLANs. When an SBC is in use, session traffic must be routed through the SBC. - Management traffic to and from a remote NOC destined for the VVoIP management VLAN address space. In this case, the data firewall and IDS inspects this traffic before it is routed to the VVoIP management VLAN. Such routing must block all traffic from the data VLAN, data subnets, and the general data network management VLANs. - Protected LSC to LSC communications clustered across the WAN. - The enclave is connected to a limited access or closed WAN, and the WAN has a dedicated address space for VVoIP. In this case, the VVoIP traffic may pass through the data firewall when the permitted traffic is limited to/from the dedicated WAN address space and routed to the internal VVoIP VLANs. If the network perimeter does not protect the VVoIP VLANS by blocking all but specifically permitted traffic destined to or sourced from the Voice VLAN IP address space and VLANs, this is a finding

Fix: F-20366r3_fix

Implement the network perimeter to protect the VVoIP VLANS by blocking all but specifically permitted traffic destined to or sourced from the Voice VLAN IP address space and VLANs.

b

The Customer Edge Router (CER) must expedite forwarding of VVoIP packets based on Differential Service Code Point (DSCP) packet marking.

Medium - V-19662 - SV-21803r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6205

Vuln IDs

V-19662

Rule IDs

SV-21803r2_rule

The typical perimeter or premise router may not be capable of supporting the needs of VVoIP and UC when entering the DISN WAN. Modern 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 needed to support the service is the CER. The CER provides the following functionality: - Provides minimally four forwarding cues (eight preferred) - Places traffic within expedited forwarding cues based on the DSCP markings carried by the traffic. - Routes inbound AS-SIP-TLS packets and SRTP/SRTCP packets to the Session Border Controller (SBC). - Routes all other inbound traffic to the data firewall. - Provides all of the filtering required of a perimeter or premise router as required by the Router STIG. Proper DSCP marking of VVoIP packets is required to provide appropriate QoS for Command and Control (C2) priority calls in support of Assured Service.Information Assurance Officer

Checks: C-24030r2_chk

Review site documentation to confirm the CER expedites forwarding of VVoIP packets based on DSCP packet marking. When the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves and the system provides Assured Services to any C2 user (Special-C2, C2, or C2-R), the required CER must expedite forwarding of VVoIP packets based on DSCP packet marking in accordance with the DISN IPVS DSCP marking plan. Proper DSCP marking provides appropriate QoS for C2 priority calls in support of Assured Service. If the CER does not expedite forwarding of VVoIP packets based on DSCP packet marking, this is a finding.

Fix: F-20367r2_fix

Implement the CER to expedite forwarding of VVoIP packets based on DSCP packet marking.

b

The Customer Edge Router (CER) must route all inbound traffic to the data firewall function except AS-SIP-TLS and SRTP/SRTCP, which must go to the Session Border Controller (SBC).

Medium - V-19663 - SV-21804r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6210

Vuln IDs

V-19663

Rule IDs

SV-21804r2_rule

The CER is the first line of defense at the gateway to the enclave or LAN. The data firewall and SBC functions are the second line of defense. Since the SBC function only processes VVoIP traffic in the form of AS-SIP-TLS and SRTP/SRTCP packets, the CER should only forward these packets to the VVoIP firewall.Information Assurance Officer

Checks: C-24032r2_chk

Review site documentation to confirm the CER routes all inbound traffic to the data firewall function except AS-SIP-TLS and SRTP/SRTCP, which must go to the SBC. This supports the VVoIP system connecting to the DISN WAN for VVoIP transport between enclaves and the system providing Assured Services to any Command and Control (C2) user (Special-C2, C2, or C2-R). If the CER does not route all inbound traffic to the data firewall function except AS-SIP-TLS and SRTP/SRTCP, this is a finding.

Fix: F-20368r2_fix

Implement the CER to route all inbound traffic to the data firewall function except AS-SIP-TLS and SRTP/SRTCP.

a

The Customer Edge Router (CER) must filter inbound AS-SIP-TLS traffic addressed to the local Session Border Controller (SBC) based on the source address of the signaling messages.

Low - V-19664 - SV-21805r2_rule

RMF Control

Severity

L

CCI

Version

VVoIP 6215

Vuln IDs

V-19664

Rule IDs

SV-21805r2_rule

The CER (premise or perimeter) router is the first line of defense at the gateway to the enclave or LAN. The data firewall and SBC functions are the second line of defense. The SBC processes VVoIP traffic in the form of AS-SIP-TLS and SRTP/SRTCP packets, and the CER must forward these packets to the SBC. A filter performed by the CER to prevent a denial-of-service is to filter the AS-SIP-TLS packets based on their source address. Within the DISN IPVS network, Local Session Controllers (LSC) only signal to their assigned Soft Switch (SS) and its backup. SSs are only to signal with their assigned LSCs, for which they are primary or backup, and other SSs. To support this, the SBC is required to authenticate the source of, and validate the integrity of, the signaling packets it receives and only process authenticated and valid packets, thereby only signaling with the appropriate devices. Still, the SBC could be flooded and overloaded with too many unauthenticated or invalid signaling packets. The CER can help prevent this by preventing signaling packets that are not sourced from authorized devices from ever reaching the SBC.Information Assurance Officer

Checks: C-24034r2_chk

Review site documentation to confirm the CER filters inbound AS-SIP-TLS traffic addressed to the local SBC based on the source address of the signaling messages. This supports the VVoIP system connecting to the DISN WAN for VVoIP transport between enclaves and the system providing Assured Services to any Command and Control (C2) user (Special-C2, C2, or C2-R). Permit inbound signaling messages sourced as follows: - When the enclave contains one or more Local Session Controllers (LSCs), filter on the IP addresses of the SBCs fronting the primary and secondary Soft Switches (SSs) associated with the enclave. - When the enclave contains an SS filter based on IP addresses of SBCs fronting the LSCs associated with the SS. If the CER does not filter inbound AS-SIP-TLS traffic addressed to the local SBC based on the source address of the signaling messages, this is a finding.

Fix: F-20370r2_fix

Implement the CER to filter inbound AS-SIP-TLS traffic addressed to the local SBC based on the source address of the signaling messages.

b

The EBC is NOT configured to filter inbound AS-SIP-TLS traffic based on the IP addresses of the internal LSC(s) (or MFSS) OR the IP addresses of the EBCs fronting its authorized signaling partners as part of a layered defense.

Medium - V-19665 - SV-21806r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6300 (DISN-IPVS)

Vuln IDs

V-19665

Rule IDs

SV-21806r1_rule

The EBC is in the VVoIP signaling between the LSC and MFSS. To limit its exposure to compromise and DOS, it must only exchange signaling messages using the designated protocol (AS-SIP-TLS) with the LSC(s) within the enclave and the EBC fronting the MFSS (and its backup) to which the LSC is assigned. Similarly, an EBC fronting an MFSS must only exchange signaling messages with the MFSS and LSC(s) within the enclave and the EBCs fronting other MFSSs and the LSCs that are assigned to it. While the EBC is also required to authenticate the source and integrity of the signaling packets it receives, filtering on source IP address adds a layer of protection for the MFSS. This is also a backup measure in the event this filtering is not done on the CER. Internal to the enclave, filtering signaling traffic based on the IP address(es) of the LSC(s) within the enclave limits the ability of rogue EIs attempting to establish calls or cause a DOS. NoneThe inability to provide assured service for critical voice and video communications.Information Assurance OfficerECSC-1

Checks: C-24038r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to only communicate as follows: > Within the enclave, ensure the EBC only establishes an AS-SIP-TLS session with the primary or backup LSC or the MFSS and its backup LSC within the enclave. >If the EBC is at a site without a MFSS: External to the enclave (across the WAN), ensure the EBC only establishes an AS-SIP-TLS session with the EBC at the enclave’s assigned primary and secondary (backup) MFSS sites. > If the EBC is at a MFSS site: External to the enclave (across the WAN), ensure the EBC only establishes an AS-SIP-TLS session with EBCs located at other MFSS sites and the LSC sites assigned to it. Determine the following: > If the enclave contains LSCs, determine the IP address of EBCs fronting the primary and backup MFSSs to which the enclave is assigned or with which the LSC is to exchange signaling messages. > If the enclave contains a MFSS, determine the IP addresses of the EBCs fronting the LSCs with which it is to signal. Additionally determine the IP addresses of the EBCs fronting the other MFSSs.

Fix: F-20371r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to only communicate as follows: > Within the enclave, ensure the EBC only establishes an AS-SIP-TLS session with the primary or backup LSC or the MFSS and its backup LSC within the enclave. >If the EBC is at a site without a MFSS: External to the enclave (across the WAN), ensure the EBC only establishes an AS-SIP-TLS session with the EBC at the enclave’s assigned primary and secondary (backup) MFSS sites. > If the EBC is at a MFSS site: External to the enclave (across the WAN), ensure the EBC only establishes an AS-SIP-TLS session with EBCs located at other MFSS sites and the LSC sites assigned to it.

b

The EBC is NOT configured to terminate and decrypt inbound and outbound AS-SIP-TLS sessions (messages) such that it can properly manage the transition of the SRTP/SRTCP streams

Medium - V-19666 - SV-21807r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6305 (DISN-IPVS)

Vuln IDs

V-19666

Rule IDs

SV-21807r1_rule

We previously discussed the reasons why a special firewall function is needed to protect the enclave if VVoIP is to traverse the boundary (see VVoIP 1005 (GENERAL) under VVoIP policy). This requirement addresses the function of the EBC which manages the AS-SIP-TLS signaling messages. In order to perform its proper function in the enclave boundary, the EBC must decrypt and decode or understand the contents of AS-SIP-TLS messages. Doing so supports the requirements that are to follow. Additionally, the EBC can perform message validity checks and determine of an attack is being attempted. NOTE: The EBC acts as an application level proxy and firewall for the signaling AS-SIP-TLS messages. NoneThe inability to properly protect the enclave.Information Assurance Officer

Checks: C-24040r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to terminate AS-SIP-TLS sessions (messages) (both inbound and outbound) and decrypt the packets to determine the information needed to properly manage the transition of SRTP/SRTCP streams across the boundary. Additionally ensure the EBC establishes a new AS-SIP-TLS session for the “next hop” to the internal LSC or the far end EBC that fronts the destination MFSS.

Fix: F-20372r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to terminate AS-SIP-TLS sessions (messages) (both inbound and outbound) and decrypt the packets to determine the information needed to properly manage the transition of SRTP/SRTCP streams across the boundary. Additionally ensure the EBC establishes a new AS-SIP-TLS session for the “next hop” to the internal LSC or the far end EBC that fronts the destination LSC or MFSS.

b

The DISN NIPRNet IPVS firewall (EBC) is NOT configured to drop (and not process) all packets except those that are authenticated as being from an authorized source within the DISN IPVS network.

Medium - V-19667 - SV-21808r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6310 (DISN-IPVS)

Vuln IDs

V-19667

Rule IDs

SV-21808r1_rule

We previously discussed the reasons why a special firewall function is needed to protect the enclave if VVoIP is to traverse the boundary (see VVoIP 1005 under VVoIP policy). This requirement addresses the function of the EBC which authenticates the AS-SIP-TLS signaling messages as being from an authorized source. DoD policy dictates that authentication be performed using DoD PKI certificates. This also applies to network hosts and elements. AS-SIP (and SIP on which it is based) is not a secure protocol. The information passed during call/session setup and teardown is in human readable plain text. To secure AS-SIP and SIP, TLS is used. TLS is PKI certificate based and is used for AS-SIP message encryption, authentication, and integrity validation. NOTE: Authentication is provided by validating the sending appliance’s public PKI certificate used to establish the TLS session. AS-SIP messages are not sent until the authenticated TLS session is established. NOTE: the methods used will be in accordance with the UCR. NoneUnauthorized access and use of the DISN NIPRNet IPVS system and/or the VVoIP system within the enclave.Information Assurance Officer

Checks: C-24042r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to drop (and not process) all packets except those that are authenticated as being from an authorized source as follows: > Authenticate outbound AS-SIP-TLS messages (packets) as being from the primary or backup LSC (or the site’s MFSS and is backup LSC) within the enclave. > Authenticate inbound AS-SIP-TLS messages (packets) as being from the EBC at the enclave’s assigned primary and secondary (backup) MFSS sites. NOTE: Authentication is provided by validating the sending appliance’s public PKI certificate used to establish the TLS session. AS-SIP messages are not sent until the authenticated TLS session is established. This is a finding in the event the EBC does not use DoD PKI to authenticate the source of AS-SIP-TLS packets.

Fix: F-20373r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to drop (and not process) all packets except those that are authenticated as being from an authorized source as follows: > Authenticate outbound AS-SIP-TLS messages (packets) as being from the primary or backup LSC (or the site’s MFSS and is backup LSC) within the enclave. > Authenticate inbound AS-SIP-TLS messages (packets) as being from the EBC at the enclave’s assigned primary and secondary (backup) MFSS sites. NOTE: Authentication is provided by validating the sending appliance’s public PKI certificate used to establish the TLS session. AS-SIP messages are not sent until the authenticated TLS session is established.

b

The DISN NIPRNet IPVS firewall (EBC) is NOT configured to drop (and not process) all signaling packets except those whose integrity is validated.

Medium - V-19668 - SV-21809r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6315 (DISN-IPVS)

Vuln IDs

V-19668

Rule IDs

SV-21809r1_rule

The validation of signaling packet integrity is required to ensure the packet has not been altered in transit. Packets can be altered in a couple of ways. The first is modification by uncontrollable network events such as bit errors and packet truncation that would cause the packet to contain erroneous information. Packets containing detectable errors must not be processed since the effect of doing so is unknown and most likely not good. The second could be modification by a man-in-the-middle. NOTE: The USR mandates the packets be hashed upon transmission and receipt using HMAC-SHA1-160 with 160 bit keys and the validation of the hash of the received packet against the transmitted hash. NoneInformation Assurance Officer

Checks: C-24044r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to drop (and not process) all signaling packets except those whose integrity is validated. This is a finding in the event the EBC does not validate the integrity of the received signaling packets.

Fix: F-20374r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to drop (and not process) all signaling packets except those whose integrity is validated. NOTE: HMAC-SHA1-160 with 160 bit keys is used for this purpose as directed by the UCR.

a

The DISN NIPRNet IPVS firewall (EBC) is NOT configured to validate the structure and validity of AS-SIP messages such that malformed messages or messages containing errors are dropped before action is taken on the contents.

Low - V-19669 - SV-21810r1_rule

RMF Control

Severity

L

CCI

Version

VVoIP 6320 (DISN-IPVS)

Vuln IDs

V-19669

Rule IDs

SV-21810r1_rule

Malformed AS_SIP messages as well as messages containing errors could be an indication that an adversary is attempting some form of attack or denial-of-service. Such an attack is called fuzzing. Fuzzing is the deliberate sending of signaling messages that contain errors in an attempt to cause the target device to react in an inappropriate manner, such as the device could fail causing a denial-of-service or could permit traffic to pass that it would not normally permit. In some cases a target can be flooded with fuzzed messages. As such the EBC must not act on any portion of a signaling message that contains errors. It is possible that a malformed or erroneous message could be sent by the signaling partner and be properly hashed for integrity.NoneInformation Assurance Officer

Checks: C-24046r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to validate the structure and validity of AS-SIP messages such that malformed messages or messages containing errors are dropped before action is taken on the contents. This is a finding in the event the EBC does not validate the correct format of the received AS-SIP message.

Fix: F-20375r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to validate the structure and validity of AS-SIP messages such that malformed messages or messages containing errors are dropped before action is taken on its contents.

b

All SIP and AS-SIP packets are not dropped by the DISN NIPRNet IPVS firewall (EBC) except those AS-SIP packets arriving on IP Port 5061 that are secured with TLS.

Medium - V-19670 - SV-21811r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6325 (DISN-IPVS)

Vuln IDs

V-19670

Rule IDs

SV-21811r1_rule

DISN NIPRNet IPVS PMO and the UCR require all session signaling across the DISN WAN and between the LSC and EBC to be secured with TLS. The standard IANA assigned IP port for SIP protected by TLS (SIP-TLS) is 5061. DoD PPSM requires that protocols traversing the DISN and DoD enclave boundaries use the standard IP port(s) for the specific protocol. Since AS-SIP is a standardized extension of the SIP protocol and since AS-SIP must be protected by TLS, AS-SIP-TLS must use IP port 5061. NoneInformation Assurance Officer

Checks: C-24048r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to drop the following signaling packets: > SIP packets arriving on IP port 5060 or 5061 > AS-SIP packets arriving on IP port 5060 > AS-SIP packets arriving on IP port 5061 not secured with TLS

Fix: F-20376r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to drop the following signaling packets: > SIP packets arriving on IP port 5060 or 5061 > AS-SIP packets arriving on IP port 5060 > AS-SIP packets arriving on IP port 5061 not secured with TLS

b

The DISN NIPRNet IPVS firewall (EBC) is NOT configured to manage IP port pinholes for the SRTP/SRTCP bearer streams based on the information in the AS-SIP-TLS messages.

Medium - V-19671 - SV-21812r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6330 (DISN-IPVS)

Vuln IDs

V-19671

Rule IDs

SV-21812r1_rule

We previously discussed the reasons why a special firewall is needed to protect the enclave if VVoIP is to traverse the boundary. (see VVoIP 1005 (GENERAL) under VVoIP policy) This requirement addresses the function of the EBC which manages the SRTP/SRTCP bearer streams. NOTE: The DISN IPVS PMO has determined that the EBC will pass the negotiated and encrypted SRTP/SRTCP bearer streams without decryption and inspection. This is because doing so will not provide a significant security benefit but would cause a significant delay with a resulting decrease in the quality of the communications. Encoded audio and video is difficult to impossible to determine if an attack is being perpetrated or if sensitive information is being improperly disclosed without reconstituting the analog audio and video signals and having a person listen and watch each communication. Due to the volume of communications, to do so would be nearly impossible. NoneThe inability to provide assured service for critical voice and video communications AND the inability to properly protect the enclave.Information Assurance Officer

Checks: C-24050r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to manage IP port pinholes for the SRTP/SRTCP bearer streams based on the information in the AS-SIP-TLS messages as follows: > Opens specific IP port pinholes on a per session basis for the SRTP/SRTCP bearer streams as negotiated by the communicating endpoints through the LSC and MFSS. > Closes the specifically opened IP port pinholes when the session is to be torn down. NOTE: “Opens specific IP port pinholes” means the EBC permits the flow of SRTP/SRTCP packets that have the specific IP port tags negotiated by the communicating endpoints through the LSC and MFSS and found in the AS-SIP-TLS messages. “Closes” means that once the session is signaled as completed, the EBC again denies all packets tagged with the IP ports previously opened.

Fix: F-20377r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to manage IP port pinholes for the SRTP/SRTCP bearer streams based on the information in the AS-SIP-TLS messages as follows: > Opens specific IP port pinholes on a per session basis for the SRTP/SRTCP bearer streams as negotiated by the communicating endpoints through the LSC and MFSS. > Closes the specifically opened IP port pinholes when the session is to be torn down. NOTE: “Opens specific IP port pinholes” means the EBC permits the flow of SRTP/SRTCP packets that have the specific IP port tags negotiated by the communicating endpoints through the LSC and MFSS and found in the AS-SIP-TLS messages. “Closes” means that once the session is signaled as completed, the EBC again denies all packets tagged with the IP ports previously opened.

b

The DISN NIPRNet IPVS firewall (EBC) is NOT configured to apply the appropriate NAT translations on the SRTP/SRTCP packets flowing across the enclave boundary between communicating endpoints based on the information contained in the AS-SIP messages that initiated the call.

Medium - V-19672 - SV-21813r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6335 (DISN-IPVS)

Vuln IDs

V-19672

Rule IDs

SV-21813r1_rule

The DISN NIPRNet IPVS utilizes SRTP/SRTCP bearer streams for the transport of voice and video information within and between enclaves during a VVoIP session. Additionally, the VVoIP system devices within the enclave are to be addressed using “private” or RFC 1918 addresses. These addresses are different than the addresses used on the NIPRNet. NIPRNet addresses are a subset of the overall public address space used by the Internet. As such, Network Address Translation (NAT) is required at the enclave boundary in order to transfer IP packets into and out of the enclave. The proper place for this to happen is in the EBC. This is because the EBC has knowledge of the IP addresses of the communicating endpoints based on the AS-SIP-TLS signaling messages. NOTE: The DISN IPVS PMO has determined that the EBC will pass the negotiated and encrypted SRTP/SRTCP bearer streams without decryption and inspection. This is because doing so will not provide a significant security benefit but would cause a significant delay with a resulting decrease in the quality of the communications. Encoded audio and video is difficult to impossible to determine if an attack is being perpetrated or if sensitive information is being improperly disclosed without reconstituting the analog audio and video signals and having a person listen and watch each communication. Due to the volume of communications, to do so would be nearly impossible. NOTE: The need to use NAT/NAPT is a given when transitioning a boundary when RFC 1918 addresses are used within the enclave. NoneThe inability to establish a VVoIP session across the enclave boundary to endpoints in other enclaves.Information Assurance Officer

Checks: C-24052r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to apply the appropriate NAT translations on the SRTP/SRTCP packets flowing across the enclave boundary between communicating endpoints based on the information contained in the AS-SIP messages that initiated the call. Determine if the EBC is providing the NAT function. This is a finding in the event NAT is not implemented on the EBC.

Fix: F-20378r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to apply the appropriate NAT translations on the SRTP/SRTCP packets flowing across the enclave boundary between communicating endpoints based on the information contained in the AS-SIP messages that initiated the call.

c

The DISN NIPRnet boundary Session Border Controller (SBC) must perform stateful inspection and packet authentication for all VVoIP traffic (inbound and outbound), and deny all other packets.

High - V-19673 - SV-21814r2_rule

RMF Control

Severity

H

CCI

Version

VVoIP 6340

Vuln IDs

V-19673

Rule IDs

SV-21814r2_rule

Once a pinhole is opened in the enclave boundary for a known session, the packets that are permitted to pass must be managed. If they are not properly managed, packets that are not part of a known session could traverse the pinhole thereby giving unauthorized access to the enclave’s LAN or connected hosts. One method for managing these packets is called stateful packet inspection. This inspection minimally validates that the permitted packets are part of a known session. This is a relatively weak but somewhat effective firewall function. A better method is to authenticate the source of the packet as coming from a known and authorized source. Information Assurance Officer

Checks: C-69773r1_chk

Verify the DISN NIPRnet boundary SBC is configured to deny all packets attempting to traverse the enclave boundary (inbound or outbound) through the IP port pinholes opened for VVoIP sessions that are not validated as being part of an established session. This requires a stateful inspection of the packets passed through the IP port pinholes or the authentication of the source of those packets. If packets that are not part of an established session can pass through the SBC, this is a finding. If stateful packet inspection or SRTP/SRTCP packet authentication is not configured, this is a finding. If stateful packet inspection is not configured but the source of the SRTP/SRTCP packets is authenticated from an authorized source, such as an internal endpoint or a remote DISN SBC, this is not a finding.

Fix: F-20379r2_fix

Configure the DISN NIPRnet SBC to deny all packets attempting to traverse the enclave boundary (inbound or outbound) through the IP port pinholes opened for known sessions, except those validated as being part of an established session. This requires a stateful inspection of the packets passed through the IP port pinholes or the authentication of the source of those packets.

c

The DISN NIPRnet boundary Session Border Controller (SBC) must deny all packets traversing the enclave boundary (inbound or outbound) through the IP port pinholes opened for VVoIP sessions, except RTP/RTCP, SRTP/SRTCP, or other protocol/flow established by signaling messages.

High - V-19674 - SV-21815r2_rule

RMF Control

Severity

H

CCI

Version

VVoIP 6345

Vuln IDs

V-19674

Rule IDs

SV-21815r2_rule

Once a pinhole is opened in the enclave boundary for a known session, the packets that are permitted to pass must be managed. If they are not properly managed, packets that are not part of a known session may traverse a pinhole, giving unauthorized access to the enclave’s LAN or connected hosts. Another method for managing packets through a pinhole opened for a VVoIP session is to only permit packets to pass matching the expected protocol type, such as RTP/RTCP or SRTP/SRTCP. If only RTP/RTCP or SRTP/SRTCP packets are permitted to pass, this reduces the exposure presented to the enclave by the open pinhole. Additional flows or protocols may be permitted if specifically required for an approved function and establishment is signaled or controlled by the signaling protocol in use by the system. An example of this is the transmission of H.281 far end camera control messages for a video conferencing session. Using AS-SIP for signaling, a UDP-based 6.4kbps H.224 over RTP control channel over which the H.281 far end camera control messages are transmitted might be established along with the media streams. This additional flow would require additional pinholes.Information Assurance Officer

Checks: C-24057r2_chk

Verify the DISN NIPRnet boundary SBC is configured to deny all packets attempting to traverse the enclave boundary (inbound or outbound) through the IP port pinholes opened for VVoIP sessions that are not an approved protocol. The allowed protocols are RTP/RTCP, SRTP/SRTCP, and other approved protocols/flows established by signaling messages. This requires filtering on protocol type. If the DISN NIPRnet boundary SBC does not deny all packets traversing the enclave boundary (inbound or outbound) through the IP port pinholes opened for VVoIP sessions, except approved protocols, this is a finding. If packets that are not RTP/RTCP or SRTP/SRTCP (or other approved packet type as established in the signaling messages) protocol packets can pass through the boundary SBC, this is a finding. NOTE: Additional flows or protocols may be permitted if specifically required for an approved function and their establishment is signaled or controlled by the signaling protocol in use by the system. An example of this would be the transmission of H.281 far end camera control messages for a video conferencing session. Using AS-SIP for signaling, a UDP-based 6.4kbps H.224 over RTP control channel over which the H.281 far end camera control messages are transmitted might be established along with the media streams. This additional flow would require additional pinholes.

Fix: F-20380r2_fix

Configure the DISN NIPRnet boundary SBC to drop any packet attempting to traverse the enclave boundary (inbound or outbound) through the IP port pinholes opened for VVoIP sessions that is not a RTP/RTCP or SRTP/SRTCP packet or other approved protocol / flow established by the signaling messages. NOTE: Additional flows or protocols may be permitted if specifically required for an approved function and their establishment is signaled or controlled by the signaling protocol in use by the system. An example of this would be the transmission of H.281 far end camera control messages for a video conferencing session. Using AS-SIP for signaling, a UDP-based 6.4kbps H.224 over RTP control channel over which the H.281 far end camera control messages are transmitted might be established along with the media streams. This additional flow would require additional pinholes.

b

The DISN NIPRNet IPVS firewall (EBC) is NOT configured to transmit a meaningful alarm message to the local EMS and DISN IPVS management system in the event of attempts to cause a denial-of-service or compromise the EBC or enclave.

Medium - V-19675 - SV-21816r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6350 (DISN-IPVS)

Vuln IDs

V-19675

Rule IDs

SV-21816r1_rule

Action cannot be taken to thwart an attempted denial-of-service or compromise if the SAs responsible for the operation of the EBC and/or the network defense operators are not alerted to the occurrence in real time.NoneInformation Assurance Officer

Checks: C-24058r1_chk

Interview the IAO to confirm compliance with the following requirement: In addition to the alarm messages required of any firewall by the NI STIG, ensure the DISN NIPRNet IPVS firewall (EBC) is configured to transmit a meaningful alarm message to the local EMS and DISN IPVS management system in the event of the following conditions: > Any number of malformed AS-SIP or SRTP/SRTCP messages are received that could indicate an attempt to compromise the EBC. > Excessive numbers of AS-SIP messages are received from any given IP address that could indicate an attempt to cause a denial-of-service. > Excessive numbers of messages that are dropped due to authentication or integrity check failures that might indicate an attempt to cause a denial-of-service or an attempt to effect a man in the middle attack. > Potentially others. This is a finding in the event the EBC does not generate and send alarms based on attempts to cause a denial-of-service or compromise the EBC or enclave.

Fix: F-20381r1_fix

Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to transmit meaningful alarm messages as required of any firewall by the NI STIG. Ensure the DISN NIPRNet IPVS firewall (EBC) is configured to transmit a meaningful alarm message to the local EMS and DISN IPVS management system in the event of the following conditions: > Any number of malformed AS-SIP or SRTP/SRTCP messages are received that could indicate an attempt to compromise the EBC. > Excessive numbers of AS-SIP messages are received from any given IP address that could indicate an attempt to cause a denial of service. > Excessive numbers of messages that are dropped due to authentication or integrity check failures that might indicate an attempt to cause a denial of service or an attempt to effect a man in the middle attack. > Potentially others.

b

The VVoIP system connects with a DISN IPVS (NPRNET or SIPRNet) but the LSC(s) is not configured to signal with a backup MFSS (or SS) in the event the primary cannot be reached.

Medium - V-19676 - SV-21817r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6400 (DISN-IPVS)

Vuln IDs

V-19676

Rule IDs

SV-21817r1_rule

Redundancy of equipment and associations is used in and IP network to increase the availability of a system. Multiple MFSSs in the DISN NIPRNet IPVS network and multiple SSs in the DISN SIPRNet IPVS network have been implemented in each theatre to provide network wide redundancy of their functions. They are intended to work in pairs such that one can provide its backbone services to multiple LSCs that are configured to use one as a primary and the other as a backup. This is necessary to the maintenance of backbone functionality in the event there is a circuit (network path) failure, a MFSS or SS failure, or one of the sites housing a MFSS or SS is lost or the MFSS or SS becomes unavailable. Based on this, when establishing a call on the WAN, each LSC must be configured to signal with a backup MFSS or SS in the event it cannot reach its primary. NoneInformation Assurance Officer

Checks: C-24060r1_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 each enclave containing one or more LSCs is assigned to, associated with, or serviced by two DISN IPVS core backbone systems as follows: > For DISN NIPRNet IPVS, each enclave will be serviced minimally by one primary and one secondary (backup) MFSS. > For DISN SIPRNet IPVS, each enclave will be serviced minimally by one primary and one secondary Soft Switch (SS) at the SIPRNET tier 0 routers. Determine to which backbone MFSSs or SSs the enclaves LSC(s) is assigned as primary and backup.

Fix: F-20382r1_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 each enclave containing one or more LSCs is assigned to, associated with, or serviced by two DISN IPVS core backbone systems as follows: > For DISN NIPRNet IPVS, each enclave will be serviced minimally by one primary and one secondary (backup) MFSS. > For DISN SIPRNet IPVS, each enclave will be serviced minimally by one primary and one secondary Soft Switch (SS) at the SIPRNET tier 0 routers.

b

The MFSS is NOT configured to synchronize minimally with a paired MFSS and/or others such that each may serve as a backup for the other when signaling with its assigned LSCs, thus reducing the reliability and survivability of the DISN IPVS network.

Medium - V-19677 - SV-21818r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 6405 (DISN-IPVS)

Vuln IDs

V-19677

Rule IDs

SV-21818r1_rule

MFSSs are critical to the operation of the DISN NIPRNet IPVS network. They broker the establishment of calls between enclaves. A MFSS provides the following functions: > Receives AS-SIP-TLS messages from other MFSSs and a specific set of regionally associated LSCs to act as a call routing manager across the backbone. > Sends AS-SIP-TLS messages to interrogate the ability of another MFSS or a LSC to receive a call, whether routine or priority. > Sends AS-SIP-TLS messages to manage the establishment of priority calls and the pre-emption of lower priority calls to LSCs and other MFSSs > Once a “trunk side” session request is received the MFSS determines if the destination is one of its assigned LSC’s. If so, it interrogates that LSC to determine if it can receive the call. If so, it signals to establish the call. If the destination is not one of its LSCs it signals with other MFSSs to locate the destination LSC and then the remote MFSS negotiates with its LSC. > Acts as a backup MFSS for LSCs assigned to other MFSSs as primary. As such, a LSC must be able to signal with a MFSS in order to establish any call across the DISN WAN. LSCs do not interact directly with LSCs. This hierarchical arrangement is required in order to be able to manage and establish priority calls and manage access circuit budgets. We established previously that each LSC must have a backup MFSS. In support of this function MFSSs must be operated in pairs with all the information about its assigned LSCs replicated across the pair. NoneReduced the reliability and survivability of the DISN IPVS network.Information Assurance Officer

Checks: C-24062r1_chk

Interview the IAO to confirm compliance with the following requirement: Ensure the MFSS is configured to synchronize minimally with a paired MFSS and/or others such that each may serve as a backup for the other when signaling with its assigned LSCs and regarding the overall operation of the DISN IPVS network and the negotiation of call establishment between enclaves. NOTE: We have already established that the local LSC portion of the MFSS requires a local backup LSC such that the ability to establish calls within the enclave and to local commercial network and emergency services is maintained. This requirement does not address redundancy or COOP within the enclave. Determine which other MFSS(s) is acting as backup for the MFSS under review. Additionally determine which LSCs are assigned this MFSS as primary and which LSCs are assigned this MFSS as backup.

Fix: F-20383r1_fix

Ensure each MFSS is configured to synchronize with a paired MFSS such that each may serve as a backup for the other when signaling with its assigned LSCs and regarding the overall operation of the DISN IPVS network and the negotiation of call establishment between enclaves.

b

The Fire and Emergency Services (FES) communications over a sites private Multi-Line Telephone Systems (MLTS) must provide the originating telephone number to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) or Automatic Location Identification (ALI) information.

Medium - V-21509 - SV-23718r2_rule

RMF Control

Severity

M

CCI

Version

VVT 2010 (GENERAL)

Vuln IDs

V-21509

Rule IDs

SV-23718r2_rule

The implementation of Enhanced F&ES telecommunications services requires that the emergency services answering point or call center be able to automatically locate the calling party in the event they are unable provide their location themselves. This is a two part process. First the telephone system must be able to provide the answering station with the telephone number from which the emergency call originated. This is Automatic Number Identification (ANI) information. The second step in the process is that this phone number must be correlated to a physical address or location. This is called Automatic Location Identification (ALI) information. ANI information comes from the telephone system controller. ALI information may come from an external database that associates the ANI information to the ALI information or the telephone system controller may maintain the ALI database internally. If the ALI database is internal to the telephone system controller, emergency services answering point or call center only needs to receive ALI information providing it contains the originating telephone number. For enterprise systems, the support for E911 by the enterprise LSC (or any remote LSC construct) is governed by FCC rules, as well as other federal, state, and local law. The design and implementation of all MLTS systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.Information Assurance OfficerInformation Assurance ManagerOther

Checks: C-25745r3_chk

Interview the IAO to validate compliance with the following requirement: Inspect the telephone system configuration to determine compliance with the requirement. Verity the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, is configured to provide the originating telephone number of an F&ES call to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) or Automatic Location Identification (ALI) information. If the originating telephone number of an F&ES call is not available or is not provided to the emergency services answering point or call center, this is a finding.

Fix: F-22298r2_fix

Configure the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, to provide the originating telephone number of an F&ES call to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) or Automatic Location Identification (ALI) information.

b

The Fire and Emergency Services (FES) communications over a sites private Multi-Line Telephone Systems (MLTS) must provide a direct callback telephone number and physical location of an FES caller to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) and extended Automatic Location Identification (ALI) information or access to an extended ALI database.

Medium - V-21510 - SV-23719r2_rule

RMF Control

Severity

M

CCI

Version

VVT 2015 (GENERAL)

Vuln IDs

V-21510

Rule IDs

SV-23719r2_rule

Under FCC rules and the laws of some states, the implementation of Enhanced F&ES telecommunications services requires that the emergency services answering point or call center must be automatically provided with enough location information so that emergency services personnel can locate the calling party within a specified radius at their exact location in the event they are unable provide their location themselves. This is a two-part process that is exacerbated if the call originates from a Multi-Line Telephone System (MLTS). Some of the FCC rules and state laws address the MLTS issue. For enterprise systems, the support for E911 by the enterprise LSC (or any remote LSC construct) is governed by FCC rules, as well as other federal, state, and local law. The design and implementation of all MLTS systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed. Public enhanced F&ES systems are implemented in conjunction with the local exchange carrier (LEC) using their central office switch (CO). When the designated F&ES number is dialed, the CO routes the call to the public F&ES answering point (PSAP) over special trunks that can provide the PSAP with the telephone number from which the emergency call originated and the geographic location of the originating telephone. The originating telephone number is provided as Automatic Number Identification (ANI) information. The geographic location of the originating telephone is provided as Automatic Location Identification (ALI) information. The ALI is generated from the ANI by looking up the ANI in a database. Typically this function is performed by the LEC and the ALI provided is the service delivery address for the telephone number. In some cases the ALI information is housed in a database at the PSAP or a at a third party provider such that the PSAP must make the “database dip” to identify the location of the caller. The information is regularly updated by the LEC based on new service deliveries and disconnections. This process does not go far enough if the originating telephone is behind (part of) a MLTS. An MLTS may serve a large building or may serve multiple buildings in a campus setting. It may also serve small or large remote sites that are geographically distant from the main MLTS switch. As discussed above, the normal process provides the address where the LEC delivers its phone service for the calling number. While this address will serve to get emergency services personnel to the lobby of a building or the front gate of a campus, it will not provide the exact location of the caller. This is where the federal and state MLTS related requirements come in. Under these rules, a MLTS operator and the system itself must provide complete ANI and ALI information to the answering point such that emergency services personnel can easily locate the caller. As such the MLTS must provide the exact location of the originating telephone minimally within a reasonably small area of it. The location information provided for telephones behind a MLTS is called Phone Switch-ALI (PS-ALI). To implement this, the MLTS must first be able to provide the F&ES answering station with the telephone number from which the emergency call originated via ANI. If the answering point is outside the MLTS, the number provided must be the exact Direct Inward Dialing (DID) number of the telephone placing the call so that the answering point can dial it directly. The number provided must not be that of an outbound trunk. Secondly, this phone number must be correlated to its physical address or location within the facility via PS-ALI. To implement PS-ALI, the owner/operator of a MLTS is responsible for maintaining an up-to-date database containing the telephone number (DID number and/or extension number) and physical location of each telephone attached to the MLTS. This database is then used to provide the PS-ALI information to the ALI database(s) accessed by the F&ES answering point. In association with each telephone and telephone number in the MLTS, the PS-ALI information contained in the database includes the following: - The address of the site containing the MLTS unless provided to the answering point by the LEC as part of its ANI/ALI information. - The name (or number) of the building in which the telephone is located. - The address of the building in which the telephone is located. - The floor in the building on which the telephone is located. - The area or quadrant of the floor where the telephone is located. - The room or cube number where the telephone is located. Additional information should be provided to the F&ES answering point and emergency services personnel in the form of up-to-date facility maps and floor plans. The maintenance of facility maps, floor plans, and PS-ALI information to keep them up-to-date is critical to life safety and facility protection and security. This can be an onerous process in light of changes in the facility and moves, adds, and changes within the MLTS. Maintaining accurate location information is exacerbated in a VoIP MLTS due to the ability of an IP phone to change its physical location within the LAN (and possibly beyond) while keeping its telephone number without specific intervention from, or knowledge of the MLTS operator. As such the PS_ALI database can quickly become inaccurate. A situation that could be life threatening. Automated systems can be used with a VoIP system and LAN to identify the general location of an IP phone within the facility based on the LAN switch and port to which the phone is connected. Once this information is obtained from the LAN, it is correlated with the documented location of the LAN switch and documented location of the outlet served by the switchport..Information Assurance OfficerInformation Assurance ManagerOther

Checks: C-25750r2_chk

Interview the IAO to validate compliance with the following requirement: Inspect the telephone system configuration or external database to determine compliance with the requirement. Verify the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, is configured to provide the originating telephone number and the physical location of an F&ES caller to the emergency services answering point through a transfer of Automatic Number Identification (ANI) and Phone Switch Automatic Location Identification (PS-ALI) information or the emergency services answering point is provided automated access to the required PS-ALI database. If the location of an F&ES caller is not is not provided to, or is not accessible by, the emergency services answering point or call center, this is a finding. NOTE: These requirements also apply to key telephone systems and installations where a single number has multiple appearances (appears on multiple telephones) such that individual instruments in the system can be identified.

Fix: F-22299r2_fix

Configure the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, to provide the originating telephone number and the physical location of an F&ES caller to the emergency services answering point through a transfer of Automatic Number Identification (ANI) and Phone Switch Automatic Location Identification (PS-ALI) information or the emergency services answering point is provided automated access to the required PS-ALI database.

b

The Fire and Emergency Services (FES) communications over a sites private Multi-Line Telephone Systems (MLTS) must route emergency calls as a priority call in a non-blocking manner.

Medium - V-21512 - SV-23721r2_rule

RMF Control

Severity

M

CCI

Version

VVT 2005 (GENERAL)

Vuln IDs

V-21512

Rule IDs

SV-23721r2_rule

When calling the designated F&ES telephone number, the call must go through no matter what the state of other calls in the system. As such, emergency calls must be treated as a priority call by the system. For enterprise systems, the support for E911 by the enterprise LSC (or any remote LSC construct) is governed by FCC rules, as well as other federal, state, and local law. The design and implementation of all MLTS systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.Information Assurance OfficerInformation Assurance Manager

Checks: C-25754r2_chk

Interview the IAO to validate compliance with the following requirement: Inspect the telephone system configuration and routing tables to determine compliance with the requirement. Verify the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, routes calls to the designated local emergency services number at the public and private emergency services answering point (PSAP) as a priority call in a non-blocking manner. If an emergency services number is not designated to access an emergency services answering point or call center whether internal to the local site or to another local agency or municipality, this is a finding. If calls to this number are not treated as a priority call in a non-blocking manner, this is also a finding. NOTE: In the event the F&ES calls are routed to a public entity outside the MLTS, the call must route to an internal emergency number in parallel with the external call. Both calls should have the same priority. This is so that the site can be aware of the emergency and assist the F&ES responders in reaching the location of the caller. F&ES calls may be routed to an internal on-site F&ES answering point providing the site maintains robust local police, fire, and medical services such that these can replace public services. In the event a public F&ES answering point is the primary answering point for the site, calls must be directly routed to it and not relayed via a local emergency answering point. A second call from the local emergency answering point should not be required to obtain emergency services from the public F&ES answering point unless the site maintains full and comparable police, fire, and medical services and its answering point is the primary. In the event a local private answering point is the primary answering point, and if this private answering point is not fully staffed on a 24-7 basis, the MLTS must route F&ES calls to the public answering point when the local answering point is not fully staffed, for example outside the normal working hours of the site.

Fix: F-22300r2_fix

Configure the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, to routes calls to the designated local emergency services number at the public or private emergency services answering point (PSAP) as a priority call in a non-blocking manner. Configure the telephone system to treat calls to the designated emergency services number as a priority call in a non-blocking manner.

b

Devices and applications using SIP or AS-SIP signaling are vulnerable to a cross site scripting attack.

Medium - V-21513 - SV-23722r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1980 (GENERAL)

Vuln IDs

V-21513

Rule IDs

SV-23722r1_rule

A cross site scripting vulnerability has been demonstrated in at least one SIP based IP phone. The vulnerability was demonstrated by adding scripting code to the From: field in the SIP invite. Upon receiving the invite, the embedded code was executed by a “vulnerable embedded web server” to download additional malicious code and affect an attack. A desktop demonstration of the vulnerability also exists on www.securityfocus.com under Bugtraq ID: 25987 that benignly pops up an alert box containing the word “HACK” on the user’s workstation after downloading a SIP invite. While this vulnerability was demonstrated on a specific IP phone it could potentially affect all SIP based endpoints or clients and their signaling partners. This vulnerability is a result of improper filtering or validation of the content of the various fields in the SIP invite and potentially the Session Description Protocol (SDP) portion of the invite. The injected code could cause all sorts of malicious code to be run on the target device which could be an endpoint (hard or soft), a session controller, or any other SIP signaling partner. Additionally this vulnerability may affect other applications other than VoIP that use SIP such as IM clients and others. A similar vulnerability would result if URLs embedded in SIP messages were launched automatically. VVoIP 1980 NoneDenial of Service and/or loss of confidentiality or integrity of the information or configuration stored on the target device and devices connected to it.Disable the ability of script engines or web browsers/servers on the device to process script code or URLs surreptitiously embedded in SIP/AS-SIP/SDP messages.Information Assurance Officer

Checks: C-25755r1_chk

Validate compliance with the following requirement: In the event SIP or AS-SIP is used for session signaling, ensure the SIP/AS-SIP/SDP interpreter/parser filters and validates the information in the signaling message fields such that the application does not process scripting statements of any kind or URLs embedded in the SIP message or the SDP packets. Obtain documentation from the system/device vendor proving that the system/device is not vulnerable to this exploit or how this vulnerability is mitigated. The IAO should maintain such documentation for inspection during a review. NOTE: a tool is needed to validate or test for compliance this requirement. Such a tool would need to send SIP or AS-SIP invites as used in the particular system under test containing scripting code. The tool would need to send repeated invites while embedding the scripting code into different message fields.

Fix: F-22301r1_fix

Implement, patch, or upgrade SIP/AS-SIP signaling agents (endpoints (hard or soft), session controllers, or any other SIP signaling partner or application that uses SIP) such that the SIP/AS-SIP/SDP interpreter/parser filters and validates the information in the signaling message fields such that the application/device does not process scripting statements of any kind or URLs embedded in the SIP message or the SDP packets. Obtain documentation from the system/device vendor proving that the system/device is not vulnerable to this exploit or how this vulnerability is mitigated. The IAO should maintain such documentation for inspection during a review. If necessary configure the system/device in accordance with the vendor mitigations. Alternately Disable the ability of script engines or web browsers/servers on the system/device to process script code or URLs surreptitiously embedded in SIP/AS-SIP/SDP messages.

b

Hardware based VVoIP or VTC endpoint web browser capabilities that permit the endpoint to browse the internet or intranet are NOT disabled.

Medium - V-21514 - SV-23723r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP/VTC 1610 (GENERAL)

Vuln IDs

V-21514

Rule IDs

SV-23723r1_rule

Permitting hardware based VVoIP or VTC endpoints to browse the internet or enterprise intranet freely opens the endpoint to the possibility of inadvertently downloading malicious code to the endpoint for which it may have no protection. VVoIP and VTC endpoints cannot typically support host based intrusion detection or anti-virus software. While the downloaded malicious code might not effect the endpoint itself, the endpoint could be used by the malicious code as a launching pad into the network and attached workstations or servers.VVoIP/VTC 1610NoneInadvertent access to malicious code for which there is no protection on the platform. Such malicious code could cause a denial of service or the loss of device configuration, log/history, or communications confidentiality or integrity.Limit or block web traffic (HTTP, HTTPS, etc) traffic from the VVoIP or VTC VLANs through the enclave boundary. Implementing ACLs in compliance with VVoIP 5600 should suffice as web protocols will be denied by default. Similar ACLs would be required for any implemented VTC VLANs.Information Assurance Officer

Checks: C-25756r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure hardware based VVoIP or VTC endpoint web browser capabilities that permit the endpoint to browse the internet or intranet are disabled unless such capabilities are specifically required for the proper function of the endpoint or to access specific external applications. Determine the web browsing capabilities of the hardware based VVoIP or VTC endpoints. This is a finding in the event the endpoint can access general web pages on the Internet or enterprise intranet other than approved external applications. NOTE: This requirement does not apply to limited web browsing capabilities required to access external applications and services that have been approved for accessibility on the endpoint and implemented by the enterprise.

Fix: F-22304r1_fix

Ensure hardware based VVoIP or VTC endpoint web browser capabilities that permit the endpoint to browse the internet or intranet are disabled unless such capabilities are specifically required for the proper function of the endpoint or to access specific external applications.

b

Hardware based VVoIP or IP-VTC endpoint contains a web server, the access to which is not restricted OR which is NOT disabled.

Medium - V-21515 - SV-23724r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP/VTC 1615 (GENERAL)

Vuln IDs

V-21515

Rule IDs

SV-23724r2_rule

Hardware based VVoIP and IP-VTC endpoints sometimes contain a web server for the implementation of various functions and features. In many cases these are used to configure the network settings or user preferences on the device. In some VVoIP phones, a user can access a missed call list, call history, or other information. If access to such a web server is not restricted to authorized entities, the device supporting it is subject to unauthorized access and compromise.NoneUnauthorized access to the platform potentially resulting in the injection of malicious code and/or denial of service or the loss of device configuration, log/history, or communications confidentiality or integrity.Information Assurance OfficerECSC-1

Checks: C-25758r1_chk

Interview the IAO to validate compliance with the following requirement: Ensure web servers embedded in hardware based VVoIP and IP-VTC endpoints restrict their accessibility to authorized devices through an authentication mechanism or minimally IP address filtering, or are otherwise disabled. Further ensure that if the connection is for direct user or administrative functions, the user is authenticated minimally with a username and password. This is a finding in the event the endpoint accepts HTTP connections from any source, except those that are specifically authorized access.

Fix: F-22305r1_fix

Ensure web servers embedded in hardware based VVoIP and IP-VTC endpoints restrict their accessibility to authorized devices through an authentication mechanism or minimally IP address filtering, or are otherwise disabled. Configure the endpoint’s web server to authenticate or minimally filter by IP address all automated machine to machine connections. Configure the web server to minimally authenticate users and administrators using a username and password.

b

Eight hours of backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support special-C2 users.

Medium - V-21516 - SV-23726r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1221 (Special-C2)

Vuln IDs

V-21516

Rule IDs

SV-23726r2_rule

Unified Capabilities (UC) users require different levels of capability depending upon command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power. Interrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering uninterruptible power supply (UPS) power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. As such, all elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.Information Assurance OfficerInformation Assurance ManagerCOPS-2

Checks: C-25761r2_chk

Inspect the VVoIP system design for evidence of continuous backup power to the infrastructure and command and control (C2) users. Ensure a UPS system is provided for all parts of the VVoIP infrastructure, including the core LSC/MFSS, adjunct systems providing critical services, SBC, CER, LAN elements, and endpoints as follows: - All VVoIP system devices including portions of the LAN that directly support one or more special-C2 users are minimally provided 8 hours UPS. - All special-C2 user VVoIP endpoints relying on Power over Ethernet (PoE) must have power sourcing equipment (PSE) sized to support the asset and endpoints by the UPS for a minimum 8 hours. - All special-C2 user VVoIP endpoints without PoE must be minimally provided 8 hours UPS. - UPS systems (battery at a minimum; plus optional generator) supplying infrastructure power supporting special-C2 and C2 users must also support environmental power (HVAC) such that equipment failures are prevented. - In no case should a UPS system immediately, or within a short time, drop power to the supported equipment when primary power is removed. This would indicate an undersized or defective UPS unit. Determine if the infrastructure assets being reviewed directly support one or more special-C2 user. If no special-C2 users are supported, this requirement is not applicable. If special-C2 users are supported, determine if assets are provided with 8 hours of backup power. If 8 hours of backup power is not provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support special-C2 users, this is a finding.

Fix: F-22306r2_fix

Ensure a UPS system is provided for all parts of the VVoIP infrastructure, including the core LSC/MFSS, adjunct systems providing critical services, SBC, CER, LAN elements, and endpoints. All VVoIP system devices including voice endpoints and portions of the LAN that directly support one or more special-C2 users must be minimally provided 8 hours UPS. Document the VVoIP system design with UPS implementation. Note: UPS systems supplying power to infrastructure supporting special-C2 and C2 users must also support environmental power to prevent equipment failures. This support must be commensurate with the users supported (8 or 2 hours as appropriate).

b

Network elements configuration supporting VoIP services must provide redundancy supporting command and control (C2) assured services and Fire and Emergency Services (FES) communications.

Medium - V-21517 - SV-23729r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5111

Vuln IDs

V-21517

Rule IDs

SV-23729r2_rule

Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. The high availability and reliability required for Special-C2 and C2 users is achieved in part by redundancy within the LAN network elements. Policy sets the minimum requirements for the availability and reliability of VVoIP systems Special-C2 users at 99.999 percent, C2 users at 99.997 percent, and C2 Routine only users (C2R) and non-C2 users at 99.9 percent. Voice services in support of high-priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DoD VVoIP implementations are in the Unified Capabilities Requirements (UCR), specifying assured services supporting DoD IP-based voice services. Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering from network failures quickly and maintaining the required QoS for existing services.Reduced to CAT III when the network elements do not directly support Special-C2 and C2 users.Information Assurance Officer

Checks: C-25770r2_chk

If the network elements do not support a minimum of 96 instruments, this is not applicable. Review the network elements configuration supporting VoIP services to provide redundancy supporting C2 assured services and FES communications. Visually confirm the routing and switching network devices are redundant as follows: - Dual Power Supplies - Each platform must have a minimum of two power supplies and the loss of a single power supply shall not cause any loss of functions within the chassis. - Dual Processors (Control Supervisors) - Each chassis shall support dual control processors and failure of any one processor shall not cause any loss of functions within the chassis. - Termination Sparing - Each chassis shall support a (N + 1) sparing capability minimally for available Ethernet modules used to terminate to an IP subscriber. - Protocol Redundancy - Each routing device shall support protocols allowing for dynamic rerouting. - Backplane Redundancy – each switching platform shall support a redundant (1 + 1) switching fabric or backplane and 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. Alternately, a secondary product may be added to provide redundancy to the primary product when redundant protocols are implemented such that the failover over to the secondary product must not result in any lost calls. Additionally, test the redundancy failover capability. While it is possible to unplug power cords and take other measures to test the failover capabilities, this is not recommended and must not be done in a production network unless scheduled for off duty hours. If required failover capability is tested and fails, this is a finding. If the network elements configuration supporting VoIP services does not provide the redundancy conditions above to support C2 assured services and FES communications, this is a finding.

Fix: F-22309r2_fix

Configure the network elements supporting VoIP services to provide redundancy supporting C2 assured services and FES communications. Ensure the routing and switching network devices have redundant capability and configured to implement as follows: - Dual Power Supplies - each platform must have a minimum of two power supplies and the loss of a single power supply shall not cause any loss of functions within the chassis. - Dual Processors (Control Supervisors) - each chassis shall support dual control processors and failure of any one processor shall not cause any loss of functions within the chassis. - Termination Sparing - each chassis shall support a (N + 1) sparing capability minimally for available Ethernet modules used to terminate to an IP subscriber. - Protocol Redundancy - each routing device shall support protocols allowing for dynamic rerouting. - Backplane Redundancy - Each switching platform shall support a redundant (1 + 1) switching fabric or backplane and 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. Alternately, a secondary product may be added to provide redundancy to the primary product when redundant protocols are implemented such that the failover over to the secondary product must not result in any lost calls.

b

Network elements configuration supporting VoIP services must interconnect redundant uplinks following physically diverse paths to physically diverse network elements in the layer above with support for the full bandwidth handled by the network element using routing protocols facilitating failover.

Medium - V-21518 - SV-23730r2_rule

RMF Control

Severity

M

CCI

Version

VVoIP 5116

Vuln IDs

V-21518

Rule IDs

SV-23730r2_rule

Policy sets the minimum requirements for the availability and reliability of VoIP systems and the supporting LAN with emphasis on C2 communications. The high availability and reliability required for Special-C2 and C2 users is achieved in part by interconnecting LAN network elements with redundant uplinks via geographically diverse paths. The core layer connects to the distribution layer below it, which then connects to the access layer below it. Voice services in support of high-priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DoD VVoIP implementations are in the Unified Capabilities Requirements (UCR), specifying assured services supporting DoD IP-based voice services. Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering quickly from network failures quickly and maintaining the required QoS for existing services. Reduced to CAT III when the network elements do not directly support Special-C2 and C2 users.Information Assurance Officer

Checks: C-25773r2_chk

If the network elements do not support a minimum of 96 instruments, this is not applicable. If the network elements are deployed in a LAN that covers an extremely small geographical area in a single physical location, this is not applicable. To meet the applicability for a geographical area, most users must be within 100 meters cabling distance of the core equipment, and the access layer switches must not be separated from the single central core location. Confirm the network elements configuration supporting VoIP services to interconnect redundant uplinks following physically diverse paths to physically diverse network elements in the layer above with support for the full bandwidth handled by the network element using routing protocols facilitating failover. If the network elements supporting VoIP services do not connect redundant uplinks following physically diverse paths to physically diverse network elements in the layer above, this is a finding. If the network elements configuration does not support the full bandwidth handled by the network element using routing protocols facilitating failover, this is a finding.

Fix: F-22310r2_fix

Configure the network elements supporting VoIP services to interconnect redundant uplinks following physically diverse paths to physically diverse network elements in the layer above. Configure the network elements to support the full bandwidth handled by the network element using routing protocols facilitating failover.

b

Activation/deactivation of and permission to use the extension mobility feature is not properly controlled.

Medium - V-21520 - SV-23732r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1670 (GENERAL)

Vuln IDs

V-21520

Rule IDs

SV-23732r1_rule

Extension mobility is a feature of a VVoIP system that permits a person to transfer their phone number extension and phone features (or configuration) to a phone that is not in their normal workspace. This is useful when a person is visiting a remote office away from their normal office and typically functions within an established enterprise wide VVoIP system where the system is designed as a contiguous system. In this case, the system is typically a single vendor solution. The system might be within one LAN/CAN may include multiple LAN/CANs at multiple interconnected sites. To activate this feature, the user approaches a phone that is not their regular phone and identifies themselves to the phone system via a username, password, pin, code, or some combination of these. Upon validation, the system configuration manager will configure the temporary phone to match the configuration of the user’s regular phone. Minimally, the phone number is transferred and possibly some or all of the user’s speed dial numbers and other personal preferences. This capability is dependant upon the capabilities of the temporary phone. Once activated the user’s inbound calls are directed to the temporary location. The user’s regular phone may or may not maintain its normal capabilities and also may also answer inbound calls. NOTE: This feature has nothing to do with LAN access control and is not related to moving physical phones/endpoints/instruments. The phone that is already in the temporary location is already authorized on the LAN and registered with the LSC. Moving phones requires pre-authorization and pre-configuration of the LAN access control mechanisms, potentially including the LSC. This feature should not be used to permanently move users from one office to another. NOTE: Extension mobility is similar to but not the same as forwarding ones calls. Forwarding is typically activated from the user’s normal phone or their user preferences configuration settings. Forwarding is therefore pre-set to a known location. Extension mobility is typically activated from the remote location and is activated upon arrival at that location. Extension mobility poses some vulnerabilities to the VVoIP system, user’s profile information, and conversations if not properly controlled. Extension mobility should be available only to those individuals that need to use the feature. There should be a configurable checkbox that enables/disables the feature within the configuration of the user’s normal phone or within the user’s profile. Making the feature available to all users all of the time broadens the exposure for potential compromise of other user’s profile information or conversations. Activation of the feature must not be via a feature button on the temporary phone or a commonly known code, either of which might be used along with the phone number to be transferred. This would leave all regular user’s phones vulnerable to anybody activating the feature from anywhere in the system to eavesdrop or collect information. Extension mobility transfer in some systems may have no time limitation. This means the temporary user’s phone configuration, preferences, speed dial information, and phone calls are available at the temporary phone until the transfer feature is deactivated. In the event the user does not specifically deactivate the transfer when they leave, the info is there until someone else deactivates it or another transfer is activated. While users should have the capability to deactivate the transfer at their discretion when they leave, the system should automatically deactivate the feature at some predetermined time of day or after a time period of inactivity. A timed deactivation might use a period of inactivity of one or two hours. Activation of the feature might be for a given period of time, such as eight hours, or for a user configurable time period set when they activate the feature. A time of day deactivation could be set to deactivate all such transfers at midnight each day. This feature might also be used as a backup for other methods. In the event controls such as those discussed above are not available, an extension mobility feature should be deactivated if the feature is provided or supported by the system. NoneInformation Assurance Officer

Checks: C-25775r1_chk

Interview the IAO to validate compliance with the following requirement: In the event an extension mobility feature is available and not deactivated, ensure the following controls are implemented: > The feature is enabled/disabled (permitted) on a per user basis. > Feature activation requires user authentication minimally using a user unique PIN; preferably including a unique user-ID; AND is NOT activated via a common activation code or feature button on the phone in conjunction with the phone number of the regular phone whose configuration is to be transferred. > The user has the capability manually disable the feature at their discretion when they no longer need it such as when they leave the temporary location. > The user may have the capability to set duration when activating the feature. (Optional) > The feature automatically deactivate based on a period of inactivity or the time of day. Determine if an extension mobility feature is available and not deactivated, that is it is usable. Determine the methods of activation and deactivation. This is a finding in the event one or more of the controls listed above is not available except for the optional one. NOTE: This check and requirement will most likely be split into its components during a future bi-monthly release cycle.

Fix: F-22311r1_fix

Disable extension mobility OR Implement / configure extension mobility feature controls as follows: > The feature is enabled/disabled (permitted) on a per user basis. > Feature activation requires user authentication minimally using a user unique PIN; preferably including a unique user-ID; AND is NOT activated via a common activation code or feature button on the phone in conjunction with the phone number of the regular phone whose configuration is to be transferred. > The user has the capability manually disable the feature at their discretion when they no longer need it such as when they leave the temporary location. > The user may have the capability to set duration when activating the feature. (Optional) > The feature automatically deactivate based on a period of inactivity or the time of day.

b

Two hours of backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support Immediate or Priority precedence C2 users.

Medium - V-57951 - SV-72381r1_rule

RMF Control

Severity

M

CCI

Version

VVoIP 1222 (C2)

Vuln IDs

V-57951

Rule IDs

SV-72381r1_rule

Unified Capabilities (UC) users require different levels of capability depending upon command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power. Interrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering UPS power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. As such, all elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.Information Assurance OfficerCOPS-2

Checks: C-58727r1_chk

Inspect the VVoIP system design for evidence of continuous backup power to the infrastructure and command and control (C2) users. Ensure a UPS system is provided for all parts of the VVoIP infrastructure, including the core LSC/MFSS, adjunct systems providing critical services, SBC, CER, LAN elements, and endpoints as follows: - All VVoIP system devices including portions of the LAN that directly support one or more C2 users are minimally provided 2 hours UPS. - All C2 user VVoIP endpoints relying on Power over Ethernet (PoE) must have power sourcing equipment (PSE) sized to support the asset and endpoints by the UPS for a minimum 2 hours. - All C2 user VVoIP endpoints without PoE must be minimally provided 2 hours UPS. - UPS systems (battery at a minimum; plus optional generator) supplying power to infrastructure that supports special-C2 and C2 users must also support environmental power (HVAC) such that equipment failures are prevented. - In no case should a UPS system immediately, or within a short time, drop power to the supported equipment when primary power is removed. This would indicate an undersized or defective UPS unit. Determine if the infrastructure assets being reviewed directly support one or more C2 users. If no C2 users are supported, this requirement is not applicable. If C2 users are supported, determine if assets are provided with 2 hours of backup power. If 2 hours of backup power is not provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support C2 users, this is a finding.

Fix: F-63159r1_fix

Ensure an UPS system is provided for all parts of the VVoIP infrastructure, including the core LSC/MFSS, adjunct systems providing critical services, SBC, CER, LAN elements, and endpoints. All VVoIP system devices including voice endpoints and portions of the LAN that directly support one or more C2 users must be minimally provided 2 hours UPS. Document the VVoIP system design with UPS implementation. Note: UPS systems supplying power to infrastructure supporting special-C2 and C2 users must also support environmental power to prevent equipment failures. This support must be commensurate with the users supported (8 or 2 hours as appropriate).

a

Sufficient backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support non-C2 user accessible endpoints for emergency life-safety and security calls.

Low - V-57953 - SV-72383r1_rule

RMF Control

Severity

L

CCI

Version

VVoIP 1223 (Non-C2)

Vuln IDs

V-57953

Rule IDs

SV-72383r1_rule

Unified Capabilities (UC) users require different levels of capability depending upon command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power. Interrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering UPS system power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPSs, communications availability is reduced. As such, all elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.Information Assurance OfficerCOPS-2

Checks: C-58729r1_chk

Inspect the VVoIP system design for evidence of continuous backup power to the infrastructure and command and control (C2) users. Ensure a UPS system is provided for all parts of the VVoIP infrastructure, including the core LSC/MFSS, adjunct systems providing critical services, SBC, CER, LAN elements, and endpoints as follows: - All VVoIP system devices including portions of the LAN that supports non-C2 users are provided 15 minutes of UPS in support of emergency life-safety and security communications during a power failure. - In no case should a UPS system immediately, or within a short time, drop power to the supported equipment when primary power is removed. This would indicate an undersized or defective UPS unit. Determine if the infrastructure assets being reviewed support non-C2 users. If non-C2 users are supported and a 15 minutes of backup power is not provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints for emergency life-safety and security calls, this is a finding. NOTE: The requirement for UPS support to non-C2 user communications is negated when such users have an alternate reliable means of communicating in such situations. A suitable alternative would be a policy and SOP in effect requiring users to evacuate the facility to a location where mobile communications capability is available and acceptable.

Fix: F-63161r1_fix

Ensure a UPS system is provided for all parts of the VVoIP infrastructure, including the core LSC/MFSS, adjunct systems providing critical services, SBC, CER, LAN elements, and endpoints. All VVoIP system devices including portions of the LAN supporting non-C2 users are provided a minimum 15 minutes of UPS in support of emergency life-safety and security communications during a power failure. Note: The 15 minutes of UPS mandated by this requirement is a minimum. Backup times of 30-60 minutes are preferred. UPS systems supplying power to infrastructure supporting non-C2 users should also support environmental power to prevent equipment failures.

Content changes 58

Checks: C-23713r2_chk

Fix: F-20189r2_fix

Generate Mitigation Statement:

Checks: C-23714r1_chk

Fix: F-20190r1_fix

Generate Mitigation Statement:

Checks: C-23716r1_chk

Fix: F-20191r1_fix

Generate Mitigation Statement:

Checks: C-23917r1_chk

Fix: F-20328r1_fix

Generate Mitigation Statement:

Checks: C-23918r1_chk

Fix: F-20329r1_fix

Generate Mitigation Statement:

Checks: C-23919r1_chk

Fix: F-20330r1_fix

Generate Mitigation Statement:

Checks: C-23920r2_chk

Fix: F-20331r2_fix

Generate Mitigation Statement:

Checks: C-23948r1_chk

Fix: F-20332r1_fix

Generate Mitigation Statement:

Checks: C-23951r1_chk

Fix: F-20333r1_fix

Generate Mitigation Statement:

Checks: C-23954r2_chk

Fix: F-20334r2_fix

Generate Mitigation Statement:

Checks: C-23955r1_chk

Fix: F-20335r1_fix

Generate Mitigation Statement:

Checks: C-23958r2_chk

Fix: F-20336r2_fix

Generate Mitigation Statement:

Checks: C-23959r2_chk

Fix: F-20337r2_fix

Generate Mitigation Statement:

Checks: C-23960r1_chk

Fix: F-20338r1_fix

Generate Mitigation Statement:

Checks: C-23961r2_chk

Fix: F-20339r2_fix

Generate Mitigation Statement:

Checks: C-23964r2_chk

Fix: F-20340r2_fix

Generate Mitigation Statement:

Checks: C-23967r2_chk

Fix: F-20341r2_fix

Generate Mitigation Statement:

Checks: C-23970r2_chk

Fix: F-20342r2_fix

Generate Mitigation Statement:

Checks: C-23973r2_chk

Fix: F-20343r2_fix

Generate Mitigation Statement:

Checks: C-23976r2_chk

Fix: F-20344r2_fix

Generate Mitigation Statement:

Checks: C-23982r2_chk

Fix: F-20346r2_fix

Generate Mitigation Statement:

Checks: C-23987r2_chk

Fix: F-20347r2_fix

Generate Mitigation Statement:

Checks: C-23988r2_chk

Fix: F-20348r2_fix

Generate Mitigation Statement:

Checks: C-23991r1_chk

Fix: F-20349r1_fix

Generate Mitigation Statement:

Checks: C-23993r1_chk

Fix: F-20350r1_fix

Generate Mitigation Statement:

Checks: C-23995r1_chk

Fix: F-20351r1_fix

Generate Mitigation Statement:

Checks: C-23997r1_chk