Video Services Policy STIG

  • Version/Release: V1R11
  • Published: 2020-02-25
  • Released: 2020-04-24
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

The Video Services Policy Security Technical Implementation Guide (STIG) provides policy guidance for video teleconferencing systems and endpoints implemented on DoD networks. These policies ensure conformance to DoD requirements that govern video services deployment and operations. 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.stig_spt@mail.mil.
c
Deficient Policy or SOP for VTC and PC camera operations regarding their ability to pickup and transmit sensitive or classified information in visual form.
High - V-16074 - SV-17061r2_rule
RMF Control
Severity
High
CCI
Version
VVoIP/VTC 1900 (GENERAL)
Vuln IDs
  • V-16074
Rule IDs
  • SV-17061r2_rule
Users of conference room or office based VTC systems and PC based communications applications that employ a camera must not inadvertently display information of a sensitive or classified nature that is not part of the communications session while the camera is active. This can happen if information in the form of charts, pictures, or maps are displayed on a wall within the viewing, or capture range of a camera. Any Pan, Tilt, and Zoom (PTZ) capabilities of the camera must be considered. One may consider visual information out of range, but it may be in range considering camera capabilities such as high definition, PTZ, and video enhancement possibilities for captured frames. Inadvertent display of classified information could also happen if the information is laying on a desk or table unprotected. NOTE: Vulnerability awareness and operational training will be provided to users of VTC and video/collaboration communications related camera(s) regarding these requirements. NOTE: This requirement is relevant no matter what the classification level of the session. In an IP environment the classification of VTC or PC communications is dependent upon the classification of the network to which the VTU or PC is attached and the classification of the facility in which it is located. While classified communications can occur at the same level of classification as the network and facility, communications having a lower classification or no classification (e.g., unclassified or FOUO) may also occur in the same environment. As such, sensitive or classified information that is not part of the communications session might be improperly disclosed without proper controls in place.NONEInformation Assurance ManagerInformation Assurance OfficerDCBP-1, ECND-1, ECSC-1
Checks: C-17117r3_chk

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

Fix: F-16179r1_fix

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

b
VTC, Unified Capability (UC) soft client, and speakerphone microphone operations policy must prevent the pickup and transmission of sensitive or classified information over non-secure systems.
Medium - V-16076 - SV-17063r2_rule
RMF Control
Severity
Medium
CCI
Version
VVT/VTC 1905
Vuln IDs
  • V-16076
Rule IDs
  • SV-17063r2_rule
Microphones used with VTC systems and devices are designed to be extremely sensitive such that people speaking anywhere within a conference room is picked up and amplified so they can be heard clearly and understood at the remote location on the call. This same sensitivity is included in VTUs that are used in office spaces. This has one disadvantage. The microphones can pick up sidebar conversations that have no relationship to the conference or call in progress. Likewise, in an open area, received conference audio can be broadcast to others in the area that are not part of the conference, and possibly should not be exposed to the conference information for need-to-know reasons. Speakerphones exhibit a similar vulnerability. This is the same confidentiality vulnerability posed to audible sound information in the environment as discussed above with the added twist that the conference audio is vulnerable to others in the environment. While this is more of an issue in environments where classified conversations normally occur, it is also an issue in any environment. This is of particularly concern in open work areas or open offices where multiple people work in near proximity. Users or operators of VTC systems of any type must take care regarding who can hear what is being said during a conference call and what unrelated conversations can be picked up by the sensitive microphone. Where a VTU is used by a single person in an open area, a partial mitigation for this could be the use of a headset with earphones and a microphone. While this would limit the ability of others to hear audio from the conference and could also limit the audio pickup of unrelated conversations, it may not be fully effective. In some instances, such as when a VTU is located in a SCIF, a Push-to-Talk (PTT) handset/headset may be required Microphones embedded in or connected to a communications endpoint, PC, or PC monitor can be sensitive enough to pick up sound that is not related to a given communications session. They could pick up nearby conversations and other sounds. This capability could compromise sensitive or classified information that is not related to the communications in progress. Speakers embedded in or connected to a communications endpoint or PC can be made loud enough to be heard across a room or in the next workspace. This capability could compromise sensitive or classified information that is being communicated during a session. Users must be aware of other conversations in the area and their sensitivity when using any communications endpoint, not only a PC based voice, video, or collaboration communications application. This awareness must then translate into protecting or eliminating these other conversations. A short range, reduced gain, or noise canceling microphone may be required. A push to talk microphone may also be required for classified areas. The microphone should be muted when the user is not speaking as both mitigation for this issue, and for proper etiquette when participating in a conference. The muting function should be performed using a positively controlled disconnect, shorting switch, or mechanism instead of a software controlled mute function on the PC. Users must be aware of other people in the area that could hear what is being communicated. This is particularly an issue if the communicated information is sensitive or classified since the parties overhearing the information may not have proper clearance or a need-to-know. To mitigate this issue, a headset or speakers should be used and at a volume that only the user can hear.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECND-1, ECSC-1
Checks: C-17118r2_chk

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

Fix: F-16180r2_fix

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

b
Deficient Policy or SOP regarding PC communications video display positioning.
Medium - V-16077 - SV-17064r1_rule
RMF Control
Severity
Medium
CCI
Version
VVoIP/VTC 1910 (GENERAL)
Vuln IDs
  • V-16077
Rule IDs
  • SV-17064r1_rule
When communicating using a PC based voice, video, UC, or collaboration communications application, the user must protect the information displayed from being viewed by individuals that do not have a need-to-know for the information. This is of additional concern if the information is classified and the viewing party does not have proper clearance. This is also a vulnerability for hardware based communications endpoints that display visual information. The mitigation for this is to position the display such that it cannot be viewed by a passerby.NONEThe inadvertent and/or improper disclosure of sensitive or classified visual information.Information Assurance OfficerInformation Assurance Manager
Checks: C-17120r1_chk

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

Fix: F-16182r1_fix

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

b
Deficient SOP or enforcement regarding presentation and application sharing via a PC or VTC.
Medium - V-16078 - SV-17065r1_rule
RMF Control
Severity
Medium
CCI
Version
VVoIP/VTC 1915 (GENERAL)
Vuln IDs
  • V-16078
Rule IDs
  • SV-17065r1_rule
Visual collaboration often requires the sharing or display of presentations, open documents, and white board information to one or more communicating endpoints. While the technology for doing this is different between hardware based VTC endpoints and PC based application endpoints, the vulnerability is the same. In both cases, the displayed information typically resides on a PC. While in presentation/sharing mode, care must be exercised so that the PC user does not inadvertently display and transmit information on their workstation which is not part of the communications session and not intended to be viewed by the other communicating parties. Users must be aware that anything they display on their PC monitor while presenting to a communications session may be displayed on the other communicating endpoints. This is particularly true when the PC video output is connected to a VTC CODEC since the information will be displayed on all of the conference monitors. This presentation/sharing feature could result in the disclosure of sensitive or classified information to individuals that do not have a validated need-to-know or have the proper clearance to view the information. Thus the presentation/sharing feature presents a vulnerability to other information displayed on the PC if the feature is misused. This is a problem when sharing (displaying) a PC desktop via any collaboration tool using any connection method. There is little that can be done to mitigate this vulnerability other than to develop policy and procedures to present to collaborative communications sessions. All users which perform this function must have awareness of the issues and be trained in the proper operational procedures. Such procedures may require that there be no non-session related documents or windows open or minimized on the PC while presenting or sharing. An additional requirement may be that the user may not permit others in a session to remotely control their PC. A SOP is needed that addresses mitigations for the vulnerabilities posed by PC data and presentation sharing. Such an SOP could include the following discussion. If a user needs to view non meeting related information while presenting to a conference, the PC external display port must be turned off or better yet, the cable disconnected. Dual monitor operation of the PC could mitigate this problem somewhat. The second monitor output would be connected to the CODEC which would serve as the second monitor. Using this method, any information may be viewed on the native PC monitor while the presentation can be displayed on the VTU presentation screen. NONEThe inadvertent and/or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.OtherInformation Assurance ManagerInformation Assurance Officer
Checks: C-17121r1_chk

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

Fix: F-16183r1_fix

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

b
Administrative sessions with the VTU do not timeout within a maximum of 15 minutes.
Medium - V-16557 - SV-17556r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2325.00
Vuln IDs
  • V-16557
Rule IDs
  • SV-17556r1_rule
An established and/or open configuration/administration (user or administrator) session that is inactive, idle, or unattended is an avenue for unauthorized access to the management port/interface of the VTU. This can lead to compromise of the system’s/device’s configuration and/or denial of service. Idle sessions can be caused simply by a user or administrator being distracted or diverted from a configuration/administration session/task or by forgetting to log out of the management session when finished with his/her tasks. To ensure that the capability for unauthorized access in the event of an idle/inactive session is mitigated; an idle/inactive session timeout/logout capability must exist and be used. The timeout duration must be configurable to adjust for changing policies and requirements. Typically this duration should be set for 15 minutes as a maximum; however it can be shortened for tighter security. This requirement applies to all types of local and remote management connections/sessions and all management session protocols. While not specifically related to VTC, this requirement can work against or inhibit certain management functions. System/device configuration backups or software upgrades requiring file transfers may exceed the idle timeout duration. In this case, the operation might fail if the idle timer disconnected the session midway through. During such events, the idle timer should recognize this activity as the session not being idle. Alternately, the idle timer duration may be extended or may be disabled as long as it is re-enabled/reset after the file transfer. Another management function that can be inhibited by an idle session timeout is when a session is required to be established for the continuous monitoring of the system/device. In this case, the idle timer may be disabled as long as it is re-enabled after the monitoring is no longer needed. RTS-VTC 2325.00 NONEAccess to the VTU by unauthorized individuals possibly leading to the disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.N/ADesignated Approving AuthorityInformation Assurance OfficerSystem Administrator
Checks: C-17356r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure a configurable “idle/inactive session timeout/logout feature” is available and used to disconnect idle/inactive management connections or sessions. The idle timer is set to a maximum of 15 minutes. Longer time periods are documented and approved by the responsible DAA. This requirement applies to all types of physical and logical management connections and all management session protocols. NOTE 1: This is not a finding in the event an approved management connection/session must be established for permanent full time monitoring of a system/device or the production traffic it processes. NOTE 2: This is not a finding during management operations where the disconnection of the connection/session due to idle session timeout would inhibit the successful completion of a management task. A SOP must be established and enforced, or an automated process used, to ensure the idle/inactive session timeout feature is re-enabled and reset following such activity NOTE 3: During APL testing, this is a finding in the event this requirement is not supported by the VTU. > Determine if a configurable “idle/inactive session timeout/logout feature” is available and used to disconnect idle/inactive management connections or sessions. > Determine if the timeout is set to a maximum of 15 minutes. > If the timeout is set to a longer period, determine if the extended time period is documented and approved by the responsible DAA and a SOP is in place and enforced that will insure that the idle/inactive session timeout feature is re-enabled and reset following monitoring/testing activity.

Fix: F-16526r1_fix

[IP][ISDN]; Perform the following tasks: > Implement a VTU with a configurable “idle/inactive session timeout/logout feature” for management sessions. > Configure/set the idle timer to a maximum of 15 minutes. > If longer periods are necessary, obtain approval from the responsible DAA. Document approval for inspection by auditors. Develop and enforce a SOP that will insure that the idle/inactive session timeout feature is re-enabled and reset following monitoring/testing activity. Include this SOP in administrator training, agreements and guides.

b
Use of media streaming is not documented properly or is not configured securely.
Medium - V-16560 - SV-17559r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2340.00
Vuln IDs
  • V-16560
Rule IDs
  • SV-17559r1_rule
Media Streaming as it is related to VTC systems permits a VTU to engage in a normal IP or ISDN connected conference with other VTUs while broadcasting (streaming) the conference audio and video to PC workstations over an IP based LAN to which it is connected. This permits a workstation user to view the conference in near real time but not to participate in it. VTUs may also stream other content such as pre-recorded media played from a VCR or similar media source and some VTUs support streaming while others do not. It seems that as vendors mature their streaming server technology and more products become available, they are removing the streaming capability from the CODEC where it presents greater vulnerability. Streaming from a VTU’s CODEC can also be used to record a conference by sending the stream to a recording/streaming server that can perform the recording function. These servers also serve as streaming distribution points. Recording/Streaming servers are discussed later. While streaming from a CODEC most often uses IP multicast, streams can also be sent to one receiver (e.g., PC or recording/distribution server), or to multiple receivers in the local broadcast domain IP multicast or broadcast streaming works best within a LAN where ample bandwidth is available and IP multicast is supported. While multicast streaming is conceivable across a WAN such as the Internet, it is much less feasible and less reliable due to limited multicast support and access circuit bandwidth constraints. To use IP multicast, the network elements must be configured to support it. To enable streaming, the following configuration items are needed: - Destination address, unicast (address of specific destination, client or server), broadcast (local subnet or global), multicast (address configured on a router in the range 224.0.0.1-239.255.255.255) - IP port(s) (some CODECs may require one port for audio and one for video) - Time-To-Live (TTL) (i.e., number of router hops or routers to traverse) VTU Streaming can typically be activated by a user selecting it from a menu. It could also be possible to activate it by the simple press of a button on the remote control. As such, it could be possible to activate streaming by accident when it is not desired or required. Additionally, some VTUs permit a remote user to activate the feature. The “broadcast” or stream is received by a compatible client running on a PC. Examples of clients used are RealMedia Player™, Apple Quicktime™, VIC, or Cisco IP/TV. To receive a multicast stream, the recipient can do one of the following two things: - First, they can use a web browser to access the IP address of the CODEC that is streaming. The user accesses the CODEC’s web page and clicks a link to receive the stream. This causes the browser to download an .sdp file (e.g., filename.sdp) that contains information about the stream and launch the streaming client. The .sdp file tells the client what IP address and port the stream can be found on as well as the compression types (protocols) being used. Accessing the streaming web page or .sdp file typically requires the use of a password before gaining access. Some vendors use the administrator password (not acceptable) while others use a “meeting password” In some cases the recipient (remote user) can also activate streaming (i.e., cause the CODEC to begin streaming) from this web page if it is not already activated. - The second method of access is essentially direct. The recipient uses the streaming client to retrieve the .sdp file from the CODECs IP address. Some streaming clients can access a multicast stream without the use of an .sdp file. The only access control for streaming is that imposed by the CODEC for accessing its web page and/or retrieving the .sdp file. While this is effective using clients such as RealMedia Player™, Apple Quicktime™, which require the .sdp file information to function, there are other clients that do not. Using a client that does not, once the CODEC is streaming, anyone knowing the IP address and port for the stream can view the stream. There is no access control for viewing a media stream in this manner because IP provides no access control for joining an IP multicast group. When streaming, there is no way of knowing who or how many recipients are viewing a conference. The number of possible recipients is virtually unlimited. Typically, there is only an indication on the VTU screen that the CODEC is streaming. Again, some VTUs permit streaming to be activated remotely by anybody who knows the IP address of the VTU and can access its streaming web page. As such, it could be possible for an unauthorized person to activate streaming and eavesdrop on the room or a conference in session. These vulnerabilities can greatly jeopardize the confidentiality of any given conference by broadcasting it on the connected LAN to indeterminate numbers of unknown recipients. An additional vulnerability that streaming presents to any conference, whether hosted on a central MCU, point-to-point, or a MCU integrated unto a VTU is that any meeting participant could accidentally or maliciously stream the meeting from their VTU if their VTU supports streaming. For these reasons, the activation and use of streaming from a VTU/CODEC is discouraged and must be tightly controlled by all IAOs who are responsible for any streaming capable VTU that might participate in a conference. CODECs must be configured in such a way that if streaming is activated, the stream can only be accessed by authorized individuals or be non-functional or inaccessible if activated by accident. Generally speaking, the use of streaming to an IP multicast or broadcast address should never be used or activated unless it is required to fulfill a specific, validated, authorized, and documented mission requirement. This applies to both streaming from a CODEC or a recording/streaming server because of the inherent lack of full user/recipient access control. Streaming to a unicast address, i.e., one recipient, from a CODEC should be the only method used. The one recipient should only be a recording/streaming server. The best method for streaming to a number of recipients is to use a recording/streaming/web server where media can be encrypted and DoD compliant access control and auditing can be enforced via individual (unicast) viewer sessions with the server. IP multicast or broadcast should not be used. In the event IP multicast must be used, the media stream must be encrypted and a secure key exchange process employed. Full DoD compliant access control and auditing is required to gain access to the .sdp file that contains the information required to decrypt the stream. Encryption will prevent a streaming client that does not require the .sdp file from viewing the content after accessing the stream. NONEThe inadvertent or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.Information Assurance ManagerInformation Assurance Officer
Checks: C-17358r1_chk

[IP]; Interview the IAO to validate compliance with the following requirement: Ensure the following regarding VTC streaming: - Streaming of VTC content will not be implemented unless required to fulfill a specific, validated, authorized, and documented mission requirement. - Streaming from a VTU/CODEC is to the unicast addresses of a streaming/recording server only, not to an IP multicast or broadcast address due to the lack of user/recipient access control. - A streaming server is used that provides the streaming service via an authenticated and audited client to server (unicast) session or authenticated and audited access to an .sdp file. - Streaming server access control will use DoD PKI. - Streaming server to client connection is encrypted for confidentiality of the streamed media. - If approved, and IP multicast must be used, the media stream must be encrypted and a secure key exchange process employed. Determine if VTC media streaming is being used. If not, this is not a finding. If so, additionally determine the following: - Inspect the documentation regarding the validated and authorized/approved mission requirement. This is a finding if the documentation or approval is deficient or non-existent. - If IP multicast or IP broadcast is being used as the distribution method. If so, this is a finding unless the use is approved (inspect DAA approval documentation) and the media stream is encrypted and a secure key exchange process employed. - If streaming from a CODEC is being used, this is a finding if the media stream is not limited to the single IP address of a streaming/recording server. - If a streaming server is being used, this is a finding if the stream is not delivered via an authenticated and audited client to server (unicast) session or authenticated and audited access to an .sdp file; and/or Streaming server access control does not use DoD PKI; and/or the server to client connection is not encrypted.

Fix: F-16528r1_fix

[IP]; Perform the following tasks: - Discontinue the use of VTC media streaming OR obtain approval for the validated mission requirement, the distribution method, and fully document the requirement, distribution method, and the approval. - If streaming from a CODEC is approved, configure the codec for a unicast connection such that the media stream is limited to the single IP address of a streaming/recording server. - If IP multicast or IP broadcast is approved as the distribution method. Configure the streaming server/CODEC to encrypt the media stream and use a secure key exchange process. - If streaming from a streaming/recording server is approved, configure the server to provide the streaming service via an authenticated and audited client to server (unicast) session or authenticated and audited access to an .sdp file; additionally configure the server to use DoD PKI for access control; and to provide an encrypted client server connection or encryption of the media stream.

b
No indicator is displayed on the VTU screen when CODEC streaming is activated.
Medium - V-16562 - SV-17561r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2350.00
Vuln IDs
  • V-16562
Rule IDs
  • SV-17561r1_rule
It is imperative that the operator of a VTU know if his/her CODEC is streaming. This is due the ease with which streaming can be activated accidentally or intentionally and that it can be activated remotely by various methods or individuals with different privilege levels. The VTU must display an indication on the screen if it is actively streaming so that the VTU user/operator can be aware of the fact and take action to stop the streaming or disconnect the call if the CODEC should not be streaming. Note: For additional information regarding the vulnerabilities associated with VTC streaming, see the discussion under RTS-VTC 2340 NONEThe inadvertent or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.OtherSystem AdministratorDCBP-1, ECSC-1
Checks: C-17361r1_chk

[IP]; Validate compliance with the following requirement: Ensure an on-screen indicator is displayed when the VTU/CODEC is actively streaming. Include awareness of the indicator and its meaning in user training and user guides. Note: This is a requirement whether streaming from a CODEC is approved or not. Note: During APL testing, this is a finding in the event this requirement is not supported by the CODEC. This is a finding if an on-screen indicator is not displayed when the VTU/CODEC is actively streaming. Validate compliance via inspection of the device manuals or activate streaming and look for the on-screen indicator. Activating the streaming feature may require applying a streaming configuration. If so, be sure to remove/disable the configuration following the indicator test.

Fix: F-16532r1_fix

[IP]; Perform the following tasks: - Purchase VTC equipment that either does not support streaming from the CODEC or provides an indicator that the CODEC is actively streaming. AND/OR - Configure the CODEC to provide the required on-screen indicator in the event such display does not occur by default. AND Include awareness of the indicator and its meaning in user training and user guides.

b
Deficient SOP or enforcement for VTC/CODEC streaming.
Medium - V-16564 - SV-17563r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2360.00
Vuln IDs
  • V-16564
Rule IDs
  • SV-17563r2_rule
To control streaming from a VTU/CODEC, the site must have a policy and procedure regarding the use of streaming. This could be very simple if streaming will never be used or more complex if there is the potential for its use. Such an SOP will reflect the requirements of this STIG regarding streaming. Note: For additional information regarding the vulnerabilities associated with VTC streaming, see the discussion under RTS-VTC 2340 NONEThe inadvertent or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerOtherDCBP-1, ECSC-1, IAAC-1, IAIA-1, IAIA-2
Checks: C-17362r1_chk

[IP]; Interview the IAO to validate compliance with the following requirement: In the event the VTU/CODEC is connected to an IP based LAN, and if the CODEC supports streaming, ensure a “Streaming” policy and procedure is in place and enforced that addresses the following: - The approval of conference streaming on a case by case basis prior to it being configured by an administrator and activated. - Implementation and distribution of temporary one-time “streaming passwords”, and other session information, to control recipient access to the media stream. For best protection of the system, this password must be used one time and not repeated. This password must not match any other user or administrative password and must be configured to meet or exceed DoD password complexity requirements since entry from a keyboard is expected. - Requirements for implementing an appropriate streaming configuration to limit the reach of the stream across the network. - Re installation of the “blocking” configuration and password (as required below) following any given streaming session. - Changes to the “access blocking” configuration and password in the event it is compromised or if administrative staff changes. Note: The details of this SOP will be included in user’s training, agreements, and guides. Note: This is a requirement whether streaming from a CODEC is approved or not. Inspect the SOP as well as user training materials, agreements, and guides to determine if the items in the requirement are adequately covered. Interview the IAO to determine how the SOP is enforced. Interview a sampling of users to determine their awareness and implementation of the requirement and whether the SOP is enforced. This is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details.

Fix: F-16534r1_fix

[IP]; If the CODEC supports streaming, Perform the following tasks: - Develop and enforce the SOP, train users, and include the SOP in user agreements and guides. - The SOP will address the following: > The approval of conference streaming on a case by case basis prior to it being configured by an administrator and activated. > Implementation and distribution of temporary “streaming passwords”, or other session information, to control recipient access to the media stream. For best protection of the system, this password must be used one time and not repeated. This password must not match any other user or administrative password and must be configured to meet or exceed DoD password complexity requirements since entry from a keyboard is expected. A temporary, one time password is implemented during streaming enablement and configuration of the given streaming session. > Requirements for implementing an appropriate streaming configuration to limit the reach of the stream across the network. > Re installation of the “blocking” configuration and password (as required below) following any given streaming session. > Changes to the “access blocking” configuration and password in the event it is compromised or if administrative staff changes.

a
The VTC endpoints and system components 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.
Low - V-17589 - SV-18715r2_rule
RMF Control
Severity
Low
CCI
Version
RTS-VTC 1000.00
Vuln IDs
  • V-17589
Rule IDs
  • SV-18715r2_rule
Configuring the network device 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. Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network device. Security-related parameters are those parameters impacting the security state of the network device, including the parameters required to satisfy other security control requirements. Traditionally, VTC systems and devices do not support DoD requirements on all access points and features. However, DoD VTC systems are subject to these policies that provide access controls, address vulnerabilities, and provide for user and administrator accountability. This requirement highlights the lack of IA support in security readiness review as well as in certification and accreditation reports. The remaining requirements attempt to define mitigations to this lack of policy compliance to the greatest extent possible.System AdministratorInformation Assurance OfficerDesignated Approving AuthorityDCBP-1, ECSC-1
Checks: C-18889r2_chk

Review the VTC system architecture and ensure the VTC endpoints and system components are configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Ensure all VTC endpoints and system components comply with the following NIST 800-53 (Rev. 4) IA controls: - Account Management (AC-2) - Individual ID & Password (IA-5) - Lockout on logon failure (AC-7) - Warning Banner (AC-8) - Roles (privileged access) (AC-1) - Least Privilege (AC-6, SA-17) - Security audit (AU-2) - Audit Content (AU-3) - Audit Trail Protection (AU-12) If the VTC endpoints and system components are not configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, this is a finding.

Fix: F-17507r2_fix

Procure and implement VTC endpoints and system components configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Encourage vendors to develop VTC systems and devices that provide robust IA features that support compliance with DoD policies for all devices.

b
Deficient SOP or enforcement regarding how to power-off the VTU when it is not actively participating in a conference.
Medium - V-17591 - SV-18718r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1020.00
Vuln IDs
  • V-17591
Rule IDs
  • SV-18718r1_rule
When the VTU is not active, it is best to power it off to mitigate its vulnerabilities. This may not be practical, particularly if the VTU is intended, or required, to receive un-scheduled incoming calls or is to be remotely managed and monitored in an un-scheduled manner. Receiving un-scheduled incoming calls that are automatically answered is, in itself, a vulnerability. This is an issue for IP and ISDN connected systems if auto-answer is on. The auto-answer feature is discussed later. Remote access and monitoring are also vulnerabilities due to the lack of strong access control mechanisms and the ease with which a VTU can be compromised if it is connected to an IP network. These vulnerabilities are discussed later. The point of this and the next requirement is to disable the capability of the VTU to “see and hear” information and activities located or occurring near the VTU when it is not actively participating in a call. While these vulnerabilities are of particular concern in an office or other work area, it may be of less concern in a conference room except if meetings occur in the facility that do not require the use of the VTC system.This can be deemed N/A or “Not a Finding” in the event there are validated, approved, and documented mission requirements; however, the VTU is still subject to RTS-VTC 1025.00. An example of a mission requirement needing validation, approval, and documentation would be a requirement for nightly testing of the VTU from a central location or a need to regularly answer incoming calls. This is N/A if the VTU is located in a conference room that is only used for VTC conferences the room is empty when not preparing for or participating in a VTC; the room contains no sensitive or classified information when not in use; no other meetings are held there; and no other work or activities occur there. The inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerOther
Checks: C-18891r1_chk

[IP][ISDN] Interview the IAO to validate compliance with the following requirement: In the event the VTU is connected to an IP network and/or if auto-answer is on while connected to an ISDN network, ensure a policy and procedure is in place and enforced that requires users to power-off the VTU when it is not actively participating in a conference unless it is required to be powered-on to meet validated, approved, and documented mission requirements. Note: While this requirement can be deemed N/A or “Not a Finding” in the event there are validated, approved, and documented mission requirements, the VTU is still subject to RTS-VTC 1025.00. An example of a mission requirement needing validation, approval, and documentation would be a requirement for nightly testing of the VTU from a central location or a need to regularly answer incoming calls. Note: The documented and validated mission requirements along with their approval(s) are maintained by the IAO for inspection by auditors. Such approval is obtained from the DAA or IAM responsible for the VTU(s) or system. Note: This is not a requirement (i.e., N/A) if the VTU is located in a conference room that is only used for VTC conferences; the room is empty when not preparing for or participating in a VTC; the room contains no sensitive or classified information when not in use; no other meetings are held there; and no other work or activities occur there. Note: Sleep mode does not fully mitigate the vulnerability addressed here unless it can be invoked by the user. Typically a VTU would go to sleep after a period of time. During this period, the vulnerability still exists and may exist in sleep mode depending upon what is required to wake the VTU. Sleep mode should be able to be initiated by the user. Exiting sleep mode should be initiated by user action and not an automated process. This functionality needs to be explored further and specific requirements defined. Note: This requirement must be stated in user’s guides and training because the user is the one that must implement these mitigations. Inspect the SOP as well as user training materials, agreements, and guides to determine if the requirement is adequately covered. Interview the IAO to determine how the SOP is enforced. Interview a sampling of users to determine their awareness and implementation of the requirement and whether the SOP is enforced. Have a sampling of users demonstrate how to power-off the VTU when it is not actively participating in a conference. This is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details. Have a sampling of users demonstrate how to power-off the VTU when it is not actively participating in a conference.

Fix: F-17509r1_fix

[IP][ISDN]; Perform the following tasks: Define and enforce policy and procedure that when a VTU is connected to an IP network and/or if auto answer is on while connected to an ISDN network that the user is required and knows how to power-off the VTU when it is not actively participating in a conference unless it is required to be powered-on to meet validated, approved, and documented mission requirements. Provide user training regarding this SOP and include it in user agreements and user guides.

b
Deficient SOP or enforcement for microphone and camera disablement when the VTU is required to be powered and inactive (in standby).
Medium - V-17592 - SV-18719r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1025.00
Vuln IDs
  • V-17592
Rule IDs
  • SV-18719r1_rule
In the event that mission requirements dictate the VTU be in a powered-on state when inactive (thereby making RTS-VTC 1020 N/A or “Not a Finding”), other measures are required to mitigate the vulnerability of possible VTU compromise and establish a defense in depth posture. These mitigations are, 1 - to mute the microphone and 2 – to disable the viewing capability of the camera in some manner. If the camera is movable, it could be aimed at the nearest corner of the room; however, this is no mitigation if the VTU is compromised or remotely controlled and the camera can be re-aimed into the room. The best mitigation for the camera is to cover the lens of the camera. This is applicable to both movable and fixed cameras.NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerOtherDCBP-1, DCSD-1, ECSC-1, PEDI-1
Checks: C-18892r1_chk

[IP][ISDN] Interview the IAO to validate compliance with the following requirement: In the event the VTU is connected to an IP network and/or if auto-answer is on while connected to an ISDN network, AND the VTU is required to be powered-on to meet validated, approved, and documented mission requirements (that is RTS-VTC 1025.00 is “not a finding”); ensure a policy and procedure is in place and enforced that requires users to perform the following when the VTU is it is not actively participating in a conference: Mute the microphone. AND Disable the capability of the camera to view activities within the room as follows: Cover the camera(s) if its/their position/aim is fixed or able to be remotely controlled. OR Aim the camera(s) at a nearby corner where it/they cannot see room activities if the camera position/aim is movable but cannot be remotely controlled. Note: The documented and validated mission requirements along with their approval(s) are maintained by the IAO for inspection by auditors. Such approvals are obtained from the DAA or IAM responsible for the VTU(s) or system. This documentation and validated mission requirements are the same documentation that renders RTS-VTC 1020.00 N/A or “Not a Finding” Note: This finding can be reduced to a CAT III in the event the camera(s) can be remote controlled but are aimed at the wall (e.g., a corner) where it/they cannot see room activities if the camera supports aiming or being moved. While the practice of aiming the camera at the side or back wall of the room where there is nothing to see and muting the microphone can mitigate normal operational issues, this measure is not a mitigation if the camera can be remotely controlled via auto-answer and Far End Camera Control (FECC) and/or the CODEC remote control/configuration feature is not configured properly, is compromised, or can be accessed by a administrator with the remote access password. Note: This is not a finding in the event sleep mode provides the necessary disablement functions and is invoked by the user when the VTU is powered on or leaves the active state. This finding can be reduced to a CAT III finding in the event sleep mode provides the necessary disablement functions and the VTU enters sleep automatically within 15 minutes of when the VTU entered standby. This is still a finding because the vulnerability exists during the standby period. Note: This is not a requirement (i.e., N/A) if the VTU is located a conference room that is only used for VTC conferences; the room is empty when not preparing for or participating in a VTC; the room contains no sensitive or classified information when not in use; no other meetings are held there; and no other work or activities occur there. Note: A camera cover should be provided by the camera vendor and attached in such a manner that it is not easily detachable so that it cannot be easily lost. Alternately, the cover can be as simple as an opaque cloth of appropriate size or sewn such that it won’t fall off easily. If the cover is detachable such that can be easily lost, a supply of replacement covers should be readily available. Note: This requirement must be stated in site user’s guides and training because the user is the one that must implement these mitigations. Inspect the SOP as well as user training materials, agreements, and guides to determine if the items in the requirement are adequately covered. Interview the IAO to determine how the SOP is enforced. Interview a sampling of users to determine their awareness and implementation of the requirement and whether the SOP is enforced. This is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details. This is a finding if the VTU is found to be powered-on when inactive and the microphone and/or camera are not disabled. This is a finding if there is no documented requirement that the VTU be powered-on or there are no approvals. Inspect the documentation relating to the DAA approvals for the validated, approved, and documented mission requirements that require the VTU to be powered-on while inactive. This is a finding if there is no SOP regarding the disablement of the VTU microphone and camera when the VTU is not actively participating in a conference. Interview the IAO to determine if this requirement is covered in a SOP and user training/agreements. Interview a sampling of users to determine their awareness and implementation of the requirement.

Fix: F-17510r1_fix

[IP][ISDN]; Perform the following tasks: Define and enforce policy and procedure that when a VTU is connected to an IP network and/or if auto answer is on while connected to an ISDN network AND the VTU is required to be powered-on to meet validated, approved, and documented mission requirements., that the user is required and knows how to disable the VTU microphone and camera when the VTU is not actively participating in a conference. Provide user training regarding this SOP and include it in user agreements and user guides.

b
Deficient VTU sleep mode configuration or operation.
Medium - V-17593 - SV-18720r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1027.00
Vuln IDs
  • V-17593
Rule IDs
  • SV-18720r1_rule
Sleep mode is the power conservation and semi-disabled state that some VTUs can enter after being on standby for a period of time. While in sleep mode, the VTU is still minimally powered and thereby could be remotely accessed, managed, compromised, or easily activated. For the purpose of our discussions, sleep mode is different from standby mode by the fact that in standby mode, by our definition, the VTU is not actively participating in a call but is ready to receive or place a call. Sleep mode, is a semi off state whereby most functions of the VTU are disabled to conserve power. If used to mitigate vulnerabilities and not just conserve power, sleep mode must have the characteristics noted in this requirement.NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerOtherDCBP-1, ECSC-1
Checks: C-18893r1_chk

[IP][ISDN]; Interview the IAO to validate for CODEC compliance with the following requirement: In the event sleep mode is to be used to mitigate standby vulnerabilities, ensure that sleep mode provides and/or is configured to provide the following functionality: - The CODEC’s audio and video pickup/transmission capability should be disabled as follows: > Disable the microphone’s audio pickup capability. > Disable the camera’s image capture capability. > Disable remote activation/control capabilities of the camera and microphone. - Auto-answer capabilities are disabled. - Local user action is required to exit sleep mode such as pressing some button or key to activate the wakeup function. - If a wake-on-incoming-call feature is available, it must not fully wake the VTU and may only provide an indication that there is an incoming call along with meeting the incoming call display requirement below so that the user can make an informed decision to wake the system and answer the call or not. - In the event the VTU can be remotely accessed or managed during sleep mode, the following controls must be in place: > The VTU must limit access to specific authorized IP addresses. > Remote access must not permit the activation of the microphone and camera unless this functionality is required to meet validated, approved, and documented mission requirements. Note: If the VTU meets the user activation/authentication and banner requirements stated later, these function must be invoked when the VTU wakes. Note: If the VTU has a sleep mode, in addition to the required capabilities noted above, it should have configurable settings that permit immediate user activation via a button press and an automatic activation with a configurable time frame that could be as short as 15 seconds or as long as several hours, or never. This would permit the sleep mode to be used as partial or full mitigation for the vulnerabilities addressed by the above two requirements. The various configurable settings could be used when the VTU is in different locations. For example, the short duration and/or user activation could be used in a classified environment. APL Testing: This is a finding in the event this requirement is not supported by the VTU. Have the IAO or SA demonstrate the configuration setting required to meet the individual features of this requirement. Place the VTU in standby/sleep mode, place a call to the VTU, and view its responses.

Fix: F-17511r1_fix

[IP][ISDN]; Perform the following tasks: Configure the VTU to provide the following functionality: - The CODEC’s audio and video pickup/transmission capability must be disabled as follows: > Disable the microphone’s audio pickup capability. > Disable the camera’s image capture capability. > Disable remote activation/control capabilities of the camera and microphone. - Auto-answer capabilities are disabled. - Local user action is required to exit sleep mode such as pressing some button or key to activate the wakeup function. - If a wake-on-incoming-call feature is available, it must not fully wake the VTU and may only provide an indication that there is an incoming call along with meeting the incoming call display requirement below so that the user can make an informed decision to wake the system and answer the call or not. - In the event the VTU can be remotely accessed or managed during sleep mode, the following controls must be in place: > The VTU must limit access to specific authorized IP addresses. > Remote access must not permit the activation of the microphone and camera unless this functionality is required to meet validated, approved, and documented mission requirements. Note: If the VTU meets the user activation/authentication and banner requirements stated later, these function must be invoked when the VTU wakes. Note: If the VTU has a sleep mode, in addition to the required capabilities noted above, it should have configurable settings that permit immediate user activation via a button press and an automatic activation with a configurable time frame that could be as short as 15 seconds or as long as several hours, or never. This would permit the sleep mode to be used as partial or full mitigation for the vulnerabilities addressed by the above two requirements. The various configurable settings could be used when the VTU is in different locations. For example, the short duration and/or user activation could be used in a classified environment.

b
Inadequate display of an incoming call notification such that the VTU user can make an informed decision to answer the call or not.
Medium - V-17594 - SV-18721r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1030.00
Vuln IDs
  • V-17594
Rule IDs
  • SV-18721r1_rule
In the event that mission requirements dictate the VTU be in a powered-on state when inactive the VTU becomes available to receive incoming calls (except possibly when sleeping). Additionally, if a VTU is connected to an IP network, it may be capable of receiving incoming calls while active. When a VTU receives an incoming call; the normal operation is that a notification of the incoming call is provided both audibly and visually. The visual notification typically includes a display of the source of the call. This can be a phone number or IP address. This information should be accompanied by an identification of the caller. While the source information is typically available from the network, the identity of the calling party associated with that information is typically contained in a locally accessible directory. If the source information is in the directory, the associated identity information is located and added to the display or displayed by itself. This directory is typically on the VTU or can be on a locally associated management or directory server. Directories must therefore be kept up to date with user information related to other VTUs with which any given VTU is expected to communicate. Ideally, the full identity of the caller is sent from the calling system for display on the called system even if there is no local directory entry. Based upon the displayed information, the user of the VTU can make an informed decision and take appropriate action to answer the call, or not. Users must be trained to not answer calls from unknown sources in the event doing so could disclose sensitive or classified information in the area of the VTU or while engaged in a VTC session. NONESystem AdministratorInformation Assurance OfficerOtherDCBP-1, ECSC-1
Checks: C-18894r1_chk

[IP][ISDN] Interview the IAO to validate for compliance with the following requirement: If the VTU is capable of receiving incoming calls while inactive or while active, ensure the following: - The VTU displays the source of the incoming call and to the extent possible, the identity of the caller, such that the user can make an informed decision to answer the call or not. - Directories are maintained with current information regarding user information related to other VTUs with which the VTU is expected to communicate unless calling VTUs provide the caller information along with the source information. - Users are trained to not answer incoming calls from unknown sources in the event doing so could disclose sensitive or classified information in the area of the VTU. - Users are trained to not answer incoming calls from unknown sources or sources that may not have appropriate clearance or a need-to-know during a conference since doing so could improperly disclose sensitive or classified information to the caller. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU. Interview the IAO and have him/her demonstrate on a sampling of the VTUs in the system

Fix: F-17512r1_fix

[IP][ISDN]; Perform the following tasks: - Configure the VTU to display the source of the incoming call and to the extent possible, the identity of the caller, such that the user can make an informed decision to answer the call or not. - Maintained directories with current information regarding user information related to other VTUs with which the VTU is expected to communicate unless calling VTUs provide the caller information along with the source information. - Train users to not answer incoming calls from unknown sources in the event doing so could disclose sensitive or classified information in the area of the VTU. - Train users to not answer incoming calls from unknown sources or sources that may not have appropriate clearance or a need-to-know during a conference since doing so could improperly disclose sensitive or classified information to the caller.

a
Auto-answer feature is not administratively disabled.
Low - V-17595 - SV-18722r1_rule
RMF Control
Severity
Low
CCI
Version
RTS-VTC 1040.00
Vuln IDs
  • V-17595
Rule IDs
  • SV-18722r1_rule
Some VTC endpoints have a user selectable feature that provides the capability to automatically answer an incoming call. This would be akin to your speakerphone picking up a call each time the phone rang allowing an ongoing conversation to be heard by the caller. This feature, if activated, is highly detrimental to the confidentiality of information in a room in which a VTU is installed. In fact, a security incident could result from “auto-answer” being enabled. Such would be the case in the event a VTU automatically answered a call when a classified meeting or discussion (not via VTC) was being held in a conference room or an office having VTC capability. The auto-answer feature must not be activated by a user unless the feature is required to satisfy mission requirements. Furthermore, users must be trained in the vulnerabilities associated with the auto-answer feature and in its proper use if it is to be used. The ideal mitigation for this vulnerability is for the auto-answer feature to not be supported by the VTU or there be an administrator setting that can disable the feature preventing a user from activating it. NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDesignated Approving AuthorityOtherDCBP-1, ECSC-1
Checks: C-18895r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: If a VTC endpoint auto-answer feature is available, ensure it is administratively disabled, thus ensuring the feature is not selectable by the user, unless required to satisfy validated, approved, and documented mission requirements. Note: The documented and validated mission requirements along with their approval(s) are maintained by the IAO for inspection by auditors. Such approval will be obtained from the DAA or IAM responsible for the VTU(s) or system. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU. Verify that if the auto-answer feature is available on the VTU endpoint that it is administratively disabled. If the auto-answer is a mission requirement, verify that IAO has evidence/documentation that the DAA or IAM responsible has given written approval for its use.

Fix: F-17513r1_fix

[IP][ISDN]; Perform the following tasks: Administratively disable the auto-answer function on the VTU unless required to fulfill validated and approved mission requirements. If auto-answer is required to fulfill validated and approved mission requirements, obtain written approval for the use of this function from DAA or IAM and maintain documentation on the validated requirement and approval. Train users in the proper use and vulnerabilities associated with the use of auto-answer

b
Deficient SOP for, enforcement, usage, or configuration of the auto-answer feature.
Medium - V-17596 - SV-18723r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1060.00
Vuln IDs
  • V-17596
Rule IDs
  • SV-18723r1_rule
In the event the auto-answer feature is approved for use or cannot be administratively disabled and thus is available for users to activate, several mitigating requirements must be met. The first of these is that the user(s) to which the feature is available must be trained in its proper use and in the vulnerabilities it presents because the user is the one that must implement the operational mitigations. The second is the VTU must answer the call with the microphone muted and with the camera covered or disabled. This will prevent an ongoing conversation from being heard and room activities seen by the caller. This will also prevent the room from being audibly and visually monitored if a call is automatically answered when the VTU is un-attended. The third mitigating requirement is that the user must be notified that the VTU has received and answered a call such that the user may be viewed if the camera is not/cannot be covered or listened to if the microphone is not/cannot be muted. This means that a noticeable visual indication must be provided and any available audible signal must be maintained at an audible level so that it can be heard.NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerOtherDCBP-1, DCSD-1, ECSC-1
Checks: C-18896r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: In the event the auto-answer feature is available and/or used, ensure a policy and procedure is in place and enforced such that, all of the following occurs: - The auto-answer feature is configured to answer with the microphone muted. - The camera is covered or otherwise disabled while waiting for a call. - The VTU provides a visual indication that a call has been answered. - The user will ensure the ringer or audible notification volume is set to an easily audible level or the VTU will automatically satisfy this requirement. - The user(s) to which the feature is available is trained in its proper use as reflected in the SOP and in the vulnerabilities it presents. Note: During APL testing, this is a finding in the event “auto-answer with microphone muted” is not configurable on the VTU. It is also desirable that this setting will ensure the audible notification is at a level to be easily heard. Determine if this requirement is covered in a SOP and user training/agreements. Interview a sampling of users to determine their awareness and implementation of the requirement. Verify that, if supported, the VTU auto-answer feature is configured to answer with microphone muted.

Fix: F-17514r1_fix

[IP][ISDN]; Perform the following tasks: In the event the auto-answer feature is approved for use, perform the following tasks: - Maintain full documentation on the validation of the mission requirement and the DAA approval to use the auto-answer feature - Develop and enforce a SOP regarding the proper use of the auto-answer feature. - Configure the auto-answer feature to answer with the microphone muted. - Ensure the camera is covered by the user or otherwise disabled automatically while waiting for a call. - Ensure the VTU provides a visual indication that a call has been answered. - Train users to ensure the ringer or audible notification volume is set and maintained at an easily audible level or the VTU automatically satisfies this requirement. - Train the user(s) to which the feature is available in its proper use as reflected in the SOP and in the vulnerabilities it presents.

b
Deficient SOP or enforcement regarding handling of incoming calls while in a conference.
Medium - V-17598 - SV-18725r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1140.00
Vuln IDs
  • V-17598
Rule IDs
  • SV-18725r1_rule
Whether active or inactive, a VTU must display the source of an incoming call and the caller’s identity so that the user can decide to answer the call or not. This decision must also be based upon what information would be made available to the caller when call is answered. The information that would be placed at risk is what can be picked up in the physical area of the VTU or what is being carried by the conference in which it is participating. If the VTU is participating in a conference already, answering a call while in a conference would activate the VTU’s integrated MCU and join the caller to the conference. The possibility of an incoming call being automatically joined to a meeting in progress in this manner places the confidentiality of that meeting at risk. The caller could become a participant of a meeting to which they were not invited and subsequently receive sensitive or classified information for which the caller may or may not have a need-to-know or appropriate security clearance. As with a VTU in standby mode, an “auto-answer” feature is of great concern during a VTC session. A VTU must be configured in such a way that it cannot automatically answer a call and join the call to an active session without some form of access control. Either user intervention or a properly managed “local meeting” password is required to join such an incoming call to an active session. In some instances the “do-not-disturb” feature may be used by the user to block such calls by returning a “busy” signal. The capability of joining a conference on a VTU using its integrated MCU through the use of a “local meeting” password must be used only when the VTU user needs to pre-schedule and host a multipoint conference on his/her VTU. This capability must not be available at all times. The VTU should have the capability to disable this kind of access when it is not needed. Local meeting passwords must be used one time and not repeated. This requirement is discussed later. NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerInformation Assurance ManagerOther
Checks: C-18898r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure the following regarding incoming calls while the VTU is engaged in a conference: - The VTU automatically rejects incoming calls, is administratively configured to return a “busy signal”, or optionally does so through the use of a user selected “do-not-disturb” feature. OR - The VTU is configured to not automatically answer an incoming call and join it to an active conference (in progress) without user intervention. (i.e., the user must decide to answer the call or not based on the required source and caller information display. Answering the call affects the join). OR - A password, entered by the caller, is required to access the VTU’s integrated MCU. This password must be unique among all other passwords used by the system. This capability must not be functional at all times, i.e., it is only to be functional when the capability is required to be used. Note: In the event the VTU supports the “call-in/join via local meeting password” feature for the integrated MCU, the VTU should also have an administrative setting that disables this capability thereby forcing host action. In effect this setting would invoke an automatic “do-not-disturb” or return of a “busy” signal while the VTU is active. The various VTC vendors implement VTU integrated MCU access control differently. Examples are as follows: Tandberg – Dial out and dial in with host action only – no local meeting password option. Polycom – Dial-out and Dial-in w/ “meeting password” which is required to join a multipoint call or streamed meeting. This is a memory location used to set the local MCU or streamed media access or join password for access to the VTU and to set the endpoint password given to another MCU when calling into it. “This field can also be used to store a password required by another system that this system calls.” Note: this pre-configurable “meeting password” violates unique and scripted password policies. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU as an administrator configurable option and/or as a default condition. The desired capability is to block incoming calls during a VTC session by default without requiring the user to set the condition since the user may forget to do so. The user may have the capability to set the condition that temporarily turns off the “do-not-disturb” feature such that the call can be answered externally to the conference and then manually joined. Interview the IAO to determine if this requirement is covered in a SOP and user training/agreements. Interview a sampling of users to determine their awareness and implementation of the requirement. Place a call to an endpoint that is already in a conference and witness its response or reaction.

Fix: F-17516r1_fix

[IP][ISDN]; Perform the following tasks: Ensure the following regarding incoming calls while the VTU is engaged in a conference: - The VTU automatically rejects incoming calls, is administratively configured to return a “busy signal”, or optionally does so through the use of a user selected “do-not-disturb” feature. AND/OR - The VTU is configured to not automatically answer an incoming call and join it to an active conference (in progress) without user intervention. (i.e., the user must decide to answer the call or not based on the required source and caller information display. Answering the call affects the join.) AND/OR - A password, entered by the caller, is required to access the VTU’s integrated MCU. This password must be unique among all other passwords used by the system. This capability must not be functional at all times, i.e., it is only to be functional when the capability is required to be used.

b
Remote monitoring is not disabled while connected to an IP Network.
Medium - V-17599 - SV-18726r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1160.00
Vuln IDs
  • V-17599
Rule IDs
  • SV-18726r1_rule
Some VTC endpoints support the capability for an administrator or facilitator to view or monitor the VTU location (i.e., the room where it is located) remotely via a web interface. Some VTUs provide this feature via snapshots, while others provide the capability in real time. This feature can also include control capabilities and is used for troubleshooting, checking endpoints and rooms for operational readiness, or active monitoring of a call for quality control, etc. This capability poses a confidentiality issue for active conferences and the information in the proximity of the endpoints. Remote monitoring must be disabled as a general rule unless required to satisfy validated and approved mission requirements to prevent unauthorized access. This discussion also applies to administrator’s endpoints fully participating in a call for reasons of troubleshooting or quality control.NONEThe inadvertent disclosure of sensitive or classified information to a SA that is monitoring a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1, PEDI-1
Checks: C-18899r1_chk

[IP]; Interview the IAO to validate compliance with the following requirement: In the event the VTU is connected to an IP network ensure remote monitoring of the VTU via IP is disabled unless required to satisfy validated, approved, and documented mission requirements. Note: The documented and validated mission requirements along with their approval(s) are maintained by the IAO for inspection by auditors. Such approval is obtained from the DAA or IAM responsible for the VTU(s) or system. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU. i.e., remote monitoring must be able to be disabled or the feature/capability must not be supported. Interview the IAO to determine if remote monitoring is required and approved to meet mission requirements. Have the IAO or SA demonstrate compliance with the requirement.

Fix: F-17517r1_fix

[IP]; Perform the following tasks: - Obtain validation of mission requirements and DAA approval if remote monitoring of a VTU is to be used. OR - Configure the VTU to disable remote monitoring if the feature is not needed to satisfy validated, approved, and documented mission requirements.

b
Inadequate “operator/facilitator/administrator” access control for remote monitoring of a VTU connected to an IP network.
Medium - V-17600 - SV-18727r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1162.00
Vuln IDs
  • V-17600
Rule IDs
  • SV-18727r1_rule
Activation and use of remote monitoring and control features such as those discussed here and in RTS-VTC 1160.00 must be protected by access control. Minimally this must be the administrator password; however, access to this feature should not give full administrator access. NONEThe inadvertent disclosure of sensitive or classified information to a SA that is monitoring a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1, IAIA-1, IAIA-2
Checks: C-18900r1_chk

[IP]; Interview the IAO to validate compliance with the following requirement: In the event the VTU is connected to an IP network ensure access to IP remote monitoring and associated control functions of the VTU is minimally protected by a password. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU. i.e., remote monitoring must be able to have a password set in order to access remote monitoring features. Verify that an administrator password is required to access remotely accessible VTU. Have the IAO or SA demonstrate compliance with the requirement.

Fix: F-17518r1_fix

[IP]; Perform the following tasks: If IP remote monitoring is activated, configure the VTU to require a password before permitting access to the remote monitoring and associated control functions.

b
Inadequate notification to conference participants (manual or automatic) of monitoring activity by someone that is not a direct participant in a VTC session/conference.
Medium - V-17680 - SV-18854r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1164.00
Vuln IDs
  • V-17680
Rule IDs
  • SV-18854r1_rule
Monitoring of a conference or VTC system can be performed in various ways. This can be by accessing the monitoring capabilities of a particular VTU via IP as discussed above, or using a capability of a centralized MCU, or an administrator or “operator/facilitator” can participate in a conference using a VTU. No matter how monitoring is being performed, participants in a call must be notified or be made aware that the call is being monitored by someone that is not a direct participant of the call or conference who therefore may not have a need-to-know regarding the conference information. This is a particular concern if the monitored conference contains classified information. If the monitoring is done by remotely accessing a VTU, typically, an automated notification is displayed on the VTU being monitored. This indication should also be displayed on all connected endpoints. Minimally, there is a SOP that requires the presence of a person monitoring a conference be announced to the conferees. Note: This can minimally be accomplished via the enforcement of a SOP whereby the person performing the monitoring notifies the conference of their presence. Alternately, if an automated monitoring indicator is displayed on one VTU, the SOP must require that the participant or conferee seeing the indication announce the monitoring activity to the conference unless the indication appears on all participating endpoints. NONEThe inadvertent disclosure of sensitive or classified information to a SA that is monitoring a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1, PEDI-1
Checks: C-18950r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure conference participants are made aware that a conference is being monitored by someone that is not a direct participant of the call or conference. Interview the IAO to determine if this requirement is covered by an automatic indicator that appears on all participating endpoints OR is covered in a SOP and user training/agreements. Interview the IAO and monitoring “operator/facilitator” to determine their awareness and implementation of the requirement.

Fix: F-17577r1_fix

[IP][ISDN]; Perform the following tasks: - Configure the CODEC and/or MCU to automatically display an indication on all endpoints participating in a conference that the conference is being monitored. OR - Develop a SOP that addresses manual notification by SAs and chair persons that the conference is being monitored.

b
Insufficient security clearance held by an “operator/facilitator/administrator” performing remote monitoring activities during a VTC session/conference.
Medium - V-17681 - SV-18855r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1168.00
Vuln IDs
  • V-17681
Rule IDs
  • SV-18855r1_rule
Administrators or “operators/facilitators” that perform monitoring as discussed in this section must have an appropriate security clearance commensurate with or higher than the classification level of the system and/or the information to which they are exposed. NONEThe inadvertent disclosure of sensitive or classified information to a SA that is monitoring a VTU that may not have an appropriate need-to-know or proper security clearance.Information Assurance OfficerOther
Checks: C-18951r1_chk

[IP][ISDN]; Interview the Administrator to validate compliance with the following requirement: Ensure administrators that are required to monitor a conference or conferences possess a security clearance that is the same as or higher than the VTC system and the conference information to which they are exposed. Verify with IAO that conference call operator/facilitator has security clearance commensurate with or higher than the classification level of the system and/or the information to which they are exposed.

Fix: F-17578r1_fix

[IP][ISDN]; Perform the following tasks: Ensure administrators that are required to monitor a conference or conferences possess a security clearance that is the same as or higher than the VTC system and the conference information to which they are exposed.

b
Far end camera control is not disabled.
Medium - V-17682 - SV-18856r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1180.00
Vuln IDs
  • V-17682
Rule IDs
  • SV-18856r1_rule
Many VTC endpoints support Far End Camera Control (FECC). This feature uses H.281 protocol which must be supported by both VTUs. Typically, this is only available during an active VTC session but could be available if the VTU is compromised or if a call is automatically answered. Allowing another conference attendee to take control of your camera can place the confidentiality of non conference related information at risk. FECC should be disabled to prevent the control of the near end camera by the far end unless required to satisfy validated mission requirements.NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1
Checks: C-18952r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure far end camera control is disabled unless required to satisfy validated, approved, and documented mission requirements. Note: The documented and validated mission requirements along with their approval(s) are maintained by the IAO for inspection by auditors. Such approval is obtained from the DAA or IAM responsible for the VTU(s) or system. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU. i.e., far end camera control must be able to be disabled or the feature must not be supported. Determine if remote monitoring is required and approved to meet mission requirements. Have the IAO or SA demonstrate compliance with the requirement.

Fix: F-17579r1_fix

[IP][ISDN]; Perform the following tasks: Configure the CODEC to disable far end camera control OR Document and validate the mission requirements that require far end camera control to be enabled and obtain DAA approval. Maintain the requirement and approval documentation for review by auditors.

b
VTC data in transit must be encrypted.
Medium - V-17683 - SV-18857r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1220.00
Vuln IDs
  • V-17683
Rule IDs
  • SV-18857r2_rule
Early VTC CODECs did not support confidentiality of the media or signaling streams directly. As security and conference confidentiality have become an IA concern, VTU vendors have standardized on DES and AES encryption standards for VTC media streams. H.235 has been developed to help to secure the signaling protocols used in the H.323 suite of protocols. Most VTC media traffic is considered to be sensitive information requiring protection. Minimally all endpoints and MCUs must employ FIPS-validated or NSA-approved cryptography for data in transit, including both media and signaling. Much of the legacy VTC gear used today either supports DES or has no encryption. Newer CODECs support FIPS 140-2 encryption for media and signaling and typically have three encryption options on, off or automatic/negotiate. The preferred setting is ON and used when the other VTUs that a VTU needs to communicate with support encryption. Auto/negotiate is the preferred setting when this is not known.[ISDN] Reduce to CAT III for legacy ISDN/dialup MCUs or VTUs when these will not interoperate using native/internal encryption options. This is typical between equipment of different vendors legacy equipment. Mitigation using external encryption devices is acceptable. [Unclassified IP] Reduce to CAT III for VTC systems when every information owner designates their information is publicly releasable or their non-public information does not require encryption. Each conference information owner must provide written confirmation that encryption is not necessary. During APL testing: - This is a CAT I finding in the event the CODEC does not support multi-vendor interoperable encryption or it supports DES encryption only. (This applies only to new, non-legacy products submitted for testing.)Information Assurance OfficerECCT-1, ECNK-1, ECSC-1
Checks: C-18953r2_chk

If a VTU under review is connected to classified IP networks and the conference information owners provide is written confirmation that encryption is not required within the classified enclave, this requirement is not applicable. If the VTC systems, endpoints, and MCUs under review are on a physically separate network from the enclave’s LAN and use dedicated point-to-point circuits outside the enclave to interconnect to MCUs and other endpoints, this requirement is not applicable. If the VTC systems, endpoints, and MCUs under review are on a logically separate network on the enclave’s LAN using a dedicated and closed VTC VLAN, and protected on the WAN using an encrypted VPN between endpoints and the MCU, this requirement is not applicable. Review the VTC system architecture and ensure the VTC data in transit is encrypted. If the VTC data in transit is not encrypted, this is a finding. Ensure the strongest encryption algorithm is used for VTC media streams as supported by all communicating VTUs and associated MCUs.

Fix: F-17580r2_fix

Configure the VTC system architecture to require all data in transit be encrypted, with a preference for FIPS-validated or NSA-approved cryptography over legacy encryption.

b
The VTU must use FIPS 140-2 validated encryption module.
Medium - V-17684 - SV-18858r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1230.00
Vuln IDs
  • V-17684
Rule IDs
  • SV-18858r2_rule
The current DoD requirement for commercial grade encryption is that the encryption module, which includes a FIPS 197 validated encryption algorithm plus approved functions (i.e., key management and sharing/distribution functions), be NIST validated to FIPS 140-2. It must be noted that legacy equipment validated to FIPS 140-1 may still be used and FIPS 140-3 is in development. While many VTU vendors support AES, they have only validated the algorithm to FIPS-197, if at all. This does not meet the FIPS 140-2 requirement because the additional approved functions have not been addressed.For APL testing and new installations of new (non-legacy) equipment, this finding can be reduced to a CAT III in the event the crypto module in use is in the FIPS validation process as listed on the NIST CMVP modules in Process web site. http://csrc.nist.gov/groups/STM/cmvp/inprocess.html. The POAM for closing the finding must indicate the expected date that the module will achieve validation and the process to ensure the module in use is the validated module.Information Assurance OfficerECCT-1, ECNK-1, ECSC-1
Checks: C-18954r2_chk

Interview the ISSO to validate compliance with the following requirement: Ensure VTUs under his/her control employ encryption module(s) validated to FIPS 140-2. Determine if the various VTUs with which the system under review is expected to communicate support and are using FIPS 140-2 validated encryption modules and that they are operated in FIPS mode. Have the ISSO or SA demonstrate and verify that the VTU is using 140-2 encryption in FIPS mode. Review documentation from the vendor designating the encryption modules in use and verify that they are listed on the NIST CMVP validated modules web site (http://csrc.nist.gov/groups/STM/cmvp/validation.html). If the VTU does not use FIPS 140-2 validated encryption module, this is a finding.

Fix: F-17581r2_fix

Purchase and install only those VTUs and MCUs that employ encryption modules that are validated to FIPS 140-2 standards. Upgrade or replace non-compliant devices. Note: Updating firmware or software to provide desired functionality is preferred. A vendor may provide security updates and patches that offer additional functions. In many cases, the IA Vulnerability Management (IAVM) system mandates updating software to reduce risk to DoD networks.

b
VTU encryption indicator is not enabled.
Medium - V-17685 - SV-18859r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1250.00
Vuln IDs
  • V-17685
Rule IDs
  • SV-18859r1_rule
In support of the need for encryption and the need for the VTU user to be aware that in fact his/her conference session is being encrypted, the VTU must display an indicator that encryption is indeed occurring. This is not a finding in the event encryption is provided by external devices (not the CODEC), AND an external indicator is used to display encryption status in place of an on-screen indicator provided by the CODEC.The inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1
Checks: C-18955r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure all VTU’s under IAO’s control display a visual indicator that encryption is in fact taking place. Note: During APL testing, this is a finding in the event this requirement is not supported by the CODEC i.e., an on screen visual indicator displaying that encryption is indeed occurring. Note: In the event encryption is provided by external devices (not the CODEC), an external indicator meets this requirement in place of the on-screen indicator.

Fix: F-17582r1_fix

[IP][ISDN]; Perform the following tasks: Implement VTU CODECs that provide an on screen indicator that encryption is occurring and active. OR If the encryption is provided by external devices (not the CODEC), implement an external indicator to display encryption status in place of an on-screen indicator provided by the CODEC.

b
Deficient SOP or enforcement for user validation that encryption is on when required
Medium - V-17686 - SV-18860r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1260.00
Vuln IDs
  • V-17686
Rule IDs
  • SV-18860r1_rule
When encryption is enabled via automatic/negotiate, and one endpoint does not support encryption or supports DES and not AES, the entire conference defaults to the lower capability level. This is not acceptable for some conferences depending upon the sensitivity of the information discussed or presented. As noted above, the stated DoD IA controls require encryption. To ensure this requirement is met, when it is unknown whether all endpoints in a conference support encryption and whether it is turned on, the VTU user must provide the final check that encryption is being used. If a conference is to be encrypted, the user must check that all participants are using encryption and have enabled the encryption on their devices. When the conference has begun, the user must ensure that the conference is encrypted. The alternate to this is to exclude the endpoint that does not support the required encryption or not proceed with the conference session.NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerOther
Checks: C-18956r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure a policy and procedure is in place and enforced that addresses user activation and verification of encryption use when encryption is required based on the sensitivity of the information discussed or presented. The following must be included: - The user must check that all participants are using encryption and have enabled the encryption on their devices if manual activation necessary. - When the conference has begun, the user must ensure that the VTU is displaying the “conference is encrypted” indication. Note: This requirement must be reflected in user training, agreements and guides. Verify that there is a policy and procedure in place that enforces and guides users on how and what to check when participants are required to use encryption.

Fix: F-17583r1_fix

[IP][ISDN]; Perform the following tasks: Define and enforce policy and procedure that addresses user activation and verification of encryption use when encryption is required based on the sensitivity of the information discussed or presented. The following must be included: - The user must check that all participants are using encryption and have enabled the encryption on their devices if manual activation necessary. - When the conference has begun, the user must ensure that the VTU is displaying the “conference is encrypted” indication.

c
The VTC system and components must not have default or factory passwords.
High - V-17687 - SV-18861r2_rule
RMF Control
Severity
High
CCI
Version
RTS-VTC 2020.00
Vuln IDs
  • V-17687
Rule IDs
  • SV-18861r2_rule
Factory default, well-known, and manufacturer backdoor accounts and their associated passwords provide easy unauthorized access to systems and devices. Leaving such accounts and passwords active on a system or device makes it extremely vulnerable to attack and unauthorized access. As such, they must be removed, changed, renamed, or otherwise disabled. Also covered by this policy are “community strings”, which act as passwords for monitoring and management of network devices and attached systems via SNMP. The universal default SNMP community strings are “public” and private” and are well known. Default access for VTC operation, local and remote control, management, and configuration purposes is typically unrestricted or minimally protected by well-known default passwords. It has been demonstrated that not changing these passwords is the most common cause of VTC system compromise.System AdministratorInformation Assurance Officer
Checks: C-18957r2_chk

Review site documentation to confirm VTC system and component default and factory passwords have been changed. This includes SNMP community strings must be changed or replaced prior to the VTU being placed into service. If the VTC system and component default and factory passwords are not changed, this is a finding. Note: During APL testing, this is a finding in the event default passwords cannot be changed on VTC or VTU.

Fix: F-17584r2_fix

Implement changing all VTC system and component default and factory passwords.

b
The VTC system and components must not display passwords in clear text.
Medium - V-17688 - SV-18862r3_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2022.00
Vuln IDs
  • V-17688
Rule IDs
  • SV-18862r3_rule
As any information is entered on a keyboard, the keyboard sends each keystroke to the processing unit which, typically, echoes the character represented by the keystroke to the display device as feedback to the system’s user. Such echoing is done in what is called “clear text” in that you can read what was entered. This process is used for normal typing, but must be changed when entering passwords. When passwords are displayed (echoed) during logon, the risk of password compromise is increased and password confidentiality is greatly reduced. If the password is displayed during logon, it can easily be compromised through the use of a simple technique of shoulder surfing, i.e., a third party witnessing the logon could view the echoed password and remember it or write it down. This could also happen through surveillance methods. This presents a major vulnerability to the security or confidential nature of the password. To mitigate this, when entering a password, the characters that are echoed to the display must be something other than the clear text characters. Typically an asterisk or other punctuation character is used to replace the actual characters in an echoed password. System AdministratorInformation Assurance Officer
Checks: C-18958r6_chk

Review site documentation to confirm the VTC system and components does not display passwords in clear text when logging onto a VTU locally or remotely. If the VTC system or any components do display passwords in clear text, this is a finding. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU.

Fix: F-17585r2_fix

Implement the VTC system and components to not display passwords in clear text. If existing devices do not support this behavior, upgrade as soon as possible.

b
The Videoconferencing system and components passwords must meet complexity and strength policy.
Medium - V-17689 - SV-18863r4_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2024.00
Vuln IDs
  • V-17689
Rule IDs
  • SV-18863r4_rule
DoD policy mandates the use of strong passwords. The minimum password length is 15 characters. The minimum password complexity when not using DoD PKI is at least one lowercase letter, one uppercase letter, one number, and one special character must be present in the password. When a password is changed, at least half the characters in the password must change; for a 15-character password this mandates eight positions, and for a four-digit PIN at least two numbers would change. While videoconferencing endpoints typically do not require a username, they do require a password for user access and authentication. The strength of these passwords is an issue for video endpoints and is dependent upon the method of entry. Strong passwords, along with other measures noted in DoD policy, are required for any access method that is received by the video endpoint across a network. This is because of the potential that a password could be broken by a variety of high-speed cracking attacks. Due to the inability to use letters, PINs are very weak passwords. Typically, a local video endpoint PIN entered from a hand-held remote control can support five or more characters.Reduced to CAT III when a five-digit PIN is used for video endpoint local access from the hand-held remote control. Reduced to CAT III when an eight-character password is used for video endpoint remote access and contains a mix of upper case letters, lower case letters, numbers, and special characters. Reduced to CAT III when the site develops and enforces a policy or procedure to manage password length and complexity to mitigate deficiencies in video endpoint enforcement of password complexity and length.System AdministratorInformation Assurance OfficerOther
Checks: C-18959r3_chk

Review site documentation to confirm a policy and procedure requires the videoconferencing system and components to have passwords meeting complexity or strength policy, as follows: - PINs entered into a local video endpoint from a hand-held remote control must contain at least six digits. - PINs entered into a remote video endpoint from a hand-held remote control must contain at least nine digits. - Passwords entered from a keyboard must contain at least at least 15 characters with at least one lowercase letter, one uppercase letter, one number, and one special character. - Passwords and PINs must be encrypted per DoD standards. If the videoconferencing system and components do not have passwords meeting complexity or strength policy, this is a finding.

Fix: F-17586r3_fix

Implement videoconferencing system and components passwords to meet complexity and strength policy.

b
A VTU password must be used for each VTU function.
Medium - V-17690 - SV-18864r4_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2026.00
Vuln IDs
  • V-17690
Rule IDs
  • SV-18864r4_rule
Passwords are required for access control to various functions provided by a VTU. The following is a list of possible functions: 1. Local user device use/activation (not typically supported). 2. Local user call accounting code. 3. Local user access to user configurable settings. 4. Local user or machine access from the VTU to the user’s networked or otherwise attached PC running a presentation or desktop sharing application (or vice versa i.e., PC to VTU) (discussed later). 5. Local administrator access to configuration settings. 6. Remote administrator access to configuration settings. 7. Remote/centralized VTU management/control system access to the VTU (identifies the management server to the VTU, alternately restricted by IP address). 8. Remote caller access to a VTU integrated MCU conference without local user intervention. 9. Remote user access to media streamed from a VTU CODEC. 10. Local VTU access to a centralized MCU for joining conferences hosted remotely (i.e., the password sent to the remote MCU). 11. Local VTU access to gatekeeper services (automatically identifies the VTU to the gatekeeper). The passwords or PINs used for various differing functions must be logically grouped and be unique among other passwords implemented on the system. For example, local user password/PINs such as those in items 1, 2, and 3 could be the same. These would be entered manually using the hand-held remote control. Another logical grouping might be items 10 and 11. The other functions are logically separate because they perform different functions and are used by different entities. One vendor uses a single password pre-configured in the VTU for functions 8 (bi-directionally), 9, 10 and possibly 11. This is a problem for two reasons. The first was stated above, it is used for different functions, and secondly, it is preprogrammed into the VTU. While a VTU can have an identity or password that identifies itself to another machine for passing control information, such a password cannot be used to provide user level access to information. The user must enter this password manually. A VTC related application of machine to machine authentication would be the VTU identifying itself to a gateway or a centralized VTU management or control system to a VTU.Information Assurance OfficerOther
Checks: C-18960r4_chk

Review site documentation to confirm passwords are required for access to all functions and services of the VTU, to include: - Local user device use/activation and access to user configurable settings. - Local user or machine access to the user’s networked or otherwise attached PC running a presentation or desktop sharing application when permitted. - Local administrator access to configuration settings. - Remote administrator access to configuration settings and for remote software or firmware upgrade. - Remote caller access to a VTU integrated MCU conference if local user intervention is not required. - Remote user access to media streamed from a VTU CODEC. - Passwords used by VTU users, administrators, and devices are logically grouped by entity and roles (human or machine), type of access provided (information vs. control), and device accessed. - Passwords are unique across these logical groups. (i.e., a single password will not be used for multiple functions or to access multiple devices from a given VTU with the exception of a user’s local access to the VTU or its user accessible settings). - Passwords that provide user or administrator level access to another device or information will not be stored on the VTU for automated entry in lieu of the person entering the required password. If a VTU password is not used for each VTU function, this is a finding. If different VTU passwords are not used for groups of VTU functions, this is a finding.

Fix: F-17587r3_fix

Implement VTUs that support different password for different functions as follows: - Passwords are required for access to all functions and services of the VTU. This includes, but may not be limited to, the following: - Local user device use/activation and access to user configurable settings. - Local user or machine access to the user’s networked or otherwise attached PC running a presentation or desktop sharing application (if used or permitted; discussed later under PC Data and Presentation Sharing). - Local administrator access to configuration settings. - Remote administrator access to configuration settings and for remote software or firmware upgrade via IP or ISDN. - Remote caller access to a VTU integrated MCU conference if local user intervention is not required. - Remote user access to media streamed from a VTU CODEC. - Passwords used by VTU users, administrators, and devices are logically grouped by entity and roles (human or machine), type of access provided (information vs. control), and device accessed. - Passwords are unique across these logical groups (i.e., a single password will not be used for multiple functions or to access multiple devices from a given VTU with the exception of a user’s local access to the VTU or its user accessible settings). - Passwords that provide user or administrator level access to another device or information will not be stored on the VTU for automated entry in lieu of the person entering the required password. Note: Updating firmware or software to provide desired functionality is preferred. A vendor may provide security updates and patches that offer additional functions.

b
Classified videoconferencing systems must authenticate with a unique user logon prior to performing functions and services.
Medium - V-17691 - SV-18865r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2028.00
Vuln IDs
  • V-17691
Rule IDs
  • SV-18865r2_rule
DoD policy requires users to authenticate prior to being authorized to use available services. While requiring a user to authenticate to the video endpoint before it can be used to make or receive calls may detract from the video endpoint's “ease of use” and the “user experience” the capability should exist, be used where needed, and be configurable. Users should authenticate to activate the video endpoint for general use, make a call, or answer a call. Minimally, authentication should be a password unique to the user and recorded in session logs. Preferably, the video endpoint should support the use of DoD PKI for user authentication. To comply with DoD access control requirements for both users and administrators, a video endpoint should use a remote authentication server that can provide centralized management of passwords and accounts. This controls access to the videoconferencing system and limits the user’s privileges or authorizations. Many videoconferencing endpoints today do not provide sufficient identification, authorization, or auditing capabilities regarding their activation and use. While at least one vendor’s system can be configured to require the entry of a PIN to place a call, the feature is only a call accounting feature and not a security feature. While gatekeepers and gateways provide some access control, this control only relates to access to their services. They do not play a part in endpoint activation or use of the endpoint for point-to-point calls. The ITU developed H.235 as the security recommendation for H.323 and other H.245-based systems. H.323 provides for user identification rather than device identification, using simple passwords/PINs or DoD PKI. H.235 has the capability of negotiating encryption and key exchange. The use of H.350 can improve security by providing standardized management and storage of authentication credentials, as well as multilevel authorization. The use of H.245 and H.350 in combination could be the solution to the endpoint activation and user identification deficiency currently exhibited by videoconferencing endpoints. While it seems debatable whether a videoconferencing endpoint is, or should be, subject to DoD access control and auditing policies, particularly in unclassified environments, there are use cases where such compliance would be beneficial to the protection of DoD information. This is particularly in cases where a video endpoint is located in an area where classified materials, information, or discussions occur because an active video endpoint could generate a security incident. This issue could be more of a concern if the video endpoint was located in a classified work area while connected to an unclassified network or network having a lower classification than the work area. Compliance would also be beneficial for video endpoints in areas processing sensitive information. To protect the information, the video endpoint should remain dormant (even while powered on) and not capable of placing or answering a call unless it is activated by a user logging onto the system. System AdministratorInformation Assurance OfficerOther
Checks: C-18961r2_chk

Review site documentation to confirm the classified videoconferencing system authenticates using a unique user logon prior to performing functions and services. The video endpoint must not be capable of placing or answering a call unless it is unlocked by a user logon. Additionally, ensure the video endpoint configuration settings are as follows: - Unique (non-default/non-shared) IDs for each privileged and user account, to include an administrator test account. Note this is best accomplished using a central user management system, such as RADIUS or TACACS+. Authentication must meet current DoD requirements and may implement username/password or multifactor authentication (DoD PKI token preferred). - Video endpoints to require unique user identities to authenticate at first logon and when unlocking. - Video endpoints to automatically lock after 15 minutes of inactivity. - Video endpoints to display incoming call notifications while locked (a unique ID is required to activate the video endpoint and answer the call). If the classified videoconferencing system is not configured as above, this is a finding. If the classified videoconferencing system does not authenticate using a unique user logon prior to performing functions and services, this is a finding.

Fix: F-17588r2_fix

Configure the classified videoconferencing system to authenticate with a unique user logon prior to performing functions and services. Additionally, configure the video endpoint with the following: - Configure unique (non-default/non-shared) IDs for each privileged and user account, to include an administrator test account. Note this is best accomplished using a central user management system, such as RADIUS or TACACS+. Authentication must meet current DoD requirements and may implement username/password or multifactor authentication (DoD PKI token preferred). - Configure video endpoints to require unique user identities to authenticate at first logon and when unlocking. - Configure video endpoints to automatically lock after 15 minutes of inactivity. - Configure video endpoints to display incoming call notifications while locked (a unique ID is required to activate the video endpoint and answer the call).

b
Deficient SOP or enforcement of the SOP for manual password management.
Medium - V-17692 - SV-18866r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2040.00
Vuln IDs
  • V-17692
Rule IDs
  • SV-18866r1_rule
DoD password and account management policies and requirements that are not supported by the CODEC must be addressed and enforced by a site policy or SOP that provides compliance to the greatest extent possible within the capabilities of the system/device. Typically a CODEC supports only one administrative password and therefore a group administrator account/password must be used. Some CODECs can support multiple user passwords or PINs for accounting purposes. Additionally, there are other passwords used to access certain features of the system and for the system and user to access other systems and devices.NONEAccess to the VTU by unauthorized individuals possibly leading to the disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1, IAAC-1, IAGA-1, IAIA-1, IAIA-2
Checks: C-18962r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: In the event a system/device does not support all DoD IA requirements for password/PIN and account management or logon requirements, ensure a policy and procedure is in place and enforced that minimally addresses the following: - Strong passwords/PINs will be used to the extent supported by the system/device. Each access point and password will be addressed separately. - Password/PIN reuse will be limited and will be in compliance with policy and INFOCON requirements - Password/PIN change intervals will be defined for each access point based upon policy, INFOCON levels, and operational requirements. - Passwords/PINs will be changed when compromised or personnel (users or administrators) leave the organization. - Passwords/PINs that are no longer needed will be removed in a timely manner. A periodic review will be performed as scheduled by the SOP. - SNMP community strings will be managed like passwords/PINs. - A password/PIN change/removal log will be maintained and stored in a secure access controlled manner (such as in a safe or encrypted file on an access controlled server of workstation) for each device noting each access point, its password, and the date the password was changed. Such a log will aid in such things as SOP enforcement, password history compliance, and password recovery. Note: If and when VTC systems provide support for user and administrator accounts, this SOP is extended or modified to cover account management as necessary to manage non-automated functions. Inspect the SOP as well as user training materials, agreements, and guides to determine if the items in the requirement are adequately covered. Interview the IAO to determine how the SOP is enforced. Interview a sampling of users to determine their awareness and implementation of the requirement and whether the SOP is enforced. This is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details.

Fix: F-17589r1_fix

[IP][ISDN]; Perform the following tasks: Define and enforce policy and procedure that addresses password/PIN and account management that includes the following: - Strong passwords/PINs will be used to the extent supported by the system/device. Each access point and password will be addressed separately. - Password/PIN reuse will be limited and will be in compliance with policy and INFOCON requirements. - Password/PIN change intervals will be defined for each access point based upon policy, INFOCON levels, and operational requirements. - Passwords/PINs will be changed when compromised or personnel (users or administrators) leave the organization. - Passwords/PINs that are no longer needed will be removed in a timely manner. A periodic review will be performed as scheduled by the SOP. - SNMP community strings will be managed like passwords/PINs. - A password/PIN change/removal log will be maintained and stored in a secure access controlled manner (such as in a safe or encrypted file on an access controlled server of workstation) for each device noting each access point, its password, and the date the password was changed. Such a log will aid in such things as SOP enforcement, password history compliance, and password recovery. Provide user training regarding this SOP and include it in user agreements and user guides.

b
Deficient SOP or enforcement of One Time Use local meeting password
Medium - V-17693 - SV-18867r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2320.00
Vuln IDs
  • V-17693
Rule IDs
  • SV-18867r1_rule
A “local meeting password” must be used one time only. Once any meeting password is distributed to conferees, it is known by them. If a different and unique meeting password is not used for subsequent meetings, someone that has knowledge of (i.e., remembered or recorded) a previously used password could join a conference to which they were not invited to or in which they should not be included. This capability could violate requirements for access to information based on need-to-know and/or could lead to the disclosure of sensitive or classified information. While the setting of the “local meeting password” password could be an administrator function, most often it is set by the VTU user hosting the conference since the integrated MCU may be used in an ad hoc manner. Ideally, its use would be prescheduled. As noted above, the capability that uses this password should not be functional at all times. Of additional concern is; in the event a local meeting password is not set on the VTU, the VTU might provide no access control to the services that use it. This cannot be permitted if the VTU performs in this manner. As such this issue must be mitigated by configuration of a “blocking” password that is kept confidential. An additional consideration when using a “meeting password” is that such passwords should be used one time only. Once a meeting password is distributed to conferees, it is known by them. If a different and unique meeting password is not used for subsequent meetings, someone that has knowledge of a previously used password could join a conference that they were not invited to or should not be included. This capability could violate access to information based on need-to-know which could lead to the disclosure of sensitive or classified information. Note: This requirement applies to VTC CODECs that can host a multipoint meeting or conference using an integral MCU. This is typically capable of supporting four to six endpoints. A “local meeting password” typically controls access to the MCU. In some cases, this password is also used to access conference streaming. NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.Information Assurance OfficerInformation Assurance Manager
Checks: C-18963r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: If the use of a local meeting password is required because it is supported by the VTU, ensure a “local meeting password” policy and procedure is in place and enforced along with user training that addresses the following: - Implementation and distribution of a temporary password for the session when use of the feature is required. This password is used one time and not repeated. This password must not match any other user or administrative password on the device. - Disablement of the feature when its use is not required or the installation of a strong blocking password that is kept confidential. This password could be distributed as the temporary password when use of the feature is required if it is changed and kept confidential following the session. - User instructions on how to properly set and manage the password if site policy permits the user to set the password instead of calling an administrator. - User awareness training regarding the vulnerabilities associated with the reuse of meeting passwords. Note: In some instances, the local meeting password is also used for gaining access to media streamed from the VTU. While these are two different functions or entry points, and should not have the same password, the passwords for these functions are to be managed and used similarly. Streaming is discussed later in this document. Inspect the SOP as well as user training materials, agreements, and guides to determine if the items in the requirement are adequately covered. Interview the IAO to determine how the SOP is enforced. Interview a sampling of users to determine their awareness and implementation of the requirement and whether the SOP is enforced. This is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details. Note: This requirement applies to VTC CODECs that can host a multipoint meeting or conference using an integral MCU. This is typically capable of supporting four to six endpoints. A “local meeting password” typically controls access to the MCU. In some cases, this password is also used to access conference streaming. Note: This requirement applies to VTU CODECs that contain an integrated MCU Note: During APL testing, this is a finding in the event one time “meeting passwords” are not supported by the MCU.

Fix: F-17590r1_fix

[IP][ISDN]; Perform the following tasks: Define and enforce policy and procedure that addresses the management and use of a “local meeting password” for access to meetings hosted or streamed by a CODEC. The SOP will include the following: - Implementation and distribution of a temporary password for the session when use of the feature is required. This password is used one time and not repeated. This password must not match any other user or administrative password on the device. - Disablement of the feature when its use is not required or the installation of a strong blocking password that is kept confidential. This password could be distributed as the temporary password when use of the feature is required if it is changed and kept confidential following the session. - User instructions on how to properly set and manage the password if site policy permits the user to set the password instead of calling an administrator. - User awareness training regarding the vulnerabilities associated with the reuse of meeting passwords. Provide user training regarding the SOP and include it in user agreements and user guides.

b
Deficient user or administrator training regarding the vulnerabilities with, and operation of, CODEC streaming
Medium - V-17694 - SV-18868r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2365.00
Vuln IDs
  • V-17694
Rule IDs
  • SV-18868r1_rule
In conjunction with the SOP for VTU/CODEC streaming, users must be trained in the vulnerabilities of streaming, how to recognize if their CODEC is streaming, and how to deactivate streaming if it should not be active. Note: For additional information regarding the vulnerabilities associated with VTC streaming, see the discussion under RTS-VTC 2340 NONEThe inadvertent or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorOtherDCBP-1, IAAC-1, IAIA-1, IAIA-2, PRTN-1
Checks: C-18964r1_chk

[IP]; Interview the IAO to validate compliance with the following requirement: In the event the VTU/CODEC is connected to an IP based LAN, and if the CODEC supports streaming, ensure users/operators and administrators of a VTU receive training regarding streaming that addresses the following: - User awareness regarding the vulnerabilities streaming from a CODEC presents to conference confidentiality. - User awareness regarding accidental activation of streaming. - How to recognize the displayed indication provided by the VTU that it is in streaming mode. - How to terminate streaming, particularly if the CODEC should not be streaming. - The implementation and distribution of a temporary password for an approved CODEC streaming session using a one-time password that is not repeated and does not match any other user or administrative password. Note: This is a requirement whether steaming from a CODEC is approved or not. Interview VTC/CODEC administrators and user/operators to verify that they have received training on the vulnerabilities of streaming, recognition of CODEC streaming, and how to deactivate streaming when it is active. Have a sampling of these individuals demonstrate their knowledge. . This is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details.

Fix: F-17591r1_fix

[IP]; In the event the VTU/CODEC is connected to an IP based LAN, and if the CODEC supports streaming, Perform the following tasks: - Train CODEC user/operators and administrators regarding CODEC streaming addressing the following: > User awareness regarding the vulnerabilities streaming from a CODEC presents to conference confidentiality. > User awareness regarding accidental activation of streaming. > How to recognize the displayed indication provided by the VTU that it is in streaming mode. > How to terminate streaming, particularly if the CODEC should not be streaming. Additionally include this information in user’s agreements and guides.

b
CODEC streaming is not disabled when it is not required.
Medium - V-17695 - SV-18869r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2380.00
Vuln IDs
  • V-17695
Rule IDs
  • SV-18869r1_rule
When a CODEC is not required to be streaming, the capability will be disabled. The preferred method for this is via an administrator configurable setting. Both user activation and remote start must be addressed. In lieu of this, a streaming configuration must be implemented on the VTU that inhibits the ability to stream such that streaming will not be able to effectively be used to view a room or conference. Note: For additional information regarding the vulnerabilities associated with VTC streaming, see the discussion under RTS-VTC 2340 NONEThe inadvertent or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1
Checks: C-18965r1_chk

); [IP]; Interview the IAO to validate compliance with the following requirement: Ensure the following streaming configuration settings are implemented as prudent to further minimize the effect of accidental or unwanted streaming activation when streaming is not required to be activated: - Disable streaming and/or user activation of streaming - Disable remote start of streaming (if remote start is supported) OR if the above settings do not exist or do not work properly: - Clear the streaming destination or multicast address(s) - Set TTL/router hops to 0 or a maximum of 1 if 0 is not accepted. - Set the password used to access the CODEC for streaming to a strong password that meets or exceeds minimum DoD password requirements. This password is kept confidential. Note: If clearing the IP address or IP port does not prevent the CODEC from streaming to a default address or port, set a unicast addresses that will never be used by a device and set a very high IP port. Note: This requirement is applicable whether the CODEC is normally connected to an IP based LAN or not. If not normally connected to an IP based LAN, these settings will mitigate the vulnerability in the event the CODEC does become connected to a LAN via un-authorized or clandestine means Note: During APL testing, this is a finding in the event the product does not support the ability to disable conference streaming. Have the IAO or SA demonstrate the streaming configuration on a random sampling of CODECs.

Fix: F-17592r1_fix

[IP]; Perform the following tasks when CODEC streaming is not required to be use: Configure the CODEC as follows: - Disable streaming and/or user activation of streaming - Disable remote start of streaming (if remote start is supported) OR if the above settings do not exist or do not work properly: - Clear the streaming destination or multicast address(s) - Set TTL/router hops to 0 or a maximum of 1 if 0 is not accepted. - Set the password used to access the CODEC for streaming to a strong password that meets or exceeds minimum DoD password requirements. This password is kept confidential. Note: If clearing the IP address or IP port does not prevent the CODEC from streaming to a default address or port, set a unicast addresses that will never be used by a device and set a very high IP port. Note: This requirement is applicable whether the CODEC is normally connected to an IP based LAN or not. If not normally connected to an IP based LAN, these settings will mitigate the vulnerability in the event the CODEC does become connected to a LAN via un-authorized or clandestine means

b
VTU/CODEC is not properly configured to support streaming.
Medium - V-17696 - SV-18870r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2420.00
Vuln IDs
  • V-17696
Rule IDs
  • SV-18870r1_rule
In the event conference streaming directly from a VTU/CODEC is approved for a given conference, the administrator will need to properly configure the VTU to support the streamed conference. One of these measures is to set a one-time-use password for the streamed media. Another measure is to install configuration settings to limit the reach of the streamed media across the network to only those portions that are to receive it. This is done by setting the TTL as low as possible. A mitigation that can be used for the lack of access control for IP multicast is to use different multicast addresses and IP ports each time a streaming session is configured. First these should never be the default address(es) or ports used by the vendor’s system and they should be randomly selected. Note: Streaming is a feature of the VTU that could be turned on and configured for monitoring purposes by an adversary if the administrative access to the VTU is compromised. This is another reason why it is imperative to change all access codes and passwords on the VTU as required earlier. Additionally, users must be trained to recognize any displayed indication provided by the VTU that it is in streaming mode. Note: For additional information regarding the vulnerabilities associated with VTC streaming, see the discussion under RTS-VTC 2340 NONEThe inadvertent or improper disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance Officer
Checks: C-18966r1_chk

[IP]; Interview the IAO to validate compliance with the following requirement: If and when implementing streaming, ensure the following streaming configuration settings are implemented as prudent to minimize accessibility to the media stream: - Implement and distribute a temporary password for the session. For best protection of the system, this password is used one time and not repeated. This password must not match any other user or administrative password. - Enter an appropriate address and IP port for delivery of the media stream. If multicast is used, these are different from the default settings used by the vendor, and are randomly different each time they are used. - Set TTL/router hops to an appropriate number to limit the range of distribution of the media stream to within the local LAN or Intranet as required. This number should be limited to 1 for the local network, 15 or 16 for the campus, 25 for the adjoining site. Never enter a high number such as 64 and above since this will extend the reach to a region or the world as the number goes higher. Determine/review site policy/procedure for the implementation of approved VTC CODEC streaming. Review configuration settings to be used. If any CODECs are currently approved for and configured to stream, inspect or have the SA demonstrate the configuration used. This is a finding if the policy/procedure and/or configuration does not match or support the requirement items listed above.

Fix: F-17593r1_fix

[IP]; Perform the following tasks if streaming of a VTC CODEC session is approved and is to be implemented: - Implement and distribute a temporary password for the session. This password is used one time and never repeated. This password must not match any other user or administrative password. - Configure the CODEC by entering an appropriate address and IP port for delivery of the media stream. If multicast is used, these must be different from the default settings used by the vendor, and are randomly different each time they are used. - Configure the CODEC by setting TTL/router hops to an appropriate number to limit the range of distribution of the media stream to within the local LAN or Intranet as required. This number should be limited to 1 for the local network, 15 or 16 for the campus, 25 for the adjoining site. Never enter a high number such as 64 and above since this will extend the reach to a region or the world as the number goes higher.

b
inadequate user training for pc presentation sharing that could lead to compromise of other information on the presenting PC
Medium - V-17697 - SV-18871r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2460.00
Vuln IDs
  • V-17697
Rule IDs
  • SV-18871r1_rule
Users must be trained regarding the display of information that is not part of the conference. Such training must be based on the SOP discussed under RTS-VTC 2440.01 that is designed to mitigate the vulnerability. NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.Information Assurance OfficerInformation Assurance ManagerDCBP-1, ECSC-1, PRTN-1
Checks: C-18967r1_chk

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure VTU users receive training in the proper use and operation of PC to CODEC connections and understand the vulnerabilities associated with such interconnections regarding inadvertent or improper information disclosure. Interview a sampling of VTU administrators and users to verify that training has been provided for proper use and operation of PC to CODEC connections and that they understand the vulnerabilities associated with such interconnections regarding inadvertent or improper information disclosure. This is a finding if deficiencies are found. List these deficiencies in the finding details.

Fix: F-17594r1_fix

[IP][ISDN]; Perform the following tasks: Train users and administrators in the proper use and operation of PC to CODEC connections and provide an understanding of the vulnerabilities associated with such interconnections regarding inadvertent or improper information disclosure.

b
Deficient SOP or enforcement regarding the use of software based virtual connection between the PC and the VTC CODEC.
Medium - V-17698 - SV-18872r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2480.00
Vuln IDs
  • V-17698
Rule IDs
  • SV-18872r2_rule
VTC CODECs provide various means and methods to permit the display of presentations and various other forms of data to all of the endpoints in a conference. Typically, this involves connecting a PC workstation, on which the presentation is displayed and controlled, to a CODEC which distributes the presentation to the conferees. Care in operating this feature must be exercised so that the PC user does not inadvertently display information on their workstation that is not part of the conference and is not intended to be viewed by the conferees. Users must be aware that anything that they display on their PC workstation display while connected to the CODEC will be displayed on all of the conference monitors. This collaboration/display 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. This is a problem when sharing a PC desktop via any collaboration tool using any connection method. The first of the PC-CODEC interconnection methods, supported by most (but not all) CODECs, is the direct connection of the PC video output to an external video input on the CODEC. This method is most common interconnection method, is most secure, and is the recommended method for DoD. This is the only method available to users of VTUs connected to ISDN only (i.e., not connected to an IP network in addition to the ISDN lines).The second method for PC-CODEC interconnection for data/presentation sharing is to establish a virtual connection between the CODEC and PC workstation across an IP based LAN. While this method is implemented in different ways by different vendors, most if not all methods require the installation of an application or a utility on the PC workstation that is to share its data or display. While this method is convenient, since it does not require a cable connected to the CODEC, it presents varying degrees of vulnerability to the PC and the data it contains depending upon the particular application or utility installed. Additionally, the installation of such software is contrary to most DoD policy regarding approved workstation applications. All such software must be thoroughly evaluated and approved before installation. Most vendors provide a proprietary application or utility that is loaded on the PC workstation to establish the virtual connection between the PC and CODEC. The main purpose and capability of this utility is to capture the PC’s display graphics and send it to the CODEC. Typically, these utilities require only the IP address of the CODEC. The CODEC may or may not require a password to accept this input. When reading the documentation on these utilities there is no indication that the media stream generated by these utilities is encrypted. This may or may not be an issue depending upon the protocols used by the utility. Sniffing the stream may or may not reveal the displayed information. One vendor provides a utility to upload MS PowerPoint files to the CODEC and display them using an embedded viewer. This same vendor provides another utility to integrate with MS NetMeeting on the PC and stream content from there using T.120 protocol. An additional feature of some of these utilities is the capability of conferees to share and work on files across the connection between CODECs. This feature brings a larger set of collaboration tool features to the VTC arena. At least one vendor’s virtual connection method requires the installation of PC remote control desktop sharing software on the PC. Once the remote control/access server application is running, anybody with the matching or compatible viewer/control application and the access password can connect to the PC workstation from another PC workstation. This provides full control of its resources and access to all of its files since this is the purpose of this type of application. This type of application can receive remote keyboard and mouse inputs as if the user was sitting at the PC itself controlling it. As such this method is capable of much more than capturing the graphics displayed on the PC monitor and sending it to a CODEC. As such an adversary could gain full control of the PC workstation at any time when the server application is running, whether there is a conference being displayed or not. Many such server applications are started as a service when the workstation is booted. This means that the connection is available to an adversary any time the PC is running. This is a huge vulnerability for the PC workstation. As such, the use of virtual connection methods must first be approved by the DAA and must be tightly controlled. Another issue that must be addressed is the access control between the VTU and the PC. This discussion and/or requirements are dependent upon the direction of the access. (i.e., PC to VTU or VTU to PC) Access to a PC (from a VTU), by policy, requires a strong policy compliant password (and other measures, supported or not). Such a password cannot be entered from a VTU remote control unless an on screen keyboard (or cell phone text entry requiring password display) is used thus opening the password to shoulder surfing or being viewed by a conference room full of people (discussed earlier). If the VTU is to initiate the connection to the PC, it is best to store a strong password on the VTU that will identify the VTU to the PC sharing application. The sharing application is only run when needed when the PC is required to interface with the VTU; it is not run as a service that is constantly available. Other constraints could apply. The recommended alternative is to initiate all VTU - PC connections from the PC and implementing the appropriate access control in the VTU in compliance with password policy if a virtual connection is to be used. Better yet, use a direct connection using a video out connection on the PC. Furthermore, it is recommended that, if the remote control/access method is used, a PC workstation be dedicated to the purpose of displaying presentations on the CODEC. No other information should be placed on this PC. The PC should be turned off or disconnected from the LAN when a presentation is not being displayed to a conference. In this way, the installation of the remote control/access software will not place non conference information at risk. NONEThe inadvertent disclosure of sensitive or classified information to a caller of a VTU that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerInformation Assurance ManagerOtherDCBP-1, ECND-1, ECSC-1, ECSD-2, VIVM-1
Checks: C-18968r1_chk

[IP]; Interview the IAO to validate compliance with the following requirement: In the event a software based virtual connection between a PC/workstation and a CODEC is to be used for presentation display, file transfer, or collaboration, the IAO will ensure the following: - Additional appropriate policy and procedures for this type of connection are added to the required “Presentation/PC workstation display sharing” policy and procedure. These are based on the particular vendor’s solution to be implemented. - Additional appropriate user training is added to the training requirement noted above. - Perform and document an assessment of the application to be used to verify that it performs only those functions that are necessary, that the application behaves properly on the platform, and that it does not invalidate the security of the workstation. - Perform and document a risk assessment regarding the use of the application in light of the application assessment and the defined operational policy/procedures. - The responsible DAA approves, in writing, the installation of the additional software to the PC workstation(s) required to use this method. - The responsible DAA approves, in writing, the implementation and use procedures that mitigate the application’s vulnerabilities. Note: Assessments should be performed and DAA approvals should be obtained prior to purchase. Note: The IAO will maintain the policy, procedures, assessment documentation, risk assessment, and DAA approvals for inspection by IA auditors as evidence of compliance. Verify that additional and appropriate user training is added to the training requirement as noted in RTS-VTC 2460.00 that addresses additional vulnerabilities associated with presentation, application, and desktop sharing to a VTU from a PC. AND Verify additional vendor specific procedures and policies have been implemented. AND Verify that assessments have been performed and documented to validate additional VTU application(s) has not invalidated the security of the workstation. Verify with the IAO that a risk assessment has been performed and documented. AND Verify that DAA has approved in writing the installation of additional VTU software and the DAA is aware and approved the implementation and procedures used to mitigate the VTU application(s) vulnerabilities This is a finding if deficiencies are found. List these deficiencies in the finding details.

Fix: F-17595r1_fix

[IP]; Perform the following tasks: - Develop additional appropriate policy and procedures for this type of connection are added to the required “Presentation/PC workstation display sharing” policy and procedure. These are based on the particular vendor’s solution to be implemented. - Provide additional appropriate user training to the training requirement noted under RTS-VTC 2460. - Perform and document an assessment of the application to be used to verify that it performs only those functions that are necessary, that the application behaves properly on the platform, and that it does not invalidate the security of the workstation. - Perform and document a risk assessment regarding the use of the application in light of the application assessment and the defined operational policy/procedures. - Obtain approval from the responsible DAA in writing for the installation of the additional software to the PC/workstation(s) required to use this method. - Obtain approval from the responsible DAA in writing for the use and implementation procedures that mitigate the application’s vulnerabilities. - Maintain the policy, procedures, assessment documentation, risk assessment, and DAA approvals for inspection by IA auditors as evidence of compliance Note: Assessments should be performed and DAA approvals should be obtained prior to purchase.

b
A CODECs local Application Programmers Interface (API) must prevent unrestricted access to user or administrator configuration settings and CODEC controls without a password.
Medium - V-17699 - SV-18873r3_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2820.00
Vuln IDs
  • V-17699
Rule IDs
  • SV-18873r3_rule
Large conference room VTC systems may be built into the conference room in such a way that a hand-held remote control cannot directly access or control the CODEC because it is located in another room such as an AV control room. While there are systems and methods for extending the control signals from the hand-held remote control to the CODEC, many times the CODEC is connected to an AV control panel (typically called a “touch panel”) that sits on the conference table or possibly a podium. While this panel can be connected to the CODEC wirelessly (as discussed later) or via a wired IP connection, typically the connection is via an EIA-232 serial connection on the CODEC. To give the “touch panel” the ability to control the CODEC, the CODEC contains an API control program. All functions that are available on the hand-held remote control are typically duplicated on the “touch panel” Typically a VTC CODEC’s API provides full access to all configuration settings and control commands supported but the CODEC. This can be a big problem if the command channel is compromised because this would give the attacker the ability to reconfigure the CODEC or its features and capabilities and not just control them. To mitigate this problem, the CODEC’s API must provide a separation of the commands that control the system from the commands related to user and administrator configuration settings. If a password/PIN is implemented for user settings as required above, the touch panel must support the manual entry of the user configuration password/PIN assuming they will need to be accessed via the touch panel. Similarly, administrator settings should not be accessible from the touch panel or the interface on the CODEC that it uses without the use of an administrator password/PIN. System AdministratorInformation Assurance Officer
Checks: C-18969r2_chk

Review site documentation to confirm a CODEC’s API does not provide unrestricted access to user or administrator configuration settings and without the use of an appropriate password. Review the vendor documentation on the API. Look for information on restricting access to user or administrator configuration settings. Determine what user or administrator configuration settings are accessible or programmable via the API. Determine all API access methods and communications protocols, meaning local serial connection or “remotely” via a network. AND Establish a connection to the CODEC’s API using the information gained above and a PC; disconnect any AV control panel if necessary. Attempt to gain access and to change various user or administrator configuration settings via the API. If a CODEC's local API does not prevent unrestricted access to user or administrator configuration settings and CODEC controls without a password, this is a finding.

Fix: F-17596r2_fix

Implement only CODEC's with a local API preventing unrestricted access to user or administrator configuration settings and CODEC controls without a password.

b
CODEC control / configuration messages received via the local Application Programmers Interface (API) are not encrypted or authenticated.
Medium - V-17700 - SV-18874r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 2840.00
Vuln IDs
  • V-17700
Rule IDs
  • SV-18874r2_rule
The commands passed between the “touch panel” and CODEC are typically in a human readable clear text format. While older touch panels required a physical and direct connection to the EIA-232 serial connection on the CODEC, newer models are being developed to make use of Ethernet networks and associated IP protocols. Wireless models are also becoming available using wireless networking technologies. Sending clear text commands across these types of connections is an issue because it places the CODEC at risk of hijack i.e., being controlled by an entity other than the authorized touch panel in the conference room. Due to these issues, if the touch panel is implemented using a networking technology, the API commands must be encrypted in transit and the CODEC must authenticate the source of the commands. RTS-VTC 2840.00 This finding can be reduced to a CAT III (as opposed to not-a finding) for direct connections using the Ethernet connection on the CODEC. This is because, in this case, direct connection is only a partial mitigation since there is the potential that the VTU could still be connected to a LAN. This is not a finding for direct connections using the EIA-232 serial connection on the CODEC. Unencrypted and unauthorized access to the CODEC via API Ethernet or wireless connection by unauthorized individuals, could possibly lead to the disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.Use the direct connect method using the EIA-232 serial connection between the CODEC and the AV control panelSystem AdministratorInformation Assurance OfficerDCBP-1, ECSC-1
Checks: C-18970r1_chk

[IP][ISDN]; Validate compliance with the following requirement: Ensure control command communications between a CODEC and an audio visual control panel (touch panel), implemented using a wired or wireless networking technology, or is via a wired network (i.e., LAN), is encrypted and the CODEC authenticates the source of the commands. Note: This finding can be reduced to a CAT III (as opposed to not-a finding) for direct connections using the Ethernet connection on the CODEC. This is because, in this case, direct connection is only a partial mitigation since there is the potential that the VTU could still be connected to a LAN Note: This is not a finding for direct connections using the EIA-232 serial connection on the CODEC. Determine if the API connection between a CODEC and its AV control panel is via wired or wireless networking technology or a LAN. This is a finding if the control panel does not encrypt its commands and the CODEC does not authenticate the source of the commands. Have the SA demonstrate or Inspect the CODEC’s configuration settings regarding the encryption and authentication methods for the API communications with the AV control panel.

Fix: F-17597r1_fix

[IP][ISDN]; Perform the following tasks: Purchase and implement VTC CODECs and AV control panels that support the encryption and authentication of API messages from the AV control panel. AND Configure VTC CODEC to only accept authenticated and encrypted API messages from the AV control panel. AND Configure the AV control panel to encrypt its control messages and to include authentication information for each message such that the CODEC can authenticate the source of the message before acting upon it.

b
Secure protocols must be implemented for CODEC remote control and management.
Medium - V-17701 - SV-18875r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3120.00
Vuln IDs
  • V-17701
Rule IDs
  • SV-18875r2_rule
Many VTC Endpoints are remotely accessed across a network using nonsecure protocols such as telnet, FTP, and HTTP. This is a confidentiality issue since these protocols do not meet DoD requirements for password encryption while in transit. They also do not meet the encryption requirements for sensitive information in transit. Therefore, non-secure protocols should not be used. Some devices provide the option to select the secure versions of these protocols such as HTTPS and SSH for remote access. Secure protocols are required over non-secure protocols if available. Of additional concern is that remote control/management/configuration is performed in-band. In other words, it is performed using the same Ethernet port as the VTC traffic utilizes. If non-secure protocols must be utilized, the VTC production and CODEC remote access traffic must be segregated on the LAN from the normal data traffic. This is so that the confidentiality of the remote access password and sensitive management/configuration information is protected to the greatest extent possible by limiting access to it. Segregation requirements are discussed later under the LAN configuration section. Reduced to no finding when unencrypted management protocols are passed through an encrypted VPN between the managing workstation and the managed device.System AdministratorInformation Assurance Officer
Checks: C-18971r2_chk

Review site documentation to confirm a policy and procedure requires secure protocols is implemented for CODEC remote control and management. Ensure secure remote access protocols, such as HTTPS and SSH, are used for CODEC remote control, management, and configuration. If secure protocols are not implemented for CODEC remote control and management, this is a finding. Note: During APL testing if the device does not support encrypted management protocols or an encrypted VPN between the managing workstation and the managed device, this is a finding.

Fix: F-17598r2_fix

Secure protocols must be implemented for CODEC remote control and management Purchase and implement VTC CODECs and other VTC devices that support encryption of “Remote Control/Management/Configuration” protocols via the use of encrypted protocols or encrypted VPN tunnels between the managing PC/workstation and the managed device. AND Configure VTC CODECs and other VTC devices to use encrypted “Remote Control/Management/Configuration” protocols or an encrypted VPN tunnel between the managing PC/workstation/server and the managed device.

b
Unnecessary/unused remote control/management/configuration protocols are not disabled.
Medium - V-17702 - SV-18876r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3130.00
Vuln IDs
  • V-17702
Rule IDs
  • SV-18876r1_rule
Management or other protocols, secure or not, that are not required or used for management of, or access to, a device in a given implementation, but are active and available for a connection, places the device at risk of compromise and unauthorized access. These protocols must be disabled or turned off. NONEThe availability of unused or unneeded ports, protocols, and services used to configure and manage or otherwise access a VTC system/device could lead to the disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1
Checks: C-18972r1_chk

[IP]; Interview the IAO and validate compliance with the following requirement: Ensure remote access ports, protocols, and services used for VTC system/device “Remote Control/Management/Configuration” are disabled, turned off, or removed if not required in the specific implementation of the device. Determine what ports, protocols, and services are required for in the specific implementation of the device. Have the SA demonstrate the device configuration regarding these protocols or independently validate that only the required ports, protocols, and services are active. Validation can be performed by performing a scan of the network and management interface of the system/device. This is a finding if it is determined that there are ports, protocols, and services active that are not needed for the specific implementation of the device.

Fix: F-17599r1_fix

[IP]; Perform the following tasks: Configure the VTC system/device such that unused or unneeded ports, protocols, and services are disabled or removed from the system.

b
SNMP is not being used in accordance with the Network Infrastructure STIG.
Medium - V-17703 - SV-18877r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3140.00
Vuln IDs
  • V-17703
Rule IDs
  • SV-18877r1_rule
Some VTC endpoints can be monitored using SNMP. It is also possible that if not today, in the future, VTC endpoints could be configured via SNMP. SNMP is typically used by vendor’s VTU/MCU management applications but it is conceivable that SNMP traps could be sent to any SNMP compatible network management system. At the time of this writing, applicable STIG requirements for the use of SNMP are contained in the Network Infrastructure STIG. NONEImproperly configured SNMP monitoring and management protocols used to monitor or control/manage/configure a VTC system/device could lead to the disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1
Checks: C-18973r1_chk

[IP]; Interview the IAO and validate compliance with the following requirement: If SNMP is used to monitor or remotely control/manage/configure a VTC system/device, ensure the use of SNMP is performed in compliance with the applicable SNMP requirements found in the Network Infrastructure STIG. This is a finding if SNMP is not being used in accordance with the Network Infrastructure STIG. Note: During APL testing, this is a finding in the event SNMP configuration cannot come into compliance with the Network Infrastructure STIG.

Fix: F-17600r1_fix

[IP]; Perform the following tasks: If SNMP is used to monitor or remotely control/manage/configure a VTC system/device, implement and configure SNMP in compliance with the applicable SNMP requirements found in the Network Infrastructure STIG.

b
Remote management access and SNMP access and reporting are not restricted by IP address and/or subnet.
Medium - V-17704 - SV-18878r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3160.00
Vuln IDs
  • V-17704
Rule IDs
  • SV-18878r2_rule
In any network device management system, it is best practice to limit the IP address or addresses from which a network attached device can be accessed and to which device status information can be sent. NONENot limiting the source and/or destination of VTC system/device “Remote Control/Management/Configuration” traffic to/from authorized IP addresses could lead to the disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECSC-1
Checks: C-18974r1_chk

[IP]; Interview the IAO and validate compliance with the following requirement: If the VTU is connected to an IP based LAN, ensure remote management access (administrator and management system/server/application) and SNMP access and reporting is restricted by IP address and/or subnet. Determine what IP addresses or subnets are authorized to send VTC system/device “Remote Control/Management/Configuration” messages and what IP addresses or subnets are authorized to receive monitoring or status messages from the VTC system/device. Have the SA demonstrate how the VTC system/device is configured to restrict “Remote Control/Management/Configuration” messages to and from these authorized IP addresses or subnets. This is a finding if there is no limitation on either sending or receiving these messages. Note: During APL testing, this is a finding in the event the VTC system/devoice does not support the limiting of all management traffic to authorized IP addresses or subnets.

Fix: F-17601r1_fix

[IP]; Perform the following tasks: Configure the VTC system/device to restrict The source and/or destination of VTC system/device “Remote Control/Management/Configuration” and monitoring/status traffic to/from authorized IP addresses or subnets.

b
VTC systems and devices must run the latest DoD-approved patches/firmware/software from the system/device vendor.
Medium - V-17705 - SV-18879r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3320.00
Vuln IDs
  • V-17705
Rule IDs
  • SV-18879r2_rule
Some of today’s VTUs do not appropriately protect their passwords or access codes. Best practice and DoD policy dictates that authenticators are to be protected. This includes user account names, passwords, PINs, access codes, etc. The primary method used to protect these bits of information is encryption in transit for both the username and the password, and encryption of passwords in storage. It has been found that some VTC endpoint vendors do not provide this protection for passwords in storage, or at least, have not in the past. The first such vulnerability to be aware of is one where the administrator password can be obtained across the network by requesting certain files from the CODEC using a web browser. Once the file is accessed, the admin password is displayed in the clear within the source code for the page. The second such vulnerability to be aware of is one where, in one vendor’s product line, the user access codes are stored in a clear text file that is uploaded to the CODEC. This file is accessible from the FTP server on the CODEC. Access is, however, protected by the remote access password. One can only assume the vendor does not value these access codes as an IA measure since the discussion of their use relates to call accounting. Vulnerabilities like these and other issues are typically addressed by vendors like most issues are addressed, via patches to software, firmware upgrades, and major new releases of code. As such, it is good practice and a widely used DoD requirement that DoD systems should be running the latest version of software and install all patches to mitigate IA issues. Such is the purpose of the DoD IAVM program.System AdministratorInformation Assurance OfficerDCBP-1, ECND-1, ECND-2, VIVM-1
Checks: C-18975r2_chk

Interview the ISSO and validate compliance with the following requirement: Ensure all VTC systems and devices are running the latest DoD-approved patches, firmware, and software from the VTC system and device vendors to ensure the most current IA vulnerability mitigations or fixes are employed. Validate the latest software, firmware, and patches are installed on VTC systems and devices. Inspect the documentation regarding DoD testing and approval of the installed versions. If a CODEC or other VTC device is not using the latest software, firmware, and patches from the VTC system or device vendor, this is a finding. Note: Updating firmware or software to provide desired functionality is preferred. A vendor may provide security updates and patches that offer additional functions. In many cases, the IA Vulnerability Management (IAVM) system mandates updating software to reduce risk to DoD networks.

Fix: F-17602r2_fix

Perform the following tasks: Ensure updates to software firmware are patched, tested, and approved by a DoD entity prior to installation of such updates and patches per DoD policy. Install the latest DoD-approved patches, firmware, and software from the system/device vendor.

a
Video Teleconferencing system components must display the Standard Mandatory DoD Notice and Consent Banner exactly as specified prior to logon or initial access.
Low - V-17706 - SV-18880r3_rule
RMF Control
Severity
Low
CCI
Version
RTS-VTC 3420.00
Vuln IDs
  • V-17706
Rule IDs
  • SV-18880r3_rule
The operating system and remotely accessed information systems are required to display the DoD-approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. System use notification messages must be displayed when individuals log on to the information system. The approved DoD text must be used as specified in the DoD Instruction 8500.01 dated March 14, 2014.System AdministratorInformation Assurance Officer
Checks: C-18976r3_chk

Interview the IAO to validate compliance with the following requirement: Verify all video teleconferencing system components display the Standard Mandatory DoD Notice and Consent Banner prior to logon or initial access. If the displayed text is not exactly as specified in the DoD Instruction 8500.01 dated March 14, 2014, this is a finding. The text is posted on the IASE website: https://dl.cyber.mil/hidden/home/unclass-consent_banner.zip

Fix: F-17603r2_fix

Configure all video teleconferencing system components to display the Standard Mandatory DoD Notice and Consent Banner prior to logon or initial access.

b
All VTC system management systems/servers are not configured in compliance with all applicable STIGs
Medium - V-17707 - SV-18881r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3460.00
Vuln IDs
  • V-17707
Rule IDs
  • SV-18881r1_rule
Most VTC system vendors offer a range of centralized VTC system management applications and application suites. These include VTC endpoint and MCU managers, gatekeeper, gateway, and scheduling software. Gateways, gatekeepers, and scheduling systems are discussed later in this document. The advantage of implementing a management system for the management of VTC endpoints is that all endpoints can be managed from a central location and their configuration can be standardized. This is a good thing in that configuration changes made on any given endpoint for temporary purposes can be discovered and corrected easily. The disadvantage is that their use makes all managed VTC endpoints vulnerable and at risk of compromise if the management system is compromised. While compliance with all applicable STIGs is covered in the next subsection, additional guidance may be provided in a future release of this or a related document. Typically, VTC vendors provide their management applications and other infrastructure products on appliances with embedded operating systems (modified/scaled down, general purpose, or proprietary) and other application and database code (proprietary or otherwise). Some of these applications may be provided to run on a general purpose platform. In general, to mitigate risks, all VTC system management applications and application suites, including endpoint and MCU managers, gateways, gatekeepers, and scheduling systems must be operated on secure or hardened platforms and comply with all applicable DoD STIGs with specific emphasis on user accounts, roles/permissions, access control, and auditing. NONENot using DoD STIG guidance to secure VTC system/device management systems/servers could lead to denial of service or the disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerECSC-1
Checks: C-18977r1_chk

[IP]; Interview the IAO and validate compliance with the following requirement: Ensure all VTC system management suites/applications, gateways, and scheduling systems are configured in compliance with all applicable STIGs and are operated on STIG compliant platforms. Note: The following is a listing of, but possibly not all, applicable STIGs: - Operating system e.g., Windows, UNIX - Web Server, Application Services - Database - Application Development, Application Security Checklist Determine the STIGs that are applicable to the site’s VTC system management suites/applications, gateways, and scheduling systems. Inspect documentation regarding the IA review of these systems and applications against the applicable STIGs. This is a finding only if the site’s VTC system management suites/applications, gateways, and scheduling systems have not been reviewed against all applicable STIGs. This is not a finding if all applicable reviews have been performed regardless of the number of findings determined during those reviews. The IA posture of the reviewed system is based on the results of those reviews.

Fix: F-17604r1_fix

[IP]; Perform the following tasks: - Determine the STIGs that are applicable to the VTC system’s management suites/applications, gateways, and scheduling systems. - Configure these systems in accordance with the requirements in the applicable STIGs

b
Deficient SOP or enforcement regarding the approval and deployment of VTC capabilities.
Medium - V-17708 - SV-18882r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3620.00
Vuln IDs
  • V-17708
Rule IDs
  • SV-18882r2_rule
Due to the various IA issues surrounding VTC endpoint operation, they should only be installed or deployed where there is a validated requirement for their use. Conference room systems are easily justified and beneficial to an organization. General deployment to every desk in an organization is more difficult to justify. Deployments of office-based VTUs, desktop VTUs, and PC software based VTC applications must be considered on the basis of a validated need for the user to have this capability. Such needs should be revalidated annually In general, when VTC systems are implemented, consideration must be given to mission benefit weighed against the operational risks and the possibility of improper disclosure of information as discussed throughout this document. While this is important for ISDN only connected VTUs, this is most important for IP connected VTUs. The site must develop policies and enforce them regarding the deployment of VTC endpoints in support of IA control DCSD-1, which requires IA documentation be maintained, and IA control DCPR-1 which requires a change management process be instituted. NONEWithout a local policy giving guidance to proper use and deployment of office-based VTUs, desktop VTUs, and PC software based VTC applications could lead to the disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.System AdministratorInformation Assurance OfficerDCBP-1, ECND-1
Checks: C-18978r1_chk

[IP][ISDN]; Interview the IAO and validate compliance with the following requirement: Ensure local policies are developed and enforced regarding the approval and deployment of office-based VTUs, desktop VTUs, and PC software based VTC applications. Such policies will include and/or address the following: - Validation and justification of the need for VTC endpoint installation to include annual revalidation. - Approval of VTC endpoint deployment on a case by case basis. - Documentation regarding the validation, justification, and approvals. Inspect the documentation regarding the policy for justifying the installation of office-based VTUs, desktop VTUs, and PC software based VTC applications. Inspect the documentation regarding the justification and re-justification of the need for all VTC endpoint installations. This is a finding if there is no documented policy, or if installation justifications have not been documented.

Fix: F-17605r1_fix

[IP][ISDN]; Perform the following tasks: - Develop, document and enforce a policy regarding the justification for the installation of office-based VTUs, desktop VTUs, and PC software based VTC applications - Document the justification for the installation of all office-based VTUs, desktop VTUs, and PC software based VTC applications - Maintain this documentation for inspection by auditors.

b
A VTC management system or endpoint must have risk approval and acceptance in writing by the responsible Authorizing Official (AO).
Medium - V-17709 - SV-18883r3_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3640.00
Vuln IDs
  • V-17709
Rule IDs
  • SV-18883r3_rule
The risk of operating any DoD system or application must be assessed, defined, and formally accepted before use. The person responsible for the enclave’s network and system’s or application’s accreditation is the AO. The AO must approve changes to an existing system or the implementation of a new system having an affect the IA posture and accreditation of a system. The IA issues surrounding the use of VTC endpoints warrant AO approval. The AO must be made aware of the issues and vulnerabilities presented to the network, the area, and information processed as well as the mitigations for same. The AO approval for the addition of IP based VTC endpoints or VTC infrastructure devices (MCUs, gatekeepers, gateways etc.) to the base network or organization’s intranet. This is not intended to require separate approval for each individual endpoint in a multi-endpoint system. However, if the system is a single endpoint, it may require an individual approval.Information Assurance Officer
Checks: C-18979r2_chk

Review site documentation to confirm the VTC management system and endpoint have risk approval and acceptance in writing by the responsible AO. Inspect documentation to ensure that if VTC and VTU endpoints are in use, they have been approved by the responsible AO in writing. This documentation should reference the risk assessment performed with the AO’s acknowledgement of a full understanding of any risk, vulnerabilities, and mitigations surrounding the VTC implementation. If the VTC management system and endpoint do not have risk approval and acceptance in writing by the responsible AO, this is a finding.

Fix: F-17606r3_fix

Implement site documentation containing the VTC management system and endpoint risk approval and acceptance in writing by the responsible AO.

b
VTC system and endpoint users, administrators, and helpdesk representatives must receive cybersecurity training.
Medium - V-17710 - SV-18884r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3660.00
Vuln IDs
  • V-17710
Rule IDs
  • SV-18884r2_rule
All users and administrators of VTC systems and endpoints must receive training covering the vulnerabilities and other cybersecurity issues associated with operating a VTC system or endpoint. Users and administrators must be trained in the proper configuration, installation techniques, and approved connections for the VTC system or endpoint applicable to their exposure to the system. Also, users and administrators must be trained in the proper operating procedures for the system so that meeting information is properly protected and other non-meeting related information in the area near a VTC endpoint is not improperly disclosed or compromised. Helpdesk representatives supporting a VTC system or endpoints must also be appropriately trained in all aspects of VTC operation and cybersecurity. Without proper and periodic training to those directly responsible for VTC and VTU equipment and applications could lead to improper use and eventually lead to the disclosure of sensitive or classified information.System AdministratorInformation Assurance OfficerInformation Assurance ManagerOther
Checks: C-18980r2_chk

Review site documentation to confirm the VTC system and endpoint users, administrators, and helpdesk representatives receive cybersecurity training as follows: - Administrators, helpdesk representatives, and users are trained in all VTC system and endpoint vulnerabilities, cybersecurity issues, risks to both meeting and non-meeting related information, and assured service capabilities. - Users, administrators, and helpdesk representatives are trained in all aspects of VTC system and endpoint vulnerability, risk mitigation, and operating procedures. This training may be tailored to the specific VTC system or devices for a site. - Administrators and helpdesk representatives are trained in all aspects of VTC system and endpoint configuration and implementation to include approved connections. - The details contained in the SOPs intended to mitigate the vulnerabilities and risks associated with the configuration and operation of the specific VTC system or devices to include: > Protection of the information discussed or presented in the meeting such as the technical measures to prevent disclosure as well as the inadvertent disclosure of sensitive or classified information to individuals within view or earshot of the VTU. >The inadvertent disclosure of non-meeting related information to other conference attendees while sharing a presentation or other information from a PC workstation. >The inadvertent capture and dissemination of non-meeting related information from the area around the VTC endpoint to the other conference attendees. - Other training topics mentioned elsewhere in this document, are not listed here. If VTC system and endpoint users, administrators, and helpdesk representatives do not receive the above cybersecurity training, this is a finding. Note: Documentation is maintained regarding users, administrators, and helpdesk representative’s receipt of training. Training is refreshed annually and may be incorporated into other IA training received annually. The site may modify these items in accordance with local site policy however these items must be addressed in the training materials.

Fix: F-17607r2_fix

Implement site documentation to support the VTC system and endpoint users, administrators, and helpdesk representatives receive cybersecurity training as follows: - Administrators, helpdesk representatives, and users are trained in all VTC system and endpoint vulnerabilities, cybersecurity issues, risks to both meeting and non-meeting related information, and assured service capabilities. - Users, administrators, and helpdesk representatives are trained in all aspects of VTC system and endpoint vulnerability, risk mitigation, and operating procedures. This training may be tailored to the specific VTC system or devices for a site. - Administrators and helpdesk representatives are trained in all aspects of VTC system and endpoint configuration and implementation to include approved connections. - The details contained in the SOPs intended to mitigate the vulnerabilities and risks associated with the configuration and operation of the specific VTC system or devices to include: > Protection of the information discussed or presented in the meeting such as the technical measures to prevent disclosure as well as the inadvertent disclosure of sensitive or classified information to individuals within view or earshot of the VTU. >The inadvertent disclosure of non-meeting related information to other conference attendees while sharing a presentation or other information from a PC workstation. >The inadvertent capture and dissemination of non-meeting related information from the area around the VTC endpoint to the other conference attendees. - Other training topics mentioned elsewhere in this document, are not listed here. Maintain documentation on who received training and when.

b
VTC system and endpoint users must sign a user agreement when accepting an endpoint or obtaining approval to use an endpoint.
Medium - V-17711 - SV-18885r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3720.00
Vuln IDs
  • V-17711
Rule IDs
  • SV-18885r2_rule
Users must read and sign a user agreement before receiving their government furnished hardware, software, or gaining access to a system, application, or additional privilege on a VTC system or endpoint. The rules of use and operational procedures for VTC endpoints of all types must be affirmed by users. Each endpoint type will or may require different rules and procedures. Users must be informed of the vulnerabilities and risks of VTC endpoint use and trained in the procedures required to mitigate them as described in the training requirement. Furthermore, users must acknowledge their awareness of the IA issues and mitigating requirements and their agreement to abide by the rules of operation of the VTC endpoint or system. This user agreement must restate the elements of the required training and serve as an acknowledgement that the training was received. This user agreement can also include a statement of the penalties for non-compliance with the rules of operation.System AdministratorInformation Assurance OfficerOther
Checks: C-18981r2_chk

Review site documentation to confirm a policy and procedure requires the VTC system and endpoint users must sign a user agreement when accepting an endpoint or obtaining approval to use an endpoint. Inspect the user agreement to confirm it contains the following at minimum: - Acknowledgement of their awareness of the vulnerabilities and risks associated with the use of the specific VTC system or devices the user is receiving, will receive, or use. - Acknowledgement of their awareness of the methods contained in the SOP and training materials intended to mitigate the vulnerabilities and risks - Agreement to operate the system in a secure manner and employ the methods contained in the SOP and training materials intended to mitigate the vulnerabilities and risks - Acknowledgement of the penalties for non-compliance with the rules of operation if stated in the agreement. - Acknowledgement of their awareness of the capability (or lack thereof) of the system to provide assured service for C2 communications If a policy and procedure requiring the VTC system and endpoint users to sign a user agreement when accepting an endpoint or obtaining approval to use an endpoint does not exist, this is a finding. If the user agreement does not, at minimum, contain the above, this is a finding.

Fix: F-17608r3_fix

Implement a policy and procedure providing VTC system and endpoint users must sign a user agreement when accepting an endpoint or obtaining approval to use an endpoint. Maintain copies of the signed user agreements and provide a copy to the user for their reference.

b
User Guides and documentation packages must be developed and distributed to users operating VTC endpoints.
Medium - V-17712 - SV-18886r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 3740.00
Vuln IDs
  • V-17712
Rule IDs
  • SV-18886r2_rule
User documentation packages should include user agreements, training documentation, and endpoint user guides that reiterate the training information and the agreed upon User Agreement policies. The Endpoint User Guides should also provide additional information to include system or device operations, usage procedures for features, and IA measures as required to address the protection of both meeting related and non-meeting related information System AdministratorInformation Assurance OfficerOther
Checks: C-18982r2_chk

Review site documentation to confirm user guides and documentation packages are developed and distributed to users operating VTC endpoints, to include conference room systems, that provides the following information: - Reiterates the policies and restrictions agreed to when the user’s agreement was signed upon receiving the VTC endpoint of authorization to use one. - Provides cautions and notice of the non-assured nature of VTC communications so that C2 users are aware and reminded regarding the use of this communications media for C2. - Provides instruction regarding the proper and safe use of a VTC endpoint’s or conference room system’s audio and video capabilities such that the appropriate confidentiality of meeting related and non-meeting related information is maintained. - Provides instruction regarding the proper and safe use of document and desktop sharing when using a PC connected to a VTC endpoint such that the appropriate confidentiality of meeting related and non-meeting related information is maintained. - Provides instruction regarding the safeguarding of meeting related and non-meeting related sensitive and/or classified information If user guides and documentation packages are not developed and distributed to users operating VTC endpoints, this is a finding.

Fix: F-17609r3_fix

Implement a policy or procedure for User Guides and documentation packages to be developed and distributed to users operating VTC endpoints, to include conference room systems that provide the following information: - Reiterates the policies and restrictions agreed to when the user’s agreement was signed upon receiving the VTC endpoint of authorization to use one. - Provides cautions and notice of the non-assured nature of VTC communications so that C2 users are aware and reminded regarding the use of this communications media for C2. - Provides instruction regarding the proper and safe use of a VTC endpoint’s or conference room system’s audio and video capabilities such that the appropriate confidentiality of meeting related and non-meeting related information is maintained. - Provides instruction regarding the proper and safe use of document and desktop sharing when using a PC connected to a VTC endpoint such that the appropriate confidentiality of meeting related and non-meeting related information is maintained. - Provides instruction regarding the safeguarding of meeting related and non-meeting related sensitive and/or classified information.

b
VTC systems must be logically or physically segregated on the LAN from data systems, other non-integrated voice communication (VoIP) systems, and by VTC system type.
Medium - V-17713 - SV-18887r3_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 4120.00
Vuln IDs
  • V-17713
Rule IDs
  • SV-18887r3_rule
A common practice in traditional LAN design is the use and implementation of VLANs and IP subnets to segregate services and organizational workgroups, including their traffic as it traverses the LAN. This has the effect of providing confidentiality for the workgroup traffic by limiting the ability of users in other workgroups to see and access the traffic during normal operations. It also enhances the ability to control traffic flows for, and access to, LAN services. Another benefit of using VLANs is that they can improve network performance if they are properly pruned. Typically, when a VLAN is configured on one LAN switch, the other switches in the network will “learn” that VLAN, thus it will propagate throughout the network. This property is not what enhances network performance since it allows broadcast traffic in the VLAN to traverse the entire network. Also, if the number of allowable VLANs that a switch has configured or learns is exceeded, the LAN can become unstable. VLAN pruning eliminates this problem and is actually what can enhance network performance by limiting the traffic that devices in the LAN must process. The use of a separate IP address space and properly pruned separate VLANs for VTC systems will have the following effects: - Enhance the confidentiality of unencrypted VTC traffic. - Enhance the confidentiality of the VTC device management traffic, particularly if secure protocols are not available for use. - Limit the ability of LAN users to see the VTC devices in other VLANs, which limits the possibility of compromise from user or machine induced malicious activity. Some VTC systems should be protected using other VLAN structures as follows: - Primary conference room systems should have their own closely pruned VLAN and IP subnet. This could be a single conference room or several conference rooms if they are required to communicate with each other or are part of an overall managed VTC network within the enclave. This will provide the maximum protection from compromise for the conference room systems. - Hardware-based desktop and office VTUs should be grouped into their own VLAN and IP subnet. This could be the same VLAN and subnet as the one used for conference rooms if these devices are to communicate with them or if they are part of an overall managed VTC network within the enclave. - Hardware-based desktop and office VTUs that integrate and signal with the site’s VoIP telephone system may be grouped separately or utilize the Voice system VLAN structure and IP subnet. - PC-based soft-VTUs are to be implemented or segregated/controlled as described in the related document covering softphones and soft-VTUs. - Local MCUs and VTU management stations must reside in the VTC VLAN and IP subnet with the devices they manage or conference. - If WAN access is required, the VLANs can be extended to the enclave boundary.System AdministratorInformation Assurance Officer
Checks: C-49195r9_chk

Review site documentation to confirm VTC systems are logically or physically segregated on the LAN from data systems, voice (VoIP) systems, and by VTC system type as follows: - Verify that there is a dedicated LAN infrastructure and IP address space for the VTC endpoints. OR - Verify that there is a pruned and closed VLAN/IP subnet structure and dedicated IP address space on the LAN for the VTC system(s) that is (are) separate from the VLAN and IP address space/IP subnet structure(s) assigned to data systems and other non-integrated voice communications (VoIP) systems. - Verify that VTC systems are segregated on the LAN from themselves and other LAN services as follows: - Primary conference room systems - Hardware-based desktop and office VTUs Exception 1: If integrated with the VoIP phone system, these devices may connect to the VoIP system VLAN structure. Exception 2: If part of an overall managed VTC network within the enclave or hardware-based desktop and office VTUs must communicate with the conference room systems within the enclave, these devices may connect to the conference room VLAN structure. - Local MCUs and VTU configuration management/control servers must reside in the VTC VLAN and IP subnet with the devices they manage or conference. - If WAN access is required, the VLAN(s) or dedicated infrastructure can be extended to the enclave boundary. If any of these criteria apply and are not implemented, this is a finding.

Fix: F-48631r6_fix

Implement VTC systems to be logically or physically segregated on the LAN from data systems, voice (VoIP) systems, and by VTC system type. Design dedicated LAN infrastructure and IP address space for the VTC endpoints or implement a pruned and closed VLAN that is separate from the VLAN assigned to data systems and voice (VoIP) systems. Implement a separate IP address subnet for the VTC systems separate from the IP address subnet assigned to data systems and other non-integrated voice communications (VoIP) systems. Configure ACLs on each routing device in the LAN to limit traffic that needs to cross between the VTC VLANs and the data or management VLAN to authorized traffic based on the service or authorized IP address.

b
VTC endpoint connectivity is established via an unapproved DoD Wireless LAN infrastructure
Medium - V-17714 - SV-18888r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 4220.00
Vuln IDs
  • V-17714
Rule IDs
  • SV-18888r1_rule
In the event wireless LAN connectivity is to be used for VTC endpoints, it must be implemented via an established and approved wireless LAN infrastructure which is configured, along with its connected devices, in compliance with the Wireless STIG. Key requirements include WiFi and WPA2 certification of the VTC wireless LAN Network Interface Card (NIC) and FIPS 140-2 certification of the wireless encryption module.NONEUnregulated and improperly configured wireless adapters have the potential to provide backdoor connectivity, which ultimately can lead to the inadvertent disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.Information Assurance OfficerSystem Administrator
Checks: C-18984r1_chk

[IP]; Interview the IAO and validate compliance with the following requirement: Ensure VTC endpoint connectivity is established via an approved DoD wireless LAN infrastructure. Furthermore, ensure both the LAN and VTC endpoint are configured and operated in compliance with the Wireless STIG. Note: During APL testing, this is a finding in the event the VTU cannot come into compliance with the applicable requirements in the Wireless STIG. Inspect VTU configuration to verify with that if wireless is not required it is disabled. If wireless connectivity is required verify/inspect that the wireless functionality is configured and operating in accordance with the Wireless STIG.

Fix: F-17611r1_fix

[IP]; Perform the following tasks: If wireless LAN connectivity is required, configure the wireless LAN capabilities of a VTU using the applicable requirements in the Wireless STIG.

c
A VTC endpoint must not bridge a wired LAN and a wireless LAN.
High - V-17715 - SV-18889r2_rule
RMF Control
Severity
High
CCI
Version
RTS-VTC 4320.00
Vuln IDs
  • V-17715
Rule IDs
  • SV-18889r2_rule
With increased use of wireless networks by DoD, the risk of accidentally or intentionally bridging networks of different security levels and requirements is rising. Unwanted network bridging is the act of connecting different IP networks against security policies and/or the intended network design. The network perimeter is changing and so are the possible vectors security threats can use. Improperly configured wireless adapters have the potential to provide backdoor connectivity, which ultimately can lead to the inadvertent disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance. A VTC system connected simultaneously to a wired LAN and an active wireless LAN/connection may permit traffic or control information to pass traffic between the two networks, thereby providing a bridge between the wired and wireless LAN connections. The unwanted network bridge is especially dangerous for VTC systems because often networks of different security policies and levels are used by the same equipment.If the wired LAN and wireless LAN are in the same security domain and have the same classification, this finding may be downgraded to CAT II.System Administrator
Checks: C-18985r2_chk

Verify VTC endpoints do not simultaneously connect to a wired LAN and a wireless LAN. If the VTC endpoint equipment can pass traffic between the two LANs, this is a finding.

Fix: F-17612r2_fix

Configure the VTC system to prohibit simultaneous connection to a wireless LAN and a wired LAN connection. NOTE: Best practice is to design the VTC endpoint unit with equipment that does not support wireless LAN connectivity or to insert an approved isolation switch between the networks connected to the VTC endpoint. For VTC endpoints relying on wireless connectivity for the conference room control system, cameras, or microphones, additional design considerations may be necessary to prevent bridging networks.

b
A VTU endpoint does not have the wireless LAN capability disabled.
Medium - V-17716 - SV-18890r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 4360.00
Vuln IDs
  • V-17716
Rule IDs
  • SV-18890r1_rule
The proper mitigation for the vulnerabilities discussed above is to disable the wireless capability available or included in a VTC endpoint. Typically, one would expect a configuration setting that says something like “Disable Wireless” that would disable any onboard wireless capability whether integrated or reliant on a plug-in card. The Wireless STIG in WIR0167 requires all wireless LAN NICs to be turned-off by default after system boot-up or whenever a wireless network connection is not required. Additionally WIR0130 requires that the NIC have the capability to disable ad hoc connectivity. While these requirements are addressed toward PCs and PEDs, they are applicable to VTC endpoints. Support for these requirements does not seem to be available with at least some VTC endpoint’s PCMCIA wireless LAN card implementations. It is conceivable that a WLAN card could be inserted into the PCMCIA slot and activated with basic default settings and no security. To prevent this, the VTU’s PCMCIA slot must be physically blocked, making it difficult to insert a WLAN card. In the event a configuration setting is not available for a PCMCIA WLAN card that will disable it when one is plugged in, this finding can be reduced to a CAT III if the PCMCIA slot is fitted with a hard to remove device that prevents the insertion of a card into the slot. Unregulated and improperly configured wireless adapters have the potential to provide backdoor connectivity, which ultimately can lead to the inadvertent disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance.Information Assurance OfficerSystem Administrator
Checks: C-18986r1_chk

[IP]; Interview the IAO and validate compliance with the following requirement: Ensure wireless capability is configured as “disabled”. Note: In the event such a setting is not available for a PCMCIA WLAN card. This finding can be reduced to a CAT III if the PCMCIA slot is fitted with a hard to remove device that prevents the insertion of a card into the slot. If the VTU supports wireless LAN connectivity and it is not needed, verify that it is it is disabled. In the event the wireless capability is supported by inserting a WLAN card onto a PCMCIA slot, verify that the wireless capability remains disabled when the card is inserted. In the event such a setting is not available for a PCMCIA WLAN card verify that the PCMCIA slot is fitted with a hard to remove device that prevents the insertion of a card into the slot. Note: It is recognized that there is no mitigation for or configuration setting that would prevent the connection of an external wireless LAN adaptor via the wired LAN connection. This however would not permit both the wired and wireless LAN capabilities of the VTU to be active at the same time.

Fix: F-17613r1_fix

[IP]; Perform the following tasks: Configure the VTU to disable wireless LAN capabilities whether an internal wireless adaptor or a WLAN card plugged into a PCMCIA slot is used. OR Physically prevent the ability to insert a WLAN card into a PCMCIA slot.

b
A VTU or conference room implemented using wireless components must be protected from external control or compromise.
Medium - V-17717 - SV-18891r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 4420.00
Vuln IDs
  • V-17717
Rule IDs
  • SV-18891r2_rule
Conference room VTC systems, and particularly large ones, can require multiple microphones, cameras, and displays along with AV control systems. These systems typically require a significant amount of wiring. This can be a problem when retrofitting a well-appointed conference room without damaging the room’s walls, ceilings, furniture, and finishes. As a result, conference room VTC systems as well as other VTC endpoint systems can utilize various wireless communication technologies to interconnect its microphones, cameras, speakers, desktop audio conferencing units, and displays to the VTC CODEC and control panels to the AV control system and CODEC. The wireless communications technologies used are 802.11, Bluetooth, standard radio (cordless telephone and wireless microphone frequencies/technology) as well as infrared. The use of wireless technologies to implement a conference room in a DoD facility could pose an eavesdropping vulnerability to VTC conferences and other meetings held in the facility. This could place sensitive or classified DoD information at risk. To mitigate this, all audio, video, white boarding, and data sharing communications within the conference room system must be encrypted. Furthermore, those technologies covered by the Wireless STIG and other DoD wireless policies, must be in compliance with them.System AdministratorInformation Assurance OfficerECSC-1, ECWN-1
Checks: C-18987r2_chk

Interview the ISSO and validate compliance with the following requirement: If the audio, video, white boarding, data sharing capabilities or components of a VTC system are implemented using wireless RF technologies, ensure the following: - All information-bearing RF transmissions are encrypted to prevent eavesdropping. - All control-bearing RF transmissions are encrypted and/or authenticated to prevent control hijacking. - Wireless technologies covered by the wireless STIG and other DoD wireless policies are implemented and configured in compliance with that STIG and other policies. - Such implementations are approved by the responsible local AO in writing, and the ISSO will maintain approval documentation for inspection by IA auditors. Note: A much more expensive mitigation to this issue would be to enclose the room in RF shielding so that the information or control bearing VTC radio signals cannot escape the facility and external control signals cannot enter the facility. This might not be practical. Note: Wireless AV control systems or “touch panels were discussed and requirements provided earlier in this document. The earlier mentioned requirements are to be used in conjunction with this one. Note: During APL testing, this is a finding in the event this requirement is not supported by the VTU. Inspect the configuration of the VTC system and all wireless RF components and their associated documentation to ensure that the wireless traffic is protected. Also inspect approval documentation to ensure the responsible local AO has approved, in writing, the implementation of VTU based wireless RF components. If a VTU or conference room implemented using wireless components is not protected from external control or compromise, this is a finding.

Fix: F-17614r2_fix

Perform the following tasks: Purchase and install wireless RF VTC system components that can support the following: - The encryption of all information-bearing RF transmissions to prevent eavesdropping. - The encrypted and/or authenticated of all control-bearing RF transmissions to prevent control hijacking. - The configuration of wireless technologies covered by the wireless STIG and other DoD wireless policies is supported. AND Configure all wireless RF VTC system components to encrypt information-bearing RF transmissions to prevent eavesdropping and to encrypt and/or authenticate all control-bearing RF transmissions to prevent control hijacking. AND Obtain written approval from the responsible AO for the use of wireless RF components to assemble the VTC system. AND/OR Enclose the facility housing the VTC system in RF shielding so that the information or control bearing VTC radio signals cannot escape the facility and external control signals cannot enter the facility. OR Implement a hardwired VTC system.

b
VTC ports and protocols cross DoD/Enclave boundaries without prior registration in the DoD Ports and Protocols Database.
Medium - V-17718 - SV-18892r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 4520.00
Vuln IDs
  • V-17718
Rule IDs
  • SV-18892r1_rule
A portion of the DoDI 8550.1 PPS policy requires registration of those PPS that cross any of the boundaries defined by the policy that are “visible to DoD-managed components”. The following PPS registration requirement applies to VTC traffic that crosses the IP based Enclave boundary to the DISN WAN or another enclave. NONEUnrestricted and undocumented traffic crossing enclave boundaries can lead to the inadvertent disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance as well as denial-of-service and the inability for the operators of the GIG to properly defend it and its interconnected enclaves.Information Assurance OfficerSystem Administrator
Checks: C-18988r1_chk

[IP]; Interview the IAO and validate compliance with the following requirement: Ensure all protocols and services that cross the enclave boundary and/or any of the defined DoD boundaries (along with their associated IP ports) used by VTC systems for which he/she is responsible are registered in the DoD Ports and Protocols Database in accordance with DoDI 8550.1. Review network diagrams, device documentation, to identify what VTC/VTU/MCU Ports/Protocols/Services are used by the VTC system. Once these Ports/Protocols/Services have been determined and confirmed for use, verify that these same Ports/Protocols/Services are registered and approved for use in the DoD Ports and Protocols Database in accordance with DoDI 8550.1. Note: Reference tables are provided in the STIG

Fix: F-17615r1_fix

[IP]; Perform the following tasks: - Determine what Ports/Protocols/Services are used by the VTC system within the enclave and which cross the enclave boundary as well as what other boundaries they traverse. - Register all Ports/Protocols/Services are used by the VTC system in the PPS database.

b
Access control measures must be implemented for all conferences hosted on a centralized MCU appliance.
Medium - V-17719 - SV-18893r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 5020.00
Vuln IDs
  • V-17719
Rule IDs
  • SV-18893r2_rule
Access control must be exercised over participants joining multipoint conferences. Attendees and endpoints must be authorized or registered in advance. This way the conference organizers can control who has access to sensitive or classified information based upon validated clearance and need-to-know. Unrestricted access or the use of a meeting password that is reused or well-known can lead to a security incident where information is improperly disclosed to unauthorized individuals not having appropriate clearance or need-to-know. Additionally, if call-in access is supported and approved, a one-time use meeting password is required. H.323 gatekeepers provide access control for VTC network infrastructure devices such as MCUs and gateways to VTC endpoints. Using H.225 an endpoint can discover a gatekeeper and register with it. The endpoint is identified by the gatekeeper by a “gatekeeper password” which is essentially the endpoint ID. The gatekeeper provides address translation and bandwidth management. Once registered with the gatekeeper an endpoint must ask permission of the gatekeeper to make a call. If the available VTC bandwidth is used or limited, the gatekeeper can reject the request or negotiate a lower bandwidth. This acts as part of the access control mechanism for the MCU and works in combination with a scheduling application. The rest of the MCU access control equation is pre-registration of the endpoint IDs when scheduling a conference. Pre-registration of endpoint IDs for specific conferences is required because there are typically no meeting passwords and the phone numbers or IP addresses of the MCU ports don’t change between sessions. Additionally (and here’s the issue mentioned above) people are not authenticated only endpoints are. The endpoint ID is critical in this access control process. The endpoint ID is entered (pre-configured) in the system for a specific scheduled conference. The system only permits the endpoint to access the MCU during the scheduled time of the conference. This discussion also applies to ad hoc conferences and “standing” conferences. A standing conference is one where MCU facilities are dedicated to a conference that is operational all of the time or one that is regularly scheduled to be operational for certain time periods. The implementation of a standing conference permits conferees to join the conference at will or as needed to discuss a current topic or mission. Standing conferences are implemented for many reasons. Standing conferences are more vulnerable to compromise than one time scheduled events. Extra care must be exercised regarding access control to these conferences. System AdministratorInformation Assurance OfficerOther
Checks: C-18989r3_chk

Review site documentation to confirm control measures are implemented for all conferences hosted on a centralized MCU appliance as follows: - Only authorized endpoints are permitted to access an MCU - Only authorized users are permitted to access/join a conference. Authorization is pre-configured on the MCU access control system and is based on validated need-to-know as well as security clearance if applicable. If access control measures are not implemented for all conferences hosted on a centralized MCU appliance, this is a finding.

Fix: F-17616r2_fix

Implement access control measures for all conferences hosted on a centralized MCU appliance as follows: - Only authorized endpoints are permitted to access an MCU - Only authorized users are permitted to access/join a conference. Authorization is pre-configured on the MCU access control system and is based on validated need-to-know as well as security clearance if applicable. Note: this applies to standing, scheduled one-time, and non-scheduled ad hoc conferences.

b
Access control measures must be implemented for all conferences hosted on a centralized MCU appliance.
Medium - V-17720 - SV-18894r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 5120.00
Vuln IDs
  • V-17720
Rule IDs
  • SV-18894r2_rule
nregulated access to conference scheduling by any individual who is not authorized can lead to the inadvertent disclosure of sensitive or classified information to individuals that may not have an appropriate need-to-know or proper security clearance or may lead to a denial-of-service for MCU facilities. Scheduling systems accessed by users or administrators via a web interface must comply with all of the requirements for a web server or applications server to include DoD PKI access control and auditing requirements for such devices and systems. Scheduling systems accessed via a collaboration tool must minimally utilize the access control required for accessing the collaboration application. Since an authorized user of a collaboration tool may or may not have the right to schedule VTC conferences, the scheduling application should receive user credentials from the collaboration application to determine authorization or the right must be controlled by the collaboration application. Scheduling systems accessed by administrators using other methods must also employ access control and auditing meeting DoD requirements.System AdministratorInformation Assurance Officer
Checks: C-18990r2_chk

Review site documentation to confirm access control measures are implemented to control access to conference scheduling systems such that only authorized individuals can schedule conferences. Verify that only authorized individuals are permitted to schedule conferences. Inspect VTC scheduling system to verify that only users that are identified for accessing and setting up scheduled VTC conferences have access to said scheduling function. If access control measures are not implemented for all conferences hosted on a centralized MCU appliance, this is a finding.

Fix: F-17617r2_fix

Implement access control measures to control access to conference scheduling systems such that only authorized individuals can schedule conferences.

b
An IP-based VTC system implementing a single CODEC supporting conferences on multiple networks having different classification levels (i.e., unclassified, SECRET, TOP SECRET, TS-SCI) must support Periods Processing by being sanitized of all information while transitioning from one period/network to the next.
Medium - V-43015 - SV-55744r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7000
Vuln IDs
  • V-43015
Rule IDs
  • SV-55744r1_rule
All residual data (data that is unintentionally left behind on computer media) must be cleared before transitioning from one period/network to the next. Since the equipment is reused, non-destructive techniques are used. According to NIST Special Publication 800-88: Clearing information is a level of media sanitization that would protect the confidentiality of information against a robust keyboard attack. Simple deletion of items would not suffice for clearing. Clearing must not allow information to be retrieved by data, disk, or file recovery utilities. It must be resistant to keystroke recovery attempts executed from standard input devices and from data scavenging tools. For example, overwriting is an acceptable method for clearing media.Information Assurance OfficerDCCS-2, ECSC-1
Checks: C-49172r3_chk

Verify that an automatic capability exists and review documentation to determine whether this capability is being implemented before transitioning from one period/network to the next. If no automatic capability exists, review organizational documentation to determine whether a manual procedure is specified and implemented before transitioning from one period/network to the next. Coordinate with the vendor/solutions provider and certifier to ensure all residual information is sanitized based on equipment make and model. If an automatic capability exists and is being implemented, this is not a finding. If an automatic capability exists but is not being implemented, this is a finding unless a manual procedure is specified and is being implemented. If a manual procedure is specified and is being implemented, this is not a finding. If no procedure is specified or none being implemented, this is a finding.

Fix: F-48599r2_fix

Obtain equipment that has an automatic capability to sanitize memory or implement and document a manual procedure. Implement the automatic capability or manual procedure to sanitize all information while transitioning from one period/network to the next.

c
An IP-based VTC system implementing a single CODEC supporting conferences on multiple networks having different classification levels (i.e., unclassified, SECRET, TOP SECRET, TS-SCI) must support Periods Processing by connecting the CODEC to one network at a time, matching the classification level of the session to the classification level of the network.
High - V-43016 - SV-55745r1_rule
RMF Control
Severity
High
CCI
Version
RTS-VTC 7020
Vuln IDs
  • V-43016
Rule IDs
  • SV-55745r1_rule
Connecting to networks of different classifications simultaneously incurs the risk of data from a higher classification being released to a network of a lower classification, referred to as a “spill”. It is imperative that networks of differing classification levels or with differing handling caveats not be interconnected at any time. Separation in a multinetwork VTC system is maintained by the use of an A/B, A/B/C, or A/B/C/D switch that meets requirements for channel isolation, or by manual connection of the CODEC to one network at a time.Information Assurance OfficerEBCR-1, ECIC-1
Checks: C-49173r4_chk

Review the VTC system architecture to verify that an approved A/B, A/B/C, or A/B/C/D switch is present and properly cabled. Alternately, validate that the VTC CODEC is manually connected to one network at a time through the use of a single patch cord. If neither is in place, this is a finding.

Fix: F-48600r3_fix

Obtain and install an approved A/B, A/B/C, or A/B/C/D switch. Alternately, manually connect the VTC CODEC to one network at a time through the use of a single patch cord.

c
IP-based VTC systems must not connect to ISDN lines when connected to a classified network.
High - V-43017 - SV-55746r2_rule
RMF Control
Severity
High
CCI
Version
RTS-VTC 7040
Vuln IDs
  • V-43017
Rule IDs
  • SV-55746r2_rule
Most CODECs have a built-in IMUX such that multiple ISDN lines can terminate directly on the CODEC. ISDN lines used for VTC transport are provided by a traditional telephone switch on an unclassified network. Connecting a classified IP network to an unclassified telephone network through a VTC CODEC while in a conference could lead to disclosure of classified information to the unclassified network and unclassified VTC endpoints. While this issue might be mitigated by using a Type 1 encryptor between the CODEC and an external IMUX, an SOP would need to be in place which would dictate that the ISDN connection must be established and the Type 1 encryptor synced with the other end BEFORE the CODEC was connected to the classified IP network. This type of operation is risky and prone to error and is therefore not recommended.Information Assurance OfficerEBCR-1
Checks: C-49174r4_chk

Review the VTC system architecture and inspect the VTC CODEC to verify that ISDN lines are not connected directly to the CODEC if it connects to a classified IP network (e.g., SIPRNet, JWICS) at any time. If they are, this is a finding. Note: If the VTC system is used to support multiple networks having different classification levels, and the ISDN lines are isolated from classified IP, they must meet periods processing requirements.

Fix: F-48601r4_fix

Do not simultaneously connect ISDN lines to a VTC CODEC if the CODEC connects to a classified IP network.

b
An IP-based VTC system implementing a single CODEC supporting conferences on multiple networks having different classification levels (i.e., unclassified, SECRET, TOP SECRET, TS-SCI) must support Periods Processing sanitization by purging/clearing volatile memory within the CODEC by powering the CODEC off for a minimum of 60 seconds.
Medium - V-43018 - SV-55747r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7060
Vuln IDs
  • V-43018
Rule IDs
  • SV-55747r1_rule
Volatile memory requires power to maintain the stored information. It retains its contents while powered, but when power is interrupted, stored data is immediately lost. Dynamic random-access memory (DRAM) is a type of random-access memory that stores each bit of data in a separate capacitor within an integrated circuit. Since capacitors leak charge, data fades unless the capacitor charge is refreshed periodically. Static random-access memory (SRAM) has a different configuration from DRAM which allows it to retain data longer when power is no longer applied (data remanence). Powering off the CODEC for 60 seconds is sufficient to discharge the capacitors and erase all data.DCCS-2, ECSC-1
Checks: C-49175r3_chk

Observe the operation of the VTC system as it transitions between networks. Verify that the CODEC is powered off for a minimum of 60 seconds during the transition. If it is not, this is a finding.

Fix: F-48602r5_fix

Sanitize volatile memory by disconnection of all power for at least 60 seconds.

b
IP-based VTC systems implementing a single CODEC supporting conferences on multiple networks having different classification levels must sanitize non-volatile memory while transitioning between networks by overwriting all configurable parameters with null settings before reconfiguring the CODEC for connection to the next network.
Medium - V-43019 - SV-55748r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7080
Vuln IDs
  • V-43019
Rule IDs
  • SV-55748r1_rule
A factory reset is the software restore of an electronic device to its original system state by erasing all of the information stored on the device to restore the device to its original factory or unconfigured settings. This erases all of the data, settings, and applications that were previously on the device. Factory reset may be used as part of the sanitization process. This requirement is satisfied by the use of either a properly configured automated configuration management system or by the use of an inherent sanitization capability of the unit. However, this requirement results in a CAT III finding if a manual procedure is used. This can be downgraded from a CAT II to a CAT III if a manual procedure is used to perform a factory reset and/or overwrite all configurable parameters with null settings before reconfiguring the CODEC for connection to the next network.Information Assurance OfficerDCSS-2, ECSC-1
Checks: C-49176r5_chk

Verify that the VTC system has an automated configuration management system configured to sanitize and reconfigure the CODEC when transitioning between networks. If it does, review documentation to determine that this capability is being implemented. If these conditions are met, this is not a finding. If the unit is not implementing an automated process, review documentation to determine whether a manual procedure is specified and implemented when transitioning between networks; this will result in a CAT III finding if these conditions are met and a CAT II finding if they are not. If an automatic capability exists but is not being implemented or an automated configuration management system is not being used, this is a CAT II finding unless a manual procedure is specified and is being implemented, then this is a CAT III finding. If the unit is not being sanitized when transitioning between networks, this is a CAT II finding.

Fix: F-48603r4_fix

Obtain a VTC system that has an automated sanitization capability. Implement and document a procedure that utilizes this capability to sanitize the CODEC when transitioning between networks. As a last resort, implement and document a manual sanitization / reconfiguration procedure to perform this function.

b
The A/B, A/B/C, or A/B/C/D switch within an IP-based VTC system supporting conferences on multiple networks having different classification levels must be based on optical technologies to maintain electrical isolation between the various networks to which it connects.
Medium - V-43020 - SV-55749r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7100
Vuln IDs
  • V-43020
Rule IDs
  • SV-55749r1_rule
The A/B, A/B/C, or A/B/C/D switch is physically connected to multiple networks having different classification levels. Copper-based switches provide minimal or no electrical isolation due to capacitance between the wires in the switch box and the switch contacts. This can permit information on one network to bleed or leak over to the other network, which can lead to the disclosure of classified information on a classified network to a network of lower classification. This must be prevented. Optical fiber is an insulator, thus it carries no electrical current and generates no electromagnetic field, eliminating the capacitance issue. As such, it provides excellent electrical isolation between the networks to which it connects. Information Assurance OfficerEBCR-1
Checks: C-49177r5_chk

Review A/B, A/B/C, or A/B/C/D switch vendor documentation to determine if optical technologies are used to maintain electrical isolation between the input port/connection and between all selectable output ports/connections. If this is not the case, this is a finding. Validate approved equipment is being used. DISN Video Services (DVS) maintains a list of A/B, A/B/C, or A/B/C/D switches that have been certified to meet the above requirements at http://disa.mil/Services/Network-Services/Video/~/media/Files/DISA/Services/DVS/red_black_peripherals.xls. If the A/B, A/B/C, or A/B/C/D switch is not on the list, this is a finding.

Fix: F-48604r4_fix

Obtain and install an approved A/B, A/B/C, or A/B/C/D switch.

b
An IP-based VTC system implementing a single CODEC supporting conferences on multiple networks having different classification levels must be implemented in a manner such that configuration information for a network having a higher classification level is not disclosed to a network having a lower classification level.
Medium - V-43021 - SV-55750r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7120
Vuln IDs
  • V-43021
Rule IDs
  • SV-55750r1_rule
Connecting the CODEC to a network while it is being reconfigured could lead to the disclosure of sensitive configuration information for a network having a higher classification level to a network having a lower classification level. Ideally, the CODEC will be disconnected from any network while it is being reconfigured. However, the requirement can be met by using a procedure that purges the configuration for the currently connected network, power cycling the CODEC as required (for a minimum of 60 seconds per another requirement) as the CODEC is switched to the next network, then reconfigures the CODEC for the next session. Information Assurance OfficerEBCR-1
Checks: C-49178r4_chk

Review the VTC system architecture documentation and observe system operation while transitioning between networks to verify one of the following: • The CODEC is switched to a disconnected/unused switch position while it is being purged/reconfigured . • The CODEC is purged while connected to one network, then power cycled as it is switched to the next network, then reconfigured for that network. • Alternately, if a manual switching procedure is used, ensure the CODEC is physically disconnected from any network while being reconfigured. If none of these procedures is being followed, this is a finding.

Fix: F-48605r8_fix

Architect, implement, and configure the system such that the A/B, A/B/C, or A/B/C/D switch connects the CODEC to an unused switch position while it is being reconfigured during transition from one network to another. OR Architect, implement, and configure the system such that the CODEC configuration is purged before it is switched to the next network, then the CODEC is power cycled for the required time period as the A/B, A/B/C, or A/B/C/D switch connects the CODEC to the next network, then the CODEC is reconfigured for that network. OR If a manual switching procedure is used, physically disconnect the CODEC from any network while it is reconfigured for the next network.

b
The A/B, A/B/C, or A/B/C/D switch used for network switching in IP-based VTC systems implementing a single CODEC supporting conferences on multiple networks having different classification levels must be Common Criteria certified.
Medium - V-43022 - SV-55751r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7140
Vuln IDs
  • V-43022
Rule IDs
  • SV-55751r1_rule
Common Criteria provides assurance that the process of specification, implementation, and evaluation of a computer security product has been conducted in a rigorous, standard, and repeatable manner at a level that is commensurate with the target environment for use. The DSAWG mandated that the A/B, A/B/C, or A/B/C/D switches used in VTC systems implementing a single CODEC supporting conferences on multiple networks having different classification levels, where these networks are simultaneously and permanently connected to these networks, must receive NIAP approval in accordance with CNSSP #11. This was primarily due to the potential interconnection of separate networks designated as National Security Systems through the switch. This was a prerequisite to their approval of the multinetwork VTC system architecture. Therefore, the A/B, A/B/C, or A/B/C/D switch must be satisfactorily evaluated and validated in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme.Information Assurance OfficerDCAS-1
Checks: C-49179r4_chk

Review the NIAP Product Compliant List (PCL) at https://www.niap-ccevs.org to verify that a certification exists for the A/B, A/B/C, or A/B/C/D switch or review a vendor-provided letter from NIAP or the NIAP test report indicating satisfactory completion of testing and PCL listing. Validation of certification via the NIAP PCL can be more easily facilitated if the vendor has provided the certification number. If the product is not on the list or a NIAP letter or test report is not provided, this is a finding.

Fix: F-48606r1_fix

Obtain and install an A/B, A/B/C, or A/B/C/D switch that has obtained Common Criteria certification.

a
The A/B, A/B/C, or A/B/C/D switch used for network switching in IP-based VTC systems implementing a single CODEC supporting conferences on multiple networks having different classification levels must be TEMPEST certified.
Low - V-43023 - SV-55752r2_rule
RMF Control
Severity
Low
CCI
Version
RTS-VTC 7160
Vuln IDs
  • V-43023
Rule IDs
  • SV-55752r2_rule
Committee on National Security Systems Advisory Memorandum (CNSSAM) TEMPEST/01-13, RED/BLACK Installation Guidance, provides criteria for the installation of electronic equipment, cabling, and facility support for the processing of secure information. National policy requires that systems and facilities processing NSI must be reviewed by a Certified TEMPEST Technical Authority (CTTA) to achieve TEMPEST security. The RED/BLACK guidance contained in TEMPEST/01-13will be considered by the CTTA along with other measures (e.g., TEMPEST Zoning, TEMPEST-suppressed equipment and shielding) to determine the most cost-effective countermeasures to achieve TEMPEST security. Only those RED/BLACK criteria specifically identified by the CTTA will be implemented.Information Assurance OfficerECTC-1
Checks: C-49180r8_chk

Review the documentation to verify whether the A/B, A/B/C, or A/B/C/D switch is TEMPEST certified. Review TEMPEST certification documentation provided by a CTTA or the vendor to validate if the switch is TEMPEST certified. If the A/B, A/B/C, or A/B/C/D switch is not on the list, or satisfactory documentation is not provided, this is a finding.

Fix: F-48607r2_fix

Obtain and install a TEMPEST-certified A/B, A/B/C, or A/B/C/D switch.

b
An IP-based VTC system implementing a single set of input/output devices (cameras, microphones, speakers, control system), an A/V switcher, and multiple CODECs connected to multiple IP networks having different classification levels must provide automatic mutually exclusive power control for the CODECs or their network connections such that only one CODEC is powered on or one CODEC is connected to any network at any given time.
Medium - V-43024 - SV-55753r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7180
Vuln IDs
  • V-43024
Rule IDs
  • SV-55753r1_rule
If a VTC system is implemented using multiple CODECs, each connected to a network having a different classification level, along with an A/V switcher, a potential path exists through the CODECs and A/V switcher that could permit classified information to be exposed/released from one classified network to a network having a lower classification. Minimally powering off the CODEC will provide a level of isolation that will prevent active passage of data. The above solution could still provide an electrical leakage path between the networks whereby classified information could leak onto another network. To improve on the electrical isolation between networks and as an alternative to powering off the CODECs, an optical link using fiber optic to Ethernet media adaptors/converters/modems between the CODEC and each of the networks it serves could be implemented. In this case, the fiber optic media adaptors would be powered in a mutually exclusive manner. Mutually exclusive power means that only one CODEC or fiber optic adaptor can be powered at a time. Turning on one CODEC or fiber optic adaptor turns off power for all others.Information Assurance OfficerDCSP-1
Checks: C-49181r3_chk

Review the VTC system architecture to determine the method of network isolation used. Verify that only one CODEC or fiber optic media adaptor can be turned on at a time by attempting to turn on more than one CODEC concurrently. If more than one CODEC operates, this is a finding.

Fix: F-48608r1_fix

Obtain and implement a power control system that can support automatic mutually exclusive power control.

b
The implementation of an IP-based VTC system supporting conferences on multiple networks having different classification levels must maintain isolation between the networks to which it connects by implementing separation of equipment and cabling between the various networks having differing classification levels in accordance with CNSSAM TEMPEST/01-13, RED/BLACK Installation Guidance.
Medium - V-43025 - SV-55754r2_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7200
Vuln IDs
  • V-43025
Rule IDs
  • SV-55754r2_rule
Information leakage is the intentional or unintentional release of information to an untrusted environment from electromagnetic signals emanations. Security categories or classifications of information systems (with respect to confidentiality) and organizational security policies guide the selection of security controls employed to protect systems against information leakage due to electromagnetic signals emanations. The Committee on National Security Systems Advisory Memorandum (CNSSAM) TEMPEST/01-13, RED/BLACK Installation Guidance, provides criteria for the installation of electronic equipment, cabling, and facility support for the processing of secure information. The TEMPEST/01-13 requires the facility housing the secure VTC equipment (i.e., the secure conference room) must meet the TEMPEST requirements for such rooms. The appropriate and required separations between RED and BLACK equipment and cables must be met. This includes cable routing inside equipment cabinets. Depending on the TEMPEST ZONE, the separation requirements are: - Minimum equipment separation - 50 cm or 1m - Minimum cable separation - 5 cm or 15 cm National policy requires that systems and facilities processing NSI must be reviewed by a Certified TEMPEST Technical Authority (CTTA) to achieve TEMPEST security. The CTTA may require separate power sources for RED equipment and BLACK equipment.Information Assurance OfficerECTC-1
Checks: C-49182r7_chk

Review the documentation and based on the TEMPEST ZONE in the CNSSAM TEMPEST/01-13, RED/BLACK Installation Guidance, verify whether the required separations between RED and BLACK equipment and cables have been met. This includes cable routing inside equipment cabinets. Depending on the TEMPEST ZONE, the separation requirements are: - Minimum equipment separation - 50 cm or 1m - Minimum cable separation - 5 cm or 15 cm If the cables or equipment are closer than the minimum cable and equipment separation distances, this is a finding. In the event a CTTA has reviewed the system’s installation and provided a favorable report or certification, this is not a finding.

Fix: F-48609r5_fix

Install cabling and equipment in accordance with the CNSSAM TEMPEST/01-13, RED/BLACK Installation Guidance. Depending on the TEMPEST ZONE, the separation requirements are: - Minimum equipment separation - 50 cm or 1m - Minimum cable separation - 5 cm or 15 cm

c
An enclave supporting an IP-based VTC system that must communicate across an IP WAN must implement a VTC/VVoIP-aware firewall or H.460-based firewall traversal solution at its boundary with the WAN.
High - V-43027 - SV-55756r1_rule
RMF Control
Severity
High
CCI
Version
RTS-VTC 6000
Vuln IDs
  • V-43027
Rule IDs
  • SV-55756r1_rule
To support a VTC session through a standard non H.323 aware firewall, the administrator must open a wide range (from 16000 to 65000) of UDP ports. If the VTU only connects with one other endpoint CODEC or MCU, this port opening can be limited to the IP address of the other end. While a hole has been opened in the firewall, the risk is somewhat mitigated by the address restriction. However, if a VTC call can come from any endpoint, with any IP address, then the hole resulting from opening the UDP ports to a large range of IP addresses negates the effectiveness of the firewall. To mitigate this issue, an H.460 border controller is required rather than opening all UDP ports to all or many IP addresses. This device effectively limits all of the UDP and TCP ports required to support H.323 VTC sessions to a very small number (3-7), the connections through which are initiated from within the enclave thus requiring little or no firewall reconfiguration to accommodate. H.460 is a set of extensions to the ITU H.323 standard that includes methods to traverse firewalls. In order for a video conference to take place across a secure firewall using H.460, a server or appliance using H.460 must be available and reachable by video conferencing endpoints. Video conference endpoints need to register with an H.460 server and in order to do this they must be enabled for this by their respective manufacturers. This requirement results in a CAT III finding in the event this requirement cannot be met and IP ports are statically opened on a standard firewall to accommodate VTC traffic such that the IP ports are restricted by the internal IP address(es) of the internal CODEC(s) and the external address(es) of a central MCU or a limited set of remote endpoints using an any-any statement. This CAT III can be eliminated in the event these ports are not statically opened, but are manually opened and closed by the firewall administrator for the duration of VTC sessions. This CAT III can also be eliminated in the event the inbound permit statements are restricted to a limited range of UDP ports and external IP addresses, while routing/outbound permit statements forces all outbound VTC traffic to these external addresses.This can be downgraded from a CAT I to a CAT III if this requirement cannot be met and IP ports are statically opened on a standard firewall to accommodate VTC traffic such that the IP ports are restricted by the internal IP address(es) of the internal CODEC(s) and the external address(es) of a central MCU or a limited set of remote endpoints using an any-any statement. This CAT III can be eliminated in the event these ports are not statically opened, but are manually opened and closed by the firewall administrator for the duration of VTC sessions. This CAT III can also be eliminated in the event the inbound permit statements are restricted to a limited range of UDP ports and external IP addresses, while routing/outbound permit statements force all outbound VTC traffic to these external addresses.Information Assurance OfficerDCPP-1, EBBD-2
Checks: C-49184r4_chk

Review system documentation and verify that a VTC/VVoIP-aware firewall or H.460-based firewall traversal solution has been implemented at the enclave boundary. If this does not exist, verify the following: • The enclave firewall allows VTC traffic only to the internal IP address(es) of the internal CODEC(s) and the external address(es) of a central MCU or a limited set of remote endpoints. • The inbound permit statements are restricted to a limited range of UDP ports and external IP addresses while routing/outbound permit statements force all outbound VTC traffic to these external addresses. • These UDP ports are not statically opened, but are manually opened and closed by the firewall administrator for the duration of VTC sessions. If there is not a VTC/VVoIP-aware firewall or H.460-based firewall traversal solution implemented at the enclave boundary and no other measures have been taken, this is a CAT I finding. If there is not a VTC/VVoIP-aware firewall or H.460-based firewall traversal solution implemented at the enclave boundary, and the firewall is configured to allow VTC traffic only to the internal IP address(es) of the internal CODEC(s) and the external address(es) of a central MCU or a limited set of remote endpoints and the inbound permit statements are restricted to a limited range of UDP ports, this is a CAT III finding. If the firewall allows the VTC traffic only during VTC sessions, then this is no longer a finding.

Fix: F-48611r2_fix

Obtain and implement a VTC/VVoIP-aware firewall or H.460-based firewall traversal solution at the enclave boundary. If this is not possible, configure the existing firewall to allow VTC traffic only to the internal IP address(es) of the internal CODEC(s) and the external address(es) of a central MCU or a limited set of remote endpoints. If possible, reconfigure the firewall to close VTC ports between sessions.

b
An IDS/IPS must protect the IP-based VTC system within the enclave.
Medium - V-43028 - SV-55757r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 6020
Vuln IDs
  • V-43028
Rule IDs
  • SV-55757r1_rule
An enclave supporting an IP-based VTC system that must communicate across an IP WAN must be protected by the existing network IDS/IPS or by the implementation of an IDS/IPS that is dedicated to the VTC enclave. The IDS/IPS must comply with the requirements of the IDS/IPS Security Technical Implementation Guide. Please refer to the “IDPS Security Guidance at a Glance” for additional implementation guidance for Network Intrusion Detection/Prevention Systems.Information Assurance OfficerEBBD-2
Checks: C-49185r3_chk

Review network documentation and verify that the existing enclave network IDS/IPS is protecting the VTC system or that a dedicated IDS/IPS is protecting the VTC enclave. If there is no IDS/IPS protecting the VTC system, this is a finding.

Fix: F-48612r2_fix

Obtain and configure a dedicated IDS/IPS or configure the existing enclave IDS/IPS to protect the VTC system.

b
The IP-based VTC system must authenticate to an H.323 Gatekeeper or VVoIP session/call controller.
Medium - V-43030 - SV-55759r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 5040
Vuln IDs
  • V-43030
Rule IDs
  • SV-55759r1_rule
An IP-based VTC system must authenticate itself to an H.323 Gatekeeper or VVoIP session/call controller for the purposes of access control, authorization, and WAN access bandwidth management. An H.323 Gatekeeper or VVoIP session/call controller is a dedicated device or application that controls the manner in which phone calls are initiated, conducted, and terminated and is often one of the main components in H.323 systems. It serves the purpose of Call Admission Control and translation services from E.164 IDs (commonly a phone number) to IP addresses in an H.323 telephony network. It also provides bandwidth control. In general, all VTC system management applications and application suites, including endpoint and MCU managers, gateways, gatekeepers, controllers, and scheduling systems must be operated on secure or hardened platforms and comply with all applicable DoD STIGs with specific emphasis on user accounts, roles/permissions, access control, and auditing.Information Assurance OfficerIAIA-1
Checks: C-49186r5_chk

Review the system documentation and verify that an H.323 Gatekeeper and/or VVoIP session/call controller is in place and is configured to require authentication of endpoints. If there is no H.323 Gatekeeper or VVoIP session/call controller present; or it is not configured to require authentication of endpoints; or endpoints are not configured to authenticate with either, this is a finding.

Fix: F-48614r3_fix

Configure the endpoints and H.323 Gatekeeper or VVoIP session/call controller to authenticate endpoints.

b
The IP-based VTC system must use H.235-based signaling encryption.
Medium - V-43035 - SV-55764r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 1240
Vuln IDs
  • V-43035
Rule IDs
  • SV-55764r1_rule
An IP/H.323-based VTC system as a whole (including CODECs, MCUs, Gatekeepers, Gateways, firewall traversal border elements, etc.) must implement H.235-based signaling encryption. H.235 has been developed to help secure the signaling protocols used in the H.323 suite of protocols. H.235 uses the Advanced Encryption Standard (AES) for encryption and the Diffie-Hellman key exchange protocol for key exchange. AES is supported under H.235 version 3. Technical details of H.235 are set forth in the ITU-T Recommendation H.235.6 (2005), H.323 security: Voice encryption profile with native H.235/H.245 key management.Information Assurance OfficerECCT-1, ECNK-1, ECSC-1
Checks: C-49187r3_chk

Review the documentation to determine that the VTC equipment supports H.235-based signaling encryption and review configuration of the equipment to verify that it is being implemented. If the equipment does not support H.235-based signaling encryption or it has not been implemented, this is a finding.

Fix: F-48617r2_fix

Obtain equipment that supports H.235-based signaling encryption and configure the equipment to implement encryption.

b
The operator of an ISDN-based VTC system utilizing a Type 1 encryptor for classified sessions must ensure any removable Keying Material (KEYMAT) (e.g., Cryptographic Ignition Key (CIK)) for the encryptor is secured in an appropriate secure facility or GSA-approved container when the system is not in use.
Medium - V-43038 - SV-55767r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7320
Vuln IDs
  • V-43038
Rule IDs
  • SV-55767r1_rule
Removable Keying Material (KEYMAT) and each CIK must be handled in accordance with the Operational Security Doctrine of the encryptor as well as all applicable policies and guidance, such as the National Security Telecommunications and Information Systems Security Instruction 4000 series policies. When the CIK is not in use, it must be stored so that unauthorized personnel are unable to access it. This may mean that it is kept in a safe or in a locked desk behind a locked door to which only authorized personnel have access. The CIK can be stored in the same room as the encryptor; however, the CIK must be protected to the same classification level as the encryptor. The CIK may be stored in a separate room from the TACLANE in a secure container that will afford sufficient protection (e.g., a locked cabinet or desk will be sufficient).Information Assurance OfficerECCM-1, PESS-1
Checks: C-49188r4_chk

Verify that the VTC Administrator and all other authorized personnel have a copy of the Operational Security Doctrine of the particular encryptor(s) in use at the site, as well as all applicable policies and guidance. Verify the following: • If Type 1 encryptors that use OTAR rekeying methods are operated in a secure facility rated for the highest classification level of the keys used, this is not a finding. • If Type 1 encryptors that use removable KEYMAT are operated in a secure facility rated for the highest classification level of the keys used and any removable KEYMAT remains with or in the Type 1 encryptor, this is not a finding. • If Type 1 encryptors that use removable KEYMAT are NOT operated in a secure facility rated for the highest classification level of the keys used, verify the removable KEYMAT is secured in an appropriate secure facility rated for the highest classification level of the KEYMAT or in a GSA-approved container when the system is not in use. If so, this is a finding.

Fix: F-48619r3_fix

Implement Cryptographic Ignition Key handling procedures that comply with Operational Security Doctrine and applicable policies and guidance. Secure each CIK in either a GSA-approved safe or locked cabinet in a secure facility rated for the highest classification level of the KEYMAT.

b
An ISDN-based or IP-based VTC system supporting conferences on multiple networks having different classification levels must utilize approved automatically controlled signage to indicate the secure/non-secure status or classification level of the conference/session. Such signage will be placed within the conference room and outside each entrance.
Medium - V-43040 - SV-55769r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7340
Vuln IDs
  • V-43040
Rule IDs
  • SV-55769r1_rule
VTC system users within the room must be informed when the system is actively engaged in a classified session and the classification level of that session if multiple classification levels are supported by the system. This will inform the participants regarding the information they may discuss during the session, thus preventing information having higher classification being discussed in a session having a lower classification level. Additionally, persons entering a room where classified VTC sessions occur must be informed of the status and classification level of the session so that persons without the appropriate clearance level for the information being discussed/presented do not enter the room. Both situations can lead to improper disclosure of classified information. System signage must minimally reflect secure/non-secure status of the system. The signage in IP-based systems connected to multiple classified networks must additionally reflect the classification of the network to which the system is connected. Signage must be controlled by the A/B, A/B/C, or A/B/C/D switch position.Information Assurance OfficerPEPF-1
Checks: C-49189r3_chk

Inspect the room where conferences take place to observe sign placement and that they accurately reflect the secure/non-secure status or classification of the network to which the system is connected. This will require a demonstration of the capability. If the signage is not posted or it does not accurately reflect the secure/non-secure status or classification of the network to which the system is connected, this is a finding.

Fix: F-48620r3_fix

Obtain and implement approved automatically controlled signage that indicates the secure/non-secure status or classification level of the conference/session. Install signs so they are clearly visible within the room and at the entranceways.

b
An ISDN-based VTC system supporting secure (classified) and non-secure (unclassified) conferences must utilize an approved pair of EIA-530 A/B switches operated in tandem or a dual A/B switch to switch the Type 1 encryptor in/out of the circuit between the CODEC and IMUX.
Medium - V-43041 - SV-55770r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7360
Vuln IDs
  • V-43041
Rule IDs
  • SV-55770r1_rule
ISDN-based VTC systems supporting secure (classified) and non-secure (unclassified) conferences operate in an unclassified manner while connecting a call. If the call is to be classified or “secure” at any level, the Type 1 encryptor is switched into the circuit between the CODEC and IMUX, then synced with the other end before the conference discussions can “go secure”. This is typically performed using approved A/B switches on both sides of the encryptor operated in tandem. The use of the word “tandem” here does not refer to public switched telephone network (PSTN) tandem switches. This refers to a pair of A/B switches that are operated at the same time. Information Assurance Officer
Checks: C-49190r6_chk

Review the documentation to determine whether approved A/B switches are in place. DISN Video Services (DVS) maintains a list of A/B switches and dial isolators that have been TEMPEST certified to meet the above requirements at http://disa.mil/Services/Network-Services/Video/~/media/Files/DISA/Services/DVS/red_black_peripherals.xls. If A/B switches operated in tandem or a dual A/B switch is not implemented and used, or the A/B switches are not on the list, this is a finding.

Fix: F-48621r3_fix

Obtain and install approved EIA-530 A/B switches.

b
An ISDN-based VTC system supporting secure (classified) and non-secure (unclassified) conferences while implementing dialing capability from the CODEC must utilize an approved EIA-366-A dial isolator that disconnects the dialing channel between the CODEC and IMUX when the IMUX signals it is connected to another IMUX (i.e., the session is connected).
Medium - V-43043 - SV-55772r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7380
Vuln IDs
  • V-43043
Rule IDs
  • SV-55772r1_rule
When dialing is performed from the CODEC, an EIA-366 connection is made between the CODEC and the IMUX to carry the dialing instructions to the IMUX which actually performs the dialing function. This is not an issue if there is no EIA-366-A connection between the CODEC and the IMUX and all dialing is performed from the IMUX.Information Assurance OfficerECSC-1, ECTC-1
Checks: C-49191r7_chk

Review the documentation to determine whether an approved EIA-366-A dial isolator is in place. DISN Video Services (DVS) maintains a list of A/B switches and dial isolators that have been TEMPEST certified to meet the above requirements at http://disa.mil/Services/Network-Services/Video/~/media/Files/DISA/Services/DVS/red_black_peripherals.xls. If a dial isolator is not implemented and used, or the dial isolator is not on the list, this is a finding. If there is no EIA-366-A connection between the CODEC and the IMUX and all dialing is performed from the IMUX, this is not a finding.

Fix: F-48623r2_fix

Obtain and install an approved EIA-366-A dial isolator unless there is no EIA-366-A connection between the CODEC and the IMUX and all dialing is performed from the IMUX.

a
An ISDN-based VTC system supporting secure (classified) and non-secure (unclassified) conferences must be cabled to maintain a minimum of 5 or 15 centimeters RED/BLACK separation on either side of any Type 1 encryptor and any dial isolator (depending on the TEMPEST zone).
Low - V-43045 - SV-55774r2_rule
RMF Control
Severity
Low
CCI
Version
RTS-VTC 7400
Vuln IDs
  • V-43045
Rule IDs
  • SV-55774r2_rule
Information leakage is the intentional or unintentional release of information to an untrusted environment from electromagnetic signals emanations. Security categories or classifications of information systems (with respect to confidentiality) and organizational security policies guide the selection of security controls employed to protect systems against information leakage due to electromagnetic signals emanations. The Committee on National Security Systems Advisory Memorandum (CNSSAM) TEMPEST/01-13, RED/BLACK Installation Guidance, provides criteria for the installation of electronic equipment, cabling, and facility support for the processing of secure information. The TEMPEST/01-13 requires separation between RED and BLACK equipment and cables, to include cable routing inside equipment cabinets. Depending on TEMPEST ZONE, the separation requirements are: - Minimum equipment separation - 50 cm or 1m - Minimum cable separation - 5 cm or 15 cm The unencrypted information, wiring, and processing equipment are considered RED while the encrypted information, wiring, and processing equipment are considered BLACK.Information Assurance OfficerECTC-1
Checks: C-49192r5_chk

Review the documentation and based on the TEMPEST ZONE in the CNSSAM TEMPEST/01-13, RED/BLACK Installation Guidance, verify whether the required separations between RED and BLACK equipment and cables are met. This includes cable routing inside equipment cabinets. Depending on the TEMPEST ZONE, the separation requirements are: - Minimum equipment separation - 50 cm or 1m - Minimum cable separation - 5 cm or 15 cm If the cables or equipment are closer than the minimum cable and equipment separation distances, this is a finding.

Fix: F-48625r3_fix

Install cabling and equipment in accordance with CNSSAM TEMPEST/01-13, RED/BLACK Installation Guidance. Depending on the TEMPEST ZONE, the separation requirements are: - Minimum equipment separation - 50 cm or 1m - Minimum cable separation - 5 cm or 15 cm

b
ISDN-based VTC equipment supporting secure (classified) and non-secure (unclassified) conferences which implement dial isolators and A/B switches must meet minimum port-to-port isolation standards.
Medium - V-43049 - SV-55778r1_rule
RMF Control
Severity
Medium
CCI
Version
RTS-VTC 7420
Vuln IDs
  • V-43049
Rule IDs
  • SV-55778r1_rule
ISDN-based VTC system A/B switches, Dial Isolators, and/or other devices used to interface between RED and BLACK circuits/equipment shall exhibit the following port-to-port isolation characteristics, as applicable: • 100 dB over the baseband audio frequency range between 0.3 and 15 kHz. • 80 dB over the baseband video frequency range up to 5 MHz. • 60 dB over the frequency range from one times (Rd) to ten times the basic data rate (10Rd) of the digital signal(s) processed. DISN Video Services (DVS) maintains a list of A/B switches and Dial Isolators that have been TEMPEST certified to meet the above requirements at http://disa.mil/Services/Network-Services/Video/~/media/Files/DISA/Services/DVS/red_black_peripherals.xlsInformation Assurance OfficerECTC-1
Checks: C-49193r6_chk

Review documentation to determine whether approved dial isolators and A/B switches are being used. DISN Video Services (DVS) maintains a list of A/B switches and dial isolators that have been TEMPEST certified to meet the above requirements at http://disa.mil/Services/Network-Services/Video/~/media/Files/DISA/Services/DVS/red_black_peripherals.xls. If the A/B switch or dial isolator is not on the list, this is a finding.

Fix: F-48626r6_fix

Obtain and install DVS-approved dial isolators and A/B switches that maintain the following port-to-port isolation standards: • 100 dB over the baseband audio frequency range between 0.3 and 15 kHz. • 80 dB over the baseband video frequency range up to 5 MHz. • 60 dB over the frequency range from one times (Rd) to ten times the basic data rate (10Rd) of the digital signal(s) processed.

a
Video teleconferencing system components Standard Mandatory DoD Notice and Consent Banner must be acknowledged by the user prior to logon or initial access.
Low - V-54695 - SV-68941r1_rule
RMF Control
Severity
Low
CCI
Version
RTS-VTC 3425.00
Vuln IDs
  • V-54695
Rule IDs
  • SV-68941r1_rule
The operating system and remotely accessed information systems are required to display the DoD-approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. System use notification messages must be displayed when individuals log on to the information system. The approved DoD text must be used as specified in the DoD Instruction 8500.01 dated March 14, 2014.ECWM-1
Checks: C-55317r2_chk

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

Fix: F-59551r2_fix

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

b
Video conferencing, Unified Capability (UC) soft client, and speakerphone speaker operations policy must prevent disclosure of sensitive or classified information over non-secure systems.
Medium - V-79051 - SV-93757r2_rule
RMF Control
Severity
Medium
CCI
Version
VVT/VTC 1906
Vuln IDs
  • V-79051
Rule IDs
  • SV-93757r2_rule
Speakers used with Voice Video systems and devices may be heard by people and microphones with no relationship to the conference or call in progress. In open areas, conference audio may be overheard by others in the area without a need-to-know. A policy must be in place and enforced regarding the placement and use of speakers connected to secure Voice Video systems (video conferencing, EVoIP, ECVoIP, etc.) and secure Voice Video endpoints (STU-III, STE, etc.) located in areas or rooms where classified meetings, conversations, or work normally occur. The policy must be in accordance with NSA and DCI guidance and address, at a minimum, the following: - Location if instruments must be limited to sole-use offices, conference rooms, and similar areas that afford sound attenuation. - Notification to all room occupants of the use of the speaker. - Notification to all room occupants for awareness of the classification of conversations taking place. - The room occupant assuming responsibility for taking the necessary precautions to ensure that the classified discussion is not overheard. - Secure Voice Video endpoints must be configured to prevent speaker enablement in the non-secure mode. Speakerphone use on secure telecommunications systems requires special consideration regarding placement and operating policy. NSA S412 approves the installation/enablement of speakerphones on National Secure Telephone Systems (NSTS) and STU-III/STE instruments. The intent of speakerphone approval rests with the room occupant assuming responsibility for taking the necessary precautions to ensure that the classified discussion is not overheard by individuals outside the conversation who may not have a need-to-know for the information discussed and/or that the speakerphone will not pick up and transmit other classified conversations in the area that are not part of the call in progress.
Checks: C-78639r1_chk

Confirm a policy and supporting procedures are in place that address the placement and operation of video conferencing, UC soft client, and speakerphone speakers to prevent disclosure of sensitive or classified information over non-secure systems. Operational policy and procedures are included in user training and guides. The policy and supporting procedures should take into account the classification of the area where the video conferencing equipment, the PC supporting a UC soft client, and Voice Video endpoints are placed, as well as the classification and need-to-know restraints of the information communicated within the area. Include measures such as closing office or conference room doors, adjusting volume levels in open offices, and muting microphones when not directly in use. If a policy and supporting procedures governing video conferencing, UC soft client, and speakerphone speaker operations preventing disclosure of sensitive or classified information over non-secure systems do not exist or are not enforced, this is a finding.

Fix: F-85801r1_fix

Document and enforce a policy and procedure for video conferencing, UC soft client, and speakerphone speaker operations to prevent disclosure of sensitive or classified information over non-secure systems. Ensure appropriate training is provided for users. The policy and supporting procedures should take into account the classification of the area where the video conferencing equipment, the PC supporting a UC soft client, and Voice Video endpoints are placed, as well as the classification and need-to-know restraints of the information communicated within the area. Include measures such as closing office or conference room doors, adjusting volume levels in open offices, and muting microphones when not directly in use.