{
"stig": {
"date": "2015-01-05",
"description": "The Video Teleconference Security Technical Implementation Guide (STIG) provides technical guidance for video teleconferencing systems and endpoints implemented on DoD networks. The Video Services Policy STIG works with the Video Teleconference STIG requirements for evaluation on each video teleconferencing (VTC) system review, regardless of the VTC product or release level. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil. ",
"findings": {
"V-19624": {
"checkid": "C-23917r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure auto-answer capabilities of any voice, video, VTC, UC, or collaboration applications are disabled in the event the application provides audio or video communications services such that the microphone and/or camera could be activated automatically when an incoming call is received. \n\nNote: This does not apply to text based communications such as IM that does not activate a microphone or camera.\n\nHave the IAO or SA demonstrate the operation of the PC communications client applications on PCs in the organization, to determine how they function with regard to the \u201cauto-answer\u201d feature, how the feature is configured, and if it is a user configurable setting. Inspect a random sample of PCs to determine if communication apps are configured in compliance. Place calls to all or minimally a random sample of PCs to determine if any of them automatically answers the call. Inspect SOPs and training materials to determine if this mitigation requirement is disseminated to users. Interview a random sampling of users to determine if they are properly trained on this topic. \n\nThis is a finding if any PC application automatically answers a call, or if the application is configured to allow auto-answer, or if the application cannot be configured to disable auto-answer.\n\nIf this feature/capability is user configurable, this is a finding in the event SOPs and training materials do not address the auto-answer feature such that it is not used. Additionally, this is a finding if users are unaware of the related training.\n\nThis is not a finding if by default the application does not automatically answer calls and such a feature cannot be activated.",
"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. ",
"fixid": "F-20328r1_fix",
"fixtext": "Ensure auto-answer capabilities of any voice, video, VTC, UC, or collaboration applications are disabled in the event the application provides audio or video communications services such that the microphone and/or camera could be activated automatically when an incoming call is received. \n\nNote: This does not apply to text based communications such as IM that does not activate a microphone or camera.\n\nIf a PC communications client application provides an auto-answer feature/function configure the application to disable the feature. \nOR\nIf the auto-answer feature/function is user configurable, develop an SOP and training materials and train users to not activate the feature. Enforce the SOP by randomly checking their compliance.\nOR\nIf a PC communications client application provides an auto-answer feature/function that cannot be disabled, replace the application with one that does not have the feature or one that can be configured to disable it.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19624",
"ruleID": "SV-21765r1_rule",
"severity": "medium",
"title": "An Auto-answer feature is not properly disabled.",
"version": "VVoIP/VTC 1740 (GENERAL) "
},
"V-19658": {
"checkid": "C-24015r1_chk",
"checktext": "Potential active tests:\nOpen a browser on an attached test PC (the normal PC may not be capable of performing the tests). Attempt to connect to the IP address of the phone. Attempt to ping the endpoint IP address. Open a sniffer program and attempt to capture traffic to/from the phone. None of these should attempts be successful. Perform a network scan of the VoIP address space from the PC port. The VVoIP endpoints should not show up in the results. \n",
"description": "VVoIP or VTC hardware endpoint possessing a \u201cPC Port\u201d 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.",
"fixid": "F-20362r1_fix",
"fixtext": "In the event a VVoIP or VTC hardware endpoint provides a \u201cPC Port\u201d Ensure all VVoIP or VTC hardware endpoints possessing a \u201cPC Port\u201d is configured to block access to the endpoint configuration and communications traffic from the attached PC or other device.\n\nAlternately ensure, if the endpoint cannot maintain this separation, the \u201cPC Port\u201d is disabled. In the event the endpoint contains an Ethernet hub, the PC port may need to be physically disabled (blocked) if it cannot be electronically disabled. \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\nGenerally, do not implement VVoIP or VTC hardware endpoints that have an embedded Ethernet hub instead of a switch since a hub cannot support VLAN separation and drastic measures may be needed to disable the PC port. \n",
"iacontrols": [
"ECSC-1"
],
"id": "V-19658",
"ruleID": "SV-21799r1_rule",
"severity": "medium",
"title": "A VVoIP or VTC hardware endpoint possessing a \u201cPC Port\u201d is not configured to block access to the endpoint configuration and communications traffic from the attached PC",
"version": "VVoIP 5705 (LAN)"
},
"V-19659": {
"checkid": "C-24018r1_chk",
"checktext": "If the VVoIP or VTC endpoints provide a PC Port (and embedded Ethernet switch), inspect the configurations of the endpoints and/or their configuration settings on the LSC to determine compliance with the following requirement:\n\nIn the event A VVoIP or VTC hardware endpoint possesses a \u201cPC Port,\u201d ensure the VVoIP packets are tagged with the correct local VVoIP endpoint VLAN ID while passing all traffic entering the PC port unchanged so that these packets are automatically placed in the correct VLAN by the access layer switch. Alternately ensure, if the endpoint cannot maintain this separation, the \u201cPC Port\u201d is disabled. In the event the endpoint contains an Ethernet hub, the PC port may need to be physically disabled (blocked) if it cannot be electronically disabled. \n",
"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.",
"fixid": "F-20363r1_fix",
"fixtext": "In the event A VVoIP or VTC hardware endpoint possesses a \u201cPC Port\u201d, configure the VVoIP or VTC endpoint to tag its Ethernet frames with the correct local VVoIP endpoint 802.1Q VLAN ID while passing all traffic entering the PC port to the LAN port unchanged so that these packets are automatically placed in the correct VLAN by the access layer switch. Alternately ensure, if the endpoint cannot maintain this separation, the \u201cPC Port\u201d is disabled. In the event the endpoint contains an Ethernet hub, the PC port may need to be physically disabled (blocked) if it cannot be electronically disabled. ",
"iacontrols": [
"ECSC-1"
],
"id": "V-19659",
"ruleID": "SV-21800r1_rule",
"severity": "medium",
"title": "A VVoIP or VTC hardware endpoint possessing a \u201cPC Port\u201d does not tag its communications traffic using 802.1Q VLAN tagging or the PC port is not disabled.",
"version": "VVoIP 5710 (LAN)"
},
"V-19660": {
"checkid": "C-24020r1_chk",
"checktext": "Interview the IAO to determine if the VVoIP or VTC endpoints provide a PC Port. Further determine the following:\nIs the port is regularly used on most endpoints?\nWhich endpoints and PC ports are NOT used? \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, though, these PC ports are the most vulnerable to unauthorized use and therefore should be disabled until actually required to be used by an authorized LAN user. \n\nEnsure all VVoIP or VTC endpoints that provide a PC Port are configured to disable the PC data port if a PC or other device is not normally attached.",
"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\u2019 configuration and communications traffic. \n",
"fixid": "F-20364r1_fix",
"fixtext": "Ensure all VVoIP or VTC endpoints that provide a PC Port are configured to disable the PC data port if a PC or other device is not normally attached.\n\nNOTE: A partial mitigation to the vulnerability addressed here is to configure the LAN access switch ports for MAC based port security and configuring it to only accept connections from the specific MAN address of the connected approved endpoint\n\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-19660",
"ruleID": "SV-21801r1_rule",
"severity": "low",
"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 ",
"version": "VVoIP 5715 (LAN)"
},
"V-21514": {
"checkid": "C-25756r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure hardware based VVoIP or VTC endpoint web browser capabilities that permit the endpoint to browse the internet or intranet are disabled unless such capabilities are specifically required for the proper function of the endpoint or to access specific external applications.\n\nDetermine the web browsing capabilities of the hardware based VVoIP or VTC endpoints. This is a finding in the event the endpoint can access general web pages on the Internet or enterprise intranet other than approved external applications.\n\nNOTE: This requirement does not apply to limited web browsing capabilities required to access external applications and services that have been approved for accessibility on the endpoint and implemented by the enterprise.\n\n",
"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.",
"fixid": "F-22304r1_fix",
"fixtext": "Ensure hardware based VVoIP or VTC endpoint web browser capabilities that permit the endpoint to browse the internet or intranet are disabled unless such capabilities are specifically required for the proper function of the endpoint or to access specific external applications.",
"iacontrols": [
"ECSC-1"
],
"id": "V-21514",
"ruleID": "SV-23723r1_rule",
"severity": "medium",
"title": "Hardware based VVoIP or VTC endpoint web browser capabilities that permit the endpoint to browse the internet or intranet are NOT disabled.",
"version": "VVoIP/VTC 1610 (GENERAL)"
},
"V-21515": {
"checkid": "C-25758r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure web servers embedded in hardware based VVoIP and IP-VTC endpoints restrict their accessibility to authorized devices through an authentication mechanism or minimally IP address filtering, or are otherwise disabled. Further ensure that if the connection is for direct user or administrative functions, the user is authenticated minimally with a username and password.\n\nThis is a finding in the event the endpoint accepts HTTP connections from any source, except those that are specifically authorized access.\n\n",
"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 subject to unauthorized access and compromise.",
"fixid": "F-22305r1_fix",
"fixtext": "Ensure web servers embedded in hardware based VVoIP and IP-VTC endpoints restrict their accessibility to authorized devices through an authentication mechanism or minimally IP address filtering, or are otherwise disabled.\n\nConfigure the endpoint\u2019s web server to authenticate or minimally filter by IP address all automated machine to machine connections. Configure the web server to minimally authenticate users and administrators using a username and password.\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-21515",
"ruleID": "SV-23724r2_rule",
"severity": "medium",
"title": "Hardware based VVoIP or IP-VTC endpoint contains a web server, the access to which is not restricted OR which is NOT disabled.",
"version": "VVoIP/VTC 1615 (GENERAL)"
}
},
"profiles": {
"MAC-1_Classified": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-1_Classified",
"title": "I - Mission Critical Classified"
},
"MAC-1_Public": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-1_Public",
"title": "I - Mission Critical Public"
},
"MAC-1_Sensitive": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-1_Sensitive",
"title": "I - Mission Critical Sensitive"
},
"MAC-2_Classified": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-2_Classified",
"title": "II - Mission Support Classified"
},
"MAC-2_Public": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-2_Public",
"title": "II - Mission Support Public"
},
"MAC-2_Sensitive": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-2_Sensitive",
"title": "II - Mission Support Sensitive"
},
"MAC-3_Classified": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-3_Classified",
"title": "III - Administrative Classified"
},
"MAC-3_Public": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-3_Public",
"title": "III - Administrative Public"
},
"MAC-3_Sensitive": {
"description": "",
"findings": {
"V-19624": "true",
"V-19658": "true",
"V-19659": "true",
"V-19660": "true",
"V-21514": "true",
"V-21515": "true"
},
"id": "MAC-3_Sensitive",
"title": "III - Administrative Sensitive"
}
},
"slug": "video_teleconference",
"title": "Video Teleconference STIG",
"version": "1"
}
}