kriterion 0.0.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +2 -0
- data/.ruby-version +1 -0
- data/.travis.yml +5 -0
- data/Dockerfile +18 -0
- data/Gemfile +12 -0
- data/Gemfile.lock +62 -0
- data/LICENSE.txt +21 -0
- data/README.md +58 -0
- data/Rakefile +6 -0
- data/bin/setup +8 -0
- data/bin/update_stigs.rb +42 -0
- data/criterion.gemspec +31 -0
- data/docker-compose.yml +14 -0
- data/exe/kriterion +16 -0
- data/lib/kriterion.rb +16 -0
- data/lib/kriterion/api.rb +27 -0
- data/lib/kriterion/backend.rb +13 -0
- data/lib/kriterion/backend/mongodb.rb +235 -0
- data/lib/kriterion/cli.rb +28 -0
- data/lib/kriterion/cli/api.rb +35 -0
- data/lib/kriterion/cli/worker.rb +35 -0
- data/lib/kriterion/event.rb +36 -0
- data/lib/kriterion/item.rb +42 -0
- data/lib/kriterion/logs.rb +14 -0
- data/lib/kriterion/metrics.rb +22 -0
- data/lib/kriterion/object.rb +50 -0
- data/lib/kriterion/report.rb +69 -0
- data/lib/kriterion/resource.rb +60 -0
- data/lib/kriterion/section.rb +32 -0
- data/lib/kriterion/standard.rb +65 -0
- data/lib/kriterion/version.rb +3 -0
- data/lib/kriterion/worker.rb +280 -0
- data/standards/cis_red_hat_enterprise_linux_7.json +34 -0
- data/standards/stig_a10_networks_adc_alg.json +209 -0
- data/standards/stig_a10_networks_adc_ndm.json +233 -0
- data/standards/stig_active_directory_domain.json +257 -0
- data/standards/stig_active_directory_forest.json +41 -0
- data/standards/stig_active_directory_service_2003.json +173 -0
- data/standards/stig_active_directory_service_2008.json +167 -0
- data/standards/stig_adobe_acrobat_pro_xi.json +167 -0
- data/standards/stig_adobe_acrobat_reader_dc_classic_track.json +179 -0
- data/standards/stig_adobe_acrobat_reader_dc_continuous_track.json +179 -0
- data/standards/stig_adobe_coldfusion_11.json +611 -0
- data/standards/stig_airwatch_mdm.json +185 -0
- data/standards/stig_aix_5.3.json +3095 -0
- data/standards/stig_aix_6.1.json +3047 -0
- data/standards/stig_akamai_ksd_service_impact_level_2_alg.json +209 -0
- data/standards/stig_akamai_ksd_service_impact_level_2_ndm.json +155 -0
- data/standards/stig_android_2.2_dell.json +311 -0
- data/standards/stig_apache_2.2_serverwindows.json +347 -0
- data/standards/stig_apache_2.2_sitewindows_security_implementation_guide.json +179 -0
- data/standards/stig_apache_server_2.0unix.json +341 -0
- data/standards/stig_apache_server_2.0windows.json +341 -0
- data/standards/stig_apache_server_2.2unix.json +347 -0
- data/standards/stig_apache_server_2.2windows.json +347 -0
- data/standards/stig_apache_site_2.0unix.json +185 -0
- data/standards/stig_apache_site_2.0windows.json +179 -0
- data/standards/stig_apache_site_2.2unix.json +185 -0
- data/standards/stig_apache_site_2.2windows.json +179 -0
- data/standards/stig_apple_ios6.json +341 -0
- data/standards/stig_apple_ios_10.json +245 -0
- data/standards/stig_apple_ios_11.json +269 -0
- data/standards/stig_apple_ios_4_good_mobility_suite_interim_security_configuration_guide_iscg.json +257 -0
- data/standards/stig_apple_ios_5.json +329 -0
- data/standards/stig_apple_ios_6.json +335 -0
- data/standards/stig_apple_ios_6_interim_security_configuration_guide_iscg.json +371 -0
- data/standards/stig_apple_ios_7.json +185 -0
- data/standards/stig_apple_ios_8_interim_security_configuration_guide.json +251 -0
- data/standards/stig_apple_ios_9_interim_security_configuration_guide.json +245 -0
- data/standards/stig_apple_os_x_10.10_yosemite_workstation.json +851 -0
- data/standards/stig_apple_os_x_10.11.json +725 -0
- data/standards/stig_apple_os_x_10.12.json +737 -0
- data/standards/stig_apple_os_x_10.8_mountain_lion_workstation.json +1241 -0
- data/standards/stig_apple_os_x_10.9_mavericks_workstation.json +809 -0
- data/standards/stig_application_layer_gateway_alg_security_requirements_guide_srg.json +911 -0
- data/standards/stig_application_layer_gateway_security_requirements_guide.json +911 -0
- data/standards/stig_application_security_and_development.json +1745 -0
- data/standards/stig_application_security_and_development_checklist.json +959 -0
- data/standards/stig_application_security_requirements_guide.json +1961 -0
- data/standards/stig_application_server_security_requirements_guide.json +791 -0
- data/standards/stig_arcgisserver_10.3.json +143 -0
- data/standards/stig_arista_mls_dcs-7000_series_l2s.json +53 -0
- data/standards/stig_arista_mls_dcs-7000_series_ndm.json +197 -0
- data/standards/stig_arista_mls_dcs-7000_series_rtr.json +143 -0
- data/standards/stig_bind_9.x.json +431 -0
- data/standards/stig_bind_dns.json +317 -0
- data/standards/stig_blackberry_10.2.x_os.json +179 -0
- data/standards/stig_blackberry_10_os.json +227 -0
- data/standards/stig_blackberry_bes_12.3.x_mdm.json +65 -0
- data/standards/stig_blackberry_bes_12.5.x_mdm.json +65 -0
- data/standards/stig_blackberry_device_service_6.2.json +425 -0
- data/standards/stig_blackberry_enterprise_mobility_server_2.x.json +149 -0
- data/standards/stig_blackberry_enterprise_server,_part_1.json +35 -0
- data/standards/stig_blackberry_enterprise_server,_part_2.json +155 -0
- data/standards/stig_blackberry_enterprise_server,_part_3.json +647 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_1.json +35 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_2.json +155 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_3.json +653 -0
- data/standards/stig_blackberry_enterprise_service_v10.1.x_blackberry_device_service.json +317 -0
- data/standards/stig_blackberry_enterprise_service_v10.2.x_blackberry_device_service.json +263 -0
- data/standards/stig_blackberry_handheld_device.json +125 -0
- data/standards/stig_blackberry_os_10.3.x.json +257 -0
- data/standards/stig_blackberry_os_7.x.json +107 -0
- data/standards/stig_blackberry_os_7.x.x.json +101 -0
- data/standards/stig_blackberry_os_version_5-7.json +107 -0
- data/standards/stig_blackberry_playbook.json +65 -0
- data/standards/stig_blackberry_playbook_os_nea_mode.json +65 -0
- data/standards/stig_blackberry_playbook_os_v2.1.json +197 -0
- data/standards/stig_blackberry_uem_12.7.json +59 -0
- data/standards/stig_bluetoothzigbee.json +35 -0
- data/standards/stig_ca_api_gateway_alg.json +497 -0
- data/standards/stig_cisco_css_dns.json +71 -0
- data/standards/stig_cisco_ios_xe_release_3_ndm.json +395 -0
- data/standards/stig_cisco_ios_xe_release_3_rtr.json +149 -0
- data/standards/stig_cmd_management_server_policy.json +53 -0
- data/standards/stig_commercial_mobile_device_cmd_policy.json +83 -0
- data/standards/stig_csfc_campus_wlan_policy_security_implementation_guide.json +95 -0
- data/standards/stig_database_security_requirements_guide.json +767 -0
- data/standards/stig_dbn-6300_idps.json +107 -0
- data/standards/stig_dbn-6300_ndm.json +359 -0
- data/standards/stig_defense_switched_network.json +683 -0
- data/standards/stig_defense_switched_network_dsn.json +653 -0
- data/standards/stig_desktop_applications_general.json +41 -0
- data/standards/stig_dns_policy.json +155 -0
- data/standards/stig_domain_name_system_dns_security_requirements_guide.json +599 -0
- data/standards/stig_draft_aix.json +3503 -0
- data/standards/stig_edb_postgres_advanced_server.json +665 -0
- data/standards/stig_email_services_policy.json +137 -0
- data/standards/stig_exchange_2010_client_access_server.json +179 -0
- data/standards/stig_exchange_2010_edge_transport_server.json +389 -0
- data/standards/stig_exchange_2010_hub_transport_server.json +269 -0
- data/standards/stig_exchange_2010_mailbox_server.json +209 -0
- data/standards/stig_f5_big-ip_access_policy_manager_11.x.json +149 -0
- data/standards/stig_f5_big-ip_advanced_firewall_manager_11.x.json +41 -0
- data/standards/stig_f5_big-ip_application_security_manager_11.x.json +89 -0
- data/standards/stig_f5_big-ip_device_management_11.x.json +467 -0
- data/standards/stig_f5_big-ip_local_traffic_manager_11.x.json +407 -0
- data/standards/stig_final_draft_general_wireless_policy.json +71 -0
- data/standards/stig_firewall.json +449 -0
- data/standards/stig_firewall_-_cisco.json +449 -0
- data/standards/stig_firewall_security_requirements_guide.json +257 -0
- data/standards/stig_forescout_counteract_alg.json +83 -0
- data/standards/stig_forescout_counteract_ndm.json +239 -0
- data/standards/stig_free_space_optics_device.json +143 -0
- data/standards/stig_general_mobile_device_policy_non-enterprise_activated.json +113 -0
- data/standards/stig_general_mobile_device_technical_non-enterprise_activated.json +59 -0
- data/standards/stig_general_purpose_operating_system_srg.json +1199 -0
- data/standards/stig_general_wireless_policy.json +71 -0
- data/standards/stig_good_mobility_suite_server_android_os.json +203 -0
- data/standards/stig_good_mobility_suite_server_apple_ios_4_interim_security_configuration_guide_iscg.json +209 -0
- data/standards/stig_good_mobility_suite_server_windows_phone_6.5.json +449 -0
- data/standards/stig_goodenterprise_8.x.json +401 -0
- data/standards/stig_google_chrome_browser.json +209 -0
- data/standards/stig_google_chrome_current_windows.json +215 -0
- data/standards/stig_google_chrome_draft.json +281 -0
- data/standards/stig_google_chrome_v23_windows.json +275 -0
- data/standards/stig_google_chrome_v24_windows.json +263 -0
- data/standards/stig_google_chrome_v24_windows_benchmark.json +227 -0
- data/standards/stig_google_search_appliance.json +209 -0
- data/standards/stig_harris_secnet_11_54.json +89 -0
- data/standards/stig_hp-ux_11.23.json +3215 -0
- data/standards/stig_hp-ux_11.31.json +3155 -0
- data/standards/stig_hp-ux_smse.json +431 -0
- data/standards/stig_hpe_3par_storeserv_3.2.x.json +131 -0
- data/standards/stig_ibm_datapower_alg.json +401 -0
- data/standards/stig_ibm_datapower_network_device_management.json +395 -0
- data/standards/stig_ibm_db2_v10.5_luw.json +575 -0
- data/standards/stig_ibm_hardware_management_console_hmc.json +221 -0
- data/standards/stig_ibm_hardware_management_console_hmc_policies.json +35 -0
- data/standards/stig_ibm_maas360_v2.3.x_mdm.json +59 -0
- data/standards/stig_ibm_zvm_using_ca_vm:secure.json +473 -0
- data/standards/stig_idps_security_requirements_guide_srg.json +1865 -0
- data/standards/stig_idsips.json +257 -0
- data/standards/stig_iis6_server.json +221 -0
- data/standards/stig_iis6_site.json +263 -0
- data/standards/stig_iis_7.0_web_server.json +155 -0
- data/standards/stig_iis_7.0_web_site.json +299 -0
- data/standards/stig_iis_8.5_server.json +293 -0
- data/standards/stig_iis_8.5_site.json +347 -0
- data/standards/stig_infoblox_7.x_dns.json +419 -0
- data/standards/stig_infrastructure_l3_switch.json +599 -0
- data/standards/stig_infrastructure_l3_switch_-_cisco.json +659 -0
- data/standards/stig_infrastructure_l3_switch_secure_technical_implementation_guide_-_cisco.json +659 -0
- data/standards/stig_infrastructure_router.json +479 -0
- data/standards/stig_infrastructure_router_-_cisco.json +539 -0
- data/standards/stig_infrastructure_router_-_juniper.json +485 -0
- data/standards/stig_infrastructure_router__cisco.json +539 -0
- data/standards/stig_infrastructure_router__juniper.json +485 -0
- data/standards/stig_internet_explorer_8.json +821 -0
- data/standards/stig_internet_explorer_9.json +815 -0
- data/standards/stig_intrusion_detection_and_prevention_systems_idps_security_requirements_guide.json +371 -0
- data/standards/stig_ipsec_vpn_gateway.json +521 -0
- data/standards/stig_java_runtime_environment_jre_6_unix.json +65 -0
- data/standards/stig_java_runtime_environment_jre_6_win7.json +65 -0
- data/standards/stig_java_runtime_environment_jre_6_windows_xp.json +77 -0
- data/standards/stig_java_runtime_environment_jre_6_winxp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_unix.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_win7.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_winxp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_version_6_unix.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_6_windows_7.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_6_windows_xp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_version_7_unix.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_7_windows_7.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_7_winxp.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_8_unix.json +107 -0
- data/standards/stig_java_runtime_environment_jre_version_8_windows.json +107 -0
- data/standards/stig_jboss_eap_6.3.json +413 -0
- data/standards/stig_juniper_srx_sg_alg.json +155 -0
- data/standards/stig_juniper_srx_sg_idps.json +179 -0
- data/standards/stig_juniper_srx_sg_ndm.json +443 -0
- data/standards/stig_juniper_srx_sg_vpn.json +185 -0
- data/standards/stig_keyboard_video_and_mouse_switch.json +269 -0
- data/standards/stig_l3_kov-26_talon_wireless_role.json +77 -0
- data/standards/stig_layer_2_switch.json +347 -0
- data/standards/stig_layer_2_switch_-_cisco.json +365 -0
- data/standards/stig_lg_android_5.x_interim_security_configuration_guide.json +245 -0
- data/standards/stig_lg_android_6.x.json +281 -0
- data/standards/stig_mac_osx_10.6_workstation.json +1319 -0
- data/standards/stig_mac_osx_10.6_workstation_draft.json +1319 -0
- data/standards/stig_mainframe_product_security_requirements_guide.json +1115 -0
- data/standards/stig_mcafee_application_control_7.x.json +203 -0
- data/standards/stig_mcafee_move_2.63.6.1_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_2.63.6.1_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_2.6_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_2.6_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_3.6.1_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_3.6.1_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_agentless_3.03.6.1_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_agentless_3.0_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_agentless_3.0_vsel_1.9sva.json +203 -0
- data/standards/stig_mcafee_move_agentless_3.6.1_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_av_agentless_4.5.json +155 -0
- data/standards/stig_mcafee_move_av_multi-platform_4.5.json +215 -0
- data/standards/stig_mcafee_virusscan_8.8_local_client.json +533 -0
- data/standards/stig_mcafee_virusscan_8.8_managed_client.json +533 -0
- data/standards/stig_mcafee_vsel_1.92.0_local_client.json +245 -0
- data/standards/stig_mcafee_vsel_1.92.0_managed_client.json +239 -0
- data/standards/stig_mdm_server_policy.json +47 -0
- data/standards/stig_microsoft_access_2003.json +47 -0
- data/standards/stig_microsoft_access_2007.json +77 -0
- data/standards/stig_microsoft_access_2010.json +119 -0
- data/standards/stig_microsoft_access_2013.json +113 -0
- data/standards/stig_microsoft_access_2016.json +107 -0
- data/standards/stig_microsoft_dot_net_framework_4.0.json +101 -0
- data/standards/stig_microsoft_excel_2003.json +47 -0
- data/standards/stig_microsoft_excel_2007.json +155 -0
- data/standards/stig_microsoft_excel_2010.json +287 -0
- data/standards/stig_microsoft_excel_2013.json +293 -0
- data/standards/stig_microsoft_excel_2016.json +257 -0
- data/standards/stig_microsoft_exchange_2010_client_access_server_role.json +71 -0
- data/standards/stig_microsoft_exchange_2010_core_server.json +47 -0
- data/standards/stig_microsoft_exchange_2010_edge_transport_server_role.json +233 -0
- data/standards/stig_microsoft_exchange_2010_hub_transport_server_role.json +125 -0
- data/standards/stig_microsoft_exchange_2010_mailbox_server_role.json +107 -0
- data/standards/stig_microsoft_exchange_server_2003.json +647 -0
- data/standards/stig_microsoft_groove_2013.json +71 -0
- data/standards/stig_microsoft_ie_version_6.json +599 -0
- data/standards/stig_microsoft_ie_version_7.json +749 -0
- data/standards/stig_microsoft_infopath_2003.json +41 -0
- data/standards/stig_microsoft_infopath_2007.json +167 -0
- data/standards/stig_microsoft_infopath_2010.json +155 -0
- data/standards/stig_microsoft_infopath_2013.json +149 -0
- data/standards/stig_microsoft_internet_explorer_10.json +857 -0
- data/standards/stig_microsoft_internet_explorer_11.json +839 -0
- data/standards/stig_microsoft_internet_explorer_9.json +821 -0
- data/standards/stig_microsoft_lync_2013.json +29 -0
- data/standards/stig_microsoft_office_system_2007.json +221 -0
- data/standards/stig_microsoft_office_system_2010.json +233 -0
- data/standards/stig_microsoft_office_system_2013.json +293 -0
- data/standards/stig_microsoft_office_system_2016.json +131 -0
- data/standards/stig_microsoft_onedrivebusiness_2016.json +89 -0
- data/standards/stig_microsoft_onenote_2010.json +77 -0
- data/standards/stig_microsoft_onenote_2013.json +71 -0
- data/standards/stig_microsoft_onenote_2016.json +71 -0
- data/standards/stig_microsoft_outlook_2003.json +65 -0
- data/standards/stig_microsoft_outlook_2007.json +479 -0
- data/standards/stig_microsoft_outlook_2010.json +515 -0
- data/standards/stig_microsoft_outlook_2013.json +497 -0
- data/standards/stig_microsoft_outlook_2016.json +359 -0
- data/standards/stig_microsoft_powerpoint_2003.json +47 -0
- data/standards/stig_microsoft_powerpoint_2007.json +131 -0
- data/standards/stig_microsoft_powerpoint_2010.json +191 -0
- data/standards/stig_microsoft_powerpoint_2013.json +251 -0
- data/standards/stig_microsoft_powerpoint_2016.json +233 -0
- data/standards/stig_microsoft_project_2010.json +83 -0
- data/standards/stig_microsoft_project_2013.json +95 -0
- data/standards/stig_microsoft_project_2016.json +95 -0
- data/standards/stig_microsoft_publisher_2010.json +107 -0
- data/standards/stig_microsoft_publisher_2013.json +101 -0
- data/standards/stig_microsoft_publisher_2016.json +101 -0
- data/standards/stig_microsoft_sharepoint_designer_2013.json +71 -0
- data/standards/stig_microsoft_skypebusiness_2016.json +29 -0
- data/standards/stig_microsoft_sql_server_2005_database.json +167 -0
- data/standards/stig_microsoft_sql_server_2005_instance.json +1001 -0
- data/standards/stig_microsoft_sql_server_2012_database.json +179 -0
- data/standards/stig_microsoft_sql_server_2012_database_instance.json +929 -0
- data/standards/stig_microsoft_visio_2013.json +89 -0
- data/standards/stig_microsoft_visio_2016.json +89 -0
- data/standards/stig_microsoft_windows_10_mobile.json +215 -0
- data/standards/stig_microsoft_windows_2008_server_domain_name_system.json +269 -0
- data/standards/stig_microsoft_windows_2012_server_domain_name_system.json +551 -0
- data/standards/stig_microsoft_windows_phone_8.1.json +161 -0
- data/standards/stig_microsoft_windows_server_2012_domain_controller.json +2633 -0
- data/standards/stig_microsoft_windows_server_2012_member_server.json +2411 -0
- data/standards/stig_microsoft_word_2003.json +47 -0
- data/standards/stig_microsoft_word_2007.json +119 -0
- data/standards/stig_microsoft_word_2010.json +221 -0
- data/standards/stig_microsoft_word_2013.json +221 -0
- data/standards/stig_microsoft_word_2016.json +215 -0
- data/standards/stig_mobile_application_management_mam_server.json +95 -0
- data/standards/stig_mobile_application_security_requirements_guide.json +233 -0
- data/standards/stig_mobile_device_integrity_scanning_mdis_server.json +119 -0
- data/standards/stig_mobile_device_management_mdm_server.json +125 -0
- data/standards/stig_mobile_device_manager_security_requirements_guide.json +2555 -0
- data/standards/stig_mobile_email_management_mem_server.json +197 -0
- data/standards/stig_mobile_operating_system_security_requirements_guide.json +1943 -0
- data/standards/stig_mobile_policy.json +35 -0
- data/standards/stig_mobile_policy_security_requirements_guide.json +437 -0
- data/standards/stig_mobileiron_core_v9.x_mdm.json +89 -0
- data/standards/stig_mobility_policy.json +65 -0
- data/standards/stig_mozilla_firefox.json +161 -0
- data/standards/stig_ms_exchange_2013_client_access_server.json +209 -0
- data/standards/stig_ms_exchange_2013_edge_transport_server.json +443 -0
- data/standards/stig_ms_exchange_2013_mailbox_server.json +437 -0
- data/standards/stig_ms_sharepoint_2010.json +269 -0
- data/standards/stig_ms_sharepoint_2013.json +245 -0
- data/standards/stig_ms_sharepoint_designer_2013.json +71 -0
- data/standards/stig_ms_sql_server_2014_database.json +263 -0
- data/standards/stig_ms_sql_server_2014_instance.json +575 -0
- data/standards/stig_ms_sql_server_2016_database.json +185 -0
- data/standards/stig_ms_sql_server_2016_instance.json +731 -0
- data/standards/stig_ms_windows_defender_antivirus.json +257 -0
- data/standards/stig_multifunction_device_and_network_printers.json +131 -0
- data/standards/stig_network_device_management_security_requirements_guide.json +863 -0
- data/standards/stig_network_devices.json +389 -0
- data/standards/stig_network_infrastructure_policy.json +455 -0
- data/standards/stig_network_security_requirements_guide.json +1961 -0
- data/standards/stig_operating_system_security_requirements_guide.json +1961 -0
- data/standards/stig_oracle_10_database_installation.json +527 -0
- data/standards/stig_oracle_10_database_instance.json +569 -0
- data/standards/stig_oracle_11_database_installation.json +527 -0
- data/standards/stig_oracle_11_database_instance.json +551 -0
- data/standards/stig_oracle_database_10g_installation.json +527 -0
- data/standards/stig_oracle_database_10g_instance.json +581 -0
- data/standards/stig_oracle_database_11.2g.json +1229 -0
- data/standards/stig_oracle_database_11g_installation.json +527 -0
- data/standards/stig_oracle_database_11g_instance.json +575 -0
- data/standards/stig_oracle_database_12c.json +1217 -0
- data/standards/stig_oracle_http_server_12.1.3.json +1703 -0
- data/standards/stig_oracle_linux_5.json +3431 -0
- data/standards/stig_oracle_linux_6.json +1583 -0
- data/standards/stig_oracle_weblogic_server_12c.json +443 -0
- data/standards/stig_palo_alto_networks_alg.json +311 -0
- data/standards/stig_palo_alto_networks_idps.json +185 -0
- data/standards/stig_palo_alto_networks_ndm.json +251 -0
- data/standards/stig_pda.json +83 -0
- data/standards/stig_pdasmartphone.json +95 -0
- data/standards/stig_perimeter_l3_switch.json +923 -0
- data/standards/stig_perimeter_l3_switch_-_cisco.json +1001 -0
- data/standards/stig_perimeter_router.json +803 -0
- data/standards/stig_perimeter_router_cisco.json +881 -0
- data/standards/stig_perimeter_router_juniper.json +803 -0
- data/standards/stig_postgresql_9.x.json +677 -0
- data/standards/stig_red_hat_enterprise_linux_5.json +3437 -0
- data/standards/stig_red_hat_enterprise_linux_6.json +1565 -0
- data/standards/stig_red_hat_enterprise_linux_7.json +1451 -0
- data/standards/stig_remote_access_policy.json +317 -0
- data/standards/stig_removable_storage_and_external_connection_technologies.json +143 -0
- data/standards/stig_removable_storage_and_external_connections.json +137 -0
- data/standards/stig_rfid_scanner.json +35 -0
- data/standards/stig_rfid_workstation.json +23 -0
- data/standards/stig_riverbed_steelhead_cx_v8_alg.json +83 -0
- data/standards/stig_riverbed_steelhead_cx_v8_ndm.json +371 -0
- data/standards/stig_router_security_requirements_guide.json +575 -0
- data/standards/stig_samsung_android_os_5_with_knox_2.0.json +365 -0
- data/standards/stig_samsung_android_os_6_with_knox_2.x.json +377 -0
- data/standards/stig_samsung_android_os_7_with_knox_2.x.json +443 -0
- data/standards/stig_samsung_android_with_knox_1.x.json +293 -0
- data/standards/stig_samsung_android_with_knox_2.x.json +371 -0
- data/standards/stig_samsung_knox_android_1.0.json +167 -0
- data/standards/stig_sharepoint_2010.json +269 -0
- data/standards/stig_sharepoint_2013.json +245 -0
- data/standards/stig_smartphone_policy.json +131 -0
- data/standards/stig_solaris_10_sparc.json +3029 -0
- data/standards/stig_solaris_10_x86.json +3065 -0
- data/standards/stig_solaris_11_sparc.json +1427 -0
- data/standards/stig_solaris_11_x86.json +1421 -0
- data/standards/stig_solaris_9_sparc.json +2915 -0
- data/standards/stig_solaris_9_x86.json +2915 -0
- data/standards/stig_sun_ray_4.json +185 -0
- data/standards/stig_sun_ray_4_policy.json +77 -0
- data/standards/stig_suse_linux_enterprise_server_v11system_z.json +3311 -0
- data/standards/stig_symantec_endpoint_protection_12.1_local_client_antivirus.json +689 -0
- data/standards/stig_symantec_endpoint_protection_12.1_managed_client_antivirus.json +695 -0
- data/standards/stig_tanium_6.5.json +461 -0
- data/standards/stig_tanium_7.0.json +803 -0
- data/standards/stig_test_and_development_zone_a.json +167 -0
- data/standards/stig_test_and_development_zone_b.json +179 -0
- data/standards/stig_test_and_development_zone_c.json +143 -0
- data/standards/stig_test_and_development_zone_d.json +143 -0
- data/standards/stig_traditional_security.json +917 -0
- data/standards/stig_unix_srg.json +3287 -0
- data/standards/stig_video_services_policy.json +497 -0
- data/standards/stig_video_teleconference.json +47 -0
- data/standards/stig_video_teleconference_vtc.json +12 -0
- data/standards/stig_vmware_esx_3_policy.json +155 -0
- data/standards/stig_vmware_esx_3_server.json +3791 -0
- data/standards/stig_vmware_esx_3_virtual_center.json +257 -0
- data/standards/stig_vmware_esx_3_virtual_machine.json +53 -0
- data/standards/stig_vmware_esxi_server_5.0.json +809 -0
- data/standards/stig_vmware_esxi_v5.json +5177 -0
- data/standards/stig_vmware_esxi_version_5_virtual_machine.json +317 -0
- data/standards/stig_vmware_nsx_distributed_firewall.json +83 -0
- data/standards/stig_vmware_nsx_distributed_logical_router.json +35 -0
- data/standards/stig_vmware_nsx_manager.json +191 -0
- data/standards/stig_vmware_vcenter_server.json +179 -0
- data/standards/stig_vmware_vcenter_server_version_5.json +149 -0
- data/standards/stig_vmware_vsphere_esxi_6.0.json +659 -0
- data/standards/stig_vmware_vsphere_vcenter_server_version_6.json +311 -0
- data/standards/stig_vmware_vsphere_virtual_machine_version_6.json +269 -0
- data/standards/stig_voice_and_video_over_internet_protocol_vvoip_policy.json +407 -0
- data/standards/stig_voice_video_endpoint_security_requirements_guide.json +395 -0
- data/standards/stig_voice_video_services_policy.json +671 -0
- data/standards/stig_voice_video_session_management_security_requirements_guide.json +329 -0
- data/standards/stig_voicevideo_over_internet_protocol.json +419 -0
- data/standards/stig_voicevideo_over_internet_protocol_vvoip.json +263 -0
- data/standards/stig_voicevideo_services_policy.json +569 -0
- data/standards/stig_web_policy.json +95 -0
- data/standards/stig_web_server.json +317 -0
- data/standards/stig_web_server_security_requirements_guide.json +587 -0
- data/standards/stig_win2k3_audit.json +761 -0
- data/standards/stig_win2k8_audit.json +1085 -0
- data/standards/stig_win2k8_r2_audit.json +1637 -0
- data/standards/stig_win7_audit.json +1613 -0
- data/standards/stig_windows_10.json +1691 -0
- data/standards/stig_windows_2003_domain_controller.json +893 -0
- data/standards/stig_windows_2003_member_server.json +845 -0
- data/standards/stig_windows_2008_domain_controller.json +1475 -0
- data/standards/stig_windows_2008_member_server.json +1301 -0
- data/standards/stig_windows_7.json +1781 -0
- data/standards/stig_windows_8.json +2399 -0
- data/standards/stig_windows_88.1.json +2273 -0
- data/standards/stig_windows_8_8.1.json +2297 -0
- data/standards/stig_windows_defender_antivirus.json +239 -0
- data/standards/stig_windows_dns.json +185 -0
- data/standards/stig_windows_firewall_with_advanced_security.json +137 -0
- data/standards/stig_windows_paw.json +155 -0
- data/standards/stig_windows_phone_6.5_with_good_mobility_suite.json +65 -0
- data/standards/stig_windows_server_2008_r2_domain_controller.json +1961 -0
- data/standards/stig_windows_server_2008_r2_member_server.json +1745 -0
- data/standards/stig_windows_server_20122012_r2_domain_controller.json +2255 -0
- data/standards/stig_windows_server_20122012_r2_member_server.json +2045 -0
- data/standards/stig_windows_server_2012_2012_r2_domain_controller.json +2279 -0
- data/standards/stig_windows_server_2012_2012_r2_member_server.json +2075 -0
- data/standards/stig_windows_server_2012_domain_controller.json +2471 -0
- data/standards/stig_windows_server_2012_member_server.json +2249 -0
- data/standards/stig_windows_server_2016.json +1661 -0
- data/standards/stig_windows_vista.json +1517 -0
- data/standards/stig_windows_xp.json +893 -0
- data/standards/stig_wireless_keyboard_and_mouse.json +23 -0
- data/standards/stig_wireless_management_server_policy.json +53 -0
- data/standards/stig_wireless_remote_access_policy_security_implementation_guide.json +29 -0
- data/standards/stig_wlan_access_point_enclave-niprnet_connected.json +227 -0
- data/standards/stig_wlan_access_point_internet_gateway_only_connection.json +209 -0
- data/standards/stig_wlan_access_point_policy.json +17 -0
- data/standards/stig_wlan_authentication_server.json +29 -0
- data/standards/stig_wlan_bridge.json +209 -0
- data/standards/stig_wlan_client.json +65 -0
- data/standards/stig_wlan_controller.json +215 -0
- data/standards/stig_wlan_ids_sensorserver.json +23 -0
- data/standards/stig_wman_access_point.json +263 -0
- data/standards/stig_wman_bridge.json +209 -0
- data/standards/stig_wman_subscriber.json +65 -0
- data/standards/stig_zos_acf2.json +1451 -0
- data/standards/stig_zos_bmc_control-dacf2.json +53 -0
- data/standards/stig_zos_bmc_control-dracf.json +59 -0
- data/standards/stig_zos_bmc_control-dtss.json +65 -0
- data/standards/stig_zos_bmc_control-macf2.json +59 -0
- data/standards/stig_zos_bmc_control-mracf.json +65 -0
- data/standards/stig_zos_bmc_control-mrestartacf2.json +23 -0
- data/standards/stig_zos_bmc_control-mrestartracf.json +23 -0
- data/standards/stig_zos_bmc_control-mrestarttss.json +23 -0
- data/standards/stig_zos_bmc_control-mtss.json +71 -0
- data/standards/stig_zos_bmc_control-oacf2.json +53 -0
- data/standards/stig_zos_bmc_control-oracf.json +59 -0
- data/standards/stig_zos_bmc_control-otss.json +65 -0
- data/standards/stig_zos_bmc_ioaacf2.json +53 -0
- data/standards/stig_zos_bmc_ioaracf.json +59 -0
- data/standards/stig_zos_bmc_ioatss.json +65 -0
- data/standards/stig_zos_bmc_mainviewzosacf2.json +47 -0
- data/standards/stig_zos_bmc_mainviewzosracf.json +53 -0
- data/standards/stig_zos_bmc_mainviewzostss.json +59 -0
- data/standards/stig_zos_ca_1_tape_managementacf2.json +65 -0
- data/standards/stig_zos_ca_1_tape_managementracf.json +77 -0
- data/standards/stig_zos_ca_1_tape_managementtss.json +77 -0
- data/standards/stig_zos_ca_auditoracf2.json +29 -0
- data/standards/stig_zos_ca_auditorracf.json +29 -0
- data/standards/stig_zos_ca_auditortss.json +29 -0
- data/standards/stig_zos_ca_common_servicesacf2.json +23 -0
- data/standards/stig_zos_ca_common_servicesracf.json +29 -0
- data/standards/stig_zos_ca_common_servicestss.json +29 -0
- data/standards/stig_zos_ca_micsacf2.json +23 -0
- data/standards/stig_zos_ca_micsracf.json +23 -0
- data/standards/stig_zos_ca_micstss.json +23 -0
- data/standards/stig_zos_ca_mimacf2.json +41 -0
- data/standards/stig_zos_ca_mimracf.json +47 -0
- data/standards/stig_zos_ca_mimtss.json +47 -0
- data/standards/stig_zos_ca_vtapeacf2.json +29 -0
- data/standards/stig_zos_ca_vtaperacf.json +35 -0
- data/standards/stig_zos_ca_vtapetss.json +35 -0
- data/standards/stig_zos_catalog_solutionsacf2.json +23 -0
- data/standards/stig_zos_catalog_solutionsracf.json +23 -0
- data/standards/stig_zos_catalog_solutionstss.json +23 -0
- data/standards/stig_zos_clsupersessionacf2.json +53 -0
- data/standards/stig_zos_clsupersessionracf.json +65 -0
- data/standards/stig_zos_clsupersessiontss.json +71 -0
- data/standards/stig_zos_compuware_abend-aidacf2.json +47 -0
- data/standards/stig_zos_compuware_abend-aidracf.json +53 -0
- data/standards/stig_zos_compuware_abend-aidtss.json +53 -0
- data/standards/stig_zos_cssmtpacf2.json +23 -0
- data/standards/stig_zos_cssmtpracf.json +29 -0
- data/standards/stig_zos_cssmtptss.json +29 -0
- data/standards/stig_zos_fdracf2.json +23 -0
- data/standards/stig_zos_fdrracf.json +23 -0
- data/standards/stig_zos_fdrtss.json +23 -0
- data/standards/stig_zos_hcdacf2.json +29 -0
- data/standards/stig_zos_hcdracf.json +29 -0
- data/standards/stig_zos_hcdtss.json +29 -0
- data/standards/stig_zos_ibm_cics_transaction_serveracf2.json +17 -0
- data/standards/stig_zos_ibm_cics_transaction_serverracf.json +17 -0
- data/standards/stig_zos_ibm_cics_transaction_servertss.json +17 -0
- data/standards/stig_zos_ibm_health_checkeracf2.json +23 -0
- data/standards/stig_zos_ibm_health_checkerracf.json +29 -0
- data/standards/stig_zos_ibm_health_checkertss.json +29 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsfacf2.json +53 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsfracf.json +59 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsftss.json +53 -0
- data/standards/stig_zos_icsfacf2.json +29 -0
- data/standards/stig_zos_icsfracf.json +35 -0
- data/standards/stig_zos_icsftss.json +35 -0
- data/standards/stig_zos_netviewacf2.json +41 -0
- data/standards/stig_zos_netviewracf.json +47 -0
- data/standards/stig_zos_netviewtss.json +53 -0
- data/standards/stig_zos_quest_nc-passacf2.json +35 -0
- data/standards/stig_zos_quest_nc-passracf.json +41 -0
- data/standards/stig_zos_quest_nc-passtss.json +47 -0
- data/standards/stig_zos_racf.json +1415 -0
- data/standards/stig_zos_roscoeacf2.json +47 -0
- data/standards/stig_zos_roscoeracf.json +53 -0
- data/standards/stig_zos_roscoetss.json +59 -0
- data/standards/stig_zos_srrauditacf2.json +23 -0
- data/standards/stig_zos_srrauditracf.json +23 -0
- data/standards/stig_zos_srraudittss.json +23 -0
- data/standards/stig_zos_tadzacf2.json +29 -0
- data/standards/stig_zos_tadzracf.json +35 -0
- data/standards/stig_zos_tadztss.json +35 -0
- data/standards/stig_zos_tdmfacf2.json +23 -0
- data/standards/stig_zos_tdmfracf.json +23 -0
- data/standards/stig_zos_tdmftss.json +23 -0
- data/standards/stig_zos_tss.json +1523 -0
- data/standards/stig_zos_vssracf.json +29 -0
- metadata +691 -0
|
@@ -0,0 +1,671 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_voice_video_services_policy",
|
|
3
|
+
"date": "2017-12-21",
|
|
4
|
+
"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.stig_spt@mail.mil.",
|
|
5
|
+
"title": "Voice Video Services Policy STIG",
|
|
6
|
+
"version": "3",
|
|
7
|
+
"item_syntax": "^\\w-\\d+$",
|
|
8
|
+
"section_separator": null,
|
|
9
|
+
"items": [
|
|
10
|
+
{
|
|
11
|
+
"id": "V-16070",
|
|
12
|
+
"title": "C2 and Special-C2 users are not aware of the assured service limitations of their PC based communications applications.",
|
|
13
|
+
"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’s 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’t 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’s 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’s 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",
|
|
14
|
+
"severity": "medium"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"id": "V-16073",
|
|
18
|
+
"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.",
|
|
19
|
+
"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’s 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’t 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’s 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’s 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",
|
|
20
|
+
"severity": "medium"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "V-16074",
|
|
24
|
+
"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.",
|
|
25
|
+
"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.",
|
|
26
|
+
"severity": "high"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "V-16076",
|
|
30
|
+
"title": "VTC, Unified Capability (UC) soft client, and speakerphone microphone operations policy must prevent the pickup and transmission of sensitive or classified information over non-secure systems.",
|
|
31
|
+
"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 on the call. This same sensitivity is included in VTUs that are used in office spaces. This has one disadvantage. The microphones can pick up sidebar conversations that have no relationship to the conference or call in progress. Likewise, in an open area, received conference audio can be broadcast to others in the area that are not part of the conference, and possibly should not be exposed to the conference information for need-to-know reasons. Speakerphones exhibit a similar vulnerability. This is the same confidentiality vulnerability posed to audible sound information in the environment as discussed above with the added twist that the conference audio is vulnerable to others in the environment. While this is more of an issue in environments where classified conversations normally occur, it is also an issue in any environment. This is of particularly concern in open work areas or open offices where multiple people work in near proximity. Users or operators of VTC systems of any type must take care regarding who can hear what is being said during a conference call and what unrelated conversations can be picked up by the sensitive microphone. Where a VTU is used by a single person in an open area, a partial mitigation for this could be the use of a headset with earphones and a microphone. While this would limit the ability of others to hear audio from the conference and could also limit the audio pickup of unrelated conversations, it may not be fully effective. In some instances, such as when a VTU is located in a SCIF, a Push-to-Talk (PTT) handset/headset may be required Microphones embedded in or connected to a communications endpoint, PC, or PC monitor can be sensitive enough to pick up sound that is not related to a given communications session. They could pick up nearby conversations and other sounds. This capability could compromise sensitive or classified information that is not related to the communications in progress. Speakers embedded in or connected to a communications endpoint or PC can be made loud enough to be heard across a room or in the next workspace. This capability could compromise sensitive or classified information that is being communicated during a session. Users must be aware of other conversations in the area and their sensitivity when using any communications endpoint, not only a PC based voice, video, or collaboration communications application. This awareness must then translate into protecting or eliminating these other conversations. A short range, reduced gain, or noise canceling microphone may be required. A push to talk microphone may also be required for classified areas. The microphone should be muted when the user is not speaking as both mitigation for this issue, and for proper etiquette when participating in a conference. The muting function should be performed using a positively controlled disconnect, shorting switch, or mechanism instead of a software controlled mute function on the PC. Users must be aware of other people in the area that could hear what is being communicated. This is particularly an issue if the communicated information is sensitive or classified since the parties overhearing the information may not have proper clearance or a need-to-know. To mitigate this issue, a headset or speakers should be used and at a volume that only the user can hear.",
|
|
32
|
+
"severity": "medium"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "V-16077",
|
|
36
|
+
"title": "Deficient Policy or SOP regarding PC communications video display positioning.",
|
|
37
|
+
"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.",
|
|
38
|
+
"severity": "medium"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "V-16078",
|
|
42
|
+
"title": "Deficient SOP or enforcement regarding presentation and application sharing via a PC or VTC.",
|
|
43
|
+
"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. ",
|
|
44
|
+
"severity": "medium"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "V-16081",
|
|
48
|
+
"title": "Deficient training for the secure operation of PC desktop, presentation, or application sharing capabilities of a collaboration tool.",
|
|
49
|
+
"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. ",
|
|
50
|
+
"severity": "medium"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "V-16082",
|
|
54
|
+
"title": "Audio pickup or video capture capabilities (microphones and cameras) are not disabled when not needed for active participation in a communications session.",
|
|
55
|
+
"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",
|
|
56
|
+
"severity": "medium"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"id": "V-16085",
|
|
60
|
+
"title": "Unified Capability (UC) soft client accessories must be tested and approved.",
|
|
61
|
+
"description": "While a headset, microphone, or webcam can be considered to be UC soft client accessories, these are also accessories for other collaboration and communications applications. Our discussion here relates to, UC soft client specific accessories, which include USB phones, USB ATAs, PPGs, and headsets. A USB phone is a physical USB connected telephone instrument that associates itself with the UC soft client 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. A USB ATA is a USB connected device that associates itself with the UC soft client 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 UC soft client 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 UC soft client application and supporting VVoIP 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 UC soft client 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. DECT 6.0 headsets provide wireless microphone and earphone use to a telephone device. ",
|
|
62
|
+
"severity": "low"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-16086",
|
|
66
|
+
"title": "User training must deny the use of personally provided Unified Capability (UC) soft client accessories.",
|
|
67
|
+
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be UC soft client 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. A USB phone is a physical USB connected telephone instrument that associates itself with the UC soft client 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. \nA USB ATA is a USB connected device that associates itself with the UC soft client 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 UC soft client 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 UC soft client application and supporting VVoIP 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 UC soft client 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. ",
|
|
68
|
+
"severity": "low"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-16087",
|
|
72
|
+
"title": "Voice networks must not be bridged via a Unified Capability (UC) soft client accessory.",
|
|
73
|
+
"description": "While a headset, microphone, or webcam can be considered to be UC soft client accessories, these are also accessories for other collaboration and communications applications. Our discussion here relates to, UC soft client 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 UC soft client 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. They should be operated accordingly. A USB ATA is a USB connected device that associates itself with the UC soft client 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 UC soft client 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 UC soft client application and supporting VVoIP 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 UC soft client 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. DECT 6.0 headsets provide wireless microphone and earphone use to a telephone device.",
|
|
74
|
+
"severity": "medium"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-16088",
|
|
78
|
+
"title": "User training must include Unified Capability (UC) soft client accessory network bridging risks.",
|
|
79
|
+
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be UC soft client 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, UC soft client 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 UC soft client 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 UC soft client 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 UC soft client 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 UC soft client application and supporting VVoIP 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 UC soft client 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.",
|
|
80
|
+
"severity": "medium"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "V-16089",
|
|
84
|
+
"title": "Deficient training or training materials addressing secure PC communications client application usage.",
|
|
85
|
+
"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’s 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. ",
|
|
86
|
+
"severity": "medium"
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "V-16090",
|
|
90
|
+
"title": "An acceptable use policy or user agreement must be enforced for Unified Capabilities (UC) soft client users.",
|
|
91
|
+
"description": "User agreements must be accompanied with a combination of user training and user guides reinforcing the organization's policies and prohibitions for UC soft clients (voice, video, and collaboration communications software clients). The user agreement is required in the DoD and must contain site policy and acceptable use of information system assets. Users must read and sign the user agreement before receiving government-furnished hardware or software. This extends to gaining access to additional information systems, adding on applications, or receiving additional privileges.\n\nPolicies must include acceptable use of the UC soft client application, UC soft client accessories, as well as web browsing, remote access, wireless use, and protection of controlled unclassified information (CUI). Minimally, the user agreement must be updated as privileges and additional applications are installed. User agreements must also be accompanied with user training and user guides that reinforce policies and provide additional relevant information.",
|
|
92
|
+
"severity": "medium"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-16091",
|
|
96
|
+
"title": "A user guide identifying the proper use of Unified Capabilities (UC) soft client applications must be provided to UC soft client users.",
|
|
97
|
+
"description": "User agreements must be accompanied with a combination of user training and user guides reinforcing the organization's policies and prohibitions for UC soft clients (voice, video, and collaboration communications software clients). The training and guides should also provide additional information such as how to operate the UC soft client and implement cybersecurity features as required. Other topics that should be contained in a user guide include the use of webcams and microphones with both UC soft clients and hardware end instruments when used in a classified environment or where classified discussions occur.\n\nThe user guide must contain a discussion pertaining to the use of UC soft client applications for assured service C2 communications. Cautions regarding the potentially unreliable nature of these communications applications or methods must be included in user guides so that C2 users are aware of, and reminded of, the non-assured service nature of these communications methods.",
|
|
98
|
+
"severity": "low"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"id": "V-16094",
|
|
102
|
+
"title": "Deficient support for COOP or emergency and life safety communications when soft-phones are implemented as the primary voice endpoint in user’s workspace caused by deficient placement of physical hardware based phones near all such workspaces.",
|
|
103
|
+
"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’s 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’s 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’s 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: • 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 “users can call on their cell phones”, 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. • 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). • 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. • 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 “soft-phone world” 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. • 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",
|
|
104
|
+
"severity": "medium"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"id": "V-16095",
|
|
108
|
+
"title": "Implementing Unified Capabilities (UC) soft clients as the primary voice endpoint must have Authorizing Official (AO) approval.",
|
|
109
|
+
"description": "The AO responsible for the implementation of a voice system that uses UC soft clients for its endpoints must be made aware of the risks and benefits. In addition, the commander of an organization whose mission depends upon such a telephone system must also be made aware and provide approval. When UC soft clients are fielded as the primary endpoint, the risk of unavailability is high compared to dedicated instruments. Another major difficulty for UC soft clients deployed on laptops is providing accurate location information for emergency services. When emergency services are called from the laptop, if it is not at the location entered in the Automated Location Identification (ALI) database, emergency services may be dispatched to the wrong place.",
|
|
110
|
+
"severity": "medium"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-16096",
|
|
114
|
+
"title": "Deploying Unified Communications (UC) soft clients on DoD networks must have Authorizing Official (AO) approval.",
|
|
115
|
+
"description": "This use case addresses situations whereby UC soft client applications on workstations are not the primary voice communications device in the work area. This means that there is a validated mission need and the number of UC soft clients 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 UC soft clients required to meet specific mission requirements. There are scenarios for the use of limited numbers of UC soft clients in the strategic LAN. The first of these scenarios is providing support for UC soft clients associated with a VoIP system in another enclave. This is a remote access scenario and must operate as they would in a normal remote access use case. 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\nVoice/video and data must reside on separate VLANs for the protection of the voice infrastructure. However, recognizing that requiring a NIC to be configured to support voice/video and data VLANs is not a viable solution, voice and data traffic can coexist in the data VLAN when leaving the workstation. Based on the Unified Capabilities Requirements (UCR) requirement that the Unified Capabilities (UC) application tag its signaling and media traffic with the proper UCR defined Differentiated Service Code Point (DSCP), the LAN access switch port can route the UC traffic to the voice/video VLAN. If the LAN access switch is not capable, then routing upstream must perform this. A separate NIC is not required to support VLANs for voice and video segmentation under UC.",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-16098",
|
|
120
|
+
"title": "A Call Center or Computer Telephony Integration (CTI) system using soft clients must be segregated into a protected enclave and limit traffic traversing the boundary.",
|
|
121
|
+
"description": "UC soft clients may be used on a strategic LAN when associated with or part of a 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’s 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’s 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 and that this can be accomplished by maintaining a closed network or a segregated and access controlled sub-enclave having appropriate boundary protection.",
|
|
122
|
+
"severity": "medium"
|
|
123
|
+
},
|
|
124
|
+
{
|
|
125
|
+
"id": "V-16099",
|
|
126
|
+
"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.",
|
|
127
|
+
"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",
|
|
128
|
+
"severity": "medium"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"id": "V-16101",
|
|
132
|
+
"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.",
|
|
133
|
+
"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",
|
|
134
|
+
"severity": "medium"
|
|
135
|
+
},
|
|
136
|
+
{
|
|
137
|
+
"id": "V-16106",
|
|
138
|
+
"title": "The Unified Capabilities (UC) soft client Certification and Accreditation (CA) documentation must be included in the CA documentation for the supporting VVoIP system.",
|
|
139
|
+
"description": "Communications applications must be tested and subsequently certified and accredited for IA purposes. This includes the applications and any upgrades or patches. Since a UC soft client 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 UC soft client must be included in the C&A documentation for the overall VVoIP system. Subsequently the VVoIP system’s C&A documentation must be included in the C&A documentation for the LAN or enclave.",
|
|
140
|
+
"severity": "medium"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-16107",
|
|
144
|
+
"title": "Unified Capabilities (UC) soft clients must be tested and approved prior to implementation.",
|
|
145
|
+
"description": "It is important that UC soft clients be tested and subsequently certified and accredited for IA purposes, to include upgrades or patches. Applications that have not been sufficiently vetted may introduce malware to the network or have security issues an adversary may manipulate.",
|
|
146
|
+
"severity": "medium"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-16108",
|
|
150
|
+
"title": "Unified Capabilities (UC) soft client patches and upgrades must be tested and approved prior to implementation.",
|
|
151
|
+
"description": "It is important that UC soft clients be tested and subsequently certified and accredited for IA purposes, to include upgrades or patches. Applications that have not been sufficiently vetted may introduce malware to the network or have security issues an adversary may manipulate.",
|
|
152
|
+
"severity": "medium"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "V-16109",
|
|
156
|
+
"title": "A PC Communications Application is not tested for IA and Interoperability and are not listed on the DoD UC APL.",
|
|
157
|
+
"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 “This 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.” 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’s 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’s 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",
|
|
158
|
+
"severity": "medium"
|
|
159
|
+
},
|
|
160
|
+
{
|
|
161
|
+
"id": "V-16111",
|
|
162
|
+
"title": "Unified Capabilities (UC) soft clients must be supported by the manufacturer or vendor.",
|
|
163
|
+
"description": "One of the measures to protect UC soft clients 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 for compromise of a communications application is the use of freeware or shareware applications. Communications applications that provide voice communications must be designed to properly interoperate with the VoIP system. These applications should be a standard product of the voice system vendor or a partner whose product is approved by this vendor. \n\nSome UC soft clients provide VTC and collaboration features and should be sourced from the voice system vendor. Applications providing VTC features that interoperate directly with a hardware based VTC system should be sourced from the VTC system’s vendor or a partner whose product is approved by this vendor. Other UC soft clients that 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. UC soft clients that provide multiple services such as IM, presence, voice, VTC, web conferencing, and so forth, may be integrated with the operating system, such as Microsoft’s Office Communications applications. Application sourcing can also be dependent on whether the application is to interoperate with hardware based communications system located and operated within an enclave or whether it is a system operated by an interagency or inter-base program. The vendor must be able to provide patches, upgrades or both to mitigate newly discovered vulnerabilities found in their product in a timely manner. ",
|
|
164
|
+
"severity": "medium"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "V-16112",
|
|
168
|
+
"title": "The integrity of a PC Communications Application, upgrade, or patch is not validated via digital signature before installation.",
|
|
169
|
+
"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’s 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.",
|
|
170
|
+
"severity": "medium"
|
|
171
|
+
},
|
|
172
|
+
{
|
|
173
|
+
"id": "V-16113",
|
|
174
|
+
"title": "A PC communications application is not maintained at the current/latest approved patch or version/upgrade level.",
|
|
175
|
+
"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.",
|
|
176
|
+
"severity": "medium"
|
|
177
|
+
},
|
|
178
|
+
{
|
|
179
|
+
"id": "V-16114",
|
|
180
|
+
"title": "A PC communications application is operated with administrative or root level privileges.",
|
|
181
|
+
"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.",
|
|
182
|
+
"severity": "medium"
|
|
183
|
+
},
|
|
184
|
+
{
|
|
185
|
+
"id": "V-16115",
|
|
186
|
+
"title": "The integrity of VVoIP endpoint configuration files downloaded during endpoint registration must be validated using digital signatures.",
|
|
187
|
+
"description": "During VVoIP endpoint registration with the session controller, a file is downloaded by the endpoint from the session manager containing specific configuration settings. This file contains the phone number assigned to the endpoint, the IP addresses for session management, the software menus specific to the system, the endpoint configuration password, the stored personal preferences and speed dial numbers, and other system operational information. These configuration settings can be updated by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded.\n\nThe integrity of these files is critical to preventing compromise of the Unified Capabilities (UC) soft clients, the hardware endpoints, and the system itself. The best method for maintaining configuration file integrity is requiring they be digitally signed. This prevents 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.",
|
|
188
|
+
"severity": "medium"
|
|
189
|
+
},
|
|
190
|
+
{
|
|
191
|
+
"id": "V-16116",
|
|
192
|
+
"title": "PC communications application server association is not properly limited.",
|
|
193
|
+
"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’s 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",
|
|
194
|
+
"severity": "medium"
|
|
195
|
+
},
|
|
196
|
+
{
|
|
197
|
+
"id": "V-16117",
|
|
198
|
+
"title": "An unapproved Instant Messaging (IM) or Unified Capabilities (UC) soft client must not be used on Government Furnished Equipment (GFE).",
|
|
199
|
+
"description": "DoD policies disallow general PC users from installing any unapproved application on their workstations or from attaching any unapproved or non-government furnished devices to them. Other DoD policies require users of GFE to limit their use to official business and not use them for personal business or other personal activities. 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. Some services use standard ports 80 and 443 for web services which are generally never blocked. ",
|
|
200
|
+
"severity": "medium"
|
|
201
|
+
},
|
|
202
|
+
{
|
|
203
|
+
"id": "V-16118",
|
|
204
|
+
"title": "Deficient user training regarding the use of non-approved applications and hardware.",
|
|
205
|
+
"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’s 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. ",
|
|
206
|
+
"severity": "medium"
|
|
207
|
+
},
|
|
208
|
+
{
|
|
209
|
+
"id": "V-16119",
|
|
210
|
+
"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.",
|
|
211
|
+
"description": "DoDI 8550.1 Ports, Protocols, and Services Management (PPSM) is the DoD’s 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 “visible to DoD-managed components”. 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.",
|
|
212
|
+
"severity": "medium"
|
|
213
|
+
},
|
|
214
|
+
{
|
|
215
|
+
"id": "V-19440",
|
|
216
|
+
"title": "VVoIP session signaling must be encrypted to provide end-to-end interoperable confidentiality and integrity.",
|
|
217
|
+
"description": "Because vendors did not have interoperability, lacked end-to-end encryption, and did not provide assured service in support of Command and Control (C2) communications, VVoIP traffic originally was restricted to the local enclave. The DSN PMO, DISA Engineering, and 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. \n\nVVoIP uses signaling protocols to set up and manage the communications session and the media transfer protocols carrying the communications. Both signaling and media protocols can be compromised when transmitted without encryption. To provide the assured service pre-emption and priority capabilities required for C2 telephone communications, DISA developed an extension to the SIP protocol 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 TLS. 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. ",
|
|
218
|
+
"severity": "medium"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "V-19441",
|
|
222
|
+
"title": "VVoIP session media must be encrypted to provide end-to-end interoperable confidentiality and integrity.",
|
|
223
|
+
"description": "Because vendors did not have interoperability, lacked end-to-end encryption, and did not provide assured service in support of Command and Control (C2) communications, VVoIP traffic originally was restricted to the local enclave. The DSN PMO, DISA Engineering, and 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. \n\nVVoIP uses signaling protocols to set up and manage the communications session and the media transfer protocols carrying the communications. Both signaling and media protocols can be compromised when transmitted without encryption. To provide the assured service pre-emption and priority capabilities required for C2 telephone communications, DISA developed an extension to the SIP protocol 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 TLS. 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. ",
|
|
224
|
+
"severity": "medium"
|
|
225
|
+
},
|
|
226
|
+
{
|
|
227
|
+
"id": "V-19442",
|
|
228
|
+
"title": "The site’s 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",
|
|
229
|
+
"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’s 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• Large sites and Intranets: \n•• Redundancy of platforms – Two or more LSC controllers clustered o Geographic diversity in locating the multiple LSCs within the site or Intranet \n• Small Sites (not dual homed): \n•• 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",
|
|
230
|
+
"severity": "low"
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "V-19443",
|
|
234
|
+
"title": "The local VVoIP system must have the capability to place intra-site and local phone calls when network connectivity is severed from the remote centrally-located session controller.",
|
|
235
|
+
"description": "Voice phone services are critical to the effective operation of a business, an office, or in support or control of a DoD mission. 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. DoD voice networks are designed to be extremely reliable and provide continuity of operations (COOP) support. However, the potential exists that a site may become severed from the DoD network. Some site’s DoD VoIP phone systems are implemented without a local session controller. The session controller may be located remotely and serve several sites by providing long local service. 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 session controller over the DISN WAN connection, then the session controller has to signal the called instrument or media gateway 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 session controller. Based on this fact, and in support of maintaining viable local voice services in the event the site is cut off from its remote session controller, 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.",
|
|
236
|
+
"severity": "medium"
|
|
237
|
+
},
|
|
238
|
+
{
|
|
239
|
+
"id": "V-19482",
|
|
240
|
+
"title": "The integrity of a vendor provided application, upgrade, or patch is not validated via digital signature before installation.",
|
|
241
|
+
"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’s 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.",
|
|
242
|
+
"severity": "medium"
|
|
243
|
+
},
|
|
244
|
+
{
|
|
245
|
+
"id": "V-19493",
|
|
246
|
+
"title": "The confidentiality of VVoIP endpoint configuration files downloaded during endpoint registration must be protected by encryption.",
|
|
247
|
+
"description": "During VVoIP endpoint registration with the session controller, a file is downloaded by the endpoint from the session manager containing specific configuration settings. This file contains the phone number assigned to the endpoint, the IP addresses for session management, the software menus specific to the system, the endpoint configuration password, the stored personal preferences and speed dial numbers, and other system operational information. These configuration settings can be updated by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded.\n\nThe confidentiality of these files is critical to preventing compromise of the Unified Capabilities (UC) soft clients, the hardware endpoints, and the system itself. Some configuration files may be human readable like XML code and most VVoIP signaling protocols. When human readable, intelligence can be gathered by capturing the file in transit. The best method for maintaining the confidentiality of configuration files is encryption. This prevents man-in-the-middle attacks. Encryption of this file is also required if the file contains the password used to access the endpoint’s configuration information and settings menus. ",
|
|
248
|
+
"severity": "low"
|
|
249
|
+
},
|
|
250
|
+
{
|
|
251
|
+
"id": "V-19500",
|
|
252
|
+
"title": "The LAN supporting VVoIP services must provide enhanced reliability, availability, and bandwidth.",
|
|
253
|
+
"description": "The traditional circuit switched telecommunications network is highly available and reliable with 99.999% uptime for equipment and 99% to 99.9% for the entire system. 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. The DoD circuit switched telecommunications network supports routine communications, emergency communications, and high priority military command and control precedence. As these services migrate from circuit-switched technologies to IP-based technologies, this reliability and support must migrate with the service. Similar measures enhance the reliability and availability of VVoIP services on an IP network.",
|
|
254
|
+
"severity": "low"
|
|
255
|
+
},
|
|
256
|
+
{
|
|
257
|
+
"id": "V-19514",
|
|
258
|
+
"title": "The LAN hardware supporting VVoIP services must provide redundancy to support command and control (C2) assured services and Fire and Emergency Services (FES) communications.",
|
|
259
|
+
"description": "Voice services in support of high priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DoD VVoIP implementations are in the UCR, specifying assured services supporting DoD IP based voice services. The UCR defines LAN design requirements for redundancy of equipment and interconnections, minimum requirements for bandwidth, specifications for backup power, and the maximum number of endpoints tolerable by a single point of failure. Policy sets the minimum requirements for the availability and reliability of VVoIP systems Special-C2 users is 99.999%, C2 users is 99.997%, C2Routine only users (C2R) and non-C2 users is 99.9%.\n\nSimilar availability and reliability through redundancy is needed to support routine user FES life-safety and security related communications. ",
|
|
260
|
+
"severity": "medium"
|
|
261
|
+
},
|
|
262
|
+
{
|
|
263
|
+
"id": "V-19521",
|
|
264
|
+
"title": "The LAN hardware supporting VVoIP services must provide physically diverse pathways for redundant links supporting command and control (C2) assured services and Fire and Emergency Services (FES) communications.",
|
|
265
|
+
"description": "Voice services in support of high priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DoD VVoIP implementations are in the Unified Capabilities Requirements (UCR), specifying assured services supporting DoD IP based voice services. Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering quickly from network failures quickly and maintaining the required QoS for existing services. Policy sets the minimum requirements for the availability and reliability of VVoIP systems Special-C2 users is 99.999%, C2 users is 99.997%, C2Routine only users (C2R) and non-C2 users is 99.9%.\n\nThe physical paths uplinks take should be physically diverse and optimally terminate in physically diverse locations. The best practices should support all VVoIP users but are required for Special-C2 and C2 users. ",
|
|
266
|
+
"severity": "medium"
|
|
267
|
+
},
|
|
268
|
+
{
|
|
269
|
+
"id": "V-19535",
|
|
270
|
+
"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.",
|
|
271
|
+
"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 “digital 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 – 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. ",
|
|
272
|
+
"severity": "medium"
|
|
273
|
+
},
|
|
274
|
+
{
|
|
275
|
+
"id": "V-19545",
|
|
276
|
+
"title": "VVoIP core components are not assigned static addresses within the dedicated VVoIP address space",
|
|
277
|
+
"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.",
|
|
278
|
+
"severity": "medium"
|
|
279
|
+
},
|
|
280
|
+
{
|
|
281
|
+
"id": "V-19547",
|
|
282
|
+
"title": "The VVoIP system management network must provide bidirectional enclave boundary protection between the local management network and the DISN voice services management network.",
|
|
283
|
+
"description": "VVoIP core system devices and Time Division Multiplexer (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’s 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. 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. Enclaves are defined as 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’s ADIMSS network, the RTS EMS, and the DISN DCN are different enclaves. Therefore, minimally, a firewall is required where these enclaves meet.",
|
|
284
|
+
"severity": "medium"
|
|
285
|
+
},
|
|
286
|
+
{
|
|
287
|
+
"id": "V-19562",
|
|
288
|
+
"title": "The VVoIP system and LAN design must provide 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.",
|
|
289
|
+
"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 –band 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’t 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. ",
|
|
290
|
+
"severity": "medium"
|
|
291
|
+
},
|
|
292
|
+
{
|
|
293
|
+
"id": "V-19565",
|
|
294
|
+
"title": "The VVoIP system and supporting LAN design must contain one or more routing devices to provide support for required ACLs between the various required VVoIP VLANs.",
|
|
295
|
+
"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’s 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 “managed service” 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.",
|
|
296
|
+
"severity": "medium"
|
|
297
|
+
},
|
|
298
|
+
{
|
|
299
|
+
"id": "V-19592",
|
|
300
|
+
"title": "The site’s 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.",
|
|
301
|
+
"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’s network via a VPN or dedicated TDM or optical circuit. In effect, a connection into the service provider’s network would provide a path to the Internet. These types of local connections provide a “back door” 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 “Approved Gateway.” 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 “back door” as used here means an illicit or UN-approved connection and is not intended to have the same meaning as the term “backdoor connection”, 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’s 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 “approved ISP gateway” 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 “back door” 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",
|
|
302
|
+
"severity": "medium"
|
|
303
|
+
},
|
|
304
|
+
{
|
|
305
|
+
"id": "V-19593",
|
|
306
|
+
"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.",
|
|
307
|
+
"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’s 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",
|
|
308
|
+
"severity": "medium"
|
|
309
|
+
},
|
|
310
|
+
{
|
|
311
|
+
"id": "V-19594",
|
|
312
|
+
"title": "The VVoIP system connection to the DISN WAN, its components, and/or changes to them are not included in the site’s enclave / LAN baseline documentation and C&A documentation.",
|
|
313
|
+
"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’s 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. ",
|
|
314
|
+
"severity": "medium"
|
|
315
|
+
},
|
|
316
|
+
{
|
|
317
|
+
"id": "V-19595",
|
|
318
|
+
"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",
|
|
319
|
+
"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’s 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",
|
|
320
|
+
"severity": "medium"
|
|
321
|
+
},
|
|
322
|
+
{
|
|
323
|
+
"id": "V-19596",
|
|
324
|
+
"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",
|
|
325
|
+
"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’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. > One or more DOD APL listed Local Session Controller’s (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’s 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",
|
|
326
|
+
"severity": "medium"
|
|
327
|
+
},
|
|
328
|
+
{
|
|
329
|
+
"id": "V-19597",
|
|
330
|
+
"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.",
|
|
331
|
+
"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’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs. > One or more DOD APL listed Local Session Controller’s (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’s mission. \n",
|
|
332
|
+
"severity": "medium"
|
|
333
|
+
},
|
|
334
|
+
{
|
|
335
|
+
"id": "V-19598",
|
|
336
|
+
"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).",
|
|
337
|
+
"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",
|
|
338
|
+
"severity": "medium"
|
|
339
|
+
},
|
|
340
|
+
{
|
|
341
|
+
"id": "V-19599",
|
|
342
|
+
"title": "One or more DOD APL listed Local Session Controller’s (LSCs) or Multi-Function Soft Switch (MFSS) are not implemented within the enclave for DISN IPVS session control.",
|
|
343
|
+
"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’s perimeter or premise router as designated by the Network Infrastructure and Enclave STIGs.\n> One or more DOD APL listed Local Session Controller’s (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’s 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",
|
|
344
|
+
"severity": "medium"
|
|
345
|
+
},
|
|
346
|
+
{
|
|
347
|
+
"id": "V-19600",
|
|
348
|
+
"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.",
|
|
349
|
+
"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’s 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. “Data” 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: “One 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.” \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: “Since 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.” \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",
|
|
350
|
+
"severity": "medium"
|
|
351
|
+
},
|
|
352
|
+
{
|
|
353
|
+
"id": "V-19601",
|
|
354
|
+
"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.",
|
|
355
|
+
"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’s 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.",
|
|
356
|
+
"severity": "medium"
|
|
357
|
+
},
|
|
358
|
+
{
|
|
359
|
+
"id": "V-19602",
|
|
360
|
+
"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.",
|
|
361
|
+
"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. ",
|
|
362
|
+
"severity": "medium"
|
|
363
|
+
},
|
|
364
|
+
{
|
|
365
|
+
"id": "V-19603",
|
|
366
|
+
"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.",
|
|
367
|
+
"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’s 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 “the big yellow fiber-finder” (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. ",
|
|
368
|
+
"severity": "medium"
|
|
369
|
+
},
|
|
370
|
+
{
|
|
371
|
+
"id": "V-19604",
|
|
372
|
+
"title": "Critical network equipment must be redundant and in geographically diverse locations for a site supporting C2 users.",
|
|
373
|
+
"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 Customer Edge Router (CER) connected to a single Session Border Controller (SBC). The reliability, redundancy, and robustness of the CER, SBC, and power source are subverted when the facility represents a single point of failure. For a small number of C2 users this may be less concerning but with more C2 users supported by the system, the greater the issue. Even less severe eventualities may limit the capability of the system to support reliable communications. \n\nThe 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, SBCs, and core LAN equipment. Session controllers can also be separated in this manner. This mitigation 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 consideration should be access to emergency services via the communications system would also be lost. \n\nThe threat to strategic facilities is greater from natural causes than from damage due to acts of war or terrorism. However, all threats must be considered. Tactical facilities have a higher vulnerability to acts of war, on a par with or exceeding the vulnerability posed by natural events.",
|
|
374
|
+
"severity": "low"
|
|
375
|
+
},
|
|
376
|
+
{
|
|
377
|
+
"id": "V-19606",
|
|
378
|
+
"title": "Enclaves with commercial VoIP connections must be approved by the DoDIN Waiver Panel and signed by DOD CIO for a permanent alternate connection to the Internet Telephony Service Provider (ITSP).",
|
|
379
|
+
"description": "The DoD requires the use of DISN services as the first choice to meet core communications needs. When additional services for SIP trunks are necessary, an ITSP may provide an “alternate connection” but this requires approval by the DoDIN Waiver Panel and signature by the DoD CIO. Local ISP connections provide an Internet pathway into the DISN, placing the DoDIN directly at risk for exploitation. A local ISP connection can circumnavigate DoD protections of the DISN at its boundaries with the Internet. Using commercial VoIP service from an ITSP requires the implementation of an internet service provider (ISP) connection, potentially providing a path to the Internet. These types of connections must be approved and must meet the requirements in the Network Infrastructure STIG (NET0160) for an Internet Access Point (IAP).\n\nITSP connections may provide SIP trunks terminating on a media gateway, which then provides TDM trunks or POTS lines to traditional non-VoIP PBX, key system, or individual end instrument. ITSP connections terminating in a separate LAN from the enclave’s DoD LAN may support a separate VoIP system. This connection type might be used for a small site having a small VoIP system or a few discrete phones dedicated to commercial network calling. \n\nAdditional guidance for the selection and procurement of telecommunications services is discussed in the DoDI 8100.4 \"DoD Unified Capabilities (UC)\" dated 9 Dec 2010 and the DoD Unified Capabilities Requirements 2013 (UCR 2013) documents.",
|
|
380
|
+
"severity": "medium"
|
|
381
|
+
},
|
|
382
|
+
{
|
|
383
|
+
"id": "V-19627",
|
|
384
|
+
"title": "Remote access VoIP must be routed to the VoIP VLAN.",
|
|
385
|
+
"description": "In addition to complying with the STIGs and VPN requirements for remotely connected PCs, there is an additional requirement for Unified Capabilities (UC) soft client and UC applications using the VPN. UC soft client and UC application traffic which must interact or communicate with systems and devices in the voice VLAN/protection zone must be routed to that zone while the other data and communications traffic is routed to the data zone. This is to be accomplished without degrading the separation of these two zones, or bridging them together. This can be accomplished in a number of ways depending upon the LAN and its boundary/VPN architecture.",
|
|
386
|
+
"severity": "medium"
|
|
387
|
+
},
|
|
388
|
+
{
|
|
389
|
+
"id": "V-19651",
|
|
390
|
+
"title": "When 802.1x is implemented and the voice video endpoint PC ports are disabled, the network access switch port must be configured to support a disabled PC port by configuring PC port traffic to the unused VLAN.",
|
|
391
|
+
"description": "A voice video endpoint that provides a PC port typically breaks 802.1x LAN access control mechanisms. The cause is the network access switch port is enabled or authorized (and configured) when the voice video endpoint authenticates to the network and is authorized to operate. This may permit whatever is connected to the PC port to have access to the LAN even if it is not authorized or uses 802.1x. Therefore, the practice of daisy chaining devices on a single LAN drop protected by 802.1x must be prohibited unless certain mitigating circumstances exist or are configured. \n\nIn the event a PC port is provided, the mitigation is to disable the port. However, the 802.1x implementation must install the configuration on the network access switch port required to support a voice video endpoint with a disabled PC port. This means the required configuration for the network access switch ports is to configure the appropriate VLAN for the voice video traffic and configure the unused VLAN for the disabled PC port.",
|
|
392
|
+
"severity": "medium"
|
|
393
|
+
},
|
|
394
|
+
{
|
|
395
|
+
"id": "V-19652",
|
|
396
|
+
"title": "The appropriate number of pre-authorized MAC addresses must be statically assigned for the pre-authorized voice video endpoints, to include daisy-chained devices, or the maximum number of MAC addresses dynamically learned on each access switch port must be limited to the minimum number of supported devices authorized to connect.",
|
|
397
|
+
"description": "Use of port security is required on network access switch ports. One method is MAC-based port security limiting the number of devices that can connect from an endpoint to a network access switch port. Allowing too many MAC addresses on a switch port could allow a hub or switch to be inserted into the voice VLAN port or PC/data port on a voice video endpoint, which allows additional unauthorized devices or workstations to be connected. \n\nVoice video endpoints in the workspace where installed are provisioned with enough LAN drops to support the number of devices to be used in the workspace. This also requires that each LAN drop that is to be used must be connected to a network access switch port. The best practice is to limit the devices permitted to connect to any given LAN drop/switch port combination to one. The two methods to do this are static mapping and MAC-based port security. Static mapping the MAC address of a pre-authorized device into the configuration of the network access switch port requires manual configuration. The MAC-based port security, also known as sticky-MAC, in which the MAC address of the first device to connect to the switch port is learned and added to the configuration. This becomes the authorized device. Sticky-MAC requires that care be exercised regarding what device is connected to a port for the first time. In both cases an alarm will be generated if an unauthorized device is connected. \n\nMany voice video endpoints provide an extra Ethernet port called a PC port that permits the endpoint and another device to share the same LAN drop. This has several advantages. First, a voice video endpoint can be added to a LAN without having to run additional cable or activate additional LAN drops. It is possible to share a single LAN drop with a hardware voice video endpoint, a desktop video conference endpoint, and computer. \n\nAnother initiative where a single LAN drop is shared is hot desking, where several people are assigned to work at the same desk at different times, each with their own laptop computer. In this case, a different MAC address needs to be permitted for each laptop that is supposed to connect to the LAN drop in the workspace. Additionally, this workspace could contain a single phone used by all assignees and the PC port on it might be the connection for their laptop.",
|
|
398
|
+
"severity": "medium"
|
|
399
|
+
},
|
|
400
|
+
{
|
|
401
|
+
"id": "V-19654",
|
|
402
|
+
"title": "The 802.1x authentication server must place voice video traffic in the correct VLAN when authorizing LAN access for voice video endpoints.",
|
|
403
|
+
"description": "802.1x has the capability of configuring the network access switch port to assign a VLAN or apply filtering rules based upon the device that was just authenticated. This is done via the “success” message sent from the authentication server back to the authenticator. General VVoIP and video conferencing requirements dictate that traffic from these devices is to be separated from the general LAN traffic and workstations by VLAN and IP address separation or segregation. An implementation of 802.1x within the LAN must support this requirement. As such, the authentication server must provide the LAN switch with the proper VLAN configuration depending upon the device that is authenticated. \n\nFor example, if all LAN ports are configured to use 802.1x LAN access control, and (as the typical case would be) are configured as disabled until a device authenticates, each port must support the authentication of a general workstation (a data device) or voice video endpoints. \n\nIf a workstation authenticates, the switch port must be configured with the data VLAN. If a VVoIP endpoint authenticates, the switch port must be configured with the VVoIP VLAN. Video conference endpoints must be similarly configured. \n\nIf a VVoIP endpoint that contains a PC port authenticates, the switch port must be configured with the VVoIP VLAN to receive the VVoIP traffic AND must be configured with the data VLAN to receive traffic from the PC port. Alternately, the switch port must be preconfigured for whatever device is expected to connect while in standby and implement the configuration when activated. The latter, however, is not how this is typically configured.",
|
|
404
|
+
"severity": "medium"
|
|
405
|
+
},
|
|
406
|
+
{
|
|
407
|
+
"id": "V-21506",
|
|
408
|
+
"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. ",
|
|
409
|
+
"description": "Backup/COOP or emergency telephones are useless if they don’t 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’s 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",
|
|
410
|
+
"severity": "low"
|
|
411
|
+
},
|
|
412
|
+
{
|
|
413
|
+
"id": "V-21507",
|
|
414
|
+
"title": "Mitigations against data exfiltration via the voice and/or video communications network/system have not been implemented",
|
|
415
|
+
"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’s 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’s 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’s 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",
|
|
416
|
+
"severity": "medium"
|
|
417
|
+
},
|
|
418
|
+
{
|
|
419
|
+
"id": "V-21508",
|
|
420
|
+
"title": "The Fire and Emergency Services (FES) communications over a sites telephone system must be configured to support the Department of Defense (DoD) Instruction 6055.06 telecommunication capabilities.",
|
|
421
|
+
"description": "Emergency communications must include requests for fire, police, and medical assistance. In DoD, these communications can also include requests for Aircraft Rescue and Fire Fighting (ARFF), explosive ordnance disposal, and similar emergency situations specific to the military. The inability of first responders to automatically locate the caller threatens life safety and facility protection or security. Contacting 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. \n\nDoD Instruction 6055.06, DoD Fire and Emergency Services (F&ES) Program, provides DoD policy regarding emergency services and emergency services communications. The document primarily discusses fire protection, with specific provisions for telecommunications support for fire, medical, and security emergencies. Private telephone systems, in general, provide a large portion of the required telecommunication capability. All DoD private telephone systems, VoIP or traditional must support enhanced emergency services communications for the completion of emergency calls. Per DoD Instruction 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 telephone system. Examples of such numbers are as follows: \n- 911 in North America \n- 112 in the EU and UK \n- 000 in Australia \n\nIssues may arise when an emergency call is originated through a private telephone 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. 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. \n\nEnhanced F&ES communications are mandated by the FCC and state legislation. Current implementation is a best practice. The enhanced F&ES communications capability is enabled using Automatic Number Identification (ANI) and Phone Switch Automatic Location Identification (PS-ALI) information. ANI provides the telephone number of the calling party and is generated by the telephone system. PS-ALI associates the calling party’s number (ANI information) with their location or registered address of the phone being used. PS-ALI is provided by a database maintained within the telephone system or externally. In many cases, the F&ES answering service system will use the PS-ALI information to map the location of the calling phone. 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 telephone system. When a private telephone system supports enhanced F&ES telecommunications, a PS-ALI database must be instituted, maintained, and kept current as endpoints and numbers move at a site. \n\nNOTE: For fire and emergency services, the requirements are for the site. The requirement must be met through the unclassified system. Classified systems at the site, because they only operate in secure areas without connection to public services, do not need to implement this requirement.\n\nReferences: \nDoD Instruction No. 6055.06, DoD Fire and Emergency Services (F&ES) Program, dated 21 Dec 2006",
|
|
422
|
+
"severity": "medium"
|
|
423
|
+
},
|
|
424
|
+
{
|
|
425
|
+
"id": "V-21509",
|
|
426
|
+
"title": "The Fire and Emergency Services (FES) communications over a sites private telephone system must provide the originating telephone number to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) or Automatic Location Identification (ALI) information.",
|
|
427
|
+
"description": "The implementation of Enhanced F&ES telecommunications services requires that the emergency services answering point or call center be able to automatically locate the calling party in the event they are unable provide their location themselves. This is a two part process. First the telephone system must be able to provide the answering station with the telephone number from which the emergency call originated. This is Automatic Number Identification (ANI) information. The second step in the process is that this phone number must be correlated to a physical address or location. This is called Automatic Location Identification (ALI) information. ANI information comes from the telephone system controller. ALI information may come from an external database that associates the ANI information to the ALI information or the telephone system controller may maintain the ALI database internally. If the ALI database is internal to the telephone system controller, emergency services answering point or call center only needs to receive ALI information providing it contains the originating telephone number.\n\nFor enterprise systems, the support for E911 by the enterprise LSC (or any remote LSC construct) is governed by FCC rules, as well as other federal, state, and local law. The design and implementation of all telephone system systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.",
|
|
428
|
+
"severity": "medium"
|
|
429
|
+
},
|
|
430
|
+
{
|
|
431
|
+
"id": "V-21510",
|
|
432
|
+
"title": "The Fire and Emergency Services (FES) communications over a sites private telephone system must provide a direct callback telephone number and physical location of an FES caller to the emergency services answering point or call center through a transfer of Automatic Number Identification (ANI) and extended Automatic Location Identification (ALI) information or access to an extended ALI database.",
|
|
433
|
+
"description": "Under FCC rules and the laws of some states, the implementation of Enhanced F&ES telecommunications services requires that the emergency services answering point or call center must be automatically provided with enough location information so that emergency services personnel can locate the calling party within a specified radius at their exact location in the event they are unable provide their location themselves. This is a two-part process that is exacerbated if the call originates from a DoD telephone system). Some of the FCC rules and state laws address the telephone system issue. For enterprise systems, the support for E911 by the enterprise LSC (or any remote LSC construct) is governed by FCC rules, as well as other federal, state, and local law. The design and implementation of all telephone system systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.\n\nPublic enhanced F&ES systems are implemented in conjunction with the local exchange carrier (LEC) using their central office switch (CO). When the designated F&ES number is dialed, the CO routes the call to the public F&ES answering point (PSAP) over special trunks that can provide the PSAP with the telephone number from which the emergency call originated and the geographic location of the originating telephone. The originating telephone number is provided as Automatic Number Identification (ANI) information. The geographic location of the originating telephone is provided as Automatic Location Identification (ALI) information. The ALI is generated from the ANI by looking up the ANI in a database. Typically this function is performed by the LEC and the ALI provided is the service delivery address for the telephone number. In some cases the ALI information is housed in a database at the PSAP or a at a third party provider such that the PSAP must make the “database dip” to identify the location of the caller. The information is regularly updated by the LEC based on new service deliveries and disconnections.\n\nThis process does not go far enough if the originating telephone is behind (part of) a DoD telephone system. A DoD telephone system may serve a large building or may serve multiple buildings in a campus setting. It may also serve small or large remote sites that are geographically distant from the main telephone system switch. As discussed above, the normal process provides the address where the LEC delivers its phone service for the calling number. While this address will serve to get emergency services personnel to the lobby of a building or the front gate of a campus, it will not provide the exact location of the caller. This is where the federal and state telephone system related requirements come in. Under these rules, a telephone system operator and the system itself must provide complete ANI and ALI information to the answering point such that emergency services personnel can easily locate the caller. As such the telephone system must provide the exact location of the originating telephone minimally within a reasonably small area of it. The location information provided for telephones behind a telephone system is called Phone Switch-ALI (PS-ALI). \n\nTo implement this, the telephone system must first be able to provide the F&ES answering station with the telephone number from which the emergency call originated via ANI. If the answering point is outside the telephone system, the number provided must be the exact Direct Inward Dialing (DID) number of the telephone placing the call so that the answering point can dial it directly. The number provided must not be that of an outbound trunk. Secondly, this phone number must be correlated to its physical address or location within the facility via PS-ALI. \n\nTo implement PS-ALI, the owner/operator of a telephone system is responsible for maintaining an up-to-date database containing the telephone number (DID number and/or extension number) and physical location of each telephone attached to the telephone system. This database is then used to provide the PS-ALI information to the ALI database(s) accessed by the F&ES answering point. In association with each telephone and telephone number in the telephone system, the PS-ALI information contained in the database includes the following: \n- The address of the site containing the telephone system unless provided to the answering point by the LEC as part of its ANI/ALI information.\n- The name (or number) of the building in which the telephone is located.\n- The address of the building in which the telephone is located.\n- The floor in the building on which the telephone is located.\n- The area or quadrant of the floor where the telephone is located.\n- The room or cube number where the telephone is located.\n\nAdditional information should be provided to the F&ES answering point and emergency services personnel in the form of up-to-date facility maps and floor plans. The maintenance of facility maps, floor plans, and PS-ALI information to keep them up-to-date is critical to life safety and facility protection and security. This can be an onerous process in light of changes in the facility and moves, adds, and changes within the telephone system. Maintaining accurate location information is exacerbated in a VoIP telephone system due to the ability of an IP phone to change its physical location within the LAN (and possibly beyond) while keeping its telephone number without specific intervention from, or knowledge of the telephone system operator. As such the PS_ALI database can quickly become inaccurate. A situation that could be life threatening. \n\nAutomated systems can be used with a VoIP system and LAN to identify the general location of an IP phone within the facility based on the LAN switch and port to which the phone is connected. Once this information is obtained from the LAN, it is correlated with the documented location of the LAN switch and documented location of the outlet served by the switchport.",
|
|
434
|
+
"severity": "medium"
|
|
435
|
+
},
|
|
436
|
+
{
|
|
437
|
+
"id": "V-21512",
|
|
438
|
+
"title": "The Fire and Emergency Services (FES) communications over a sites private telephone system must route emergency calls as a priority call in a non-blocking manner.",
|
|
439
|
+
"description": "When calling the designated F&ES telephone number, the call must go through regardless of the state of other calls in the system. As such, emergency calls must be treated as a priority call by the system. \n\nFor enterprise systems, the support for E911 by the Enterprise LSC (or any remote LSC construct) is governed by FCC rules, as well as other federal, state, and local law. The design and implementation of all telephone systems must include reasonable efforts to provide E911, even when the access connection to the Enterprise LSC is severed.",
|
|
440
|
+
"severity": "medium"
|
|
441
|
+
},
|
|
442
|
+
{
|
|
443
|
+
"id": "V-21516",
|
|
444
|
+
"title": "Eight hours of backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support special-C2 users.",
|
|
445
|
+
"description": "Unified Capabilities (UC) users require different levels of capability depending upon command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power.\n\nInterrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering uninterruptible power supply (UPS) power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. As such, all elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.",
|
|
446
|
+
"severity": "medium"
|
|
447
|
+
},
|
|
448
|
+
{
|
|
449
|
+
"id": "V-21521",
|
|
450
|
+
"title": "Unnecessary PPS have not been disabled or removed from VVoIP system devices or servers.",
|
|
451
|
+
"description": "The availability of applications and services that are not necessary for the OAM&P of the VVoIP system’s 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",
|
|
452
|
+
"severity": "medium"
|
|
453
|
+
},
|
|
454
|
+
{
|
|
455
|
+
"id": "V-21522",
|
|
456
|
+
"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.",
|
|
457
|
+
"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’s 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’s 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’s 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",
|
|
458
|
+
"severity": "low"
|
|
459
|
+
},
|
|
460
|
+
{
|
|
461
|
+
"id": "V-21523",
|
|
462
|
+
"title": "The VVoIP system time is not properly implemented and/or synched with the LAN’s NTP servers. ",
|
|
463
|
+
"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’S 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",
|
|
464
|
+
"severity": "medium"
|
|
465
|
+
},
|
|
466
|
+
{
|
|
467
|
+
"id": "V-47735",
|
|
468
|
+
"title": "VVoIP endpoint configuration files transferred via Cisco TFTP must be encrypted and signed using DoD PKI certificates.",
|
|
469
|
+
"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 “CISCO-UCM-TFTP” 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.",
|
|
470
|
+
"severity": "medium"
|
|
471
|
+
},
|
|
472
|
+
{
|
|
473
|
+
"id": "V-47753",
|
|
474
|
+
"title": "Unencrypted and unsigned VVoIP endpoint configuration files traversing the DISN must be protected within a VPN between enclaves.",
|
|
475
|
+
"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.",
|
|
476
|
+
"severity": "medium"
|
|
477
|
+
},
|
|
478
|
+
{
|
|
479
|
+
"id": "V-54691",
|
|
480
|
+
"title": "VVoIP system components and UC soft clients must display the Standard Mandatory DoD Notice and Consent Banner exactly as specified prior to logon or initial access.",
|
|
481
|
+
"description": "The operating system and remotely accessed information systems are required to display the DoD-approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. \n\nSystem use notification messages must be displayed when individuals log in to the information system. The approved DoD text must be used as specified in the DoD Instruction 8500.01 dated March 14, 2014.",
|
|
482
|
+
"severity": "low"
|
|
483
|
+
},
|
|
484
|
+
{
|
|
485
|
+
"id": "V-54693",
|
|
486
|
+
"title": "VVoIP system components and UC soft clients Standard Mandatory DoD Notice and Consent Banner must be acknowledged by the user prior to logon or initial access.",
|
|
487
|
+
"description": "The operating system and remotely accessed information systems are required to display the DoD-approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. \n\nSystem use notification messages must be displayed when individuals log in to the information system. The approved DoD text must be used as specified in the DoD Instruction 8500.01 dated March 14, 2014.",
|
|
488
|
+
"severity": "low"
|
|
489
|
+
},
|
|
490
|
+
{
|
|
491
|
+
"id": "V-57951",
|
|
492
|
+
"title": "Two hours of backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support Immediate or Priority precedence C2 users.",
|
|
493
|
+
"description": "Unified Capabilities (UC) users require different levels of capability depending upon command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power.\n\nInterrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering UPS power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPS systems, communications availability is reduced. As such, all elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.",
|
|
494
|
+
"severity": "medium"
|
|
495
|
+
},
|
|
496
|
+
{
|
|
497
|
+
"id": "V-57953",
|
|
498
|
+
"title": "Sufficient backup power must be provided for LAN Infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints to support non-C2 user accessible endpoints for emergency life-safety and security calls.",
|
|
499
|
+
"description": "Unified Capabilities (UC) users require different levels of capability depending upon command and control needs. Special-C2 decision makers requiring Flash or Flash Override precedence must have eight hours of continuous backup power at all times. C2 users requiring Immediate or Priority precedence must have two hours of continuous backup power.\n\nInterrupting any of the routing or switching infrastructures will disrupt VVoIP service. If the infrastructure is interrupted, command and control communications are disrupted, preventing critical communications from occurring. When implementing a VVoIP system without considering UPS system power needs for the VVoIP controllers and endpoints as well as the entire LAN, and supporting those needs with UPSs, communications availability is reduced. As such, all elements of the LAN infrastructure, WAN boundary, VVoIP infrastructure, and VVoIP endpoints directly supporting users with precedence needs must be provided with sufficient backup power to meet availability requirements. This reduction in availability threatens facility and personal security and safety as well as life safety during a power failure.",
|
|
500
|
+
"severity": "low"
|
|
501
|
+
},
|
|
502
|
+
{
|
|
503
|
+
"id": "V-61319",
|
|
504
|
+
"title": "The VVoIP endpoint configuration files must not be downloaded automatically during endpoint registration.",
|
|
505
|
+
"description": "During VVoIP endpoint registration with the session controller, a file is downloaded by the endpoint from the session manager containing specific configuration settings. This file contains the phone number assigned to the endpoint, the IP addresses for session management, the software menus specific to the system, the endpoint configuration password, the stored personal preferences and speed dial numbers, and other system operational information. These configuration settings can be updated by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded.\n\nAutomatic download of VVoIP endpoint configuration files during registration allows rogue endpoints to become part of the system. It also potentially allows human readable configuration files to be sent without encryption or digital signatures.",
|
|
506
|
+
"severity": "medium"
|
|
507
|
+
},
|
|
508
|
+
{
|
|
509
|
+
"id": "V-61321",
|
|
510
|
+
"title": "The VVoIP system management network with a single device providing bidirectional enclave boundary protection between the local management network and the DISN voice services management network must have a Memorandum of Agreement (MoA) in effect.",
|
|
511
|
+
"description": "VVoIP core system devices and Time Division Multiplexer (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’s 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. 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. Enclaves are defined as 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’s ADIMSS network, the RTS EMS, and the DISN DCN are different enclaves. Therefore, minimally a firewall is required where these enclaves meet.",
|
|
512
|
+
"severity": "low"
|
|
513
|
+
},
|
|
514
|
+
{
|
|
515
|
+
"id": "V-61323",
|
|
516
|
+
"title": "The VVoIP system management network bidirectional enclave boundary protection between the local management network and the DISN voice services management network must have ACLs permitting only specific inbound/outbound traffic and deny all other traffic.",
|
|
517
|
+
"description": "VVoIP core system devices and Time Division Multiplexer (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’s 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. 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. Enclaves are defined as 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’s ADIMSS network, the RTS EMS, and the DISN DCN are different enclaves. Therefore, minimally, a firewall is required where these enclaves meet.",
|
|
518
|
+
"severity": "low"
|
|
519
|
+
},
|
|
520
|
+
{
|
|
521
|
+
"id": "V-61325",
|
|
522
|
+
"title": "The VVoIP system management network bidirectional enclave boundary protection between the local management network and the DISN voice services management network must be scanned to confirm protections in place are effective.",
|
|
523
|
+
"description": "VVoIP core system devices and Time Division Multiplexer (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’s 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. 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. Enclaves are defined as 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’s ADIMSS network, the RTS EMS, and the DISN DCN are different enclaves. Therefore, minimally, a firewall is required where these enclaves meet.",
|
|
524
|
+
"severity": "low"
|
|
525
|
+
},
|
|
526
|
+
{
|
|
527
|
+
"id": "V-79051",
|
|
528
|
+
"title": "Video conferencing, Unified Capability (UC) soft client, and speakerphone speaker operations policy must prevent disclosure of sensitive or classified information over non-secure systems.",
|
|
529
|
+
"description": "Speakers used with Voice Video systems and devices may be heard by people and microphones with no relationship to the conference or call in progress. In open areas, conference audio may be overheard by others in the area without a need-to-know. \n\nA policy must be in place and enforced regarding the placement and use of speakers connected to secure Voice Video systems (video conferencing, EVoIP, ECVoIP, etc.) and secure Voice Video endpoints (STU-III, STE, etc.) located in areas or rooms where classified meetings, conversations, or work normally occur. The policy must be in accordance with NSA and DCI guidance and address, at a minimum, the following:\n- Location if instruments must be limited to sole-use offices, conference rooms, and similar areas that afford sound attenuation.\n- Notification to all room occupants of the use of the speaker.\n- Notification to all room occupants for awareness of the classification of conversations taking place.\n- The room occupant assuming responsibility for taking the necessary precautions to ensure that the classified discussion is not overheard.\n- Secure Voice Video endpoints must be configured to prevent speaker enablement in the non-secure mode.\n\nSpeakerphone use on secure telecommunications systems requires special consideration regarding placement and operating policy. NSA S412 approves the installation/enablement of speakerphones on National Secure Telephone Systems (NSTS) and STU-III/STE instruments. The intent of speakerphone approval rests with the room occupant assuming responsibility for taking the necessary precautions to ensure that the classified discussion is not overheard by individuals outside the conversation who may not have a need-to-know for the information discussed and/or that the speakerphone will not pick up and transmit other classified conversations in the area that are not part of the call in progress.",
|
|
530
|
+
"severity": "medium"
|
|
531
|
+
},
|
|
532
|
+
{
|
|
533
|
+
"id": "V-8223",
|
|
534
|
+
"title": "The VVoIP system, its components, and/or changes to them are not included in the site’s enclave / LAN baseline documentation and Configuration & Accreditation documentation",
|
|
535
|
+
"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.",
|
|
536
|
+
"severity": "low"
|
|
537
|
+
},
|
|
538
|
+
{
|
|
539
|
+
"id": "V-8224",
|
|
540
|
+
"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.",
|
|
541
|
+
"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. ",
|
|
542
|
+
"severity": "medium"
|
|
543
|
+
},
|
|
544
|
+
{
|
|
545
|
+
"id": "V-8225",
|
|
546
|
+
"title": "Voice/Video Telecommunications infrastructure components (traditional TDM, VVoIP, or VTC) are not housed in secured or “controlled access” facilities with appropriate classification level or appropriate documented access control methods.",
|
|
547
|
+
"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 “wiring closets” 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: “Access 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.”\n",
|
|
548
|
+
"severity": "medium"
|
|
549
|
+
},
|
|
550
|
+
{
|
|
551
|
+
"id": "V-8227",
|
|
552
|
+
"title": "VVoIP system components within the LAN must have separate address blocks from those used by non-VVoIP system devices.\n \n",
|
|
553
|
+
"description": "VVoIP 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 networks be secured as tightly as possible to reduce the impact that an attack can have on either network. 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.",
|
|
554
|
+
"severity": "medium"
|
|
555
|
+
},
|
|
556
|
+
{
|
|
557
|
+
"id": "V-8230",
|
|
558
|
+
"title": "The VVoIP VLAN design for the supporting LAN must provide segmentation of the VVoIP service from the other services on the LAN and between the VVoIP components such that access and traffic flow can be properly controlled.",
|
|
559
|
+
"description": "An IPT system is built on an IP infrastructure based on layer 2 and layer 3 switches and routers, which comprise the network’s 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 through 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. ",
|
|
560
|
+
"severity": "medium"
|
|
561
|
+
},
|
|
562
|
+
{
|
|
563
|
+
"id": "V-8247",
|
|
564
|
+
"title": "Servers supporting the VVoIP and UC/UM telephony environment are not dedicated to telephony (VVoIP, UC, or UM) applications or their support.",
|
|
565
|
+
"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 “mission critical” 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. ",
|
|
566
|
+
"severity": "medium"
|
|
567
|
+
},
|
|
568
|
+
{
|
|
569
|
+
"id": "V-8248",
|
|
570
|
+
"title": "All applicable STIGs have NOT been applied to the VVoIP / unified communications core infrastructure assets. ",
|
|
571
|
+
"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 “mission critical” 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.",
|
|
572
|
+
"severity": "low"
|
|
573
|
+
},
|
|
574
|
+
{
|
|
575
|
+
"id": "V-8250",
|
|
576
|
+
"title": "DoD-to-DoD VVoIP traffic traversing any publicly accessible wide area network (i.e., Internet, NIPRnet) must use FIPS-validated encryption for unclassified traffic or NSA-approved encryption for classified traffic.",
|
|
577
|
+
"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 FIPS-validated site-to-site or client-to-site (remote access) VPN technologies mitigates the risk. The inherent NSA-approved site-to-site encryption employed for 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 an SDN, or close enough to it to be served by DoD-owned facilities, some portion of the access circuit will use 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.",
|
|
578
|
+
"severity": "high"
|
|
579
|
+
},
|
|
580
|
+
{
|
|
581
|
+
"id": "V-8253",
|
|
582
|
+
"title": "The stand alone or IP connected Voice mail system/server is not secured to applicable OS and DSN STIG guidance.",
|
|
583
|
+
"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",
|
|
584
|
+
"severity": "low"
|
|
585
|
+
},
|
|
586
|
+
{
|
|
587
|
+
"id": "V-8254",
|
|
588
|
+
"title": "IP connected Voice/Unified Mail servers have not been secured using all applicable general purpose application STIGs. ",
|
|
589
|
+
"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. ",
|
|
590
|
+
"severity": "medium"
|
|
591
|
+
},
|
|
592
|
+
{
|
|
593
|
+
"id": "V-8255",
|
|
594
|
+
"title": "Access to personal voice mail settings by the subscriber via an IP connection is not secured via encryption and/or web” server on the voicemail system is not configured in accordance with the “private web server” requirements in the Web Server STIG/Checklist. ",
|
|
595
|
+
"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’s 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’s dial-pad falls under the normal requirement for the encryption of VoIP signaling and media.\n\nIn the event the subscriber’s personal settings are accessible via a “web” connection using a browser on the subscriber’s desktop or phone, the connection must use HTTPS and TLS minimally to protect the user’s logon credentials. Additionally, the voicemail system/server, which provides this service via a web server application, must be configured in accordance with the “private web server” requirements in the Web Server STIG/Checklist.\n",
|
|
596
|
+
"severity": "medium"
|
|
597
|
+
},
|
|
598
|
+
{
|
|
599
|
+
"id": "V-8256",
|
|
600
|
+
"title": "VVoIP services over wireless IP networks must apply the Wireless STIG to the wireless service and endpoints.",
|
|
601
|
+
"description": "The incorporation of wireless technology into the VVoIP environment elevates many existing VVoIP concerns such as quality of service (QoS), network capacity, provisioning, architecture and security. Many government entities use mobile communication solutions that include wireless VVoIP and Unified Communications (UC) applications to meet critical needs for interoperability and flexibility. Smartphone vendors integrate Wi-Fi, Bluetooth, and mobile radio that transitions seamlessly for VVoIP and UC apps. 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. This encryption is in addition to the WLAN encryption required by the Wireless STIG and the endpoints must authenticate to the WLAN before being granted access. Another great concern for using wireless VVoIP communications services is reliability and availability when using the technology for critical C2 communications. Initiated calls 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.",
|
|
602
|
+
"severity": "low"
|
|
603
|
+
},
|
|
604
|
+
{
|
|
605
|
+
"id": "V-8257",
|
|
606
|
+
"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 “Retired APL” lists.",
|
|
607
|
+
"description": "DoD Instruction 8100.3 governs DoD telecommunications, the Defense Switched Network (DSN), and the Defense RED Switched Network (DRSN), and requires that “Telecommunications 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).” 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. ",
|
|
608
|
+
"severity": "medium"
|
|
609
|
+
},
|
|
610
|
+
{
|
|
611
|
+
"id": "V-8288",
|
|
612
|
+
"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).",
|
|
613
|
+
"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",
|
|
614
|
+
"severity": "medium"
|
|
615
|
+
},
|
|
616
|
+
{
|
|
617
|
+
"id": "V-8290",
|
|
618
|
+
"title": "An inventory of authorized instruments is NOT documented or maintained in support of the detection of unauthorized instruments connected to the VoIP system.",
|
|
619
|
+
"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, “moves, adds, and changes” 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. ",
|
|
620
|
+
"severity": "medium"
|
|
621
|
+
},
|
|
622
|
+
{
|
|
623
|
+
"id": "V-8294",
|
|
624
|
+
"title": "The VVoIP system DHCP server is not dedicated to the VVoIP system within the LAN. ",
|
|
625
|
+
"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",
|
|
626
|
+
"severity": "low"
|
|
627
|
+
},
|
|
628
|
+
{
|
|
629
|
+
"id": "V-8295",
|
|
630
|
+
"title": "Customers of the DISN VoSIP service on ARE NOT utilizing address blocks assigned by the DRSN / VoSIP PMO.",
|
|
631
|
+
"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’s 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’s 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’s 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",
|
|
632
|
+
"severity": "low"
|
|
633
|
+
},
|
|
634
|
+
{
|
|
635
|
+
"id": "V-8302",
|
|
636
|
+
"title": "The LAN supporting VVoIP services for command and control (C2) users must provide assured services in accordance with the Unified Capabilities Requirements (UCR).",
|
|
637
|
+
"description": "Voice services in support of high priority military command and control precedence must meet minimum requirements for reliability and survivability of the supporting infrastructure. Design requirements for networks supporting DoD VVoIP implementations are in the UCR, specifying assured services supporting DoD IP based voice services. The UCR defines LAN design requirements for redundancy of equipment and interconnections, minimum requirements for bandwidth, specifications for backup power, and the maximum number of endpoints tolerable by a single point of failure. Policy sets the minimum requirements for the availability and reliability of VVoIP systems Special-C2 users is 99.999%, C2 users is 99.997%, C2Routine only users (C2R) and non-C2 users is 99.9%.",
|
|
638
|
+
"severity": "low"
|
|
639
|
+
},
|
|
640
|
+
{
|
|
641
|
+
"id": "V-8306",
|
|
642
|
+
"title": "A hardware based VVoIP or VTC endpoint possesses or provides a “PC Port” but does not maintain the required VLAN separation through the implementation of an Ethernet switch (not a hub).",
|
|
643
|
+
"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 “PC Port”. 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’s or VTU’s configurations or communications traffic. VAN separation helps to prevent this. NOTE: the switch or endpoint will typically utilize 802.1Q trunking (VLAN tagging) but may use some other means to separate voice and data traffic. Typically when 802.1Q VLAN tagging is used, the phone firmware tags the VoIP packets while the embedded switch passes all packets without modification. This permits devices connected to the PC port to tag their packets and assign the proper VLAN to their traffic type. 802.1Q VLAN tagging enables the LAN to better maintain separation of the traffic and is therefore the preferred method. ",
|
|
644
|
+
"severity": "medium"
|
|
645
|
+
},
|
|
646
|
+
{
|
|
647
|
+
"id": "V-8323",
|
|
648
|
+
"title": "The VVoIP VLAN ACL design must document the control of VVoIP system access and traffic flow.",
|
|
649
|
+
"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, “web” 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 “Procedure 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. ",
|
|
650
|
+
"severity": "medium"
|
|
651
|
+
},
|
|
652
|
+
{
|
|
653
|
+
"id": "V-8328",
|
|
654
|
+
"title": "The implementation of all VoIP systems in the local enclave must not degrade the enclaves perimeter protection due to inadequate design of the VoIP boundary and its connection to external networks.",
|
|
655
|
+
"description": "VoIP has the potential to significantly degrade the enclave boundary protection afforded by the required boundary firewall unless the firewall is designed to properly handle VoIP traffic. The typical firewall used to protect an enclave supporting data traffic is not capable of properly handling or supporting real-time communications (VoIP and video conferencing).\n\nSession Initiation Protocol (SIP) and related protocols used for call establishment and control rely on dedicated TCP ports that must be open inbound at all times to receive calls. Real-time Transfer Protocol (RTP) and Real-time Transfer Control Protocol (RTCP) use randomly assigned UDP ports in the range of 1025-65535 with four IP ports required for every bi-directional voice session. The number of ports is increased when video is added. The method of supporting VoIP through a standard data firewall is to open the signaling TCP ports and a broad range of UDP ports for the RTP/RTCP media streams. A data firewall does provide limited protection for VoIP implementations when inbound permit statements are restricted to specific address ranges. This is not possible if calls are to be permitted from any IP address on the Internet or NIPRNet. \n\nVoIP stateful firewalls and session border controllers, in parallel with the data firewall, provide the best protection for the enclave. Dynamically opening required UDP ports to permit the flow of the media, performing stateful inspection of UDP media packets and dropping all non-session packets, and then closing the UDP ports at the session’s end or after an inactivity timeout greatly increases enclave protection. This configuration provides the capability to decrypt the media streams for inspection and recording. This supports, for CALEA purposes, the monitoring and recording of calls that traverse the enclave boundary.\n\nWhen a VoIP system is a closed system, such as DISN classified networks, the entire address space of the WAN and connected enclaves is managed by a single system manager. In this instance, a specific limited and segregated address space may be assigned for all VoIP devices in use across the network. The risk to the enclave is limited when a standard firewall is used with inbound permit statements that are based on the segregated IP address range.\n\nFurthermore, when NAT is used, the VoIP stateful firewall or session border controller provide RFC 1918 internal private addressing, allowing RTP/RTCP packets to traverse the boundary. Although NAT is no longer required to be implemented, it is still a common security best practice.",
|
|
656
|
+
"severity": "high"
|
|
657
|
+
},
|
|
658
|
+
{
|
|
659
|
+
"id": "V-8329",
|
|
660
|
+
"title": "Without an applicable exception the site’s 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’s need to support C2 communications via the DSN.",
|
|
661
|
+
"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’s 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’s 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’s efforts to develop interoperable usage of the standards with vendor assistance. The use of a MG converts each vendor’s implementation to a common interoperable system, the TDM DSN. \n",
|
|
662
|
+
"severity": "medium"
|
|
663
|
+
},
|
|
664
|
+
{
|
|
665
|
+
"id": "V-8349",
|
|
666
|
+
"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’s instructions.",
|
|
667
|
+
"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’s 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 “fix” is to apply the original vendors patch or to upgrade to the “fixed” 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",
|
|
668
|
+
"severity": "medium"
|
|
669
|
+
}
|
|
670
|
+
]
|
|
671
|
+
}
|