kriterion 0.0.1

data/standards/stig_voice_and_video_over_internet_protocol_vvoip_policy.json

@@ -0,0 +1,407 @@
+{
+  "name": "stig_voice_and_video_over_internet_protocol_vvoip_policy",
+  "date": "2010-08-17",
+  "description": "None",
+  "title": "VOICE and VIDEO over INTERNET PROTOCOL (VVoIP) POLICY SECURITY TECHNICAL IMPLEMENTATION GUIDE ",
+  "version": "None",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-19444",
+      "title": "A unified messaging / mail, text-to-speech feature is enabled without providing proper CAC based authentication and access control to email and the sensitive information it contains.",
+      "description": "Unified messaging / mail 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 CAC/PKI based authentication of the user before they are granted access to their email account. Additionally, CAC based PKI certificates are required to decrypt encrypted email. CAC based authentication is not available when using a standard telephone. While some organizations might implement CAC 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-CAC 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. Due to these two issues email should not be accessible via the voicemail / unified messaging / mail text-to-speech feature in DoD. That said, this issue does not apply to DoD issued PDA/PED devices that provide CAC authenticated access to email. An example of such a device is the CAC enabled Blackberry. In this case, access to unified mail voicemail would be via the CAC 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. Wireless Bluetooth earphones or headsets are vulnerable. Guidance for their use can be found in the Wireless STIG. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19445",
+      "title": "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",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19446",
+      "title": "UN-authorized VVoIP instruments are registered with the LSC and are operational",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19624",
+      "title": "An Auto-answer feature is not properly disabled.",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19625",
+      "title": "PC presentation or application sharing capabilities are not properly limited.",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19626",
+      "title": "A PC Collaboration application does not identify all connected parties.",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19627",
+      "title": "Remote access VoIP is not properly routed to the VoIP VLAN.",
+      "description": "In addition to complying with the STIGs and VPN requirements for remotely connected PCs,  there is an additional requirement for PC soft-phone and UC applications using the VPN. Soft-phone 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19628",
+      "title": "VVoIP component(s) are NOT addressed using the defined dedicated VVoIP system addresses",
+      "description": "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. \n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19629",
+      "title": "VVoIP core components use random address assignment via DHCP and are not statically addressed",
+      "description": "Assigning static addresses to core VVoIP devices permits tighter control using ACLs on firewalls and routers to help in the protection of these devices.\n\nNOTE: 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19630",
+      "title": "VVoIP endpoints receive improper IP address assignment/configuration information or receive it from a DHCP server that is NOT dedicated to the VVoIP system",
+      "description": "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. Ideally this means that there would be a DHCP server dedicated to providing IP address and configuration information to the VVoIP endpoints which is separate from that providing IP address and configuration information to data hosts (workstations etc). That is to say that a DHCP server serving VVoIP devices needs to be in the V_VUC domain i.e., same address space and VLAN(s). This alleviates the need to route DHCP requests into the data environment on the LAN which would degrade the separation of the VVoIP environment and the Data environment. \n\nNOTE: The best practice is to manually assign addresses when authorizing the instrument by generating its configuration file.\n\nIn 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).\n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19631",
+      "title": "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).",
+      "description": "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.\n\nIndividual 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.\n\nPermitting 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.\n\nNOTE: 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19632",
+      "title": "Logical or physical interfaces (VLAN/subnets or direct connect physical interfaces with discrete subnets) have not been established/configured on the VVoIP core routing devices for the VVoIP core equipment in support of access and traffic control for the VVoIP system components.",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19633",
+      "title": "The required VVoIP endpoint VLANs are NOT configured on this network element",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19634",
+      "title": "VLANs established for the VVoIP system are NOT pruned from trunks and/or interfaces that are not required to carry the VVoIP traffic",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19635",
+      "title": "A deny-by-default ACL  is not implemented on all VVoIP endpoint (hardware and software) VLAN interface(s) on  the VVoIP core routing device(s) (as defined in the VVoIP system ACL design) to properly control VVoIP endpoint access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system \n \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19636",
+      "title": "A deny-by-default ACL  is not implemented on all VVoIP endpoint (hardware and software) VLAN interface(s) on the VVoIP routing device(s) other than at the core (as defined in the VVoIP system ACL design) to properly control VVoIP endpoint access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19637",
+      "title": "A deny-by-default ACL  is not implemented on the VVoIP Local Session Controller (LSC) VLAN interface(s) on the VVoIP routing device(s) supporting the VVoIP system core (as defined in the VVoIP system ACL design) to properly control VVoIP LSC access and traffic flow. ",
+      "description": "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 / 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 VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19638",
+      "title": "A deny-by-default ACL is not implemented on the VVoIP Media Gateway (MG) VLAN interface(s) on the VVoIP routing device(s) supporting the VVoIP system core (as defined in the VVoIP system ACL design) to properly control VVoIP LSC access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19639",
+      "title": "A deny-by-default ACL is not implemented on the VVoIP Signaling Gateway (SG)VLAN interface(s) on the VVoIP routing device(s) supporting the VVoIP system core (as defined in the VVoIP system ACL design) to properly control VVoIP LSC access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19640",
+      "title": "A deny-by-default ACL is not implemented on the VVoIP Edge Boundary Controller (EBC)  VLAN interface(s) on the VVoIP routing device(s) supporting the VVoIP system core (as defined in the VVoIP system ACL design) to properly control VVoIP LSC access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19642",
+      "title": "A deny-by-default ACL is not implemented on the VVoIP Voicemail / Unified Messaging Server(s) VLAN interface(s) on the VVoIP routing device(s) supporting the VVoIP system core (as defined in the VVoIP system ACL design) to properly control VVoIP LSC access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19643",
+      "title": "A deny-by-default ACL is not implemented on the VVoIP Unified Communications Server(s) VLAN interface(s) on the VVoIP routing device(s) supporting the VVoIP system core (as defined in the VVoIP system ACL design) to properly control VVoIP LSC access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19644",
+      "title": "A deny-by-default ACL is not implemented on the VVoIP system management VLAN interface(s) on the VVoIP routing device(s) supporting the VVoIP system core (as defined in the VVoIP system ACL design) to properly control VVoIP LSC access and traffic flow. ",
+      "description": "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 / subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19645",
+      "title": "The implementation of Unified Mail services degrades the separation between the voice and data protection zones (VLANs). ",
+      "description": "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. \n\nSince 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. \n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19646",
+      "title": "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.  ",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19647",
+      "title": "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.",
+      "description": "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.  \n\nThese 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.\n\nNOTE: 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.\n\nThe 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.\n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19648",
+      "title": "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.” ",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19649",
+      "title": "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. ",
+      "description": "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. \n\nNOTE: 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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19650",
+      "title": "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.",
+      "description": "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. \n\nNOTE: 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. \n\nNOTE: 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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19651",
+      "title": "A LAN access switchport supporting a VVoIP or VTC endpoint containing a PC port that is required to be disabled is not configured such that the switch’s “unused” VLAN is assigned as the endpoint’s “default data” VLAN. ",
+      "description": "A PC port on a VVoIP or VTC endpoint that is not intended for regular use is required to be disabled.  Unused LAN access switchports and LAN drops are also to be disabled per the Network Infrastructure STIG. From the Network Infrastructure Checklist NET1435 vulnerability discussion: “It is possible that a disabled port that is assigned to a user or management VLAN becomes enabled by accident or by an attacker and as a result gains access to that VLAN as a member.” The resulting requirement is: “ensure disabled ports are placed in an unused VLAN (do not use VLAN 1 ).” Similarly, a PC port on a VVoIP or VTC endpoint that is disabled may become “un-disabled” (activated). If this were to occur, and the switchport is statically assigned to the VVoIP or VTC VLAN, the connected device, PC or otherwise would have direct access to the VLAN that the VVoIP or VTC endpoint is configured to use and thereby compromising it. This could provide unauthorized access to the VVoIP or VTC traffic, endpoints, and core control devices. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19652",
+      "title": "The appropriate number of pre-authorized MAC addresses are not statically assigned on a LAN access switchport for the pre-authorized VVoIP or VTC endpoints and their daisy chained devices OR the correct maximum number of MAC addresses that can be dynamically learned on a given switch port is NOT limited to the minimum number that is required to support the devices that are authorized to connect.",
+      "description": "The Network Infrastructure (NI) STIG provides DoD policy for the use of “port security” or LAN access control on LAN access switchports. One of the methods is MAC based port security which limits the number of devices that can be connected to a LAN drop and LAN access switchport thereby protecting the LAN by providing a measure of access control. Allowing too many MAC addresses on a switch port could allow a mini-hub or switch to be added to the voice VLAN port or PC/data port on a VVoIP  or VTC endpoint to which additional unauthorized devices or workstations to be connected. Thus, the entire VVoIP or VTC systems or the LAN may be compromised. This requirement works in association with the NI STIG requirements on MAC based port security. In some cases this requirement might conflict with or modify the requirements contained therein. This is because the focus of the NI STIG is data networks where typically only one data device is authorized to connect to any given LAN drop. This follows through for VVoIP or VTC endpoints providing the workspace in which they are to be installed is 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 LAN access switchport. In such a scenario, it is best practice to limit the devices that are permitted to connect to any given LAN drop/switchport combination to one. There are two methods for effecting this limitation. The first is to statically map the MAC address of a pre-authorized device into the configuration of the PAN access switchport. The second method is called sticky (MAC based) port security in which the MAC address of the first device to connect to the switchport is learned and added to the configuration. This becomes the authorized device. Sticky port security requires that 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 a PC (or other device) to share the same LAN drop. This has several advantages. First, a VVoIP or VTC endpoint can be added to a LAN that heretofore only supported PCs without having to run additional cable or activate additional LAN drops. This provides a cost savings in both initial installation and operating costs for the LAN infrastructure. This is because this method reduces the number of active LAN access switchports thereby reducing energy consumption. This reduction not only reduces the energy needed to operate the LAN equipment but the energy required to cool the equipment is reduced thereby providing another reduction (or lack of increase) in energy usage and operating cost. Sharing LAN drops is green. There are other devices such as access control devices that can also share a LAN drop. It is possible to share a single LAN drop with a VVoIP endpoint, a desktop VTC endpoint, and a PC. The following limitations for MAC based port security are to be implemented to support VVoIP or VTC endpoints in various scenarios: > A single authorized VVoIP or VTC endpoint on a LAN drop/switchport requires one MAC to be statically configured or the learned maximum set to one whether it provides a PC port or not. In this case the PC port is disabled. Connecting a device to the PC port will cause an alarm. > A single VVoIP or VTC endpoint on a LAN drop/switchport that provides a PC port to which a PC will be connected will require two statically mapped MAC addresses or a 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. > In the event a VVoIP endpoint, VTC endpoint, and a PC are to be daisy chained on one LAN drop/switchport and switchport, the switchport will need to be configured for 3 statically mapped addresses or a maximum of 5 dynamically learned MAC addresses. This is because both the VVoIP and VTC endpoints will typically be assigned to the VVoIP VLAN due to switchport mode configuration limitations and both endpoints may be learned twice in association with the data VLAN and the VVoIP or VTC VLAN. NOTE: another green initiative where a single LAN drop is shared among several devices is called \"hot desking\" which is related to conservation of office space and teleworking. Hot desking is where several people are assigned to work at the same desk at different times, each with their own laptop PC. 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 (and possibly desktop VTC endpoint) used by all assignees and the PC port on it might be the connection for their laptop. In this case it is best not to use sticky port security but to use a static mapping of pre-authorized devices or implement 802.1x. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19653",
+      "title": "VVoIP or VTC endpoints are NOT integrated into the implemented 802.1x LAN access control system.",
+      "description": "IEEE 802.1x is a protocol that is used to control access to LAN services via a LAN access switchport or wireless access point. It requires a device or user (supplicant) to authenticate to the network element (authenticator) and become authorized by the authentication server before the authenticator provides access to the LAN. This process is used to activate the LAN access switchport and potentially limit traffic to a specific VLAN and/or install traffic filters. This method is more secure and capable than using basic MAC based port security. As such, 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19654",
+      "title": "The 802.1x authentication server does not configure the LAN access switchport to place the VVoIP or VTC traffic (and data traffic if applicable) in the correct VLAN when authorizing LAN access for VVoIP or VTC endpoints OR the LAN access switchport is NOT configured to do so by default. ",
+      "description": "802.1x has the capability of configuring the LAN access switchport 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 (LAN switch). 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 switchport must be configured with the data VLAN. If a VVoIP endpoint authenticates, the switchport must be configured with the VVoIP VLAN. Similarly for a VTC endpoint. If a VVoIP endpoint t hat contains a PC port authenticates, the switchport 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 switchport 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19655",
+      "title": "LAN access control is implemented using 802.1x AND one or more VVoIP or VTC endpoints provide a PC port, however the PC port is NOT disabled; AND/OR the LAN access switchport is NOT configured as required to support a disabled PC port (i.e., having the “unused” VLAN configured for PC port traffic); OR the VVoIP or VTC endpoint (or LAN access switchport) does not extend 802.1x port activation/deactivation to the PC port.",
+      "description": "A VVoIP or VTC endpoint that provides a PC port typically breaks 802.1x LAN access control mechanisms. The reason is that the LAN access switchport is turned on or authorized (and configured) when the VVoIP or VTC endpoint authenticates to the network and is authorized to operate. This typically permits whatever is connected to the PC port to have access to the LAN whether it is authorized or not or whether the device uses 802.1x or not. As such, the practice of daisy chaining devices on a single LAN drop that is “protected” by 802.1x must be prohibited unless certain mitigating circumstances exist, or are configured. The normal mitigation for this situation is to not implement VVoIP or VTC endpoints that provides a PC port if 802.1x is implemented as the LAN access control method. 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 LAN access switchport that is required to support a VVoIP or VTC endpoint with a disabled PC port. This means that the required configuration for the LAN access switchports 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). NOTE: the prohibition discussed here could be lifted (eliminated) in the event one of the following occurs: 1 - The LAN switchport can authorize access at the VLAN level and be reconfigured as additional devices are connected. That is, the switchport is activated and the VVoIP or VTC VLAN is configured/activated when the endpoint  is authenticated/authorized but the data VLAN for the PC port is set to the “unused” VLAN until the PC or other device is connected. When a device is connected to the PC port, it must then use 802.1x to gain access to the LAN. Once authenticated and authorized, the LAN switchport is reconfigured with the active e data VLAN if a PC is connected. This process could, in theory, also support a VVoIP, VTC endpoint, and PC daisy chained on one LAN port if each was authenticated to the LAN one at a time in sequence from the LAN drop out. 2 - The VVoIP or VTC endpoint’s embedded switch and the PC port fully supports 802.1x as an authenticator. That is the PC port works like an 802.1x capable LAN access switchport and can be activated and deactivated (configured) by the 802.1x authentication server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19656",
+      "title": "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.",
+      "description": "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. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-19657",
+      "title": "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.",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19658",
+      "title": "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",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19659",
+      "title": "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.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19660",
+      "title": "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 ",
+      "description": "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. \n\nNOTE: 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. \n",
+      "severity": "low"
+    },
+    {
+      "id": "V-19661",
+      "title": "The data network perimeter protection (data firewall function) is NOT configured 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",
+      "description": "See the discussion regarding the design of the enclave boundary when using VVoIP within the enclave. The following is a summary:\n\nThe 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/NAPT is implemented.\n\nTo properly protect the enclave when implementing VVoIP across the boundary, there are a specific set of processes and protections required as discussed earlier. For the purpose of this document, this set of processes and protections is referred to as the VVoIP firewall function. These are different from the data firewall processes and protections which are referred to as the data firewall function. These sets of processes and protections are defined as functions and not as discrete devices. This is primarily because as firewall platforms and their computing processors become faster and more robust, we do not want to limit the DoD from implementing a vendor’s product that can effectively support both sets of functions on the same platform.\n\nThe 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.\n\nAs such data firewall function must bock all traffic to/from the VVoIP VLANs and/or address space except as follows:\n• Signaling, media, registration protocols, UC protocols, etc to/from a remote endpoint entering the enclave via a properly authenticated VPN tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is an EBC (VoIP firewall) in which case session traffic must be routed through the EBC.\n• Management traffic to/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/subnets and the general data network management VLAN(s). \n• Protected LSC to LSC communications (e.g., database replication) between LSCs that are clustered across the WAN\n• The enclave is connected to a limited access / closed WAN (e.g., a classified WAN) AND the WAN has a dedicated address space for VVoIP (e.g., SIPRNet). In this case the VVoIP traffic may pass through the data firewall providing the permitted traffic is limited to/from the dedicated WAN address space and then routed to the internal VVoIP VLANs.",
+      "severity": "high"
+    },
+    {
+      "id": "V-19662",
+      "title": "The CER (premise or perimeter) router is NOT capable of, or is NOT configured to, provide expedited forwarding of VVoIP packets based on DSCP packet marking in accordance with the DISN IPVS DSCP marking plan.",
+      "description": "The typical perimeter or premise router (as designated by the NI and Enclave STIGs) will most likely not be capable of supporting the needs of VVoIP entering the DISN WAN. This is because only newer routers are capable of dealing with service classes and expedited forwarding. This why the DISN IPVS PMO specifies the specific additional capabilities required of the perimeter or premise router to support the needs of the Assures Service network. The router designated by the DISN IPVS PMO that is needed to support the service is called the Customer Edge Router (CER). This terminology is consistent with the terminology used by the DISN CORE PMO and other WAN service providers. The CER provides the following functionality: > Provides minimally four forwarding cues (eight preferred) >  Places traffic within expedited forwarding cues based on the Differential Service Code Point (DSCP) markings carried by the traffic. > Routes inbound AS-SIP-TLS packets and SRTP/SRTCP packets to the EBC function. (VVoIP firewall) > Routes all other inbound traffic to the data firewall > Provides all of the filtering and security required of a perimeter or premise router as required by the NI STIG. \n\nNOTE: proper DSCP marking of VVoIP packets is required to provide appropriate QoS for C2 priority calls in support of Assured Service The UCR requires the CER to support Expedited Forwarding (EF) PHBs in accordance with RFC 3246 and Assured Forwarding (AF) PHB in accordance with RFC 2597. The UCR further requires the CER to minimally support four forwarding cues but prefers eight cues which will be the requirement in the future when the vendors can support eight. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19663",
+      "title": "The CER (premise or perimeter) router is NOT configured to route all inbound traffic except AS-SIP-TLS and SRTP/SRTCP that is addressed to the VVoIP firewall (EBC) to the “data” firewall function.",
+      "description": "The CER (premise or perimeter) router is the first line of defense at the gateway to the enclave or LAN. The data and VVoIP firewall (EBC) functions are the second line of defense. Since the VVoIP firewall 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 such that it is better protected from being overloaded causing a denial of service. \n\nThis is part of a layered defense.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19664",
+      "title": "The CER is NOT configured to filter inbound AS-SIP-TLS traffic addressed to the local EBC based on the source address of the signaling messages as part of a layered defense.",
+      "description": "The CER (premise or perimeter) router is the first line of defense at the gateway to the enclave or LAN. The data and VVoIP firewall (EBC) functions are the second line of defense. Since the VVoIP firewall 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 such that it is better protected from being overloaded causing a denial-of-service. An additional filter that can be performed by the CER to help prevent a denial-of-service is to filter the AS-SIP-TLS packets based on their source address. Within the DISN IPVS network, LSCs are only to signal with their assigned MFSS and its backup. On the other hand, MFSSs are only to signal with their assigned LSCs, for which they are primary or backup, and other MFSSs. To support this, the EBC 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. Even though this is the case, the EBC could be flooded and overloaded with too many unauthenticated or invalid signaling packets. A situation that could cause a DOS. The CER can help prevent this by preventing signaling packets that are not sourced from authorized devices from ever reaching the EBC. This is part of a layered defense. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-19665",
+      "title": "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.",
+      "description": "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. \n\nSimilarly, 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. \n\nWhile 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.\n\nInternal 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19666",
+      "title": "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",
+      "description": "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.\n\nIn 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.\n\nNOTE: The EBC acts as an application level proxy and firewall for the signaling AS-SIP-TLS messages.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19667",
+      "title": "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.",
+      "description": "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.\n\nDoD policy dictates that authentication be performed using DoD PKI certificates. This also applies to network hosts and elements. \n\nAS-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. \n\nNOTE: 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.\n\nNOTE: the methods used will be in accordance with the UCR.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19668",
+      "title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to drop (and not process) all signaling packets except those whose integrity is validated.",
+      "description": "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.   \nNOTE: 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.\n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19669",
+      "title": "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.",
+      "description": "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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-19670",
+      "title": "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.\n\n",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19671",
+      "title": "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.",
+      "description": "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. \n\nNOTE: 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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19672",
+      "title": "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.",
+      "description": "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.\n\nNOTE: 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.\n\nNOTE: The need to use NAT/NAPT is a given when transitioning a boundary when RFC 1918 addresses are used within the enclave.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19673",
+      "title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to drop any packet (inbound or outbound) that is not validated as being part of an established and known call/session through stateful packet inspection or packet authentication.",
+      "description": "Once a pinhole is opened in the enclave boundary for a known call/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.\n\nOne 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. \n",
+      "severity": "high"
+    },
+    {
+      "id": "V-19674",
+      "title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to drop any packet attempting to traverse the enclave boundary (inbound or outbound) through the IP port pinholes that have been opened for known call/sessions that is not a RTP/RTCP or SRTP/SRTCP packet or other protocol / flow established by the signaling messages..",
+      "description": "Once a pinhole is opened in the enclave boundary for a known call/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. Another method for managing packets through a pinhole opened for a VVoIP call/session is to only permit packets to pass that match the expected protocol type. In this case 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. \nNOTE: 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 (FECC) messages for a VTC 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.\n",
+      "severity": "high"
+    },
+    {
+      "id": "V-19675",
+      "title": "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.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19676",
+      "title": "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. ",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-19677",
+      "title": "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.",
+      "description": "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: \n> 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. \n> Sends AS-SIP-TLS messages to interrogate the ability of another MFSS or a LSC to receive a call, whether routine or priority. \n> 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 \n> 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. \n> 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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21509",
+      "title": "The site’s private MLTS’s (VoIP or traditional), support/implementation for Fire and Emergency Services (F&ES) (life safety, security, fire, police, medical, etc) communications is deficient in that the originating telephone number of an F&ES call is not provided to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) or Automatic Location Identification (ALI) information.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21510",
+      "title": "The site’s private Multi-Line Telephone System’s (MLTS)  (VoIP or traditional), support/implementation for Fire and Emergency Services (F&ES) (life safety, security, fire, police, medical, etc.) communications is deficient in that the direct callback telephone number and physical location of an F&ES caller is not provided to, or accessible by, 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.",
+      "description": "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.\n\nPublic 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.\n\nThis 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). \n\nNOTE: 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.\n\nTo 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. \n\nTo 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:\n> The address of the site containing the MLTS unless provided to the answering point by the LEC as part of its ANI/ALI information.\n> The name (or number) of the building in which the telephone is located.\n> The address of the building in which the telephone is located.\n> The floor in the building on which the telephone is located.\n> The area or quadrant of the floor where the telephone is located.\n> The room or cube number where the telephone is located.\n\nNOTE: 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. \n\nNOTE: 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. \n\nNOTE: there are automated systems that 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. \n  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21512",
+      "title": "The site’s private Multi-Line Telephone System’s (MLTS) (VoIP or traditional) support/implementation for Fire and Emergency Services (F&ES) (life safety, security, fire, police, medical, etc.) communications is deficient in that such emergency calls are not routed as a priority call in a non-blocking manner. ",
+      "description": "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. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21513",
+      "title": "Devices and applications using SIP or AS-SIP signaling are vulnerable to a cross site scripting attack.",
+      "description": "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. \n\nWhile 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21514",
+      "title": "Hardware based VVoIP or VTC endpoint web browser capabilities that permit the endpoint to browse the internet or intranet are NOT disabled.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21515",
+      "title": "Hardware based VVoIP or IP-VTC endpoint contains a web server, the access to which is not restricted OR which is NOT disabled.",
+      "description": "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 subjedt to unauthorized access and compromise.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21516",
+      "title": "Sufficient backup power is not provided for the LAN Infrastructure, WAN boundary, VVoIP infrastructure, and/or VVoIP endpoints as required in support of special-C2 and C2 users system availability needs during a power outage OR sufficient backup power is not provided to C2-R or non-C2/admin user accessible endpoints, minimally in support of emergency life-safety and security calls.",
+      "description": "DoD Policy requires special-C2 users to be provided 8 hours of backup power in support of their VVoIP communications needs when primary power has failed. \n\nFrom CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 with eight hours uninterrupted power supply. \n\nAs such, all elements of the LAN infrastructure, WAN boundary infrastructure, VVoIP infrastructure, and VVoIP endpoints that directly support any Special-C2 user must be provided with sufficient backup power to meet the availability requirements.\n \n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21517",
+      "title": "The LAN hardware asset does not provide the required redundancy to support the availability/reliability needs of the C2 and Special C2 users of VVoIP services for command and control communications.",
+      "description": "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 spedial-C2 and C2 users is achieved in part by redundancy within the LAN network elements. For further detail, see VVoIP 5110 (LAN)",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21518",
+      "title": "LAN NEs supporting VV0IP services are NOT interconnected with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above OR each uplink can NOT support the full bandwidth handled by the NE AND/OR the appropriate routing protocol is NOT configured to affect the failover from one uplink to the other in the event of the failure of one.",
+      "description": "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 spedial-C2 and C2 users is achieved in part by interconnecting LAN network elements with redundant uplinks via geographically diverse paths. For further detail, see VVoIP 5115 (LAN)",
+      "severity": "medium"
+    },
+    {
+      "id": "V-21520",
+      "title": "Activation/deactivation of and permission to use the extension mobility feature is not properly controlled.",
+      "description": "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.\n\nNOTE: 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. \n\nNOTE: 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.\n\nExtension mobility poses some vulnerabilities to the VVoIP system, user’s profile information, and conversations if not properly controlled. \n\nExtension 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.\n\nActivation 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.\n\nExtension 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.\n\nIn 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.\n\n",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_voice_video_endpoint_security_requirements_guide.json

@@ -0,0 +1,395 @@
+{
+  "name": "stig_voice_video_endpoint_security_requirements_guide",
+  "date": "2017-12-28",
+  "description": "This Security Requirements Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
+  "title": "Voice Video Endpoint Security Requirements Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-66683",
+      "title": "The hardware Voice Video Endpoint must integrate into the implemented 802.1x network access control system.",
+      "description": "IEEE 802.1x is a protocol used to control access to LAN services via a network access switchport 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 switchport limiting traffic to a specific VLAN or install traffic filters. Implementing 802.1x port security on each access switchport denies all other MAC users, which eliminates the security risk of additional users attaching to a switch to bypass authentication. The hardware Voice Video Endpoint must be an 802.1x supplicant and integrate into the 802.1x access control system. When 802.1x is used, all devices connecting to the LAN are required to use 802.1x.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66685",
+      "title": "The hardware Voice Video Endpoint must be an 802.1x supplicant.",
+      "description": "IEEE 802.1x is a protocol used to control access to LAN services via a network access switchport 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 switchport limiting traffic to a specific VLAN or install traffic filters. Implementing 802.1x port security on each access switchport denies all other MAC users, which eliminates the security risk of additional users attaching to a switch to bypass authentication. The hardware Voice Video Endpoint must be an 802.1x supplicant and integrate into the 802.1x access control system. When 802.1x is used, all devices connecting to the LAN are required to use 802.1x.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66687",
+      "title": "The hardware Voice Video Endpoint PC port must connect to an 802.1x supplicant, or the PC port must be disabled.",
+      "description": "IEEE 802.1x is a protocol used to control access to LAN services via a network access switchport 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 switchport limiting traffic to a specific VLAN or install traffic filters. Implementing 802.1x port security on each access switchport denies all other MAC users, which eliminates the security risk of additional users attaching to a switch to bypass authentication. The hardware Voice Video Endpoint must be an 802.1x supplicant and integrate into the 802.1x access control system. When 802.1x is used, all devices connecting to the LAN are required to use 802.1x.\n\nA Voice Video Endpoint with a PC port may break 802.1x LAN access control mechanisms when the network access switchport is authorized during the Voice Video Endpoint authentication to the network. This condition may permit devices connected to the PC port to access the LAN. The access switchport can be configured in one of the following modes: single-host, multi-host, or multi-domain. Single-host allows only one device to authenticate, and only packets from this devices MAC address will be allowed, dropping all other packets. Multi-host mode requires one host to authenticate but once this is done, all packets regardless of source MAC address will be allowed. For both the PC attached to the PC port and the Voice Video Endpoint to authenticate separately, multi-domain authentication on the access switchport must be configured. This divides the switchport into a data and a voice domain. In this case if more than one device attempts authorization on either the voice or the data domain of a port, the switchport goes into an error disable state. Disabling the PC port requires the network access switchports are configured with the appropriate VLAN for the VVoIP or VTC traffic and placing the disabled PC port traffic on the unused VLAN. MAC Address Bypass (MAB) is a possible mitigation for this vulnerability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66689",
+      "title": "The unused hardware Voice Video Endpoint PC port must be disabled.",
+      "description": "IEEE 802.1x is a protocol used to control access to LAN services via a network access switchport 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 switchport limiting traffic to a specific VLAN or install traffic filters. Implementing 802.1x port security on each access switchport denies all other MAC users, which eliminates the security risk of additional users attaching to a switch to bypass authentication. The hardware Voice Video Endpoint must be an 802.1x supplicant and integrate into the 802.1x access control system. When 802.1x is used, all devices connecting to the LAN are required to use 802.1x.\n\nA Voice Video Endpoint with a PC port may break 802.1x LAN access control mechanisms when the network access switchport is authorized during the Voice Video Endpoint authentication to the network. This condition may permit devices connected to the PC port to access the LAN. Daisy chaining devices on a single LAN drop protected by 802.1x must be prohibited unless the PC port is an 802.1x authenticator and configured to work with an approved authentication server. Disabling the PC port requires the network access switchports are configured with the appropriate VLAN for the VVoIP or VTC traffic and placing the disabled PC port traffic on the unused VLAN. MAC Address Bypass (MAB) is a possible mitigation for this vulnerability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66691",
+      "title": "The hardware Voice Video Endpoint with a PC port must have the switchport configured as single-host or enable 802.1x multi-domain authentication.",
+      "description": "IEEE 802.1x is a protocol used to control access to LAN services via a network access switchport 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 switchport limiting traffic to a specific VLAN or install traffic filters. Implementing 802.1x port security on each access switchport denies all other MAC users, which eliminates the security risk of additional users attaching to a switch to bypass authentication. The hardware Voice Video Endpoint must be an 802.1x supplicant and integrate into the 802.1x access control system. When 802.1x is used, all devices connecting to the LAN are required to use 802.1x.\n\nA Voice Video Endpoint with a PC port may break 802.1x LAN access control mechanisms when the network access switchport is authorized during the Voice Video Endpoint authentication to the network. This condition may permit devices connected to the PC port to access the LAN. Daisy chaining devices on a single LAN drop protected by 802.1x must be prohibited unless the PC port is an 802.1x authenticator and configured to work with an approved authentication server. Disabling the PC port requires the network access switchports are configured with the appropriate VLAN for the VVoIP or VTC traffic and placing the disabled PC port traffic on the unused VLAN. MAC Address Bypass (MAB) is a possible mitigation for this vulnerability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66693",
+      "title": "The hardware Voice Video Endpoint not supporting 802.1x must be configured to use MAC Authentication Bypass (MAB) on the access switchport.",
+      "description": "IEEE 802.1x is a protocol used to control access to LAN services via a network access switchport 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 switchport limiting traffic to a specific VLAN or install traffic filters. Implementing 802.1x port security on each access switchport denies all other MAC users, which eliminates the security risk of additional users attaching to a switch to bypass authentication. The hardware Voice Video Endpoint must be an 802.1x supplicant and integrate into the 802.1x access control system. When 802.1x is used, all devices connecting to the LAN are required to use 802.1x.\n\nA Voice Video Endpoint with a PC port may break 802.1x LAN access control mechanisms when the network access switchport is authorized during the Voice Video Endpoint authentication to the network. This condition may permit devices connected to the PC port to access the LAN. Daisy chaining devices on a single LAN drop protected by 802.1x must be prohibited unless the PC port is an 802.1x authenticator and configured to work with an approved authentication server. Disabling the PC port requires the network access switchports are configured with the appropriate VLAN for the VVoIP or VTC traffic and placing the disabled PC port traffic on the unused VLAN. MAC Address Bypass (MAB) is a possible mitigation for this vulnerability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66695",
+      "title": "The hardware Voice Video Endpoint must reauthenticate 802.1x or MAC Authentication Bypass (MAB) every three (3) hours or less.",
+      "description": "IEEE 802.1x is a protocol used to control access to LAN services via a network access switchport 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 switchport limiting traffic to a specific VLAN or install traffic filters. Implementing 802.1x port security on each access switchport denies all other MAC users, which eliminates the security risk of additional users attaching to a switch to bypass authentication. The hardware Voice Video Endpoint must be an 802.1x supplicant and integrate into the 802.1x access control system. Devices connecting to the LAN are required to use 802.1x or MAC Address Bypass (MAB).\n\nWithout periodically reauthenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity on the network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66699",
+      "title": "The Voice Video Endpoint must limit the number of concurrent sessions to two (2) users.",
+      "description": "Voice video endpoint management includes the ability to control the number of user sessions and limiting the number of allowed user sessions helps limit risk related to DoS attacks. Voice video endpoint sessions occur peer-to-peer for media streams and client-server with session managers. For those endpoints that conference together multiple streams, the limit may be increased according to policy but a limit must still exist.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66701",
+      "title": "The hardware Voice Video Endpoint must apply 802.1Q VLAN tags to signaling and media traffic.",
+      "description": "When Voice Video Endpoints do not dynamically assign 802.1Q VLAN tags as data is created and combined, it is possible the VLAN tags will not correctly reflect the data type with which they are associated. VLAN tags are used as security attributes. These attributes are typically associated with signaling and media streams within the application and are used to enable the implementation of access control and flow control policies. Security labels for packets may include traffic flow information (e.g., source, destination, protocol combination), traffic classification based on QoS markings for preferred treatment, and VLAN identification.\n\nVirtualized networking is used to separate voice video traffic from other types of traffic, such as data, management, and other special types. VLANs provide segmentation at layer 2. Virtual Routing and Forwarding (VRF) provides segmentation at layer 3, and works with Multiprotocol Label Switching (MPLS) for enterprise and WAN environments. When VRF is used without MPLS, it is referred to as VRF lite. For Voice Video systems, VLANs and VRFs are used to separate media and signaling streams from all other traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66703",
+      "title": "The hardware Voice Video Endpoint must use a voice video VLAN, separate from all other VLANs.",
+      "description": "Virtualized networking is used to separate voice video traffic from other types of traffic, such as data, management, and other special types. VLANs provide segmentation at layer 2. Virtual Routing and Forwarding (VRF) provides segmentation at layer 3, and works with Multiprotocol Label Switching (MPLS) for enterprise and WAN environments. When VRF is used without MPLS, it is referred to as VRF lite. For Voice Video systems, VLANs and VRFs are used to separate media and signaling streams from all other traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66705",
+      "title": "The hardware Voice Video Endpoint PC port must maintain VLAN separation from the voice video VLAN, or be disabled.",
+      "description": "Virtualized networking is used to separate voice video traffic from other types of traffic, such as data, management, and other special types. VLANs provide segmentation at layer 2. Virtual Routing and Forwarding (VRF) provides segmentation at layer 3, and works with Multiprotocol Label Switching (MPLS) for enterprise and WAN environments. When VRF is used without MPLS, it is referred to as VRF lite. For Voice Video systems, VLANs and VRFs are used to separate media and signaling streams from all other traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66707",
+      "title": "The Voice Video Endpoint must block both inbound and outbound communications traffic between Unified Capability (UC) and Videoconferencing (VC) clients independently configured by end users and external service providers for voice and video.",
+      "description": "Various communication services such as public VoIP and Instant Messaging services route traffic over their own networks and are stored on their own servers; therefore, that traffic can be accessed at any time by the provider and potentially intercepted. \n\nCommunication clients independently configured by end users and external service providers include, for example, instant messaging clients. Traffic blocking does not apply to communication clients that are configured by organizations to perform authorized functions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66709",
+      "title": "The Voice Video Endpoint must implement replay-resistant authentication mechanisms for network access.",
+      "description": "A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Voice video endpoints often use passwords or PINs that can be easily exploited.\n\nThis requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user. This does not apply to authentication for the purpose of configuring the device itself (i.e., device management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66711",
+      "title": "The hardware Voice Video Endpoint using SIP or AS-SIP signaling must prevent cross-site scripting attacks caused by improper filtering or validation of the content of SIP invitation fields.",
+      "description": "A cross-site scripting vulnerability has been demonstrated by adding scripting code to the \"From:\" field in the SIP invite. Upon receiving the invite, the embedded code can be executed by a vulnerable embedded web server to download additional malicious code and launch an attack. The demonstration of the vulnerability also exists on www.securityfocus.com under Bugtraq ID: 25987, which pops up a specific alert box on the user’s workstation after downloading a SIP invite. \n\nWhile this vulnerability has been 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 potentially causes malicious code to be run on the target device, to include an endpoint (hard or soft), a session controller, or any other SIP signaling partner. Additionally, this vulnerability may affect applications other than SIP VoIP clients, such as IM clients. A similar vulnerability results when URLs embedded in SIP messages are launched automatically.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66713",
+      "title": "The Voice Video Endpoint must protect the integrity of transmitted configuration files from the Voice Video Session Manager.",
+      "description": "Without protection of the transmitted information, confidentiality and integrity may be compromised as unprotected communications can be intercepted and either read or altered. When Voice Video Endpoint configuration files traverse a network without encryption for confidentiality, system information can be intercepted by an adversary. Encryption of the configuration files mitigates this vulnerability. However, TFTP is the most common protocol used for configuration file transfers and does not natively encrypt data. The Cisco TFTP implementation for VoIP systems uses encryption to both store and transfer configuration files. Refer to the “CISCO-UCM-TFTP” Vulnerability Analysis report provided by the Protocols, Ports, and Services management site for more details. Integrity checks during the transmission of configuration files ensure no changes have been introduced by adversarial attacks. TLS can be utilized to secure SIP and SCCP signaling by configuring the session manager in a secure mode.\n\nDoD-to-DoD voice communications are generally considered to contain sensitive information and therefore DoD voice and data traffic crossing the unclassified DISN must be encrypted. Cryptographic mechanisms such as Media Access Control Security (MACsec) implemented to protect information integrity include cryptographic hash functions that have common application in digital signatures, checksums, and message authentication codes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66715",
+      "title": "The Voice Video Endpoint must protect the confidentiality of transmitted configuration files from the Voice Video Session Manager.",
+      "description": "Without protection of the transmitted information, confidentiality and integrity may be compromised as unprotected communications can be intercepted and either read or altered. When Voice Video Endpoint configuration files traverse a network without encryption for confidentiality, system information can be intercepted by an adversary. Encryption of the configuration files mitigates this vulnerability. However, TFTP is the most common protocol used for configuration file transfers and does not natively encrypt data. The Cisco TFTP implementation for VoIP systems uses encryption to both store and transfer configuration files. Refer to the “CISCO-UCM-TFTP” Vulnerability Analysis report provided by the Protocols, Ports, and Services management site for more details. Integrity checks during the transmission of configuration files ensure no changes have been introduced by adversarial attacks. TLS can be utilized to secure SIP and SCCP signaling by configuring the session manager in a secure mode.\n\nDoD-to-DoD voice communications are generally considered to contain sensitive information and therefore DoD voice and data traffic crossing the unclassified DISN must be encrypted. Cryptographic mechanisms such as Media Access Control Security (MACsec) implemented to protect information integrity include cryptographic hash functions that have common application in digital signatures, checksums, and message authentication codes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66717",
+      "title": "The Voice Video Endpoint must dynamically implement configuration file changes.",
+      "description": "Configuration management includes the management of security features and assurances through control of changes made to device hardware, software, and firmware throughout the life cycle of a product. Secure configuration management relies on performance and functional attributes of products to determine the appropriate security features and assurances used to measure a system configuration state. When configuration changes are made, it is critical for those changes to be implemented by the Voice Video Endpoint as quickly as possible. This ensures that Voice Video Endpoints communicate using the correct address books, session managers, gateways, and border elements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66719",
+      "title": "The Voice Video Endpoint must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the network.",
+      "description": "Display of a standardized and approved use notification before granting access to the network ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to Voice Video Endpoints that have the concept of a user account and have the logon function residing on the network element.\n\nThe banner must be formatted in accordance with current policy. Use the following verbiage for network elements that can accommodate banners of 1300 characters:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"\n\nUse the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:\n\n\"I've read & consent to terms in IS user agreem't.\"",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66725",
+      "title": "The Voice Video Endpoint must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.",
+      "description": "The banner must be acknowledged by the user prior to allowing the user access to the network. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The network element must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating \"OK\". System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to Voice Video Endpoints that have the concept of a user account and have the logon function residing on the network element.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66727",
+      "title": "The Voice Video Endpoint must produce session (call detail) records containing what type of connection occurred.",
+      "description": "Session records are commonly produced by session management and border elements. Many Voice Video Endpoints are not capable of providing session records and instead rely on session management and border elements. Voice video endpoints capable of producing session records provide supplemental confirmation of monitored events. Voice video endpoints that communicate beyond these defined environments must generate session records.\n\nSession record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records. Detailed records are typically produced by the session manager but can be augmented by non-telephone endpoint records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66729",
+      "title": "The Voice Video Endpoint must produce session (call detail) records containing when (date and time) the connection occurred.",
+      "description": "Session records are commonly produced by session management and border elements. Many Voice Video Endpoints are not capable of providing session records and instead rely on session management and border elements. Voice video endpoints capable of producing session records provide supplemental confirmation of monitored events. Voice video endpoints that communicate beyond these defined environments must generate session records.\n\nSession record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records. Detailed records are typically produced by the session manager but can be augmented by non-telephone endpoint records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66731",
+      "title": "The Voice Video Endpoint must produce session (call detail) records containing where the connection occurred.",
+      "description": "Session records are commonly produced by session management and border elements. Many Voice Video Endpoints are not capable of providing session records and instead rely on session management and border elements. Voice video endpoints capable of producing session records provide supplemental confirmation of monitored events. Voice video endpoints that communicate beyond these defined environments must generate session records.\n\nSession record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records. Detailed records are typically produced by the session manager but can be augmented by non-telephone endpoint records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66733",
+      "title": "The Voice Video Endpoint must produce session (call detail) records containing the outcome of the connection.",
+      "description": "Session records are commonly produced by session management and border elements. Many Voice Video Endpoints are not capable of providing session records and instead rely on session management and border elements. Voice video endpoints capable of producing session records provide supplemental confirmation of monitored events. Voice video endpoints that communicate beyond these defined environments must generate session records.\n\nSession record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records. Detailed records are typically produced by the session manager but can be augmented by non-telephone endpoint records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66735",
+      "title": "The Voice Video Endpoint must produce session (call detail) records containing the identity of all users.",
+      "description": "Session records are commonly produced by session management and border elements. Many Voice Video Endpoints are not capable of providing session records and instead rely on session management and border elements. Voice video endpoints capable of producing session records provide supplemental confirmation of monitored events. Voice video endpoints that communicate beyond these defined environments must generate session records.\n\nSession record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records. Detailed records are typically produced by the session manager but can be augmented by non-telephone endpoint records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66737",
+      "title": "The Voice Video Endpoint must provide session (call detail) record generation capability.",
+      "description": "Session records are commonly produced by session management and border elements. Many Voice Video Endpoints are not capable of providing session records and instead rely on session management and border elements. Voice video endpoints capable of producing session records provide supplemental confirmation of monitored events. Voice video endpoints that communicate beyond these defined environments must generate session records.\n\nSession records for Voice Video systems are generally handled in a similar fashion to audit records for other systems and are used for billing, usage analysis, and record support for actions taken. Detailed records are typically produced by the session manager but can be augmented by non-telephone endpoint records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66739",
+      "title": "The Voice Video Endpoint must terminate all network connections associated with a communications session at the end of the session.",
+      "description": "Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, de-allocating associated TCP/IP address/port pairs at the device or operating system level, and de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66741",
+      "title": "The Voice Video Endpoint used for videoconferencing must uniquely identify participating users.",
+      "description": "To assure accountability and prevent unauthenticated access, users must be identified to prevent potential misuse and compromise of the system. The Voice Video Endpoint must display the source of an incoming call and the participant's identity to aid the user in deciding whether to answer a call. The information potentially at risk is that which can be seen in the physical area of the Voice Video Endpoint or carried by the conference in which it is participating. \n\nThis does not apply to authentication for the purpose of configuring the device itself (i.e., device management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66743",
+      "title": "The Voice Video Endpoint used for videoconferencing must accept a Common Access Card (CAC) or derived credentials.",
+      "description": "The use of CAC or derived credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66745",
+      "title": "The Voice Video Endpoint used for videoconferencing must electronically verify the Common Access Card (CAC) or derived credentials.",
+      "description": "The use of CAC or derived credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66747",
+      "title": "The Voice Video Endpoint used for videoconferencing must use multifactor authentication for network access.",
+      "description": "To assure accountability and prevent unauthenticated access, users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. \n\nFactors include:\n(i) Something you know (e.g., password/PIN); \n(ii) Something you have (e.g., cryptographic identification device, token); or \n(iii) Something you are (e.g., biometric). \n\nNetwork access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. The DoD CAC with DoD-approved PKI is an example of multifactor authentication. \n\nThis does not apply to authentication for the purpose of configuring the device itself (i.e., device management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66749",
+      "title": "The Voice Video Endpoint, when using passwords or PINs for authentication or authorization, must cryptographically-protect the transmission.",
+      "description": "Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.\n\nThis does not apply to authentication for the purpose of configuring the device itself (management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66751",
+      "title": "When using PKI-based authentication, the Voice Video Endpoint must enforce authorized access to the corresponding private key.",
+      "description": "If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to authenticate to network devices. \n\nThis does not apply to authentication for the purpose of configuring the device itself (management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66753",
+      "title": "When using PKI-based authentication, the Voice Video Endpoint used for videoconferencing must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.",
+      "description": "Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key. Within a chain of trust, the top entity to be trusted is the \"root certificate\" or \"trust anchors\" such as a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. \n\nThis requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66755",
+      "title": "When using PKI-based authentication, the Voice Video Endpoint used for videoconferencing must implement a local cache of revocation data to support path discovery and validation in the event the network path becomes unavailable.",
+      "description": "Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates). \n\nThis does not apply to authentication for the purpose of configuring the device itself (i.e., device management).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66757",
+      "title": "The Voice Video Endpoint must use encryption for signaling and media traffic.",
+      "description": "Without protection of the transmitted information, confidentiality and integrity may be compromised as unprotected communications can be intercepted and either read or altered. TLS can be utilized to secure SIP and SCCP signaling by configuring the session manager in a secure mode.\n\nDoD-to-DoD voice communications are generally considered to contain sensitive information and therefore DoD voice and data traffic crossing the unclassified DISN must be encrypted. Cryptographic mechanisms such as Media Access Control Security (MACsec) implemented to protect information include cryptographic hash functions that have common application in digital signatures, checksums, and message authentication codes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66759",
+      "title": "The Voice Video Endpoint processing classified information over public networks must implement NSA-approved cryptography.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66761",
+      "title": "The Voice Video Endpoint processing unclassified information must implement NIST FIPS-validated cryptography.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66763",
+      "title": "The Voice Video Endpoint processing unclassified information must implement NIST FIPS-validated cryptography to generate cryptographic hashes.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66765",
+      "title": "The Voice Video Endpoint must provide an explicit indication of current participants in all Videoconference (VC)-based and IP-based online meetings and conferences.",
+      "description": "Providing an explicit indication of current participants in teleconferences helps to prevent unauthorized individuals from participating in collaborative teleconference sessions without the explicit knowledge of other participants. Teleconferences allow groups of users to collaborate and exchange information. Without knowing who is in attendance, information could be compromised. This requirement excludes audio-only teleconferences using traditional telephony.\n\nNetwork elements that provide a teleconference capability must provide a clear indication of who is attending the meeting, thus providing all attendees with the capability to clearly identify users who are in attendance.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66767",
+      "title": "In the event of a device failure, hardware Voice Video Endpoints must preserve any information necessary to determine cause of failure and return to operations with least disruption to service.",
+      "description": "Failure in a known state can address safety or security in accordance with the mission needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving network element state information helps to facilitate network element restart and return to the operational mode of the organization with less disruption to mission-essential processes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66769",
+      "title": "The Voice Video Endpoint must prevent unauthorized and unintended information transfer via shared system resources.",
+      "description": "Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. \n\nUnified capability (UC) and videoconferencing (VC) vendors have included capabilities in products that must be disabled for users. Many current UC and VC products include hooks into email, IM, and local file transfer. Peer networking options allowing transfer often use holding storage locations that are accessible to all users. This would allow potentially sensitive information to be shared without central control.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66771",
+      "title": "The Voice Video Endpoint supporting Command and Control (C2) communications must implement Multilevel Precedence and Preemption (MLPP) dialing to enable Routine, Priority, Immediate, Flash, and Flash Override.",
+      "description": "Configuring the C2 Voice Video Endpoint to implement MLPP ensures vital high-level communications occurs regardless of environmental, geographical, and political conditions. When conditions require immediate discussion among high-level officials, the C2 communications systems must be capable of implementing MLPP. \n\nThe MLPP service allows properly validated users to place priority calls and when necessary, C2 users can preempt lower priority phone calls. Precedence designates the priority level that is associated with a call and preemption designates the process of terminating lower precedence calls currently using a Voice Video Endpoint. A call of higher precedence can be extended to or through the device. A validated C2 user can preempt calls to targeted stations when AS-SIP is fully implemented on the network or through fully subscribed time division multiplexing (TDM) trunks. This capability assures high-level personnel of communication to critical organizations and personnel during network stress situations, such as a national emergency or degraded network situations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66773",
+      "title": "The Voice Video Endpoint supporting Command and Control (C2) communications must implement Multilevel Precedence and Preemption (MLPP) call disconnect to enable Routine, Priority, Immediate, Flash, and Flash Override.",
+      "description": "Configuring the C2 Voice Video Endpoint to implement MLPP ensures vital high-level communication occurs regardless of environmental, geographical, and political conditions. When conditions require immediate discussion among high-level officials, the C2 communications systems must be capable of implementing MLPP.\n\nThe MLPP service allows properly validated users to place priority calls and when necessary, C2 users can preempt lower-priority phone calls. Precedence designates the priority level that is associated with a call and preemption designates the process of terminating lower-precedence calls currently using a Voice Video Endpoint. A call of higher precedence can be extended to or through the device. A validated C2 user can preempt calls to targeted stations when AS-SIP is fully implemented on the network or through fully subscribed time division multiplexing (TDM) trunks. This capability assures high-level personnel of communication to critical organizations and personnel during network stress situations, such as a national emergency or degraded network situations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66775",
+      "title": "The Voice Video Endpoint supporting Command and Control (C2) communications must implement Assured Service Session Initiation Protocol (AS-SIP).",
+      "description": "Configuring the C2 Voice Video Endpoint to implement MLPP ensures vital high-level communication occurs regardless of environmental, geographical, and political conditions. When conditions require immediate discussion among high-level officials, the C2 communications systems must be capable of implementing MLPP.\n\nThe MLPP service allows properly validated users to place priority calls and when necessary, C2 users can preempt lower-priority phone calls. Precedence designates the priority level that is associated with a call and preemption designates the process of terminating lower-precedence calls currently using a Voice Video Endpoint. A call of higher precedence can be extended to or through the device. A validated C2 user can preempt calls to targeted stations when AS-SIP is fully implemented on the network or through fully subscribed time division multiplexing (TDM) trunks. This capability assures high-level personnel of communication to critical organizations and personnel during network stress situations, such as a national emergency or degraded network situations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66777",
+      "title": "The Voice Video Endpoint microphone must provide hardware mechanisms, such as push-to-talk (PTT) handset switches, to prevent pickup and transmission of sensitive or classified information over non-secure networks.",
+      "description": "Microphones used with videoconferencing are designed to be extremely sensitive, designed to pick up audio from anywhere within a conference room. The microphones may pick up sidebar conversations with no relationship to the conference or call in progress. Speakerphones exhibit a similar vulnerability. This is especially at risk when unclassified conversations are conducted in classified spaces. Users or operators of videoconferencing systems must take care regarding what is being said and seen during a conference call and what sensitive information can be picked up by a camera or microphone. \n\nVoice Video Endpoints used in classified areas must use hardware mechanisms such as push-to-talk (PTT) to prevent conversations occurring in the area of the call from being heard over unclassified systems. This capability mitigates the risk to compromise sensitive or classified information not related to the conversation in progress. Speakers embedded in or connected to a Voice Video Endpoint may be turned up loud enough to be heard across a room or in the next workspace, risking compromise or sensitive or classified information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66779",
+      "title": "The Voice Video Endpoint camera must provide hardware mechanisms, such as push-to-see (PTS) camera switches, to prevent pickup and transmission of sensitive or classified information over non-secure networks.",
+      "description": "Cameras used with Voice Video Endpoints may reveal sensitive or classified information. This is especially at risk when unclassified conversations are conducted in classified spaces. Users or operators of videoconferencing systems must take care regarding what is being said and seen during a conference call and what sensitive information can be picked up by a camera or microphone. \n\nVoice Video Endpoints used in classified areas must use hardware mechanisms such as push-to-see (PTS) to prevent sensitive or classified information picked up by the camera in the area of the call from being transmitted over unclassified systems. This capability mitigates the risk to compromise sensitive or classified information not related to the conversation in progress.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66781",
+      "title": "The Voice Video Endpoint auto-answer feature must be disabled.",
+      "description": "A Voice Video Endpoint set to automatically answer a call with audio or video capabilities enabled risks transmitting information not intended for the caller. In the event a Voice Video Endpoint automatically answered a call during a classified meeting or discussion. Potentially sensitive or classified information could be transmitted. The auto-answer feature must not be activated by a user unless the feature is required to satisfy mission requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66783",
+      "title": "The hardware Voice Video Endpoint must disable or restrict web browser capabilities permitting the endpoint to browse the internet or intranet.",
+      "description": "Permitting hardware Voice Video 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. Voice Video Endpoints typically do not support host based intrusion detection or anti-virus software. While the downloaded malicious code might not affect the endpoint itself, the endpoint could be used by the malicious code as a launching pad into the network and attached workstations or servers.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66785",
+      "title": "The hardware Voice Video Endpoint must disable or restrict built-in web servers.",
+      "description": "Hardware Voice Video 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 Voice Video Endpoints, 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66787",
+      "title": "The hardware Voice Video Endpoint must prevent the configuration of network IP settings without the use of a PIN or password.",
+      "description": "Many Voice Video Endpoints can set or display configuration settings in the instrument itself. This presents a risk if a user obtains information such as the IP addresses and URLs of system components. This obtained information could be used to facilitate an attack on the system. Therefore these devices should be considered a target to be defended against such individuals that would collect voice network information for illicit purposes. To mitigate information gathering by the adversaries, measures must be taken to protect this information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66789",
+      "title": "The hardware Voice Video Endpoint must prevent the display of network IP settings without the use of a PIN or password.",
+      "description": "Many Voice Video Endpoints can set or display configuration settings in the instrument itself. This presents a risk if a user obtains information such as the IP addresses and URLs of system components. This obtained information could be used to facilitate an attack on the system. Therefore these devices should be considered a target to be defended against such individuals that would collect voice network information for illicit purposes. To mitigate information gathering by the adversaries, measures must be taken to protect this information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66791",
+      "title": "The hardware Voice Video Endpoint must not use the default PIN or password to access configuration and display of network IP settings.",
+      "description": "Many Voice Video Endpoints can set or display configuration settings in the instrument itself. This presents a risk if a user obtains information such as the IP addresses and URLs of system components. This obtained information could be used to facilitate an attack on the system. Therefore these devices should be considered a target to be defended against individuals that would collect voice network information for illicit purposes. To mitigate information gathering by the adversaries, measures must be taken to protect this information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66793",
+      "title": "The Voice Video Endpoint must be configured to disable or remove non-essential capabilities.",
+      "description": "It is detrimental for Voice Video Endpoints when unnecessary features are enabled by default. Often these features are enabled by default with functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.\n\nNetwork elements are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66795",
+      "title": "The Voice Video Endpoint must prevent the user from installing third-party software.",
+      "description": "Unauthorized third-party software is challenging the security posture of DoD. Most established vendors have developed patch management process that prevents risk, resulting in an estimated 80 percent of threats arise from third-party software. Preventing users from installing third-party software limits organizational exposure. Additionally, preventing installation of untrusted software further reduces risk to the network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66797",
+      "title": "The Voice Video Endpoint must prevent installation of untrusted third-party software.",
+      "description": "Unauthorized third-party software is challenging the security posture of DoD. Most established vendors have developed a patch management process that prevents risk, resulting in an estimated 80 percent of threats arising from third-party software. Preventing users from installing third-party software limits organizational exposure. Additionally, preventing installation of untrusted software further reduces risk to the network. Vendors that prevent installation of all third-party software meet the intent of this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66799",
+      "title": "The Voice Video Endpoint must only use ports, protocols, and services allowed per the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and Vulnerability Assessments (VAs).",
+      "description": "In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Voice video endpoints are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component but doing so increases risk compared to limiting the services provided by any one component. \n\nTo support the requirements and principles of least functionality, the network element must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. The current Category Assurance List (CAL) and Vulnerability Assessments (VA) listings for ports, protocols, and services are available on the DISA Information Assurance Support Environment (IASE) website for Ports, Protocols, and Services Management (PPSM) at http://iase.disa.mil/ppsm/Pages/index.aspx.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66801",
+      "title": "The Voice Video Endpoint must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.",
+      "description": "Configuring the Voice Video Endpoint to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. \n\nConfiguration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network element. Security-related parameters are those parameters impacting the security state of the network element, including the parameters required to satisfy other security control requirements. For the network element, security-related parameters include settings for network traffic management configurations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66803",
+      "title": "The Voice Video Endpoint processing unclassified information must implement NIST FIPS-validated cryptography to provision digital signatures.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67985",
+      "title": "The Voice Video Endpoint must register with a Voice Video Session Manager.",
+      "description": "Authentication must not automatically give an entity access to an asset. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Registration authenticates and authorizes endpoints with the Voice Video Session Manager.\n\nFor most VoIP systems, registration is the process of centrally recording the user ID, endpoint MAC address, service/policy profile with 2 stage authentication prior to authorizing the establishment of the session and user service. The event of successful registration creates the session record immediately. VC systems register using a similar process with a gatekeeper. Without enforcing registration, an adversary could impersonate a legitimate device on the Voice Video network. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-71671",
+      "title": "The Voice Video Endpoint used for unclassified communication within a Sensitive Compartmented Information Facility (SCIF) or Special Access Program Facility (SAPF) must be National Telecommunications Security Working Group (NTSWG) approved device in accordance with the Committee on National Security Systems Instruction (CNSSI) 5000.",
+      "description": "Configuring the Voice Video Endpoint to implement CNSSI 5000 for unclassified communication within SCIFs and SAPF ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. \n\nVoice Video Endpoints may transmit classified conversations over unclassified networks. Voice Video Endpoint microphones, speakers, and supporting electronics may pick up conversation audio within the area and conduct it over the network connection, even when the endpoint is on-hook, powered or not. The Technical Surveillance Counter-Measures (TSCM) program protects sensitive government information, to include classified information, through the establishment of on-hook audio security standards. Voice Video Endpoints certified by NTSWG are modified to prevent this behavior, or limit it to within acceptable levels.\n\nReferences:\nCNSS Instruction No. 5000, Guidelines for Voice over Internet Protocol (VoIP), dated August 2016\nCNSS Instruction No. 5001, Type-Acceptance Program for Voice over Internet Protocol (VoIP) Telephones, dated December 2007\nCNSS Instruction No. 5007, Telephone Security Equipment Submission and Evaluation Procedures, dated April 2013\nIC Tech Spec-For ICD/ICS 705, Technical Specifications for Construction and Management of Sensitive Compartmented Information Facilities, version 1.3 dated September 10, 2015\nJoint Air Force, Army, Navy (JAFAN) 6/0 Manual; Special Access Program Security Manual – Revision 1, dated May 29, 2008\nJoint Air Force, Army, Navy (JAFAN) 6/9 Manual; Physical Security Standards for Special Access Program Facilities, dated March 23, 2004",
+      "severity": "medium"
+    },
+    {
+      "id": "V-77277",
+      "title": "The Voice Video Endpoint processing classified calls must produce session (call detail) records containing classification level and Security Access Level (SAL).",
+      "description": "Session records are commonly produced by session management and border elements. Many Voice Video Endpoints are not capable of providing session records and instead rely on session management and border elements. Voice video endpoints capable of producing session records provide supplemental confirmation of monitored events. Voice video endpoints that communicate beyond these defined environments must generate session records.\n\nSession record content for classified calls may include additional information not pertinent to unclassified calls, such as the classification and SAL. Detailed records are typically produced by the session manager but can be augmented by non-telephone endpoint records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-77281",
+      "title": "The Voice Video Endpoint processing classified calls must be properly marked with the highest security level of the information being processed.",
+      "description": "Without the association of security attributes to information, there is no basis for the network element to make security related access-control and flow-control decisions. Security attributes includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in process. If the security attributes are lost when the data is being processed, there is the risk of a data compromise.\n\nAll hardware Voice Video endpoints processing classified calls, including phones and terminals, must be properly marked with the highest class-mark of the system. (Formerly DRSN 1098).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-77283",
+      "title": "The Voice Video Endpoint processing classified calls must  display the classification level and Security Access Level (SAL) for the call or conference in progress.",
+      "description": "Without the association of security attributes to information, there is no basis for the network element to make security related access-control and flow-control decisions. Security attributes includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in process. If the security attributes are lost when the data is being processed, there is the risk of a data compromise.\n\nVoice video endpoints processing classified calls must display the appropriate security classification and SAL to ensure users protect information accordingly. Further, endpoints must be compatible with STU-III and STE displays. Voice video endpoints must indicate:\n - SCI when the connected terminals are authorized to process SCI information\n - Foreign national presence when non-U.S. personnel are authorized uncontrolled access\n - Terminal identifier associated with distant STU-IIIs or STEs and RED switch subscriber terminals\n - Non-secure calls and conferences established through an unclassified switch or key system.\n\nNote: Each DRSN RED telephone (except for the IST) must have, at a minimum, a two-line alphanumeric display with a minimum of 16-characters per line. The Integrated Services Telephone (IST) has a one-line, 40-character display instead of the two-line by 16-character display. These displays will show the following:\n - The first line will display the self-authenticating security level of the call or conference in progress.\n - The second line will display the identity data of the distant terminal or identify the network and/or equipment type associated with the distant party and when a conference call is in progress.\n(Formerly DRSN 2384/2385)",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79055",
+      "title": "The hardware Voice Video Endpoint must have a physical DD 2056 affixed, or display a digital representation.",
+      "description": "Display of a standardized and approved use notification before granting access to the network ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Consent to monitoring stickers.",
+      "severity": "medium"
+    }
+  ]
+}