{
"stig": {
"date": "2014-04-07",
"description": "The Voice/Video Services Policy STIG includes the non-computing requirements for Voice/Video systems operating to support the DoD. The Voice/Video over Internet Protocol (VVoIP) STIG containing the computing requirements must also be reviewed for each site using voice/video services. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil.",
"findings": {
"V-16070": {
"checkid": "C-17113r1_chk",
"checktext": " Interview the IAO to validate compliance with the following requirement: \n\nEnsure C2 and special-C2 users are made aware of the potential for unreliability and reduced availability of PC based communications for assured service/C2 communications in the various situations in which they might use their PC for this purpose. The IAO will additionally ensure C2 and Special-C2 users are made aware of the need for, and availability of, backup communications methods are available and provided in these various situations.\n\nAdditionally, interview a random sampling of C2 and special-C2 users to confirm their awareness. This is a finding in the event the users are unaware of the limitations of reliability and/or there is no attempt to make them aware.\n",
"description": "PC based communications applications rely on many different factors, but are dependant upon the platform on which they operate. A PC could be dedicated to a task, protected, and controlled such that it is highly available for mission critical applications and communications. However, a user\u2019s general purpose PC or other computing device may not be highly available for mission critical communications, particularly if it is not dedicated to that task. This because it supports many applications and functions while being connected to a network through which any number of threats can come. Mission critical applications and communications are also negatively affected if the PC is powered off, busy with another process, the communications application is not loaded or running properly, or if the PC is compromised and/or is having operational problems. While a fixed desktop or tower PC may be kept in a powered on and network connected state most of the time, a portable PC (laptop) is much more likely to be powered off and disconnected from the network. There is more chance that the PC and communications application won\u2019t work, or be available, when needed compared to a dedicated device such as purpose built hard phones or dedicated PCs. Power for operating the PCs is another consideration in our discussion of their support for assured services and mission critical systems, users, and locations. If there is no power in the user\u2019s workspace, the PC will not function unless a backup power supply is provided. Thus may be provided using a battery based Uninterruptible Power Supply (UPS) or a backup generator. Either solution is very costly when providing backup power to the workspace for the PC, particularly for large numbers of users. Provisions for light and other environmental factors may also be necessary adding to cost. On the other hand, power is much more easily provided to a hardware based phone from the wiring closet using the LAN cabling. A UPS or generator will still be needed but in a centralized location reducing cost. Another factor is the robustness and reliability of the network to which the PC is connected. As noted above, DoD networks can and must be designed and controlled to provide the reliability and robustness needed to support assured service. This can work well for a dedicated communications endpoint but not necessarily for a PC communications application. This is because the PC will be connected to the portion of the LAN that carries normal data traffic by default. That is the portion of the LAN that can be compromised and degraded by various DoS attacks and other issues making it difficult for this portion of the LAN to provide assured service. The VoIP STIG defines some of the LAN requirements for the support of assured service, most notably the separation of the voice assets and traffic on the LAN from the data assets and traffic while maintaining a converged LAN architecture. Various solutions may also be available that can allow a PC to mitigate or manage these issues. These will be discussed later in the LAN use case section of this STIG. \n\nA remotely connected PC cannot be relied upon to support assured service if it is connected to a non-DoD network such as an Internet connected LAN or the internet itself. This is due to lack of DoD control over the network to which it is attached. While most non-DoD LANs and the Internet are relatively reliable and may be robust regarding bandwidth, there is no control over the conditions in, or the availability of, these networks, whether it is the LAN or WAN. Based on the factors noted in the previous paragraphs, PCs cannot provide the reliability and availability required for assured service when compared to the reliability and availability specifications for a LAN supporting assured service. These factors make it difficult to consider a user\u2019s general purpose fixed, or portable, PC as being a stable platform for mission critical communications in an assured service sense, even though that is desired. All of these factors also affect non-assured service systems that provide life safety and emergency communications. In the future, PC and PC based communications application vendors may solve these problems and provide us with fully assured service capable PC based communications on a standard general purpose, general use platform at a reasonable cost. These issues do not, however, preclude a PC based communications application from attempting to place and receive priority communications sessions. A C2 user may use this type of end instrument for the origination of, or reception of routine and non-routine calls at their discretion, as long as a purpose built instrument or other backup communications system/device is also available for use as a backup communications method when necessary. This however, may not be feasible in all situations such as when using a portable PC outside of the normal workspace. \n",
"fixid": "F-16175r1_fix",
"fixtext": "Ensure C2 and Special-C2 users are made aware of the potential for unreliability and reduced availability of PC based communications for assured service/C2 communications in the various situations in which they might use their PC for this purpose. The IAO will additionally ensure C2 and Special-C2 users are made aware of the need for, and availability of, backup communications methods are available and provided in these various situations.\n\nImplement training for C2 and Special-C2 users to provide awareness of the potential for unreliability and reduced availability of PC based communications for assured service / C2 communications in the various situations in which they might use their PC for this purpose.\n",
"iacontrols": [
"ECSC-1",
"PRTN-1"
],
"id": "V-16070",
"ruleID": "SV-17057r1_rule",
"severity": "medium",
"title": "C2 and Special-C2 users are not aware of the assured service limitations of their PC based communications applications.",
"version": "VVoIP 1300 (GENERAL)"
},
"V-16073": {
"checkid": "C-17115r1_chk",
"checktext": "Interview the IAO and a sampling of C2 or Special-C2 users to determine if C2 or Special-C2 users are provided with a more reliable communications method than a PC based communications application in compliance with the following requirement: \n\nWithin a C2 or Special-C2 user\u2019s normal workspace (e.g., office) or alternate fixed workspace (e.g., quarters, alternate office), ensure C2 and Special-C2 users are provided with an alternate assured service communications device/system (e.g., hardware based IP or traditional telephone endpoint) is provided as backup to a PC based communications application (e.g., soft-phone) for their mission critical assured service (C2) voice communications needs if and when the PC or application fails or is unavailable. \n\nNote: Cell phones. PDA/PEDs, or other wireless devices are not considered reliable enough within a normal workspace to meet this requirement due to lack of reliable signal everywhere and their inability to be used in certain DoD environments. However these could be considered in a remote use case.\n\nNOTE: This is not intended to require the installation of assured service communications devices in alternate workspaces such as quarters unless there is a requirement for the C2 or Special-C2 user to place and receive C2 communications in that location.\n\nThis is a finding if C2 or Special-C2 users are not provided with a more reliable communications method than a PC based communications application for their assured service needs. \n\n\n",
"description": "PC based communications applications rely on many different factors, but are dependant upon the platform on which they operate. A PC could be dedicated to a task, protected, and controlled such that it is highly available for mission critical applications and communications. However, a user\u2019s general purpose PC or other computing device may not be highly available for mission critical communications, particularly if it is not dedicated to that task. This because it supports many applications and functions while being connected to a network through which any number of threats can come. Mission critical applications and communications are also negatively affected if the PC is powered off, busy with another process, the communications application is not loaded or is not running properly, or if the PC is compromised and/or is having operational problems. While a fixed desktop or tower PC may be kept in a powered on and network connected state most of the time, a portable PC (laptop) is much more likely to be powered off and disconnected from the network. There is more chance that the PC and communications application won\u2019t work, or be available, when needed compared to a dedicated device such as purpose built hard phones or dedicated PCs. \n\nPower for PCs is another consideration in our discussion of their support for assured services and mission critical systems, users, and locations. If there is no power in the user\u2019s workspace, the PC will not function unless a backup power supply is provided. Thus may be provided using a battery based Uninterruptible Power Supply (UPS) or a backup generator. Either solution is very costly when providing backup power to the workspace for the PC, particularly for large numbers of users. Provisions for light and other environmental factors may also be necessary adding to cost. On the other hand, power is much more easily provided to a hardware based phone from the wiring closet using the LAN cabling. A UPS or generator will still be needed but in a centralized location reducing cost.\n\nAnother factor is the robustness and reliability of the network to which the PC is connected. As noted above, DoD networks can and must be designed and controlled to provide the reliability and robustness needed to support assured service. This can work well for a dedicated communications endpoint but not necessarily for a PC communications application. This is because the PC will be connected to the portion of the LAN that carries normal data traffic by default. That is the portion of the LAN that can be compromised and degraded by various DoS attacks and other issues making it difficult for this portion of the LAN to provide assured service. \n\nThis STIG defines some of the LAN requirements for the support of assured service, most notably the separation of the voice assets and traffic on the LAN from the data assets and traffic while maintaining a converged LAN architecture. Various solutions may also be available that can allow a PC to mitigate or manage these issues. These will be discussed later in the LAN use case section of this STIG.\n\nA remotely connected PC cannot be relied upon to support assured service if it is connected to a non-DoD network such as an Internet connected LAN or the internet itself. This is due to lack of DoD control over the network to which it is attached. While most non-DoD LANs and the Internet are relatively reliable and may be robust regarding bandwidth, there is no control over the conditions in, or the availability of, these networks, whether it is the LAN or WAN. \n\nBased on the factors noted in the previous paragraphs, PCs cannot provide the reliability and availability required for assured service when compared to the reliability and availability specifications for a LAN supporting assured service. These factors make it difficult to consider a user\u2019s general purpose fixed or portable PC as being a stable platform for mission critical communications in an assured service sense even though we desire it to be so. All of these factors also affect non-assured service systems that provide life safety and emergency communications. In the future, PC and PC based communications application vendors may solve these problems and provide us with fully assured service capable PC based communications on a standard general purpose, general use platform at a reasonable cost.\n\nThese issues do not, however, preclude a PC based communications application from attempting to place and receive priority communications sessions. A C2 user may use this type of end instrument for the origination of, or reception of routine and non-routine calls at their discretion, as long as a purpose built instrument or other backup communications system/device is also available for use as a backup communications method when necessary. This however, may not be feasible in all situations such as when using a portable PC outside of the normal workspace.\nNote: Voice communications is the most critical communications service for C2 users. While VTC and collaboration is an important C2 tool, a telephone call is the minimal method needed to give and receive orders. Since a PC based application may not be available at all times, backup voice communications methods are needed. This could be accomplished in several ways. Minimally, in the normal workspace, there needs to be a hardware based telephone, either IP or otherwise, connected to a different portion of the network than the PC. While a hardware based IP phone could be associated with the PC, if the portion of the network serving the PC was the cause of the PC being inoperable for C2 communications, the phone might also not be available or operational.\n",
"fixid": "F-16177r1_fix",
"fixtext": "Ensure C2 and Special-C2 users are provided with an alternate assured service communications device/system (e.g., hardware based IP or traditional telephone endpoint) is provided as backup to a PC based communications application (e.g., soft-phone) for their mission critical assured service (C2) voice communications needs \n\nMinimally provide C2 and Special-C2 users with a hardware based telephone and supporting infrastructure that can support reliable assured service communications within their normal or alternate workspaces. \n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16073",
"ruleID": "SV-17060r1_rule",
"severity": "medium",
"title": "A C2 or Special-C2 user does not have a more reliable communications method in their normal or alternate fixed workspace than a PC based communications client.",
"version": "VVoIP 1205 (GENERAL)"
},
"V-16074": {
"checkid": "C-17117r3_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure 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: \n- Conference room and office users do not display sensitive or classified information on walls that are within the view of the camera(s).\n- 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).\n- 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. \n\n\nNOTE: 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.\n\nNOTE: Vulnerability awareness and operational training will be provided to users of video/collaboration communications related camera(s) regarding these requirements.\n\nNOTE: 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.\nInspect the applicable SOP. \n\nInspect 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). \n\nInterview 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.\n\nThis is a finding if deficiencies are found in any of these areas. Note the deficiencies in the finding details.\n",
"description": "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.\n\nNOTE: Vulnerability awareness and operational training will be provided to users of VTC and video/collaboration communications related camera(s) regarding these requirements.\n\nNOTE: 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.",
"fixid": "F-16179r1_fix",
"fixtext": "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. \n\nDo not post potentially sensitive information posted on the walls in view of the camera(s).\n\nProduce 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: \n- Conference room and office users do not display sensitive or classified information on walls that are within the view of the camera(s).\n- 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).\n- 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. \n\nNOTE: 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.\n\nProvide appropriate training such that users follow the SOP. Enforce user compliance with the SOP.\n",
"iacontrols": [
"DCBP-1",
"ECND-1",
"ECSC-1"
],
"id": "V-16074",
"ruleID": "SV-17061r2_rule",
"severity": "high",
"title": "Deficient Policy or SOP for VTC and PC camera operations regarding their ability to pickup and transmit sensitive or classified information in visual form.",
"version": "VVoIP/VTC 1900 (GENERAL)"
},
"V-16076": {
"checkid": "C-17118r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure 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. \n\nNOTE: This SOP should take into account the classification of the area where the 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.\n\nInspect the applicable SOP. \n\nSuch 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.\n\nInspect 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.\n\nThis is a finding if the SOP or training is deficient. \n",
"description": "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(s) 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(s). 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 pickup sound that is not related to a given communications session. They could pickup 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 (e.g., cube). 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 a 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. ",
"fixid": "F-16180r1_fix",
"fixtext": "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. \n\nProduce 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. \n\nSuch 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.\n\nProvide appropriate training such that users follow the SOP. Enforce user compliance with the SOP.\n",
"iacontrols": [
"DCBP-1",
"ECND-1",
"ECSC-1"
],
"id": "V-16076",
"ruleID": "SV-17063r1_rule",
"severity": "medium",
"title": "Deficient Policy or SOP regarding VTC, PC, and speakerphone microphone operations regarding their ability to pickup and transmit sensitive or classified information in aural form.",
"version": "VVT/VTC 1905 (GENERAL)"
},
"V-16077": {
"checkid": "C-17120r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure 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.\n\nIf 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.\n\nInspect 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.\n\nInspect 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.\n\nThis 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\u2019s work area. This is also a finding if the SOP or training is deficient.\n\nNOTE: 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.\n",
"description": "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.",
"fixid": "F-16182r1_fix",
"fixtext": "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.\n\nProduce 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. \n\nProvide appropriate training such that users follow the SOP. Enforce user compliance with the SOP.\n",
"iacontrols": [
"PEDI-1"
],
"id": "V-16077",
"ruleID": "SV-17064r1_rule",
"severity": "medium",
"title": "Deficient Policy or SOP regarding PC communications video display positioning.",
"version": "VVoIP/VTC 1910 (GENERAL)"
},
"V-16078": {
"checkid": "C-17121r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure a policy and procedure is in place and enforced that addresses the proper implementation and use of the \u201cPresentation and Sharing\u201d features of collaboration applications and devices. This policy and SOP will be based on the specific application\u2019s or device\u2019s 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.\n\nInterview the IAO and inspect the applicable SOP. The SOP should address the proper implementation and use of the \u201cPresentation and Sharing\u201d features of collaboration applications and devices. This policy and SOP will be based on the specific application\u2019s or device\u2019s capabilities and will address mitigations for the possible inadvertent disclosure of information to conferees that have no need to see or have access to.\n\nInspect 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.\nThis is a finding if the if the SOP or training is deficient.\n",
"description": "Visual collaboration often requires the sharing or display of presentations, open documents, and white board information to one or more communicating endpoints. While the technology for doing this is different between hardware based 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. ",
"fixid": "F-16183r1_fix",
"fixtext": "Ensure a policy and procedure is in place and enforced that addresses the proper implementation and use of the \u201cPresentation and Sharing\u201d features of collaboration applications and devices. This policy and SOP will be based on the specific application\u2019s or device\u2019s 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.\n\nProduce an SOP that addresses the proper implementation and use of the \u201cPresentation and Sharing\u201d features of collaboration applications and devices. This policy and SOP will be based on the specific application\u2019s or device\u2019s 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.\n\nProvide appropriate training such that users follow the SOP. Enforce user compliance with the SOP \n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16078",
"ruleID": "SV-17065r1_rule",
"severity": "medium",
"title": "Deficient SOP or enforcement regarding presentation and application sharing via a PC or VTC.",
"version": "VVoIP/VTC 1915 (GENERAL)"
},
"V-16081": {
"checkid": "C-17124r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure users of PC based collaboration applications are trained to only share control of their PC or applications with other users that they are familiar with and/or can identify as trustworthy. \n\nDetermine if training is provided such that users of PC based collaboration applications only share control of their PC or applications with other users with whom they are familiar with and/or can identify as trustworthy. Inspect training materials for related content. Interview a random sampling of users to determine if they are properly trained on this topic. \n\nThis is a finding if the training or training materials are deficient. \n",
"description": "Visual collaboration often requires the sharing or display of presentations, open documents, and white board information to one or more communicating endpoints. While the technology for doing this is different between hardware based endpoints, and PC based application endpoints, the vulnerability is the same. In both cases, the displayed information typically resides on a PC. While in presentation/sharing mode, care must be exercised so that the PC user does not inadvertently display and transmit information on their workstation that is not part of the communications session and not intended to be viewed by the other communicating parties. Users must be aware that anything they display on their PC monitor while presenting to a communications session may be displayed on the other communicating endpoints. This is particularly true when the PC video output is connected to a VTC CODEC since the information is 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. The mitigation for this vulnerability is to develop policy and procedures on how to securely present to collaborative communications sessions . All users that perform this function must have awareness of the issues and be trained in the proper operational procedures. Such procedures may require that there be no non-session related documents or windows open or minimized on the PC while presenting or sharing. An additional requirement may be that the user may not permit others in a session to remotely control their PC. A similar issue is that some PC based collaboration applications can permit a user to allow other session participants to remotely control their PC. Depending upon how this feature is implemented and limited, it could lead to undesired activities on the part of the person in control and possible compromise of information that is external to the collaboration session. This would be the case if such sharing or remote control provided access to the local hard drive and non session related applications or network drives accessible from the controlled PC. ",
"fixid": "F-16186r1_fix",
"fixtext": "Ensure users of PC based collaboration applications are trained to only share control of their PC or applications with other users that they are familiar with and/or can identify as trustworthy. \n\nProduce training materials and provide training such that users of PC based collaboration applications only share control of their PC or applications with other users with whom they are familiar with and/or can identify as trustworthy.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16081",
"ruleID": "SV-17069r1_rule",
"severity": "medium",
"title": "Deficient training for the secure operation of PC desktop, presentation, or application sharing capabilities of a collaboration tool.",
"version": "VVoIP 1310 (GENERAL)"
},
"V-16082": {
"checkid": "C-17125r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure audio and video pickup/capture capabilities of microphones and cameras associated with a PC are disabled or inhibited when not required for communications such that inadvertent disclosure of aural or visual information is prevented. Ensure that operational policy and procedures are included in user training and guides.\n\nDetermine if the applicable training on the required operational procedures is provided. Inspect training materials. Interview a random sampling of users to determine if they are properly trained on this topic and actually perform the mitigating actions. Inspect a random sample of PCs that are not actively communicating to determine if the required mitigations are in place. \n\nNOTE: This requirement minimally involves muting the PC microphone and camera. If necessary, the camera lens must be covered, or the camera aimed at a blank wall to \u201cmute\u201d it. Ideally, the microphone and camera would be external devices and not embedded in the PC or an external monitor that could be disconnected from the PC when not needed. The external microphone and camera could remain connected to the PC if there was a positive physical disconnect or mute (shorting) switch for the microphone, and if the camera is disconnected by the switch or the camera lens is covered.\n\nThis is a finding if any of the inspected items are deficient such that audio and video pickup/capture capabilities of microphones and cameras associated with a PC are not disabled or inhibited when not required for communications such that inadvertent disclosure of aural or visual information is prevented. \n",
"description": "The VTC STIG discusses the possibility of undesired or improper viewing of and/or listening to activities and conversations in the vicinity of a hardware based VTC endpoint, whether it is a conference room system or an office based executive or desktop system. If this was to occur, there could be inadvertent disclosure of sensitive or classified information to individuals without the proper clearance or need-to-know. This vulnerability could occur if the endpoint was set to automatically answer a voice, VTC, or collaboration call with audio and video capabilities enabled, or if the endpoint was compromised and remotely controlled. The stated requirements and mitigations involve muting the microphone(s) and disabling or covering the camera(s).\n\nThese or similar vulnerabilities could exist in PC based communications/collaboration applications due to an auto answer feature or compromised application or platform. As such, the simplest mitigation would be to only operate the software that accesses the microphone and camera when they are needed for communication. This does not work well for a unified communications application that is used to enhance our communications/collaboration capabilities since the application would be running most, if not all of the time when the PC is operating. In this case, the microphone could be muted and camera disabled in software as a mitigation. However, this also may not work well due to the possibility of the communications/collaboration application, microphone, or camera could be remotely activated if the platform or a communications application is compromised. In this case positive physical controls may be required. We must also rely on our defense in depth strategy for protecting our PC applications, including our communications applications, from compromise. \n\nPhysical disablement such as unplugging from the PC, using a physical mute switch, or covering a camera could work if using external devices. However, this mitigation would not work for embedded microphones and cameras as is the trend in laptops and monitors today. While it may not be easily feasible to physically disable an embedded microphone, the lens of an embedded camera can be covered.\n",
"fixid": "F-16187r1_fix",
"fixtext": "Ensure audio and video pickup/capture capabilities of microphones and cameras associated with a PC are disabled or inhibited when not required for communications such that inadvertent disclosure of aural or visual information is prevented. Ensure that operational policy and procedures are included in user training and guides.\n\nProduce training materials and provide training such that users of PC based collaboration applications disable their microphones and cameras when not participating in a collaboration session. This minimally involves muting the PC microphone and camera. If necessary, the camera lens must be covered, or the camera aimed at a blank wall to \u201cmute\u201d it. Ideally, the microphone and camera would be external devices and not embedded in the PC or an external monitor that could be disconnected from the PC when not needed. The external microphone and camera could remain connected to the PC if there was a positive physical disconnect or mute (shorting) switch for the microphone, and if the camera is disconnected by the switch or the camera lens is covered.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16082",
"ruleID": "SV-17070r1_rule",
"severity": "medium",
"title": "Audio pickup or video capture capabilities (microphones and cameras) are not disabled when not needed for active participation in a communications session.",
"version": "VVoIP 1735 (GENERAL)"
},
"V-16085": {
"checkid": "C-17128r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) capabilities are reviewed and their functionality tested or validated prior to approval, providing them to users, or implementing them.\n\nAsk IAO or IAM if the use of USB phones, USB ATAs, and PPGs is permitted and if they are provided to users. If so, determine if the devices have been reviewed and tested as necessary with regard to their network bridging capabilities. This is a finding if these devices are provided to users and they have not been properly reviewed and/or tested. \n\n",
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. A USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. PPGs can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. ",
"fixid": "F-16190r1_fix",
"fixtext": "Ensure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) capabilities are reviewed and their functionality tested or validated prior to approval, providing them to users, or implementing them.\n\nReview and/or test of USB phones, USB ATAs, and PPGs for their network bridging capabilities. Do not use such devices if the capability exists except to fulfill a validated mission requirement. ",
"iacontrols": [
"DCBP-1",
"DCCT-1",
"DCHW-1",
"EBCR-1",
"ECSC-1"
],
"id": "V-16085",
"ruleID": "SV-17073r1_rule",
"severity": "low",
"title": "Deficient testing of, or lack of approval for, soft-phone accessories.",
"version": "VVoIP 1745 (GENERAL)"
},
"V-16086": {
"checkid": "C-17129r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure personnel are trained not to employ personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones). This policy is to be acknowledged in user agreements and included in user training and user guides.\n\nDetermine if training is provided to users about not employing personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones). Inspect user agreements for acknowledgement of this training. Interview a random sampling of users regarding their awareness of this subject. \n\nThis is a finding if the training, training materials, or user awareness of the policy are deficient or if the policy is not addressed and acknowledged in signed user agreements.\n",
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in the topic of this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. \n\nA USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. They can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones can contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. \n",
"fixid": "F-16191r1_fix",
"fixtext": "Ensure personnel are trained not to employ personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones). This policy is to be acknowledged in user agreements and included in user training and user guides.\n\nProvide the appropriate user training such that they do not employ personally provided soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones); and require they sign user agreements that acknowledge the training and policy.",
"iacontrols": [
"DCBP-1",
"ECSC-1",
"PRTN-1"
],
"id": "V-16086",
"ruleID": "SV-17074r1_rule",
"severity": "low",
"title": "Deficient user training regarding the use of personally provided soft-phone accessories.",
"version": "VVoIP 1315 (GENERAL)"
},
"V-16087": {
"checkid": "C-17130r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability are not used on a DoD PC or network except to fulfill a validated and approved mission requirement.\n\nDetermine if soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability to the PSTN are used on a DoD PC or network. If so, further determine if there is a validated and approved mission requirement for their use. Interview a random sampling of users regarding their use of this bridging capability. This is a finding if these devices are used and there is no validated mission requirement.\n",
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. A USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. They can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones can contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. ",
"fixid": "F-16192r1_fix",
"fixtext": "Ensure soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability are not used on a DoD PC or network except to fulfill a validated and approved mission requirement.\n\nDiscontinue the use of soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability unless there is a validated and approved mission requirement for their use.",
"iacontrols": [
"DCBP-1",
"DCCT-1",
"DCHW-1",
"EBCR-1",
"ECSC-1"
],
"id": "V-16087",
"ruleID": "SV-17075r1_rule",
"severity": "medium",
"title": "Voice networks are improperly bridged via a soft-phone accessory.",
"version": "VVoIP 1750 (GENERAL)"
},
"V-16088": {
"checkid": "C-17131r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nIn the event a soft-phone accessory providing a network bridging capability is approved for use to fulfill a validated and approved mission requirement, the IAO will ensure personnel are properly trained in their implementation and proper use. This training is to be acknowledged in user agreements and included in user guides.\n\nDetermine if soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging capability to a different network (e.g., the PSTN or DSN) are used on a DoD PC or network. If so, further determine if there is a validated and approved mission requirement for their use. Inspect training materials on this subject. Interview a random sampling of users regarding their knowledge of the proper usage of this bridging capability. Inspect user agreements for acknowledgement of this training. \n\nThis is a finding if the training, training materials, or user awareness of the proper use policy are deficient or if the policy is not addressed and acknowledged in signed user agreements.\n",
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in the topic of this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. A USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. They can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones can contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. ",
"fixid": "F-16193r1_fix",
"fixtext": "In the event a soft-phone accessory providing a network bridging capability is approved for use to fulfill a validated and approved mission requirement, the IAO will ensure personnel are properly trained in their implementation and proper use. This training is to be acknowledged in user agreements and included in user guides.\n\nProvide the appropriate user training and training materials such that users operate their soft-phone accessories (i.e., PPGs, ATAs, and/or USB phones) that provide a network bridging in an approved manner and require they sign user agreements that acknowledge the training and policy.",
"iacontrols": [
"DCBP-1",
"ECSC-1",
"PRTN-1"
],
"id": "V-16088",
"ruleID": "SV-17076r1_rule",
"severity": "medium",
"title": "Deficient user training regarding soft-phone accessory network bridging capabilities.",
"version": "VVoIP 1320 (GENERAL)"
},
"V-16089": {
"checkid": "C-17132r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure training materials are developed and PC based voice, video, UC, and collaboration communications application users are trained in, and aware of, various aspects of the application\u2019s safe and proper use as well as the application or service vulnerabilities. Training will include all items contained in user agreements and user guides.\n\nAsk the IAO about the training provided to users about the various aspects of the application\u2019s safe and proper use as well as the application or service vulnerabilities. Inspect training materials for the content contained in user agreements. \n\nThis is a finding if the training materials do not address the contents of the user agreements and the various aspects of the application\u2019s safe and proper use as well as the application or service vulnerabilities.\n",
"description": "Users of PC based voice, video, UC, and collaboration communications applications must be aware of, and trained in, the various aspects of the application\u2019s safe and proper use. They must also be aware of the application or service vulnerabilities and the mitigations for them. This awareness is supported by a combination of user training in the use of the application and any associated accessories as well as its limitations and vulnerabilities. Training is subsequently acknowledged through the signing of user agreements and bolstered by the distribution and utilization of user guides. ",
"fixid": "F-16194r1_fix",
"fixtext": "Ensure training materials are developed and PC based voice, video, UC, and collaboration communications application users are trained in, and aware of, various aspects of the application\u2019s safe and proper use as well as the application or service vulnerabilities. Training will include all items contained in user agreements and user guides.\n\nDevelop training materials that address the contents of the user agreements and the various aspects of the application\u2019s safe and proper use as well as the application or service vulnerabilities",
"iacontrols": [
"DCBP-1",
"ECSC-1",
"PRTN-1"
],
"id": "V-16089",
"ruleID": "SV-17077r1_rule",
"severity": "medium",
"title": "Deficient training or training materials addressing secure PC communications client application usage.",
"version": "VVoIP 1305 (GENERAL)"
},
"V-16090": {
"checkid": "C-17133r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure user agreements are developed in accordance with DoD policies that address the acceptable use of PC based voice, video, UC, collaboration communications applications and their accessories. Topics to be covered are, but are not limited to, the following:\n- Users are not permitted to install soft-phone agents, soft-VTUs, and/or IM clients that connect to or use a public VoIP or IM service for personal use (i.e., non-official business).\n- Users are not permitted to install private soft-phone agents that communicate with other private soft-phone agents or personal phone gateways (PPGs).\n- Users are not permitted to use a stick-phone associated with a commercial VoIP service or a personal VoIP system on a DoD system unless they are sanctioned and provided by a DoD component or organization.\n- Users are not permitted to use soft-phone accessories that can provide a bridge (if connected) between the DoD communications application or DoD network and another computer, phone network, or the PSTN.\n- Users are not permitted to use the DoD provided soft-phone and/or soft-VTU intended for remote access while working in their normal DoD workspace such as in the office, without permission of the IAO and via a special or properly configured network connection or the LANs remote access architecture. \n- User should be cautioned and given notice of the unreliable nature of PC based voice, video, UC, and collaboration applications communications such that C2 users are aware of and acknowledge the non-assured service nature of this communications media.\n- User should be cautioned and given restrictions for the use of PC based voice, video, UC, and collaboration communications application\u2019s capabilities when used in an area where classified work or discussion occurs with emphasis on \u201cwebcam\u201d and speakerphone usage. \n\nNOTE: The site may modify these items in accordance with local site policy however these items must be addressed in a user agreement. The user agreement may be stand alone regarding acceptable use of PC based voice, video, UC, and collaboration communications applications and their accessories or may be included in a larger user agreement that addresses remote access and/or workstation usage.\n\nNOTE: To the extent possible, PC protection and monitoring mechanisms (e.g., HBSS) should monitor compliance with these requirements. \n\nNOTE: Requirements supporting the above user agreement items may be discussed later in this document. The list above may not include all items that need be in the requirement based on the other requirements discussed.\n\nDiscuss the existence and enforcement of an acceptable use policy for PC based voice, video, UC, collaboration communications applications and their accessories. Inspect signed user agreements. Look for items that address the concerns listed in the requirement. \n\nThis is a finding if there is no acceptable use policy or related user agreement or these items are deficient in content.\n",
"description": "DoDI 8500.2 IA control PRRB-1 regarding \u201cSecurity Rules of Behavior or Acceptable Use Policy\u201d states \u201cA set of rules that describe the IA operations of the DoD information system and clearly delineate IA responsibilities and expected behavior of all personnel is in place. The rules include the consequences of inconsistent behavior or non-compliance. Signed acknowledgement of the rules is a condition of access.\u201d\n\nThis IA control requires the generation and use of a \u201cuser agreement\u201d that contains site policy regarding acceptable use of various information system (IS) assets. Requiring the user to read and sign the user agreement before receiving their government furnished hardware and software, or before gaining access to an additional IS, add on application, or an additional privilege, provides the required acknowledgement. \n\nThe Secure Remote Computing STIG requires that a user agreement be used and signed for a user to be permitted to remotely access a DoD network or system. The Wireless STIG adds policy items to this user agreement regarding the use of wireless capabilities in conjunction with remote access. This STIG will be no different in that we, the DoD IA community, must define acceptable use requirements for the use of PC based voice, video, UC, and collaboration communications applications and accessories. While the first two STIGs mentioned require a user agreement prior to remote access privileges being granted, the user agreement should be signed when the user receives their government furnished hardware that covers all acceptable use policies. These policies are to include such things as acceptable web browsing, remote access, all wireless usage, as well as the usage of communications applications, soft-phone accessories, stick phones, personally configured VoIP, and IM clients. Minimally, the user agreement must be updated as privileges and certain applications are installed. User agreements must also be accompanied with user training and guides that reiterate the agreed to policies and provide additional information such as how to implement certain features and IA measures as required. \n\n",
"fixid": "F-16195r1_fix",
"fixtext": "Ensure user agreements are developed in accordance with DoD policies that address the acceptable use of PC based voice, video, UC, collaboration communications applications and their accessories. \n\nRequire users to sign users agreements that address the acceptable use of PC based voice, video, UC, collaboration communications applications and their accessories. Topics to be covered are, but are not limited to, the following:\n- Users are not permitted to install soft-phone agents, soft-VTUs, and/or IM clients that connect to or use a public VoIP or IM service for personal use (i.e., non-official business).\n- Users are not permitted to install private soft-phone agents that communicate with other private soft-phone agents or personal phone gateways (PPGs).\n- Users are not permitted to use a stick-phone associated with a commercial VoIP service or a personal VoIP system on a DoD system unless sanctioned and provided by a DoD component or organization.\n- Users are not permitted to use soft-phone accessories that can provide a bridge (if connected) between the DoD communications application or DoD network and another computer, phone network, or the PSTN.\n- Users are not permitted to use the DoD provided soft-phone and/or soft-VTU intended for remote access while working in their normal DoD workspace (i.e., in the office) without permission of the IAO and via a special or properly configured network connection or the LANs remote access architecture. \n- Cautions and notice of the unreliable nature of PC based voice, video, UC, and collaboration applications communications such that C2 users are aware of and acknowledge the non-assured service nature of this communications media.\n- Cautions and restrictions for the use of PC based voice, video, UC, and collaboration communications application\u2019s capabilities when used in an area where classified work or discussion occurs with emphasis on \u201cwebcam\u201d and speakerphone usage. \n\nNOTE: The site may modify these items in accordance with local site policy however these items must be addressed in a user agreement. The user agreement may be stand alone regarding acceptable use of PC based voice, video, UC, and collaboration communications applications and their accessories or may be included in a larger user agreement that addresses remote access and/or workstation usage.\n\nNOTE: To the extent possible, PC protection and monitoring mechanisms (e.g., HBSS) should monitor compliance with these requirements. \n\nNOTE: Requirements supporting the above user agreement items may be discussed later in this document. The list above may not include all items that need be in the requirement based on the other requirements discussed.\n",
"iacontrols": null,
"id": "V-16090",
"ruleID": "SV-17078r1_rule",
"severity": "medium",
"title": "Deficient acceptable use policy or user agreement regarding PC communication clients.",
"version": "VVoIP 1335 (GENERAL)"
},
"V-16091": {
"checkid": "C-17134r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure a user guide is developed and distributed to users of PC based voice, video, UC, and collaboration communications applications that minimally provides the following information:\n- Reiterates the policies and restrictions agreed to when the user agreement was signed upon receiving the communications application.\n- Provides cautions and notice of the potential unreliable nature of PC communications applications so that C2 users are aware and reminded of the non-assured service nature of this communications media/method.\n- Provides instruction regarding the proper and safe use of webcams in general, and more specifically when used in a classified environment or where classified work is performed and/or classified material and information is displayed or used.\n- Provides instruction regarding the proper and safe use of speakerphone capabilities in general, and more specifically when using them in environments where classified discussion or work occurs. \n- Provides instruction regarding the proper and safe use of presentation, document, and desktop sharing.\n\t\nNOTE: this requirement is supported by DoDI 8500.2 IA control PRRB-1 discussed above.\n\nInspect the user guide regarding the proper use of PC based voice, video, UC, and collaboration communications applications. Validate that user\u2019s have been provided with this guide by interviewing a random sampling of users. The user\u2019s guide should minimally provide the information listed in the requirement.\n\nThis is a finding if the user guide is deficient in its content and/or the guide is not provided to users.\n",
"description": "User agreements must be accompanied with a combination of user training and user guides that will reiterate the agreed to policies and prohibitions. The training and guides should also provide additional information such as how to operate a system or device and implement certain features and IA measures as required. \n\nA user guide would be extremely helpful in providing information to the user for the proper usage of PC based voice, video, UC, and collaboration communications applications and remote access implementations in general. An item that must not be forgotten in such a user guide is a discussion relating to the use of a PC based voice, video, UC, and collaboration communications applications for assured service C2 communications. Cautions and notice of the potential unreliable nature of these communications applications or methods must be included in user guides so that C2 users are aware, and reminded of, the non-assured service nature of these communications methods. \n\nThere are other topics that should be contained in a user guide serving this purpose. One such topic is the use of a \u201cwebcam\u201d with hardware or software based VTU, particularly when used in a classified environment. Another user guide topic is the possible use of speakerphone capabilities when using a hard or soft EI in environments where classified discussion or work occurs.\n",
"fixid": "F-16196r1_fix",
"fixtext": "Ensure a user guide is developed and distributed to users of PC based voice, video, UC, and collaboration communications applications.\n\nDevelop a users guide regarding the proper use of PC based voice, video, UC, and collaboration communications applications and distribute to users. \n\nThe user\u2019s guide should minimally provide the following information:\n- Reiterates the policies and restrictions agreed to when the user agreement was signed upon receiving the communications application.\n- Provides cautions and notice of the potential unreliable nature of PC communications applications so that C2 users are aware and reminded of the non-assured service nature of this communications media/method.\n- Provides instruction regarding the proper and safe use of webcams in general, and more specifically when used in a classified environment or where classified work is performed and/or classified material/information is displayed or used.\n- Provides instruction regarding the proper and safe use of speakerphone capabilities in general, and more specifically when using them in environments where classified discussion or work occurs. \n- Provides instruction regarding the proper and safe use of presentation, document, and desktop sharing.\nNOTE: this requirement is supported by DoDI 8500.2 IA control PRRB-1.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1",
"PRTN-1"
],
"id": "V-16091",
"ruleID": "SV-17079r1_rule",
"severity": "low",
"title": "Deficient or Non-Existent user guide regarding the proper use of PC based voice, video, UC, and collaboration communications applications.",
"version": "VVoIP 1330 (GENERAL)"
},
"V-16094": {
"checkid": "C-17138r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nIn the event PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in the user\u2019s workspace, the IAO will ensure hardware based telephone instruments, are installed within a short distance (e.g., 30 to 50 feet) of every workspace to be used for backup and emergency communications. \n\nDetermine if PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in user\u2019s workspaces. If so, inspect users work areas to determine if hardware based telephone instruments, are installed within a short distance (e.g., 30 to 50 feet) of every workspace to be used for backup and emergency communications. Cell phones, PDA/PEDs, or other wireless devices are not considered reliable enough to meet this requirement due to lack of reliable signal available everywhere and their inability to be used in certain DoD environments. This is a finding if these conditions are not met. \n\nNOTE: This requirement is satisfied by the implementation of hardwired hardware based telephone instruments using any telephony technology. That is, traditional analog, or digital instruments may be used or VoIP based instruments may be used. Such instruments may be part of the local site\u2019s PBX or VoIP system, or may be served from the Local Exchange Carrier (LEC) or Competitive LEC (CLEC). Of additional concern when implementing backup/COOP or emergency telephones is power. Such phones should be remotely powered from a source that can provide backup power. Additionally, the dialing capabilities of backup/COOP or emergency may be limited to internal and/or emergency calls. This means that minimally, emergency services numbers must be reachable from these phones. \n\nPART2 manual\nMinimally select a random sample if not all of the implemented hard-phones and test them to ensure they are functional. This is a finding if non functional phones are found.\n\n",
"description": "This and several other requirements discuss the implementation of PC soft-phones or UC applications as the primary and only communications device in the user\u2019s workspace. While this degrades the protections afforded a hardware based system, the trend is to use more and more PC based communications applications due to their advanced features, collaborative benefits, and perceived reduced cost. This soft-phone use case results in the elimination of hardware based telephones on user\u2019s desks in the workplace. This can be seen as, or result in, trading down (from a hardware based system) with regard to availability, reliability, and quality of service since the data network is generally more susceptible to compromise from many sources inside and outside the local LAN making the soft-phones more exposed to attack. This also means that there will be no telephone available in the workspace if the PC is not powered on, or the application is not loaded, or the PC is not fully functional. While this is undesirable from an IA standpoint, a business case can be developed to support it. NOTE: The recommended relationship between PC soft-phone/UC applications and hardware based endpoints in the normal work area is that the PC application should augment the functionality of, or be a backup to, the hardware based instrument in the user\u2019s workspace. The implementation of PC soft-phones or UC applications in the user work space as their only endpoint has several ramifications that must be considered. The following is a list of some of these: \u2022 The PC becomes a single point of failure for communications services provided to a user in their workspace. A widespread problem, which affects many PCs or the network infrastructure, may disable all communications for many users at one time. Users may not even have a means to report the failure without using an alternate communications system. A fast spreading worm or power outage could create such a situation. While some may argue that \u201cusers can call on their cell phones\u201d, service may not be available or their use may not be permitted in the facility. This translates into the following: - The loss of functionality and efficiency as in lost time due to the inability to communicate when the PC or soft-phone application is not running or functioning properly. \u2022 The protections afforded hardware based endpoints by the use of the voice protection zone such as VoIP VLAN(s), and others are missing for soft-phones in a widespread use/implementation scenario and, depending on the implementation on the PC, may degrade the protections afforded hardware based endpoints. Such is the case for all software based communications endpoints since they are typically implemented on all PCs and therefore will be connected to the data VLANs. Assured service for voice traffic will be degraded from that obtained with hardware based instruments connected in the voice protection zone. This translates into the following additional IA measures required to protect the VoIP infrastructure (e.g., a firewall between the VoIP and data VLANs). \u2022 The hardware based endpoint is not available for use in parallel with, or in place of, the PC. This can be a problem if the PC is having performance or operational issues, is turned off, or is unavailable. Accessing help desk services requiring logging onto the PC to use the voice services and work on a problem could be a real challenge. Rebooting the PC to clear a problem would disconnect the call to the helpdesk. Accessing voice mail or answering the phone while the PC is booting is made impossible reducing efficiency, particularly when the user starts their day. If the user has C2 responsibilities, the IP equivalent of MLPP cannot function properly if application or PC is unavailable. Precedence calls will not be received by the user but will be transferred to their designated alternate answering point. \u2022 Emergency communications could be unavailable if the PC is not booted, the communications application is not running, or either is otherwise compromised. Voice communications must be readily available for life safety and medical reasons, as well as other facility security emergencies. A partial mitigation for this in a \u201csoft-phone world\u201d is to place common use hardware telephones within a short distance (e.g., 30 to 50 feet) of every workspace which is an additional cost. This additional distance however, could be an issue in a medical emergency where a worker might be alone in their workspace and their PC or voice communications application not functioning properly, they may not be able to reach the common use instrument depending upon the nature of the medical emergency. If the worker was suffering a heart attack or diabetic emergency, they could die. Business cases therefore need to include the cost of insurance and/or law suites for this eventuality. \u2022 The previous 2 items translate into the following: - The addition of common use hardware based instruments placed around the facility (for backup and emergency usage) along with the additionally required LAN cabling and access switch ports. While some may feel that this is not an IA issue, in reality it is since the discussion is truly about availability, which is one of the prime tenets of IA. Additionally, the VoIP controllers (i.e., the equipment that controls the telephone system) must be able to be accessed by the PC soft-phones while being protected as they would be in a normal VoIP system using hardware based instruments. NOTE: Methods for permitting the necessary PC traffic to, from, and between the voice and data zones while protecting the voice zone will be discussed later in this document. \n\n",
"fixid": "F-16199r1_fix",
"fixtext": "In the event PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in the user\u2019s workspace, the IAO will ensure hardware based telephone instruments, are installed within a short distance (e.g., 30 to 50 feet) of every workspace to be used for backup and emergency communications.\n\nNOTE: This requirement is satisfied by the implementation of hardwired hardware based telephone instruments using any telephony technology. That is, traditional analog, or digital instruments may be used or VoIP based instruments may be used. Such instruments may be part of the local site\u2019s PBX or VoIP system, or may be served from the Local Exchange Carrier (LEC) or Competitive LEC (CLEC). Of additional concern when implementing backup/COOP or emergency telephones is power. Such phones should be remotely powered from a source that can provide backup power. Additionally, the dialing capabilities of backup/COOP or emergency may be limited to internal and/or emergency calls. This means that minimally, emergency services numbers must be reachable from these phones. \n\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16094",
"ruleID": "SV-17082r1_rule",
"severity": "medium",
"title": "Deficient support for COOP or emergency and life safety communications when soft-phones are implemented as the primary voice endpoint in user\u2019s workspace caused by deficient placement of physical hardware based phones near all such workspaces.",
"version": "VVoIP 1920 (GENERAL)"
},
"V-16095": {
"checkid": "C-17139r1_chk",
"checktext": "In the event PC soft-phones and/or UC applications are implemented as the primary telephone endpoint in the user\u2019s workspace. That is, there is no PC independent telephone. Interview the IAO to validate compliance with the following requirement:\n\nEnsure the command structure as well as the DAA approves the implementation or transition in writing. Approval documentation will be maintained by the IAO for inspection by IA reviewers or auditors.\n\nReview written DAA and Command approval for the implementation of a telephone system which primarily uses PC software applications for its endpoints. \n\nThis is a finding if such approvals are not provided.\n",
"description": "The Designated Approving Authority (DAA) responsible for the implementation of a telephone system which primarily uses PC software applications for its endpoints must be made aware of the risks of operating such as system as well as the benefits. This is because the DAA must personally accept the risk of operating the system. In addition, the commander of an organization whose mission depends upon such a telephone system must also be made aware and provide their approval.",
"fixid": "F-16200r1_fix",
"fixtext": "Ensure the command structure as well as the DAA approves the implementation or transition in writing. Approval documentation will be maintained by the IAO for inspection by IA reviewers or auditors.\n\nObtain the required written DAA and Command approval for the implementation of a telephone system which primarily uses PC software applications for its endpoints or install a hardware based wired telephone system.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16095",
"ruleID": "SV-17083r1_rule",
"severity": "medium",
"title": "No command or DAA approval exists for implementing soft-phones as the primary voice endpoint.",
"version": "VVoIP 1110 (GENERAL)"
},
"V-16096": {
"checkid": "C-17140r1_chk",
"checktext": "In the event that limited numbers of PC soft-phones are implemented in the strategic LAN, Interview the IAO to validate compliance with the following requirement:\n\nEnsure the responsible DAA approves the use of PC soft-phones in the strategic LAN along with the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure. Approval will be provided in writing and will be maintained by the IAO for inspection by IA reviewers or auditors.\n\nIf limited numbers of PC soft-phones associated with the local VoIP system are to be implemented in the strategic LAN, a separate protection zone or VLAN structure must be implemented for them. The purpose of this VLAN is to provide a means whereby the PC can access the services it requires in both the data and VoIP VLANs while protecting the VoIP infrastructure and enhancing soft-phone reliability, performance, and security. Implementation of such a VLAN must not provide an access path as in a bridge, between the VoIP and data VLANs. Traffic must be filtered such that the soft-phone\u2019s VoIP traffic is routed to the VoIP VLAN while all other traffic is routed to the data VLAN. This should happen at only one location such as a core router or firewall, however, the PC might be capable of this itself. \n\nNOTE: Limited numbers in this scenario means as few as possible, but may mean 25 or 30 percent of the overall PCs on the LAN. Beyond this percentage, the protections afforded by this implementation become limited or negated because of the large number of PCs in the soft-phone VLAN.\n\nNOTE: Methods for permitting the necessary PC traffic to, from, and between the voice and data zones while protecting the voice zone will be discussed next in this document.\n\nDetermine if limited numbers of PC soft-phones are permitted to operate or are implemented in the strategic LAN. If so, review the written DAA approval for the implementation/permission.\n\nThis is a finding in the event limited numbers of PC soft-phones are to be implemented in the strategic LAN and there is no written DAA approval for the implementation and the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure.\n",
"description": "This use case addresses situations whereby the soft-phone/UC application and PC is not the primary voice communications \u201cdevice\u201d in the work area. This means that there is a validated mission need and the number of PC soft-phones permitted to operate inside the LAN will be less than the number of hardware based phones in the LAN. This number should be limited to those soft-phones required to meet specific mission requirements. UC applications that are ubiquitous in the LAN are addressed later, however, typically these work in association with a hardware based phone system, not in place of it. There are three possible scenarios for the use of limited numbers of soft-phones in the strategic LAN. We will discuss the first two in this section and the third in the next section. The first of these scenarios is providing support for soft-phones associated with a VoIP system in another enclave. This is a remote access scenario and must operate as they would in a normal telework/remote access use case. We will discuss this use case later, however, if this scenario is approved, special accommodations must be made in the local LAN to support users from a remote LAN and permit them to connect to their home enclave. This could include segregating them on a separate dedicated LAN with its own boundary protection or by implementing a dedicated VLAN protection zone while opening the enclave boundary to permit the remote connection. \n\nNOTE: Approval for this scenario would also require approval for specific foreign (non-local) PC attachment to the local LAN. These topics are beyond the scope of this document. The second of these scenarios is providing support for soft-phones associated with a local VoIP system. It is preferred that PC soft-phones associated with the local VoIP system not be used in the LAN, at all, due to the difficulties they present to the protection of the local hardware based VoIP infrastructure. Under normal circumstances, due to the separation of the VoIP and data VLANs a PC soft-phone application (associated with the local VoIP system) should not be able to register with the VoIP controller and function when the PC is connected to the LAN. This is because the PC connects to a LAN access port assigned to the data VLAN(s) and traffic between the voice and data VLANs is blocked. Similarly, if the PC was to be connected to a LAN access port assigned to the VoIP VLAN(s), the soft-phone might work but the PC would not have its normal data connectivity or services. If PC soft-phones are to be used in the strategic LAN, except as noted in the section on discrete instrument replacement, their numbers should be limited to those that are essential to the mission and additional protections, as discussed later in this section, must be added to the LAN to maintain the protection of the VoIP infrastructure. Implementations of limited numbers of PC soft-phones along with the protections afforded them and the local VoIP infrastructure must be approved by the responsible DAA. \n",
"fixid": "F-16201r1_fix",
"fixtext": "Ensure the responsible DAA approves the use of PC soft-phones in the strategic LAN along with the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure. Approval will be provided in writing and will be maintained by the IAO for inspection by IA reviewers or auditors.\n\nIn the event that limited numbers of PC soft-phones are to be implemented in the strategic LAN, obtain written approval from the responsible DAA along with approval for the measures implemented to protect these soft-phones and the local VoIP and/or data infrastructure. Alternately remove the PC soft-phones and/or UC applications from the LAN.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16096",
"ruleID": "SV-17084r1_rule",
"severity": "medium",
"title": "No DAA approval for permitting limited numbers of soft-phones to operate in LAN.",
"version": "VVoIP 1720 (GENERAL)"
},
"V-16098": {
"checkid": "C-17142r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nIn the event a Call Center / CTI system/application (e.g., call center, helpdesk, operators console, E911 system, etc.) utilizing or incorporating PC based soft-phones are approved for use in the strategic LAN, ensure the following:\n- The supporting network is configured as a closed environment (enclave) or a segregated and access controlled sub-enclave having appropriate boundary protection between it and the local general business LAN or external WAN.\n- In the event the CTI application accesses resources outside this enclave and there is the potential of the application being compromised from external sources, the supporting network is configured to provide separate voice and data zones and maintains separation of voice and data traffic per the VoIP STIG if technically feasible (i.e., such separation does not break the CTI application or there is another compelling reason).\n- The supporting network enclave and boundary protection is configured in substantial compliance with the Enclave, Network Infrastructure, and VoIP STIGs.\n- The CTI application/enclave (e.g., a call center application) is supported by a dedicated VoIP controller.\n\nInspect network drawings and perform a scan from outside the CTI system enclave to determine what traffic is permitted to flow between the CTI system and external network or VLANs. \n\nThis is a finding in the event unnecessary traffic can pass.\n",
"description": "The third scenario in which limited numbers of PC soft-phones might be used in a strategic LAN is when they are associated with or are actually part of a Computer Telephony Integration (CTI) application. Traditional computer telephony integration CTI encompasses the control of a telephone or telecommunications switch by a computer application. Interfaces have been developed to provide connection between the computer, typically a workstation, and the telephone or other terminal attached to the telephone switch, and possibly a special analog or TDM line going directly to the telephone switch. Applications are also developed to make use of these interfaces to integrate a data application with the telephone system. Sometimes the integration is as simple as being able to dial a number from the computer application or it could provide full control of the switch as in the case of an operator\u2019s console. In these traditional scenarios, the voice stayed in a traditional telephone set and the data stayed on the computer with the exception of the control information. If the voice does enter the computer, it is sent directly to the sound card or converted to a sound file for storage and possible file transfer. The voice communication is not transmitted in real time via IP protocols. In contrast, modern day CTI is changing in that today the voice communications and control is being transmitted using IP protocols and the hardware interfaces and telephones are being replaced by computer applications. \n\nNOTE: the CTI systems discussed here are not unified communications applications although some of the features are similar. CTI systems generally have a special function and are not a general user application. These are typically Call Center or Help Desk applications. This type of CTI typically involves integration with a database application. In this scenario, where soft-phones are an integral part of the CTI system/application, implementation of separate voice and data zones could be detrimental to the proper functioning of the application. While separation requirements should be enforced if possible, they could be relaxed providing the general CTI requirement of treating the CTI system as an enclave is followed. A system such as this should have its own VoIP controller. If the system needs to communicate with systems outside the CTI system enclave, proper boundary protection must be provided. For example, since IP soft-phones are prevalent in today\u2019s call center / helpdesk systems, such a system would require the ability to place and receive phone calls from outside the CTI enclave. Calls might leave and enter the enclave via VoIP or a TDM media gateway. The workstations and call center agents may also need to email and access the web. \n\nNOTE: we have established that a network supporting a CTI application must be segregated from the enclave general business LAN and that this can be accomplished by maintaining a closed network or a segregated and access controlled sub-enclave having appropriate boundary protection. This is in support of DoDI 8500.2 IA control DCSP-1 regarding \u201cSecurity Design and Configuration / Security Support Structure Partitioning\u201d which states \u201cThe security support structure maintains separate execution domains as in address spaces, for each executing process by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions.\u201d \n",
"fixid": "F-16203r1_fix",
"fixtext": "In the event a Call Center / CTI system/application (e.g., call center, helpdesk, operators console, E911 system, etc.) utilizing or incorporating PC based soft-phones are approved for use in the strategic LAN, ensure the following:\n- The supporting network is configured as a closed environment (enclave) or a segregated and access controlled sub-enclave having appropriate boundary protection between it and the local general business LAN or external WAN.\n- In the event the CTI application accesses resources outside this enclave and there is the potential of the application being compromised from external sources, the supporting network is configured to provide separate voice and data zones and maintains separation of voice and data traffic per the VoIP STIG if technically feasible (i.e., such separation does not break the CTI application or there is another compelling reason).\n- The supporting network enclave and boundary protection is configured in substantial compliance with the Enclave, Network Infrastructure, and VoIP STIGs.\n- The CTI application/enclave (e.g., a call center application) is supported by a dedicated VoIP controller.\n\nImplement the proper Call Center / CTI system protection mechanisms segregating it into its own protected enclave and limit traffic into and out of this enclave.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16098",
"ruleID": "SV-17086r1_rule",
"severity": "medium",
"title": "Deficient protection for a Call Center (or CTI) system that uses soft-phones.",
"version": "VVoIP 1025 (GENERAL)"
},
"V-16099": {
"checkid": "C-17143r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure permanent, semi-permanent, or fixed (not highly mobile) tactical networks supporting IP based voice, video, unified, and/or collaboration communications are configured per the requirements for a strategic LAN supporting voice/video/UC services.\n\nDetermine if the tactical LAN is supporting a fixed or generally non-moving base making it a fixed tactical LAN. If the fixed tactical network supports IP based voice, video, UC, and/or collaboration communications, determine if it is configured per the requirements for a strategic LAN. Inspect network diagrams and interview the IAO to determine compliance. \n\nThis is a finding in the event the deployed tactical network is relatively permanent compared to a small highly mobile unit and the LAN is not configured as a strategic LAN for the support of supports IP based voice, video, UC, and/or collaboration communications as defined in this and other STIGs.\n\nNOTE: The factors determining whether a deployed tactical VVoIP system is subject to this requirement are varied. In general all VVoIP systems should be configured the same and such that the service and supporting infrastructure is protected. It is recognized that a small system operated out of a transit case in a tent, conex box, or a truck is highly mobile as opposed to a fixed installation in a building. While initially such a system can support a few users and remain highly mobile, as the number of users increases, the deployment becomes semi-permanent, or fixed (not highly mobile). Initial deployments may include as little as a half dozen workstations or as many as fifty. Once the initial deployment is in place, the network may grow and become relatively permanent as would be the case for a rear command or logistics center. Small deployable packages that are designed to be initially deployed with a small footprint supporting or using PC soft-phones, which are then to be the basis of a larger network, must be configured, or be configurable, to support the separate VoIP and data zones as well as hardware based instruments and admission control for C2 communications as the deployed network and supported systems grow. The network will also include soft-phone protection zones as required in a strategic network if soft-phones are permitted to be used beyond the initial deployment. \nNOTE: A shipboard LAN is minimally considered as a fixed tactical LAN but can also be considered as a Strategic LAN. This is because the installation is permanent within the confines of the mobile floating base.\n",
"description": "The primary reason for the implementation of the LAN architecture and security measures defined in this and other STIGs is to improve the survivability (availability) of the VVoIP communications service in whatever environment it is deployed. These measures are designed to protect the VVoIP service and infrastructure to the greatest extent possible in the event there is a compromise of an OS or application on a workstation or server attached to the data side of the LAN. If this occurs, the compromised platform could be used by an adversary to compromise the VVoIP communications or its supporting infrastructure. Such compromise can happen rather easily, particularly when a server is a web or application server or a workstation is used for web surfing or email. A secondary reason for the implementation of the LAN architecture and security measures defined is to help protect the confidentiality and integrity of the supported VVoIP communications. Based on these two reasons, the defined VVoIP architecture serves to segregate and hide the VVoIP communications and infrastructure (to the greatest extent possible on a converged LAN) from the data workstation users and associated platforms. While VVoIP systems deployed on a strategic B/C/P/S provide a combination of general business or administrative communications along with C2 communications, tactical deployments primarily support C2 communications. There is nowhere other than a tactical deployment that the availability, confidentiality, and integrity of a VVoIP communications service is as critical. Therefore the network supporting a tactical VVoIP communications system must follow the same guidelines as a network supporting a strategic VVoIP system or application. \n\nNOTE: Initial deployments may include as little as a half dozen workstations or as many as fifty. Once the initial deployment is in place, the network may grow and become relatively permanent as would be the case for a rear command or logistics center. \nNOTE: A shipboard LAN is minimally considered as a fixed tactical LAN but can also be considered as a Strategic LAN. This is because the installation is permanent within the confines of the mobile floating base. In other words, the base (AKA ship) moves without disrupting the LAN.\n",
"fixid": "F-16204r1_fix",
"fixtext": "Ensure permanent, semi-permanent, or fixed (not highly mobile) tactical networks supporting IP based voice, video, unified, and/or collaboration communications are configured per the requirements for a strategic LAN.\n\nConfigure the fixed tactical LAN in accordance with the requirements for a strategic LAN that supports IP based voice, video, UC, and/or collaboration communications.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16099",
"ruleID": "SV-17087r1_rule",
"severity": "medium",
"title": "The architecture and/or configuration of a permanent, semi-permanent, or fixed (not highly mobile) tactical LAN supporting IP based voice, video, unified, and/or collaboration communications is not adequate to protect the VVoIP services and infrastructure.",
"version": "VVoIP 1925 (GENERAL)"
},
"V-16101": {
"checkid": "C-17144r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nIn the event voice/video/UC IA configuration measures are reduced for highly mobile tactical networks (e.g., initial deployment packages) supporting hardware or PC based voice, video, unified, and/or collaboration communications, the IAO will ensure a benefit vs. risk analysis is performed, documented, and approved in the certification and accreditation of the system.\n\nNOTE: It is recognized that deployable packages for highly mobile tactical networks may only support PC based voice, video, UC, and/or collaboration communications applications. Such a network may not require separate zones for voice and data since all traffic will be in the data zone.\n\nDetermine if IA configuration measures are reduced for highly mobile tactical networks (e.g., initial deployment packages) supporting hardware or PC based voice, video, UC, and/or collaboration communications. If so, inspect network diagrams and device configurations to determine the IA measures implemented. If the implemented IA measures are reduced from those required in a strategic or fixed tactical LAN, inspect the documented benefit vs. risk analysis used in the C&A process for the system.\n\nThis is a finding if there is no benefit vs. risk analysis, or it is found to be deficient in some manner, such that the appropriate risk level was not used in the C&A of the system.\n",
"description": "As discussed above, the network supporting a tactical VVoIP communications system must follow the same guidelines as a network supporting a strategic VVoIP system or application to help ensure the availability, confidentiality, and integrity of the communications service.\n\nAn argument could be made that a tactical LAN and attached workstations might be less prone to compromise than a strategic LAN and its attached workstations therefore we do not need all these security measures for VoIP. This argument might be supported by the smaller size of a tactical LAN, particularly an initially deployed system, mission duration, and the ability to limit its usage to tactical applications. Unfortunately if the tactical LAN is connected to NIPRNet or the strategic LAN at the home base, it can still be compromised particularly if general web browsing is permitted and performed and email is used. Additionally, there is nowhere that C2 communications is more important than in the tactical LAN. Any decision to eliminate any of the protective measures for the C2 voice service that could negatively impact its reliability must be based in a risk assessment that weighs the benefits against the risks. Deployable packages that are designed to be initially deployed with a small footprint supporting or using PC soft-phones, which are then to be the basis of a larger network, must be configured, or be configurable, to support the separate VoIP and data zones as well as hardware based instruments and admission control for C2 communications as the deployed network and supported systems grow. The network will also include soft-phone protection zones as required in a strategic network if soft-phones are permitted to be used beyond the initial deployment. In general, larger relatively permanent tactical networks should be configured the same as a strategic network since similar vulnerabilities exist. \n\nAs a result, if IA measures are to be relaxed for a highly mobile tactical network or deployable package, the reduction must be supported by an approved benefit vs. risk analysis. Approval must be given by the person or entity responsible for accepting the risk of operating the VVoIP system in a vulnerable manner.\n\nNOTE: This requirement does not apply to shipboard LANs since they are permanently installed.\n",
"fixid": "F-16205r1_fix",
"fixtext": "In the event voice/video/UC IA configuration measures are reduced for highly mobile tactical networks (e.g., initial deployment packages) supporting hardware or PC based voice, video, unified, and/or collaboration communications, perform and document a benefit vs. risk analysis for the reduced IA measures and update the C&A for the system.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16101",
"ruleID": "SV-17089r1_rule",
"severity": "medium",
"title": "Deficient benefit vs. risk analysis and/or approval for reduced VVoIP IA configuration measures in highly mobile tactical LANs and systems supporting hardware or PC based voice, video, unified, and/or collaboration communications.",
"version": "VVoIP 1930 (GENERAL)"
},
"V-16106": {
"checkid": "C-17150r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC communications applications are certified and accredited in association with, or as part of, their supporting communications system or service.\n\nInspect the C&A documentation of the communications system or service supporting a PC communications application. Look for the inclusion and IA of the PC communications application. If not included, this is a finding.\n",
"description": "Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. Since a PC VVoIP communications application is typically supported by a larger VVoIP communications system, the security of the application will affect the security of the overall system. Therefore the C&A documentation for the PC application must be included in the C&A documentation for the overall VVoIP system. Subsequently the VVoIP system\u2019s C&A documentation must be included in the C&A documentation for the LAN/enclave. DoDI 8500.2 IA control DCCT-1 under \u201cSecurity Design and Configuration / Compliance Testing\u201d states \u201cA comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.\u201d This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. ",
"fixid": "F-16211r1_fix",
"fixtext": "Ensure PC communications applications are certified and accredited in association with, or as part of, their supporting communications system or service.\n\nInclude PC communications applications in the C&A of the supporting communications system or service. If PC communications applications are added after the supporting system is accredited, modify the system C&A documentation and update the \u201capprovals to operate\u201d (ATO) to include the added PC communications applications.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16106",
"ruleID": "SV-17094r1_rule",
"severity": "medium",
"title": "PC communications application C&A documentation is not included in the C&A documentation for the supporting VVoIP system .",
"version": "VVoIP 1105 (GENERAL)"
},
"V-16107": {
"checkid": "C-17151r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC communications applications are tested and approved prior to implementation.\n\nDetermine if implemented PC communications applications were tested and approved prior to implementation. Review documentation relating to the testing and approval of the PC communications application(s) that are implemented. This is a finding if it is determined that PC communications applications were NOT tested and approved prior to implementation.\n",
"description": "Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. DoDI 8500.2 IA control DCCT-1 under \u201cSecurity Design and Configuration / Compliance Testing\u201d states \u201cA comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.\u201d This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. ",
"fixid": "F-16212r1_fix",
"fixtext": "Ensure PC communications applications are tested and approved prior to implementation.\n\nTest PC communications applications for IA concerns and seek approval for their use prior to implementation. Document the testing and approval of PC communications application(s) before they are implemented. Maintain this documentation for auditors / inspectors.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16107",
"ruleID": "SV-17095r1_rule",
"severity": "medium",
"title": "Deficient PC communications application testing prior to implementation.",
"version": "VVoIP 1125 (GENERAL)"
},
"V-16108": {
"checkid": "C-17221r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure upgrades and patches to communications systems supporting PC communications applications are tested and approved prior to implementation.\n\nDetermine if upgrades and patches to communications systems supporting PC communications applications and PC communications applications are tested and approved prior to implementation. Review documentation relating to the testing of the patch or upgrade to the PC communications system and application(s) as verification. This is a finding if it is determined that upgrades and patches to systems supporting PC communications applications and/or the applications themselves were NOT tested and approved prior to implementation.\n",
"description": "Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. DoDI 8500.2 IA control DCCT-1 under \u201cSecurity Design and Configuration / Compliance Testing\u201d states \u201cA comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.\u201d This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. ",
"fixid": "F-16214r1_fix",
"fixtext": "Ensure upgrades and patches to communications systems supporting PC communications applications are tested and approved prior to implementation.\n\nTest upgrades and patches to PC communications systems and applications for IA concerns and seek approval for their use prior to implementation. Document the testing and approval of the patch or upgrade to the PC communications system or application(s) before implementation. Maintain this documentation for auditors/inspectors.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16108",
"ruleID": "SV-17096r1_rule",
"severity": "medium",
"title": "Deficient testing or approval of PC communications application patches or upgrades.",
"version": "VVoIP 1130 (GENERAL)"
},
"V-16109": {
"checkid": "C-17153r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC communications applications providing voice, data, or video communications interoperability with the DSN, DRSN/VoSIP, or PSTN, along with any associated accessories (e.g., USB phones, cameras, and USB ATAs), are interoperability and IA tested and placed on the Approved Products List (APL) prior to purchase, per DoDI 8100.3.\n\nNOTE : APL listing of soft-phone applications, and/or associated accessories, will be in association with, or part of, the listed VoIP telecommunications switch/system that supports the application. Other applications (VTC or collaboration) will be listed with their core service or system.\n\nNOTE: This is not a finding in the event a PC communications application implementation and/or supporting system is not associated with, interoperable with, or connected to DSN, DRSN/VoSIP, or PSTN and is never expected to be.\n\nNOTE: The DRSN is a custom and proprietary non-VoIP telephone system. It interoperates, to a degree, with a Defense Information System Network (DISN) VoIP telephone system/service on the Secret Internet Protocol Router Network (SIPRNet). This VoIP service is called VoSIP (see acronym discussion in the next note). The discussion/requirement here applies to PC communications application associated with VoSIP that ultimately can interoperate with DRSN endpoints. \n\nNOTE: NSA defines VoSIP as Voice over Secure IP or regular (un-encrypted or encrypted) VoIP over any secure or classified IP LAN (i.e., local C-LAN) or WAN (e.g., SIPRNet or JWICS). In general, VoSIP employs encryption at Layer 1/Layer 2 applied to links between un-encrypted classified enclaves. The use of the acronym VoSIP for the DISN service and for instantiations on DoD component\u2019s classified LANs leads to confusion between the service and the intentional meaning of the acronym. NSA defines a similar acronym, SVoIP, meaning Secure VoIP. This refers to end-to-end NSA type-1 encrypted VoIP media and possibly signaling streams that can traverse a network having a lower classification. This is similar in concept to the secure voice service provided by a STU or STE as well as SCIP based devices. SCIP works at Layer 7 (application layer) and can use Type 1 or Type 3 encryption. It is not IP specific since it was developed for traditional fixed and mobile transport methods. Type 3 encryption of VoIP signaling and media is not SCIP. Unfortunately, the SVoIP acronym/term has also been corrupted by some organizations using it to refer to their implementation of VoIP on their classified LANs and the SIPRNet WAN.\n\nInspect the APL testing report for the APL approved VoIP system supporting the PC communications application to determine if it was tested and approved along with the supporting communications system. \n\nNOTE: these applications are typically NOT listed separately on the APL. APL testing reports are available to DoD users of the product and reviewers via email from the Unified Capabilities Certification Office (UCCO) at ucco@disa.mil. It is highly recommended that requests for these reports are submitted and the report obtained before SRR trips commence. This is a finding if it is determined that the PC communications application was not tested and approved along with the supporting communications system.\n",
"description": "DoDI 8100.3 provides policy for the DoD that requires the testing and certification of telecommunications systems for Interoperability and Information Assurance (IA) while establishing an Approved Products List (APL) for certified and accredited products. Under Applicability and Scope, it states \u201cThis Instruction applies to the hardware or software for sending and receiving voice, data, or video signals across a network that provides customer voice, data, or video equipment access to the DSN, DRSN or PSTN.\u201d Additional statements in this section expand this to most devices or systems that are associated with providing telecommunications service. \n\nThe purpose of this testing is twofold. One aspect is to determine if a vendor\u2019s product or system meets DoD functional requirements and that it can interoperate with established or existing DoD systems. The other aspect is to determine if the system can be configured to meet DoD IA requirements and operate at an acceptable level of risk. A product must be approved under both categories before listing on the APL. \n\nDoD components are required to fulfill their communications needs by only purchasing APL listed products, providing one of the listed products meets their needs. This means the APL must be consulted prior to purchasing a system or product. If no listed product meets the organization\u2019s needs, they may sponsor a product for testing that does meet their needs. \n\nNOTE: The APL as created by this instruction was originally called the DSN APL and covered dial-up telecommunications systems or products providing unclassified communications. It has been expanded to cover additional types of approved products and has been renamed to the Unified Capabilities APL by the Office of the Assistant Secretary of Defense (OASD) for Networks and Information Integration (NII). Additional categories have been implemented for DRSN (classified communications) related systems/products and for IPv6 capable products. The APL can be found at http://jitc.fhu.disa.mil/apl/index.html. This APL is referred to as the DoD APL or UC APL. \n\nTactical use cases or systems that do not provide access to the DSN, DRSN or PSTN which are private closed communications systems, may be accredited via the Information Support Plan (ISP) or Tailored Information Support Plan (TISP) process managed by the Office of the Secretary of Defense (OSD), Joint Staff J6I, and the Joint Interoperability Test Command (JITC) United States (US) Military Communications Electronics Board (USMCEB) Interoperability Test Panel (ITP). \n\nThis policy applies directly to any PC communications application that provides voice communications services to and/or from the DSN, DRSN/VoSIP, or PSTN. This will most often be a soft-phone or unified communications application (with any associated accessories) that is associated with or supported by a DoD telephone system. The application may, or may not, provide additional communications services such as video, collaboration, or other unified communications services. This policy is extensible to other types of PC communications applications whose primary purpose may be VTC, IM, or collaboration, if the application or service provides interoperability with the DSN, DRSN/VoSIP, or PSTN typically through a gateway, or uses these systems for transport.\n",
"fixid": "F-16215r1_fix",
"fixtext": "Ensure PC communications applications providing voice, data, or video communications interoperability with the DSN, DRSN/VoSIP, or PSTN, along with any associated accessories (e.g., USB phones, cameras, and USB ATAs), are interoperability and IA tested and placed on the Approved Products List (APL) prior to purchase, per DoDI 8100.3.\n\nOnly implement APL tested PC communications applications. If necessary contact the Unified Capabilities Certification Office (UCCO) to determine what course of action and testing submittals should be pursued.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16109",
"ruleID": "SV-17097r1_rule",
"severity": "medium",
"title": "A PC Communications Application is not tested for IA and Interoperability and are not listed on the DoD UC APL.",
"version": "VVoIP 1120 (GENERAL)"
},
"V-16111": {
"checkid": "C-17155r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and can provide support for the application to resolve operational and IA issues for DoD implementations.\n\nNOTE: The following are applicable sources:\n- Soft-phone and/or UC applications providing voice telephone services source from the enclave\u2019s voice (VoIP) system vendor (or their approved partner).\n- Soft-VTC applications source from the enclave\u2019s or program\u2019s VTC system vendor (or their approved partner).\n- Collaboration applications source from the enclave\u2019s or program\u2019s Collaboration system/service vendor (or their approved partner).\n- The PC\u2019s operating system vendor (e.g., Microsoft) providing the application is approved to interoperate with the primary systems above. \n- An AIS program that has sourced the application from an appropriate source and provided the necessary testing, certification, and accreditation.\n\nDetermine the source of the PC voice, video, UC, and collaboration communications applications that are installed or are in use. \n\nDetermine if freeware or shareware PC voice, video, UC, or collaboration communications applications are in use. Examples are applications from yahoo, MSN, Google, Skype and other third party applications downloadable from the internet via freeware and shareware distribution web sites. \n\nInspect a random sample of PCs to determine what PC voice, video, UC, or collaboration communications applications are installed.\n\nThis is a finding if the PC voice, video, UC, or collaboration communications applications are either freeware / shareware, or are not sourced from the original manufacturer of the supporting voice, video, UC, and collaboration system. \n\nThe only PC voice, video, UC, or collaboration communications applications that should be used are those licensed products from major communications system vendors such as Cisco, Nortel, Avaya, Polycom, Tandberg, and so on, for which a clear support path is defined.\n\nThis is to ensure PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and that support for the application can be provided to resolve operational and IA issues for DoD.\n\nNOTE: this is NOT a finding in the event the applications in question are shareware/freeware or are sourced from a third party other than a major communications system vendor AND they are necessary for mission accomplishment; there are no alternative IT solutions available; and the product has been assessed for information assurance impacts, and approved for use by the DAA in writing. If this is the case, inspect the DAA approval documentation to validate.\n",
"description": "Another one of the measures in our defense in depth strategy to protect our PC based voice, video, UC, and collaboration applications is to ensure the application originates from a reputable source. The source of these applications can vary depending upon the type of application. To protect DoD interests, the source of the application depends on the criticality of the communications method. One source of possible compromise of a communications application is the use of freeware or shareware applications. This issue is covered in DoDI 8500.2 IA control DCPD-1 regarding \u201cSecurity Design and Configuration / Public Domain Software Controls\u201d which states \u201cBinary or machine executable public domain software products and other software products with limited or no warranty such as those commonly known as freeware or shareware are not used in DoD information systems unless they are necessary for mission accomplishment and there are no alternative IT solutions available. Such products are assessed for information assurance impacts, and approved for use by the DAA. The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the Government.\u201d Communications applications that primarily provide voice communications such as a soft-phone need to be designed to properly interoperate directly with the hardware based voice (VoIP) communications system. These applications should be a standard product of the voice system vendor or a partner whose product is approved by this vendor. The voice system is the most critical of all of the communications systems discussed in this document. \n\nCommunications applications that primarily provide VTC \u2018like\u2019 communications can come from several sources. Some soft-phone applications provide VTC and collaboration features and should be sourced from the voice system vendor as noted previously. Applications that primarily provide VTC features and need to interoperate directly with a hardware based VTC system should be sourced from the VTC system\u2019s vendor or a partner whose product is approved by this vendor. Communications applications that primarily provide collaboration services while also providing voice and video communications features must also be sourced from a major vendor in the business of providing collaboration systems or services. Unified communications applications that provide multiple services such as IM, presence, voice, VTC, web conferencing, and so forth, may also be a product of the PC\u2019s operating system vendor as with Microsoft\u2019s Office Communications applications. Application sourcing can also be dependant upon whether the application is to interoperate with a hardware based communications system located and operated within an enclave or whether it is a system operated by an interagency or inter-base program. This requirement is based on the fact that DoD components are required to use software and applications that are supported by a vendor that can maintain the security and integrity of the software or application. The vendor must be able to provide patches, upgrades or both to mitigate newly discovered vulnerabilities found in their product in a timely manner. \n",
"fixid": "F-16217r1_fix",
"fixtext": "Ensure PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and can provide support for the application to resolve operational and IA issues for DoD implementations.\n\nObtain PC voice, video, UC, and collaboration communications applications are obtained from an approved reputable source such that the integrity of the application along with its interoperability and security is assured and that can provide support for the application to resolve operational and IA issues for DoD implementations.\nNOTE: The following are applicable sources:\n- Soft-phone and/or UC applications providing voice telephone services source from the enclave\u2019s voice (VoIP) system vendor (or their approved partner).\n- Soft-VTC applications source from the enclave\u2019s or program\u2019s VTC system vendor (or their approved partner).\n- Collaboration applications source from the enclave\u2019s or program\u2019s Collaboration system/service vendor (or their approved partner).\n- The PC\u2019s operating system vendor (e.g., Microsoft) providing the application is approved to interoperate with the primary systems above. \n- An AIS program that has sourced the application from an appropriate source and provided the necessary testing, certification, and accreditation.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16111",
"ruleID": "SV-17099r1_rule",
"severity": "medium",
"title": "Deficient PC Communications Application integrity or supportability.",
"version": "VVoIP 1705 (GENERAL)"
},
"V-16112": {
"checkid": "C-17156r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC voice, video, UC, or collaboration communications applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation.\n\nDetermine if PC voice, video, UC, or collaboration communications applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Have the IAO or SA demonstrate the application and upgrade/patch integrity validation process. This is a finding if digital signatures are not validated before installation.\n",
"description": "It is important that the PC Communications application is not modified during its delivery and installation. This can be a problem if the application is obtained from a source other than directly from it\u2019s original developing vendor such as a third party download service. Any application that is not obtained from its original developing vendor could be modified to add some sort of malicious code that could affect the confidentiality, integrity, and availability of the communications supported by the application. Malicious code could also affect the platform on which the application is operated, the network to which the platform is attached, and the communications system with which the application operates. To mitigate this issue, it is highly recommended that vendors provide their applications in a digitally signed and hashed format such that the integrity of the application can be verified.",
"fixid": "F-16218r1_fix",
"fixtext": "Ensure PC voice, video, UC, or collaboration communications applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation.\n\nEmploy only those PC voice, video, UC, or collaboration communications applications, upgrades, and patches that are digitally signed by the vendor. Perform the appropriate digital signature validation process to validate application and upgrade/patch integrity before installation.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16112",
"ruleID": "SV-17100r1_rule",
"severity": "medium",
"title": "The integrity of a PC Communications Application, upgrade, or patch is not validated via digital signature before installation.",
"version": "VVoIP 1710 (GENERAL)"
},
"V-16113": {
"checkid": "C-17157r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC voice, video, UC, and/or collaboration communications applications are maintained at the current/latest approved patch or version/upgrade level.\n\nDetermine if PC voice, video, UC, and/or collaboration communications applications are maintained at the current/latest approved patch or version/upgrade level. Consult with the vendor or their web site to determine if the version that is in use is the latest version that contains the latest IA mitigations. Determine if this version is the latest approved version. \n",
"description": "Managing, mitigating, or eliminating a newly discovered vulnerably in a communications application is just as important as managing and mitigating the vulnerabilities of the platform supporting the application. PC communications applications must be patched or upgraded when a security related patch or upgrade is released by the vendor. While many vendors will release a patch to mitigate a vulnerability in an operating system or major application, other vendors will include the fix in a new version of the application. Multiple patches can also be rolled up into an upgrade. It is important to maintain the current patch and upgrade level of any communications applications installed on a PC. The purpose of this is to maintain the highest possible level of security for the application and the communications service(s) it provides.",
"fixid": "F-16219r1_fix",
"fixtext": "Ensure PC voice, video, UC, and/or collaboration communications applications are maintained at the current/latest approved patch or version/upgrade level.\n\nImplement the current/latest approved patch or version/upgrade level to utilize the latest IA mitigations. If an outdated application version is no longer in use, un-install it. If the latest version is not approved, submit it for testing and approval to ensure the latest IA mitigations are available and used.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16113",
"ruleID": "SV-17101r1_rule",
"severity": "medium",
"title": "A PC communications application is not maintained at the current/latest approved patch or version/upgrade level.",
"version": "VVoIP 1700 (GENERAL)"
},
"V-16114": {
"checkid": "C-17158r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\nEnsure PC voice, video, UC, or collaboration communications applications do not require and/or are not configured to operate with administrative privileges.\n\nDetermine if the installed PC voice, video, UC, or collaboration communications application(s) requires and/or is configured to operate with administrative privileges. Inspect a random sampling of PC voice, video, UC, or collaboration communications applications to determine if they are configured to operate with administrative privileges. This is a finding if a PC voice, video, UC, or collaboration communications application requires with administrative privileges to operate or if the application or platform is configured such that the application runs with administrative privileges. Even though a user has administrative privileges, the application should not inherit those privileges and should operate without them.\n",
"description": "PC voice, video, UC, and collaboration communications applications must not be operated in a manner that can compromise the platform if the application itself becomes compromised. One way to mitigate this possibility is to ensure that the application does not require administrative privileges to operate and that it is not operated with privileges that could be used to compromise the platform, other applications, or the network.",
"fixid": "F-16220r1_fix",
"fixtext": "Ensure PC voice, video, UC, or collaboration communications applications do not require and/or are not configured to operate with administrative privileges.\n\nConfigure the application and/or platform to not operate with administrative privileges or un-install it. Even though a user has administrative privileges, the application should not inherit those privileges and should operate without them.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16114",
"ruleID": "SV-17102r1_rule",
"severity": "medium",
"title": "A PC communications application is operated with administrative or root level privileges.",
"version": "VVoIP 1715 (GENERAL)"
},
"V-16115": {
"checkid": "C-17159r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC based or hardware based voice, video, UC, or collaboration communications endpoints or applications that require configurations to be downloaded from the system (LSC) with which they are associated, accepts only those configuration files that are digitally signed by the proper authority (e.g., using a DoD PKI certificate). Further ensure the digital signature and integrity of the file is validated before the endpoint uses the file. \n\nAsk the IAO and/or consult the vendor and/or the system documentation to determine if downloaded configuration files are digitally signed and that the digital signature is validated before the endpoint uses the file. This is a finding if either condition is not met. Additionally determine if the certificates used are DoD PKI machine certificates. This is a CAT III finding if DoD PKI certificates are not used but the integrity of the file is validated against a vendor generated certificate.\n\nThis is not a finding in the event the following mitigations are employed:\n> Disable automatic configuration file download on endpoint registration \n> Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated \u201cProvisioning\u201d LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN. This will ensure the configuration file is sourced from the LSC eliminating the need for a file integrity check, and will limit its exposure eliminating the need to encrypt.\n",
"description": "During VVoIP endpoint registration with the LSC, a file is downloaded by the endpoint from the LSC that contains specific configuration parameters needed by the endpoint to operate as needed to support its assigned user. This file contains the phone number assigned to the endpoint; the IP addresses (or URLs) of the LSC(s) with which the endpoint is associated; the software menus specific to the system; the password used to access the endpoint\u2019s configuration; the user\u2019s personal preferences and speed dial numbers; as well as other information critical to the operation of the endpoint. NOTE: Hardware based VVoIP endpoints are like diskless computers on the LAN which need to download an operating system and configurations before they can operate. The code necessary to download this OS is stored in ROM or Flash Memory and is called firmware. To varying degrees some, most, or all of the endpoint\u2019s OS can be stored on the device as firmware. The more of the OS that is stored the device, the quicker it initializes. In any case, no matter how much of the OS is stored as firmware, each endpoint requires a customized configuration settings file to be downloaded that individualizes the endpoint to meet the needs of the user to which it is assigned. These configuration settings can be updated occasionally or regularly by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded. Many PC based communications applications are fully configured locally on the platform, however, in some cases they rely on a configuration file downloaded from the system with which they are associated. The integrity of these files is critical to preventing compromise of the PC application, hardware endpoint, and the system itself. The best method for maintaining the integrity of these files is to require that they digitally signed. This can prevent man in the middle attacks where the configuration file could be modified in transit or the source of the file spoofed. Digital signatures and the file integrity must also be validated before the configuration file is used. NOTE: DoD PKI machine certificates are preferred for digital file signing, however, a vendor generated certificate would provide similar albeit not the same protection. LSCs and endpoints are to be assigned DoD machine certificates when the system operates as part of the DISN IPVS network. These certificates are also used for encryption purposes. ",
"fixid": "F-16221r1_fix",
"fixtext": "Ensure PC based or hardware based voice, video, UC, or collaboration communications endpoints or applications that require configurations to be downloaded from the system (LSC) with which they are associated, accepts only those configuration files that are digitally signed by the proper authority (e.g., using a DoD PKI certificate). Further ensure the digital signature and integrity of the file is validated before the endpoint uses the file. \n\nConfigure PC based or hardware based endpoint configuration downloads to use digital signatures. Additionally configure the application to validate the digital signature and the integrity of the configuration file prior to using the file. Additionally configure the system to use DoD PKI certificates.\nOR \nEmploy the following mitigations:\n> Disable automatic configuration file download on endpoint registration \n> Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated \u201cProvisioning\u201d LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16115",
"ruleID": "SV-17103r1_rule",
"severity": "medium",
"title": "The integrity of VVoIP endpoint configuration files downloaded by hardware or PC based VVoIP endpoints during endpoint registration are not validated using digital signatures.",
"version": "VVoIP 1935 (GENERAL)"
},
"V-16116": {
"checkid": "C-17160r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC based voice, video, UC, or collaboration communications applications are configured such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups.\n\nDetermine what the application\u2019s permitted controllers, gateways, and/or servers including backups should be from the IAO. Review application configuration settings on a random sampling of PCs to determine if only the permitted controllers, gateways, and/or servers are configured. Further determine if users (not SAs) can reconfigure these settings. This is a finding if PC based voice, video, UC, or collaboration communications applications are NOT configured such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups or if general users (not SAs) can reconfigure the related settings.\n",
"description": "All voice, video, UC, or collaboration communications endpoints must be configured to only associate with approved DoD controllers, gateways, and/or servers. While this is the norm for hardware based endpoints in a LAN, it is even more important for PC application based endpoints. Such endpoints must not accept service from just any available system. Such a system could actually be in a different organization than the one the application belongs to, depending upon how the application seeks out its controller/server. Peer-to-peer, or direct PC application-to-application communications are based on knowing the other endpoint\u2019s IP address is not permitted. All communications applications must contact their designated session controller(s), gateway(s), or server(s) for authorization to operate. \n\nNOTE: This is the general rule for all communications types with the exception of point-to-point VTC sessions between hardware based VTC CODECs.\n\nAn additional consideration is the reliability of a critical voice communications service and its continuity of operations. This is a prime concern for hardware based VoIP systems which are intended or are designed to provide assured service. Such critical systems must be supported by redundant controllers. If a soft-phone associated with such a system is to be reliable, it must be configured to interact with its primary controller(s) and at least one backup.\n",
"fixid": "F-16222r1_fix",
"fixtext": "Ensure PC based voice, video, UC, or collaboration communications applications are configured such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups.\n\nConfigure PC based voice, video, UC, or collaboration communications applications such that they only contact and associate with their designated and approved DoD controllers, gateways, and/or servers and their approved backups. Further ensure general application users cannot reconfigure these settings.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16116",
"ruleID": "SV-17104r1_rule",
"severity": "medium",
"title": "PC communications application server association is not properly limited.",
"version": "VVoIP 1805 (REMOTE)"
},
"V-16117": {
"checkid": "C-17161r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure PC based public or commercial IM and/or VoIP telephony services and/or supporting applications are unable to be used in the enclave in support of DoDI 8500.2 IA controls ECVI-1 and ECIM-1. \n\nNOTE: This requirement does not include IM and/or IP telephony services and/or supporting applications implemented by a DoD component and approved for use by the responsible DAA to fulfill a validated mission requirement. (e.g., DISA\u2019s enterprise wide collaboration tools).\n\nNOTE: Examples of soft-clients and services to be disabled are, but are not limited to, the following:\n- Yahoo Messenger\n- America Online (AOL) Instant Messenger (AIM)\n- Microsoft Network (MSN) Messenger\n- Skype\n- Freshtel\n- Google Talk \n- Magic Jack (A hardware USB ATA and PC soft-client)\n- Soft clients associated with home telephone service from major PSTN carriers such as Verizon. AT&T, and Quest, major cable carriers such as Comcast and Cox, or competing VoIP carriers such as Vonage.\nMany others.\n\nDetermine if Public or commercial IM or VoIP services are installed on PCs and/or are used. If installed, further determine if the application(s) are implemented by a DoD component and approved for use by the responsible DAA to fulfill a validated mission requirement. Inspect a random sample of PCs to determine if such applications are installed and which ones. This is a finding if such applications are installed whether used or not unless approved to fulfill a validated mission requirement or a non-approved application is installed beside an approved one. \n",
"description": "Various DoD policies disallow general PC users from installing any non-approved application on their workstations or from attaching any non-approved or non-government furnished devices to them. Still other DoD policies require users of government furnished equipment (GFE) (i.e., DoD PCs/workstations) to limit their use to official business and not use them for personal business or other personal activities. Additionally, and more specific to this STIG, DoDI 8500.2 IA controls ECVI-1 and ECIM-1 to disallow general PC users from installing VoIP and IM clients that are intended to access public services for non-official, personal, use. An exception is made for the eventuality that such installations may be approved and performed by a DoD component for official business purposes. The IA controls state the following: \u2022 ECVI-1: \u201cVoice over Internet Protocol (VoIP) traffic to and from workstation IP telephony clients that are independently configured by end users for personal use is prohibited within DoD information systems. Both inbound and outbound individually configured voice over IP traffic is blocked at the enclave boundary. \n\nNOTE: This does not include VoIP services that are configured by a DoD AIS application or enclave to perform an authorized and official function.\u201d \u2022 ECIM-1: \u201cInstant messaging traffic to and from instant messaging clients that are independently configured by end users and that interact with a public service provider is prohibited within DoD information systems. Both inbound and outbound public service instant messaging traffic is blocked at the enclave boundary. \n\nNOTE: This does not include IM services that are configured by a DoD AIS application or enclave to perform an authorized and official function.\u201d \n\nNOTE: AIS in this case means Automated Information System and relates to an official program. The vulnerability is that installation of VoIP and IM clients that associate themselves with, and connect to a public VoIP or IM service places the DoD system on which the client is installed at risk of, and provides an avenue for, its compromise and unauthorized access. Once compromised, the system could be used as a launching point for further compromise of the network or other DoD systems. Additionally, the use of these services also places the confidentiality of DoD information conveyed by them at risk. Such information could be sensitive or the collection of non-sensitive information over time could reveal sensitive information. The mitigation of the vulnerabilities presented by these public services requires a two prong approach. The first is a technical approach, while the second is an administrative approach requiring user awareness, training, and agreements. A technical approach defined by the IA controls stipulates that traffic to and from public IM and VoIP services is to be blocked at the enclave boundary. It would be best if this were to occur at the NIPRNet Internet Access Points (IAPs), thus preventing such traffic from using the DISN, however this is not happening at this time since such blockage might also block other required services and the IAPs are not fully capable of such blockage at this time. This traffic must also be blocked at any Internet Service Provider (ISP) connection(s) to the enclave. \n\nNOTE: All ISP connections must be approved and operated under a waiver obtained from the Global Information Grid (GIG) waiver panel. It is the responsibility of the enclave to provide the required blocking since their firewalls and proxies are where the capability resides. To implement the mitigation, one might think that blocking specific IP addresses would be effective. This is not correct, however, since many of the public services have many IP addresses and servers, while they change their IP addresses regularly as a method of enhancing availability. Some of the public services have classically used non standard IP ports for their communications. Blocking these ports can be an effective measure in meeting the IA controls. Unfortunately, some of the public services are changing to use standard ports to get around the fact that many organizations block the nonstandard ports at their firewalls. The services are migrating to the standard ports 80 and 443 for web services which are generally never blocked. While the purpose of blocking these public services in the network is that this mitigation will prevent the application or service from functioning properly in the event one is installed. It is best to prevent the user from installing the client applications. This can be accomplished by limiting a user\u2019s privileges on their PC such that they cannot install new software. This is typically done on many DoD PCs, however, some users require that ability. Also, unfortunately, just like the trend toward using standard ports, some services may function without a specific client by just using a web browser. This will most likely be the trend for the future. A seemingly more effective approach to blocking these public services or prevent their installation is to block them by their URL. This might be done at a proxy in the enclave boundary or on the PC itself by listing the URLs as un-trusted and setting the PC or proxy security or protection level such that un-trusted sites are blocked. \n",
"fixid": "F-16223r1_fix",
"fixtext": "Ensure PC based public or commercial IM and/or IP telephony services and/or supporting applications are unable to be used in the enclave in support of DoDI 8500.2 IA controls ECVI-1 and ECIM-1. \n\nUninstall any and all applications associated with Public IM or VoIP services that have not been implemented by a DoD component and approved for use by the responsible DAA to fulfill a validated mission requirement.\n\nNOTE: This is typically handled by limiting user permissions to install software on their workstations or via policy or profile limitations enforced by HBSS.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16117",
"ruleID": "SV-17105r1_rule",
"severity": "medium",
"title": "A non-approved public or commercial IM or IP telephony service or soft-client application is in use.",
"version": "VVoIP 1990 (GENERAL) "
},
"V-16118": {
"checkid": "C-17162r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure: \n- Users are made aware and trained that even if their permissions allow, they are not to download and install IM and/or soft-phone applications on their DoD PCs that use or connect to public IM and/or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. \n- Users are made aware and trained that, they are not to attempt to use a stick phone on their DoD PC that associates itself or connects to a public IM or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. \n- Users are made aware and trained that, they are not to attempt to use a PPG on their DoD PC that associates itself with an installed soft-phone unless directed to do so by their DoD organization for the fulfillment of an official requirement. \n- The limitations in this requirement are listed in a signed user agreement.\n\nNote: DAA approval and possibly DISN DAA approval is required in the event IM and/or soft-phone applications, or stick phones that associate with or connect to a public IM or IP telephony service are to be implemented by a DoD component.\n\nAsk the IAO if the required user training is provided and if the items in the requirement are listed in a signed user agreement.\n\nInspect user agreements for inclusion of the limitations and user acknowledgment.\n\nAdditionally, interview a random sample of users to determine their awareness of these limitations. \n\nThis is a finding if training is inadequate and users are unaware of the limitations and/or the limitations are not listed in signed user agreements.\n",
"description": "The second mitigation for the vulnerability regarding personally installed apps and hardware is the administrative prevention of the installation of the applications in question by the PC user. This is generally handled by today\u2019s policies and STIG requirements that are used to secure DoD workstations which limit the privileges of the workstation user. Users that are not given administrator rights on their workstations cannot install such applications. On the other hand, some users are given these rights. To cover those workstations on which the user can install software, the above policy must be enforced, and must be augmented by user awareness, training, and user agreements. The limitations of these IA controls are extensible to hardware devices that provide the same or similar functionality. Such a device is a stick phone, because it contains a client application. Such devices are available for commercial VoIP services such as Vonage and Skype. Another device that can be included under these guidelines is a PPG that connects a soft-phone to a traditional phone line permitting the uncontrolled bridging of voice networks. ",
"fixid": "F-16224r1_fix",
"fixtext": "Ensure users are trained as follows: \n- Users are made aware and trained that even if their permissions allow, they are not to download and install IM and/or soft-phone applications on their DoD PCs that use or connect to public IM and/or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. \n- Users are made aware and trained that, they are not to attempt to use a stick phone on their DoD PC that associates itself or connects to a public IM or IP telephony services unless directed to do so by their DoD organization for the fulfillment of an official requirement. \n- Users are made aware and trained that, they are not to attempt to use a PPG on their DoD PC that associates itself with an installed soft-phone unless directed to do so by their DoD organization for the fulfillment of an official requirement.\n\nAdditionally ensure: \n- The limitations in this requirement are listed in a signed user agreement.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-16118",
"ruleID": "SV-17106r1_rule",
"severity": "medium",
"title": "Deficient user training regarding the use of non-approved applications and hardware.",
"version": "VVoIP 1325 (GENERAL)"
},
"V-16119": {
"checkid": "C-17163r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement: \n\nEnsure all IP Ports, Protocols, and Services (PPSs) used by a Voice/Video/UC system to include its core infrastructure devices and hardware-based or PC application-based endpoints are registered in the DoD Ports and Protocols Database in accordance with DoDI 8550.1. This applies to PPSs that remain within the enclave (\u201clocal PPS\u201d) and those that cross the enclave boundary and/or any of the defined DoD boundaries.\n\nDetermine the PPS used by all Voice/Video/UC system devices and endpoints (to include PC based endpoints) used at the site within the enclave and those that cross a boundary as well as the boundaries they cross where the network is exposed to them. Inspect the system documentation and if necessary contact the vendor. If necessary, use a sniffer to detect the protocols used. This would require operating all system functions or sniffing during a period of time when all functions are accessed. \n\nInspect PPS registrations with regard to PPS used. \n\nThis is a finding if all IP ports and protocols used by the Voice/Video/UC system to include its core infrastructure devices and its hardware based or PC application based endpoints are NOT registered in the DoD Ports and Protocols Database in accordance with DoDI 8550.1.",
"description": "DoDI 8550.1 Ports, Protocols, and Services Management (PPSM) is the DoD\u2019s policy on IP Ports, Protocols, and Services (PPS). It controls the PPS that are permitted or approved to cross DoD network boundaries as well as mitigations for vulnerabilities inherent in the approved PPSs. Standard well known and registered IP ports and associated protocols and services are assessed for vulnerabilities and threats to the entire Global Information Grid (GIG) which includes the DISN backbone networks. The results are published in a Vulnerability Assessment (VA) report. Each port and protocol is given a rating of green, yellow, orange, or red associated with each of the 16 defined boundary types. Green means the protocol is relatively secure and is approved to cross the associated boundary without restrictions. Yellow means the protocol has issues that can be mitigated and it can be used if the required mitigations are used as noted in the VA. Red means that the protocol issues cannot be mitigated, is not secure, or approved, and in fact is banned when crossing that boundary. A new category is Orange which is the same as red except that the protocol is in use and cannot be removed from the network. It recognizes that the protocol exists on the network and is necessary but also mandates that new systems and applications must not be developed using this protocol whether it crosses a boundary or not. Some red and orange protocols have mitigations listed in their VA that must be used if the protocol is used during its remaining life. The information regarding the assessed ports and protocols and the defined boundaries is published in the PPS Assurance Categories Assignment List (CAL). See the Enclave and Network Infrastructure STIGS, the 8550.1, and the latest PPS CAL for a more complete discussion of this DoD program and policy. The PPSM information is available on the IASE and DKO/DoD IA Portal web sites. 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 \u201cvisible to DoD-managed components\u201d. The following PPS registration requirement applies to all PPSs used by a Voice/Video/UC system to include the core infrastructure devices and its hardware based or PC application based endpoints whether or not a PPS crosses the IP based Enclave boundary to the DISN WAN or another enclave. The PPSM PMO is requiring internal PPSs to be registered in case they find their way to the DISN WAN.",
"fixid": "F-16225r1_fix",
"fixtext": "Ensure all IP Ports, Protocols, and Services (PPSs) used by a Voice/Video/UC system to include its core infrastructure devices and its hardware-based or PC application-based endpoints are registered in the DoD Ports and Protocols Database in accordance with DoDI 8550.1. This applies to PPSs that remain within the enclave (\u201clocal PPS\u201d) and those that cross the enclave boundary and/or any of the defined DoD boundaries.\n\nProperly register all IP ports and protocols used by the Voice/Video/UC system to include its core infrastructure devices and hardware based or PC application based endpoints whether it crossed a boundary or not.\n",
"iacontrols": [
"DCBP-1",
"DCPP-1",
"ECSC-1"
],
"id": "V-16119",
"ruleID": "SV-17107r1_rule",
"severity": "medium",
"title": "Deficient PPS registration of those PPSs used by a Voice/Video/UC system to include its core infrastructure devices and hardware based or PC application based endpoints.",
"version": "VVoIP 1020 (GENERAL)"
},
"V-19440": {
"checkid": "C-23699r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event a VVoIP system provides assured, service sensitive but unclassified (SBU), or classified site-to-site communications and is integrated into a DISN IP Voice Services (VS) or Unified Capabilities (UC) network (DISN IPVS/UCN)(classified or unclassified); ensure all active participants in the signaling path provide hop-by-hop confidentiality, integrity, and authentication for signaling messages using TLS or IPSec. Implement the AES 128-bit algorithm or AES 256-bit algorithm as defined in the UCR. \n\nNOTE: The participants in question are the End Instruments (EIs), Media Gateways (MGs), Local Session Controller (LSC), Soft-Switch (SS), Multi-Function Soft Switch (MFSS), and Edge Border Controllers (EBCs) (which is the DISN IPVS VVoIP firewall). \n\nAdditionally, ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS network.\n\n\n\n",
"description": "Until recently VVoIP traffic has been restricted to the LAN/CAN within the enclave for most VVoIP systems. This is due to the lack of inter-vendor interoperability, end-to-end encryption, and the inability of VoIP to provide assured service in support of C2 communications reliability and priority requirements. The DSN PMO, DISA Engineering, and the Real Time Services (RTS) working group have been working to define network and system requirements to overcome the inherent obstacles in pursuit of a DISN wide interoperable assured service VVoIP or Voice Services network. In doing so, specific choices had to be made amongst the various technological and vendor solutions to provide the capability. These choices were made with the full cooperation of a consortium of vendor engineers. The following requirement reflects one of these choices made to meet DoD \u201cconfidentiality of data in transit\u201d requirements under the DoDI 8500.2 IA controls ECCT-1 and ECNK-1 as well as Federal Information Processing Standards (FIPS) and Internet Engineering Task Force (IETF) recommendations. \n\nNOTE: For the purpose of this document the DISN wide IP enabled DSN or RTS network will be referred to the DISN IP Voice Services network or DISN IPVS network. Real time IP communications (known as real time Services (RTS)) is comprised of signaling protocols which set up and manage the communications session and the media transfer protocols which carry the communications. Both signaling and media protocols and the resulting communications can be compromised when sent in the clear. One of the common means (per IETF recommendations) of initiating a RTS communications session across an IP network is to use Session Initiation Protocol (SIP). To provide the assured service pre-emption and priority capabilities required for C2 telephone communications, DISA developed an extension to the SIP protocol (with the assistance of interested vendors) which is called Assured Service SIP or AS-SIP. The common means of providing confidentiality and integrity for SIP signaling as well as providing session authentication is to encrypt it using Transport Layer Security (TLS) as defined by the IETF recommendations. An additional factor to interoperability is the use of the same key management strategies at both ends of the session. The encryption algorithm, key strength, and key management processes are denied in the current version of the DoD Unified Capabilities Requirements (UCR) document available from the DISA voice Services PMO. \n\nNOTE: the devices in a VVoIP system that are required to provide this protection are all those involved in session initiation from end-to-end. These are the End Instruments (EIs), Media Gateways (MGs), Local Session Controller (LSC), Soft-Switch (SS), Multi-Function Soft Switch (MFSS), and Edge Border Controllers (EBCs) (which is the DISN IPVS/UCN VVoIP firewall). \n",
"fixid": "F-20184r1_fix",
"fixtext": "When integrating a VVoIP system into an assured services classified or unclassified DISN IPVS/UC network:\n\nEnsure all active participants in the signaling path provide hop-by-hop confidentiality, integrity, and authentication for signaling messages using TLS or IPEec. Implement the AES 128-bit algorithm or AES 256-bit algorithm as defined in the UCR. \nNOTE: The participants in question are the End Instruments (EIs), Media Gateways (MGs), Local Session Controller (LSC), Soft-Switch (SS), Multi-Function Soft Switch (MFSS), Signaling Gateway (SG), and Edge Border Controllers (EBCs) (which is the DISN IPVS VVoIP firewall).\n\nAdditionally ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS/UC network.\n\nConfigure the VVoIP system components per the DoD APL IA deployment guide specific to the product being deployed.\n",
"iacontrols": [
"ECCT-1",
"ECSC-1"
],
"id": "V-19440",
"ruleID": "SV-21491r1_rule",
"severity": "medium",
"title": "Deficient end-to-end interoperable confidentiality, integrity, and authentication for VVoIP session signaling per DISN IPVS Requirements.",
"version": "VVoIP 6165 (DISN-IPVS)"
},
"V-19441": {
"checkid": "C-23701r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event a VVoIP system provides assured, service sensitive but unclassified (SBU), or classified site-to-site communications and is integrated into a DISN IP Voice Services (VS) or Unified Capabilities (UC) network (classified or unclassified); ensure End Instruments (EIs) and Media Gateways (MGs) provide end-to-end confidentiality for media streams using SRTP with AES_CM_128 as the default encryption algorithm or [as Required FY12] AES 256-bit algorithm as defined in the UCR.\n\nAdditionally ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS network.\n\n\n",
"description": "Until recently VVoIP traffic has been restricted to the LAN/CAN within the enclave for most VVoIP systems. This is due to the lack of inter-vendor interoperability, end-to-end encryption, and the inability of VoIP to provide assured service in support of C2 communications reliability and priority requirements. The DSN PMO, DISA Engineering, and the Real Time Services (RTS) working group have been working to define network and system requirements to overcome the inherent obstacles in pursuit of a DISN wide interoperable assured service VVoIP or Voice Services network. In doing so, specific choices had to be made among the various technological and vendor solutions to provide the capability. These choices were made with the full cooperation of a consortium of vendor engineers. The following requirement reflects one of these choices made to meet DoD \u201cconfidentiality of data in transit\u201d requirements under the DoDI 8500.2 IA controls ECCT-1 and ECNK-1 as well as Federal Information Processing Standards (FIPS) and Internet Engineering Task Force (IETF) recommendations. NOTE: For the purpose of this document the DISN wide IP enabled DSN or RTS network will be referred to the DISN IP Voice Services / Unified Capabilities (UC) Network or DISN IPVS/UCN or DISN IPVS/UC network. Real time IP communications (known as real time Services (RTS)) is comprised of signaling protocols which set up and manage the communications session and the media transfer protocols which carry the communications. Both signaling and media protocols and the resulting communications can be compromised when sent in the clear. The common means (per IETF recommendations) of transporting RTS media across an IP network is to use Real-time Transfer Protocol (RTP). The common means of providing confidentiality and integrity of the RTP streams is to apply a security profile to RTP called Secure Real-time Transfer Protocol (RTP). An additional factor to interoperability is the use of the same key management strategies at both ends of the session. The encryption algorithm, key strength, and key management processes are denied in the current version of the DoD Unified Capabilities Requirements (UCR) document available from the DISA voice Services PMO. \n\nNOTE: The devices in a VVoIP system that are required to provide this protection are the End Instruments (EIs) and Media Gateways (MGs). These are the only devices in the end-to-end communications path that are required to have access to the unencrypted media stream. \n",
"fixid": "F-20295r1_fix",
"fixtext": "When integrating a VVoIP system into an assured services classified or unclassified DISN IPVS network, ensure End Instruments (EIs) and Media Gateways (MGs) provide end-to-end confidentiality for media streams using SRTP with AES_CM_128 as the default encryption algorithm or [as Required FY12] AES 256-bit algorithm as defined in the UCR.\n\nAdditionally ensure key management is performed in accordance with UCR requirements to ensure interoperability across the DISN IPVS network.\n\nConfigure the VVoIP system components per the DoD APL IA deployment guide specific to the product being deployed.\n",
"iacontrols": [
"ECCT-1",
"ECSC-1"
],
"id": "V-19441",
"ruleID": "SV-21492r1_rule",
"severity": "medium",
"title": "Deficient end-to-end interoperable confidentiality and integrity for VVoIP session media streams per DISN IPVS requirements.",
"version": "VVoIP 6170 (DISN-IPVS)"
},
"V-19442": {
"checkid": "C-23706r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure all sites possessing a LSC or MFSS are capable of maintaining call/session establishment capability such that it can minimally make local internal and local commercial network calls in the event the LSC or MFSS becomes unavailable to receive and act on EI signaling requests. \n\nDetermine if the LSC or LSC portion of the MFSS has a backup call/session establishment capability such that it can minimally make local internal and local commercial network calls\n\nThis is a finding in the event the primary LSC or LSC portion of the MFSS has no COOP relationship with another LSC in a redundant and geographically diverse facility.\n\nNOTE: The minimum capability for placement of precedence calls (line-side or to the DISN) is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.\n",
"description": "Voice phone services are critical to the effective operation of a business, an office, or in support or control of a DoD mission. We rely on these services being available when they are needed. Additionally, it is critical that phone service is available in the event of an emergency situation such as a security breach or life safety event. The capability or ability to place calls to emergency services must be maintained. While the DoD voice and data networks are designed to be extremely reliable, such that continuity of operations (COOP) is supported, there is the potential that a site\u2019s EIs will loose the availability to communicate or signal with the LSC or MFSS. Reality is that if signaling messages cannot reach a LSC or MFSS, calls cannot be established. This is an issue even though the LSC and MFSS are specified to provide 5 9s availability; there are many other factors that affect the availability of these central devices. Natural disasters or physical damage to the network connections and/or pathways are just some. The following are considerations for meeting this requirement: \n\u2022 Large sites and Intranets: \n\u2022\u2022 Redundancy of platforms \u2013 Two or more LSC controllers clustered o Geographic diversity in locating the multiple LSCs within the site or Intranet \n\u2022 Small Sites (not dual homed): \n\u2022\u2022 A single local subtended LSC may use a LSC to which it is subtended as the backup LSC for call control in the event the local LSC goes down. The best method for meeting this requirement on a large site is to implement redundancy for the LSC and the LSC portion of a MFSS. These redundant devices would then be located in redundant and geographically diverse facilities and connected to different parts of the LAN or CAN. This would mean that two core locations would be established within the site/enclave. LSCs and the LSC portion of a MFSS may be implemented on redundant platforms to meet the 5 9s availability requirements. Potentially these internally redundant devices might be able to be decomposed and located in the redundant facilities. Additional protections are needed for the communications between these decomposed elements. Additionally, each portion of the decomposed elements would need to be able to function on its own. In the event a site/enclave supports multiple tenants and one or more of these tenants have their own LSC, the main site could establish a COOP relationship with the tenant LSC and vise versa. An alternate method might be to establish a COOP relationship to a LSC or MFSS in another site or enclave. The issue with this arrangement is that the interconnection between sites is vulnerable and should be redundant with potentially COOP relationships with multiple LSCs at multiple sites. The best method for an Intranet served by a central LSC or MFSS is to place redundant LSCs in redundant and geographically diverse facilities which are then connected to different parts of the Intranet. Sites served by these LSCs should be dual homed using redundant circuits via geographically diverse paths. \n",
"fixid": "F-20186r1_fix",
"fixtext": "Establish COOP capabilities for the primary LSC or LSC portion of the MFSS using redundant LSCs or COOP arrangements with other LSCs in redundant and geographically diverse facilities.\n\nNOTE: The minimum capability for placement of precedence calls (line-side or to the DISN)is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.\n",
"iacontrols": [
"COEF-1",
"DCBP-1",
"ECSC-1"
],
"id": "V-19442",
"ruleID": "SV-21493r1_rule",
"severity": "low",
"title": "The site\u2019s V-VoIP system is NOT capable of maintaining call/session establishment capability such that it can minimally make local internal and local commercial network calls in the event the LSC or MFSS becomes unavailable to receive and act on EI signaling requests. \n\n",
"version": "VVoIP 1210 (GENERAL)"
},
"V-19443": {
"checkid": "C-23709r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the site has a VVOIP phone system which is implemented so that the endpoints are controlled by a LSC at a remote site, (e.g., implemented as \u201clong Local\u201d service), AND, the site does not have a separate commercial phone system (dedicated PBX, key system or discrete instruments) available, ensure the site has a backup VoIP call control capability such that it can minimally make local internal and local commercial network calls in the event the site is cut off from the remote LSC.\nThat is, ensure the site has a backup VoIP call control capability such that normal or semi normal phone service is maintained in the event the site is cut off from the remote LSC; or ensure the site has an alternate phone system or instruments through which local commercial calls can be made.\n\nThis is a finding in the event of the following:\nThe VVoIP phone system is controlled by a remote LSC. \nAND\nThe site does not have a local backup call control agent to maintain functionality of the VVoIP phones for both intra-site calls and external commercial network calls.\nAND \nThe site does not have an alternate phone system for making external commercial network calls.\n\nNOTE: In general, reliance on DoD provided or personal cell phones does not meet this requirement due to the fact that good signal strength is not universal and reliable particularly in buildings and cell phones are not permitted everywhere in DoD facilities. This might, however, be a viable solution in some instances.\n\nNOTE: The minimum capability for placement of line-side precedence calls is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.\n",
"description": "Voice phone services are critical to the effective operation of a business, an office, or in support or control of a DoD mission. We rely on these services being available when they are needed. Additionally, it is critical that phone service is available in the event of an emergency situation such as a security breach or life safety event. The ability of maintaining the ability to place calls to emergency services must be maintained. While the DoD voice networks are designed to be extremely reliable, such that continuity of operations (COOP) is supported, there is the potential that a site will be cut off from the DoD network. Additionally, some site\u2019s DoD VoIP phone systems are implemented without a local LSC. The LSC is located at some remote location and may serve several sites, both large and small. This scenario is sometimes called \u201clong Local\u201d service. Such an implementation can be used in regionalized organizational intranets and in MOBs with their tethered GSUs. This implementation scenario provides for central management of the overall phone system, saves in initial implementation cost, and saves in operating costs. As such this scenario has many benefits. Unfortunately, the reality of this implementation is that in order to place a call between two endpoints within the local site or to place a call via the local commercial service connection, the initiating end instrument has to send its signal messages to the remote LSC over the DISN WAN connection, then the LSC has to signal the called instrument or MG over the same WAN connection. Several messages are sent (back and forth) over the WAN connection before the two local endpoints can send their media streams directly between themselves. While the need to signal over the WAN connection can cause longer call setup time which can be extended if there is congestion in the network, no call can be placed anywhere from the local site if it is cut off from its LSC. Based on this fact, and in support of maintaining viable local voice services in the event the site is cut off from its remote LSC, each physical site must maintain minimal local call control as a backup so that local intra-site and local commercial network calls can be placed. While this works to maintain local emergency service availability for security and life safety emergencies, it also provides the capability to make calls between DoD sites using the commercial network. ",
"fixid": "F-20187r1_fix",
"fixtext": "Ensure the site has a backup VoIP call control capability such that normal or semi normal phone service is maintained in the event the site is cut off from the remote LSC or ensure the site has an alternate phone system or instruments through which local commercial calls can be made.\n\nNOTE: The minimum capability for placement of line-side precedence calls is dependant upon the C2 requirements of the site in question and should be determined in conjunction with the local command authority. To satisfy this requirement, however, the minimum requirement is the maintenance of ROUTINE call placement capabilities.\n",
"iacontrols": [
"COEF-1",
"DCBP-1",
"ECSC-1"
],
"id": "V-19443",
"ruleID": "SV-21494r1_rule",
"severity": "medium",
"title": "The local VVOIP system cannot place local intra-site or local commercial network calls in the event it is cut off from its remote, centrally located LSC.",
"version": "VVoIP 1215 (GENERAL) "
},
"V-19482": {
"checkid": "C-23772r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure VVoIP system applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation.\n\nDetermine if VVoIP system applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation. Have the IAO or SA demonstrate the application and upgrade/patch integrity validation process. This is a finding if digital signatures are not validated before installation.\n\nNOTE: This requirement addresses applications, upgrades, and patches for the overall VVoIP system infrastructure. PC based applications, upgrades, and patches are addressed separately.",
"description": "It is important that the vendor provided upgrades or patches are not modified during their delivery and installation. This can be a problem if the application is obtained from a source other than directly from it\u2019s original developing vendor such as a third party download service. Any application that is not obtained from its original developing vendor could be modified to add some sort of malicious code that could affect the confidentiality, integrity, and availability of the communications supported by the application. Also malicious code could affect the platform on which the application is operated, the network to which the platform is attached, and the communications system with which the application operates. To mitigate this issue, it is highly recommended that vendors provide their applications, upgrades, or patches in a digitally signed and hashed format such that the integrity of the application can be verified.",
"fixid": "F-20210r1_fix",
"fixtext": "Ensure VVoIP system applications, upgrades, and patches are digitally signed by the vendor and validated for integrity before installation.\n\nEmploy only those VVoIP system applications, upgrades, and patches that are digitally signed by the vendor. Perform the appropriate digital signature validation process to validate application and upgrade/patch integrity before installation.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19482",
"ruleID": "SV-21541r1_rule",
"severity": "medium",
"title": "The integrity of a vendor provided application, upgrade, or patch is not validated via digital signature before installation.",
"version": "VVoIP 1201 (GENERAL)"
},
"V-19493": {
"checkid": "C-23776r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure configuration files for hardware based and/or PC application based voice, video, UC, or collaboration communications endpoints downloaded during registration, are in a vendor specific binary format only interpretable by the vendor\u2019s endpoints; or, if human readable; are encrypted; or, if downloaded across a WAN, are downloaded over an encrypted tunnel (VPN). \n\nDetermine if the downloaded configuration files are binary or human readable. If they are human readable, verify that the files are directly encrypted. If not, and the endpoint in question is a PC communications application, determine if the file is downloaded over an encrypted channel such as a VPN. \n\nNOTE: Many of these configuration files are transferred using simple protocols such as BootP or TFTP which are designated \u201clocal management\u201d per the PPSM VAs for these protocols. This means that these protocols and therefore the configuration files transported by them must not traverse the WAN or enclave boundary unless protected by an encrypted VPN. As such, VVoIP endpoints that register with a LSC located in another LAN/enclave, must do so via an encrypted site-to-site VPN between the enclaves or via an encrypted client-to-site VPN. \n\nNOTE: the segregation of VVoIP and data on the LAN provides some protection for these downloaded configuration files providing the transfer occurs within the LAN and not across a WAN. This becomes an issue for endpoints that register with an LSC in a remote enclave. \n\nThis is a finding in the event of the following:\n> The downloaded configuration file is not in a vendor specific binary format only interpretable by the vendor\u2019s endpoints OR the file is human readable and not natively encrypted.\nOR\n> The downloaded configuration file is transferred across a WAN but not transferred within an encrypted tunnel (VPN), (encrypted human readable or binary).\n \nThis is not a finding in the event the following mitigations are employed:\n> Disable automatic configuration file download on endpoint registration. \n> Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated \u201cProvisioning\u201d LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN.\n\n",
"description": "During VVoIP endpoint registration with the LSC, a file is downloaded by the endpoint from the LSC that contains specific configuration parameters needed by the endpoint to operate as needed to support its assigned user. This file contains the phone number assigned to the endpoint; the IP addresses (or URLs) of the LSC(s) with which the endpoint is associated; the software menus specific to the system; the user\u2019s personal preferences and speed dial numbers; as well as other information critical to the operation of the endpoint. \n\nNOTE: Hardware based VVoIP endpoints are like diskless computers on the LAN which need to download an operating system and configurations before they can operate. The code necessary to download this OS is stored in ROM or Flash Memory and is called firmware. To varying degrees some, most, or all of the endpoint\u2019s OS can be stored on the device as firmware. The more of the OS that is stored the device, the quicker it initializes. In any case, no matter how much of the OS is stored as firmware, each endpoint requires a customized configuration settings file to be downloaded that individualizes the endpoint to meet the needs of the user to which it is assigned. These configuration settings can be updated occasionally or regularly by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded.\n\nMany PC based communications applications are fully configured locally on the platform, however, in some cases they rely on a configuration file downloaded from the system with which they are associated. \n\nThe confidentiality of these files is critical to preventing compromise of the PC application, hardware endpoint, and the system itself. Many vendors use configuration files of this sort that are a compact binary format that is only interpretable by the endpoint\u2019s firmware or PD application. However, there is the potential that such files may be human readable as is XML code and most VVoIP signaling protocols. If the file is human readable, intelligence can be gathered by capturing the file while it is in transit. Additionally, the file is easier to understand and therefore makes it easier to modify it and then forward it to its destination. This facilitates man-in-the-middle attacks.\n\nThe best method for maintaining the confidentiality of human readable files is to require that they be directly encrypted or downloaded over an encrypted channel. This can prevent man-in-the-middle attacks. Encryption of this file is also required if the file contains the password used to access the endpoint\u2019s configuration information and settings menus. While encryption will also protect binary files, the threat is less due to the inability to easily read the information in the file without a program designed to interpret the binary code. As noted earlier, digital signatures and the file integrity must also be validated before the configuration file is used.\n\nNOTE: To satisfy the encryption requirement here, the file can be encrypted directly (preferred) or downloaded over an encrypted channel. (This is applicable to PC applications only)\n\nNOTE: Many of these configuration files are transferred using protocols such as BootP or TFTP which are designated \u201clocal management\u201d per the DoD PPSM VAs for these protocols. These protocols are generally considered to be vulnerable due to their simplicity and lack of any security features. Per the DoD PPSM guidelines, a designation of \u201clocal management\u201d means that PPSM recognizes the use of the protocol may be necessary within the LAN/enclave but it must remain within the LAN/enclave. This means that these protocols and therefore the configuration files transported by them must not traverse the WAN or enclave boundary unless protected by an encrypted VPN. As such, VVoIP endpoints that register with a LSC located in another LAN/enclave must do so via an encrypted site-to-site VPN between the enclaves or via an encrypted client-to-site VPN. \n\n",
"fixid": "F-20214r1_fix",
"fixtext": "Ensure configuration files for hardware based and/or PC application based voice, video, UC, or collaboration communications endpoints downloaded during registration, are in a vendor specific binary format only interpretable by the vendor\u2019s endpoints; or, if human readable; are encrypted; or, if downloaded across a WAN, are downloaded over an encrypted tunnel (VPN). \n\nIn the event the system does not use a vendor specific binary format only interpretable by the vendor\u2019s endpoints, configure the system to natively encrypt the endpoint configuration file. \nOR \nIn the event the endpoint registers with a LSC in another enclave across a WAN, establish an encrypted tunnel between the enclave containing the LSC and the enclave containing the endpoint (site-to-site) or the endpoint itself (client-to-site).\nOR \nEmploy the following mitigations:\n> Disable automatic configuration file download on endpoint registration \n> Pre-install the configuration file before the endpoint is deployed to its user using a dedicated and segregated \u201cProvisioning\u201d LAN or VLAN that is local to the LSC having restricted access to or from VLANs other than the LSC VLAN.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19493",
"ruleID": "SV-21552r1_rule",
"severity": "low",
"title": "The confidentiality of endpoint configuration files downloaded by hardware based or PC based VVoIP endpoints during registration is not protected. ",
"version": "VVoIP 1936 (GENERAL)"
},
"V-19500": {
"checkid": "C-23780r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \nEnsure any LAN that supports VVoIP services is designed and implemented to provide enhanced reliability, availability, and bandwidth for those services. \n\nReview the network diagrams and design information to determine if the LAN is designed to provide the required enhanced reliability and availability for the supported VVoIP services.\n\nSpecific attention should be given in the areas of:\n- Bandwidth and traffic engineering (25% voice, 25% video, 50% data)\n- No single points of failure affecting service to greater than 96 instruments.\n- Equipment reliability \n- Equipment redundancy above the access layer\n- Equipment robustness and bandwidth capability\n- Connection redundancy above the access layer\n- Connection bandwidth capability \n- Access layer switch size / number of phones served \n- Backup power for all equipment. \n\nNOTE: Voice bandwidth engineering is based on 102 kbps (each direction) for each IP call for IPv4 and 110.0 kbps for IPv6. Video bandwidth engineering is not so simple since when present, a single video stream can utilize 160kbps to 7.5Mbps in addition to any audio stream. See the UCR for details.\n\nThis is a finding in the event the design is generally deficient in these areas. \n\nNOTE: this check is not intended to initiate an in depth analysis of the network design. If the LAN is not is not properly designed it should be easily discerned because many of the criteria will not be met unless the LAN was already designed for high reliability and availability before adding VVUC services. If VoIP is added to a basic LAN infrastructure that has not been properly designed, the service will not be reliable.\n\n",
"description": "\u2022 The traditional circuit switched telecommunications network is in general highly available highly and reliable on the order of 5 - 9s (99.999% uptime) reliability for the equipment and an aggregate of 2 to 3 9s for entire system and its provided services. This is achieved through a series of measures such as redundant hardware and network connectivity as well as backup power for the central switching equipment which also provides power for the subscriber instruments.\n\u2022 The traditional circuit switched telecommunications network supports routine communications, emergency communications, and high priority military command and control communications. Military telecommunications systems support various user types Special-C2, C2, C2-Routine (C2R), Non-C2, and administrative. C2 and Special-C2 users require higher levels of reliability and availability then do the rest. \n\u2022 As these services migrate from circuit switched technologies to packet switched IP based technologies, this reliability and support is expected to and must migrate with the service. \n\u2022 Similar measures are used to enhance the reliability and availability of VVoIP services on an IP network as are used in a circuit switched network.\n\nNOTE: \nfrom CJCSI 6215.01C Appendix A Enclosure C\nAvailability requirement for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. While this also states that no uninterrupted power supply is required (as a cost savings), all equipment and instruments in a VVOIP system should be provided with backup power in support of emergency, security, and life safety related communications.\n\nAlso from the UCR, 5.3.1.7.3.1 Voice Services \n1. Voice IP subscribers do not exceed more than 25 percent of available bandwidth (in LAN equipment and links)\n2. No single point of failure within the ASLAN can cause a voice service outage to more than 96 users.\n5.3.1.7.3.3 Data Services\nThe LAN will be engineered for a ratio of 25 percent voice, 25 percent video, and 50 percent data. Data traffic can burst up to the full link capacity if voice and video are not present.\n",
"fixid": "F-20216r1_fix",
"fixtext": "Ensure the LAN that supports VVoIP services is designed and implemented to provide enhanced reliability and availability for those services. \n\nRedesign and Upgrade the LAN infrastructure as necessary to meet requirements.\nSpecific attention should be given in the areas of:\n- Bandwidth and traffic engineering (25% voice, 25% video, 50% data)\n- No single points of failure affecting service to greater than 96 instruments.\n- Equipment reliability \n- Equipment redundancy above the access layer\n- Equipment robustness and bandwidth capability\n- Connection redundancy above the access layer\n- Connection bandwidth capability \n- Access layer switch size / number of phones served \n- Backup power for all equipment. \n\nNOTE: Voice bandwidth engineering is based on 102 kbps (each direction) for each IP call for IPv4 and 110.0 kbps for IPv6. Video bandwidth engineering is not so simple since when present, a single video stream can utilize 160kbps to 7.5Mbps in addition to any audio stream. See the UCR for details.\n\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-19500",
"ruleID": "SV-21562r1_rule",
"severity": "low",
"title": "The LAN supporting VVoIP services is not designed or implemented to provide enhanced availability and reliability above that of a traditional data LAN.",
"version": "VVoIP 5100 (LAN)"
},
"V-19514": {
"checkid": "C-23782r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \nEnsure all ASLAN (and optionally Non-ASLAN) switching/routing platforms that support more than 96 telephony subscribers/instruments (C2 or not) are redundant in the following manner:\n1. Dual Power Supplies. The platform shall provide a minimum of two power supplies each with the power capacity to support the entire chassis. Loss of a single power supply shall not cause any loss of ongoing functions within the chassis.\n2. Dual Processors (Control Supervisors). The chassis shall support dual control processors. Failure of any one processor shall not cause loss of any ongoing functions within the chassis (e.g., no loss of active calls).\n3. Termination Sparing. The chassis shall support a (N + 1) sparing capability for available 10/100Base-T modules used to terminate to an IP subscriber.\n4. Redundancy Protocol. Routing equipment shall support a protocol that allows for dynamic rerouting.\n5. Switch Fabric or Backplane Redundancy. Switching platforms within the ASLAN shall support a redundant (1 + 1) switching fabric or backplane. The second fabric\u2019s backplane shall be in active standby so that failure of the first shall not cause loss of ongoing events within the switch. \nOR \nA secondary product is added to the ASLAN to provide redundancy to the primary product.\nAND\nA redundancy protocol is implemented such that the failover over to the secondary product must not result in any lost calls.\n\nDetermine if the LAN supports Special-C2 or C2 users. If so, determine which part (or parts) of the LAN directly supports these users. \n\nInspect the system design documentation and specifications of the LAN network elements. This is a finding in the event the LAN is not designed to provide the required redundant processors, power supplies, etc as noted above or there is no secondary product through which VVUC services can be routed. \n\nThis finding carries a severity of Cat II if the NE directly supports a Special-C2 or C2 user. This finding carries a severity of Cat III if the NE only directly supports C2R, or Non-C2/admin users. \n\nNOTE: This is not applicable if the LAN as a whole supports 96 or fewer VVUC users. In the event the LAN as a whole supports more than 96 VVUC users, there will be some portion of the LAN infrastructure to which this will be applicable. These will typically the core elements as a minimum.\n",
"description": "Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. Policy excerpts are as follows: From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN \u2013 Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN \u2013 Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details. \n\nNOTE: In large LAN infrastructures, it is most likely that each network element in the core and distribution layers of the LAN will support in excess of 96 users whether they are C2 users or not. All users of VVUC services supported by the LAN deserve reliable communications, particularly in emergency situations. As such, these devices should possess the ability to fail-over to a redundant piece of hardware. At the network access layer (the layer where endpoints connect), this is more difficult. While redundant power supplies, backplanes, and processors can provide redundancy for a given NE, this is not possible for the portion of the NE to which the LAN drop cable attaches. Here there can be no automatic failover. The use of the 96 user figure at the access layer is in support of this requirement. Typically access layer modules or stand alone devices support 48 and fewer connections. So, while all access layer switches should have some form of internal redundancy, there is a point when this is not cost effective or possible. In this case, a failure must be mitigated by physically moving LAN drop connections to a hot-standby device or replacing the defective module. Also note that for a LAN that supports 96 or fewer VVUC users as a whole would mean that by policy omission redundancy is not required, it is best practice that redundancy exists in some manner and particularly at the core or that there is spare equipment available. \n\nNOTE: While the policy discusses availability and reliability, through LAN equipment redundancy for C2 and Special C2 users of VVUC services, similar availability and reliability through redundancy is needed in support of routine user emergency life-safety and security related communications. \n",
"fixid": "F-20226r1_fix",
"fixtext": "Ensure all ASLAN (and optionally Non-ASLAN) switching/routing platforms that support more than 96 telephony subscribers/instruments (C2 or not) are redundant in the following manner:\n1. Dual Power Supplies. The platform shall provide a minimum of two power supplies each with the power capacity to support the entire chassis. Loss of a single power supply shall not cause any loss of ongoing functions within the chassis.\n2. Dual Processors (Control Supervisors). The chassis shall support dual control processors. Failure of any one processor shall not cause loss of any ongoing functions within the chassis (e.g., no loss of active calls).\n3. Termination Sparing. The chassis shall support a (N + 1) sparing capability for available 10/100Base-T modules used to terminate to an IP subscriber.\n4. Redundancy Protocol. Routing equipment shall support a protocol that allows for dynamic rerouting.\n5. Switch Fabric or Backplane Redundancy. Switching platforms within the ASLAN shall support a redundant (1 + 1) switching fabric or backplane. The second fabric\u2019s backplane shall be in active standby so that failure of the first shall not cause loss of ongoing events within the switch. \nOR \nA secondary product is added to the ASLAN to provide redundancy to the primary product.\nAND\nA redundancy protocol is implemented such that the failover over to the secondary product must not result in any lost calls.\n\nUpgrade as needed.\n\nNOTE: While redundancy may not be required by policy for NEs that support 96 VVUC users or less, it is best practice to provide redundancy or maintain spares such that service can be restored in a timely manner in the event of a failure.\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-19514",
"ruleID": "SV-21576r1_rule",
"severity": "medium",
"title": "The LAN hardware does not provide the required redundancy to support the availability/reliability needs of the C2 and Special C2 users of VVoIP services for command and control communications OR the needs of routine users for emergency life-safety and security related communications.",
"version": "VVoIP 5110 (LAN)"
},
"V-19521": {
"checkid": "C-23785r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure the LAN supporting VVUC services is designed to interconnect all LAN NEs with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above. Additionally ensure that each uplink is designed to support the full bandwidth handled by the NE and the NE is capable of affecting a failover from one uplink to the other in the event of the failure of one. \nNOTE: This applies to access layer NEs connected to distribution layer NEs and distribution NEs connected to core layer NEs.\n\nDetermine if the LAN supports Special-C2 or C2 users. If so, Determine which parts of the LAN support Special-C2 users, which parts support C2 users, and which parts support only C2R and Non-C2/admin users. Inspect the LAN design documentation, and as built schematics and physical cable routing diagrams to determine design compliance. \n\n",
"description": "Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. The UCR in section 5.3.1.7.7.1 Single Product Redundancy states \u201cIn the event of a component failure in the network, all calls that are active shall not be disrupted (loss of existing connection requiring redialing) and the path through the network shall be restored within 5 seconds.\u201d While the UCR is discussing hardware redundancy in this section it also discusses connectivity within the LAN as follows: 5.3.1.7.9 Survivability Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering quickly from network failures quickly and maintaining the required QoS for existing services. For the ASLAN, survivability needs to be inherent in the design. The following guidelines are provided for the ASLAN: 1. Layer 3 Dynamic Rerouting. The ASLAN products that route (normally the Distribution and Core Layers) shall use routing protocols IAW the DISR to provide survivability. 2. Layer 2 Dynamic Rerouting. \u2022 Virtual Router Redundancy Protocol (VRRP) \u2013 RFCs 2787 and 3768. VRRP is able to provide redundancy to Layer 2 switches that lose connectivity to a Layer 3 router. The ASLAN shall employ VRRP to provide survivability to any product running Layer 2 (normally the Access Layer). These requirements translate into the need for redundant connections between all connected NEs within the LAN. As such this requires a single access layer or distribution layer NE to have two uplinks to the layer above. Additionally the physical paths these uplinks take should be physically diverse. Additionally, these paths should terminate in physically diverse locations (that is, different NEs in different locations) These measures represent best practices and should be utilized to support all VVUC users but are required for special-C2 and C2 users. The availability and reliability policy excerpts are repeated here in support of this requirement for convenience: From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN \u2013 Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN \u2013 Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details.",
"fixid": "F-20229r1_fix",
"fixtext": "Ensure all LAN NEs supporting VVUC services are interconnected with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above. Additionally ensure that each uplink can support the full bandwidth handled by the NE and the appropriate routing protocol is configured to affect the failover from one uplink to the other in the event of the failure of one. \nNOTE: This applies to access layer NEs connected to distribution layer NEs and distribution NEs connected to core layer NEs.\n\nRun cable, upgrade, or reroute as necessary.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19521",
"ruleID": "SV-21583r1_rule",
"severity": "medium",
"title": "The design of the LAN supporting VVoIP services does not provide for the interconnection of LAN NEs with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above ",
"version": "VVoIP 5115 (LAN)"
},
"V-19535": {
"checkid": "C-23787r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \nEnsure an uninterruptible power supply (battery at a minimum; plus optional generator) is provided for all parts of the VVoIP infrastructure (Core LSC/MFSS, adjunct systems providing critical services, EBC, CER, LAN NEs, and endpoints as follows:\n> All VVoIP system devices including voice endpoints and portions of the LAN that directly support any single special-C2 user are minimally provided 8 hours UPS.\n> All VVoIP system devices including voice endpoints and portions of the LAN that directly supports any single C2 user are minimally provided 2 hours UPS.\n> All VVoIP system devices including voice endpoints and portions of the LAN that supports C2R and non-C2/admin users (that is the balance of the VVoIP system) are provided some reasonable level (minimum 15 minutes / target 30 to 60 minutes) of UPS in support of emergency life-safety and security communications. \n> UPS systems supplying power to infrastructure that supports special-C2 and C2 users must also support environmental power (for example cooling power) such that equipment failures are prevented. This support may not need to be continuous but must be commensurate with the users supported (8 or 2hrs as appropriate).\nUPS.\n\nNOTE: UPS in support of C2R and non-C2/admin users\u2019 endpoints is best provided using POE particularly if supporting the general population. (Probably more cost effective than a battery under every desk). While support of all such endpoints and infrastructure is desirable since this provides greater availability, the cost could become a negating factor. In this case, a portion of the regular endpoints or emergency use endpoints could be provided at strategic locations within the facility to fulfill the requirement to support emergency life-safety and security communications. \n\nDetermine if the LAN supports Special-C2 or C2 users. If so, determine which part (or parts) of the LAN directly supports these users. Determine the method by which C2R and non-C2/admin users\u2019 emergency life-safety and security communications are supported. \n\nThis is a finding in the event, based on the interview; consideration has not been given to all aspects of backup power as described in the requirement. \n\nThis finding carries a severity of Cat II if the requirements supporting a Special-C2 or C2 user are deficient. This finding carries a severity of Cat III if the requirements supporting C2R or Non-C2/admin users are deficient.\n\nNOTE: The requirement here for UPS support for C2R or Non-C2/admin users communications is negated in the event that such users have an alternate reliable means of communicating in such situations. Personal and potentially even government provided cell phones are not the answer since there are many locations in DoD facilities where they are prohibited and/or signal availability is unreliable. An alternative to this could be to put a policy and SOP into effect that requires such users to evacuate the facility to a location where the appropriate communications capability is available. \n\n",
"description": "An uninterruptible power source for the LAN and VVoIP infrastructure is a necessity for the continued survivability, availability, and reliability of the VVoIP services. In traditional telecommunications systems the need for backup power is the same but it can be met generally at a single location, which is the phone switch location. The power required by the endpoints is generally provided by the phone switch to maintain basic dial tone services even though some \u201cdigital and feature phones require a local power supply. This is not possible in an IP/LAN based VVoIP network because the LAN infrastructure is geographically spread out to be within 100m cabling distance from each LAN endpoint. As such, the power, both primary and backup, must follow the NE to its location. Centrally located core equipment must also have a central uninterruptible power supply (UPS). The endpoints also need continuous power to maintain service. IP telephony endpoints require power to operate. This can be provided locally with a power brick (a small plug-in power adaptor/supply) and an AC outlet or can be provided by the LAN using Power Over Ethernet (POE) technologies. The UPS providing backup power to the LAN access switch can also provide backup power to the endpoint via POE if properly sized. If this is not the case, an individual UPS is required for each instrument supporting special C2 and C2 users of the proper capacity. Policy sets the minimum requirements for the backup power supplied to the VVoIP systems and the supporting LAN and VVoIP endpoints with emphasis on supporting C2 communications when primary power is lost. While this is a very valid case, it is also best practice, if not critical, to provide some level of backup power to the core systems, LAN, and endpoints that only support C2R and non-C2/admin users to support some level of reliable/survivable service, especially for emergency life-safety and security calls. NOTE: The requirement here for UPS support for C2R or Non-C2/admin users communications is negated in the event that such users have an alternate reliable means of communicating in such situations. Personal and potentially even government provided cell phones are not the answer since there are many locations in DoD facilities where they are prohibited and/or signal availability is unreliable. An alternative to this could be to put a policy and SOP into effect that requires such users to evacuate the facility to a location where the appropriate communications capability is available. The policy excerpts driving this requirement are as follows: From the UCR 5.3.1.7.5 Power Backup [Required: ASLAN \u2013 Conditional: Non-ASLAN] To meet CJCS requirements for assured services, equipment serving special C2 and C2 users must be provided with backup power. The ASLAN must meet the power requirements outlined at a minimum as follows: Special C2: The ASLAN must provide an 8-hour backup capability in the event of primary power loss to special C2 users. Any ASLAN product, Core, Distribution, or Access that supplies service to the special C2 user must have an 8-hour UPS. 2. C2: The ASLAN must provide 2 hour backup capability in the event of primary power loss to C2 users. Any ASLAN product, core, distribution or access, that supplies service to the C2 user must have a 2 hour uninterruptible power system (UPS). 3. C2(R) or Non-C2: C2(R) or non-C2 users may lose telephony service in the event of a power failure. NOTE: Backup Power (Environmental). The backup power system shall have the capacity to operate environmental systems needed to sustain continuous equipment operation. Power to the environmental systems may not need to be continuous. From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 with eight hours uninterrupted power supply. (b) Availability requirement for equipment/software serving C2 users is 0.99997 with two hours uninterrupted power supply. (c) Availability requirement for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2/admin users is 0.999 with no uninterrupted power supply. NOTE: While current DoD policy dictates that the VVoIP system as a whole only provide C2 and C2R users with specific durations of continued service during a power failure (as a cost saving measure), it is highly recommended that the entire system be provided some level of UPS. Traditional phone service is generally always available in a power failure since the endpoint or subscriber instrument is powered from the telephone switch. While there are exceptions to this regarding feature phones and some digital phones that need local power, for the most part all analog phones and others powered by the switch always work when local power is out. As noted above, VVoIP service is subject to disruption if power to the LAN infrastructure is disrupted. This can happen at various points since the LAN is a distributed (non-centralized) network. When implementing a VVoIP system without considering UPS power needs for the VVoIP controllers and endpoints as well as entire LAN, and supporting those needs with UPSs, we are reducing the availability of the telecommunications service that we are accustomed to. ",
"fixid": "F-20235r1_fix",
"fixtext": "Ensure an uninterruptible power supply (battery at a minimum; plus optional generator) is provided for all parts of the VVoIP infrastructure (Core LSC/MFSS, adjunct systems providing critical services, EBC, CER, LAN NEs, and endpoints as follows:\n> All devices including voice endpoints and portions of the LAN that directly support any single special-C2 user are minimally provided 8 hours UPS.\n> All devices including voice endpoints and portions of the LAN that directly supports any single C2 user are minimally provided 2 hours UPS.\n> All devices including voice endpoints and portions of the LAN that supports C2R and non-C2/admin users (that is the balance of the VVoIP system) are provided some reasonable level of UPS in support of emergency life-safety and security communications. \n> UPS systems supplying power to infrastructure that supports special-C2 and C2 users must also support environmental power (for example cooling power) such that equipment failures are prevented. This support may not need to be continuous but must be commensurate with the users supported (8 or 2hrs as appropriate).\nUPS \nNOTE: UPS in support of C2R and non-C2/admin users\u2019 endpoints is best provided using POE particularly if supporting the general population. (Probably more cost effective than a battery under every desk). While support of all such endpoints and infrastructure is desirable since this provides greater availability, the cost could become a negating factor. In this case, a portion of the regular endpoints or emergency use endpoints could be provided at strategic locations within the facility to fulfill the requirement to support emergency life-safety and security communications. \n\nInstall, upgrade, and maintain UPS systems as needed to meet the backup power requirements. \n",
"iacontrols": [
"COPS-2",
"DCBP-1",
"ECSC-1"
],
"id": "V-19535",
"ruleID": "SV-21597r1_rule",
"severity": "medium",
"title": "An uninterruptible power system (UPS) has not been designed or implemented to provide sufficient continuous backup power for the LAN Infrastructure, WAN boundary Infrastructure, VVoIP infrastructure, and/or VVoIP endpoints as required in support of special-C2 and C2 users system availability needs during a power outage OR sufficient backup power is not provided to C2-R or non-C2/admin user accessible endpoints, minimally in support of emergency life-safety and security calls.",
"version": "VVoIP 1220 (GENERAL)"
},
"V-19545": {
"checkid": "C-23792r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \nEnsure static addresses are assigned to the VVoIP core components within the dedicated VVoIP address space. \n\n",
"description": "Assigning static addresses to core VVoIP devices permits tighter control using ACLs on firewalls and routers to help in the protection of these devices.",
"fixid": "F-20238r1_fix",
"fixtext": "Ensure static addresses are assigned to the VVoIP core components within the dedicated VVoIP address space. \n\nWhen defining the VVoIP system implementation plan and addressing scheme, assign static addresses to the VVoIP core components\n",
"iacontrols": [
"DCBP-1",
"DCPA-1",
"ECSC-1"
],
"id": "V-19545",
"ruleID": "SV-21607r1_rule",
"severity": "medium",
"title": "VVoIP core components are not assigned static addresses within the dedicated VVoIP address space",
"version": "VVoIP 5220 (LAN)"
},
"V-19547": {
"checkid": "C-23797r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP core system or the TDM based telecom switch is managed via a local voice management network (OOB or in-band VLAN) and a DISN management network (e.g., RTS EMS, ADIMSS, ARDIMSS, or DCN), AND these two networks are interconnected for the management of one or more devices via the same management interface, ensure proper enclave boundary protection mechanisms and deny-by-default ACLs are placed at the entry point of the DISN management network to the local management network to block unauthorized access from either network to the other. Additionally ensure the enclave boundary protection configuration only permits specific protocols to flow between specific pairs of IP addresses across the boundary as required for proper operation of the management mission. Validate the effectiveness of the boundary protection on an annual basis.\n\nNOTE: Per EDDB-x proper boundary protection is defined as a firewall and IDS.\n\nNOTE: All intrusion alerts or alarms generated by the IDS or firewall should be reported in real time to the service level NOC and/or CNDSP NOC associated with each enclave with potential additional reporting to a DISN level NOC such as a TNOSC or GNOSC.\n\nDetermine who owns the enclave boundary protection device (e.g., a firewall) and therefore who is responsible for its configuration and management. This device could be owned and operated by the DISN management network or the local network. Or there could be two such devices owned and operated each entity.\n\nIf there is a single boundary protection device, additionally determine if there is a MOA regarding the operation of the device such that the owner implements a configuration that not only protects the owner\u2019s network but also protects the other\u2019s network. Further validate that both parties have agreed to or signed the MOA. If there is no such MOA, the respective owners may need to implement their own devices.\n\n",
"description": "VVoIP core system devices and TDM based telecom switches can be and in many cases are connected to multiple management networks. Such is the case when the system is managed by local SAs and systems via the local management VLAN or dedicated OOB management network and other SAs or systems manage or monitor the system via another network such as a remote MILDEP NOC, the DSN\u2019s ADIMSS network, the RTS EMS, or the DISN DCN. A similar situation occurs in the DRSN with the ARDIMSS network. In some cases, these networks are interconnected such that both management networks have access to the same devices via a single management port on each. Each of these management networks is in reality a different enclave and as such access and traffic between them must be filtered thus protecting each of the enclaves from compromise from one of the others. This intra-enclave protection is required by DoD IA policy (DoDD 8500.1) which states: \u201cdefend the perimeters of enclaves; provide appropriate degrees of protection to all enclaves and computing environments.\u201d More specifically DoDI 8500.2 IA controls EBBD-2 and EBBD-3 regarding Enclave Boundary Defense for sensitive and classified systems respectively state, in part, \u201cBoundary defense mechanisms to include firewalls and network intrusion detection systems (IDS) are deployed at the enclave boundary to the wide area network, at layered or internal enclave boundaries, and at key points in the network, as required.\u201d The key portion of these IA controls addressed here is the part that states \u201cat layered or internal enclave boundaries, and at key points in the network, as required.\u201d This is further qualified by the definition of an enclave which states in part: Enclave: A collection of computing environments connected by one or more internal networks under the control of a single authority and security policy, including personnel and physical security. Based on this definition, the local LAN enclave, remote MILDEP NOC, the DSN\u2019s ADIMSS network, the RTS EMS, and the DISN DCN are different enclaves. Therefore IA control EDDB-x is applicable and minimally a firewall is required where these enclaves meet. This requirement is generally applicable to VVoIP core system devices and TDM based telecom switches that are managed via multiple networks and specifically applicable to those where those systems and devices are managed via a single physical Ethernet/IP interface. As an example, if the ADIMSS and local SAs both manage a TDM switch or VVoIP system/device via a common pathway e.g., the local management VLAN or OOB management network, a firewall is required between the local network and the ADIMSS network. ",
"fixid": "F-20249r1_fix",
"fixtext": "In the event the VVoIP core system or the TDM based telecom switch is managed via a local voice management network (OOB or VLAN) and a DISN management network (e.g., RTS EMS, ADIMSS, ARDIMSS, or DCN), ensure proper enclave boundary protection mechanisms and ACLs are placed at the entry point of the DISN management network to the local management network to block unauthorized access from either network to the other. Additionally, ensure the enclave boundary protection configuration only permits specific protocols to flow between specific pairs of IP addresses across the boundary as required for proper operation of the management mission. Validate the effectiveness of the boundary protection on an annual basis.\n\nNOTE: Per EDDB-x proper boundary protection is defined as a firewall and IDS.\n\nNOTE: All intrusion alerts or alarms generated by the IDS or firewall should be reported in real time to the service level NOC and/or CNDSP NOC associated with each enclave with potential additional reporting to a DISN level NOC such as a TNOSC or GNOSC.\n\nIf there is a single boundary protection device, additionally determine if there is a MOA regarding the operation of the device such that the owner implements a configuration that not only protects the owner\u2019s network but also protects the other\u2019s network. Further validate that both parties have agreed to (signed) the MOA. If there is no such MOA, the respective owners may need to implement their own devices.\n\nImplement ACLs that provide a deny-by-default posture such that only the specifically required protocol traffic between specific pairs of IP addresses is permitted across the boundary. \n\nMore specifically, ACLs should be defined as follows:\nInbound ACL:\n> Permit the specifically authorized and required protocol sourced from the IP address of the specifically authorized device on the DISN management network to reach the specific IP address of the managed device or required local management server.\n> Additional statements for each protocol and IP address pair.\n>Deny all other traffic.\nOutbound ACL:\n> Permit the specifically authorized and required protocol sourced from the specific IP address of the managed device or any required local management server to reach the specific IP address of the specifically authorized device on the DISN management network.\n> Additional statements for each protocol and IP address pair.\n>Deny all other traffic.\n\nThe net result of this ACL is to permit authorized devices to communicate while blocking unauthorized access from the local management network and any attached workstations to the DISN management network and to block access from the DISN management network to all devices on the local management network other than the required managed devices or management servers. \n\nNOTE: An ACL statement is required for each IP address on the local management network that must communicate across the boundary to provide proper control. Defining ACLs to permit a subnet, while easiest, will not provide the proper control. This is supported by the previously started requirement that managed devices are all required to have static IP addresses. This requirement is extend to management servers and potentially to management workstations.\n\nValidate the effectiveness of the boundary protection ACLs on a regular basis and/or minimally on an annual basis by performing network vulnerability scans as follows:\n> Scan the entire DISN management network (e.g., RTS EMS, ADIMSS, ARDIMSS, or DCN), address space from an unused randomly selected IP address on the local management network. \n> Scan the entire local management network address space from an unused randomly selected IP address on the DISN management network.\nThe expected result is no response from any host on either network. \n\nNOTE: While this scan is useful in determining if the boundary protection works by blocking access from a randomly selected IP address, a more effective test would be to perform the scan from a randomly selected management workstation. A different workstation should be selected each time the scan is performed.\n\n",
"iacontrols": [
"EBBD-2",
"ECSC-1"
],
"id": "V-19547",
"ruleID": "SV-21610r1_rule",
"severity": "medium",
"title": "The voice/video system management network is not designed or implemented to provide the proper bidirectional enclave boundary protection between the local management network and the DISN Voice Services (VS) management network.",
"version": "VVoIP 5405 (LAN)"
},
"V-19562": {
"checkid": "C-23802r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure voice/video system (VVoIP system and/or TDM switch) management is segregated or separated from production traffic and other management traffic and such that access and traffic flow can be properly controlled and role based access is supported. \n\nNOTE: This can be implemented using a separate voice (VVoIP or TDM) system management VLAN or OOB network, the purpose of which is to provide for separation of access paths in support of separation of duties between the data network or server SAs and the VVoIP or TDM system SAs. This VLAN may be accessed from the general LAN management VLAN via a controlled ACL, gateway or firewall if needed.\n\nThis is a finding in the event the VVoIP system and LAN is not designed to provide the necessary separation of the management traffic and interfaces or such separation is not implemented as described above or at all.\n\n",
"description": "The management interface on any system/device is its Achilles heel. Unauthorized access can lead to complete corruption of the system or device, causing the loss of availability (denial-of-service), integrity, and information or communications confidentiality. As such management interfaces and the management traffic they transmit or receive must be protected. The most effective method for providing this protection is to establish a separate dedicated network for the purpose of managing systems, devices, and network elements. Such a network is typically called an out-of-band (OOB) management network. Such networks can be expensive to establish depending on the geographical placement of the managed devices. This protection can also be afforded the management interfaces and traffic on the same network as the production traffic uses, but the process is more difficult and protection requirements more stringent. This method is called In-Band management. When using in-band management, the most effective method for providing management interface and traffic protection is to establish a separate dedicated management VLAN on the production network. Another method for protecting management traffic is the use of secure protocols and encryption. The Network Infrastructure STIG defines the requirements for both in-band and OOB management. In-band management is permitted for the typically geographically disbursed network elements using a dedicated management VLAN and logically separate management interfaces on each NE. In general the management of VVoIP core systems and devices must follow the NI STIG/checklist guidance. This means that these systems/devices can be managed via an OOB management network or an in \u2013band VLAN. While this is the case, the this management access must be segregated from all other management VLANs on the network. The purpose of the separate VVoIP management VLAN or OOB network is to provide for separation of access in support of separation of duties between the data network or server SAs and the VVoIP system SAs. In some organizations these SAs are from different departments or just have different duties that don\u2019t require that they have access to all devices on the network. The VVoIP management VLAN or OOB network may be accessed from the general LAN management VLAN/OOB network or other management VLANs or networks via a controlled ACL, gateway. A firewall may be needed if crossing enclave boundaries. ",
"fixid": "F-20254r1_fix",
"fixtext": "Implement a dedicated OOB network or closed virtual In-band network (VLAN) for the VVoIP system and connect the core device management interfaces to it in compliance with the following requirement:\n\nEnsure VVoIP system management is segregated or separated from production traffic and other management traffic and such that access and traffic flow can be properly controlled and role based access is supported.\n\nNOTE: the purpose of the separate VVoIP management VLAN or OOB network is to provide for separation of access in support of separation of duties between the data network or server SAs and the VVoIP system SAs. This VLAN may be accessed from the general LAN management VLAN via a controlled ACL, gateway or firewall if needed.\n\n\n",
"iacontrols": [
"DCBP-1",
"DCPA-1",
"DCSP-1",
"ECSC-1"
],
"id": "V-19562",
"ruleID": "SV-21626r1_rule",
"severity": "medium",
"title": "The VVoIP system and LAN design does not provide the necessary segmentation and protection of the VVoIP system core device management traffic and interfaces such that role based access and traffic flow can be properly controlled.",
"version": "VVoIP 5505 (LAN)"
},
"V-19565": {
"checkid": "C-23804r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the LAN supports VVoIP system core or infrastructure equipment or multiple VVoIP VLANs, ensure the supporting LAN design contains one or more routing devices (router or layer 3 switch) to provide traffic control (support for required ACLs) between the various required VVoIP VLANs required for the core equipment. This device(s) should be as close to the VVoIP core equipment as possible. As such this is the intersection of these VLANs. \nNOTE: this does not have to be one device but could be several, particularly if the VVoIP equipment is split and geographically diverse in support of system survivability.\nNOTE: These devices may be (and typically will be) the core routing devices for the data LAN as well or may be dedicated to the VVoIP system.\n\n\n",
"description": "VLAN and IP address segmentation enables access and traffic control for the VVoIP system components. Only the required protocols are to reach a given VVoIP device thereby protecting it from non-essential protocols. This protection is afforded on the LAN by implementing ACLs based on VLAN/subnet, protocol and in some instances specific IP addresses. While a firewall placed between the core equipment and endpoint VLANs might provide better protection for the core equipment as a whole, a router is best suited to control the varying traffic patterns between the various devices. Normally a large B/C/P/S will have a large LAN and one or more LSCs supporting a large VVoIP phone system. In this case, it is within normal network design parameters to employ routing devices at the core of the LAN within the enclave. As such, the VVoIP system\u2019s core equipment would be connected to these routing devices or have one or more routing devices of its own. \n\nNOTE: It is recognized that small LANs and enclaves may not support VVoIP phone system core equipment as would be the case if they used a \u201cmanaged service\u201d or a remote LSC. In such a LAN the number of VLANs might be limited to one for data and one for VoIP. Also, a small LAN may not have a router at its core, potentially due to cost, thereby not having the capability of supporting multiple VVoIP VLANs. In this case, this requirement does not apply and all VVoIP endpoints and local VVoIP infrastructure equipment would be in a single VLAN. However, the use of a Layer 3 LAN switch instead of a dedicated router may be a cost effective method to meet this requirement for small LANs.\n \n",
"fixid": "F-20255r1_fix",
"fixtext": "Ensure the VVoIP system and supporting LAN design contains one or more routing devices (router or layer 3 switch) to provide traffic control (support for required ACLs) between the various required VVoIP VLANs.\n\nInstall the required routing equipment as close to the VVoIP core equipment as is practical and apply the required ACLs.\n",
"iacontrols": [
"DCBP-1",
"DCPA-1",
"DCSP-1",
"ECSC-1"
],
"id": "V-19565",
"ruleID": "SV-21629r1_rule",
"severity": "medium",
"title": "The VVoIP system and supporting LAN design does not contain one or more routing devices (router or layer-3 switch) or they are not implemented to provide support for required ACLs between the various required VVoIP VLANs.",
"version": "VVoIP 5510 (LAN)"
},
"V-19592": {
"checkid": "C-23862r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure all VVoIP system access to/from commercial dialup services (voice, video, fax, data) is via a locally implemented Media Gateway (MG) using a PRI or CAS trunk to a PSTN CO except as follows: \n\u2022 The enclave is small and has one or more PSTN subscriber lines terminated on individual phones, a dedicated key system, or a PBX, all of which are separate from the DoD VVoIP system. \n\u2022 The enclave is small and has one or more Commercial/Public VoIP subscriber lines or trunks terminated on an IP/Ethernet network that is separate from the DoD NIPRNet accessible network. (NOTE: This situation requires OSD GIG Waiver Panel approval for the required ISP connection.) \n\nNOTE: Trunks that support SS7 signaling and SS7 based signaling between a DoD network and a non-DOD network is prohibited.\n\nDetermine if the following exceptions apply:\n\u2022 Is the enclave small and does it have one or more PSTN subscriber lines terminated on individual phones, OR a dedicated key system, OR a dedicated PBX, all of which are separate from the DoD VVoIP system?\n\u2022 Is the enclave small and does it have one or more Commercial/Public VoIP subscriber lines or trunks terminated on an IP/Ethernet network that is separate from the DoD NIPRNet accessible network?\n\nThis is a finding in the event the site is not connected to the PSTN via a MG located within the local site enclave as described above AND one of the exceptions is not applicable.\n\n",
"description": "There are several reasons why VVoIP system access to commercial voice services (i.e., the PSTN) must be via a Media Gateway if exceptions do not apply. These reasons are as follows: \n> Most high capacity local commercial voice service (more than a few individual lines) is delivered from the carrier via TDM trunks. This requires the conversion to VoIP via a media gateway. \n> The implementation or receipt of commercial VoIP service from an Internet Telephony Service Provider (ITSP), would require the implementation of an Internet Service Provider (ISP) connection or a connection into the service provider\u2019s network via a VPN or dedicated TDM or optical circuit. In effect, a connection into the service provider\u2019s network would provide a path to the Internet. These types of local connections provide a \u201cback door\u201d into the local network that can place the entire DISN or GIG at risk from exploitation and can circumnavigate the protections put in place by the operators of the DISN (DISA). Such connections need to be specifically approved under CJCSI 6211.02C and DODI 4640.14. Such connections must also meet the requirements in the Network Infrastructure STIG for an \u201cApproved Gateway.\u201d This generally means that a full boundary architecture has to be implemented. Specific requirements for the implementation of commercial VoIP service will be defined later. NOTE: The term \u201cback door\u201d as used here means an illicit or UN-approved connection and is not intended to have the same meaning as the term \u201cbackdoor connection\u201d, as defined in RFC 2764, and used in the Network Infrastructure STIG. NOTE: A PRI or CAS trunk is required because the DSN is not permitted to exchange SS7 signaling with the PSTN. Doing so would place the DoD\u2019s SS7 network at risk. \nNOTE: The implementation of local ITSP connections to utilize commercial VoIP services at all BCPS would mean the implementation of an OSD / Gig Waiver Panel \u201capproved ISP gateway\u201d at each BCPS. This would amount to over 1000 direct connections between the Internet and the NIPRNet via the BCPS LAN. While these connections might be limited to VoIP only traffic, these would have the potential to be mis-configured in such a way that the connection provides an open \u201cback door\u201d for general access, Internet traffic, and attacks. This presents a huge risk to the DISN which is unacceptable. It is therefore highly unlikely that DoD will take such an approach and approve such connections.\n",
"fixid": "F-20290r1_fix",
"fixtext": "Ensure all VVoIP system access to/from commercial dialup services (voice, video, fax, data) is via a locally implemented Media Gateway (MG) using a PRI or CAS trunk to a PSTN CO except as follows: \n\u2022 The enclave is small and has one or more PSTN subscriber lines terminated on individual phones, a dedicated key system, or a PBX, all of which are separate from the DoD VVoIP system. \n\u2022 The enclave is small and has one or more Commercial/Public VoIP subscriber lines or trunks terminated on an IP/Ethernet network that is separate from the DoD NIPRNet accessible network. (NOTE: This situation requires OSD GIG Waiver Panel approval for the required ISP connection.) \n\nNOTE: Trunks that support SS7 signaling and SS7 based signaling between a DoD network and a non DOD network is prohibited.\n\n",
"iacontrols": [
"EBBD-1",
"EBBD-2",
"EBBD-3",
"ECSC-1"
],
"id": "V-19592",
"ruleID": "SV-21733r1_rule",
"severity": "medium",
"title": "The site\u2019s enclave boundary protection is not designed or implemented to route all VoIP traffic to/from a commercial number via a locally implemented Media Gateway (MG) connected to a PSTN CO using a PRI or CAS trunk.",
"version": "VVoIP 1015 (GENERAL)"
},
"V-19593": {
"checkid": "C-23865r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nAt each B/C/P/S, Ensure local analog or TDM commercial phone service is implemented in support of COOP for DoD calls and local emergency services. This applies to TDM or VVoIP systems conditionally as follows:\n\u2022 Via the sites local, on site, phone system/switch (TDM or VoIP) providing access to the local service from all work areas.\n\u2022 Via dedicated instruments (separate from the DoD site wide phone system) distributed throughout the facility and accessible within a short distance from every work area. NOTE: These dedicated instruments may be stand alone or may be part of a dedicated a key system, PBX, or VoIP network all of which are separate from the DoD VVoIP or TDM phone system.\n\nNOTE: The IA premise of this requirement is \u201cavailability\u201d and COOP. The purpose of this requirement is to provide local commercial service in the event the site is cut off from the DSN or a main site to which the local site is subtended and tethered (e.g., a small site that has no local switch/LSC and relies on the main site\u2019s switch/LSC for its calling capabilities. \n\nNOTE: This requirement supports calls to other DoD facilities in the event the DSN or DISN IP-VS connection is unavailable (i.e., some portion of the network is down preventing access) and is required in support of local emergency services calls.\n\nDetermine if the site has local commercial phone service.\n\nThis is a finding in the event the site has no local commercial phone service available.\n\nNOTE: This applies to all strategic BCPS, CONUS or OCONUS, large and small, main base (MOB), or tethered GSU, wherever \u201cfriendly\u201d local phone service is available and there is a need to call commercial numbers that are local to the site. \n\nNOTE: This does not apply to tactical sites in a war zone where \u201cfriendly\u201d local phone service is not available. It is recommended that local phone service be obtained if \u201cfriendly\u201d service is available\n\n",
"description": "Voice phone services are critical to the effective operation of a business, an office, or in support or control of a DoD mission. We rely on these services being available when they are needed. Additionally, it is critical that phone service is available in the event of an emergency situation such as a security breach or life safety event. The ability of maintaining the ability to place calls to emergency services must be maintained. While the DoD voice networks are designed to be extremely reliable, such that continuity of operations (COOP) is supported, there is the potential that a site will be cut off from the DoD network. Based on this fact, each physical site must maintain local commercial phone service in the event the site is cut off. While this works to maintain local emergency service availability for security and life safety emergencies, it also provides the capability to make calls between DoD sites using the commercial network. An additional, non IA benefit is that this supports the ability to make local calls without having to pay toll charges to call a local number via some distant regional access point. Local phone service can be delivered in a number of ways, all of which meet this requirement, while some of them must meet additional requirements to secure them. \n\nDelivery options are as follows: \n> PRI or CAS TDM trunks \n> Analog phone lines The type and amount of local phone service required can also depend upon the size of the site. \n\nThe following are some examples: \n> A large site or main operating base (MOB) could use PRI or CAS TDM trunks connected to the site\u2019s PBX. The larger the site the more trunks are used. \n> A small site or geographically separate unit (GSU) attached to a MOB. \n>> May have a PBX and be served similar to a large site. \n>> May be served by several analog phone lines terminated on discrete instruments or a key system. \n\nNOTE: The use of locally delivered commercial VoIP service is prohibited.\n",
"fixid": "F-20291r1_fix",
"fixtext": "Contract for and Install local commercial phone service commensurate with the size of the site and the following:\n\nEnsure local analog or TDM commercial phone service is implemented in support of COOP for DoD calls and local emergency services. This applies to TDM or VVoIP systems conditionally as follows:\n\u2022 Via the sites local, on site, phone system/switch (TDM or VoIP) providing access to the local service from all work areas.\n\u2022 Via dedicated instruments (separate from the DoD site wide phone system) distributed throughout the facility and accessible within a short distance from every work area. NOTE: These dedicated instruments may be stand alone or may be part of a dedicated a key system, PBX, or VoIP network all of which are separate from the DoD VVoIP or TDM phone system.\n\n",
"iacontrols": [
"COEF-1",
"DCBP-1",
"ECSC-1"
],
"id": "V-19593",
"ruleID": "SV-21734r1_rule",
"severity": "medium",
"title": "Local commercial phone service has not been implemented in support of COOP and local emergency services calls in the event the site is cut off from the DISN phone networks whether they are TDM of IP based.",
"version": "VVoIP 1225 (GENERAL)"
},
"V-19594": {
"checkid": "C-23866r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement: \n\nIn the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves, ensure the VVoIP system\u2019s WAN connection and boundary as well as its components including as their upgrades and changes are included in the site\u2019s enclave / LAN C&A documentation (i.e., the DIACAP Implementation Plan (DIP), System Identification Profile (SIP), Scorecard, etc.). \n\n> Review the baseline documentation and/or C&A documentation to verify that the VVoIP WAN boundary and/or modifications are included. Verify there is a procedure for approving changes to configuration.\n",
"description": "Documentation of the enclave / LAN configuration must include all VVoIP systems. If the current configuration cannot be determined then it is difficult to apply security policies effectively. Security is particularly important for VoIP technologies attached to the enclave network because these systems increase the potential for eavesdropping and other unauthorized access to network resources. Accurate network documentation is critical to maintaining the network and understanding its security posture, threats, and vulnerabilities. Baseline and C&A documentation is the vehicle by which the DAA receives security related information on the network for which he/she is personally responsible and accepts the security risk of operating the system. Additionally, When subscribing to DISN NIPRNet IP Voice Services (IPVS) or DISN SIPRNet IP Voice Services (IPVS) otherwise known as VoSIP, Or if the system connects to the DISN WAN for VVoIP transport between enclaves (such as in an Intranet), the enclave(s) must update their LAN / Enclave C&A and CAP documentation. The site must then seek an updated ATO/ATC or if necessary an IATO/IATC for the enclave\u2019s connection to the DISN for VVoIP from the appropriate DISN CAP office (UCAO or CCAO). Without connection approval the site will not be included in the DISN Voice Services dial plan. ",
"fixid": "F-20292r1_fix",
"fixtext": "In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves, ensure the VVoIP system\u2019s WAN connection and boundary as well as its components including as their upgrades and changes are included in the site\u2019s enclave / LAN C&A documentation (i.e., the DIACAP Implementation Plan (DIP), System Identification Profile (SIP), Scorecard, etc). \n\nAdd the VVoIP WAN boundary and/or its modifications to the site\u2019s enclave / LAN baseline and C&A documentation Obtain DAA approval for the updated documentation. Submit to the SRR team lead for validation and finding closure.\n",
"iacontrols": [
"DCHW-1"
],
"id": "V-19594",
"ruleID": "SV-21735r1_rule",
"severity": "medium",
"title": "The VVoIP system connection to the DISN WAN, its components, and/or changes to them are not included in the site\u2019s enclave / LAN baseline documentation and C&A documentation.",
"version": "VVoIP 6100 (DISN-IPVS)"
},
"V-19595": {
"checkid": "C-23867r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system within the enclave connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications between enclaves to any level of C2 user (Special C2, C2, C2(R)), ensure the system is integrated with (subscribed to) the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service (i.e., DISN NIPRNet IP Voice Services (IPVS) or DISN SIPRNet IP Voice Services (IPVS) otherwise known as VoSIP).\nNOTE: an exception is given for an enclave that is part of an Intranet if the intranet as a whole is subscribed to the appropriate DISN IPVS.\nNOTE: An exception is given for private VVoIP communications systems implemented amongst a small community of interest to fulfill a validated mission requirement. In this case, the system is essentially an intercom even though it might span enclave boundaries and the DISN.\n\nDetermine if the system is used to provide assured service communications between enclaves to any level of C2 user (Special C2, C2, C2(R)).\n \nThis is a finding in the event the VVoIP system within the enclave is connected to the DISN WAN for VVoIP transport but is not subscribes to or integrated with the DISN IPVS implemented on NIPRNet or SIPRNet. \n\nThis is not a finding in the event the VVoIP system within the enclave is integrated with a service level Intranet or if it is implemented as a private communications system (e.g., intercom) implemented amongst a small community of interest to fulfill a validated mission requirement.",
"description": "DISN IP based C2 Assured Service is about providing a highly available and reliable communications voice, video, and data service on a world wide scale that supports the command and control (C2) of military forces by all levels of command, from the lower echelons up to the president. While this is relatively easy for data transmission, this is not an easy task for voice and video communications, particularly when the state of the art for VoIP communications today has developed along different paths followed by each vendor. As such, VoIP communications has not been interoperable between different vendor\u2019s systems or between these systems and the various VoIP services that are available today. The task is made more difficult by the fact that the transport medium, that is IP networks, are generally not designed to transport time sensitive communications. Information contained in packets is transported in a manner that ensures the information will get to its destination reliably, although not in a specific amount of time. This is not acceptable for packetized voice and video since lost or delayed packets affects intelligibility of the communications. An additional aspect of assured service voice communications is that of call or message priority. Some calls, that are high priority C2 calls, must be completed at the expense of lower priority or routine calls. DISA has worked to overcome these issues by working with the many vendors that provide telecommunications equipment to the DoD to develop a highly available, reliable, and interoperable IP based assured service voice and video communications network to meet the needs of its C2 customers. Additional DoD policy dictates that DISN services be used as the first choice for DoD components to fulfill their long haul communications needs. For dialup voice, video, and data services the Defense Switched Network (DSN) has fulfilled this role for sensitive but unclassified communications. Similarly the Defense RED Switched Network (DRSN) has fulfilled this role for multi-level classified voice communications. \n\nAs DoD migrates to an all IP based DISN, the IP based voice services with the addition of video will fulfill this role into the future. A single vendor, classified, secret level, IP voice communications system has been implemented on SIPRNet which is currently called VoSIP. VoSIP stands for Voice over Secret (or secure) IP. This service and the supporting network are expected to provide assured service in the future. \n\nFor the purpose of this document, assured voice/video communications services (classified or unclassified) on the DISN is designated as DISN IP Voice Services (IPVS). \n\nAs such, if the VVoIP system within the enclave connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications between enclaves to any level of C2 user (Special C2, C2, C2(R)), the system must be integrated with (or subscribed to) the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service.\n\nNOTE: an exception might be given for private VVoIP communications systems implemented amongst a small community of interest to fulfill a validated mission requirement. \n",
"fixid": "F-20293r1_fix",
"fixtext": "In the event the VVoIP system within the enclave connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications between enclaves to any level of C2 user (Special C2, C2, C2(R)), ensure the system is integrated with (subscribed to) the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service (i.e., DISN NIPRNet IP Voice Services (IPVS) or DISN SIPRNet IP Voice Services (IPVS) otherwise known as VoSIP).\n\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19595",
"ruleID": "SV-21736r1_rule",
"severity": "medium",
"title": "The VVoIP system within the enclave is not subscribed to or integrated with the worldwide DISN IPVS network operating on the appropriately classified DISN IP WAN service",
"version": "VVoIP 6105 (DISN-IPVS)"
},
"V-19596": {
"checkid": "C-23868r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system is subscribed to the DISN NIPRNet IP Voice Services (IPVS) network, ensure the system and enclave boundary is designed to include one or more DOD APL listed CER(s) (Perimeter Router) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. \nNOTE: The CER is the enclave\u2019s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs.\nNOTE: If the DISN access circuits are dual homed, dual CERs should be implemented unless a single CER can provide uninterrupted (5 9s) connectivity to the DISN.\nNOTE: In the future this requirement may be applicable (with some modification) to the DISN SIPRNet IPVS (VoSIP) network when the PMO adopts the DISN NIPRNet IPVS architecture. \n\nDetermine, through interview and/or physical inspection, the specific make, model, and OS version of the CER.\n",
"description": "DISA has developed the DISN IPVS to support C2 Assured Service reliability and availability. As such, the worldwide availability and effectiveness of this service is dependant upon the components of the overall system that are located in each interconnected enclave. These components must be interoperable and support the needed quality of service. Therefore, if the VVoIP system in an enclave is to utilize the DISN IPVS to communicate with other enclaves across the NIPRNet, the system must be designed with equipment that has specific capabilities. Additionally, the implementation of VVoIP across the enclave boundary must not degrade the security or protection of the enclave. Use of the DISN IPVS network requires the following equipment such that interoperability is assured across the DISN service: > One or more DOD APL listed Customer Edge Routers (CERs) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. \n\nNOTE: The CER is the enclave\u2019s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. > One or more DOD APL listed Local Session Controller\u2019s (LSCs) or Multi-Function Soft Switch (MFSS) within the enclave for session control. These are the system control and signaling agents of the system. The LSC and MFSS are robust/reliable and provide admission control, and QOS features / capabilities as required by the UCR. The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (typically one per site) performs LSC functions for its site and provides signaling management for a regional set of LSCs. > Each LSC or MFSS and CER will be separated by a firewall or session border controller having specific functionality as defined in the UCR. This DoD specific device is called an Edge Boundary Controller (EBC). This may be a dedicated device or may be a functional part of the required data firewall. The use of these devices is critical to the success of the DISN IPVS\u2019s mission. Additionally, The typical perimeter or premise router (as designated by the NI and Enclave STIGs) will most likely not be capable of supporting the needs of VVoIP entering the DISN WAN. This is because only newer routers are capable of dealing with service classes and expedited forwarding. This why the DISN IPVS PMO specifies the specific additional capabilities required of the perimeter or premise router to support the needs of the Assures Service network. The router designated by the DISN IPVS PMO that is needed to support the service is called the Customer Edge Router (CER). This terminology is consistent with the terminology used by the DISN CORE PMO and other WAN service providers. The CER provides the following functionality: > Provides minimally four expedited forwarding cues (eight may be required in the future) > Places traffic within expedited forwarding cues based on the DSCP markings carried by the traffic > Routes AS-SIP-TLS packets and SRTP/SRTCP packets to the EBC function. (VVoIP firewall) > Routes all other traffic to the data firewall > Provides all of the filtering and security required of a perimeter or premise router as required by the NI STIG. \n\nNOTE: Proper DSCP marking of VVoIP packets is required to provide appropriate QoS for C2 priority calls in support of Assured Service. \n",
"fixid": "F-20294r1_fix",
"fixtext": "In the event the VVoIP system is subscribed to the DISN NIPRNet IP Voice Services (IPVS) network, ensure the system and enclave boundary is designed to include one or more DOD APL listed CER(s) (Perimeter Router) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. \nNOTE: The CER is the enclave\u2019s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs.\nNOTE: If the DISN access circuits are dual homed, dual CERs should be implemented unless a single CER can provide uninterrupted (5 9s) connectivity to the DISN.\nNOTE: In the future this requirement may be applicable (with some modification) to the DISN SIPRNet IPVS (VoSIP) network when the PMO adopts the DISN NIPRNet IPVS architecture. \n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19596",
"ruleID": "SV-21737r1_rule",
"severity": "medium",
"title": "One or more DOD APL listed Customer Edge Routers (CER) are not implemented as the DISN access circuit termination point for the DISN NIPRNet IPVS",
"version": "VVoIP 6115 (DISN-IPVS)"
},
"V-19597": {
"checkid": "C-23870r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system is subscribed to the DISN NIPRNet IP Voice Services (IPVS) network, ensure a DoD APL listed Edge Boundary Controller (EBC) is implemented at the enclave boundary between the CER and LSC/MFSS to maintain the required enclave boundary protection while permitting DISN IPVS traffic to pass.\nNOTE: This may be a dedicated device or may be part of the required data firewall. \nNOTE: In the future this requirement may be applicable (with some modification) to the DISN SIPRNet IPVS (VoSIP) network when the PMO adopts the DISN NIPRNet IPVS architecture. \n\nNOTE: The EBC functionality may be combined in one device with the required data firewall functionality.\n\nDetermine, through interview and/or physical inspection, the specific make, model, and OS version of the EBC.\n",
"description": "DISA has developed the DISN IPVS to support C2 Assured Service reliability and availability. As such, the worldwide availability and effectiveness of this service is dependant upon the components of the overall system that are located in each interconnected enclave. These components must be interoperable and support the needed quality of service. Therefore, if the VVoIP system in an enclave is to utilize the DISN IPVS to communicate with other enclaves across the NIPRNet, the system must be designed with equipment that has specific capabilities. Additionally, the implementation of VVoIP across the enclave boundary must not degrade the security or protection of the enclave. Use of the DISN IPVS network requires the following equipment such that interoperability is assured across the DISN service: > One or more DOD APL listed Customer Edge Routers (CERs) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. \n\nNOTE: The CER is the enclave\u2019s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. > One or more DOD APL listed Local Session Controller\u2019s (LSCs) or Multi-Function Soft Switch (MFSS) within the enclave for session control. These are the system control and signaling agents of the system. The LSC and MFSS are robust/reliable and provide admission control, and QOS features / capabilities as required by the UCR. The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (typically one per site) performs LSC functions for its site and provides signaling management for a regional set of LSCs. > Each LSC or MFSS and CER will be separated by a firewall or session border controller having specific functionality as defined in the UCR. This DoD specific device is called an Edge Boundary Controller (EBC). This may be a dedicated device or may be a functional part of the required data firewall. The use of these devices is critical to the success of the DISN IPVS\u2019s mission. \n",
"fixid": "F-20296r1_fix",
"fixtext": "Ensure a DOD APL listed Edge Border Controller (EBC) is implemented at the enclave boundary between the CER and LSC/MFSS to maintain the required enclave boundary protection while permitting DISN IPVS traffic to pass. \n\nNOTE: The EBC functionality may be combined in one device with the required data firewall functionality.\n\nAPL listed devices and software loads can be found at Access the DoD APL web site at http://jitc.fhu.disa.mil/tssi/apl.html.\n\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19597",
"ruleID": "SV-21738r1_rule",
"severity": "medium",
"title": "A DOD APL listed Edge Boundary Controller (EBC) is not implemented as the DISN NIPRNet boundary to maintain the required enclave boundary protection while permitting DISN IPVS traffic to pass.",
"version": "VVoIP 6120 (DISN-IPVS)"
},
"V-19598": {
"checkid": "C-23872r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system within the enclave is interconnected with other VVoIP systems across the WAN, ensure the required internal Network IDS (NIDS) is implemented such that it monitors the traffic to/from both the data firewall (function) and the required VVoIP firewall/EBC (function). \nNOTE: This is applicable whether the VVoIP system is integrated with the DISN IPVS or not.\n\nThis is a finding in the event the NIDS is not implemented such that it sees traffic from the VVoIP firewall (EBC or other) as well as the data firewall.\n\nNOTE: The NIDS monitoring the VVoIP firewall may be the same device that monitors the data firewall or it may be a separate device. In the event it is a separate device, it is subject to all Network Infrastructure STIG requirements to include CNDSP monitoring if applicable.\n\nNOTE: The Network Infrastructure STIG recognizes that many of today\u2019s NIDS are also intrusion prevention devices. The NI STIG refers to the required NIDS as an Intrusion detection/Prevention System (IDPS). \n",
"description": "The purpose of the Internal Network IDS is to provide a backup for the enclave firewall(s) in the event they are compromised or mis-configured such that traffic which is normally blocked ends up being passed as well as to detect other malicious activity entering (or leaving) the enclave. As such the NIDS must be implemented in such a manner that it monitors all traffic flowing through the data and VVoIP firewalls. Minimally, it will detect improper data protocol traffic coming through the VVoIP firewall. While the NIDS will not be able to inspect the VVoIP signaling and bearer packet payload due to its encryption, it could detect anomalous behavior in the flow of these packets.\n\nAdditionally, per the NI STIG, the NIDS is required to be a separate device from the firewall for reliability reasons. If the common firewall/IDS platform is compromised, both the firewall and IDS is vulnerable. \n",
"fixid": "F-20297r1_fix",
"fixtext": "In the event the VVoIP system within the enclave is interconnected with other VVoIP systems across the WAN, ensure the required internal Network IDS (NIDS) is implemented such that it monitors the traffic to/from both the data firewall (function) and the required VVoIP firewall/EBC (function).\n\nNOTE: This is applicable whether the VVoIP system is integrated with the DISN IPVS or not.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19598",
"ruleID": "SV-21739r1_rule",
"severity": "medium",
"title": "The network IDS is not configured or implemented such that it can monitor the traffic to/from the required VVoIP firewall/EBC (function) as well as the traffic to/from the data firewall (function).",
"version": "VVoIP 6125 (DISN-IPVS)"
},
"V-19599": {
"checkid": "C-23875r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system within the enclave is integrated with the unclassified DISN IPVS network, ensure the system is designed to include one or more DOD APL listed LSCs or a MFSS for call/session control within the enclave. \n \nNOTE: The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (one per site and potentially a backup LSC) performs LSC functions for its site and provides signaling management for a regional set of LSCs. An MFSS is a backbone device and is only required at DISN IPVS PMO designated locations.\n\nNOTE: The LSC and MFSS are robust/reliable and provide admission control, and QoS features / capabilities as required by the UCR.\n\nNOTE: in the future this requirement may be applicable (with some modification) to the classified DISN IPVS network when the PMO adopts the unclassified DISN IPVS architecture.\n\nDetermine, through interview and/or physical inspection, the specific make, model, and OS version of the LSCs and/or MFSS.\n",
"description": "DISA has developed the DISN IPVS to support C2 Assured Service reliability and availability. As such, the worldwide availability and effectiveness of this service is dependant upon the components of the overall system that are located in each interconnected enclave. These components must be interoperable and support the needed quality of service. Therefore, if the VVoIP system in an enclave is to utilize the DISN IPVS to communicate with other enclaves across the NIPRNet, the system must be designed with equipment that has specific capabilities. Additionally, the implementation of VVoIP across the enclave boundary must not degrade the security or protection of the enclave. \n\nUse of the DISN IPVS network requires the following equipment such that interoperability is assured across the DISN service:\n> One or more DOD APL listed Customer Edge Routers (CERs) on which the DISN access circuits are terminated. The CER is robust/reliable and provides QOS features / capabilities as required by the UCR for the specific type of site. NOTE: the CER is the enclave\u2019s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs.\n> One or more DOD APL listed Local Session Controller\u2019s (LSCs) or Multi-Function Soft Switch (MFSS) within the enclave for session control. These are the system control and signaling agents of the system. The LSC and MFSS are robust/reliable and provide admission control, and QOS features / capabilities as required by the UCR. The LSC (one or more per site) manages local endpoint registration and calls established to/from local endpoints and facilities. Also manages calls into and out of the enclave. The MFSS (typically one per site) performs LSC functions for its site and provides signaling management for a regional set of LSCs. An MFSS is a backbone device and is only required at DISN IPVS PMO designated locations.\n> Each LSC or MFSS and CER will be separated by a firewall or session border controller having specific functionality as defined in the UCR. This DoD specific device is called a Edge Boundary Controller (EBC). This may be a dedicated device or may be a functional part of the required data firewall. \n\nThe use of these devices is critical to the success of the DISN IPVS\u2019s mission\n\nNOTE: As noted in the LAN section, on a large facility (site) the primary LSC should have a backup LSC that is geographically separate from it. This is also applicable to a facility/site that has a MFSS. While the MFSSs work in pairs in the backbone and are therefore redundant with regard to backbone services, their LSC functionality should also be redundant. \n",
"fixid": "F-20298r1_fix",
"fixtext": "In the event the VVoIP system within the enclave is integrated with the unclassified or classified DISN IPVS network, ensure the system is designed to include one or more DOD APL listed LSCs or a MFSS for call/session control within the enclave.\n\nAn MFSS is a backbone device and is only required at DISN IPVS PMO designated locations.\n\nAPL listed devices and software loads can be found at Access the DoD APL web site at http://jitc.fhu.disa.mil/tssi/apl.html.\n\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19599",
"ruleID": "SV-21740r1_rule",
"severity": "medium",
"title": "One or more DOD APL listed Local Session Controller\u2019s (LSCs) or Multi-Function Soft Switch (MFSS) are not implemented within the enclave for DISN IPVS session control.",
"version": "VVoIP 6130 (DISN-IPVS)"
},
"V-19600": {
"checkid": "C-23877r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure Session Admission Control (SAC) for the DISN Core access circuit(s) is supported by engineered bandwidth budgets for VoIP and Video calls/sessions in support of Assured Service.\nNOTE: SAC in support of Assured Service is also referred to as Assured Service Admission Control (ASAC)\nNOTE: The VoIP budget covers the following types of services: Voice VoIP, FoIP, MoIP, or SCIP over IP calls\nNOTE: Per call/session units are defined in the UCR and are unidirectional. They must be doubled to support bi-directional communications between users which is the typical phone call. \n\nThis is a finding in the event there is no evidence that the required budgets have been calculated and/or the access circuit has not been sized accordingly.\n",
"description": "The DISN NIPRNet IPVS PMO has developed a method to provide Assured Service voice and video communications over the bandwidth constrained portion of the DISN. This method includes or supports providing precedence and priority capabilities for C2 users similar to the MLPP service provided by the traditional TDM based DSN. The enclave\u2019s internal LAN is required to be designed to be non-blocking. That is it must provide ample bandwidth for all the traffic that it is expected to carry. This is controllable by DoD. On the other hand, the DISN Core is designed to have ample bandwidth and expandability to support what ever traffic the DoD enclaves throw at it. As such it is considered to be bandwidth rich. Due to issues surrounding the ability for an attached enclave to determine the bandwidth availability or congestion conditions within the core in real time, an assumption has to be made that the DISN Core is also non-blocking. The DISN Core bandwidth is also controllable by DoD. The portion of the overall DISN network that is bandwidth constrained is the TDM or optical OCx access circuits between the local enclave and the DISN Core. This is the portion of the network where we have the least control over bandwidth availability, primarily due to the cost of these circuits. The cost factor is an issue since many DISN access circuits must rely on commercial carriers for some portion of the overall circuit. This is typically the portion that delivers the DISN service to the B/C/P/S. Access circuit issues are less of an issue if the B/C/P/S also provides a home for one of the DISN Core SDNs. This is because a direct connection can be made between the CER and the SDN, however, the circuit capacity may still be an issue if the SDN is a small one that does not have an AR or PE. Due to the nature of digital transmission over these bandwidth constrained circuits, the quality and availability of the communications is degraded as these circuits become congested. \u201cData\u201d packets can wait until processed without negatively affecting the delivery of a message. This is not the case for VVoIP due to its time sensitive nature (it is a real time service). If VVoIP packets have to wait for transmission, the quality of the call suffers. In IA terms, this relates to the availability of the service and quality communications. To overcome the bandwidth constraints inherent in WAN access circuits, an engineered bandwidth budget must be developed for each service (voice, video, and data) using the circuit. Voice and video budgets are developed in terms of call or session counts. For example, the UCR defines a voice call as follows: \u201cOne voice session budget unit shall be equivalent to 110 kilobits per second (kbps) of access circuit bandwidth independent of the EI codec used. This includes ITUT Recommendation G.711 encoding rate plus Internet Protocol Version 6 (IPv6) packet overhead plus ASLAN Ethernet overhead. IPv6 overhead, not IPv4 overhead, is used to determine bandwidth equivalents here.\u201d \n\nNOTE: This budget is unidirectional and must be doubled for bi-directional communications sessions. \n\nNOTE: The VoIP budget covers the following types of services: Voice VoIP, FoIP, MoIP, or SCIP over IP calls The UCR also defines a video call as follows: \u201cSince the bandwidth of a video session can vary [depending upon video resolution (ed)], video sessions will be budgeted in terms of video session units (VSUs). One VSU equals 500 kbps and bandwidth for video sessions will be allocated in multiples of VSUs. For example, the bandwidth allocated to video sessions may be 500 kbps, 1000 kbps, and 2500 kbps. Thus, a video session that requires 2500 kbps will be allocated five VSUs.\u201d \n\nNOTE: This discussion, as it relates to video, is in regard to video sessions controlled by the LSC using AS-SIP for the signaling protocol. H.323 signaled video and/or VTC sessions must be considered separately and potentially have their own budget for access circuit bandwidth. \n\nNOTE: This budget (which also includes the audio component) is unidirectional and must be doubled for bi-directional communications sessions. When developing the bandwidth budgets, the engineer must determine how many simultaneous voice and video calls/sessions are to be supported by the access circuit based upon the unit per call defined in the UCR. The bandwidth budget to be reserved for voice is then calculated along with a budget for video. Next the engineer must determine what percentage of the overall access circuit bandwidth these reserved budgets should consume. The access circuit is then sized (ordered) to accommodate the needs. It is not recommended that IP voice and video capabilities be added to an existing circuit since this would mean the call/session counts would have to be restricted or the data budget would have to be squeezed. \n\nNOTE: Data traffic is permitted to surge into the voice and video budgets if the bandwidth is available; however the voice and video budgets are reserved and will be reclaimed if needed. Voice and video is not permitted to surge into the data budget since ASAC needs a fixed call count to be effective. \n\nNOTE: Instructions for determining voice call budgets for a DISN WAN access circuit can be found in the UCR section 5.3.3.11 Provisioning \n",
"fixid": "F-20299r1_fix",
"fixtext": "In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure Session Admission Control (SAC) for the DISN Core access circuit(s) is supported by engineered bandwidth budgets for VoIP and Video calls/sessions in support of Assured Service.\nNOTE: SAC in support of Assured Service is also referred to as Assured Service Admission Control (ASAC)\nNOTE: The VoIP budget covers the following types of services:\nVoice VoIP, FoIP, MoIP, or SCIP over IP calls\nNOTE: Per call/session units are defined in the UCR and are unidirectional. They must be doubled to support bi-directional communications between users which is the typical phone call. \nNOTE: Instructions for determining voice call budgets for a DISN WAN access circuit can be found in the UCR section 5.3.3.11 Provisioning\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19600",
"ruleID": "SV-21741r1_rule",
"severity": "medium",
"title": "The DISN Core access circuit is NOT properly sized to accommodate the calculated Assured Service Admission Control (ASAC) budgets for AS voice and video calls/sessions OR the required budgets have not been calculated.",
"version": "VVoIP 6155 (DISN-IPVS)"
},
"V-19601": {
"checkid": "C-23879r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure the enclave is dual homed to two geographically diverse DISN SDNs and DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers.\n\nNOTE: This means there are two DISN (or commercial) access circuits (many circuits will have a commercial component, typically the \u201clast mile\u201d) from the site/enclave to the DISN SDNs.\n\nNOTE: This assumes the site/enclave is NOT collocated with a DISN SDN such that a direct Ethernet or optical connection can be made. \n\nNOTE: If a site is located at a DISN SDN and is able to directly connect to the SDN using Ethernet or optical connections, the site may be able to rely on the dual homing of the SDN into the core. However, the site must still be homed to two geographically diverse ARs. This is dependant upon the size or type of the SDN. A large site directly connected to a smaller SDN will implement an access circuit to a geographically diverse SDN (i.e., another SDN in another location remote from the local SDN. This should not be one of the SDNs that to which the local SDN is homed. \n\nDetermine if the site supports any level of C2 user. Determine how many access circuits are implemented and to what SDN they are homed. Additionally, determine the ARs or PEs to which the enclave is homed.\n\nThis is a finding in the event the site is a C2 site and the DISN access circuits between the enclave\u2019s WAN boundary and the DISN is not redundant and diverse as described in the requirement and notes. \n\nThis is not a finding in the event the site does not support any level of C2 user.",
"description": "Redundancy and dual homing is used within the DISN core to provide for continuity of operations (COOP) in the event a piece of equipment, circuit path, or even an entire service delivery node is lost. DoD policy also requires DoD enclaves that support C2 users for data services to be dual homed to the DISN core SDNs. This means that there will be two physically separate access circuits from the enclave to two geographically diverse DISN SDNs. Once the access circuits arrive at the SDNs, the circuits need to be connected to two geographically diverse DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers. Depending upon the size of the SDN, one or both of the access circuits must be extended to another SDN containing the AR or PE. AR\u2019s are also dual homed to geographically diverse DISN PE routers. A single circuit provides far less redundancy and reliability than dual circuits This redundancy is required to increase the availability of the access to the DISN core so that there is more chance that assured service can be achieved. This need extends to assured service C2 VVoIP communications and is why we check it here.",
"fixid": "F-20300r1_fix",
"fixtext": "In the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure the enclave is dual homed to two geographically diverse DISN SDNs and DISN WAN Service (NIPRNet or SIPRNet) routers.\n\nNOTE: This means there are two DISN (or commercial) access circuits (many circuits will have a commercial component, typically the \u201clast mile\u201d) from the site/enclave to the DISN SDNs.\n\nNOTE: This assumes the site/enclave is NOT collocated with a DISN SDN such that a direct Ethernet or optical connection can be made.. \n\nNOTE: If a site is located at a DISN SDN and is able to directly connect to the SDN using Ethernet or optical connections, the site may be able to rely on the dual homing of the SDN into the core. However, the site must still be homed to two geographically diverse ARs. This is dependant upon the size or type of the SDN. A large site directly connected to a smaller SDN will implement an access circuit to a geographically diverse SDN (i.e., another SDN in another location remote from the local SDN. This should not be one of the SDNs that to which the local SDN is homed.",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19601",
"ruleID": "SV-21742r1_rule",
"severity": "medium",
"title": "The enclave is NOT dual homed to two geographically diverse DISN SDNs and DISN WAN Service (NIPRNet or SIPRNet) Aggregation Routers (AR) or DISN Provider Edge (PE) routers.",
"version": "VVoIP 6135 (DISN-IPVS)"
},
"V-19602": {
"checkid": "C-23881r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event dual homed DISN core access circuits are implemented as required to serve the enclave, ensure each circuit has the same capacity such that one is able to support the entire engineered bandwidth needs of the enclave.\nNOTE: Each circuit must be engineered to include additional bandwidth to support higher levels of both data and VVoIP communications in time of crisis.\n\nDetermine if the site is dual homed via dual access circuits. Determine the size of both access circuits. Determine the engineered bandwidth needs for the enclave connection to the WAN. \n",
"description": "Providing dual homed access circuits from a C2 enclave to the DISN core is useless unless both circuits provide the same capacity to include enough overhead to support surge conditions. If one circuit is lost due equipment failure or facility damage, the other circuit must be able to carry the entire engineered load for a single circuit servicing the site. Additionally, the engineered capacity must take additional bandwidth into account to support higher levels of both data and VVoIP communications in time of crisis. ",
"fixid": "F-20301r1_fix",
"fixtext": "Ensure a bandwidth engineering study is performed to determine the WAN bandwidth needs for the site to include surge capacity.\n\nEnsure each redundant DISN Core access circuit has the same capacity such that one is able to support the entire engineered bandwidth needs of the enclave.\n\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19602",
"ruleID": "SV-21743r1_rule",
"severity": "medium",
"title": "The dual homed DISN core access circuits are NOT implemented such that each one can support the full bandwidth engineered for the enclave plus additional bandwidth to support surge conditions in time of crisis.",
"version": "VVoIP 6140 (DISN-IPVS)"
},
"V-19603": {
"checkid": "C-23883r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system connects to the DISN WAN for VVoIP transport between enclaves AND the system is intended to provide assured service communications to any level of C2 user (Special C2, C2, C2(R)), ensure the required dual homed DISN Core or NIPRNet access circuits follow geographically diverse paths from the CER(s) along the entire route to the geographically diverse SDNs. Each circuit will use different facilities such as cables, demarks, and digital cross connects in geographically diverse locations. \nNOTE: Geographic and facilities diversity will be maintained on-site and off-site.\n\nThis is a finding in the event the required dual-homed circuits follow the same path or are close enough to be damaged by a single event.\n\nNOTE: The paths taken by the access circuits must remain significantly separate for their entire length such that a single point of failure is not created. \n",
"description": "In previous requirements we discussed the need for redundant DISN Core access circuits between the enclave and the DISN SDNs. Another method for providing the greatest reliability and availability for DISN services is to provide redundancy in the network pathways between the customer site and the redundant DISN SDNs. The DISN core network is designed to be highly reliable and available in support of the DoD mission, the most vulnerable part of the network is the access circuit from the enclave to the core and the path it takes from the SDN to the customer\u2019s site. Therefore redundant access circuits should be provisioned. Physical pathways for communications network access circuits are vulnerable to physical disruption from a variety of threats, both natural and man made. These threats range from storm damage (falling trees, floods, to being damaged or dug up by \u201cthe big yellow fiber-finder\u201d (backhoe); to rampaging vehicles attacking utility poles; to malicious acts including war and terrorism. To overcome the physical threat, the redundant circuits should follow geographically diverse paths. ",
"fixid": "F-20302r1_fix",
"fixtext": "Ensure dual homed DISN Core or NIPRNet access circuits follow geographically diverse paths from the CER(s) along the entire route to the geographically diverse SDNs. \n\nEnsure each circuit uses different facilities such as cables, demarks, and digital cross connects in geographically diverse locations. \n\nEnsure geographic and facilities is maintained on-site and off-site.\n\nEnsure the paths taken by the access circuits remain significantly separate along their entire length such that a single point of failure is not created.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19603",
"ruleID": "SV-21744r1_rule",
"severity": "medium",
"title": "The required dual homed DISN Core or NIPRNet access circuits DO NOT follow geographically diverse paths from the CER(s) along the entire route to the geographically diverse SDNs.",
"version": "VVoIP 6145 (DISN-IPVS)"
},
"V-19604": {
"checkid": "C-23886r1_chk",
"checktext": "Inspect the redundant facilities and equipment to determine compliance with the requirement.\n\nThis is a finding in the event dual sets of CER, EBC, and LSC are NOT implemented that are housed in redundant facilities in geographically diverse locations.\n\nNOTE: If it is determined, following a cost vs benefit study and risk analysis, that redundant facilities containing dual sets of CER, EBC, and LSC are not warranted, for the given site, this should be marked as a finding and the justification included in the POA&M such that the DAA is cognizant of and can accept the risk.\n",
"description": "The enhanced reliability and availability achieved by the implementation of redundancy and geographic diversity throughout the DISN Core along with the implementation of dual homed circuits via geographically diverse pathways and facilities is negated if both access circuits enter the enclave via the same facility containing a single (or dual) CER connected to a single (or dual) EBC. It does not matter how reliable, redundant, and robust the CER, EBC, and power supply is (required to be 5 \u2013 9s reliable), the facility housing this equipment represents a single point of failure. While this may be deemed to not be an issue for a small number of C2 users, the more C2 supported by the system, the greater the issue because all communications would be cut off in the event the facility is lost or severely damaged. Even less severe eventualities may also severely limit the capability of the system to support reliable communications. The mitigation for this system wide vulnerability is to implement redundant facilities to which the geographically diverse pathways containing the dual homed access circuits can run and terminate on redundant, geographically separated sets of CERs, EBCs, and core LAN equipment. LSCs can also be separated in this manner.\n\nUnderstandably, the mitigation for this issue is costly and facilities housing critical communications infrastructure are not lost very often. However, the cost of mitigating this vulnerability must be weighed against the loss of critical communications, particularly in time of crisis. If the site supports large numbers of high level C2 users or special C2 users, the cost of losing communications may outweigh the cost of providing redundant facilities. Another aspect of the loss of communications is that access to emergency services via the communications system would also be lost. The more users affected by such a loss the more the potential need to place calls to emergency services. \n\nAs such, all sites, large and small can benefit from the implementation of redundant facilities and equipment. \n\nNOTE: The threat to strategic facilities is far greater from natural causes than from damage due to acts of war or terrorism, but all threats need to be considered. On the other hand, tactical facilities naturally have a higher vulnerability to acts of war, which are raised on a par with or exceed the vulnerability posed my natural events.\n",
"fixid": "F-20303r1_fix",
"fixtext": "Ensure dual sets of CER, EBC, and LSC are implemented that are housed in redundant facilities in geographically diverse locations within the site such that if one of locations is lost or isolated from the network, communications service is maintained. \n\nNOTE: If a site has a MFSS, a backup LSC should be implemented in a geographically diverse location.\n\nIf it is determined that meeting this requirement is not warranted as based upon a cost vs benefit study and risk analysis, take the finding and justify it such that the DAA is cognizant of and can accept the risk.\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-19604",
"ruleID": "SV-21745r1_rule",
"severity": "low",
"title": "Dual sets of CER, EBC, and LSC are NOT implemented in geographically diverse locations within a site supporting large numbers of C2 users",
"version": "VVoIP 6150 (DISN-IPVS)"
},
"V-21506": {
"checkid": "C-25737r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event hardware based instruments are implemented in a COOP capacity for backup or emergency communications, and such instruments are not regularly used, the IAO will ensure the functionality of these instruments by implementing and documenting a testing program which will include the documentation of the results of each test. \n\nNOTE: The frequency of testing for each instrument is variable but should minimally be monthly. Weekly, daily, or randomly within a monthly cycle is better. Testing may be made the responsibility of the user(s) the instrument serves providing they document their tests. The test could minimally involve determining if dial tone is present (unless generated within the phone as with some VoIP phones), but should include the placement of a call to an emergency number. \n\n\n\n\n",
"description": "Backup/COOP or emergency telephones are useless if they don\u2019t work. Thus they need to be tested regularly to ensure their functionality, particularly if they are not used regularly. Regular use will detect non functionality issues quickly. If not regularly used, service can be disrupted and the phone rendered inoperable without detection until a situation arose requiring its use. There\u2019s nothing worse than a non functional communications device in an emergency situation. \n\nAs such, a regular testing plan for backup/COOP or emergency telephones must be developed and documented that includes a record of the tests performed. The records of the test should include such information as the instrument being tested, date and potentially the time the test was performed, the name of the person performing the test, and whether the phone is functional or not. Additional information should be added if the phone is found to be non-functional such as maintenance actions taken and when service was restored.\n\n The frequency of testing for each instrument is variable but should minimally be monthly. Weekly, daily, or randomly within a monthly cycle is better. Testing may be made the responsibility of the user(s) the instrument serves providing they document their tests.\n\nTesting should include the placement of a call. While testing for the presence of dial tone could be a minimal test, this may not be an accurate indicator that a call can be completed.\n",
"fixid": "F-22295r1_fix",
"fixtext": "In the event hardware based instruments are implemented in a COOP capacity for backup or emergency communications, and such instruments are not regularly used, the IAO will ensure the functionality of these instruments by implementing and documenting a testing program which will include the documentation of the results of each test. \n\nNOTE: The frequency of testing for each instrument is variable but should minimally be monthly. Weekly, daily, or randomly within a monthly cycle is better. Testing may be made the responsibility of the user(s) the instrument serves providing they document their tests. The test could minimally involve determining if dial tone is present (unless generated within the phone as with some VoIP phones), but should include the placement of a call to an emergency number. \n\n",
"iacontrols": [
"DCBP-1"
],
"id": "V-21506",
"ruleID": "SV-23715r1_rule",
"severity": "low",
"title": "Regular documented testing of hardware based COOP/backup or emergency telephones is not performed in accordance with a documented test plan or related documentation is deficient or non existent. ",
"version": "VVoIP 1921 (GENERAL)"
},
"V-21507": {
"checkid": "C-25739r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure mitigations are implemented against sensitive data exfiltration via IP based voice/video communications systems as follows:\n>Filter/monitor IP media traffic through Media Gateways (MGs), Session Border Controllers (SBCs), and Edge Border Controllers (EBCs) to detect and block/inhibit the exfiltration of sensitive DoD data from the network via VVoIP RTP/SRTP communications sessions.\n> Enable appropriate alarms and security event auditing/logging on these filters such that network security personnel and administrators can take appropriate action.\n\nDetermine the following: \n> The type(s) of connections to external networks: \n>> Traditional switch trunks connected to a VVoIP system via a MG.\n>> A VVoIP system connected to an external IP WAN (DISN U-IPVS or ITSP) via a SBC or EBC.\n\nThis is a finding in the event one or more of the following conditions exist:\n> Traditional switch trunks are connected to a VVoIP system via a MG without a RTP/SRTP data exfiltration filter between the MG and the VVoIP system endpoints.\n>> The VVoIP system is connected to an external IP WAN (DISN U-IPVS or ITSP) via a SBC or EBC without a RTP/SRTP data exfiltration filter within the SBC/EBC or between the SBC/EBC and the VVoIP system endpoints.\n\n",
"description": "The voice and video communications network provides an often overlooked pathway to spirit sensitive data out of an enterprise network without the likelihood of detection. Data exfiltration presents a huge vulnerability to any data that is stored within any enterprise and especially sensitive data. The DoD\u2019s data is no less vulnerable. While predominantly an insider threat at this time, as EoIP technology progresses, the bad actors will find external methods to get at and exfiltrate our data through this covert channel that does not require insider activities. \n\nThe traditional pathway to exploit this vulnerability is via a modem and the traditional voice network. The modem was invented to transfer data via the traditional telephone system. A modem can easily be connected to a phone line and a server or workstation (if not already embedded,), a outbound call can be made to an external computer\u2019s modem, and data can flow easily, albeit slowly. To mitigate this threat, we institute both policy and technological mitigations such as specifically authorizing modem use; disabling an embedded modem while its host is connected to a computer network, and others. While modem usage for day-to-day data transfers and network access is dwindling at the enterprise level, many devices today still require the use of a modem. These are FAX machines, traditional secure telephones, and traditional secure VTC systems. As part of a layered defense against enterprise data exfiltration via a modem; detection, filtering, blocking, and call admission control mechanisms can be placed on traditional telephone switch trunks to detect unauthorized modem traffic and take appropriate action. Generally speaking, all modem traffic should be blocked with permissions established for pre-authorized devices on a specific line-by-line, case-by-case basis. Such technologies exist today.\n\nToday\u2019s technology is taking us swiftly toward a totally converged IP based data and communications network. This can be referred to as Everything over IP (EoIP). As this trend continues the many vulnerabilities and threats that we have been dealing with for years on our data networks are extended to our voice and video communications networks. The threat of sensitive enterprise data exfiltration via the data network is nothing new, and mitigations have been developed to address the various methods and exploits. However, little or nothing has been done to date to address the covert channel through our VoIP communications infrastructure whether connected to a traditional telephone network via a Media Gateway (MG), or to an IP WAN via a Session Border Controller (SBC), or Edge Border Controller (EBC). VVoIP aware firewalls generally address signaling issues and vulnerabilities, but do little to address those of the media streams. \n\nA data exfiltration exploit using the VVoIP network would look something like this. A trusted insider places a VoIP call from a compromised soft-phone on their workstation to a collection server outside the enterprise network. The call is processed and routed by the VoIP session manager as it would any voice call. The collection server answers the call as if it was a VoIP endpoint; e.g., using another compromised soft-phone. Once the connection is established, a file transfer can occur using the normal RTP streams established for the call as the transport medium. The data transfer is not detected because RTP or SRTP streams are generally not inspected. This is because of a general perception that payload anomalies are undetectable due to the random nature of encoded audio and video signals. SRTP encryption makes the payload inspection task even harder. This scenario easy to implement via IP end to-end-through one or more SBCs/EBCs without any data degradation. While it has been commonly thought that the transcoding performed in a MG would prevent such an exploit, such an exploit has been demonstrated using a pair of MGs resulting in only minor data degradation. Due to this fact, it is time to be concerned about data exfiltration via the VVoIP infrastructure and implement mitigations to prevent it. \n\n\nToday we employ various mitigations that serve to inhibit data exfiltration exploits via VVoIP such as described above. These include but are not limited to the following: \n> Restricting what software can be installed on a server or workstation \n> Restricting what that software can do\n> Restricting user to data\n> Restricting machine and user access to the network via port security and user authentication\n> As well as others\n\nAs an additional part of a layered defense against enterprise data exfiltration via the VVoIP network, is to place filters at the VVoIP network egress points, (that is at the MGs and at or within the SBCs/EBCs) that can detect data flows and other anomalies in a RTP/SRTP media stream. Today this is an emerging technology with initial capabilities available today. It is expected that this technology will more robust and mature in the not too distant future.\n",
"fixid": "F-22296r1_fix",
"fixtext": "Implement mitigations against sensitive data exfiltration via IP based voice/video communications systems as follows:\n>Filter/monitor IP media traffic through Media Gateways (MGs), Session Border Controllers (SBCs), and Edge Border Controllers (EBCs) to detect and block/inhibit the exfiltration of sensitive DoD data from the network via VVoIP RTP/SRTP communications sessions.\n> Enable appropriate alarms and security event auditing/logging on these filters such that network security personnel and administrators can take appropriate action.\n\nEstablish proactive monitoring as well as policy and procedure regarding incident response. \n\n",
"iacontrols": [
"DCBP-1"
],
"id": "V-21507",
"ruleID": "SV-23716r1_rule",
"severity": "medium",
"title": "Mitigations against data exfiltration via the voice and/or video communications network/system have not been implemented",
"version": "VVoIP 2200 (GENERAL)"
},
"V-21508": {
"checkid": "C-25742r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure the site provides for the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, and supports enhanced Fire and Emergency Services (F&ES) telecommunications as follows:\n> The site has implemented support for DoDI 6055.06 through local policies, procedures, staffing, and facilities; or agreements/contracts with external agencies.\n> The site\u2019s telephone system supports enhanced F&ES emergency communications. \n> If the site\u2019s telephone system is a private MLTS (VoIP or traditional), the system provides Automatic Number Identification (ANI) information to the emergency services answering point and a Phone Switch Automatic Location Identification (PS-ALI) database is established within the telephone system or externally, the information from which is accessible to the emergency services answering point.\n> The site maintains the PS-ALI database and keeps it current with all telephone adds/moves and number changes.\n",
"description": "The inability to contact emergency services via the public telephone system and/or privately-owned Multi-Line Telephone Systems (MLTS) (such as PBXs and VoIP telephone systems) threatens life safety as well as facility protection and security. Emergency communications generally includes requests for fire, police, and/or medical assistance. In DoD, these communications can also include requests for Aircraft Rescue and Fire Fighting (ARFF), explosive ordnance disposal, and similar emergency situations. The inability of first responders to automatically locate the caller threatens life safety and facility protection or security. The ability to call an F&ES telephone number is called Basic F&ES Communications. The ability for the operator answering the emergency call to automatically determine the location of the caller and relay this information to the first responders is called Enhanced F&ES Communications. The ability to contact emergency services via the public telephone system has been mandated for many years in the US and other countries around the world. In the US, the FCC has mandated various aspects of providing enhanced F&ES communications and also relies upon state legislation to extend these rules. The Federal Communications Commission (FCC) rules primarily address public communications service providers including traditional LEC and CLECs, mobile communications providers, and VoIP communications providers. Support for enhanced emergency services communications by private MLTS is left to state legislation. Several states have such legislation today while more states are on the way. Eventually, most, if not all, states will likely have such legislation. Additionally, with respect to the DoD, DoDI 6055.06, DoD Fire and Emergency Services (F&ES) Program, December 21, 2006, provides DoD policy regarding emergency services and emergency services communications. While much of this policy addresses fire protection in general and more specifically training, staffing, and equipment, it also provides for telecommunications support for fire, medical, and security emergencies, whether directly or by implication. Several items of interest for this and subsequent STIG requirements are as follows: > 5.8. The Combatant Commanders, through Chairman of the Joint Chiefs of Staff, shall ensure F&ES protection of personnel, equipment, and facilities. > 6.6. Telecommunication Capability. Implement around-the-clock capability to conduct dedicated F&ES communications. > E8.1 Telecommunication Capability; Maintain around-the-clock capability to conduct essential F&ES communications. > E8.1.2. The DoD Components shall implement the installation F&ES alarm and communication function where feasible. > E8.1.2.1. Consolidate with an established continuously manned emergency communications center for all emergency services. > E8.1.2.4. DoD F&ES communications and dispatch functions may be provided by municipal F&ES or other outside agencies when those agencies compare favorably with DoD standards and can meet the prescribed communications criteria. Private telephone systems, in general, provide a large portion of the required telecommunication capability. All DoD telecommunications systems are private MLTS. As such, ALL private MLTS, VoIP or traditional must support enhanced emergency services communications for the completion of emergency calls. Per DoDI 6055.06, all sites must support, provide for, and implement F&ES telecommunications services. When implementing basic F&ES telecommunications services, each country or region designates a specific standard telephone number or prefix code to be dialed that can be easily remembered by the public. In some instances, while not best practice, organizations might designate an internal emergency number for use within their MLTS. PSTN LECs and CLECs must route calls to this number in a non-blocking priority manner. Examples of such numbers are as follows: > 911 in North America > 112 in the EU and UK > 000 in Australia In some cases countries use a separate code for Police vs Medical vs Fire. A rather comprehensive listing can be found at http://en.wikipedia.org/wiki/Emergency_telephone_number. Issues arise when an emergency call is originated through a private phone system, such as a traditional PBX or a VVoIP system. While the LEC or CLEC may properly route the call in a priority manner, the same may not be true for the private system unless specificity addressed in the systems call routing tables and potentially other system features. This is an issue when providing emergency communications services as a best practice or in compliance with governmental mandate. As such, the private system must be configured to properly handle emergency communications. Enhanced F&ES communications permits the answering station to automatically locate the caller. This is particularly helpful when the caller cannot provide their location themselves. Enhanced F&ES communications is generally mandated by the FCC and state legislation. It is today\u2019s state of the art and its implementation is a best practice. The enhanced F&ES communications capability is enabled using Automatic Number Identification (ANI) and Automatic Location Identification (ALI) information. ANI provides the telephone number of the calling party and is generated by the telephone system/switch. ALI associates the calling party\u2019s number (ANI information) with their address, or registered the address/location of the phone being used. ALI is provided by a database function. The database may be maintained within the telephone system/switch or externally. In many cases, the F&ES answering service system will use the ALI information to map the location of the calling phone. ALI information in the public sector is maintained by the telephone service providers and is generally based on billing records. This works fine for traditional phones that have a fixed location at the end of a telephone company wire. VoIP phones, on the other hand, can be connected anywhere in the world and function. This is an issue for commercial VoIP services which is being addressed by the FCC. ALI information in the private sector must be handled by the owners/operators of private MLTS. If a private MLTS is to support enhanced F&ES telecommunications, an ALI database must be instituted and maintained current as instruments and numbers move around a facility or site. While, in many cases, this may be a manual task, automated systems are being developed. NOTE: Notwithstanding system configuration and capabilities, the system must also remain fully functional, minimally for a reasonable time period, in the event primary power is lost. As such, both traditional PBXs and VVoIP systems along with their supporting LAN infrastructure must be provided with sufficient backup power. Specific requirements for voice communications system backup power are addressed in additional requirements. ",
"fixid": "F-22297r1_fix",
"fixtext": "Ensure the site provides for the local DoD Multi-Line Telecommunications System (MLTS), VoIP or traditional, and supports enhanced Fire and Emergency Services (F&ES) telecommunications as follows:\n> The site has implemented support for DoDI 6055.06 through local policies, procedures, staffing, and facilities; or agreements/contracts with external agencies.\n> The site\u2019s telephone system supports enhanced F&ES emergency communications. \n> If the site\u2019s telephone system is a private MLTS (VoIP or traditional), the system provides Automatic Number Identification (ANI) information to the emergency services answering point and a Phone Switch Automatic Location Identification (PS-ALI) database is established within the telephone system or externally, the information from which is accessible to the emergency services answering point or call center.\n> The site maintains the PS-ALI database and keeps it current with all telephone adds/moves and number changes.\n\nImplement a fire and emergency services telecommunications system. \n",
"iacontrols": [
"DCBP-1"
],
"id": "V-21508",
"ruleID": "SV-23717r1_rule",
"severity": "medium",
"title": "The site has not provided for Fire and Emergency Services (F&ES) telecommunications services (fire, police, medical, etc) and/or the telephone system does not support or is not configured to support enhanced emergency communications. ",
"version": "VVT 2000 "
},
"V-21521": {
"checkid": "C-25777r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement: \n\nFor VVoIP and UC servers and endpoints, ensure all PPS that are not necessary for the operation or maintenance of the system are disabled or the supporting software removed. Limit production PPS to production interfaces and management PPS to the OAM&P interfaces.\n\n",
"description": "The availability of applications and services that are not necessary for the OAM&P of the VVoIP system\u2019s devices and servers, running or not as well as the existence of their code, places them at risk of being attacked and these avenues exploited. As such they should be removed if possible or minimally disabled so they cannot run and be exploited.\n\nFor VVoIP and UC servers and endpoints, remove the software for or minimally disable PPS that are not necessary for the operation or maintenance of the system. Limit production PPS to production interfaces and management PPS to the OAM&P interfaces.\n",
"fixid": "F-22312r1_fix",
"fixtext": "Disable all PPS on all VVoIP or UC system servers and sevices that are not required to support OAM&P in the specific VVoIP system implementation. Additionally, if possible, remove the software for the unnecessary PPS.",
"iacontrols": [
"DCBP-1"
],
"id": "V-21521",
"ruleID": "SV-23733r1_rule",
"severity": "medium",
"title": "Unnecessary PPS have not been disabled or removed from VVoIP system devices or servers.",
"version": "VVoIP 1021 (GENERAL)"
},
"V-21522": {
"checkid": "C-25780r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nIn the event DNS is used in the VVoIP system, ensure the DNS server is dedicated to the VVoIP system and that any DNS server interaction with other DNS servers is limited. Additionally ensure internal system URLS and information is not published to the enterprise WAN or the Internet. \n\nDetermine if: \nThe VVoIP system DNS server is not dedicated to the VVoIP system within the LAN;\nOR \nThe VVoIP system DNS server freely interacts with other DNS servers outside the VVoIP system;\nOR \nThe VVoIP system information is published to the enterprise WAN or the Internet.\n\nThis is a finding in the event one or more of these conditions exist.\n",
"description": "In some cases a VVoIP endpoint will be configured with one or more URLs pointing to the locations of various servers with which they are associated such as their call controller. These URLs are translated to IP addresses by a DNS server. The use of URLS in this manner permits an endpoint to find the server it is looking for in the event the server\u2019s IP address is changed. This also permits the endpoint to locate its assigned or home call controller from a remote location on a network that is not their home network. While all of this adds flexibility to the system and the endpoint\u2019s location, it also exposes the endpoint and the home system to DNS vulnerabilities. Additionally, the home VVoIP system must expose critical IP address and domain information to the DNS system. If the DNS system is exposed to the DNS servers that support the enterprise data network or the Internet, this information and exposure of the system is, or may be, extended to the world. This provides information that can be used to attack or compromise the VVoIP system. \n\nWhen using DNS within a VVoIP system so that endpoints can find various servers in the network, the DNS server should be dedicated to the VVoIP system. Further more this DNS server should have limited or no interaction with the DNS server used by the data portion of the LAN/CAN or a publicly accessible DNS server. This will protect the VVoIP system\u2019s DNS server from some of the vulnerabilities inherent in DNS servers that serve data endpoints and that are connected to the wider enterprise networks or the Internet.\n\nWhile the use of DNS adds IP addressing flexibility to a VVoIP system, it is not necessary to use it for systems within the local LAN. VVoIP servers and infrastructure devices are required to be statically addressed. Therefore the endpoints can be configured with these known IP addresses rather than URLs. A remote endpoint is required to connect to the home enclave via a VPN. It receives an internal LAN address and therefore becomes a part of the LAN and can directly reach its servers using their IP address. A URL is not required. The only time a URL might be required is in the event the endpoint is required to find a server such as a directory server that is somewhere on the WAN. This is the case in the VoSIP system on SIPRNet. Not using DNS in a VVoIP system eliminates its exposure to DNS vulnerabilities and attacks effected using information obtained from the DNS. \n\nNOTE: In the event a DNS server is implemented within the VVoIP system, the DNS STIG must be applied to the server.\n",
"fixid": "F-22313r1_fix",
"fixtext": "Consider not using DNS for the VVoIP system unless it is required. \n\nIn the event DNS is used in the VVoIP system, ensure the DNS server serving the VVoIP system is dedicated to the VVoIP system and that any DNS server interaction with other DNS servers is limited. Additionally ensure internal system URLS and information is not published to the enterprise WAN or the Internet.\n\nNOTE: In the event a DNS server is implemented within the VVoIP system, the DNS STIG must be applied to the server.\n",
"iacontrols": [
"DCBP-1"
],
"id": "V-21522",
"ruleID": "SV-23734r1_rule",
"severity": "low",
"title": "The VVoIP system DNS server is not dedicated to the VVoIP system within the LAN; or the VVoIP system DNS server freely interacts with other DNS servers outside the VVoIP system; or the VVoIP system information is published to the enterprise WAN or the Internet.",
"version": "VVoIP 5212 (LAN)"
},
"V-21523": {
"checkid": "C-25782r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement:\n\nEnsure the VVoIP system\u2019s time is synchronized with or receives its time from the two internal LAN NTP servers that are configured within the LAN management VLAN in accordance with the Network Infrastructure STIG. Further ensure the VVoIP endpoints receive their time from the VVoIP system controller.\n\nNOTE: The use and implementation of NTP within the VVoIP system must be implemented in accordance with the Network Infrastructure STIG NTP requirements and policies. \n\nThis is a finding in the event these conditions are not met.\n\nAdditionally determine how the endpoints time is synchronized. This is a finding in the event their time is not sourced from the VVoIP system controller via the VVoIP VLANs.\n",
"description": "It is critical that the network time be synchronized across all network elements when troubleshooting network problems or investigating an incident. Each log entry is required to be time stamped. If time-stamps are not synchronised, it can be difficult or impossible to see in what order events occurred. Additionally legacy telecommunications systems require synchronized time. Network elements (NE). \n\nThe Network Infrastructure STIG provides guidance for using NTP and implementing NTP servers within the enclave or LAN. A paraphrased summary of the basic requirements follows:\n> Implement two NTP servers in the LAN management network to act as the source of NTP information to the rest of the enclave/LAN.\n> Reference the two NTP servers to two different stratum 1 reference clocks via GPS or NIST WWVB.\n> Harden NTP servers in accordance with the applicable OS STIG.\n> Distribute NTP information to all LAN NEs via the management interface. This provides a protected environment for the distribution of network time.\n> All received and sent messages between NTP peers are authenticated.\n> Receive NTP messages from authorized sources based on their IP address. \n> All LAN NEs are configured to receive NTP messages from two NTP sources within the LAN such that one backs up the other. \n> Distribution of \nNOTE: This list is not complete and is provided as information only. Refer to the current Network Infrastructure STIG for all policy and requirements associated with NTP use and implementation in the LAN. \n\nThe VVoIP system must be synchronized with the LAN time, minimally to support troubleshooting and incident response. Therefore the VVoIP system must be integrated into the LAN\u2019S NTP system in accordance with the Network Infrastructure STIG NTP guidance. Its network time must not be synchronized with an independent source. \n\nAdditionally, if the VVoIP system is synchronized with an independent source via the Internet, the VVoIP system becomes exposed to NTP exploits and attacks from the Internet.\n\nImplementing NTP within the VVoIP system will require the system/call controller to be configured to receive authenticated NTP messages from the two NTP server IP addresses via its management interface. This will require that permissions be granted between the VVoIP management VLAN and the LAN management VLAN such that NTP requests and responses can flow between the VVoIP system controller and the two NTP servers in the LAN management VLAN. If the VVoIP endpoints time is synchronized via NTP, the VVoIP controller will have to serve as their NTP server since the endpoints do not have access to the VVoIP or LAN management VLANs and should not be permitted such access.\n \n",
"fixid": "F-22314r1_fix",
"fixtext": "Implement NTP usage in the VVoIP system in accordance with the Network Infrastructure STIG policy and requirements. \n\nEnsure the VVoIP system\u2019s time is synchronized with or receives its time from the two internal LAN NTP servers that are configured within the LAN management VLAN in accordance with the Network Infrastructure STIG. Further ensure the VVoIP endpoints receive their time from the VVoIP system controller.\n\nNOTE: Implementing NTP within the VVoIP system will require the system/call controller to be configured to receive authenticated NTP messages from the two NTP server IP addresses via its management interface. This will require that permissions be granted between the VVoIP management VLAN and the LAN management VLAN such that NTP requests and responses can flow between the VVoIP system controller and the two NTP servers in the LAN management VLAN. If the VVoIP endpoints time is synchronized via NTP, the VVoIP controller will have to serve as their NTP server since the endpoints do not have access to the VVoIP or LAN management VLANs and should not be permitted such access.\n\n",
"iacontrols": [
"DCBP-1"
],
"id": "V-21523",
"ruleID": "SV-23735r1_rule",
"severity": "medium",
"title": "The VVoIP system time is not properly implemented and/or synched with the LAN\u2019s NTP servers. ",
"version": "VVoIP 5250 (LAN)"
},
"V-47735": {
"checkid": "C-50233r2_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement:\nVerify VVoIP endpoint configuration files transferred via Cisco TFTP are encrypted and signed using DoD PKI certificates.\n\nNOTE: This requirement is not applicable to systems that do not use Cisco TFTP.",
"description": "When VVoIP configuration files traverse a network in an unencrypted state, system information may be used by an adversary, which in the aggregate, may reveal sensitive data. When VVoIP traffic is passed in the clear it is open to sniffing attacks. This vulnerability exists whether the traffic is on a LAN or a WAN. End-to-end encryption of the configuration files mitigates this vulnerability. However, TFTP does not natively encrypt data. The Cisco TFTP implementation for VoIP systems uses encryption to both store and transfer configuration files. Refer to the \u201cCISCO-UCM-TFTP\u201d Vulnerability Analysis report provided by the Protocols, Ports, and Services management site for more details. \n\nDoD-to-DoD voice communications are generally considered to contain sensitive information. Local DoD enclaves connect to a DISN SDN via an access circuit. Unless the site is a host to a SDN, or close enough to it to be served by DoD owned facilities, some portion of the access circuit will utilize leased commercial facilities. Additionally, the DISN core network itself may traverse commercial services and facilities. Therefore, DoD voice and data traffic crossing the unclassified DISN must be encrypted.",
"fixid": "F-51371r1_fix",
"fixtext": "Configure the VVoIP endpoint configuration files transferred via Cisco TFTP to be encrypted and signed using DoD PKI certificates. Refer to the \u201cCISCO-UCM-TFTP\u201d Vulnerability Analysis report provided by the Protocols, Ports, and Services management site for more details.",
"iacontrols": [
"ECSC-1"
],
"id": "V-47735",
"ruleID": "SV-60611r1_rule",
"severity": "medium",
"title": "VVoIP endpoint configuration files transferred via Cisco TFTP must be encrypted and signed using DoD PKI certificates.",
"version": "VVoIP 1410 (GENERAL) "
},
"V-47753": {
"checkid": "C-50235r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement:\nVerify VVoIP endpoint configuration files traversing the DISN must be protected within a VPN secured using FIPS 140-2 or NSA approved encryption between enclaves. The reviewer may downgrade to CAT 3 when vendor provided PKI or x.509 certs are used rather than DoD PKI certificates.\n\nNOTE: This requirement is not applicable to systems that use Cisco TFTP.",
"description": "When VVoIP configuration files traverse a network in an unencrypted state, system information may be used by an adversary, which in the aggregate, may reveal sensitive data. When VVoIP traffic is passed in the clear it is open to sniffing attacks. This vulnerability exists whether the traffic is on a LAN or a WAN. Unencrypted and unsigned configuration files must be wrapped within an encrypted VPN to mitigate this risk.\n\nDoD-to-DoD voice communications are generally considered to contain sensitive information. Local DoD enclaves connect to a DISN SDN via an access circuit. Unless the site is a host to a SDN, or close enough to it to be served by DoD owned facilities, some portion of the access circuit will utilize leased commercial facilities. Additionally, the DISN core network itself may traverse commercial services and facilities. Therefore, DoD voice and data traffic crossing the unclassified DISN must be encrypted.",
"fixid": "F-51379r1_fix",
"fixtext": "Configure the VVoIP endpoint configuration files traversing the DISN to be protected within a VPN secured using FIPS 140-2 or NSA approved encryption between enclaves.",
"iacontrols": [
"ECSC-1"
],
"id": "V-47753",
"ruleID": "SV-60629r1_rule",
"severity": "medium",
"title": "Unencrypted and unsigned VVoIP endpoint configuration files traversing the DISN must be protected within a VPN between enclaves.",
"version": "VVoIP 1415 (GENERAL)"
},
"V-8223": {
"checkid": "C-23599r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement: Ensure the VVoIP and/or IP connected VTC system and its components as well as their upgrades and changes are included in the site\u2019s enclave / LAN C&A documentation (e.g., the DIACAP Implementation Plan (DIP), System Identification Profile (SIP), Scorecard, etc.). \n\nNOTE: This requirement applies to or includes the existence or implementation of soft-phone applications or wireless VoIP (Wi-Fi or WiMAX) endpoints. \n\n> Review the baseline documentation and/or C&A documentation to verify that all VVoIP installations and/or modifications are included. Verify there is a procedure for approving changes to configuration.\n> Determine if soft-phone applications or wireless VoIP (Wi-Fi or WiMAX) endpoints are used or implemented within the network. Look for the appearance of these in the required documentation noted above.\n",
"description": "Documentation of the enclave / LAN configuration must include all VVoIP systems. If the current configuration cannot be determined then it is difficult to apply security policies effectively. Security is particularly important for VoIP technologies attached to the enclave network because these systems increase the potential for eavesdropping and other unauthorized access to network resources. Accurate network documentation is critical to maintaining the network and understanding its security posture, threats, and vulnerabilities. Baseline and C&A documentation is the vehicle by which the DAA receives security related information on the network for which he/she is personally responsible and accepts the security risk of operating the system.",
"fixid": "F-7706r1_fix",
"fixtext": "Add all VoIP installations and/or modifications to the SSAA. Obtain DAA approval for the updated SSAA. Submit to the SRR team lead for validation and finding closure.",
"iacontrols": [
"DCHW-1"
],
"id": "V-8223",
"ruleID": "SV-8709r1_rule",
"severity": "low",
"title": "The VVoIP system, its components, and/or changes to them are not included in the site\u2019s enclave / LAN baseline documentation and Configuration & Accreditation documentation",
"version": "VVoIP 1100 (GENERAL)"
},
"V-8224": {
"checkid": "C-23703r1_chk",
"checktext": "Interview the IAO and review/inspect site network/facilities diagrams and documentation to confirm compliance with the following requirement: \n\nIn the event MGCP or MEGACO/H.248 is used to control Media Gateways (MGs) or other devices (e.g., endpoints), ensure the following: \n> The LSC/MGC and MG are located in the same protected LSC VLAN and ACLs are established on all VLAN egress points to block the MGCP or MEGACO/H.248 from exiting the VLAN; OR \n> the LSC/MGC and MG are located in adjacent protected VLANs and ACLs are established to permit MGCP or MEGACO/H.248 between the LSC/MGC and MG but block the MGCP or MEGACO/H.248 from exiting these VLANs; AND \n> In the event MGCP or MEGACO/H.248 is used to control a MG or a distributed set of MGs across a WAN, ensure an encrypted VPN is used to protect the MGCP traffic. \n> Additionally, ensure the source of MGCP or MEGACO/H.248 packets is authenticated to originate from a valid source and/or minimally filter acceptance on source IP address.\n",
"description": "Media Gateway Control Protocol (MGCP) is a protocol that is used between Media Gateway Controllers (MGCs), Media Gateways (MGs), and other MGs to exchange sensitive gateway status and zone information as well as establish sessions via the MG. MGCP is a clear text human readable protocol. This information is critical in the setup and completion of voice calls from one VoIP zone to another VoIP zone or more typically from a VoIP zone to a TDM zone. If this information is poisoned or if collected and used by an unauthorized unscrupulous individual, the effects to the VoIP environment could be detrimental. Denial-of-service or fraudulent system use are only two of the potential compromises. As such, MGCP messages must be protected from eavesdropping, man in the middle, and replay attacks. To protect MGCP, Request for Comment (RFC) 2705 which defines MGCP outlines and recommends the use of IPSec for encryption and authentication between gateways. This recommendation primarily applies to the use of MGCP across unprotected WANs like the Internet. This extends to use on NIPRNet as well. A follow-on protocol defined jointly by the IETF in RFC 3435 and the ITU-T in Recommendation H.248.1 is MEGACO/H.248 which provides the same general functionality as MGCP. RFC 3435 also requires that H.248 packets be authenticated and/or encrypted using IPSec. Unfortunately there is not widespread support by MGCs and MGs for IPSec protection and therefore we must rely on external IPSec VPNs when traversing the WAN. When confined within the LAN, we can protect MGCP in a number of ways without IPSec. ",
"fixid": "F-20185r1_fix",
"fixtext": "In the event MGCP or MEGACO/H.248 is used to control Media Gateways (MGs) or other devices (e.g., endpoints), ensure the following: \n> the LSC/MGC and MG are located in the same protected LSC VLAN and ACLs are established on all VLAN egress points to block the MGCP or MEGACO/H.248 from exiting the VLAN; OR \n> the LSC/MGC and MG are located in adjacent protected VLANs and ACLs are established to permit MGCP or MEGACO/H.248 between the LSC/MGC and MG but block the MGCP or MEGACO/H.248 from exiting these VLANs; AND \n> In the event MGCP or MEGACO/H.248 is used to control a MG or a distributed set of MGs across a WAN, ensure an encrypted VPN is used to protect the MGCP traffic. \n> Additionally, ensure the source of MGCP or MEGACO/H.248 packets is authenticated to originate from a valid source and/or minimally filter acceptance on source IP address.\n",
"iacontrols": [
"ECCT-1",
"ECSC-1"
],
"id": "V-8224",
"ruleID": "SV-8710r1_rule",
"severity": "medium",
"title": "MGCP and/or H.248 (MEGACO) is not restricted/controlled on the LAN and/or protected on the WAN using encryption OR MGCP and/or H.248 (MEGACO) packets are not authenticated or filtered by source IP address.",
"version": "VVoIP 1405 (GENERAL)"
},
"V-8225": {
"checkid": "C-23525r1_chk",
"checktext": "Perform a walk through of the facilities the IAO to validate compliance with the following requirement: Ensure all telecommunications infrastructure components (traditional TDM, VVoIP, UC or VTC) are housed in secured facilities with appropriate classification level and appropriate documented access control methods. NOTE: This does not apply to end instruments. Additionally ensure all facilities housing telecommunications infrastructure components are rated at or above the highest classification level of the information communicated. For example, VoSIP (VoIP on SIPRNet) infrastructure components must be housed in facilities rated at or above the secret level. NOTE: This DOES apply to end instruments.\n\nDuring the walk through inspection, visually confirm that telecommunications infrastructure (traditional TDM, VVoIP, UC or VTC specific network and server) components are installed in secured areas to include locked rooms, closets, and/or cabinets. \n\nInterview the IAO to determine how the distribution of keys to access the equipment is limited, controlled, and documented. Additionally, determine if access control procedures/documentation are/is being used and review the access logs for compliance. Finally; interview the IAO regarding the security classification of the facilities housing the telecommunications infrastructure components in relation to the highest classification level of the information communicated.\n\nThis is a finding in the event of the following: \n> Any telecommunications infrastructure component is not housed in a secured facility (locked room or cabinet).\n> The facility access control procedures or its documentation is deficient.\n> Access to the facility is not logged or the procedures are not followed.\n> The facility classification of any facility housing telecommunications infrastructure components is rated below the highest classification level of the information communicated.\n\nNOTE: The infrastructure addressed here are components of traditional TDM, VVoIP, UC or VTC systems that support the communications endpoints. This includes \u201cwiring closets\u201d for traditional non IP based systems.\n\nNOTE: Physical access to the LAN infrastructure (which may also support VVoIP, UC, and VTCoIP services) is covered by a Network Infrastructure STIG requirement. This requirement does not directly address the physical security of the general LAN infrastructure, such as LAN routers and switches. \n\nNOTE: While this requirement is based on best practice and requirements for protecting classified information, it is also supported in part by DOD 5200.08-R, Physical Security Program, April 9, 2007 Incorporating change 1, 27 May 2009, Chapter 6, Security of Communications Facilities, section C6.2.4 which states: \u201cAccess shall be controlled at all communications facilities and only authorized personnel shall be allowed to enter. Facilities should be designated and posted as a minimum, a Controlled Area, as directed.\u201d\n",
"description": "Controlling physical access to telecommunications infrastructure components is critical to assuring the reliability of the voice network and service delivery. Documenting or logging physical access to these components is critical to determine accountability for auditing purposes. Key control and access logs are a large part of this. Additionally, the facilities housing the telecommunications infrastructure must be certified at a classification level commensurate with the highest classification level of the information communicated by the system. \n\nNOTE: The infrastructure addressed here are components of traditional TDM, VVoIP, UC or VTC systems that support the communications endpoints. This includes \u201cwiring closets\u201d for traditional non IP based systems.\n\nNOTE: Physical access to the LAN infrastructure (which may also support VVoIP, UC, and VTCoIP services) is covered by a Network Infrastructure STIG requirement. This requirement does not directly address the physical security of the general LAN infrastructure, such as LAN routers and switches. \n\nNOTE: While this requirement is based on best practice and requirements for protecting classified information, it is also supported in part by DOD 5200.08-R, Physical Security Program, April 9, 2007 Incorporating change 1, 27 May 2009, Chapter 6, Security of Communications Facilities, section C6.2.4 which states: \u201cAccess shall be controlled at all communications facilities and only authorized personnel shall be allowed to enter. Facilities should be designated and posted as a minimum, a Controlled Area, as directed.\u201d\n",
"fixid": "F-20063r1_fix",
"fixtext": "Ensure all telecommunications infrastructure components are housed in secured facilities with appropriate classification level and appropriate documented access control methods. NOTE: This does not apply to end instruments. Additionally, ensure all facilities housing telecommunications infrastructure components are rated at or above the highest classification level of the information communicated. For example, VoSIP (VVoIP on SIPRNet) infrastructure components must be housed in facilities rated at or above the secret level. NOTE: This DOES apply to end instruments.\n\n\nEnsure that all equipment is installed in a locked room, closet, or cabinet. \nEnsure the distribution of keys to access the equipment is limited, controlled, and documented.\nEnsure access control procedures are implemented to ensure that physical access is documented such that an audit trail can be established if necessary.\n\nNOTE: The infrastructure addressed here are components of traditional TDM, VVoIP, UC or VTC systems that support the communications endpoints. This includes \u201cwiring closets\u201d for traditional non IP based systems.\n\nNOTE: Physical access to the LAN infrastructure (which may also support VVoIP, UC, and VTCoIP services) is covered by a Network Infrastructure STIG requirement. This requirement does not directly address the physical security of the general LAN infrastructure, such as LAN routers and switches. \n\nNOTE: While this requirement is based on best practice and requirements for protecting classified information, it is also supported in part by DOD 5200.08-R, Physical Security Program, April 9, 2007 Incorporating change 1, 27 May 2009, Chapter 6, Security of Communications Facilities, section C6.2.4 which states: \u201cAccess shall be controlled at all communications facilities and only authorized personnel shall be allowed to enter. Facilities should be designated and posted as a minimum, a Controlled Area, as directed.\u201d\n",
"iacontrols": [
"DCBP-1",
"ECSC-1"
],
"id": "V-8225",
"ruleID": "SV-8711r1_rule",
"severity": "medium",
"title": "Voice/Video Telecommunications infrastructure components (traditional TDM, VVoIP, or VTC) are not housed in secured or \u201ccontrolled access\u201d facilities with appropriate classification level or appropriate documented access control methods.",
"version": "VVT/VTC 1000 (GENERAL)"
},
"V-8227": {
"checkid": "C-23790r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure (a) different, dedicated, address block(s) or range(s) are defined for the VVoIP system within the LAN (Enclave) that is separate from the address blocks/ranges used by the rest of the LAN for non VVoIP system devices thus allowing traffic and access control using firewalls and router ACLs. \nNOTE: the address range defined should be contiguous in order to simplify the development of the ACLs.\n\n\nNOTE: This is applicable to the following:\n> A closed unclassified LAN\n> An unclassified LAN connected to an unclassified WAN such as the NIPRNet or Internet\n> A closed classified LAN \n> A classified LAN connected to a classified WAN (such as the SIPRNet).\n\nNOTE: In the case of a classified WAN where network wide address based accountability or traceability is required by the network PMO, the PMO must provide a segregated, network wide address block(s) so that the attached classified LANs can meet this requirement.\n\nNOTE: The affected devices in this case are as follows:\n> VVoIP Call or session controllers; LSC / MFSS \n> Adjunct UC systems\n> Edge Boundary Controller (EBC) internal and external interfaces\n> Customer Edge (Premise) router internal interface to the VVoIP VLANs\n> VVoIP endpoints including for PCs that support multiple VLANs.\n\nNOTE: VVoIP Core systems including the EBC and CER must be statically addressed. DHCP may only be used for endpoint address assignment/configuration.\n\nDetermine if a dedicated LAN address space has been designated for the VVoIP system that is segregated from the address space used for the general LAN and management VLANs.\n\nNote the defined address range(s) for use when reviewing the devices themselves.\n",
"description": "VoIP networks increasingly represent high-value targets for attacks and represent a greater risk to network security than most other network applications; hence, it is imperative that the voice network and supporting data network(s) be secured as tightly as possible to reduce the impact that an attack can have on either network(s). Segregating voice traffic from data traffic greatly enhances the security and availability of all services. Further subdivision of the voice and data networks can further enhance security. Achieving the ideal security posture for voice and data would require two physically separate and distinct networks (including cable plant), much as is the case with traditional voice and data technologies. Although this might be considered for the most demanding security environments, it works against the idea of convergence and the associated cost savings expected by having one network (and cable plant). Logical segregation of VoIP components and data components can be accomplished at both layer 2 using Virtual Local Area Networks (VLANs) and layer 3 using IP addressing. While these methods, in themselves, are not designed as security mechanisms, they do provide a derived security benefit by easing management of filtering rules and obfuscating or hiding addresses and information that an attacker could use to facilitate an attack. Separation may also prevent an attack on one network from impacting the other. These methods make it harder for an attacker to be successful and help to provide a layered approach to VoIP and network security. Segregating data from telephony by placing VoIP servers and subscriber terminals on logically separate IP networks and logically separate Ethernet networks while controlling access to these VoIP components through filters will help to ensure security and aid in protecting the VoIP environment from external threats. In addition, further subdivision of those components is necessary to protect the telephony applications which are running across the infrastructure. Layer 3 address segregation is the first layer in our layered defense approach to VoIP security. It allows the use of switches, routers, and firewalls with their associated access lists and other processes, to control traffic between the components on the network. To provide address segregation, best practices dictate that all like components will be placed in like address ranges. Therefore VoIP components (i.e., Gatekeepers, Call Managers, voice mail systems, IP Subscriber Terminals etc.) will be deployed within their own, separate private IP network, logical sub-network, or networks. The combination of logical data and voice segmentation via addressing and VLANs coupled with a switched and routed infrastructure strongly mitigates call eavesdropping and other attacks. In addition, limiting logical access to VoIP components is necessary for protecting telephony applications running across the infrastructure. Segregating data from telephony by placing VoIP servers and subscriber terminals on logically separate IP networks while controlling access to these VoIP components through IP filters will help to ensure security and aid in protecting the VoIP environment. ",
"fixid": "F-7710r1_fix",
"fixtext": "Implement VoIP systems and components on a logically segregated and dedicated telephony (VoIP) network.",
"iacontrols": [
"DCBP-1",
"DCPA-1",
"ECSC-1"
],
"id": "V-8227",
"ruleID": "SV-8713r1_rule",
"severity": "medium",
"title": "Different contiguous address blocks or ranges are NOT defined for the V-VoIP system within the LAN (Enclave) that is separate from the address blocks/ranges used by the rest of the LAN for non V-VoIP system devices thus allowing V-VoIP system traffic and access control using firewalls and router ACLs. \n \n",
"version": "VVoIP 5200 (LAN)"
},
"V-8228": {
"checkid": "C-23791r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure the dedicated VVoIP address range is defined using \u201cprivate\u201d (non WAN routed) addresses IAW RFC 1918.\nNOTE: This is applicable to the following:\n> A closed unclassified LAN\n> A unclassified LAN connected to a unclassified WAN such as the NIPRNet or Internet\n> A closed classified LAN \n> A classified LAN connected to a classified WAN where network wide address based accountability or traceability is NOT required by the WAN PMO and the WAN is configured to NOT route \u201cprivate\u201d addresses.\n\nNOTE: This is not applicable in situations where network wide address based accountability or traceability is required by the WAN PMO. For example, This is not applicable to DAA approved VoSIP systems residing on secured classified LANs that are connected to a classified WAN (such as the SIPRNet) where RFC 1918 addressing is not permissible for reasons of network wide accountability, traceability, and policy.\n\nNOTE: This is applicable to the following:\n> A closed unclassified LAN (in the event this LAN is some day connected to a WAN).\n> A unclassified LAN connected to a unclassified WAN such as the NIPRNet or Internet.\n> A closed classified LAN (in the event this LAN is some day connected to a WAN).\n> A classified LAN connected to a classified WAN where network wide address based accountability or traceability is NOT required by the WAN PMO and the WAN is configured to NOT route \u201cprivate\u201d addresses.\n\nDetermine if \u201cprivate\u201d RFC 1918 addresses are being used for the VVoIP system. These will be within one of the following ranges: 10.x.x.x, 172.16.x.x, and 192.168.x.x. \n\n",
"description": "RFC 1918 defines \u201cprivate\u201d IP address blocks as follows: 10.x.x.x, 172.16.x.x, and 192.168.x.x. The purpose of this is to conserve the available public address pool since there are far more hosts needing addresses than there are addresses. This is done by using one public address for a publicly accessible WAN termination at the enclave boundary and NAT on the firewall or router with many \u2018private\u201d addresses in the LAN. The use of the term \u201dprivate\u201d IP addresses in this sense means that these address blocks are not routed or advertised across the internet by international agreement. NIPRNet WAN addresses are \u201cpublicly accessible\u201d and the PMO also follows RFC 1918 routing policy (meaning that these addresses are not routed). RFC 1918 addresses are routable within the LAN enclave however, and can be on closed private networks. This sub-network(s) will use a different major address range than is deployed on the local data network(s) to further separate IPT from the data network. This will help to reduce the chances of voice traffic traversing outside the telephony network segment and vice versa for data traffic. The use of RFC 1918 IP address space, like the data VLANs, has the effect hiding the VVoIP components from the WAN, and making their addresses non-routable as a destination across the Internet (or NIPRNet). Deploying VVoIP Systems using RFC1918 address space enhances security of the VVoIP environment. If VVoIP systems are not deployed on \u201dprivate\u201d address space and if the address space is not properly configured, managed, and controlled, the VVoIP network could be accessed by unauthorized personnel resulting in security compromise of site information and resources. ",
"fixid": "F-20237r1_fix",
"fixtext": "Ensure the dedicated VVoIP address range is defined using \u201cprivate\u201d (non WAN routed) addresses IAW RFC 1918.\n\nNOTE: This is applicable to the following:\n> A closed unclassified LAN (in the event this LAN is some day connected to a WAN)\n> A unclassified LAN connected to a unclassified WAN such as the NIPRNet or Internet\n> A closed classified LAN (in the event this LAN is some day connected to a WAN)\n> A classified LAN connected to a classified WAN where network wide address based accountability or traceability is NOT required by the WAN PMO and the WAN is configured to NOT route \u201cprivate\u201d addresses.\n\nNOTE: This is not applicable in situations where network wide address based accountability or traceability is required by the WAN PMO. For example, This is not applicable to DAA approved VoSIP systems residing on secured classified LANs that are connected to a classified WAN (such as the SIPRNet) where RFC 1918 addressing is not permissible for reasons of network wide accountability, traceability, and policy.\n\nNOTE: The affected devices in this case are as follows:\n> VVoIP Call or session controllers; LSC / MFSS. \n> Adjunct UC systems.\n> Edge Boundary Controller (EBC) internal and external interfaces.\n> Customer Edge (Premise) router internal interface to the VVoIP VLANs.\n> VVoIP endpoints including for PCs that support multiple VLANs.\n\n",
"iacontrols": [
"DCBP-1",
"DCPA-1",
"ECSC-1"
],
"id": "V-8228",
"ruleID": "SV-8714r1_rule",
"severity": "low",
"title": "The dedicated VVoIP address range is NOT defined using \u201cprivate\u201d (non WAN routed) addresses IAW RFC 1918. ",
"version": "VVoIP 5205 (LAN)"
},
"V-8230": {
"checkid": "C-23801r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure the VVoIP system and the supporting LAN are designed and implemented using multiple VLANs to segregate the VVoIP core equipment and endpoints and services from all other hosts and services (such as data and dedicated VTC) running on the LAN such that the security, QoS, and reliability of the VVoIP system/service is enhanced thus allowing VVoIP system traffic and access control using router ACLs. \nVLANs and subnets will be provided and equipment separated, for those devices that are implemented in the system, as follows:\n> Hardware Endpoints: multiple VLANs generally in parallel with data LAN VLANs the number of which is dependant on the size of the LAN and as required for the reduction of broadcast domains per good LAN design. For small networks there will be a minimum of one.\n> Software endpoints on workstations: multiples as with hardware endpoints. \n> VVoIP system core control equipment containing the LSC, endpoint configuration server, and DHCP server if used, etc.\n> Media gateways (MG) to the DSN and PSTN.\n> Signaling gateways (SG) to the DSN. \n> DoD WAN access VVoIP firewall (EBC or other).\n> Voicemail / Unified Messaging Servers. These may need to be accessible from both the voice and data VLANs.\n> UC servers such as those supporting unified messaging, IM/presence, \u201cweb\u201d browser based conferencing, and directory services. These may need to be accessible from both the voice and data VLANs.\n\nNOTE: Hardware based VTC endpoints that utilize LSC services for session control may reside in the VoIP endpoint VLAN(s). These may include desktop and \u201cexecutive\u201d or office based units. All other Hardware based VTC endpoints require their own dedicated network or VLAN. \n \nNOTE: Separate VLANs work in conjunction with the dedicated address space discussed earlier to provide the required effect. Each VLAN is configured with a subset of addresses (valid IP subnet) from the designated VVoIP address space\nNOTE: Per NI STIG requirements the NE\u2019s default VLAN (VLAN 0 or 1) will not be used for any of the required VVoIP, data, or VTC VLANs.\n\nNOTE: ACLs are required between the various VLANs that will filter traffic between them based on what protocols and IP addresses are permitted to access or control the device(s) residing in the VLAN. Therefore it is expected that the LAN / VVoIP system design will include one or more routers or layer-3 switches as the intersection of all of these VLANs to access and traffic flow between them. This routing device will be configured with ACLs to only permit the functionally necessary traffic to flow between the various VLANs and the equipment they contain. \n\nNOTE: These VLANs may be replaced by direct connections to the VVoIP core routing device(s) so that the ACLs may be implemented on the physical interface to the device. This requires that such direct physical connections be given a discrete subnet. \n\nNOTE: The VLAN/subnets and associated ACLs need only to be assigned / applied for devices that exist in the VVoIP system. The VLAN / ACL design may change depending upon the location and physical makeup of the VVoIP core equipment. An example of this is if a MG and SG reside on the same platform and both use the same Ethernet LAN connection(s) (and potentially the same or different IP address(s)), then separate VLANs are not needed for the MG and SG but the ACL protecting them may need to be adjusted accordingly. \n\nThis is a finding in the event the design or implementation of the VVoIP system and supporting LAN does not include the required VLANs and subnets based upon the equipment and services provided by or included in the VVoIP system. Size of the system or the number of users supported has no effect on the need for this segmentation. However under some circumstances such as in the case of a small deployable package the number of VLANs can be reduced based upon a benefit vs. risk assessment, DAA approval, and package C&A.\n\nNOTE: The existence of the required VLANs will be validated in subsequent computing checks. The purpose of this check is to determine if the system design and implementation plan includes consideration for VLAN segmentation.\n\n",
"description": "An IPT system is built on an IP infrastructure based on layer 2 and layer 3 switches and routers, which comprise the network\u2019s access and distribution layers respectively. The layer 2 switches found at the access layer provide high port density for both host and IP phone connectivity as well as layer 2 services such as QoS and VLAN membership. (It should also be mentioned that some access layer switches can also do layer 2 and 3 filtering.) Guidelines and requirements for securing access layer devices including any associated cross-connect hardware can be found in the Network Infrastructure STIG. Layer 2 network segregation is the second layer in our layered defense approach to VoIP security. Voice traffic must be isolated from data traffic using separate physical LANs or Virtual LANs. The combination of data and voice segregation and segmentation using VLANs along with a switched infrastructure strongly enhances the security posture of the system. This will also help to mitigate call eavesdropping and other attacks. VLAN technology has traditionally been an efficient way of grouping users into workgroups to share a specific network address space and broadcast domain regardless of their physical location on the network. Hosts within the same VLAN can communicate with other hosts in the same VLAN using layer-2 switching. To communicate with other VLANs, traffic must go through a layer 3 device where it can be filtered and routed. VLANs can offer significant benefits in a multi-service network by providing a convenient way of isolating VVoIP equipment and traffic from the data equipment and traffic. When VLANs are deployed, excessive broadcast and multicast packets present in the normal data traffic will not disrupt IPT services. As with data networks, IPT equipment and instruments should be logically grouped using multiple VLANs such that IP Phones share their VLANs only with other IP Phones, gateways with like gateways, and so on. Each type of VVoIP device would have mutually exclusive VLANs. This forces layer 3 routing and thereby enables all the filtering capabilities of the layer 3 devices. Additionally, each server type should have its own VLAN. Private server VLANs would prevent a compromised server from attacking another server on the same VLAN at layer two. Since all the devices on any given VLAN would have the same Layer 2 though 4 (at least) characteristics the filtering rules become easier to develop, deploy, and manage. Additionally, the implementation of VLANs helps to mitigate the risk of attacks sourced from the data VLANs such as virus driven DoS attack or packet sniffing. In addition, placing voice and data traffic into separate VLANs will reduce competition for the network and thus reduce latency (queue/wait time) for transmission services, which will reduce the possibility of denial of voice services. This also reduces the Ethernet broadcast domain thereby reducing network overhead. Since VoIP is very latency sensitive this segmentation approach is the most economical way to improve performance in an existing network infrastructure. ",
"fixid": "F-7713r1_fix",
"fixtext": "Deploy VoIP systems and components on a dedicated VLAN structure that is separate from the data network VLAN structure. A minimum of one VLAN is required. More than one is highly recommended.",
"iacontrols": [
"DCBP-1",
"DCPA-1",
"ECSC-1"
],
"id": "V-8230",
"ruleID": "SV-8716r1_rule",
"severity": "medium",
"title": "The VVoIP VLAN design for the supporting LAN does not provide the necessary segmentation of the VVoIP system and service from the other services on the LAN and/or between the VVoIP components such that access and traffic flow can be properly controlled.",
"version": "VVoIP 5500 (LAN)"
},
"V-8247": {
"checkid": "C-23603r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure critical servers/devices supporting the VVoIP/UC/UM system are dedicated to only applications required to support operations.\n\nInterview the IAO and SA to determine the purpose and use of each server/device that comprises the VVoIP/UC/UM core infrastructure. Then determine each server/device can support or run any application other than what is required in support of its primary purpose. Such servers would be the LSC, without which the system will not operate, voicemail or unified mail servers, management servers, IM / presence servers, conference bridges, etc. Inspect each server/device\u2019s software storage looking for its installed applications. This is a finding if applications are found that are not required to fulfill the server/device\u2019s primary function. General purpose applications like browsers, word processors, etc., or other applications like development software or special purpose applications should not be found unless directly required for operations and support. Additionally, unnecessary portions of the operating system such as sub-applications or files and routines that are not required to support the telephony system should not be found. \n\nNOTE: VVoIP core infrastructure servers/devices include but may not be limited to the TDM telephone switches, local session controller (LSC), voicemail / unified mail system, interactive voice response system, media gateway, signaling gateway, management servers and workstations, conference bridges, IM/presence servers, etc.\n",
"description": "For the purpose of this requirement a VVoIP, UC, or UM server is any server directly supporting the communications service. Unlike a regular PC or print server on the network VVoIP servers are \u201cmission critical\u201d to the operation of the VoIP system. Dedicating these critical servers to their task is one of the key steps in key in securing the VVoIP environment. Permitting critical servers to run non-critical applications can provide a means or a path whereby the server or the critical applications can be compromised. Additionally, by running non-critical applications not required for the operations or not related to the primary purpose of the server can degrade the performance of the server and thereby the reliability of the service provided. By not permitting non-critical applications to run on these servers the server is made more secure. Therefore, the securing of these voice processing and signaling platforms, to include their installed applications, is vital in protecting the VoIP environment from malicious attack. ",
"fixid": "F-20122r1_fix",
"fixtext": "Ensure critical servers/devices supporting the VVoIP/UC/UM system are dedicated to only applications required to support operations.\n\nDedicate critical servers in the VVoIP/UC/UM core infrastructure to only run applications required for executing the primary function of the server/device and those required for its support. Additionally, remove all unnecessary portions of the operating system such as sub-applications or files and routines that are not required to support the telephony system.\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-8247",
"ruleID": "SV-8733r1_rule",
"severity": "medium",
"title": "Servers supporting the VVoIP and UC/UM telephony environment are not dedicated to telephony (VVoIP, UC, or UM) applications or their support.",
"version": "VVoIP 1050 (GENERAL)"
},
"V-8248": {
"checkid": "C-23615r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement:\nEnsure that the VVoIP core infrastructure servers/devices have been secured and hardened in compliance with all applicable STIGs (i.e., UNIX, Microsoft Windows, database, web, etc.). \n\nDetermine if the asset is based upon any of the general purpose technology (OS or application) for which there is a STIG or checklist. \n\nObtain a copy of the applicable SRR or Self Assessment results and review for compliance. If SRR results are not available, then SRR a representative number of devices. \n\nThis is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance.\n\nNOTE: If the server/device is purpose built to its function (potentially considered an appliance) using an embedded or stripped down version of a general purpose OS and/or if the device has limited I/O capabilities, it may be difficult to impossible to perform a normal review that would be done on a general purpose platform. In this case the best way to determines if the device is vulnerable is to perform a network scan on it.\n\nNOTE: VVoIP core infrastructure servers/devices include but may not be limited to the TDM telephone switches, local session controller (LSC), voicemail / unified mail system, interactive voice response system, media gateway, signaling gateway, management servers and workstations, conference bridges, IM/presence servers, etc.\n",
"description": "For the purpose of this requirement a VVoIP server is any server directly supporting the communications service. Unlike a regular PC or print server on the network VVoIP servers are \u201cmission critical\u201d to the operation of the VoIP system. Some vendors provide IP Telephony services on their own proprietary systems while others provided these services on standard UNIX, Linux, and Microsoft Windows based systems. They may also use general-purpose applications such as databases like MS-SQL or Oracle and/or employ web server technology like IIS or similar as well as open source software. Additionally, application security guidance may be applicable for the vendor's application that makes the server or device perform the functions, or the management, of the system. \nHardening these general purpose applications and operating systems against the much inherent vulnerabilities found in them is critical to securing the VVoIP core infrastructure, to include their installed applications. Doing so is vital to protecting the VoIP environment from malicious attack. The specific VVoIP system server or device determines the applicability of any given STIG.\nUNIX and Microsoft Windows based systems. Most known vulnerabilities exist on UNIX and Windows based operating systems. They may also use general-purpose applications such as databases like MS-SQL or Oracle and/or employ web server technology like IIS or similar. Additionally, application security guidance may be applicable for the vendor's application that makes the server or device perform the functions, or the management, of the system. Therefore, the securing of these voice processing and signaling platforms, to include their installed applications, is vital in protecting the VoIP environment from malicious attack. The specific VoIP system server or device determines the applicability of any given STIG.",
"fixid": "F-7731r1_fix",
"fixtext": "Secure critical servers supporting the telephony environment. Apply all applicable STIGs (i.e., UNIX, Microsoft Windows, database, web, etc. UNIX, Win2k/NT, DSN, etc.) and ensure compliance with applicable STIG guidelines.",
"iacontrols": [
"ECSC-1"
],
"id": "V-8248",
"ruleID": "SV-8734r1_rule",
"severity": "low",
"title": "All applicable STIGs have NOT been applied to the VVoIP / unified communications core infrastructure assets. ",
"version": "VVoIP 1030 (GENERAL)"
},
"V-8250": {
"checkid": "C-23685r2_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \nVerify all DoD-to-DoD VVOIP signaling and media traffic traversing a public or publicly accessible WAN (i.e., Internet, NIPRNet) is encrypted, natively at the application or protocol level, or using network or data-link layer encryption (i.e., encrypted VPN or bulk link encryption) using FIPS 140-2 or NSA approved encryption. Otherwise this is a finding.\n\nNOTE: This requirement is applicable to the following:\n - Calls established between DoD endpoints within an extended enclave (single MILDEP organization using directly interoperable VoIP systems)\n - Calls established between DoD endpoints located in different enclaves operated by a single MILDEP organization using directly interoperable VoIP systems. \n - Calls established between DoD endpoints located in different enclaves operated by different MILDEP organizations whether using directly interoperable VoIP systems and endpoints or the systems are subscribers to the DISN IPVS using IPVS standard protocols. \n - Calls established between remote DoD endpoints located outside their home enclave and connecting across the Internet and/or NIPRNet. In this case, a remote access VPN is used. \n\nNOTE: At this time, this requirement is not applicable for calls established from DoD to commercial VoIP telephones via commercial ITSP services implemented as a replacement for TDM based PSTN access. This is because there is no encryption standard for end-to-end VoIP sessions to which all ITSPs and phone vendors have subscribed. Once a universal standard is adopted and implemented, or translation gateways are developed, this requirement could then be applied. Before encryption standards are adopted, the world must adopt interoperable signaling and media standards. At this time, Session Border Controllers can provide some translation services. Additional considerations are discussed in the section on ITSP services.",
"description": "When VVoIP connections are established across a publicly accessible WAN, all communications confidentiality and integrity can be lost. Information gleaned from signaling messages can be used to attack the system or for other nefarious reasons. If VVoIP traffic is passed in the clear it is open to sniffing attacks. This vulnerability exists whether the traffic is on a LAN/CAN or a MAN/WAN. Native end-to-end encryption of the signaling and media mitigates this vulnerability. As a secondary solution, mitigation can be accomplished at the link-level through the incorporation of encrypted VPN tunneling technology. Both solutions are applicable when the communicating endpoints are operated by the same organization or they reside in enclaves operated by the same organization and the endpoints and supporting systems are interoperable. As such, encryption of some approved form is required to protect DoD-to-DoD communications across a public network such as the Internet or a publicly accessible network such as the NIPRNet.\n\nWhile end-to-end application or protocol level encryption is preferred, tunneling unencrypted VVOIP signaling and media traffic using approved commercial grade (Type 3) site-to-site or client-to-site (remote access) VPN technologies mitigates the risk. The inherent type 1 site-to-site encryption employed afforded classified networks, such as the SIPRNet, also meets this requirement, although such networks are not public or publicly accessible as a rule.\n\nDoD-to-DoD voice communications are generally considered to contain sensitive information. Local DoD enclaves connect to a DISN SDN via an access circuit. Unless the site is a host to a SDN, or close enough to it to be served by DoD owned facilities, some portion of the access circuit will utilize leased commercial facilities. Additionally, the DISN core network itself may traverse commercial services and facilities. Therefore, DoD voice and data traffic crossing the unclassified DISN must be encrypted. ",
"fixid": "F-20178r2_fix",
"fixtext": "Configure all DoD-to-DoD VVOIP signaling and media traffic traversing a public or publicly accessible WAN network (i.e., Internet, NIPRNet) to use FIPS 140-2 or NSA approved encryption, either natively at the application or protocol level, or by using network or data-link layer encryption (i.e., encrypted VPN or bulk link encryption). The encryption of VVOIP signaling and media traffic may either use native end-to-end basis or tunnel it using site-to-site or client-to-site (remote access) VPN technologies or bulk link encryption.",
"iacontrols": [
"EBRU-1",
"ECCT-1",
"ECSC-1"
],
"id": "V-8250",
"ruleID": "SV-8736r2_rule",
"severity": "high",
"title": "DoD-to-DoD VVoIP traffic traversing any publicly accessible wide area network (i.e. Internet, NIPRNet) must use FIPS 140-2 or NSA approved encryption.",
"version": "VVoIP 1400 (GENERAL)"
},
"V-8253": {
"checkid": "C-23617r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure all systems/servers hosting the Voice Mail Service are properly secured in accordance with the DSN STIG and applicable OS STIG (i.e., Windows, Unix, etc.).\n\nDetermine if the Voice Mail system/servers are based upon a general purpose OS for which there is a STIG or checklist. \n\nObtain a copy of the applicable OS and DSN SRR or Self Assessment results and review for compliance. If SRR results are not available, perform a review to determine if the STIGs have been applied. \n\nThis is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance\n\n",
"description": "Voice mail services are subject to the guidance and requirements in the DSN STIG. Older voice mail systems/servers commonly use proprietary OSs while newer ones can be designed to run on common general-purpose operating systems, such as, Microsoft Windows, UNIX or Linux. If this is the case, steps should be taken to ensure that these general-purpose operating systems are secured in accordance to the appropriate STIG. \n\n",
"fixid": "F-20134r1_fix",
"fixtext": "Ensure all systems/servers hosting the Voice Mail Service are properly secured in accordance with the DSN STIG and applicable OS STIG (i.e., Windows, Unix, etc.).\n\nSecure all Voice Mail systems/servers supporting the telephony environment. Apply the DSN STIG and all applicable OS STIGs (i.e., UNIX, Microsoft Windows, etc.) and ensure compliance with applicable STIG guidelines.\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-8253",
"ruleID": "SV-8739r1_rule",
"severity": "low",
"title": "The stand alone or IP connected Voice mail system/server is not secured to applicable OS and DSN STIG guidance.",
"version": "VVoIP 1040 (GENERAL)"
},
"V-8254": {
"checkid": "C-23621r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement: In the event a Voice Mail or Unified Mail server is VoIP enabled or connected to an IP network for user access to the Voice/Unified Mail service or for system management, ensure application services supporting the voice/unified mail service such as SQL, IIS, Apache, Oracle, Exchange, etc., are properly secured according to the appropriate STIGs.\n\nDetermine if the Voice/Unified Mail servers are connected to an IP network. Then determine if it is based upon any of the general purpose application technologies for which there is a STIG or checklist. Note: compliance with these STIGs is in addition to compliance with the DSN and applicable OS STIGs as covered under VoIP 0330.\n\nObtain a copy of the applicable SRR or Self Assessment results and review for compliance. If SRR results are not available, perform a review to determine if the STIGs have been applied \n\nThis is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance\n",
"description": "Voice mail and Unified Mail services in a VoIP environment are available in several different configurations. For example, a legacy voice mail platform can connect to a VoIP gateway to provide voice mail services for VoIP users. In the same respect, a VoIP based voice mail platform can provide voice mail services to the legacy voice users and the VoIP users. In addition to providing traditional voice mail services, many VoIP voice mail systems are also capable of providing unified mail (integrated voice and electronic mail), or by interacting with existing email messaging systems. Voice mail services are commonly configured to run on common operating systems, such as, Microsoft Windows NT, Windows 2000, or Sun Solaris. Steps should be taken to ensure that these operating systems are secured in accordance to the appropriate STIG. Application services supporting the voice mail services should also be hardened. For example, MS SQL Server may be used to support subscriber accounts, or MS IIS may be used to allow subscribers to change their voice mail settings using an Internet Browser. Various VoIP solutions use various application services to provide Voice and voice mail support. Many of these applications can provide access to the VoIP environment via unsecured channels. This can happen through the abuse and use of enabled but unused services or through known un-patched vulnerabilities that exist on common application servers. All unused services are to be disabled and all application servers are to be secured using the applicable STIG guidance. ",
"fixid": "F-20136r1_fix",
"fixtext": "In the event a Voice Mail or Unified Mail server is VoIP enabled or connected to an IP network for user access to the Voice/Unified Mail service or for system management, ensure application services supporting the voice/unified mail service such as SQL, IIS, Apache, Oracle, Exchange, etc., are properly secured according to the appropriate STIGs\n\nSecure IP connected Voice/Unified Mail servers. Apply all applicable general purpose application STIGs (i.e., Database, Web, Application Services, e-mail, etc.) and ensure compliance with applicable STIG guidelines.\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-8254",
"ruleID": "SV-8740r1_rule",
"severity": "medium",
"title": "IP connected Voice/Unified Mail servers have not been secured using all applicable general purpose application STIGs. ",
"version": "VVoIP 1045 (GENERAL)"
},
"V-8255": {
"checkid": "C-23710r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement: In the event voicemail subscribers can access their voicemail settings via an IP or \u201cweb\u201d connection (in addition to having the standard normal capability from the phone via the dial pad), ensure the connection is encrypted using HTTPS with TLS. Additionally, ensure the web server on the voicemail system/server is configured in accordance with \u201cprivate web server\u201d requirements in the Web Services STIG/Checklist.\n\nNOTE: Web Services STIG/Checklist requirements include but are not limited to user CAC/PKI authentication\n\nInspect the Web SRR results from the web server review performed on the web based personal settings interface to the voicemail system. If there is none, perform a Web SRR. This check is not intended to determine if the asset is in full compliance, it is only to determine if the applicable STIG has been applied.\n\nThis is a finding in the event the voicemail system provides a web interface that is either not configured in accordance with the applicable Web STIG/Checklist requirements and/or it does not the web interface does not use HTTPS/TLS.",
"description": "In traditional TDM phone systems, personal voicemail settings and greetings are accessed / configured by the subscriber/user on traditional voicemail servers via the traditional telephone. Control commands are dialed using the keypad and transmitted using Dial-Tone Multi-Frequency (DTMF) audio tones. The voice greetings are transmitted using normal audio as well. The audio can be analog or digital, which is encoded in whatever coding scheme is used by the local PBX. In IP based phone systems access to the voicemail server carries the same vulnerabilities as the IP voice communications carried by the system. As such access to voicemail for the purpose of creating greeting messages, retrieving voicemail, or adjusting personal settings, must be encrypted on the IP network. In part this is because anyone with a sniffer and access to the right LAN segment can acquire the subscriber\u2019s account and password information. With this intercepted information a hacker could gain access to the subscribers voice mail account, intercept sensitive information, and/or perform other destructive actions. Once access to settings is achieved there the intruder could change greetings or possibly forward all voicemails received.\n\nEncryption of the voice message traffic as well as control from the phone\u2019s dial-pad falls under the normal requirement for the encryption of VoIP signaling and media.\n\nIn the event the subscriber\u2019s personal settings are accessible via a \u201cweb\u201d connection using a browser on the subscriber\u2019s desktop or phone, the connection must use HTTPS and TLS minimally to protect the user\u2019s logon credentials. Additionally, the voicemail system/server, which provides this service via a web server application, must be configured in accordance with the \u201cprivate web server\u201d requirements in the Web Server STIG/Checklist.\n",
"fixid": "F-20188r1_fix",
"fixtext": "Configure the voicemail system web access to personal settings in accordance with the applicable private web server requirements in the Web STIG/Checklist and ensure web interface is configured to use HTTPS/TLS.\n",
"iacontrols": [
"EBRU-1",
"ECCT-1",
"ECSC-1"
],
"id": "V-8255",
"ruleID": "SV-8741r1_rule",
"severity": "medium",
"title": "Access to personal voice mail settings by the subscriber via an IP connection is not secured via encryption and/or web\u201d server on the voicemail system is not configured in accordance with the \u201cprivate web server\u201d requirements in the Web Server STIG/Checklist. ",
"version": "VVoIP 1520 (GENERAL)"
},
"V-8256": {
"checkid": "C-23624r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement: In the event IP based VVoIP (V-V) services are used over a Wireless LAN (WLAN - Wi-Fi 802.11x) or Wireless MAN (WMAN - WiMAX 802.16) connection, Ensure the applicable endpoint and service related requirements contained in the Wireless STIG/Checklist have been applied to the wireless VVoIP service and endpoints in addition to the applicable VoIP STIG/Checklist requirements.\nNOTE: If a wireless LAN exists, the WLAN must already be implemented and secured per the Wireless STIG.\n\nNOTE: If registering an IP based wireless VVoIP endpoint asset in the DISA VMS apply the following postures to ensure the applicable checks are assigned and reviewed.\n> If the wireless endpoint is a PDA or smartphone, ensure the following VMS condition has been applied \"Computing \u2013Network \u2013 Wireless - PDA/PED\u201d.\n > If the phone uses WLAN, the following condition should be applied in VMS to the asset \"Computing \u2013Network \u2013 Wireless \u2013 wireless Client - Wireless LAN Client\u201d.\n> If the phone uses WiMax, the following condition should be applied in VMS to the asset \"Computing \u2013Network \u2013 Wireless \u2013 wireless Client - WMAN Subscriber\u201d.\n\nDetermine if the site has implemented or supports IP based wireless (802.11x or 802.16) VVoIP endpoints. If so this implies that there is a supporting WLAN and any applicable requirements in the Wireless STIG apply to the wireless VVoIP endpoints and service in addition to those in this checklist. \n\nObtain a copy of the Wireless SRR or Self Assessment results and review for compliance. If SRR results are not available, then perform a wireless SRR on a representative number of wireless VVoIP endpoints and on the service. \n\nAreas of primary concern are, but are not limited to the following:\n> Is the endpoint an approved endpoint?\n> Is the endpoint configured to support the required VoIP endpoint, registration, authentication, and media/signaling encryption requirements? \n> Is the endpoint configured to support the required WLAN access control, authentication, and encryption requirements?\n\nThis is a finding in the event it is evident that the appropriate STIGs have not been applied. This check is not intended to determine if the asset is in full compliance. Additionally, this check does not relate to the STIG compliance of the WLAN itself. However if the WLAN is not STIG compliant, then the wireless VVoIP endpoints and service it supports will not meet STIG requirements. Ergo this is a finding.\n\nNOTE: Wireless endpoints in this case are typically going to be handheld devices of some sort such as a dedicated VoIP only \u201ccordless phone\u201d, a cellular phone with dual cellular and Wi-Fi (possibly including WiMAX) capabilities, or a PDA/PED with a VoIP soft-phone installed. However, the endpoints could also be desk phones and some could also support Bluetooth headsets, which are also covered in the Wireless STIG/Checklist.\nNOTE: Wireless VVoIP service relates to the conveyance of the V-V traffic over the wireless LAN/MAN including related requirements for encryption and endpoint authentication. This requirement does not relate directly to the VVoIP infrastructure connected to a wired LAN that also happens to be using wireless transport. \n",
"description": "The incorporation of wireless technology into the VVoIP environment or service elevates many existing VoIP concerns such as quality of service (QoS), network capacity, provisioning, architecture and not the least important, security. Many government entities are exploring mobile communication solutions that include wireless VoIP that can meet critical needs for interoperability and flexibility. This will soon expand to video and unified communications over wireless. IP based wireless voice services and devices (endpoints) initially used Wi-Fi (802.11(x)) wireless LAN (WLAN) technologies. These devices are still available today and are essentially a cordless phone that happens to use Wi-Fi. Today vendors are integrating 802.11(x) VoIP capabilities into cellular phones that can transition seamlessly between a cellular network and a WLAN. This means that a user can place a call using the WLAN in their office and then move out of range and transition to their cellular carrier\u2019s network without losing the call. Such a transition can operate in the other direction as well. Other devices integrate Cellular and Wi-Fi with WiMAX (802.11(e)) capabilities providing similar transitions as well as enterprise grade presence, messaging, directories, email, etc. Additionally, SmartPhones can support VoIP softphone applications which utilize the smartphone\u2019s native IP connectivity. Similarly SmartPhone supported connectivity can be over cellular, Wi-Fi, and/or WiMAX network. Using these capabilities over wireless technologies presents vulnerabilities to the communications carried and the VVoIP infrastructure. Confidentiality is one of the greatest concerns requiring encryption of the media and signaling as it is on a wired MAN/WAN or LAN per the VoIP STIG/Checklist but even more so. This encryption is in addition to the WLAN encryption required by the Wireless STIG/Checklist. Additionally, per the Wireless STIG/Checklist, the endpoints must authenticate to the WLAN before being granted access thus preventing rogue endpoints and other devices from accessing the network, while the endpoint must also register with the VVoIP controllers. Another great concern for using wireless VVoIP communications services is reliability and availability when using the technology for critical C2 communications. Being wireless, all of the usual issues with radio transmission and reception come into play. In the event a C2 call is initiated, it could be blocked at either the transmitting end or the receiving end. This could be because the spectrum or channels could be busy/overloaded, unavailable, or deliberately jammed by an adversary. As such, VVoIP services should not be relied upon for C2 communications. NOTE: If Wireless VoIP technology is deployed all the requirements in the VoIP STIG/Checklist as well as those contained in the Wireless STIG/Checklist are to be applied to the wireless VoIP environment. ",
"fixid": "F-7739r1_fix",
"fixtext": "Apply requirements contained in both the VoIP STIG and the Wireless STIG wherever VoIP over Wireless is used.",
"iacontrols": [
"ECSC-1",
"ECWN-1"
],
"id": "V-8256",
"ruleID": "SV-8742r1_rule",
"severity": "low",
"title": "IP based VVoIP services over Wireless LAN (WLAN - Wi-Fi 802.11x) or Wireless MAN (WMAN - WiMAX 802.16) are being used without the applicable Wireless STIG/Checklist security guidance applied to the wireless service or endpoints in addition to the VoIP STIG/Checklist requirements.",
"version": "VVoIP 1035 (GENERAL)"
},
"V-8257": {
"checkid": "C-23596r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure that new or recently installed VVoIP systems, devices, and/or their software loads are certified, accredited, and placed on the DoD Approved Products List per DODI 8100.3 and UCR prior to obtaining an Authority to Connect (ATC). Further ensure that existing systems appear on the current APL or the retired product list. NOTE: upgrades to and new software loads for existing systems and devices must appear on the current APL.",
"description": "DoD Instruction 8100.3 governs DoD telecommunications, the Defense Switched Network (DSN), and the Defense RED Switched Network (DRSN), and requires that \u201cTelecommunications switches (and associated software releases) leased, procured (whether systems or services), or operated by the DoD Components, and connected or planned for connection to the DSN or PSTN, shall be joint interoperability certified by the Defense Information Systems Agency (DISA), Joint Interoperability Test Command (JITC) and granted information assurance certification and accreditation by the Defense Information System Network (DISN) Designated Approval Authorities (DAAs).\u201d DAA certification is obtained through the DISN Security Accreditation Working Group (DSAWG). DoDI 8100.3 also requires that the DoD use (or connect to the DISN) only devices that appear on the DoD Approved Products List (APL). Both IA and Interoperability certification requirements must be met for inclusion on the DoD APL. NOTE: The DoD APL was formerly referred to as the DSN APL. Any interconnected VVoIP system or device poses a potential security risk to the DISN and should not be connected until interoperability certification by the DISA Joint Interoperability Test Command (JITC) and Information Assurance Certification and Accreditation by the DSAWG is completed per the requirements of the DoDI 8100.3. This testing is required on two fronts to ensure that the system/device will interoperate with other DoD systems in support of C2 communications requirements and that it can be secured to within an acceptable level of risk. Once approved, and APL listed, DoD components may purchase and install the systems while following the deployment restrictions and configuration guidance developed during testing. NOTE: Through the publication of the UCR, the APL requirements are being extended by OSD/NII to cover all network elements and components that support converged Assured Service (C2) communications. ",
"fixid": "F-20111r1_fix",
"fixtext": "Ensure that new or recently installed VVoIP systems, devices, and/or their software loads are certified, accredited, and placed on the DoD Approved Products List per DODI 8100.3 and UCR prior to obtaining an Authority to Connect (ATC). Further ensure that existing systems appear on the current APL or the retired list. NOTE: upgrades to and new software loads for existing systems and devices must appear on the current APL.",
"iacontrols": [
"EBCR-1"
],
"id": "V-8257",
"ruleID": "SV-8743r1_rule",
"severity": "medium",
"title": "New or recently installed VVoIP systems, devices, and/or their software loads are NOT certified, accredited, and placed on the DoD Approved Products List per DODI 8100.3 and UCR OR existing systems DO NOT appear on the current APL or the \u201cRetired APL\u201d lists.",
"version": "VVT 1115 (GENERAL)"
},
"V-8288": {
"checkid": "C-23600r1_chk",
"checktext": "Interview the IAO to validate compliance with the following requirement: Ensure that a policy/SOP is in place and enforced to ensure that the IPT terminal (VoIP phone or instrument) configuration and display password/PIN is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage).\n\nAdditionally investigate the enforcement of the SOP.\n\nThis is a finding in the event there is no SOP addressing the concern here or the SOP does not adequately address the related DoD policies OR the policy/SOP is not enforced. \n",
"description": " \nPer other requirements, the network configuration information and settings on a VoIP instrument must be protected by a password or PIN. VVoIP endpoints do not typically provide automated PIN/password management. PINs that are not managed or required to be changed are most likely never changed, therefore they are easily compromised or guessed. Additionally as SA personnel change, the group passwords and PINs they know and use must be changed. As such, the organization must have and follow a policy and procedure for managing the passwords or PINs used to access the local VoIP phone network configurations. Such a SOP should address password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage. NOTE: Most instruments will only accept numerical input therefore a PIN is used. Some instruments may accept alpha characters for passwords. These factors help determine the password/PIN complexity that is achievable.\n",
"fixid": "F-20116r1_fix",
"fixtext": "Ensure that a policy/SOP is in place and enforced to ensure that the IPT terminal (VoIP phone or instrument) configuration and display password/PIN is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage).\n\nDevelop a policy/SOP and enforced it to ensure that the IPT terminal (VoIP phone or instrument) configuration and display password is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage)).\n",
"iacontrols": [
"ECSC-1",
"IAIA-1",
"IAIA-2"
],
"id": "V-8288",
"ruleID": "SV-8783r1_rule",
"severity": "medium",
"title": "A policy/SOP is NOT in place OR NOT enforced to ensure that the VVoIP terminal (VoIP phone or instrument) configuration and display password/PIN is managed IAW DOD password policies (e.g., password/PIN complexity (length and character mix), expiration, change intervals, other conditions requiring a change, reuse, protection and storage).",
"version": "VVoIP 1500 (GENERAL)"
},
"V-8290": {
"checkid": "C-23627r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure that an inventory of authorized instruments is documented and maintained.\n\nInspect the authorized instrument inventory.\n\nNOTE: This inventory will be separate from the inventory created within the Local Session Controller (LSC) from the listing of registered instruments. Authorized instruments must be added to this inventory before configuration in the LSC and instrument registration. The inventory may be offline or online on a separate server or workstation from the LSC (for example, the LSC management workstation).\n\nThis is a finding if the inventory does not exist, does not appear to be up to date.\n\nAsk how this inventory is generated and where it is stored. This is a finding in the event it is located on the LSC. ",
"description": "Traditional telephone systems require physical wiring and/or switch configuration changes to add an instrument to the system. This makes it difficult for someone to add unauthorized digital instruments to the system. This, however, could be done easier with older analog systems by tapping an existing analog line. With VoIP, this is no longer the case. Most IPT/VoIP systems employ an automatic means of detecting and registering a new instrument on the network with the call management server and then downloading its configuration to the instrument. This presents a vulnerability whereby unauthorized instruments could be added to the system or instruments could be moved without authorization. Such activity can happen anywhere there is an active network port or outlet. This is not only a configuration management problem, but it could also allow theft of services or some other malicious attack. It is recognized however, that auto-registration is necessary during large deployments of VoIP terminals, as well as a short time thereafter, to facilitate additions and troubleshooting. This applies to initial system setup and to any subsequent large redeployments or additions. Normal, day to day, \u201cmoves, adds, and changes\u201d will require manual registration. Since, it may be possible for an unauthorized VoIP terminal to easily be added to the system during auto-registration, the registration logs must be compared to the authorized terminal inventory. Alternately the system could have a method of automatically registering only pre-authorized terminals. This feature would support VoIP terminals that are DAA approved for connection from multiple local or remote locations. It is critical to the security of the system that all IPT /VoIP end instruments be authorized to connect to and use the system. Only authorized instruments should be configured in the system controller and therefore allowed to operate. Unauthorized instruments could lead to system compromise or abuse. A manual inventory of authorized end instruments will aid in the detection of unauthorized instruments registered to the system particularly during the period when auto-detection/registration is permitted. This will also aid in C&A efforts. ",
"fixid": "F-20141r1_fix",
"fixtext": "Ensure that an inventory of authorized instruments is documented and maintained.\nNOTE: This inventory will be separate from the inventory created within the Local Session Controller (LSC) from the listing of registered instruments. Authorized instruments must be added to this inventory before configuration in the LSC and instrument registration. The inventory may be offline or online on a separate server or workstation from the LSC (for example, the LSC management workstation).\n\nPrepare and maintain an inventory / database of authorized VoIP instruments. Generate and store the inventory on a separate workstation or server from the LSC (for example, the LSC management workstation).\n\nRecommendation: Create the inventory in a format that can easily be compared through automation to the report of registered instruments from the LSC (if available). This will facilitate regular review of the inventory to detect unauthorized instruments and will make the IA review easier.\n\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-8290",
"ruleID": "SV-8785r1_rule",
"severity": "medium",
"title": "An inventory of authorized instruments is NOT documented or maintained in support of the detection of unauthorized instruments connected to the VoIP system.",
"version": "VVoIP 1505 (GENERAL)"
},
"V-8294": {
"checkid": "C-23793r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event the VVoIP system is designed to use DHCP for initial VVoIP endpoint address assignment/configuration, ensure the design incorporates a different DHCP server than any that might be used for data components/hosts. Additionally ensure these servers reside in their respective voice or data address space and VLAN.\n\nNOTE: Soft-phones or VVoIP/UC applications residing on PC/workstations will, by default, utilize the IP information obtained by the workstation from the data DHCP server unless the workstation and soft-phone is capable of multiple VLANs and the soft-phone is assigned to the VVoIP VLAN. In case of the latter, the workstation or the soft-phone itself may obtain its IP information from the VVoIP DHCP server for use by the soft-phone or VVoIP application. \n\n\nDetermine if, in the VVoIP system design, DHCP is used for VVoIP endpoint address assignment/configuration. If so, determine the location of the DHCP server and whether it is dedicated to the VVoIP system (separate from the data host DHCP server) and is deployed in the core VVoIP VLAN with an appropriate IP address within the dedicated VVoIP address space. This is a finding in the event DHCP is used for VVoIP endpoint address assignment/configuration and these conditions are not met.\n\nNOTE: It is recommended that the VVoIP DHCP server used as discussed in this requirement be implemented in the following order of preference: a dedicated device, part of the VVoIP call controller (LSC/MFSS) or other VVoIP related server; on an infrastructure router inside the enclave that is directly involved in the control of the VVoIP system or VLANs. \n\nNOTE: The Network Infrastructure STIG precludes the implementation of a DHCP server on a perimeter router. \n\n",
"description": "When using Dynamic Host Configuration Protocol (DHCP) for address assignment and host configuration, different DHCP scopes (different address space, subnets, and VLANs) must be used for voice components and data components. This is most easily and safely accomplished by providing a DHCP server that is dedicated to the VVoIP system endpoints. That is to say that a DHCP server serving VVoIP devices needs to be in the VVoIP domain i.e., same address space and VLAN(s). This alleviates the need to route DHCP requests into the data environment on the LAN which would degrade the separation of the VVoIP environment and the Data environment. \n\nNOTE: In the event a dedicated DHCP server for VVoIP endpoints is not implemented, the network (i.e., the router controlling access to and from the VVoIP endpoint VLANs) must route VVoIP endpoint DHCP requests directly to the DHCP server in such a manner that prevents traffic to flow between the VVoIP and data VLANs. Additionally the DHCP server must prevent such traffic flows while providing the VVoIP endpoints with proper VVoIP addresses and other information within the VVoIP address/subnet range (scope).\n\nNOTE: The best practice for endpoint address assignment is to manually assign addresses when authorizing the instrument by generating its configuration file. \n\n\n\n",
"fixid": "F-20239r1_fix",
"fixtext": "If the VVoIP system design uses DHCP for VVoIP initial endpoint address assignment/configuration, ensure the design incorporates a different DHCP server than any that might be used for data components/hosts. Additionally ensure these servers reside in their respective voice or data address space and VLAN.\n\nNOTE: Soft-phones or VVoIP/UC applications residing on PC/workstations will, by default, utilize the IP information obtained by the workstation from the data DHCP server unless the workstation and soft-phone is capable of multiple VLANs and the soft-phone is assigned to the VVoIP VLAN. In case of the latter, the workstation or the soft-phone itself may obtain its IP information from the VVoIP DHCP server for use by the soft-phone or VVoIP application. \n\nNOTE: It is recommended that the VVoIP DHCP server used as discussed in this requirement be implemented in the following order of preference: a dedicated device, part of the VVoIP call controller (LSC/MFSS) or other VVoIP related server; on an infrastructure router inside the enclave that is directly involved in the control of the VVoIP system or VLANs. \n\nNOTE: The Network Infrastructure STIG precludes the implementation of a DHCP server on a perimeter router. \n\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-8294",
"ruleID": "SV-8789r1_rule",
"severity": "low",
"title": "The VVoIP system DHCP server is not dedicated to the VVoIP system within the LAN. ",
"version": "VVoIP 5210 (LAN)"
},
"V-8295": {
"checkid": "C-23794r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure customers of the DISN VoSIP service use IP addresses assigned to them by the DRSN/VoSIP PMO when defining the required dedicated address space for the VoIP controllers and endpoints within their secret C-LANs.\n\nNOTE: This is similarly applicable to other classified DISN services and customer\u2019s C-LANs.\nNOTE: This is not a requirement in the event a VoIP based VVoIP communications system operated in a secret C-LAN has no need or potential need to use the worldwide DISN VoSIP service or have access the DRSN and communicate with other enclaves that do use the DISN service or have access the DRSN, they must utilize their own dedicated IP address space carved out of the address space assigned to their C-LANs by the SIPRNet PMO in accordance with the previously noted requirement.\n\nNOTE: This requirement does not directly apply to dedicated hardware based IP - VTC systems using the C-LAN and SIPRNet for transport although there may be similar requirements to address this technology in the future.\n\nDetermine the following:\nIs the organization\u2019s secret C-LAN connected to SIPRNet?\nDoes the organization\u2019s secret C-LAN support VVoIP communications (Not dedicated IP based VTC)?\nDoes organization\u2019s secret C-LAN VVoIP system interconnect with other enclaves using the DISN VoSIP service?\nWhat address blocks are dedicated to the VVoIP system on the C-LAN?\nIs there documented evidence that the DRSN/VoSIP PMO assigned these addresses to the organization or can such assignment be validated by other means?\n\nThis is a finding in the event the organization\u2019s secret C-LAN supports VVoIP communications (Not dedicated IP based VTC) AND is connected to SIPRNet AND uses the DISN VoSIP service BUT DOES NOT use the DRSN/VoSIP PMO assigned address blocks when addressing all of the VVoIP system components. \n\n",
"description": "A previous requirement states the following: Ensure a different, dedicated, address blocks or ranges are defined for the VVoIP system within the LAN (Enclave) that is separate from the address blocks/ranges used by the rest of the LAN for non VVoIP system devices thus allowing traffic and access control using firewalls and router ACLs. \nNOTE: This is applicable to the following: > A classified LAN connected to a classified WAN (such as the SIPRNet). \n\nNOTE: In the case of a classified WAN where network wide address based accountability or traceability is required by the network PMO, the PMO must provide a segregated, network wide address block(s) so that the attached classified LANs can meet this requirement. DISA provides a world wide VoIP based voice communications service called the DISN Voice over Secret IP (VoSIP) service or just VoSIP for short. This service is managed by the DRSN PMO. This service also provides gateways into the DRSN. In support of the above requirement, the SIPRNet PMO has designated specific dedicated address ranges for use by the DISN VoSIP service and assigned these address blocks to the DRSN/VoSIP PMO for VoSIP address management and assignment. The VoSIP service provides VoIP based communications between VoIP systems within customer\u2019s classified LANs (C-LANs) operating at the secret level while using the SIPRNet WAN for the inter-enclave (inter-LAN) transport. Additionally, the SIPRNet PMO requires network wide address based accountability or traceability based on assigned IP address. As such customer\u2019s SIPRNet connected secret C-LANs utilize addresses assigned by the SIPRNet PMO. Therefore, customers of the DISN VoSIP service must use IP addresses assigned to them by the DRSN/VoSIP PMO when addressing the VoIP controllers and endpoints within their C-LANs. This is to maintain the segregation of the Voice and data environments on the customer\u2019s secret C-LANs as required by this STIG. This also facilitates proper routing and flow control over the traffic between VoSIP addresses. \n\nNOTE: the DISN service is designated DISN Voice over Secret IP but uses an acronym (VoSIP) which also means Voice over Secure IP. Voice over Secure IP relates to any VoIP based service on a secure or classified IP network. \n\nNOTE: While the DISN VoSIP service is the preferred means to interconnect SIPRNet connected secret C-LANs for VoIP service, it is recognized that there may be a need for an organization to implement a VoIP based voice or video communications system within their organization or with close partners. In the event such a system has no need or potential need to communicate with other enclaves that use the DISN VoSIP service, they must utilize their own dedicated IP address space carved out of the address space assigned to their C-LANs by the SIPRNet PMO in accordance with the previously noted requirement. \n",
"fixid": "F-20240r1_fix",
"fixtext": "Ensure customers of the DISN VoSIP service use IP addresses assigned to them by the DRSN/VoSIP PMO when defining the required dedicated address space for the VoIP controllers and endpoints within their secret C-LANs.\nNOTE: This is similarly applicable to other classified DISN services and customer\u2019s C-LANs.\n\nNOTE: This is not a requirement in the event a VoIP based VVoIP communications system operated in a secret C-LAN has no need or potential need to use the worldwide DISN VoSIP service or have access the DRSN and communicate with other enclaves that do use the DISN service or have access the DRSN, they must utilize their own dedicated IP address space carved out of the address space assigned to their C-LANs by the SIPRNet PMO in accordance with the previously noted requirement.\n\nNOTE: This requirement does not directly apply to dedicated hardware based IP - VTC systems using the C-LAN and SIPRNet for transport although there may be similar requirements to address this technology in the future.\n\nObtain and assign IP addresses as provided by the DRSN PMO- VoSIP department when defining the required dedicated address space on the LAN.\n",
"iacontrols": [
"DCBP-1",
"DCPA-1",
"ECSC-1"
],
"id": "V-8295",
"ruleID": "SV-8790r1_rule",
"severity": "low",
"title": "Customers of the DISN VoSIP service on ARE NOT utilizing address blocks assigned by the DRSN / VoSIP PMO.",
"version": "VVoIP 5215 (LAN)"
},
"V-8302": {
"checkid": "C-23781r1_chk",
"checktext": "Interview the IAO and review site network/facilities diagrams and documentation to confirm compliance with the following requirement: \n\nIn the event VVoIP services are provided by an IP based network to Special-C2 and C2 subscribers/users, ensure the network supporting VVoIP services (i.e., the underlying data network) is designed and implemented as an Assured Services Local Area Network (ASLAN) such that it will possess bandwidth, reliability, survivability, quality of service (QoS) and prioritization capabilities in accordance with the current Unified Capabilities Requirements (UCR) specifications.\nNOTE: This applies to all types of C2 users whether they have the need to originate precedence calls or not. C2 routine users may receive high priority calls therefore the LAN must support the capability. \n\n\nDetermine the types of users or subscribers supported by the IP VVoIP services network. Refer to the Procedures Guide for the various user/subscriber type definitions to determine applicability of this requirement.\n\nThis is a finding in the event the LAN is not designed as an ASLAN in support of its C2 and Special-C2 user\u2019s availability and reliability requirements. The following is a list of the areas to be addressed by the design (validation will be addressed later):\n\nSpecific attention should be given in the areas of:\n- Equipment reliability and redundancy \n- Connection redundancy above the access layer\n- Equipment robustness and bandwidth capability\n- Connection bandwidth capability\n- Access layer switch size / number of phones served \n- Single points of failure affecting service to greater than 96 instruments.\n- Backup power for all equipment. \n>> 2 hours for all equipment and instruments supporting C2 users\n>> 8 hours for all equipment and instruments supporting Special-C2 users\n\nSpecific requirements or deficiencies will be investigated in subsequent checklist items.\n\nNOTE: The primary difference between this requirement and the general requirement checked earlier is that the availability and reliability requirements in support of C2 and Special-C2 users are higher than C2R, Non C2, and administrative users.\n\n",
"description": "Voice services in support of C2 and Special C2 users are required to meet certain minimum requirements relating to reliability and survivability of the supporting infrastructure. These requirements are defined in the current CJCSI 6215.01x Policy for DoD Voice Networks With Real Time Services (RTS). Design requirements for networks supporting DOD IPT/VoIP implementations can be found in the Unified Capabilities Requirements (UCR) specification document. This document contains the design specifications for an Assured Services Local Area Network (ASLAN) which is required to support DOD IP based voice services. These specifications define LAN design requirements for redundancy of equipment and their interconnections as well as minimum requirements for bandwidth and backup power, including the maximum number of endpoints that can be affected by a single point of failure. Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. Policy excerpts are as follows: From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN \u2013 Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN \u2013 Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details.",
"fixid": "F-20217r1_fix",
"fixtext": "Ensure that the network supporting VVoIP services (i.e., the underlying data network) is designed and implemented as an Assured Services Local Area Network.(ASLAN) and will possess bandwidth, reliability, survivability, quality of service (QoS) and prioritization capabilities in accordance with the current Unified Capabilities Requirements (UCR) specifications\n\nUpgrade the LAN infrastructure as necessary to meet requirements of a DoD ASLAN supporting C2 users as specified in the UCR and CJCSI 6215.01x.\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-8302",
"ruleID": "SV-8797r1_rule",
"severity": "low",
"title": "The LAN supporting VVoIP services for special-C2 and C2 users is not designed or implemented as a DOD ASLAN in accordance with the current UCR and therefore cannot support assured service in support of C2 communications reliability and availability requirements.",
"version": "VVoIP 5105 (LAN)"
},
"V-8306": {
"checkid": "C-23809r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure a VVoIP or VTC hardware endpoint possessing a \u201cPC Port\u201d is capable of maintaining voice/data VLAN separation via the use of an Ethernet switch and that it does not contain an Ethernet hub OR ensure the \u201cPC Port\u201d is physically disabled. \n\nReview VVoIP or VTC hardware endpoint specifications and documentation.\n\nThis is a finding in the event the VVoIP or VTC hardware endpoint that provides PC port but cannot maintain voice/data VLAN separation. \n\n",
"description": "Some VVoIP hardware endpoints and hardware based VTC endpoints have a second Ethernet port on the device to provide a connection to external devices such as a. This port is typically called a \u201cPC Port\u201d. This is done so that a can share a single network cable drop and LAN access switchport. The PC port can, in general, support any device requiring an Ethernet connection. In theory, a VoIP phone, a desktop VTC unit, and a workstation could be daisy chained on a single LAN drop. These PC ports are supported by an embedded three port Ethernet switch or a hub. Hubs cannot support VLANs and therefore cannot be used to daisy chain VVoIP endpoints and non VVoIP devices in DoD networks. A switch must be used because the VVoIP or VTC endpoint must be capable of maintaining the separation of the voice (VVoIP), data, VLANs as well as the VTC VLAN and PC Comm Client VLAN if present. For example the attached PC must not be able to directly access the phone\u2019s or VTU\u2019s configurations or communications traffic. VAN separation helps to prevent this. NOTE: the switch or endpoint will typically utilize 802.1Q trunking (VLAN tagging) but may use some other means to separate voice and data traffic. Typically when 802.1Q VLAN tagging is used, the phone firmware tags the VoIP packets while the embedded switch passes all packets without modification. This permits devices connected to the PC port to tag their packets and assign the proper VLAN to their traffic type. 802.1Q VLAN tagging enables the LAN to better maintain separation of the traffic and is therefore the preferred method. ",
"fixid": "F-20257r1_fix",
"fixtext": "Ensure a VVoIP or VTC hardware endpoint possessing a \u201cPC Port\u201d contains an Ethernet switch such that VLAN separation can be maintained and that it does not contain an Ethernet hub OR ensure the \u201cPC Port\u201d is physically disabled. \n\n",
"iacontrols": [
"DCPA-1",
"ECSC-1"
],
"id": "V-8306",
"ruleID": "SV-8801r1_rule",
"severity": "medium",
"title": "A hardware based VVoIP or VTC endpoint possesses or provides a \u201cPC Port\u201d but does not maintain the required VLAN separation through the implementation of an Ethernet switch (not a hub).",
"version": "VVoIP 5700 (LAN)"
},
"V-8323": {
"checkid": "C-23806r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure a comprehensive VVoIP VLAN ACL design is developed for the supporting LAN such that VVoIP system access and traffic flow is properly controlled. \n\nIn general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address / subnet, protocol type, and associated standard IP port for the protocol. In general the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system. \n\n\nSee the \u201cprocedures guide\u201d for a detailed example of the required ACL design. The design will change depending on the specifics of the VVoIP system implementation; i.e., the components used and defined VLANs. The design as shown is developed in reference to the VLAN it protects and the device type on which they are implemented.\n\nThis is a finding in the event a comprehensive VVoIP VLAN ACL design has not been developed and documented. Validation that they are implemented will be done via a series of computing checks. \n\nNOTE: The IAO will maintain design documentation for inspection by auditors.\n",
"description": "Previous requirements in this STIG/Checklist define the need for dedicated VVoIP VLANs and IP subnets to provide the capability for VVoIP system access and traffic control. This control is implemented through the use of a properly designed set of ACLs on the LANs routing device(s) (router or layer-3 switch(s) capable of implementing ACLs) for each of the defined VLAN/subnets implemented. This requirement defines the ACLs that manage the flow of traffic between the various VVoIP VLAN/subnets. As a refresher, the VLAN/subnets are defined as follows: > Hardware Endpoints: multiple VLAN/subnets generally in parallel with data LAN VLANs the number of which is dependant on the size of the LAN and as required for the reduction of broadcast domains per good LAN design. For small networks there will be a minimum of one. > Software endpoints on workstations: multiples as with hardware endpoints. > VVoIP system core control equipment containing the LSC, endpoint configuration server, and DHCP server if used, etc > VVoIP system management VLAN which is separate from the general LAN management VLAN > Media gateways to the DSN and PSTN > Signaling gateways (SG) to the DSN > DoD WAN access VVoIP firewall (EBC) > Voicemail / Unified Messaging Servers. These may need to be accessible from both the voice and data VLANs. > UC servers such as those supporting IM/presence, \u201cweb\u201d browser based conferencing, and directory services. These may need to be accessible from both the voice and data VLANs. NOTE: The VLAN/subnets and associated ACLs need only to be assigned / applied for devices that exist in the VVoIP system. The VLAN / ACL design may change depending upon the location and physical makeup of the VVoIP core equipment. An example of this is if a MG and SG reside on the same platform and both use the same Ethernet LAN connection(s) (and potentially the same or different IP address(s)), then separate VLANs are not needed for the MG and SG but the ACL protecting them may need to be adjusted accordingly. In general the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address / subnet, protocol type, and associated standard IP port for the protocol. In general the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system The \u201cProcedure Guide: defines a nominal design for the ACLs for each VLAN interface. Validation that they are implemented will be done via a series of computing checks. ",
"fixid": "F-20256r1_fix",
"fixtext": "Ensure a comprehensive VVoIP VLAN ACL design is developed for the supporting LAN such that VVoIP system access and traffic flow is properly controlled. \n\nIn general the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address / subnet, protocol type, and associated standard IP port for the protocol. In general the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should log and alarm on inappropriate traffic. An example of this is an HTTP request sourced from the data VLAN(s) to the endpoint or media gateway VLAN(s). The primary purpose of ACL on all VVoIP VLAN interface(s) is to block traffic to/from the data VLAN interface(s). Similar restrictions are placed on a dedicated VTC VLAN interface, however, VVoIP media and signaling is permitted in the event a VTC unit needs to communicate with the UC system. \n\n\nSee the \u201cprocedures guide\u201d for a detailed example of the required ACL design. The design will change depending on the specifics of the VVoIP system implementation; i.e., the components used and defined VLANs. The design as shown is developed in reference to the VLAN it protects and the device type on which they are implemented.\n\nMaintain design documentation for inspection by auditors.\n\n",
"iacontrols": [
"DCPA-1",
"ECSC-1"
],
"id": "V-8323",
"ruleID": "SV-8818r1_rule",
"severity": "medium",
"title": "The necessary protection of the VVoIP system, its components, and its provided services are not supported by a comprehensive VVoIP VLAN ACL design for the supporting LAN such that VVoIP system access and traffic flow is properly controlled.",
"version": "VVoIP 5515 (LAN)"
},
"V-8328": {
"checkid": "C-23854r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nIn the event a VVoIP system is deployed/implemented within the local enclave (LAN/CAN) AND the enclave accesses or connects to external networks (for example, another LAN or a WAN), ensure the enclave\u2019s connection to the external network is designed to maintain the required enclave boundary protection for the data, VVoIP, and VTCoIP sub-enclaves (internal VLANS); maintains VLAN separation within the LAN/CAN; as well as support assured service interoperability between different vendor\u2019s VVoIP systems implemented in different enclaves. \n\nNOTE: Connection to a WAN generally means a connection to a DISN service such as the NIPRNet or SIPRNet but might also refer to the Internet. \n\nDetermine if the local enclave (LAN/CAN) connects to a WAN or if it reaches the WAN via a connection with another LAN/CAN/enclave as might be the case for a tenant of a larger BCPS (subtended enclave). If so, determine if the enclave\u2019s boundary protection is designed/implemented to protect the VVoIP endpoints and infrastructure as well as the data enclave. \n\n> The data firewall function provides protection for the VVoIP sub-enclave (VLANs) and infrastructure as follows: \n >> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC\n>> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs. \n>> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations (local or in a remote NOC). \n>> Inspects (along with the IDS) all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose.)\n\n> The VVoIP firewall function Required if VVoIP is permitted on the WAN)provides protection for the VVoIP sub-enclave and the data sub-enclave as follows: \n>> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs \n>> Inspects all VVoIP traffic destined for the VVoIP production VLANs.\n>> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication of this is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html.\n\n> In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system). \n\nNOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements. \n\nNOTE: The following is here for informational purposes and is discussed in another requirement.\n\n> In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor\u2019s VVoIP system does not directly interoperate with other vendor\u2019s VVoIP systems AND the VVoIP system is connected to the DSN, the connection is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk). \n",
"description": "VVoIP has the potential to significantly degrade the enclave boundary protection afforded by the required boundary firewall unless the firewall is designed to properly handle VVoIP traffic. The typical firewall used to protect an enclave that supports normal data traffic is not capable of properly handling or supporting real time communications (VVoIP). The following paragraphs will demonstrate this. VVoIP uses a signaling protocol and a media transfer protocol that require both inbound and outbound permissions be set for these protocols in order to provide the capability to place and receive calls to/from endpoints outside the enclave. More specifically, the signaling protocol typically uses one or more static TCP ports that must be open inbound at all times to receive calls. The media protocol; Real-time Transfer Protocol (RTP) and its companion protocol Real-time Transfer Control Protocol (RTCP) utilize randomly assigned UDP ports in the potential range of 1025-65535 with four IP ports required for every bi-directional voice session/call. The number of ports is expanded if video is added. The typical method of supporting VoIP through a standard data firewall is to open (or permit inbound) the signaling IP port(s) and a wide range of UDP ports for the RTP/RTCP media streams. While a typical data firewall can provide some protection from a VoIP implementation if the inbound permit statements are limited to specific limited address ranges (applicable in some situations), this is not possible if calls are to be permitted from any IP address on the Internet or NIPRNet that could be located anywhere in the world. Address segregation for VVoIP is generally not possible since the NIPRNet address space is disjointed (chopped up) and is spread across the overall public Internet (IPv4) address space. To support a worldwide IP enabled DSN, a typical data firewall would need to permit VVoIP signaling and media inbound from the entire registered IPv4 address space. One reason why this is the case is that an ACL developed to limit inbound enclave access to permit only NIPRNet addresses would require many permit statements such that the ACL itself could degrade firewall or router performance. As such, permitting VVoIP traffic across a standard data firewall opens gaping holes in the enclave\u2019s perimeter protection. This is of particular concern when the WAN is the Internet or a DISN service that provides connection to the INTERNET such as the NIPRNet. On the other hand, a standard data firewall poses problems for VVoIP call/session completion if external public addressing is used with internal private (RFC 1918) addressing which requires the firewall to do NAT/NAPT. This is because the VVoIP endpoints need to know the IP address of the other endpoint and they signal their address within the signaling messages. The firewall changes the IP address of the packet during the NAT but does not change it in the signaling message causing a mismatch. The effect is that the call/session cannot be completed. NOTE: If the WAN is a \u201cclosed\u201d system where the entire address space of the WAN and connected enclaves is managed by a \u201csingle system manager\u201d (as is the case with DISN classified networks) a specific limited and segregated address space can be assigned for all VVoIP devices for use across the entire network. In this case, the risk to the enclave can be limited (although not eliminated) if a standard firewall is used with inbound permit statements that are based on the segregated IP address range. This protection can be further enhanced by limiting the UDP port range. An allowance has been made for such a situation; however, this may change in the future. Based on the above, If VVoIP is to traverse the enclave boundary; the firewall must be VVoIP aware or capable. A VVoIP aware/capable firewall provides the following minimal functions. > Interprets and understands the signaling protocol to determine the UDP ports that are negotiated for the RTP/RTCP media streams. > Dynamically opens the required UDP ports to permit the flow of the media (audio and video). > Performs stateful inspection on the UDP media packets to ensure the packets are part of the active call/session, while dropping all non session packets. > Closes the UDP ports when the end of the call/session is signaled OR after a period of session inactivity. In the event NAT is used across the enclave boundary, the VVoIP aware/capable firewall provides the following NAT functions: > Interprets and understands the signaling protocol to determine the IP addresses that are negotiated between the endpoints and adjusts the signaling messages in accordance with the local NAT/NAPT internal and external addresses. > Performs the NAT/NAPT address changes on the RTP/RTCP media packets as they traverse the boundary. In the event, the VVoIP enclave boundary provides access to and interoperability with a DISN IP based assured service voice service (such as the IP-DSN on NIPRNet), VVoIP aware/capable firewall must provide the following additional functions (Note: these are defined in the UCR): > Provides encryption services for the signaling protocol (AS-SIP uses TLS) > Provides authentication of the source of the signaling protocol packets and drops all unauthenticated packets. > Provides integrity validation of the signaling protocol packets and drops all invalid or modified packets. > Terminates the AS-SIP signaling session and checks the validity of the AS-SIP messages based on content and establishes a new signaling session for the next hop, thus performing an application level inspection of the signaling messages. > Communicates with Call controllers (LSCs and MFSSs) using AS-SIP/TLS > Interprets and understands the AS-SIP signaling protocol to provide the minimal and NAT functions noted above > Supports encrypted RTP/RTSP media streams. That is SRTP/SRTCP > Provides the capability to decrypt the media streams for inspection and recording. This supports monitoring/recording for CALEA and COMSEC monitoring purposes for calls that traverse the enclave boundary. > Performs intrusion and DoS detection with alarm capability for both the signaling and media. > Blocks all non VVoIP traffic whether destined for the VVoIP or data sub-enclaves. NOTE: While RTCP messages could be validated for content and format, the contents of RTP packets cannot due to the random nature of the audio and video data being transmitted. Delaying the RTCP packets for inspection or the SRTCP messages for decryption and inspection while passing the RTP/SRTP packets would cause disruption in the media flow and thereby negatively affect its quality. Additionally, the delay of the SRTP packets for decryption and inspection would have similar effects. Thus intrusion detection based on the media streams is almost impossible since attack profiles are generally unavailable. Based on this and to improve worldwide voice quality, the DSN/RTS PMO and the RTS WG has determined that the SRTP/SRTCP streams will be passed by the VVoIP firewall without inspecting the encrypted contents of the packets. NOTE: The VVoIP aware/capable firewall discussed here defines a set of functions that are unique to a VVoIP which are different from the set of functions required for data firewalls. The functions for data firewalls are defined in the Network Infrastructure STIG. While typically a single firewall will not be capable of supporting both sets of functions (which means a separate VVoIP firewall is needed in parallel to the data firewall) this requirement does not mean that a dedicated VVoIP firewall must be implemented in the event a single firewall is capable of implementing both sets of functions simultaneously. The primary task of the data firewall function is to protect the entire enclave. In doing so, it must perform its normal function of protecting the data sub-enclave while also blocking all VVoIP traffic destined for it via the data firewall. An exception could be made for this on a case by case basis if permissions are limited in scope as would be the case for VTC. All data traffic/protocols destined for the VVoIP sub-enclave must also be blocked unless specifically authorized to meet a mission need. Such a mission need might be for remote management of the VVoIP system from a NOC or user-to-site VPN, however, this traffic must would be routed to the VVoIP management VLAN(s) and not the VVoIP production VLANs. An additional consideration for passing VoIP across an enclave boundary is when there are different vendor\u2019s VoIP systems deployed within the different enclaves connected to the WAN, and the various vendor\u2019s systems are not interoperable or do not provide assured service outside the enclave, or the WAN cannot support QoS and assured service. In this case, interoperability and assured service must be preserved across the DSN or DISN voice network, whether traditional TDM or VoIP. Therefore, the VoIP system must connect to other enclaves via a traditional TDM based long haul network. Such a connection is made using a media gateway. Therefore, if the enclave VoIP system is not compatible with the IP enabled DSN as defined in the UCR thereby providing interoperability and assured service end-to-end across the DISN voice network, the system must employ a media gateway and connect to a traditional DSN switch. Additionally, unless specific requirements (discussed later) are met, all connections to the PSTN must be via a media gateway and an appropriate trunk (PRI or CAS). ",
"fixid": "F-20286r1_fix",
"fixtext": "In the event a VVoIP/UC system is deployed/implemented within the enclave AND the enclave accesses external networks, ensure the enclave\u2019s connection to external networks is designed to maintain the required enclave boundary protection for both the data and voice/video sub-enclaves as well as separation within the LAN and to support interoperability between different vendor\u2019s VVoIP/UC systems implemented in different enclaves. \n\nDesign and implement the boundary protection to provide for the following: \n\n> The data firewall function provides protection for the VVoIP sub-enclave and infrastructure as follows: \n>> Blocks all VVoIP traffic to/from the VVoIP production VLANs (This is in favor of this traffic traversing a media gateway or VVoIP firewall function) except for signaling, media, registration protocols, UC protocols, etc., to/from a remote endpoint entering the enclave via a properly authenticated and encrypted tunnel. In this case, such traffic is blocked from the data VLAN(s) and routed to the VVoIP VLANs unless there is a VVoIP firewall (EBC) in which case session traffic must be routed through the EBC\n>> Blocks all NON-VVoIP traffic to/from the VVoIP production VLANs. \n>> Blocks all NON-VVoIP traffic to/from the VVoIP management VLANs except that which is specifically required for management of the VVoIP system to/from specifically authorized management servers and workstations. \n>> Inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose).\n\nThe network IDS inspects all NON-VVoIP traffic to/from the VVoIP management VLANs that is specifically required for management of the VVoIP system. (Except if there is an alternate data perimeter implemented for this purpose). \n\n> The VVoIP firewall function provides protection for the VVoIP sub-enclave and the data sub-enclave as follows: \n>> Blocks all NON-VVoIP traffic to/from data production VLANs as well as the data and VVoIP system management VLANs. \n>> Inspects all VVoIP destined for the VVoIP production VLANs.\n>> Supports the interoperability and assured service requirements per the DoD UCR (as noted in the discussion) of the DISN IP enabled voice service on the WAN to which the VVoIP system is connected. NOTE: A good indication is whether or not the VVoIP firewall is listed on the DoD UC APL found at http://jitc.fhu.disa.mil/apl/index.html.\n\n> In the event the VVoIP firewall function does not exist or does not meet the requirements above, OR the locally implemented vendor\u2019s VVoIP system does not directly interoperate with other vendor\u2019s VVoIP systems AND the VVoIP system is connected to the DSN; the connection to the DSN is via a media gateway and an appropriate trunk that supports DSN assured service (a T619A trunk) NOTE: this is covered under another requirement.\n\n> In the event the VVoIP system is connected to the PSTN; the connection is via a media gateway and a BRI/PRI or CAS trunk (or, for small sites, DS-0s or there is an alternate phone system). \n\nNOTE: A PSTN media gateway connection may not be required if the site is approved for a commercial VoIP service connection. Concerns for this possibility will be addressed in subsequent requirements. \n\nIn the event the enclave is part of a \u201cclosed\u201d DISN classified network or an organizational intranet AND the PMO for the \u201cclosed\u201d DISN classified network or an organizational intranet has designated a segregated IP address range for use by VVoIP systems, AND There is no dedicated VVoIP firewall function (as defined by the UCR) implemented, configure the system for the following:\n>> Utilizes the PMO designated VVoIP address space for the VVoIP system within the enclave.\n>> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on the PMO designated VVoIP address space.\n>> Configure the enclave perimeter data firewall to limit permitted VVoIP traffic and protocols based on a limited range of UDP ports as needed for the particular vendor\u2019s system implemented.\n\nNOTE: in the event the enclave is part of an organizational intranet, and there is no firewall at the local enclave perimeter, configure the perimeter/premise router to provide the required filtering and routing along with ensuring all inbound and outbound traffic enters the required dedicated circuit or encrypted VPN. Specific network requirements for organizational intranet design and implementation is beyond the scope of this document.\n",
"iacontrols": [
"EBBD-1",
"EBBD-2",
"EBBD-3",
"ECSC-1"
],
"id": "V-8328",
"ruleID": "SV-8823r1_rule",
"severity": "high",
"title": "The implementation of a VVoIP system in the local enclave and its connection to external networks degrades the enclave\u2019s perimeter protection due to an inadequate design of the VVoIP boundary with those external networks.",
"version": "VVoIP 1005 (GENERAL) "
},
"V-8329": {
"checkid": "C-23858r1_chk",
"checktext": "Interview the IAO to confirm compliance with the following requirement: \n\nEnsure all local DSN access for intra DoD dialup services (voice, video, fax, data) to/from a VVoIP system within a site enclave and a DSN number is via a local Media Gateway (MG) and one or more T619A trunks for C2 enclaves (MLPP support) or one or more PRI or CAS trunks for NON-C2 enclaves with a IP-PBX-2 (NO MLPP support) to a DSN EO or MFS except as follows:\n\u2022 The VVoIP system within a site enclave is approved for DISN NIPRNet IP Voice Services (VS) (IP enabled DSN VoIP on NIPRNet).\n\u2022 The VVoIP system within a site enclave is subtended to a larger enclave and tethered (connected) to it via a direct cable, or a dedicated TDM or optical circuit (e.g., a T1, DS2, OCx ). (This connection would be typical of a GSU located in relative close proximity to its MOB. This would be similar to a MAN).\n\u2022 The enclave is part of an organizational Intranet whose enclaves (MOBs and GSUs and regional service/computing centers or server farms) are interconnected across the DISN using dedicated TDM or optical circuits or encrypted VPN tunnels, whether site-to-site or meshed. \n\nNOTE: organizational Intranets using encrypted site-to-site or meshed VPN tunnels across a DISN IP routed network must block local access to/from the DISN IP routed network (e.g., NIPRNet) at the VPN termination points unless a full boundary protection suite of equipment is implemented locally. \n\nNOTE: This does not apply to approved remote VoIP instruments or Soft Phones that connect to the VVoIP system enclave via an encrypted VPN and are therefore part of the enclave\u2019s LAN.\n\nNOTE: TDM or optical circuits should be bulk encrypted if using a commercial provider to supply any portion of the complete circuit. This will most likely be the case for the \u201clast mile\u201d connection to a DISN SDN since DoD owned facilities do not touch most sites. \n\nDetermine if the VVoIP system within the site enclave is connected to a DSN EO or MFS via a local (on site) Media Gateway (MG) and one or more T619A trunks for C2 enclaves (provides MLPP support) or one or more PRI or CAS trunks for NON-C2 enclaves with a IP-PBX-2 (NO MLPP support).\n\nAdditionally, determine if the following exceptions apply:\n\u2022 Is the VVoIP system within the site enclave approved for DISN NIPRNet IP Voice Services (VS) (IP enabled DSN VoIP on NIPRNet)? \n\u2022 Is the VVoIP system within the site enclave subtended to a larger enclave and tethered (connected) to it via a direct cable, or a dedicated TDM or optical circuit (e.g., a T1, DS2, OCx )? (This connection is typical of a GSU located in relative close proximity to its MOB. This would be similar to a MAN.)\n\u2022 Is the enclave part of an organizational Intranet whose enclaves (MOBs and GSUs and regional service centers or server farms) are interconnected across the DISN using dedicated TDM or optical circuits or encrypted VPN tunnels, whether site-to-site or meshed? \n\nThis is a finding in the event the site is not connected to the DSN via a MG located at the local site enclave as described above AND one of the exceptions is not applicable. \n\nNOTE: This requirement dictates that each site\u2019s VoIP enclave has a local (on site) MG for connecting the site locally to a DSN EO or MFS. The DSN EO or MFS may be located at a remote site, in which case the TDM trunks will carry the voice traffic between the sites. This arrangement means that VoIP traffic does not have to traverse the enclave boundary with the WAN which is one of the reasons for the requirement.\n",
"description": "There are several reasons why voice traffic to/from the DSN must use a locally implemented Media Gateway (MG) connected to a DSN EO or MFSS via the appropriate type of trunk based on the site\u2019s need to support C2 communications via the DSN if exceptions do not apply. These reasons are as follows: \n> VVoIP has the potential to significantly degrade the standard data enclave boundary protection afforded by the required data enclave firewall unless the firewall is designed to properly handle VVoIP traffic. Based on this degradation, VVoIP must not traverse a standard data firewall except under certain circumstances. \n> VVoIP aware/capable firewalls are being developed and few are deployed. \n> DoD must purchase and use VVoIP/UC devices and firewalls that meet UC requirements as defined in the UCR. \n> Confidentiality and integrity: Legacy (early) VoIP systems could not encrypt VoIP signaling or media to protect it for confidentiality and from various attacks while traversing a publicly accessible WAN (e.g., NIPRNet or Internet). This is changing due to the DoD\u2019s efforts to develop interoperable VVoIP encryption standards with vendor assistance. The use of a MG eliminates the need for encryption on an IP WAN by placing the voice traffic on a traditional TDM network where the communications are more secure in general even though they are not encrypted. Physical access to the wire or TDM switch is required to compromise TDM communication whereas compromise could be effected from anywhere on an IP network. \n> Availability and C2 support between sites via interoperability: VoIP systems from different vendors are typically not directly interoperable via IP. This is primarily due to the lack of fully defined standards leaving vendors to develop their own extensions to the available protocols in support of unique feature sets. This is changing due to the DoD\u2019s efforts to develop interoperable usage of the standards with vendor assistance. The use of a MG converts each vendor\u2019s implementation to a common interoperable system, the TDM DSN. \n",
"fixid": "F-20287r1_fix",
"fixtext": "Unless one of the following exceptions apply: \n\u2022 The VVoIP system within a site enclave is approved for DISN NIPRNet IP Voice Services (VS) (IP enabled DSN VoIP on NIPRNet).\n\u2022 The VVoIP system within a site enclave is subtended to a larger enclave and tethered (connected) to it via a direct cable, or a dedicated TDM or optical circuit (e.g., a T1, DS2, OCx ). (This connection would be typical of a GSU located in relative close proximity to its MOB. This would be similar to a MAN.)\n\u2022 The enclave is part of an organizational Intranet whose enclaves (MOBs and GSUs and regional service/computing centers or server farms) are interconnected across the DISN using dedicated TDM or optical circuits or encrypted VPN tunnels, whether site-to-site or meshed. \n\nEnsure all DSN access for intra DoD dialup services (voice, video, fax, data) to/from a VVoIP system within a site enclave and a DSN number is via a local (on site) Media Gateway (MG) and one or more T619A trunks for C2 enclaves (MLPP support) or one or more PRI or CAS trunks for NON-C2 enclaves with a IP-PBX-2 (NO MLPP support) to a DSN EO or MFS:\n\nNOTE: This does not apply to approved remote VoIP instruments or Soft Phones that connect to the VVoIP system enclave via an encrypted VPN and are therefore part of the enclave\u2019s LAN.\n\nNOTE: TDM or optical circuits should be bulk encrypted if using a commercial provider to supply any portion of the complete circuit. This will most likely be the case for the \u201clast mile\u201d connection to a DISN SDN since DoD owned facilities do not touch most sites. \n\nNOTE: organizational Intranets using encrypted site-to-site or meshed VPN tunnels across a DISN IP routed network must block local access to/from the DISN IP routed network (e.g., NIPRNet) at the VPN termination points unless a full boundary protection suite of equipment is implemented locally.\n",
"iacontrols": [
"EBBD-1",
"EBBD-2",
"EBBD-3",
"ECSC-1"
],
"id": "V-8329",
"ruleID": "SV-8824r1_rule",
"severity": "medium",
"title": "Without an applicable exception the site\u2019s enclave boundary protection is not designed or implemented to route all voice traffic to/from a DSN number via a locally implemented Media Gateway (MG) connected to a DSN EO or MFSS using the appropriate type of trunk based on the site\u2019s need to support C2 communications via the DSN.",
"version": "VVoIP 1010 (GENERAL)"
},
"V-8349": {
"checkid": "C-23623r1_chk",
"checktext": "Interview the IAO and review site documentation to confirm compliance with the following requirement: Ensure that software patches for critical, VVoIP servers and other related devices originate from or are approved by the system vendor/manufacturer and are applied in accordance with their instructions. Third party OEM upgrades/patches from general-purpose OS and application vendors or the OSS community are not to be applied without the system vendor\u2019s approval and assurance that such application will not impact the system negatively. \n\nNOTE: This includes patches or mitigations required by IAVAs. IAVA vulnerabilities must be referred to the system vendor to determine applicability and a mitigation path.\n",
"description": "VVoIP systems and particularly voice telecommunications systems (that is to say phone systems) are considered critical infrastructure for communications, security, and life safety. As such they are considered mission critical and we have become accustomed to their high reliability and availability which is generally on the order of 5 nines. \n\nMany VVoIP systems are based on general-purpose operating systems such as Windows, Unix, LINUX as well as database and web server applications such as MS-SQL, Oracle, IIS, Tomcat, and others. Additionally, vendors of these systems usually customize or only use portions of the general-purpose operating systems and applications. Vendors also use and potentially customize open source software (OSS).\n\nVulnerabilities are discovered every day in these general-purpose operating systems and applications by the community their original vendors. The vendors of these general-purpose systems and applications (such as Microsoft and others) routinely provide patches for their products to address bugs and vulnerabilities while other vendors and the OSS community provide upgraded versions of the software. These vulnerabilities and their mitigations usually appear in the DOD\u2019s Information Assurance Vulnerability Management (IAVM) process as Information Assurance Vulnerability Alerts (IAVAs). The process mandates that these IAVAs be addressed in a specific time frame based on the severity of the issue. Many times the mandated \u201cfix\u201d is to apply the original vendors patch or to upgrade to the \u201cfixed\u201d version of the software that has the vulnerability.\n\nDue to the mission critical nature of our voice telecommunications systems, owners and operators must be cautioned against applying patches to their systems that are provided by the original vendor of the general-purpose operating systems and applications used in their systems as these may severely and adversely affect the operability of a portion of the system or may cause the system to crash. Significant down time could result which would amount to a self imposed denial of service.\n\nTo prevent operability issues and downtime to the greatest extent possible, the VVoIP system vendor must first determine if the OEM vulnerability and mitigating patch is applicable to their system or a portion thereof, and then test the mitigation/patch to validate that it will not degrade the system or its security. The IPT / VoIP vendor may have to modify the OEM patch or produce their own patch before releasing it to their customers. Obtaining a vendor tested and vendor approved patch from the system vendor provides the greatest assurance that responding to an IAVA will not involve a negative impact on the system.\n\nTo aid in this process, VVoIP system vendor must be advised of IAVAs that may apply to their systems. This is best accomplished by asking the vendor if the CVE or OEM patch number noted in the IAVA applies to your system and version of code. If so, they probably already have a tested and approved patch available for their customers. If not they will be alerted to the fact they need to provide one or test and approve the application of the OEM mitigation.\n",
"fixid": "F-20138r1_fix",
"fixtext": "Ensure that software patches for critical, VVoIP servers and other related devices originate from or are approved by the system vendor/manufacturer and are applied in accordance with their instructions. Third party OEM upgrades/patches from general-purpose OS and application vendors or the OSS community are not to be applied without the system vendor\u2019s approval and assurance that such application will not impact the system negatively. Note: This includes patches or mitigations required by IAVAs. IAVA vulnerabilities must be referred to the system vendor to determine applicability and a mitigation path.\n\nOnly Apply vendor-approved or vendor supplied patches. Correct site policy to require only vendor provided and approved patches are applied.\n",
"iacontrols": [
"ECSC-1"
],
"id": "V-8349",
"ruleID": "SV-8844r1_rule",
"severity": "medium",
"title": "Software patches for critical VoIP servers and other IPT devices DO NOT originate from the system manufacturer and are NOT applied in accordance with manufacturer\u2019s instructions.",
"version": "VVoIP 1200 (GENERAL)"
}
},
"profiles": {
"MAC-1_Classified": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-1_Classified",
"title": "I - Mission Critial Classified"
},
"MAC-1_Public": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-1_Public",
"title": "I - Mission Critial Public"
},
"MAC-1_Sensitive": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-1_Sensitive",
"title": "I - Mission Critial Sensitive"
},
"MAC-2_Classified": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-2_Classified",
"title": "II - Mission Support Classified"
},
"MAC-2_Public": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-2_Public",
"title": "II - Mission Support Public"
},
"MAC-2_Sensitive": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-2_Sensitive",
"title": "II - Mission Support Sensitive"
},
"MAC-3_Classified": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-3_Classified",
"title": "III - Administrative Classified"
},
"MAC-3_Public": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-3_Public",
"title": "III - Administrative Public"
},
"MAC-3_Sensitive": {
"description": "",
"findings": {
"V-16070": "true",
"V-16073": "true",
"V-16074": "true",
"V-16076": "true",
"V-16077": "true",
"V-16078": "true",
"V-16081": "true",
"V-16082": "true",
"V-16085": "true",
"V-16086": "true",
"V-16087": "true",
"V-16088": "true",
"V-16089": "true",
"V-16090": "true",
"V-16091": "true",
"V-16094": "true",
"V-16095": "true",
"V-16096": "true",
"V-16098": "true",
"V-16099": "true",
"V-16101": "true",
"V-16106": "true",
"V-16107": "true",
"V-16108": "true",
"V-16109": "true",
"V-16111": "true",
"V-16112": "true",
"V-16113": "true",
"V-16114": "true",
"V-16115": "true",
"V-16116": "true",
"V-16117": "true",
"V-16118": "true",
"V-16119": "true",
"V-19440": "true",
"V-19441": "true",
"V-19442": "true",
"V-19443": "true",
"V-19482": "true",
"V-19493": "true",
"V-19500": "true",
"V-19514": "true",
"V-19521": "true",
"V-19535": "true",
"V-19545": "true",
"V-19547": "true",
"V-19562": "true",
"V-19565": "true",
"V-19592": "true",
"V-19593": "true",
"V-19594": "true",
"V-19595": "true",
"V-19596": "true",
"V-19597": "true",
"V-19598": "true",
"V-19599": "true",
"V-19600": "true",
"V-19601": "true",
"V-19602": "true",
"V-19603": "true",
"V-19604": "true",
"V-21506": "true",
"V-21507": "true",
"V-21508": "true",
"V-21521": "true",
"V-21522": "true",
"V-21523": "true",
"V-47735": "true",
"V-47753": "true",
"V-8223": "true",
"V-8224": "true",
"V-8225": "true",
"V-8227": "true",
"V-8228": "true",
"V-8230": "true",
"V-8247": "true",
"V-8248": "true",
"V-8250": "true",
"V-8253": "true",
"V-8254": "true",
"V-8255": "true",
"V-8256": "true",
"V-8257": "true",
"V-8288": "true",
"V-8290": "true",
"V-8294": "true",
"V-8295": "true",
"V-8302": "true",
"V-8306": "true",
"V-8323": "true",
"V-8328": "true",
"V-8329": "true",
"V-8349": "true"
},
"id": "MAC-3_Sensitive",
"title": "III - Administrative Sensitive"
}
},
"slug": "voicevideo_services_policy",
"title": "Voice/Video Services Policy STIG",
"version": "3"
}
}