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,263 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_voicevideo_over_internet_protocol_vvoip",
|
|
3
|
+
"date": "2017-04-05",
|
|
4
|
+
"description": "The Voice/Video over Internet Protocol (VVoIP) STIG includes the computing requirements for Voice/Video systems operating to support the DoD. The Voice/Video Services Policy STIG must also be applied 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 over Internet Protocol (VVoIP) STIG",
|
|
6
|
+
"version": "3",
|
|
7
|
+
"item_syntax": "^\\w-\\d+$",
|
|
8
|
+
"section_separator": null,
|
|
9
|
+
"items": [
|
|
10
|
+
{
|
|
11
|
+
"id": "V-19444",
|
|
12
|
+
"title": "Unified messaging and email text-to-speech features must be disabled because there is no PKI authentication and no access control to email.",
|
|
13
|
+
"description": "Unified messaging and email systems provide the capability to receive voicemails via email and in some cases, have emails read to the user via a text-to-speech feature when accessing the system from a telephone (dial-in). For DoD, this presents two issues or vulnerabilities. Access to voicemail from a telephone only requires the user’s telephone number and a PIN. The telephone number is the account or mailbox number on the voicemail system while the PIN is the user password for accessing the account. This is a rather weak authentication method. The first issue for DoD, is that DoD policy states that access to email requires PKI based authentication of the user before they are granted access to their email account. PKI certificates are required to decrypt encrypted email. PKI authentication is not available when using a standard telephone. While some organizations might implement PKI authenticated access to the site’s phone system, such a facility is not available via most DoD phone systems and certainly not via the PSTN. Additionally, while a non-PKI enabled text-to-speech feature would not be able to read encrypted email (which would be considered the most sensitive) the unencrypted email is still considered sensitive DoD information. The argument could be made that normal voicemail messages and regular telephone conversations can also contain sensitive information. However, there is typically more sensitive information in email. This does not apply to DoD issued PDA/PED devices that provide CAC authenticated access to email. Access to unified mail voicemail would be via PKI authenticated email service through which the user could listen to the voicemail. Text-to-speech conversion would be permitted in this case even though caution should be used when listening to any voicemail, particularly in a public place. The use of a wired earphone is highly recommended. The use of Bluetooth, DECT/DECT 6.0, and other RF wireless technologies for accessories must be approved.",
|
|
14
|
+
"severity": "medium"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"id": "V-19625",
|
|
18
|
+
"title": "PC presentation or application sharing capabilities are not properly limited.",
|
|
19
|
+
"description": "Visual collaboration often requires the sharing or display of presentations, open documents, and white board information to one or more communicating endpoints. While the technology for doing this is different between hardware based endpoints and PC based application endpoints, the vulnerability it creates is the same. In both cases, the displayed information typically resides on a PC. While in presentation/sharing mode, care must be exercised so that the PC user does not inadvertently display and transmit information on their workstation that is not part of the communications session and not intended to be viewed by the other communicating parties. Users must be aware that anything they display on their PC monitor while presenting to a communications session may be displayed on the other communicating endpoints. This is particularly true when the PC video output is connected to a VTC CODEC since the information will be displayed on all of the conference monitors. This presentation/sharing feature could result in the disclosure of sensitive or classified information to individuals that do not have a validated need-to-know or have the proper clearance to view the information. Thus, the presentation/sharing feature presents a vulnerability to other information displayed on the PC, if the feature is misused. This is a problem when sharing (displaying) a PC desktop via any collaboration tool using any connection method. There is little that can be done to mitigate this vulnerability other than to develop policy and procedures to present to collaborative communications sessions. All users that perform this function must have awareness of the issues and be trained in the proper operational procedures. Such procedures may require that there be no non-session related documents or windows open or minimized on the PC while presenting or sharing. An additional requirement may be that the user may not permit others in a session to remotely control their PC. A similar issue is that some PC based collaboration applications can permit a user to allow other session participants to remotely control their PC. Depending upon how this feature is implemented and limited, it could lead to undesired activities on the part of the person in control and possible compromise of information that is external to the collaboration session. This would be the case if such sharing or remote control provided access to the local hard drive and non session related applications or network drives accessible from the controlled PC. ",
|
|
20
|
+
"severity": "medium"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "V-19628",
|
|
24
|
+
"title": "VVoIP component(s) are NOT addressed using the defined dedicated VVoIP system addresses",
|
|
25
|
+
"description": "The protection of the VVoIP system is enhanced by ensuring all VVoIP systems and components within the LAN (Enclave) are deployed using separate address blocks from the normal data address blocks. This is one of the required steps required to help protect the VVoIP infrastructure and services by allowing traffic and access control via firewalls and router ACLs. \n\n",
|
|
26
|
+
"severity": "medium"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "V-19629",
|
|
30
|
+
"title": "VVoIP core components use random address assignment via DHCP and are not statically addressed",
|
|
31
|
+
"description": "Assigning static addresses to core VVoIP devices permits tighter control using ACLs on firewalls and routers to help in the protection of these devices.\n\nNOTE: In the event DHCP is used for address assignment, ensure the DHCP server assigns the same address to the core VVoIP device each time one is requested.",
|
|
32
|
+
"severity": "medium"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "V-19630",
|
|
36
|
+
"title": "VVoIP endpoints must receive IP address assignment and configuration information from a DHCP server dedicated to the VVoIP system.",
|
|
37
|
+
"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. Optimally, the design would place a DHCP server dedicated to providing IP address and configuration information to the VVoIP endpoints separate from the IP address and configuration information to data hosts (workstations etc.). The DHCP server providing VVoIP devices should be in the V_VUC domain having the same address space and VLAN to prevent DHCP requests routed onto the data environment that degrade the separation of the VVoIP environment and the data environment. With centralized management of DHCP (and other services, such as DNS) this separation is obviously eliminated. DHCP requests and responses for voice must reside on a segregated VLAN.\n \nThe best practice is to manually assign addresses when authorizing the instrument by generating its configuration file. 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).",
|
|
38
|
+
"severity": "medium"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "V-19631",
|
|
42
|
+
"title": "A VVoIP core system/device or a traditional TDM based telecom switch is acting as a network router in that it does not block traffic between its attached management network interfaces(s) (one or more; logical or physical) and/or its production network interface(s) (logical or physical).",
|
|
43
|
+
"description": "Based on a previously stated requirement, a VVoIP system must have one or more production VLANs containing the VVoIP endpoints and a separate OOB management network or virtual management network (management VLAN). Also previously stated is the requirement that the LAN NEs maintain the separation between management network(s) and the production network VLANs by blocking traffic from passing between them. Maintaining this separation is also incumbent upon the managed devices that are connected to both the management and production VLANs.\n\nIndividual VVoIP system core devices and traditional TDM based telecom switches connect to their production and management networks or VLANs in different ways. In some cases there are separate dedicated physical management and production interfaces. There may also be one or more physically separate management interfaces. On the other hand these interfaces may be logical or there may be some combination of logical and physical interfaces that support the required production and management traffic. In the event production and management connections use separate interfaces, whether logical or physical, the target/ managed device must not permit one network (physical or logical VLAN) to access another network through the device. That is, the device must not route IP traffic between logical or physical interfaces connected to different VLANs or physical networks that are part of a different logical security zone (protected VLAN) or physical network enclave.\n\nPermitting such routing permit a host on one network or VLAN to gain unauthorized access to a host on another network which can lead to complete corruption of the accessed system or device causing the, loss of availability (denial-of-service), integrity, and information or communications confidentiality.\n\nNOTE: While this specifically addresses a similar situation addressed in the Network Infrastructure STIG that essentially requires that the production side of a managed device must not be accessible from the management interface and vise versa, this requirement extends that requirement to multiple management interfaces. Many DSN switches and DISN IPVS system core devices are managed from the BCPS network and CCSA NOC via one interface and also monitored and potentially managed by the DISA ADIMSS or other NOC. These are separate enclaves which must be protected from inappropriate access between them. In some cases the connections from these enclaves to the managed devices are via separate interfaces on the managed devices. Ergo the requirement the managed device must not pass traffic between these interfaces.\n",
|
|
44
|
+
"severity": "medium"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "V-19632",
|
|
48
|
+
"title": "Logical or physical interfaces must be configured on the VVoIP core routing devices for the VVoIP core equipment to support access and traffic control for the VVoIP system components.",
|
|
49
|
+
"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.",
|
|
50
|
+
"severity": "medium"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "V-19634",
|
|
54
|
+
"title": "VLANs established for the VVoIP system are NOT pruned from trunks and/or interfaces that are not required to carry the VVoIP traffic",
|
|
55
|
+
"description": "While VLANs facilitate access and traffic control for the VVoIP system components and enhanced QoS, they should only be implemented on the network elements that are needed to carry the traffic from the attached devices. LAN switches will typically learn the VLANs configured on an adjacent switch and configure it locally. As such a VLAN configured on one switch can be learned and configured on the entire LAN in a very short period of time. Too many learned VLANs and a NE can crash. Additionally, a VLAN that appears on NEs where it is not required to carry traffic, places the VLAN at risk of compromise by presenting many more points at which the VLAN might be accessed. Therefore the VLANs must be pruned from trunks and interfaces where the VLAN does not need to send traffic. A VLAN that supports a number of local VVoIP endpoints only needs to traverse the NEs in two paths to the core routing devices at the VVoIP core equipment, Any specific endpoint VLAN does not need to appear on every switch in the LAN unless it serves endpoints everywhere on the LAN. Likewise the VVoIP core equipment VLANs do not need to extend past the VVoIP core routing devices (routers or layer 3 switches. The endpoint VLANs come to the core, the core VLANs do not extend to the endpoints. As such all VLANs must be pruned from any trunk where its traffic does not need to go. ",
|
|
56
|
+
"severity": "medium"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"id": "V-19635",
|
|
60
|
+
"title": "A deny-by-default ACL for VVoIP endpoint VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design. ",
|
|
61
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.",
|
|
62
|
+
"severity": "medium"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-19636",
|
|
66
|
+
"title": "A deny-by-default ACL for all VVoIP endpoint VLAN interfaces must be implemented on VVoIP non-core routing devices as defined in the VVoIP system ACL design. ",
|
|
67
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.",
|
|
68
|
+
"severity": "medium"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-19637",
|
|
72
|
+
"title": "A deny-by-default ACL for session manager VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design. ",
|
|
73
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and subnet, protocol type, and associated standard IP port for the protocol. In general, the ACLs mentioned are egress filters (referenced the router core) on the VLAN interfaces. Additionally, the routing devices should send an alarm in response to inappropriate traffic and log the occurrence. An example of this is an HTTP request sourced from the data VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.",
|
|
74
|
+
"severity": "medium"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-19638",
|
|
78
|
+
"title": "A deny-by-default ACL for media gateway VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design.",
|
|
79
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.",
|
|
80
|
+
"severity": "medium"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "V-19639",
|
|
84
|
+
"title": "A deny-by-default ACL for signaling gateway VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design. ",
|
|
85
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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.",
|
|
86
|
+
"severity": "medium"
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "V-19640",
|
|
90
|
+
"title": "A deny-by-default ACL for session border VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design. ",
|
|
91
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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 .",
|
|
92
|
+
"severity": "medium"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-19642",
|
|
96
|
+
"title": "A deny-by-default ACL for voicemail and unified messaging servers VLAN interfaces must be implemented on core routing devices as defined in the VVoIP system ACL design. ",
|
|
97
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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. ",
|
|
98
|
+
"severity": "medium"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"id": "V-19643",
|
|
102
|
+
"title": "A deny-by-default ACL for unified communications server VLAN interfaces must be implemented on core routing devices as defined in the VVoIP system ACL design. ",
|
|
103
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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 .",
|
|
104
|
+
"severity": "medium"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"id": "V-19644",
|
|
108
|
+
"title": "A deny-by-default ACL for system management VLAN interfaces must be implemented on VVoIP core routing devices as defined in the VVoIP system ACL design. ",
|
|
109
|
+
"description": "Router ACLs are required to control access and the flow of traffic to and from VVoIP system devices and their VLANs as a protection mechanism. In general, the defined ACLs are designed in a deny-by-default manner such that only the protocols and traffic that needs to reach the device or devices in the VLAN receive the packets. The ACLs filter on VLAN, IP address and 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 VLANs to the endpoint or media gateway VLANs. The primary purpose of ACL on all VVoIP VLAN interfaces is to block traffic to or from the data VLAN interfaces. 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. ",
|
|
110
|
+
"severity": "medium"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-19645",
|
|
114
|
+
"title": "The implementation of Unified Mail services degrades the separation between the voice and data protection zones (VLANs). ",
|
|
115
|
+
"description": "Voice mail services in a VoIP environment are available in several different configurations. A legacy voice mail platform can connect to a VoIP environment to provide voice mail services for VoIP users. In the same respect, a VoIP voice mail platform can provide voice mail services to the legacy voice users and the VoIP users. Some voice mail systems are also capable of providing unified mail by interacting with email messaging systems. Voicemails when recorded are converted to a .wav or similar digital audio file and sent to the email server as an attachment to an email. The subject line will typically contain the caller ID information if available. The email user can then open the attachment and listen to the voicemail on their PC or whatever device that provides properly authenticated access to the user’s email. \n\nSince the voicemail server must access the voice network (which, in a VoIP system is the VoIP VLAN system), and the data network (data VLANs) to send the email, caution and control must be exercised to not degrade the separation between the voice and data VLANs. Additionally, if the email server is part of or collocated with the voicemail server, user access to email must also not degrade the separation between the voice and data VLANs. Since this server may have 2 NICs and be connected to both voice and data VLANs, the server must not act as a bridge between the voice and data VLANs. \n\n",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-19646",
|
|
120
|
+
"title": "The LAN Access switch port is NOT configured to place the VVoIP or VTC traffic in the proper VLAN (e.g., the port is NOT assigned to the proper VLAN) or the port does not assign the appropriate VLAN tag via some other method. ",
|
|
121
|
+
"description": "Some VVoIP hardware endpoints and hardware based VTC endpoints contain a multi-port Ethernet switch to provide a connection on the endpoint for external devices such as a workstation (i.e., PC port). Additionally, some of these endpoints have the capability of defining the VLAN that their traffic will use via various methods but most typically by using 802.1Q trunking (VLAN tagging). However, some endpoints do not support VLAN assignment or cannot themselves maintain VLAN separation. In these cases, the responsibility of VLAN assignment and maintenance of VLAN separation falls to the LAN access switch (discrete NE or module in a larger NE) that supports the LAN cable drop to which the endpoint(s) is connected. Typically the LAN access switch port configurations contain a statement assigning the port to a specific VLAN. ",
|
|
122
|
+
"severity": "medium"
|
|
123
|
+
},
|
|
124
|
+
{
|
|
125
|
+
"id": "V-19647",
|
|
126
|
+
"title": "The LAN access switch (discrete NE or module in a larger NE) is NOT capable of, or is NOT configured to; maintain the required VLAN separation for traffic originating from supported endpoints and DOES NOT route voice, VTC, PC communications client, and data traffic to their respective VLANs on the LAN.",
|
|
127
|
+
"description": "Some VVoIP hardware endpoints and hardware based VTC endpoints contain a multi-port Ethernet switch to provide a connection on the endpoint for external devices such as a workstation (i.e., PC port). This is done so that a PC and a workstation can share a single network cable drop and LAN access layer switch port. The PC port can, in general, support any device requiring an Ethernet connection. In theory, a VoIP phone, a desktop VTC unit could be daisy chained on a single LAN drop. \n\nThese embedded multi-port Ethernet switches must be capable of maintaining the separation of the voice (VVoIP), data, VLANs as well as the VTC VLAN and PC Comm Client VLAN if present. For example the attached PC must not be able to directly access the phone’s or VTU’s configurations or communications traffic. VAN separation helps to prevent this.\n\nNOTE: the switch or endpoint will typically utilize 802.1Q trunking (VLAN tagging) but may use some other means to separate voice and data traffic. Typically when 802.1Q VLAN tagging is used, the phone firmware tags the VoIP packets while the embedded switch passes all packets without modification. This permits devices connected to the PC port to tag their packets and assign the proper VLAN to their traffic type. 802.1Q VLAN tagging enables the LAN to better maintain separation of the traffic and is therefore the preferred method.\n\nThe LAN access switch (discrete NE or module in a larger NE) must be capable of, and must be configured to, support the VLAN separation method used by the supported endpoints. The NE may perform this function in various ways as determined by the overall VVoIP system and LAN design. However, the typical (or preferred) method used by an endpoint to maintain VLAN separation is 802.1Q VLAN tagging. As such, the LAN access port and NE needs to support the receipt of tagged packets and handle them appropriately to also maintain VLAN separation. While the NE may retag the packets thereby reassigning the VLAN based on some defined rule, the NE may not strip the tags and mix all traffic together. Furthermore, The LAN access NE supporting LAN cable drops will typically have a VLAN defined for each service (VVoIP, VTC, Data, PC Comm. Client) supported by the endpoints connected to the NE. Traffic within the respective VLANs may flow between different physical ports on the NE but may not change VLANs in the process. This must be done by a routing device (discrete NE or module in a larger NE) and must be controlled by an appropriate ACL. The LAN access layer Ethernet switch may be combined in the same unit with the routing device as in the case of a layer-3 switch or a router containing an Ethernet switch module.\n\n",
|
|
128
|
+
"severity": "medium"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"id": "V-19648",
|
|
132
|
+
"title": "LAN access switchports supporting VVoIP or VTC endpoints containing a PC port are configured in trunk mode, NOT in access mode or “802.1Q tagged access mode.” ",
|
|
133
|
+
"description": "Policy regarding LAN access switchport mode has been established in the Network Infrastructure STIG by NET1416 which states “ensure trunking is disabled on all access ports (do not configure trunk on, desirable, non-negotiate, or auto—only off).” The reason for this is that a malicious user could affect a VLAN hopping attack. VLAN “hopping” occurs when a tagged frame destined for one VLAN is redirected to a different VLAN, threatening network security. The redirection can be initiated using two methods: “tagging attack” and “double encapsulation.” Frame tagging attacks allow a malicious user on a VLAN to get unauthorized access to another VLAN. For example, if a switch port’s trunk mode were configured as auto (enables a port to become a trunk if the connected switch it is negotiating trunking with has its state set to on or desirable) and were to receive a fake DTP packet specifying trunk on or desirable, it would become a trunk port and it could then start accepting traffic destined for all VLANs that belong to that trunk group. The attacker could start communicating with other VLANs through that compromised port—including the management VLAN. Insuring that trunk mode for any non-trunking port is configured as off can prevent this type of attack. Double encapsulation can be initiated by an attacker who has access to a switch port belonging to the native VLAN of the trunk port. Knowing the victim’s MAC address and with the victim attached to a different switch belonging to the same trunk group, thereby requiring the trunk link and frame tagging, the malicious user can begin the attack by sending frames with two sets of tags. The outer tag that is the attacker’s VLAN ID (probably the well known and omnipresent VLAN 1) is stripped off by the switch, and the inner tag that will have the victim’s VLAN ID is used by the switch as the next hop and sent out the trunk port. To ensure the integrity of the trunk link and prevent unauthorized access, the native VLAN of the trunk port should be changed from the default VLAN 1 to its own unique VLAN. NOTE: Trunk mode is typically used between LAN switches to extend defined VLANs across a network. This mode is used to interconnect LAN switches and routers with other LAN switches and routers to create a network across multiple NEs. Trunk mode generally requires each packet to be tagged with the VLAN ID that it belongs to. This tagging can follow the 802.1Q standard format or can use a vendor proprietary protocol such as Cisco’s ISL. Access mode on the other hand is used on a switchport that supports a connection to a LAN endpoint device. Typically single endpoint devices connected to a switchport send traffic that does not contain a VLAN tag. In this case, if a VLAN is defined for the endpoint, the switchport is statically assigned to a VLAN. As such, when a packet is received and sent out the “Trunk” the packet is tagged with the VLAN ID. Best practices dictate that the implementation of VVoIP on a network requires one or more VVoIP VLANs be established within the network. Therefore LAN access switchports that support VVoIP and VTC endpoints that do not tag or are capable but not configured to add a VLAN tag to their traffic must be statically assigned to the local VVoIP VLAN. VVoIP and VTC endpoints that do have the capability of adding the VLAN tag to their traffic typically use 802.1Q format and also typically support a PC port on the device. The PC port is added to the VVoIP or VTC endpoints since it reduces cabling and LAN infrastructure cost. Typically, VVoIP or VTC endpoints that support a PC port pass traffic from this port unchanged whether the traffic is tagged or not, while adding the VVoIP VLAN tag for the locally defined VVoIP VLAN to its VVoIP traffic. As such, a LAN access switchport must now support tagged and untagged traffic and keep the traffic separated. This is done by defining a default “data” VLAN (that is not the default VLAN on the NE such as VLAN 0 or 1) for the switchport in which untagged traffic is placed and defining a secondary VVoIP VLAN that matches the 802.1Q tag used for the VVoIP traffic. This method maintains the LAN access nature of the port even though it supports multiple VLANs while not requiring it to be configured as a trunk. ",
|
|
134
|
+
"severity": "medium"
|
|
135
|
+
},
|
|
136
|
+
{
|
|
137
|
+
"id": "V-19649",
|
|
138
|
+
"title": "LAN access switchport supporting a VVoIP or VTC endpoint that does not, or is not configured to, apply 802.1Q VLAN tags to its traffic is NOT statically assigned to the appropriate local VVoIP or VTC VLAN. ",
|
|
139
|
+
"description": "VVoIP or VTC endpoints that are not configured to or cannot provide a 802.1Q VLAN tag to its VVoIP traffic have no control over what VLAN their traffic ends up in, if any. Therefore the responsibility of placing VVoIP or VTC traffic in an appropriate VLAN for the type of traffic falls to the LAN switch. As such each switchport on a LAN NE that supports a VVoIP or VTC endpoint must place the traffic in the correct VLAN. This means that, in lieu of any other means to sort the traffic, each switchport must be statically assigned to the appropriate VLAN. \n\nNOTE: In some cases a LAN NE can use some other endpoint or traffic characteristic other than 802.1Q tagging to assign the traffic to the correct VLAN. \n",
|
|
140
|
+
"severity": "medium"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-19650",
|
|
144
|
+
"title": "A LAN access switchport supports a VVoIP or VTC endpoint containing a PC port but is not configured with a default “data” VLAN to handle untagged PC port traffic and assign a secondary VVoIP or VTC VLAN to handle the tagged VVoIP or VTC traffic.",
|
|
145
|
+
"description": "Many VVoIP and VTC endpoints provide a PC port on the device. Doing so permits a PC to share the same LAN drop as a VoIP phone or desktop VTC endpoint. The net effect is reduced installation and maintenance cost for the LAN infrastructure. Endpoints that provide a PC port have an embedded Ethernet switch which is required to support the separation of the PC data traffic from the VVoIP and VTC traffic. This is primarily accomplished by the embedded Ethernet switch in the endpoint supporting VLANs. In support of this, many VVoIP and VTC endpoints have the capability of adding a VLAN tag to their traffic using the 802.1Q format. Typically the PC port traffic is passed to the LAN unchanged whether the traffic is tagged or not, while adding the VVoIP VLAN tag for the locally defined VVoIP VLAN to its VVoIP traffic. \n\nNOTE: this is a limitation of the switchport access mode. It seems that configuring more than a default and tagged VLAN on a switchport requires the port to be set as a trunk, which is not permissible based on NET1416. This causes a limitation in the number of devices and applications that can be supported by a single switchport and LAN drop. For example, a single switchport will support a single VoIP phone (w/ an embedded switch and PC port) which tags its traffic and a connected PC that does not. Similarly, a single switchport will support a single VTC endpoint (w/ an embedded switch and PC port) which tags its traffic and a connected PC that does not. Similarly, a single switchport will support a single PC that supports a soft phone and tags its VoIP traffic while not tagging its data traffic (per the PCCC STIG). A single port will not support a VoIP phone and a VTC endpoint and a PC on a single drop unless the VTC endpoint also tags its VTC traffic with the VoIP VLAN. If a PC with a compliant soft phone is connected, it must also tag its traffic with the single VoIP VLAN tag. \n\nNOTE: Traffic to/from a VTC endpoint may use the same VLAN as the VVoIP phone system. Some exceptions may apply. NOTE: Do not use the default VLAN for the switch which is generally VLAN 1. This is used for LAN control traffic. No traffic or interface is permitted to be assigned to the switches’ default VLAN. \n",
|
|
146
|
+
"severity": "medium"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-19661",
|
|
150
|
+
"title": "The data network boundary must block all traffic destined to or sourced from VVoIP VLAN IP address space and VLANs except specifically permitted media and signaling traffic.",
|
|
151
|
+
"description": "The typical data firewall does not adequately protect the enclave when permitting VVoIP to traverse the boundary. Furthermore, a data firewall breaks VVoIP call completion when implementing NAT. NAT is no longer a security requirement. To properly protect the enclave when implementing VVoIP across the boundary, there are a specific set of processes and protections required, referred to as the VVoIP firewall function. These are separate from the data firewall processes and protections. The data firewall function plays a part in the protection of the VVoIP sub-enclave within the LAN, while the VVoIP firewall function protects the entire enclave while permitting the VVoIP system to function properly.",
|
|
152
|
+
"severity": "high"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "V-19662",
|
|
156
|
+
"title": "The Customer Edge Router (CER) must expedite forwarding of VVoIP packets based on Differential Service Code Point (DSCP) packet marking.",
|
|
157
|
+
"description": "The typical perimeter or premise router may not be capable of supporting the needs of VVoIP and UC when entering the DISN WAN. Modern 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 needed to support the service is the CER. The CER provides the following functionality:\n - Provides minimally four forwarding cues (eight preferred)\n - Places traffic within expedited forwarding cues based on the DSCP markings carried by the traffic.\n - Routes inbound AS-SIP-TLS packets and SRTP/SRTCP packets to the Session Border Controller (SBC).\n - Routes all other inbound traffic to the data firewall.\n - Provides all of the filtering required of a perimeter or premise router as required by the Router STIG.\n\nProper DSCP marking of VVoIP packets is required to provide appropriate QoS for Command and Control (C2) priority calls in support of Assured Service.",
|
|
158
|
+
"severity": "medium"
|
|
159
|
+
},
|
|
160
|
+
{
|
|
161
|
+
"id": "V-19663",
|
|
162
|
+
"title": "The Customer Edge Router (CER) must route all inbound traffic to the data firewall function except AS-SIP-TLS and SRTP/SRTCP, which must go to the Session Border Controller (SBC).",
|
|
163
|
+
"description": "The CER is the first line of defense at the gateway to the enclave or LAN. The data firewall and SBC functions are the second line of defense. Since the SBC function only processes VVoIP traffic in the form of AS-SIP-TLS and SRTP/SRTCP packets, the CER should only forward these packets to the VVoIP firewall.",
|
|
164
|
+
"severity": "medium"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "V-19664",
|
|
168
|
+
"title": "The Customer Edge Router (CER) must filter inbound AS-SIP-TLS traffic addressed to the local Session Border Controller (SBC) based on the source address of the signaling messages.",
|
|
169
|
+
"description": "The CER (premise or perimeter) router is the first line of defense at the gateway to the enclave or LAN. The data firewall and SBC functions are the second line of defense. The SBC processes VVoIP traffic in the form of AS-SIP-TLS and SRTP/SRTCP packets, and the CER must forward these packets to the SBC. A filter performed by the CER to prevent a denial-of-service is to filter the AS-SIP-TLS packets based on their source address. Within the DISN IPVS network, Local Session Controllers (LSC) only signal to their assigned Soft Switch (SS) and its backup. SSs are only to signal with their assigned LSCs, for which they are primary or backup, and other SSs. To support this, the SBC is required to authenticate the source of, and validate the integrity of, the signaling packets it receives and only process authenticated and valid packets, thereby only signaling with the appropriate devices. Still, the SBC could be flooded and overloaded with too many unauthenticated or invalid signaling packets. The CER can help prevent this by preventing signaling packets that are not sourced from authorized devices from ever reaching the SBC.",
|
|
170
|
+
"severity": "low"
|
|
171
|
+
},
|
|
172
|
+
{
|
|
173
|
+
"id": "V-19665",
|
|
174
|
+
"title": "The EBC is NOT configured to filter inbound AS-SIP-TLS traffic based on the IP addresses of the internal LSC(s) (or MFSS) OR the IP addresses of the EBCs fronting its authorized signaling partners as part of a layered defense.",
|
|
175
|
+
"description": "The EBC is in the VVoIP signaling between the LSC and MFSS. To limit its exposure to compromise and DOS, it must only exchange signaling messages using the designated protocol (AS-SIP-TLS) with the LSC(s) within the enclave and the EBC fronting the MFSS (and its backup) to which the LSC is assigned. \n\nSimilarly, an EBC fronting an MFSS must only exchange signaling messages with the MFSS and LSC(s) within the enclave and the EBCs fronting other MFSSs and the LSCs that are assigned to it. \n\nWhile the EBC is also required to authenticate the source and integrity of the signaling packets it receives, filtering on source IP address adds a layer of protection for the MFSS. This is also a backup measure in the event this filtering is not done on the CER.\n\nInternal to the enclave, filtering signaling traffic based on the IP address(es) of the LSC(s) within the enclave limits the ability of rogue EIs attempting to establish calls or cause a DOS.\n",
|
|
176
|
+
"severity": "medium"
|
|
177
|
+
},
|
|
178
|
+
{
|
|
179
|
+
"id": "V-19666",
|
|
180
|
+
"title": "The EBC is NOT configured to terminate and decrypt inbound and outbound AS-SIP-TLS sessions (messages) such that it can properly manage the transition of the SRTP/SRTCP streams",
|
|
181
|
+
"description": "We previously discussed the reasons why a special firewall function is needed to protect the enclave if VVoIP is to traverse the boundary (see VVoIP 1005 (GENERAL) under VVoIP policy). This requirement addresses the function of the EBC which manages the AS-SIP-TLS signaling messages.\n\nIn order to perform its proper function in the enclave boundary, the EBC must decrypt and decode or understand the contents of AS-SIP-TLS messages. Doing so supports the requirements that are to follow. Additionally, the EBC can perform message validity checks and determine of an attack is being attempted.\n\nNOTE: The EBC acts as an application level proxy and firewall for the signaling AS-SIP-TLS messages.\n",
|
|
182
|
+
"severity": "medium"
|
|
183
|
+
},
|
|
184
|
+
{
|
|
185
|
+
"id": "V-19667",
|
|
186
|
+
"title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to drop (and not process) all packets except those that are authenticated as being from an authorized source within the DISN IPVS network.",
|
|
187
|
+
"description": "We previously discussed the reasons why a special firewall function is needed to protect the enclave if VVoIP is to traverse the boundary (see VVoIP 1005 under VVoIP policy). This requirement addresses the function of the EBC which authenticates the AS-SIP-TLS signaling messages as being from an authorized source.\n\nDoD policy dictates that authentication be performed using DoD PKI certificates. This also applies to network hosts and elements. \n\nAS-SIP (and SIP on which it is based) is not a secure protocol. The information passed during call/session setup and teardown is in human readable plain text. To secure AS-SIP and SIP, TLS is used. TLS is PKI certificate based and is used for AS-SIP message encryption, authentication, and integrity validation. \n\nNOTE: Authentication is provided by validating the sending appliance’s public PKI certificate used to establish the TLS session. AS-SIP messages are not sent until the authenticated TLS session is established.\n\nNOTE: the methods used will be in accordance with the UCR.\n",
|
|
188
|
+
"severity": "medium"
|
|
189
|
+
},
|
|
190
|
+
{
|
|
191
|
+
"id": "V-19668",
|
|
192
|
+
"title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to drop (and not process) all signaling packets except those whose integrity is validated.",
|
|
193
|
+
"description": "The validation of signaling packet integrity is required to ensure the packet has not been altered in transit. Packets can be altered in a couple of ways. The first is modification by uncontrollable network events such as bit errors and packet truncation that would cause the packet to contain erroneous information. Packets containing detectable errors must not be processed since the effect of doing so is unknown and most likely not good. The second could be modification by a man-in-the-middle. \nNOTE: The USR mandates the packets be hashed upon transmission and receipt using HMAC-SHA1-160 with 160 bit keys and the validation of the hash of the received packet against the transmitted hash.\n\n",
|
|
194
|
+
"severity": "medium"
|
|
195
|
+
},
|
|
196
|
+
{
|
|
197
|
+
"id": "V-19669",
|
|
198
|
+
"title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to validate the structure and validity of AS-SIP messages such that malformed messages or messages containing errors are dropped before action is taken on the contents.",
|
|
199
|
+
"description": "Malformed AS_SIP messages as well as messages containing errors could be an indication that an adversary is attempting some form of attack or denial-of-service. Such an attack is called fuzzing. Fuzzing is the deliberate sending of signaling messages that contain errors in an attempt to cause the target device to react in an inappropriate manner, such as the device could fail causing a denial-of-service or could permit traffic to pass that it would not normally permit. In some cases a target can be flooded with fuzzed messages. As such the EBC must not act on any portion of a signaling message that contains errors. It is possible that a malformed or erroneous message could be sent by the signaling partner and be properly hashed for integrity.",
|
|
200
|
+
"severity": "low"
|
|
201
|
+
},
|
|
202
|
+
{
|
|
203
|
+
"id": "V-19670",
|
|
204
|
+
"title": "All SIP and AS-SIP packets are not dropped by the DISN NIPRNet IPVS firewall (EBC) except those AS-SIP packets arriving on IP Port 5061 that are secured with TLS.\n\n",
|
|
205
|
+
"description": "DISN NIPRNet IPVS PMO and the UCR require all session signaling across the DISN WAN and between the LSC and EBC to be secured with TLS. The standard IANA assigned IP port for SIP protected by TLS (SIP-TLS) is 5061. DoD PPSM requires that protocols traversing the DISN and DoD enclave boundaries use the standard IP port(s) for the specific protocol. Since AS-SIP is a standardized extension of the SIP protocol and since AS-SIP must be protected by TLS, AS-SIP-TLS must use IP port 5061. ",
|
|
206
|
+
"severity": "medium"
|
|
207
|
+
},
|
|
208
|
+
{
|
|
209
|
+
"id": "V-19671",
|
|
210
|
+
"title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to manage IP port pinholes for the SRTP/SRTCP bearer streams based on the information in the AS-SIP-TLS messages.",
|
|
211
|
+
"description": "We previously discussed the reasons why a special firewall is needed to protect the enclave if VVoIP is to traverse the boundary. (see VVoIP 1005 (GENERAL) under VVoIP policy) This requirement addresses the function of the EBC which manages the SRTP/SRTCP bearer streams. \n\nNOTE: The DISN IPVS PMO has determined that the EBC will pass the negotiated and encrypted SRTP/SRTCP bearer streams without decryption and inspection. This is because doing so will not provide a significant security benefit but would cause a significant delay with a resulting decrease in the quality of the communications. Encoded audio and video is difficult to impossible to determine if an attack is being perpetrated or if sensitive information is being improperly disclosed without reconstituting the analog audio and video signals and having a person listen and watch each communication. Due to the volume of communications, to do so would be nearly impossible. \n",
|
|
212
|
+
"severity": "medium"
|
|
213
|
+
},
|
|
214
|
+
{
|
|
215
|
+
"id": "V-19673",
|
|
216
|
+
"title": "The DISN NIPRnet boundary Session Border Controller (SBC) must perform stateful inspection and packet authentication for all VVoIP traffic (inbound and outbound), and deny all other packets.",
|
|
217
|
+
"description": "Once a pinhole is opened in the enclave boundary for a known session, the packets that are permitted to pass must be managed. If they are not properly managed, packets that are not part of a known session could traverse the pinhole thereby giving unauthorized access to the enclave’s LAN or connected hosts.\n\nOne method for managing these packets is called stateful packet inspection. This inspection minimally validates that the permitted packets are part of a known session. This is a relatively weak but somewhat effective firewall function. A better method is to authenticate the source of the packet as coming from a known and authorized source. ",
|
|
218
|
+
"severity": "high"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "V-19674",
|
|
222
|
+
"title": "The DISN NIPRnet boundary Session Border Controller (SBC) must deny all packets traversing the enclave boundary (inbound or outbound) through the IP port pinholes opened for VVoIP sessions, except RTP/RTCP, SRTP/SRTCP, or other protocol/flow established by signaling messages.",
|
|
223
|
+
"description": "Once a pinhole is opened in the enclave boundary for a known session, the packets that are permitted to pass must be managed. If they are not properly managed, packets that are not part of a known session may traverse a pinhole, giving unauthorized access to the enclave’s LAN or connected hosts. Another method for managing packets through a pinhole opened for a VVoIP session is to only permit packets to pass matching the expected protocol type, such as RTP/RTCP or SRTP/SRTCP. If only RTP/RTCP or SRTP/SRTCP packets are permitted to pass, this reduces the exposure presented to the enclave by the open pinhole.\n\nAdditional flows or protocols may be permitted if specifically required for an approved function and establishment is signaled or controlled by the signaling protocol in use by the system. An example of this is the transmission of H.281 far end camera control messages for a video conferencing session. Using AS-SIP for signaling, a UDP-based 6.4kbps H.224 over RTP control channel over which the H.281 far end camera control messages are transmitted might be established along with the media streams. This additional flow would require additional pinholes.",
|
|
224
|
+
"severity": "high"
|
|
225
|
+
},
|
|
226
|
+
{
|
|
227
|
+
"id": "V-19675",
|
|
228
|
+
"title": "The DISN NIPRNet IPVS firewall (EBC) is NOT configured to transmit a meaningful alarm message to the local EMS and DISN IPVS management system in the event of attempts to cause a denial-of-service or compromise the EBC or enclave.",
|
|
229
|
+
"description": "Action cannot be taken to thwart an attempted denial-of-service or compromise if the SAs responsible for the operation of the EBC and/or the network defense operators are not alerted to the occurrence in real time.",
|
|
230
|
+
"severity": "medium"
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "V-19676",
|
|
234
|
+
"title": "The VVoIP system connects with a DISN IPVS (NPRNET or SIPRNet) but the LSC(s) is not configured to signal with a backup MFSS (or SS) in the event the primary cannot be reached. ",
|
|
235
|
+
"description": "Redundancy of equipment and associations is used in and IP network to increase the availability of a system. Multiple MFSSs in the DISN NIPRNet IPVS network and multiple SSs in the DISN SIPRNet IPVS network have been implemented in each theatre to provide network wide redundancy of their functions. They are intended to work in pairs such that one can provide its backbone services to multiple LSCs that are configured to use one as a primary and the other as a backup. This is necessary to the maintenance of backbone functionality in the event there is a circuit (network path) failure, a MFSS or SS failure, or one of the sites housing a MFSS or SS is lost or the MFSS or SS becomes unavailable. Based on this, when establishing a call on the WAN, each LSC must be configured to signal with a backup MFSS or SS in the event it cannot reach its primary. ",
|
|
236
|
+
"severity": "medium"
|
|
237
|
+
},
|
|
238
|
+
{
|
|
239
|
+
"id": "V-19677",
|
|
240
|
+
"title": "The MFSS is NOT configured to synchronize minimally with a paired MFSS and/or others such that each may serve as a backup for the other when signaling with its assigned LSCs, thus reducing the reliability and survivability of the DISN IPVS network.",
|
|
241
|
+
"description": "MFSSs are critical to the operation of the DISN NIPRNet IPVS network. They broker the establishment of calls between enclaves. A MFSS provides the following functions: \n> Receives AS-SIP-TLS messages from other MFSSs and a specific set of regionally associated LSCs to act as a call routing manager across the backbone. \n> Sends AS-SIP-TLS messages to interrogate the ability of another MFSS or a LSC to receive a call, whether routine or priority. \n> Sends AS-SIP-TLS messages to manage the establishment of priority calls and the pre-emption of lower priority calls to LSCs and other MFSSs \n> Once a “trunk side” session request is received the MFSS determines if the destination is one of its assigned LSC’s. If so, it interrogates that LSC to determine if it can receive the call. If so, it signals to establish the call. If the destination is not one of its LSCs it signals with other MFSSs to locate the destination LSC and then the remote MFSS negotiates with its LSC. \n> Acts as a backup MFSS for LSCs assigned to other MFSSs as primary. As such, a LSC must be able to signal with a MFSS in order to establish any call across the DISN WAN. LSCs do not interact directly with LSCs. This hierarchical arrangement is required in order to be able to manage and establish priority calls and manage access circuit budgets. We established previously that each LSC must have a backup MFSS. In support of this function MFSSs must be operated in pairs with all the information about its assigned LSCs replicated across the pair. \n",
|
|
242
|
+
"severity": "medium"
|
|
243
|
+
},
|
|
244
|
+
{
|
|
245
|
+
"id": "V-21517",
|
|
246
|
+
"title": "Network elements configuration supporting VoIP services must provide redundancy supporting command and control (C2) assured services and Fire and Emergency Services (FES) communications.",
|
|
247
|
+
"description": "Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. The high availability and reliability required for Special-C2 and C2 users is achieved in part by redundancy within the LAN network elements. Policy sets the minimum requirements for the availability and reliability of VVoIP systems Special-C2 users at 99.999 percent, C2 users at 99.997 percent, and C2 Routine only users (C2R) and non-C2 users at 99.9 percent. \n\nVoice 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 from network failures quickly and maintaining the required QoS for existing services.",
|
|
248
|
+
"severity": "medium"
|
|
249
|
+
},
|
|
250
|
+
{
|
|
251
|
+
"id": "V-21518",
|
|
252
|
+
"title": "Network elements configuration supporting VoIP services must interconnect redundant uplinks following physically diverse paths to physically diverse network elements in the layer above with support for the full bandwidth handled by the network element using routing protocols facilitating failover.",
|
|
253
|
+
"description": "Policy sets the minimum requirements for the availability and reliability of VoIP systems and the supporting LAN with emphasis on C2 communications. The high availability and reliability required for Special-C2 and C2 users is achieved in part by interconnecting LAN network elements with redundant uplinks via geographically diverse paths. The core layer connects to the distribution layer below it, which then connects to the access layer below it.\n\nVoice 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. ",
|
|
254
|
+
"severity": "medium"
|
|
255
|
+
},
|
|
256
|
+
{
|
|
257
|
+
"id": "V-21520",
|
|
258
|
+
"title": "Activation/deactivation of and permission to use the extension mobility feature is not properly controlled.",
|
|
259
|
+
"description": "Extension mobility is a feature of a VVoIP system that permits a person to transfer their phone number extension and phone features (or configuration) to a phone that is not in their normal workspace. This is useful when a person is visiting a remote office away from their normal office and typically functions within an established enterprise wide VVoIP system where the system is designed as a contiguous system. In this case, the system is typically a single vendor solution. The system might be within one LAN/CAN may include multiple LAN/CANs at multiple interconnected sites. To activate this feature, the user approaches a phone that is not their regular phone and identifies themselves to the phone system via a username, password, pin, code, or some combination of these. Upon validation, the system configuration manager will configure the temporary phone to match the configuration of the user’s regular phone. Minimally, the phone number is transferred and possibly some or all of the user’s speed dial numbers and other personal preferences. This capability is dependant upon the capabilities of the temporary phone. Once activated the user’s inbound calls are directed to the temporary location. The user’s regular phone may or may not maintain its normal capabilities and also may also answer inbound calls.\n\nNOTE: This feature has nothing to do with LAN access control and is not related to moving physical phones/endpoints/instruments. The phone that is already in the temporary location is already authorized on the LAN and registered with the LSC. Moving phones requires pre-authorization and pre-configuration of the LAN access control mechanisms, potentially including the LSC. This feature should not be used to permanently move users from one office to another. \n\nNOTE: Extension mobility is similar to but not the same as forwarding ones calls. Forwarding is typically activated from the user’s normal phone or their user preferences configuration settings. Forwarding is therefore pre-set to a known location. Extension mobility is typically activated from the remote location and is activated upon arrival at that location.\n\nExtension mobility poses some vulnerabilities to the VVoIP system, user’s profile information, and conversations if not properly controlled. \n\nExtension mobility should be available only to those individuals that need to use the feature. There should be a configurable checkbox that enables/disables the feature within the configuration of the user’s normal phone or within the user’s profile. Making the feature available to all users all of the time broadens the exposure for potential compromise of other user’s profile information or conversations.\n\nActivation of the feature must not be via a feature button on the temporary phone or a commonly known code, either of which might be used along with the phone number to be transferred. This would leave all regular user’s phones vulnerable to anybody activating the feature from anywhere in the system to eavesdrop or collect information.\n\nExtension mobility transfer in some systems may have no time limitation. This means the temporary user’s phone configuration, preferences, speed dial information, and phone calls are available at the temporary phone until the transfer feature is deactivated. In the event the user does not specifically deactivate the transfer when they leave, the info is there until someone else deactivates it or another transfer is activated. While users should have the capability to deactivate the transfer at their discretion when they leave, the system should automatically deactivate the feature at some predetermined time of day or after a time period of inactivity. A timed deactivation might use a period of inactivity of one or two hours. Activation of the feature might be for a given period of time, such as eight hours, or for a user configurable time period set when they activate the feature. A time of day deactivation could be set to deactivate all such transfers at midnight each day. This feature might also be used as a backup for other methods.\n\nIn the event controls such as those discussed above are not available, an extension mobility feature should be deactivated if the feature is provided or supported by the system.\n\n",
|
|
260
|
+
"severity": "medium"
|
|
261
|
+
}
|
|
262
|
+
]
|
|
263
|
+
}
|
|
@@ -0,0 +1,569 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_voicevideo_services_policy",
|
|
3
|
+
"date": "2014-04-07",
|
|
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.letterkenny.FSO.mbx.stig-customer-support-mailbox@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": "Deficient Policy or SOP regarding VTC, PC, and speakerphone microphone operations regarding their ability to pickup and transmit sensitive or classified information in aural form.",
|
|
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(s) on the call. This same sensitivity is included in VTUs that are used in office spaces. This has one disadvantage. The microphones can pick up sidebar conversations that have no relationship to the conference or call in progress. Likewise, in an open area, received conference audio can be broadcast to others in the area that are not part of the conference, and possibly should not be exposed to the conference information for need-to-know reasons. Speakerphones exhibit a similar vulnerability. This is the same confidentiality vulnerability posed to audible sound information in the environment as discussed above with the added twist that the conference audio is vulnerable to others in the environment. While this is more of an issue in environments where classified conversations normally occur, it is also an issue in any environment. This is of particularly concern in open work areas or open offices where multiple people work in near proximity. Users or operators of VTC systems of any type must take care regarding who can hear what is being said during a conference call and what unrelated conversations can be picked up by the sensitive microphone(s). Where a VTU is used by a single person in an open area, a partial mitigation for this could be the use of a headset with earphones and a microphone. While this would limit the ability of others to hear audio from the conference and could also limit the audio pickup of unrelated conversations, it may not be fully effective. In some instances, such as when a VTU is located in a SCIF, a Push-to-Talk (PTT) handset/headset may be required Microphones embedded in or connected to a communications endpoint, PC, or PC monitor can be sensitive enough to pickup sound that is not related to a given communications session. They could pickup nearby conversations and other sounds. This capability could compromise sensitive or classified information that is not related to the communications in progress. Speakers embedded in or connected to a communications endpoint or PC can be made loud enough to be heard across a room or in the next workspace (e.g., cube). This capability could compromise sensitive or classified information that is being communicated during a session. Users must be aware of other conversations in the area and their sensitivity when using any communications endpoint, not only a PC based voice, video, or collaboration communications application. This awareness must then translate into protecting or eliminating these other conversations. A short range, reduced gain, or noise canceling microphone may be required. A push to talk microphone may also be required for classified areas. The microphone should be muted when the user is not speaking as both a mitigation for this issue, and for proper etiquette when participating in a conference. The muting function should be performed using a positively controlled disconnect, shorting switch, or mechanism instead of a software controlled mute function on the PC. Users must be aware of other people in the area that could hear what is being communicated. This is particularly an issue if the communicated information is sensitive or classified since the parties overhearing the information may not have proper clearance or a need-to-know. To mitigate this issue, a headset or speakers should be used and at a volume that only the user can hear. ",
|
|
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": "Deficient testing of, or lack of approval for, soft-phone accessories.",
|
|
61
|
+
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. A USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. PPGs can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. ",
|
|
62
|
+
"severity": "low"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-16086",
|
|
66
|
+
"title": "Deficient user training regarding the use of personally provided soft-phone accessories.",
|
|
67
|
+
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in the topic of this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. \n\nA USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. They can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones can contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. \n",
|
|
68
|
+
"severity": "low"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-16087",
|
|
72
|
+
"title": "Voice networks are improperly bridged via a soft-phone accessory.",
|
|
73
|
+
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. A USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. They can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones can contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. ",
|
|
74
|
+
"severity": "medium"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-16088",
|
|
78
|
+
"title": "Deficient user training regarding soft-phone accessory network bridging capabilities.",
|
|
79
|
+
"description": "While a headset, microphone, webcam, combination headset/microphone, or a combination webcam/microphone can be considered to be soft-phone accessories, these are also accessories for other collaboration and communications applications. These have been discussed previously and are not included in the topic of this section. Our discussion here relates to, soft-phone specific accessories, which consist of USB phones, USB ATAs, and PPGs. A USB phone is a physical USB connected telephone instrument that associates itself with the soft-phone application running on the PC. It minimally provides a handset which includes both the mouthpiece and receiver and may provide a dial pad, a speakerphone function, or other functions. In general, these devices do not pose a security threat other than those discussed previously under audio pickup/broadcast section above. They should be operated accordingly. A USB ATA is a USB connected device that associates itself with the soft-phone application and provides the ability to utilize a standard analog telephone or speakerphone. Some USB ATAs also provide a port to which an analog phone line can be connected. This allows a single analog phone to be used with the soft-phone while also answering and placing calls via the analog phone line. This line could be connected to a local PBX or to the PSTN. Some USB phones contain a port to which an analog phone line can be connected so the USB phone can be used with it to place and receive calls. There is little risk in the operation of this kind of USB ATA or USB phone providing it operates only as described and there is no direct bridging of networks as described next. A PPG (USB connected or internal card) is a type of ATA that is a gateway intended to bridge the soft-phone application and supporting VoIP network to an analog phone line from a local PBX or the PSTN. PPGs pose legal and fraud threats to a DoD network due to this bridging of networks. They can be used for toll fraud, toll avoidance, or placing or receiving unauthorized calls. Some USB Phones can contain a PPG. While these devices might be used to meet a specific mission requirement, their use may be illegal in certain countries and instances when connected between a DoD IP voice and data network and a public dial-up voice network. The use of any soft-phone accessory that provides a network bridging function poses both a legal and an IA threat to the DoD voice communications network. PPGs must not be used except to fulfill a validated and approved mission requirement. ",
|
|
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": "Deficient acceptable use policy or user agreement regarding PC communication clients.",
|
|
91
|
+
"description": "DoDI 8500.2 IA control PRRB-1 regarding “Security Rules of Behavior or Acceptable Use Policy” states “A set of rules that describe the IA operations of the DoD information system and clearly delineate IA responsibilities and expected behavior of all personnel is in place. The rules include the consequences of inconsistent behavior or non-compliance. Signed acknowledgement of the rules is a condition of access.”\n\nThis IA control requires the generation and use of a “user agreement” that contains site policy regarding acceptable use of various information system (IS) assets. Requiring the user to read and sign the user agreement before receiving their government furnished hardware and software, or before gaining access to an additional IS, add on application, or an additional privilege, provides the required acknowledgement. \n\nThe Secure Remote Computing STIG requires that a user agreement be used and signed for a user to be permitted to remotely access a DoD network or system. The Wireless STIG adds policy items to this user agreement regarding the use of wireless capabilities in conjunction with remote access. This STIG will be no different in that we, the DoD IA community, must define acceptable use requirements for the use of PC based voice, video, UC, and collaboration communications applications and accessories. While the first two STIGs mentioned require a user agreement prior to remote access privileges being granted, the user agreement should be signed when the user receives their government furnished hardware that covers all acceptable use policies. These policies are to include such things as acceptable web browsing, remote access, all wireless usage, as well as the usage of communications applications, soft-phone accessories, stick phones, personally configured VoIP, and IM clients. Minimally, the user agreement must be updated as privileges and certain applications are installed. User agreements must also be accompanied with user training and guides that reiterate the agreed to policies and provide additional information such as how to implement certain features and IA measures as required. \n\n",
|
|
92
|
+
"severity": "medium"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-16091",
|
|
96
|
+
"title": "Deficient or Non-Existent user guide regarding the proper use of PC based voice, video, UC, and collaboration communications applications.",
|
|
97
|
+
"description": "User agreements must be accompanied with a combination of user training and user guides that will reiterate the agreed to policies and prohibitions. The training and guides should also provide additional information such as how to operate a system or device and implement certain features and IA measures as required. \n\nA user guide would be extremely helpful in providing information to the user for the proper usage of PC based voice, video, UC, and collaboration communications applications and remote access implementations in general. An item that must not be forgotten in such a user guide is a discussion relating to the use of a PC based voice, video, UC, and collaboration communications applications for assured service C2 communications. Cautions and notice of the potential unreliable nature of these communications applications or methods must be included in user guides so that C2 users are aware, and reminded of, the non-assured service nature of these communications methods. \n\nThere are other topics that should be contained in a user guide serving this purpose. One such topic is the use of a “webcam” with hardware or software based VTU, particularly when used in a classified environment. Another user guide topic is the possible use of speakerphone capabilities when using a hard or soft EI in environments where classified discussion or work occurs.\n",
|
|
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": "No command or DAA approval exists for implementing soft-phones as the primary voice endpoint.",
|
|
109
|
+
"description": "The Designated Approving Authority (DAA) responsible for the implementation of a telephone system which primarily uses PC software applications for its endpoints must be made aware of the risks of operating such as system as well as the benefits. This is because the DAA must personally accept the risk of operating the system. In addition, the commander of an organization whose mission depends upon such a telephone system must also be made aware and provide their approval.",
|
|
110
|
+
"severity": "medium"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-16096",
|
|
114
|
+
"title": "No DAA approval for permitting limited numbers of soft-phones to operate in LAN.",
|
|
115
|
+
"description": "This use case addresses situations whereby the soft-phone/UC application and PC is not the primary voice communications “device” in the work area. This means that there is a validated mission need and the number of PC soft-phones permitted to operate inside the LAN will be less than the number of hardware based phones in the LAN. This number should be limited to those soft-phones required to meet specific mission requirements. UC applications that are ubiquitous in the LAN are addressed later, however, typically these work in association with a hardware based phone system, not in place of it. There are three possible scenarios for the use of limited numbers of soft-phones in the strategic LAN. We will discuss the first two in this section and the third in the next section. The first of these scenarios is providing support for soft-phones associated with a VoIP system in another enclave. This is a remote access scenario and must operate as they would in a normal telework/remote access use case. We will discuss this use case later, however, if this scenario is approved, special accommodations must be made in the local LAN to support users from a remote LAN and permit them to connect to their home enclave. This could include segregating them on a separate dedicated LAN with its own boundary protection or by implementing a dedicated VLAN protection zone while opening the enclave boundary to permit the remote connection. \n\nNOTE: Approval for this scenario would also require approval for specific foreign (non-local) PC attachment to the local LAN. These topics are beyond the scope of this document. The second of these scenarios is providing support for soft-phones associated with a local VoIP system. It is preferred that PC soft-phones associated with the local VoIP system not be used in the LAN, at all, due to the difficulties they present to the protection of the local hardware based VoIP infrastructure. Under normal circumstances, due to the separation of the VoIP and data VLANs a PC soft-phone application (associated with the local VoIP system) should not be able to register with the VoIP controller and function when the PC is connected to the LAN. This is because the PC connects to a LAN access port assigned to the data VLAN(s) and traffic between the voice and data VLANs is blocked. Similarly, if the PC was to be connected to a LAN access port assigned to the VoIP VLAN(s), the soft-phone might work but the PC would not have its normal data connectivity or services. If PC soft-phones are to be used in the strategic LAN, except as noted in the section on discrete instrument replacement, their numbers should be limited to those that are essential to the mission and additional protections, as discussed later in this section, must be added to the LAN to maintain the protection of the VoIP infrastructure. Implementations of limited numbers of PC soft-phones along with the protections afforded them and the local VoIP infrastructure must be approved by the responsible DAA. \n",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-16098",
|
|
120
|
+
"title": "Deficient protection for a Call Center (or CTI) system that uses soft-phones.",
|
|
121
|
+
"description": "The third scenario in which limited numbers of PC soft-phones might be used in a strategic LAN is when they are associated with or are actually part of a Computer Telephony Integration (CTI) application. Traditional computer telephony integration CTI encompasses the control of a telephone or telecommunications switch by a computer application. Interfaces have been developed to provide connection between the computer, typically a workstation, and the telephone or other terminal attached to the telephone switch, and possibly a special analog or TDM line going directly to the telephone switch. Applications are also developed to make use of these interfaces to integrate a data application with the telephone system. Sometimes the integration is as simple as being able to dial a number from the computer application or it could provide full control of the switch as in the case of an operator’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 general business LAN and that this can be accomplished by maintaining a closed network or a segregated and access controlled sub-enclave having appropriate boundary protection. This is in support of DoDI 8500.2 IA control DCSP-1 regarding “Security Design and Configuration / Security Support Structure Partitioning” which states “The security support structure maintains separate execution domains as in address spaces, for each executing process by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions.” \n",
|
|
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": "PC communications application C&A documentation is not included in the C&A documentation for the supporting VVoIP system .",
|
|
139
|
+
"description": "Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. Since a PC VVoIP communications application is typically supported by a larger VVoIP communications system, the security of the application will affect the security of the overall system. Therefore the C&A documentation for the PC application must be included in the C&A documentation for the overall VVoIP system. Subsequently the VVoIP system’s C&A documentation must be included in the C&A documentation for the LAN/enclave. DoDI 8500.2 IA control DCCT-1 under “Security Design and Configuration / Compliance Testing” states “A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.” This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. ",
|
|
140
|
+
"severity": "medium"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-16107",
|
|
144
|
+
"title": "Deficient PC communications application testing prior to implementation.",
|
|
145
|
+
"description": "Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. DoDI 8500.2 IA control DCCT-1 under “Security Design and Configuration / Compliance Testing” states “A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.” This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. ",
|
|
146
|
+
"severity": "medium"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-16108",
|
|
150
|
+
"title": "Deficient testing or approval of PC communications application patches or upgrades.",
|
|
151
|
+
"description": "Along with the measures described later to ensure application integrity, it is important that communications applications be tested and subsequently certified and accredited for IA purposes. This includes the applications as well as any upgrades and/or patches. DoDI 8500.2 IA control DCCT-1 under “Security Design and Configuration / Compliance Testing” states “A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.” This IA control relates to all PC communications applications and the accessories that work in conjunction with them such as USB phones or audio adapters, USB ATAs/PPGs, cameras, etc. Additionally, the specific network implementation(s) in which these applications are used must be addressed along with any central communications service for which the applications act as clients. The DoD certification and accreditation process in defined by DoDI 8510.01; Department of Defense Information Assurance Certification and Accreditation Process (DIACAP), 28 November 2007. ",
|
|
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": "Deficient PC Communications Application integrity or supportability.",
|
|
163
|
+
"description": "Another one of the measures in our defense in depth strategy to protect our PC based voice, video, UC, and collaboration applications is to ensure the application originates from a reputable source. The source of these applications can vary depending upon the type of application. To protect DoD interests, the source of the application depends on the criticality of the communications method. One source of possible compromise of a communications application is the use of freeware or shareware applications. This issue is covered in DoDI 8500.2 IA control DCPD-1 regarding “Security Design and Configuration / Public Domain Software Controls” which states “Binary or machine executable public domain software products and other software products with limited or no warranty such as those commonly known as freeware or shareware are not used in DoD information systems unless they are necessary for mission accomplishment and there are no alternative IT solutions available. Such products are assessed for information assurance impacts, and approved for use by the DAA. The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the Government.” Communications applications that primarily provide voice communications such as a soft-phone need to be designed to properly interoperate directly with the hardware based voice (VoIP) communications system. These applications should be a standard product of the voice system vendor or a partner whose product is approved by this vendor. The voice system is the most critical of all of the communications systems discussed in this document. \n\nCommunications applications that primarily provide VTC ‘like’ communications can come from several sources. Some soft-phone applications provide VTC and collaboration features and should be sourced from the voice system vendor as noted previously. Applications that primarily provide VTC features and need to interoperate directly with a hardware based VTC system should be sourced from the VTC system’s vendor or a partner whose product is approved by this vendor. Communications applications that primarily provide collaboration services while also providing voice and video communications features must also be sourced from a major vendor in the business of providing collaboration systems or services. Unified communications applications that provide multiple services such as IM, presence, voice, VTC, web conferencing, and so forth, may also be a product of the PC’s operating system vendor as with Microsoft’s Office Communications applications. Application sourcing can also be dependant upon whether the application is to interoperate with a hardware based communications system located and operated within an enclave or whether it is a system operated by an interagency or inter-base program. This requirement is based on the fact that DoD components are required to use software and applications that are supported by a vendor that can maintain the security and integrity of the software or application. The vendor must be able to provide patches, upgrades or both to mitigate newly discovered vulnerabilities found in their product in a timely manner. \n",
|
|
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 by hardware or PC based VVoIP endpoints during endpoint registration are not validated using digital signatures.",
|
|
187
|
+
"description": "During VVoIP endpoint registration with the LSC, a file is downloaded by the endpoint from the LSC that contains specific configuration parameters needed by the endpoint to operate as needed to support its assigned user. This file contains the phone number assigned to the endpoint; the IP addresses (or URLs) of the LSC(s) with which the endpoint is associated; the software menus specific to the system; the password used to access the endpoint’s configuration; the user’s personal preferences and speed dial numbers; as well as other information critical to the operation of the endpoint. NOTE: Hardware based VVoIP endpoints are like diskless computers on the LAN which need to download an operating system and configurations before they can operate. The code necessary to download this OS is stored in ROM or Flash Memory and is called firmware. To varying degrees some, most, or all of the endpoint’s OS can be stored on the device as firmware. The more of the OS that is stored the device, the quicker it initializes. In any case, no matter how much of the OS is stored as firmware, each endpoint requires a customized configuration settings file to be downloaded that individualizes the endpoint to meet the needs of the user to which it is assigned. These configuration settings can be updated occasionally or regularly by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded. Many PC based communications applications are fully configured locally on the platform, however, in some cases they rely on a configuration file downloaded from the system with which they are associated. The integrity of these files is critical to preventing compromise of the PC application, hardware endpoint, and the system itself. The best method for maintaining the integrity of these files is to require that they digitally signed. This can prevent man in the middle attacks where the configuration file could be modified in transit or the source of the file spoofed. Digital signatures and the file integrity must also be validated before the configuration file is used. NOTE: DoD PKI machine certificates are preferred for digital file signing, however, a vendor generated certificate would provide similar albeit not the same protection. LSCs and endpoints are to be assigned DoD machine certificates when the system operates as part of the DISN IPVS network. These certificates are also used for encryption purposes. ",
|
|
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": "A non-approved public or commercial IM or IP telephony service or soft-client application is in use.",
|
|
199
|
+
"description": "Various DoD policies disallow general PC users from installing any non-approved application on their workstations or from attaching any non-approved or non-government furnished devices to them. Still other DoD policies require users of government furnished equipment (GFE) (i.e., DoD PCs/workstations) to limit their use to official business and not use them for personal business or other personal activities. Additionally, and more specific to this STIG, DoDI 8500.2 IA controls ECVI-1 and ECIM-1 to disallow general PC users from installing VoIP and IM clients that are intended to access public services for non-official, personal, use. An exception is made for the eventuality that such installations may be approved and performed by a DoD component for official business purposes. The IA controls state the following: • ECVI-1: “Voice over Internet Protocol (VoIP) traffic to and from workstation IP telephony clients that are independently configured by end users for personal use is prohibited within DoD information systems. Both inbound and outbound individually configured voice over IP traffic is blocked at the enclave boundary. \n\nNOTE: This does not include VoIP services that are configured by a DoD AIS application or enclave to perform an authorized and official function.” • ECIM-1: “Instant messaging traffic to and from instant messaging clients that are independently configured by end users and that interact with a public service provider is prohibited within DoD information systems. Both inbound and outbound public service instant messaging traffic is blocked at the enclave boundary. \n\nNOTE: This does not include IM services that are configured by a DoD AIS application or enclave to perform an authorized and official function.” \n\nNOTE: AIS in this case means Automated Information System and relates to an official program. The vulnerability is that installation of VoIP and IM clients that associate themselves with, and connect to a public VoIP or IM service places the DoD system on which the client is installed at risk of, and provides an avenue for, its compromise and unauthorized access. Once compromised, the system could be used as a launching point for further compromise of the network or other DoD systems. Additionally, the use of these services also places the confidentiality of DoD information conveyed by them at risk. Such information could be sensitive or the collection of non-sensitive information over time could reveal sensitive information. The mitigation of the vulnerabilities presented by these public services requires a two prong approach. The first is a technical approach, while the second is an administrative approach requiring user awareness, training, and agreements. A technical approach defined by the IA controls stipulates that traffic to and from public IM and VoIP services is to be blocked at the enclave boundary. It would be best if this were to occur at the NIPRNet Internet Access Points (IAPs), thus preventing such traffic from using the DISN, however this is not happening at this time since such blockage might also block other required services and the IAPs are not fully capable of such blockage at this time. This traffic must also be blocked at any Internet Service Provider (ISP) connection(s) to the enclave. \n\nNOTE: All ISP connections must be approved and operated under a waiver obtained from the Global Information Grid (GIG) waiver panel. It is the responsibility of the enclave to provide the required blocking since their firewalls and proxies are where the capability resides. To implement the mitigation, one might think that blocking specific IP addresses would be effective. This is not correct, however, since many of the public services have many IP addresses and servers, while they change their IP addresses regularly as a method of enhancing availability. Some of the public services have classically used non standard IP ports for their communications. Blocking these ports can be an effective measure in meeting the IA controls. Unfortunately, some of the public services are changing to use standard ports to get around the fact that many organizations block the nonstandard ports at their firewalls. The services are migrating to the standard ports 80 and 443 for web services which are generally never blocked. While the purpose of blocking these public services in the network is that this mitigation will prevent the application or service from functioning properly in the event one is installed. It is best to prevent the user from installing the client applications. This can be accomplished by limiting a user’s privileges on their PC such that they cannot install new software. This is typically done on many DoD PCs, however, some users require that ability. Also, unfortunately, just like the trend toward using standard ports, some services may function without a specific client by just using a web browser. This will most likely be the trend for the future. A seemingly more effective approach to blocking these public services or prevent their installation is to block them by their URL. This might be done at a proxy in the enclave boundary or on the PC itself by listing the URLs as un-trusted and setting the PC or proxy security or protection level such that un-trusted sites are blocked. \n",
|
|
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": "Deficient end-to-end interoperable confidentiality, integrity, and authentication for VVoIP session signaling per DISN IPVS Requirements.",
|
|
217
|
+
"description": "Until recently VVoIP traffic has been restricted to the LAN/CAN within the enclave for most VVoIP systems. This is due to the lack of inter-vendor interoperability, end-to-end encryption, and the inability of VoIP to provide assured service in support of C2 communications reliability and priority requirements. The DSN PMO, DISA Engineering, and the Real Time Services (RTS) working group have been working to define network and system requirements to overcome the inherent obstacles in pursuit of a DISN wide interoperable assured service VVoIP or Voice Services network. In doing so, specific choices had to be made amongst the various technological and vendor solutions to provide the capability. These choices were made with the full cooperation of a consortium of vendor engineers. The following requirement reflects one of these choices made to meet DoD “confidentiality of data in transit” requirements under the DoDI 8500.2 IA controls ECCT-1 and ECNK-1 as well as Federal Information Processing Standards (FIPS) and Internet Engineering Task Force (IETF) recommendations. \n\nNOTE: For the purpose of this document the DISN wide IP enabled DSN or RTS network will be referred to the DISN IP Voice Services network or DISN IPVS network. Real time IP communications (known as real time Services (RTS)) is comprised of signaling protocols which set up and manage the communications session and the media transfer protocols which carry the communications. Both signaling and media protocols and the resulting communications can be compromised when sent in the clear. One of the common means (per IETF recommendations) of initiating a RTS communications session across an IP network is to use Session Initiation Protocol (SIP). To provide the assured service pre-emption and priority capabilities required for C2 telephone communications, DISA developed an extension to the SIP protocol (with the assistance of interested vendors) which is called Assured Service SIP or AS-SIP. The common means of providing confidentiality and integrity for SIP signaling as well as providing session authentication is to encrypt it using Transport Layer Security (TLS) as defined by the IETF recommendations. An additional factor to interoperability is the use of the same key management strategies at both ends of the session. The encryption algorithm, key strength, and key management processes are denied in the current version of the DoD Unified Capabilities Requirements (UCR) document available from the DISA voice Services PMO. \n\nNOTE: the devices in a VVoIP system that are required to provide this protection are all those involved in session initiation from end-to-end. These are the End Instruments (EIs), Media Gateways (MGs), Local Session Controller (LSC), Soft-Switch (SS), Multi-Function Soft Switch (MFSS), and Edge Border Controllers (EBCs) (which is the DISN IPVS/UCN VVoIP firewall). \n",
|
|
218
|
+
"severity": "medium"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "V-19441",
|
|
222
|
+
"title": "Deficient end-to-end interoperable confidentiality and integrity for VVoIP session media streams per DISN IPVS requirements.",
|
|
223
|
+
"description": "Until recently VVoIP traffic has been restricted to the LAN/CAN within the enclave for most VVoIP systems. This is due to the lack of inter-vendor interoperability, end-to-end encryption, and the inability of VoIP to provide assured service in support of C2 communications reliability and priority requirements. The DSN PMO, DISA Engineering, and the Real Time Services (RTS) working group have been working to define network and system requirements to overcome the inherent obstacles in pursuit of a DISN wide interoperable assured service VVoIP or Voice Services network. In doing so, specific choices had to be made among the various technological and vendor solutions to provide the capability. These choices were made with the full cooperation of a consortium of vendor engineers. The following requirement reflects one of these choices made to meet DoD “confidentiality of data in transit” requirements under the DoDI 8500.2 IA controls ECCT-1 and ECNK-1 as well as Federal Information Processing Standards (FIPS) and Internet Engineering Task Force (IETF) recommendations. NOTE: For the purpose of this document the DISN wide IP enabled DSN or RTS network will be referred to the DISN IP Voice Services / Unified Capabilities (UC) Network or DISN IPVS/UCN or DISN IPVS/UC network. Real time IP communications (known as real time Services (RTS)) is comprised of signaling protocols which set up and manage the communications session and the media transfer protocols which carry the communications. Both signaling and media protocols and the resulting communications can be compromised when sent in the clear. The common means (per IETF recommendations) of transporting RTS media across an IP network is to use Real-time Transfer Protocol (RTP). The common means of providing confidentiality and integrity of the RTP streams is to apply a security profile to RTP called Secure Real-time Transfer Protocol (RTP). An additional factor to interoperability is the use of the same key management strategies at both ends of the session. The encryption algorithm, key strength, and key management processes are denied in the current version of the DoD Unified Capabilities Requirements (UCR) document available from the DISA voice Services PMO. \n\nNOTE: The devices in a VVoIP system that are required to provide this protection are the End Instruments (EIs) and Media Gateways (MGs). These are the only devices in the end-to-end communications path that are required to have access to the unencrypted media stream. \n",
|
|
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 cannot place local intra-site or local commercial network calls in the event it is cut off from its remote, centrally located LSC.",
|
|
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. We rely on these services being available when they are needed. Additionally, it is critical that phone service is available in the event of an emergency situation such as a security breach or life safety event. The ability of maintaining the ability to place calls to emergency services must be maintained. While the DoD voice networks are designed to be extremely reliable, such that continuity of operations (COOP) is supported, there is the potential that a site will be cut off from the DoD network. Additionally, some site’s DoD VoIP phone systems are implemented without a local LSC. The LSC is located at some remote location and may serve several sites, both large and small. This scenario is sometimes called “long Local” service. Such an implementation can be used in regionalized organizational intranets and in MOBs with their tethered GSUs. This implementation scenario provides for central management of the overall phone system, saves in initial implementation cost, and saves in operating costs. As such this scenario has many benefits. Unfortunately, the reality of this implementation is that in order to place a call between two endpoints within the local site or to place a call via the local commercial service connection, the initiating end instrument has to send its signal messages to the remote LSC over the DISN WAN connection, then the LSC has to signal the called instrument or MG over the same WAN connection. Several messages are sent (back and forth) over the WAN connection before the two local endpoints can send their media streams directly between themselves. While the need to signal over the WAN connection can cause longer call setup time which can be extended if there is congestion in the network, no call can be placed anywhere from the local site if it is cut off from its LSC. Based on this fact, and in support of maintaining viable local voice services in the event the site is cut off from its remote LSC, each physical site must maintain minimal local call control as a backup so that local intra-site and local commercial network calls can be placed. While this works to maintain local emergency service availability for security and life safety emergencies, it also provides the capability to make calls between DoD sites using the commercial network. ",
|
|
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 endpoint configuration files downloaded by hardware based or PC based VVoIP endpoints during registration is not protected. ",
|
|
247
|
+
"description": "During VVoIP endpoint registration with the LSC, a file is downloaded by the endpoint from the LSC that contains specific configuration parameters needed by the endpoint to operate as needed to support its assigned user. This file contains the phone number assigned to the endpoint; the IP addresses (or URLs) of the LSC(s) with which the endpoint is associated; the software menus specific to the system; the user’s personal preferences and speed dial numbers; as well as other information critical to the operation of the endpoint. \n\nNOTE: Hardware based VVoIP endpoints are like diskless computers on the LAN which need to download an operating system and configurations before they can operate. The code necessary to download this OS is stored in ROM or Flash Memory and is called firmware. To varying degrees some, most, or all of the endpoint’s OS can be stored on the device as firmware. The more of the OS that is stored the device, the quicker it initializes. In any case, no matter how much of the OS is stored as firmware, each endpoint requires a customized configuration settings file to be downloaded that individualizes the endpoint to meet the needs of the user to which it is assigned. These configuration settings can be updated occasionally or regularly by resetting and re-registering the endpoint, which causes an updated configuration file to be downloaded.\n\nMany PC based communications applications are fully configured locally on the platform, however, in some cases they rely on a configuration file downloaded from the system with which they are associated. \n\nThe confidentiality of these files is critical to preventing compromise of the PC application, hardware endpoint, and the system itself. Many vendors use configuration files of this sort that are a compact binary format that is only interpretable by the endpoint’s firmware or PD application. However, there is the potential that such files may be human readable as is XML code and most VVoIP signaling protocols. If the file is human readable, intelligence can be gathered by capturing the file while it is in transit. Additionally, the file is easier to understand and therefore makes it easier to modify it and then forward it to its destination. This facilitates man-in-the-middle attacks.\n\nThe best method for maintaining the confidentiality of human readable files is to require that they be directly encrypted or downloaded over an encrypted channel. This can prevent man-in-the-middle attacks. Encryption of this file is also required if the file contains the password used to access the endpoint’s configuration information and settings menus. While encryption will also protect binary files, the threat is less due to the inability to easily read the information in the file without a program designed to interpret the binary code. As noted earlier, digital signatures and the file integrity must also be validated before the configuration file is used.\n\nNOTE: To satisfy the encryption requirement here, the file can be encrypted directly (preferred) or downloaded over an encrypted channel. (This is applicable to PC applications only)\n\nNOTE: Many of these configuration files are transferred using protocols such as BootP or TFTP which are designated “local management” per the DoD PPSM VAs for these protocols. These protocols are generally considered to be vulnerable due to their simplicity and lack of any security features. Per the DoD PPSM guidelines, a designation of “local management” means that PPSM recognizes the use of the protocol may be necessary within the LAN/enclave but it must remain within the LAN/enclave. This means that these protocols and therefore the configuration files transported by them must not traverse the WAN or enclave boundary unless protected by an encrypted VPN. As such, VVoIP endpoints that register with a LSC located in another LAN/enclave must do so via an encrypted site-to-site VPN between the enclaves or via an encrypted client-to-site VPN. \n\n",
|
|
248
|
+
"severity": "low"
|
|
249
|
+
},
|
|
250
|
+
{
|
|
251
|
+
"id": "V-19500",
|
|
252
|
+
"title": "The LAN supporting VVoIP services is not designed or implemented to provide enhanced availability and reliability above that of a traditional data LAN.",
|
|
253
|
+
"description": "• The traditional circuit switched telecommunications network is in general highly available highly and reliable on the order of 5 - 9s (99.999% uptime) reliability for the equipment and an aggregate of 2 to 3 9s for entire system and its provided services. This is achieved through a series of measures such as redundant hardware and network connectivity as well as backup power for the central switching equipment which also provides power for the subscriber instruments.\n• The traditional circuit switched telecommunications network supports routine communications, emergency communications, and high priority military command and control communications. Military telecommunications systems support various user types Special-C2, C2, C2-Routine (C2R), Non-C2, and administrative. C2 and Special-C2 users require higher levels of reliability and availability then do the rest. \n• As these services migrate from circuit switched technologies to packet switched IP based technologies, this reliability and support is expected to and must migrate with the service. \n• Similar measures are used to enhance the reliability and availability of VVoIP services on an IP network as are used in a circuit switched network.\n\nNOTE: \nfrom CJCSI 6215.01C Appendix A Enclosure C\nAvailability requirement for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. While this also states that no uninterrupted power supply is required (as a cost savings), all equipment and instruments in a VVOIP system should be provided with backup power in support of emergency, security, and life safety related communications.\n\nAlso from the UCR, 5.3.1.7.3.1 Voice Services \n1. Voice IP subscribers do not exceed more than 25 percent of available bandwidth (in LAN equipment and links)\n2. No single point of failure within the ASLAN can cause a voice service outage to more than 96 users.\n5.3.1.7.3.3 Data Services\nThe LAN will be engineered for a ratio of 25 percent voice, 25 percent video, and 50 percent data. Data traffic can burst up to the full link capacity if voice and video are not present.\n",
|
|
254
|
+
"severity": "low"
|
|
255
|
+
},
|
|
256
|
+
{
|
|
257
|
+
"id": "V-19514",
|
|
258
|
+
"title": "The LAN hardware does not provide the required redundancy to support the availability/reliability needs of the C2 and Special C2 users of VVoIP services for command and control communications OR the needs of routine users for emergency life-safety and security related communications.",
|
|
259
|
+
"description": "Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. Policy excerpts are as follows: From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details. \n\nNOTE: In large LAN infrastructures, it is most likely that each network element in the core and distribution layers of the LAN will support in excess of 96 users whether they are C2 users or not. All users of VVUC services supported by the LAN deserve reliable communications, particularly in emergency situations. As such, these devices should possess the ability to fail-over to a redundant piece of hardware. At the network access layer (the layer where endpoints connect), this is more difficult. While redundant power supplies, backplanes, and processors can provide redundancy for a given NE, this is not possible for the portion of the NE to which the LAN drop cable attaches. Here there can be no automatic failover. The use of the 96 user figure at the access layer is in support of this requirement. Typically access layer modules or stand alone devices support 48 and fewer connections. So, while all access layer switches should have some form of internal redundancy, there is a point when this is not cost effective or possible. In this case, a failure must be mitigated by physically moving LAN drop connections to a hot-standby device or replacing the defective module. Also note that for a LAN that supports 96 or fewer VVUC users as a whole would mean that by policy omission redundancy is not required, it is best practice that redundancy exists in some manner and particularly at the core or that there is spare equipment available. \n\nNOTE: While the policy discusses availability and reliability, through LAN equipment redundancy for C2 and Special C2 users of VVUC services, similar availability and reliability through redundancy is needed in support of routine user emergency life-safety and security related communications. \n",
|
|
260
|
+
"severity": "medium"
|
|
261
|
+
},
|
|
262
|
+
{
|
|
263
|
+
"id": "V-19521",
|
|
264
|
+
"title": "The design of the LAN supporting VVoIP services does not provide for the interconnection of LAN NEs with redundant uplinks following physically diverse paths to physically diverse NEs in the layer above ",
|
|
265
|
+
"description": "Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. The UCR in section 5.3.1.7.7.1 Single Product Redundancy states “In the event of a component failure in the network, all calls that are active shall not be disrupted (loss of existing connection requiring redialing) and the path through the network shall be restored within 5 seconds.” While the UCR is discussing hardware redundancy in this section it also discusses connectivity within the LAN as follows: 5.3.1.7.9 Survivability Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network. This can be accomplished by recovering quickly from network failures quickly and maintaining the required QoS for existing services. For the ASLAN, survivability needs to be inherent in the design. The following guidelines are provided for the ASLAN: 1. Layer 3 Dynamic Rerouting. The ASLAN products that route (normally the Distribution and Core Layers) shall use routing protocols IAW the DISR to provide survivability. 2. Layer 2 Dynamic Rerouting. • Virtual Router Redundancy Protocol (VRRP) – RFCs 2787 and 3768. VRRP is able to provide redundancy to Layer 2 switches that lose connectivity to a Layer 3 router. The ASLAN shall employ VRRP to provide survivability to any product running Layer 2 (normally the Access Layer). These requirements translate into the need for redundant connections between all connected NEs within the LAN. As such this requires a single access layer or distribution layer NE to have two uplinks to the layer above. Additionally the physical paths these uplinks take should be physically diverse. Additionally, these paths should terminate in physically diverse locations (that is, different NEs in different locations) These measures represent best practices and should be utilized to support all VVUC users but are required for special-C2 and C2 users. The availability and reliability policy excerpts are repeated here in support of this requirement for convenience: From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details.",
|
|
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 voice/video system management network is not designed or implemented to provide the proper bidirectional enclave boundary protection between the local management network and the DISN Voice Services (VS) management network.",
|
|
283
|
+
"description": "VVoIP core system devices and TDM based telecom switches can be and in many cases are connected to multiple management networks. Such is the case when the system is managed by local SAs and systems via the local management VLAN or dedicated OOB management network and other SAs or systems manage or monitor the system via another network such as a remote MILDEP NOC, the DSN’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 on each. Each of these management networks is in reality a different enclave and as such access and traffic between them must be filtered thus protecting each of the enclaves from compromise from one of the others. This intra-enclave protection is required by DoD IA policy (DoDD 8500.1) which states: “defend the perimeters of enclaves; provide appropriate degrees of protection to all enclaves and computing environments.” More specifically DoDI 8500.2 IA controls EBBD-2 and EBBD-3 regarding Enclave Boundary Defense for sensitive and classified systems respectively state, in part, “Boundary defense mechanisms to include firewalls and network intrusion detection systems (IDS) are deployed at the enclave boundary to the wide area network, at layered or internal enclave boundaries, and at key points in the network, as required.” The key portion of these IA controls addressed here is the part that states “at layered or internal enclave boundaries, and at key points in the network, as required.” This is further qualified by the definition of an enclave which states in part: Enclave: A collection of computing environments connected by one or more internal networks under the control of a single authority and security policy, including personnel and physical security. Based on this definition, the local LAN enclave, remote MILDEP NOC, the DSN’s ADIMSS network, the RTS EMS, and the DISN DCN are different enclaves. Therefore IA control EDDB-x is applicable and minimally a firewall is required where these enclaves meet. This requirement is generally applicable to VVoIP core system devices and TDM based telecom switches that are managed via multiple networks and specifically applicable to those where those systems and devices are managed via a single physical Ethernet/IP interface. As an example, if the ADIMSS and local SAs both manage a TDM switch or VVoIP system/device via a common pathway e.g., the local management VLAN or OOB management network, a firewall is required between the local network and the ADIMSS network. ",
|
|
284
|
+
"severity": "medium"
|
|
285
|
+
},
|
|
286
|
+
{
|
|
287
|
+
"id": "V-19562",
|
|
288
|
+
"title": "The VVoIP system and LAN design does not provide the necessary segmentation and protection of the VVoIP system core device management traffic and interfaces such that role based access and traffic flow can be properly controlled.",
|
|
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 does not contain one or more routing devices (router or layer-3 switch) or they are not implemented to provide support for required ACLs between the various required VVoIP VLANs.",
|
|
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.\n \n",
|
|
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": "Dual sets of CER, EBC, and LSC are NOT implemented in geographically diverse locations within a site supporting large numbers of 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 (or dual) CER connected to a single (or dual) EBC. It does not matter how reliable, redundant, and robust the CER, EBC, and power supply is (required to be 5 – 9s reliable), the facility housing this equipment represents a single point of failure. While this may be deemed to not be an issue for a small number of C2 users, the more C2 supported by the system, the greater the issue because all communications would be cut off in the event the facility is lost or severely damaged. Even less severe eventualities may also severely limit the capability of the system to support reliable communications. The mitigation for this system wide vulnerability is to implement redundant facilities to which the geographically diverse pathways containing the dual homed access circuits can run and terminate on redundant, geographically separated sets of CERs, EBCs, and core LAN equipment. LSCs can also be separated in this manner.\n\nUnderstandably, the mitigation for this issue is costly and facilities housing critical communications infrastructure are not lost very often. However, the cost of mitigating this vulnerability must be weighed against the loss of critical communications, particularly in time of crisis. If the site supports large numbers of high level C2 users or special C2 users, the cost of losing communications may outweigh the cost of providing redundant facilities. Another aspect of the loss of communications is that access to emergency services via the communications system would also be lost. The more users affected by such a loss the more the potential need to place calls to emergency services. \n\nAs such, all sites, large and small can benefit from the implementation of redundant facilities and equipment. \n\nNOTE: The threat to strategic facilities is far greater from natural causes than from damage due to acts of war or terrorism, but all threats need to be considered. On the other hand, tactical facilities naturally have a higher vulnerability to acts of war, which are raised on a par with or exceed the vulnerability posed my natural events.\n",
|
|
374
|
+
"severity": "low"
|
|
375
|
+
},
|
|
376
|
+
{
|
|
377
|
+
"id": "V-21506",
|
|
378
|
+
"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. ",
|
|
379
|
+
"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",
|
|
380
|
+
"severity": "low"
|
|
381
|
+
},
|
|
382
|
+
{
|
|
383
|
+
"id": "V-21507",
|
|
384
|
+
"title": "Mitigations against data exfiltration via the voice and/or video communications network/system have not been implemented",
|
|
385
|
+
"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",
|
|
386
|
+
"severity": "medium"
|
|
387
|
+
},
|
|
388
|
+
{
|
|
389
|
+
"id": "V-21508",
|
|
390
|
+
"title": "The site has not provided for Fire and Emergency Services (F&ES) telecommunications services (fire, police, medical, etc) and/or the telephone system does not support or is not configured to support enhanced emergency communications. ",
|
|
391
|
+
"description": "The inability to contact emergency services via the public telephone system and/or privately-owned Multi-Line Telephone Systems (MLTS) (such as PBXs and VoIP telephone systems) threatens life safety as well as facility protection and security. Emergency communications generally includes requests for fire, police, and/or medical assistance. In DoD, these communications can also include requests for Aircraft Rescue and Fire Fighting (ARFF), explosive ordnance disposal, and similar emergency situations. The inability of first responders to automatically locate the caller threatens life safety and facility protection or security. The ability to call an F&ES telephone number is called Basic F&ES Communications. The ability for the operator answering the emergency call to automatically determine the location of the caller and relay this information to the first responders is called Enhanced F&ES Communications. The ability to contact emergency services via the public telephone system has been mandated for many years in the US and other countries around the world. In the US, the FCC has mandated various aspects of providing enhanced F&ES communications and also relies upon state legislation to extend these rules. The Federal Communications Commission (FCC) rules primarily address public communications service providers including traditional LEC and CLECs, mobile communications providers, and VoIP communications providers. Support for enhanced emergency services communications by private MLTS is left to state legislation. Several states have such legislation today while more states are on the way. Eventually, most, if not all, states will likely have such legislation. Additionally, with respect to the DoD, DoDI 6055.06, DoD Fire and Emergency Services (F&ES) Program, December 21, 2006, provides DoD policy regarding emergency services and emergency services communications. While much of this policy addresses fire protection in general and more specifically training, staffing, and equipment, it also provides for telecommunications support for fire, medical, and security emergencies, whether directly or by implication. Several items of interest for this and subsequent STIG requirements are as follows: > 5.8. The Combatant Commanders, through Chairman of the Joint Chiefs of Staff, shall ensure F&ES protection of personnel, equipment, and facilities. > 6.6. Telecommunication Capability. Implement around-the-clock capability to conduct dedicated F&ES communications. > E8.1 Telecommunication Capability; Maintain around-the-clock capability to conduct essential F&ES communications. > E8.1.2. The DoD Components shall implement the installation F&ES alarm and communication function where feasible. > E8.1.2.1. Consolidate with an established continuously manned emergency communications center for all emergency services. > E8.1.2.4. DoD F&ES communications and dispatch functions may be provided by municipal F&ES or other outside agencies when those agencies compare favorably with DoD standards and can meet the prescribed communications criteria. Private telephone systems, in general, provide a large portion of the required telecommunication capability. All DoD telecommunications systems are private MLTS. As such, ALL private MLTS, VoIP or traditional must support enhanced emergency services communications for the completion of emergency calls. Per DoDI 6055.06, all sites must support, provide for, and implement F&ES telecommunications services. When implementing basic F&ES telecommunications services, each country or region designates a specific standard telephone number or prefix code to be dialed that can be easily remembered by the public. In some instances, while not best practice, organizations might designate an internal emergency number for use within their MLTS. PSTN LECs and CLECs must route calls to this number in a non-blocking priority manner. Examples of such numbers are as follows: > 911 in North America > 112 in the EU and UK > 000 in Australia In some cases countries use a separate code for Police vs Medical vs Fire. A rather comprehensive listing can be found at http://en.wikipedia.org/wiki/Emergency_telephone_number. Issues arise when an emergency call is originated through a private phone system, such as a traditional PBX or a VVoIP system. While the LEC or CLEC may properly route the call in a priority manner, the same may not be true for the private system unless specificity addressed in the systems call routing tables and potentially other system features. This is an issue when providing emergency communications services as a best practice or in compliance with governmental mandate. As such, the private system must be configured to properly handle emergency communications. Enhanced F&ES communications permits the answering station to automatically locate the caller. This is particularly helpful when the caller cannot provide their location themselves. Enhanced F&ES communications is generally mandated by the FCC and state legislation. It is today’s state of the art and its implementation is a best practice. The enhanced F&ES communications capability is enabled using Automatic Number Identification (ANI) and Automatic Location Identification (ALI) information. ANI provides the telephone number of the calling party and is generated by the telephone system/switch. ALI associates the calling party’s number (ANI information) with their address, or registered the address/location of the phone being used. ALI is provided by a database function. The database may be maintained within the telephone system/switch or externally. In many cases, the F&ES answering service system will use the ALI information to map the location of the calling phone. ALI information in the public sector is maintained by the telephone service providers and is generally based on billing records. This works fine for traditional phones that have a fixed location at the end of a telephone company wire. VoIP phones, on the other hand, can be connected anywhere in the world and function. This is an issue for commercial VoIP services which is being addressed by the FCC. ALI information in the private sector must be handled by the owners/operators of private MLTS. If a private MLTS is to support enhanced F&ES telecommunications, an ALI database must be instituted and maintained current as instruments and numbers move around a facility or site. While, in many cases, this may be a manual task, automated systems are being developed. NOTE: Notwithstanding system configuration and capabilities, the system must also remain fully functional, minimally for a reasonable time period, in the event primary power is lost. As such, both traditional PBXs and VVoIP systems along with their supporting LAN infrastructure must be provided with sufficient backup power. Specific requirements for voice communications system backup power are addressed in additional requirements. ",
|
|
392
|
+
"severity": "medium"
|
|
393
|
+
},
|
|
394
|
+
{
|
|
395
|
+
"id": "V-21521",
|
|
396
|
+
"title": "Unnecessary PPS have not been disabled or removed from VVoIP system devices or servers.",
|
|
397
|
+
"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",
|
|
398
|
+
"severity": "medium"
|
|
399
|
+
},
|
|
400
|
+
{
|
|
401
|
+
"id": "V-21522",
|
|
402
|
+
"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.",
|
|
403
|
+
"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",
|
|
404
|
+
"severity": "low"
|
|
405
|
+
},
|
|
406
|
+
{
|
|
407
|
+
"id": "V-21523",
|
|
408
|
+
"title": "The VVoIP system time is not properly implemented and/or synched with the LAN’s NTP servers. ",
|
|
409
|
+
"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",
|
|
410
|
+
"severity": "medium"
|
|
411
|
+
},
|
|
412
|
+
{
|
|
413
|
+
"id": "V-47735",
|
|
414
|
+
"title": "VVoIP endpoint configuration files transferred via Cisco TFTP must be encrypted and signed using DoD PKI certificates.",
|
|
415
|
+
"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.",
|
|
416
|
+
"severity": "medium"
|
|
417
|
+
},
|
|
418
|
+
{
|
|
419
|
+
"id": "V-47753",
|
|
420
|
+
"title": "Unencrypted and unsigned VVoIP endpoint configuration files traversing the DISN must be protected within a VPN between enclaves.",
|
|
421
|
+
"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.",
|
|
422
|
+
"severity": "medium"
|
|
423
|
+
},
|
|
424
|
+
{
|
|
425
|
+
"id": "V-8223",
|
|
426
|
+
"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",
|
|
427
|
+
"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.",
|
|
428
|
+
"severity": "low"
|
|
429
|
+
},
|
|
430
|
+
{
|
|
431
|
+
"id": "V-8224",
|
|
432
|
+
"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.",
|
|
433
|
+
"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. ",
|
|
434
|
+
"severity": "medium"
|
|
435
|
+
},
|
|
436
|
+
{
|
|
437
|
+
"id": "V-8225",
|
|
438
|
+
"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.",
|
|
439
|
+
"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",
|
|
440
|
+
"severity": "medium"
|
|
441
|
+
},
|
|
442
|
+
{
|
|
443
|
+
"id": "V-8227",
|
|
444
|
+
"title": "Different contiguous address blocks or ranges are NOT defined for the V-VoIP system within the LAN (Enclave) that is separate from the address blocks/ranges used by the rest of the LAN for non V-VoIP system devices thus allowing V-VoIP system traffic and access control using firewalls and router ACLs. \n \n",
|
|
445
|
+
"description": "VoIP networks increasingly represent high-value targets for attacks and represent a greater risk to network security than most other network applications; hence, it is imperative that the voice network and supporting data network(s) be secured as tightly as possible to reduce the impact that an attack can have on either network(s). Segregating voice traffic from data traffic greatly enhances the security and availability of all services. Further subdivision of the voice and data networks can further enhance security. Achieving the ideal security posture for voice and data would require two physically separate and distinct networks (including cable plant), much as is the case with traditional voice and data technologies. Although this might be considered for the most demanding security environments, it works against the idea of convergence and the associated cost savings expected by having one network (and cable plant). Logical segregation of VoIP components and data components can be accomplished at both layer 2 using Virtual Local Area Networks (VLANs) and layer 3 using IP addressing. While these methods, in themselves, are not designed as security mechanisms, they do provide a derived security benefit by easing management of filtering rules and obfuscating or hiding addresses and information that an attacker could use to facilitate an attack. Separation may also prevent an attack on one network from impacting the other. These methods make it harder for an attacker to be successful and help to provide a layered approach to VoIP and network security. Segregating data from telephony by placing VoIP servers and subscriber terminals on logically separate IP networks and logically separate Ethernet networks while controlling access to these VoIP components through filters will help to ensure security and aid in protecting the VoIP environment from external threats. In addition, further subdivision of those components is necessary to protect the telephony applications which are running across the infrastructure. Layer 3 address segregation is the first layer in our layered defense approach to VoIP security. It allows the use of switches, routers, and firewalls with their associated access lists and other processes, to control traffic between the components on the network. To provide address segregation, best practices dictate that all like components will be placed in like address ranges. Therefore VoIP components (i.e., Gatekeepers, Call Managers, voice mail systems, IP Subscriber Terminals etc.) will be deployed within their own, separate private IP network, logical sub-network, or networks. The combination of logical data and voice segmentation via addressing and VLANs coupled with a switched and routed infrastructure strongly mitigates call eavesdropping and other attacks. In addition, limiting logical access to VoIP components is necessary for protecting telephony applications running across the infrastructure. Segregating data from telephony by placing VoIP servers and subscriber terminals on logically separate IP networks while controlling access to these VoIP components through IP filters will help to ensure security and aid in protecting the VoIP environment. ",
|
|
446
|
+
"severity": "medium"
|
|
447
|
+
},
|
|
448
|
+
{
|
|
449
|
+
"id": "V-8228",
|
|
450
|
+
"title": "The dedicated VVoIP address range is NOT defined using “private” (non WAN routed) addresses IAW RFC 1918. ",
|
|
451
|
+
"description": "RFC 1918 defines “private” IP address blocks as follows: 10.x.x.x, 172.16.x.x, and 192.168.x.x. The purpose of this is to conserve the available public address pool since there are far more hosts needing addresses than there are addresses. This is done by using one public address for a publicly accessible WAN termination at the enclave boundary and NAT on the firewall or router with many ‘private” addresses in the LAN. The use of the term ”private” IP addresses in this sense means that these address blocks are not routed or advertised across the internet by international agreement. NIPRNet WAN addresses are “publicly accessible” and the PMO also follows RFC 1918 routing policy (meaning that these addresses are not routed). RFC 1918 addresses are routable within the LAN enclave however, and can be on closed private networks. This sub-network(s) will use a different major address range than is deployed on the local data network(s) to further separate IPT from the data network. This will help to reduce the chances of voice traffic traversing outside the telephony network segment and vice versa for data traffic. The use of RFC 1918 IP address space, like the data VLANs, has the effect hiding the VVoIP components from the WAN, and making their addresses non-routable as a destination across the Internet (or NIPRNet). Deploying VVoIP Systems using RFC1918 address space enhances security of the VVoIP environment. If VVoIP systems are not deployed on ”private” address space and if the address space is not properly configured, managed, and controlled, the VVoIP network could be accessed by unauthorized personnel resulting in security compromise of site information and resources. ",
|
|
452
|
+
"severity": "low"
|
|
453
|
+
},
|
|
454
|
+
{
|
|
455
|
+
"id": "V-8230",
|
|
456
|
+
"title": "The VVoIP VLAN design for the supporting LAN does not provide the necessary segmentation of the VVoIP system and service from the other services on the LAN and/or between the VVoIP components such that access and traffic flow can be properly controlled.",
|
|
457
|
+
"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 though 4 (at least) characteristics the filtering rules become easier to develop, deploy, and manage. Additionally, the implementation of VLANs helps to mitigate the risk of attacks sourced from the data VLANs such as virus driven DoS attack or packet sniffing. In addition, placing voice and data traffic into separate VLANs will reduce competition for the network and thus reduce latency (queue/wait time) for transmission services, which will reduce the possibility of denial of voice services. This also reduces the Ethernet broadcast domain thereby reducing network overhead. Since VoIP is very latency sensitive this segmentation approach is the most economical way to improve performance in an existing network infrastructure. ",
|
|
458
|
+
"severity": "medium"
|
|
459
|
+
},
|
|
460
|
+
{
|
|
461
|
+
"id": "V-8247",
|
|
462
|
+
"title": "Servers supporting the VVoIP and UC/UM telephony environment are not dedicated to telephony (VVoIP, UC, or UM) applications or their support.",
|
|
463
|
+
"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. ",
|
|
464
|
+
"severity": "medium"
|
|
465
|
+
},
|
|
466
|
+
{
|
|
467
|
+
"id": "V-8248",
|
|
468
|
+
"title": "All applicable STIGs have NOT been applied to the VVoIP / unified communications core infrastructure assets. ",
|
|
469
|
+
"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.",
|
|
470
|
+
"severity": "low"
|
|
471
|
+
},
|
|
472
|
+
{
|
|
473
|
+
"id": "V-8250",
|
|
474
|
+
"title": "DoD-to-DoD VVoIP traffic traversing any publicly accessible wide area network (i.e. Internet, NIPRNet) must use FIPS 140-2 or NSA approved encryption.",
|
|
475
|
+
"description": "When VVoIP connections are established across a publicly accessible WAN, all communications confidentiality and integrity can be lost. Information gleaned from signaling messages can be used to attack the system or for other nefarious reasons. If VVoIP traffic is passed in the clear it is open to sniffing attacks. This vulnerability exists whether the traffic is on a LAN/CAN or a MAN/WAN. Native end-to-end encryption of the signaling and media mitigates this vulnerability. As a secondary solution, mitigation can be accomplished at the link-level through the incorporation of encrypted VPN tunneling technology. Both solutions are applicable when the communicating endpoints are operated by the same organization or they reside in enclaves operated by the same organization and the endpoints and supporting systems are interoperable. As such, encryption of some approved form is required to protect DoD-to-DoD communications across a public network such as the Internet or a publicly accessible network such as the NIPRNet.\n\nWhile end-to-end application or protocol level encryption is preferred, tunneling unencrypted VVOIP signaling and media traffic using approved commercial grade (Type 3) site-to-site or client-to-site (remote access) VPN technologies mitigates the risk. The inherent type 1 site-to-site encryption employed afforded classified networks, such as the SIPRNet, also meets this requirement, although such networks are not public or publicly accessible as a rule.\n\nDoD-to-DoD voice communications are generally considered to contain sensitive information. Local DoD enclaves connect to a DISN SDN via an access circuit. Unless the site is a host to a SDN, or close enough to it to be served by DoD owned facilities, some portion of the access circuit will utilize leased commercial facilities. Additionally, the DISN core network itself may traverse commercial services and facilities. Therefore, DoD voice and data traffic crossing the unclassified DISN must be encrypted. ",
|
|
476
|
+
"severity": "high"
|
|
477
|
+
},
|
|
478
|
+
{
|
|
479
|
+
"id": "V-8253",
|
|
480
|
+
"title": "The stand alone or IP connected Voice mail system/server is not secured to applicable OS and DSN STIG guidance.",
|
|
481
|
+
"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",
|
|
482
|
+
"severity": "low"
|
|
483
|
+
},
|
|
484
|
+
{
|
|
485
|
+
"id": "V-8254",
|
|
486
|
+
"title": "IP connected Voice/Unified Mail servers have not been secured using all applicable general purpose application STIGs. ",
|
|
487
|
+
"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. ",
|
|
488
|
+
"severity": "medium"
|
|
489
|
+
},
|
|
490
|
+
{
|
|
491
|
+
"id": "V-8255",
|
|
492
|
+
"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. ",
|
|
493
|
+
"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",
|
|
494
|
+
"severity": "medium"
|
|
495
|
+
},
|
|
496
|
+
{
|
|
497
|
+
"id": "V-8256",
|
|
498
|
+
"title": "IP based VVoIP services over Wireless LAN (WLAN - Wi-Fi 802.11x) or Wireless MAN (WMAN - WiMAX 802.16) are being used without the applicable Wireless STIG/Checklist security guidance applied to the wireless service or endpoints in addition to the VoIP STIG/Checklist requirements.",
|
|
499
|
+
"description": "The incorporation of wireless technology into the VVoIP environment or service elevates many existing VoIP concerns such as quality of service (QoS), network capacity, provisioning, architecture and not the least important, security. Many government entities are exploring mobile communication solutions that include wireless VoIP that can meet critical needs for interoperability and flexibility. This will soon expand to video and unified communications over wireless. IP based wireless voice services and devices (endpoints) initially used Wi-Fi (802.11(x)) wireless LAN (WLAN) technologies. These devices are still available today and are essentially a cordless phone that happens to use Wi-Fi. Today vendors are integrating 802.11(x) VoIP capabilities into cellular phones that can transition seamlessly between a cellular network and a WLAN. This means that a user can place a call using the WLAN in their office and then move out of range and transition to their cellular carrier’s network without losing the call. Such a transition can operate in the other direction as well. Other devices integrate Cellular and Wi-Fi with WiMAX (802.11(e)) capabilities providing similar transitions as well as enterprise grade presence, messaging, directories, email, etc. Additionally, SmartPhones can support VoIP softphone applications which utilize the smartphone’s native IP connectivity. Similarly SmartPhone supported connectivity can be over cellular, Wi-Fi, and/or WiMAX network. Using these capabilities over wireless technologies presents vulnerabilities to the communications carried and the VVoIP infrastructure. Confidentiality is one of the greatest concerns requiring encryption of the media and signaling as it is on a wired MAN/WAN or LAN per the VoIP STIG/Checklist but even more so. This encryption is in addition to the WLAN encryption required by the Wireless STIG/Checklist. Additionally, per the Wireless STIG/Checklist, the endpoints must authenticate to the WLAN before being granted access thus preventing rogue endpoints and other devices from accessing the network, while the endpoint must also register with the VVoIP controllers. Another great concern for using wireless VVoIP communications services is reliability and availability when using the technology for critical C2 communications. Being wireless, all of the usual issues with radio transmission and reception come into play. In the event a C2 call is initiated, it could be blocked at either the transmitting end or the receiving end. This could be because the spectrum or channels could be busy/overloaded, unavailable, or deliberately jammed by an adversary. As such, VVoIP services should not be relied upon for C2 communications. NOTE: If Wireless VoIP technology is deployed all the requirements in the VoIP STIG/Checklist as well as those contained in the Wireless STIG/Checklist are to be applied to the wireless VoIP environment. ",
|
|
500
|
+
"severity": "low"
|
|
501
|
+
},
|
|
502
|
+
{
|
|
503
|
+
"id": "V-8257",
|
|
504
|
+
"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.",
|
|
505
|
+
"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. ",
|
|
506
|
+
"severity": "medium"
|
|
507
|
+
},
|
|
508
|
+
{
|
|
509
|
+
"id": "V-8288",
|
|
510
|
+
"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).",
|
|
511
|
+
"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",
|
|
512
|
+
"severity": "medium"
|
|
513
|
+
},
|
|
514
|
+
{
|
|
515
|
+
"id": "V-8290",
|
|
516
|
+
"title": "An inventory of authorized instruments is NOT documented or maintained in support of the detection of unauthorized instruments connected to the VoIP system.",
|
|
517
|
+
"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. ",
|
|
518
|
+
"severity": "medium"
|
|
519
|
+
},
|
|
520
|
+
{
|
|
521
|
+
"id": "V-8294",
|
|
522
|
+
"title": "The VVoIP system DHCP server is not dedicated to the VVoIP system within the LAN. ",
|
|
523
|
+
"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",
|
|
524
|
+
"severity": "low"
|
|
525
|
+
},
|
|
526
|
+
{
|
|
527
|
+
"id": "V-8295",
|
|
528
|
+
"title": "Customers of the DISN VoSIP service on ARE NOT utilizing address blocks assigned by the DRSN / VoSIP PMO.",
|
|
529
|
+
"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",
|
|
530
|
+
"severity": "low"
|
|
531
|
+
},
|
|
532
|
+
{
|
|
533
|
+
"id": "V-8302",
|
|
534
|
+
"title": "The LAN supporting VVoIP services for special-C2 and C2 users is not designed or implemented as a DOD ASLAN in accordance with the current UCR and therefore cannot support assured service in support of C2 communications reliability and availability requirements.",
|
|
535
|
+
"description": "Voice services in support of C2 and Special C2 users are required to meet certain minimum requirements relating to reliability and survivability of the supporting infrastructure. These requirements are defined in the current CJCSI 6215.01x Policy for DoD Voice Networks With Real Time Services (RTS). Design requirements for networks supporting DOD IPT/VoIP implementations can be found in the Unified Capabilities Requirements (UCR) specification document. This document contains the design specifications for an Assured Services Local Area Network (ASLAN) which is required to support DOD IP based voice services. These specifications define LAN design requirements for redundancy of equipment and their interconnections as well as minimum requirements for bandwidth and backup power, including the maximum number of endpoints that can be affected by a single point of failure. Policy sets the minimum requirements for the availability and reliability of VVoIP systems and the supporting LAN with emphasis on C2 communications. Policy excerpts are as follows: From CJCSI 6215.01C Appendix A Enclosure C Based on the GIG MA ICD requirements associated with availability and reliability, the following requirements shall be met by IP based RTS. (a) Availability requirement for equipment/software serving Special C2 users is 0.99999 (b) Availability requirement for equipment/software serving C2 users is 0.99997 (c) Availability requirements for equipment/software serving C2 users that are authorized to originate Routine ONLY (C2R) and non C2 users is 0.999. From UCR 5.3.1.7.6 Availability LAN [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN has two configurations depending on whether it supports special C2 or C2 users. The ASLAN shall have a hardware availability designed to meet the needs of its subscribers: 1. Special C2. An ASLAN that supports special C2 users is classified a High Availability ASLAN and must meet 99.999 percent availability to include scheduled maintenance. 2. C2. An ASLAN that supports C2 users is classified as a Medium Availability ASLAN and must have 99.997 percent availability to include scheduled maintenance. [Required: Non-ASLAN] The non-ASLAN shall provide an availability of 99.9 percent to include scheduled maintenance. From UCR 5.3.1.7.7 Redundancy [Required: ASLAN – Conditional: Non-ASLAN] The ASLAN shall have no single point of failure that can cause an outage of more than 96 IP telephony subscribers. In order to meet the availability requirements, all switching/routing platforms that offer service to more than 96 telephony subscribers shall provide redundancy in either of two ways: 1. The product itself (Core, Distribution, or Access) provides redundancy internally. 2. A secondary product is added to the ASLAN to provide redundancy to the primary product. See UCR 5.3.1.7.7.1 Single Product Redundancy and 5.3.1.7.7.2 Dual Product Redundancy for details.",
|
|
536
|
+
"severity": "low"
|
|
537
|
+
},
|
|
538
|
+
{
|
|
539
|
+
"id": "V-8306",
|
|
540
|
+
"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).",
|
|
541
|
+
"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. ",
|
|
542
|
+
"severity": "medium"
|
|
543
|
+
},
|
|
544
|
+
{
|
|
545
|
+
"id": "V-8323",
|
|
546
|
+
"title": "The necessary protection of the VVoIP system, its components, and its provided services are not supported by a comprehensive VVoIP VLAN ACL design for the supporting LAN such that VVoIP system access and traffic flow is properly controlled.",
|
|
547
|
+
"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. ",
|
|
548
|
+
"severity": "medium"
|
|
549
|
+
},
|
|
550
|
+
{
|
|
551
|
+
"id": "V-8328",
|
|
552
|
+
"title": "The implementation of a VVoIP system in the local enclave and its connection to external networks degrades the enclave’s perimeter protection due to an inadequate design of the VVoIP boundary with those external networks.",
|
|
553
|
+
"description": "VVoIP has the potential to significantly degrade the enclave boundary protection afforded by the required boundary firewall unless the firewall is designed to properly handle VVoIP traffic. The typical firewall used to protect an enclave that supports normal data traffic is not capable of properly handling or supporting real time communications (VVoIP). The following paragraphs will demonstrate this. VVoIP uses a signaling protocol and a media transfer protocol that require both inbound and outbound permissions be set for these protocols in order to provide the capability to place and receive calls to/from endpoints outside the enclave. More specifically, the signaling protocol typically uses one or more static TCP ports that must be open inbound at all times to receive calls. The media protocol; Real-time Transfer Protocol (RTP) and its companion protocol Real-time Transfer Control Protocol (RTCP) utilize randomly assigned UDP ports in the potential range of 1025-65535 with four IP ports required for every bi-directional voice session/call. The number of ports is expanded if video is added. The typical method of supporting VoIP through a standard data firewall is to open (or permit inbound) the signaling IP port(s) and a wide range of UDP ports for the RTP/RTCP media streams. While a typical data firewall can provide some protection from a VoIP implementation if the inbound permit statements are limited to specific limited address ranges (applicable in some situations), this is not possible if calls are to be permitted from any IP address on the Internet or NIPRNet that could be located anywhere in the world. Address segregation for VVoIP is generally not possible since the NIPRNet address space is disjointed (chopped up) and is spread across the overall public Internet (IPv4) address space. To support a worldwide IP enabled DSN, a typical data firewall would need to permit VVoIP signaling and media inbound from the entire registered IPv4 address space. One reason why this is the case is that an ACL developed to limit inbound enclave access to permit only NIPRNet addresses would require many permit statements such that the ACL itself could degrade firewall or router performance. As such, permitting VVoIP traffic across a standard data firewall opens gaping holes in the enclave’s perimeter protection. This is of particular concern when the WAN is the Internet or a DISN service that provides connection to the INTERNET such as the NIPRNet. On the other hand, a standard data firewall poses problems for VVoIP call/session completion if external public addressing is used with internal private (RFC 1918) addressing which requires the firewall to do NAT/NAPT. This is because the VVoIP endpoints need to know the IP address of the other endpoint and they signal their address within the signaling messages. The firewall changes the IP address of the packet during the NAT but does not change it in the signaling message causing a mismatch. The effect is that the call/session cannot be completed. NOTE: If the WAN is a “closed” system where the entire address space of the WAN and connected enclaves is managed by a “single system manager” (as is the case with DISN classified networks) a specific limited and segregated address space can be assigned for all VVoIP devices for use across the entire network. In this case, the risk to the enclave can be limited (although not eliminated) if a standard firewall is used with inbound permit statements that are based on the segregated IP address range. This protection can be further enhanced by limiting the UDP port range. An allowance has been made for such a situation; however, this may change in the future. Based on the above, If VVoIP is to traverse the enclave boundary; the firewall must be VVoIP aware or capable. A VVoIP aware/capable firewall provides the following minimal functions. > Interprets and understands the signaling protocol to determine the UDP ports that are negotiated for the RTP/RTCP media streams. > Dynamically opens the required UDP ports to permit the flow of the media (audio and video). > Performs stateful inspection on the UDP media packets to ensure the packets are part of the active call/session, while dropping all non session packets. > Closes the UDP ports when the end of the call/session is signaled OR after a period of session inactivity. In the event NAT is used across the enclave boundary, the VVoIP aware/capable firewall provides the following NAT functions: > Interprets and understands the signaling protocol to determine the IP addresses that are negotiated between the endpoints and adjusts the signaling messages in accordance with the local NAT/NAPT internal and external addresses. > Performs the NAT/NAPT address changes on the RTP/RTCP media packets as they traverse the boundary. In the event, the VVoIP enclave boundary provides access to and interoperability with a DISN IP based assured service voice service (such as the IP-DSN on NIPRNet), VVoIP aware/capable firewall must provide the following additional functions (Note: these are defined in the UCR): > Provides encryption services for the signaling protocol (AS-SIP uses TLS) > Provides authentication of the source of the signaling protocol packets and drops all unauthenticated packets. > Provides integrity validation of the signaling protocol packets and drops all invalid or modified packets. > Terminates the AS-SIP signaling session and checks the validity of the AS-SIP messages based on content and establishes a new signaling session for the next hop, thus performing an application level inspection of the signaling messages. > Communicates with Call controllers (LSCs and MFSSs) using AS-SIP/TLS > Interprets and understands the AS-SIP signaling protocol to provide the minimal and NAT functions noted above > Supports encrypted RTP/RTSP media streams. That is SRTP/SRTCP > Provides the capability to decrypt the media streams for inspection and recording. This supports monitoring/recording for CALEA and COMSEC monitoring purposes for calls that traverse the enclave boundary. > Performs intrusion and DoS detection with alarm capability for both the signaling and media. > Blocks all non VVoIP traffic whether destined for the VVoIP or data sub-enclaves. NOTE: While RTCP messages could be validated for content and format, the contents of RTP packets cannot due to the random nature of the audio and video data being transmitted. Delaying the RTCP packets for inspection or the SRTCP messages for decryption and inspection while passing the RTP/SRTP packets would cause disruption in the media flow and thereby negatively affect its quality. Additionally, the delay of the SRTP packets for decryption and inspection would have similar effects. Thus intrusion detection based on the media streams is almost impossible since attack profiles are generally unavailable. Based on this and to improve worldwide voice quality, the DSN/RTS PMO and the RTS WG has determined that the SRTP/SRTCP streams will be passed by the VVoIP firewall without inspecting the encrypted contents of the packets. NOTE: The VVoIP aware/capable firewall discussed here defines a set of functions that are unique to a VVoIP which are different from the set of functions required for data firewalls. The functions for data firewalls are defined in the Network Infrastructure STIG. While typically a single firewall will not be capable of supporting both sets of functions (which means a separate VVoIP firewall is needed in parallel to the data firewall) this requirement does not mean that a dedicated VVoIP firewall must be implemented in the event a single firewall is capable of implementing both sets of functions simultaneously. The primary task of the data firewall function is to protect the entire enclave. In doing so, it must perform its normal function of protecting the data sub-enclave while also blocking all VVoIP traffic destined for it via the data firewall. An exception could be made for this on a case by case basis if permissions are limited in scope as would be the case for VTC. All data traffic/protocols destined for the VVoIP sub-enclave must also be blocked unless specifically authorized to meet a mission need. Such a mission need might be for remote management of the VVoIP system from a NOC or user-to-site VPN, however, this traffic must would be routed to the VVoIP management VLAN(s) and not the VVoIP production VLANs. An additional consideration for passing VoIP across an enclave boundary is when there are different vendor’s VoIP systems deployed within the different enclaves connected to the WAN, and the various vendor’s systems are not interoperable or do not provide assured service outside the enclave, or the WAN cannot support QoS and assured service. In this case, interoperability and assured service must be preserved across the DSN or DISN voice network, whether traditional TDM or VoIP. Therefore, the VoIP system must connect to other enclaves via a traditional TDM based long haul network. Such a connection is made using a media gateway. Therefore, if the enclave VoIP system is not compatible with the IP enabled DSN as defined in the UCR thereby providing interoperability and assured service end-to-end across the DISN voice network, the system must employ a media gateway and connect to a traditional DSN switch. Additionally, unless specific requirements (discussed later) are met, all connections to the PSTN must be via a media gateway and an appropriate trunk (PRI or CAS). ",
|
|
554
|
+
"severity": "high"
|
|
555
|
+
},
|
|
556
|
+
{
|
|
557
|
+
"id": "V-8329",
|
|
558
|
+
"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.",
|
|
559
|
+
"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",
|
|
560
|
+
"severity": "medium"
|
|
561
|
+
},
|
|
562
|
+
{
|
|
563
|
+
"id": "V-8349",
|
|
564
|
+
"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.",
|
|
565
|
+
"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",
|
|
566
|
+
"severity": "medium"
|
|
567
|
+
}
|
|
568
|
+
]
|
|
569
|
+
}
|