RubyGems - kriterion - Versions diffs - 0.0.1 - Mend

kriterion 0.0.1

Files changed (564) hide show

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

data/standards/stig_mobile_email_management_mem_server.json ADDED

@@ -0,0 +1,197 @@
+{
+  "name": "stig_mobile_email_management_mem_server",
+  "date": "2013-05-08",
+  "description": "This STIG provides technical security controls required for the use of a MEM server that manages mobile email from/to mobile devices in the DoD environment. The requirements listed in this benchmark apply to any DoD iOS implementation when iOS devices process sensitive DoD information, connect to a DoD network or network connected PC, or provide service to a DoD email system. The requirements can be implemented in an application server separate from the MDM server or included in the MDM server.  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.",
+  "title": "Mobile Email Management (MEM) Server Security Technical Implementation Guide (STIG)",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-24972",
+      "title": "The required mobile device management server version (or later) must be used. ",
+      "description": "Earlier versions of the MDM server may have security vulnerabilities or not have required security features implemented. Therefore, sensitive DoD data could be exposed if required security features are not implemented on site-managed mobile devices.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-24973",
+      "title": "The host server where the mobile management server is installed must be hardened according to the appropriate Application STIG (SQL, Apache Tomcat, IIS, etc.). ",
+      "description": "The host server where the mobile management server is installed must be compliant with the Windows STIG and applicable application STIGs to ensure the system is not vulnerable to attack resulting in a Denial of Service or compromise of the management server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-24975",
+      "title": "The host server where the mobile management server is installed must have a host-based or appliance firewall, which must be configured as required.\n",
+      "description": "A mobile device user could get access to unauthorized network resources (application and content servers, etc.) via the communications link between the mobile device and mobile management server if the server host firewall is not set up as required. HBSS is usually used to satisfy this requirement.",
+      "severity": "high"
+    },
+    {
+      "id": "V-25754",
+      "title": "The PKI digital certificate installed on mobile management servers for server authentication must be a DoD PKI-issued certificate.",
+      "description": "When a self-signed PKI certificate is used, a rogue mobile management server can impersonate the DoD mobile management server. DoDI 8520-02 requires PKI certificates come from a trusted DoD PKI.",
+      "severity": "low"
+    },
+    {
+      "id": "V-26564",
+      "title": "Authentication on system administration accounts for mobile management servers must be configured to support CTO 07-15 Rev 1 requirements.\n",
+      "description": "CTO 07-15 Rev 1 requires administrator accounts use either CAC authentication or use complex passwords to ensure strong access control is enforced. This is best enforced by requiring the server support AD authentication.",
+      "severity": "high"
+    },
+    {
+      "id": "V-32776",
+      "title": "The MEM client must provide users with the option to deny acceptance of a certificate when the certificates revocation status cannot be verified. \n",
+      "description": "When the certificate revocation status cannot be verified, the email sender's identity cannot be verified and the user must have the capability to accept or deny the certificate and act on the email content based on sensitivity of the email content and mission needs.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32777",
+      "title": "The MEM client must alert the user if it receives a public-key certificate issued from an untrusted certificate authority. ",
+      "description": "When the  public-key certificate is issued from an untrusted certificate authority, the certificate cannot be trusted and the recipient must have the capability to accept or deny the certificate and act on the email content based on sensitivity of the email content and mission needs.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32779",
+      "title": "The MEM client must alert the user if it receives an invalid public-key certificate. ",
+      "description": "When the public-key certificate is invalid, the certificate cannot be trusted and the recipient must have the capability to accept or deny the certificate and act on the email content based on sensitivity of the email content and mission needs.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32781",
+      "title": "The MEM client must not accept certificate revocation information without verifying its authenticity. \n",
+      "description": "When the  public-key certificate has been identified as revoked but the revocation authenticity cannot be verified, the revocation cannot be trusted and the recipient must have the capability to accept or deny the certificate and act on the email content based on sensitivity of the email content and mission needs.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-32782",
+      "title": "The MEM client must verify user digital certificate when performing PKI transactions. ",
+      "description": "The trust of any PKI operation is contingent on the certificate chain. Authentication and encryption services based on PKI would be untrusted if the certificate chain is not verified.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32788",
+      "title": "The MEM client must alert the user if it receives an unverified public-key certificate. ",
+      "description": "When the  public-key certificate is  unverified certificate, the certificate cannot be trusted and the recipient must have the capability to accept or deny the certificate and act on the email content based on sensitivity of the email content and mission needs.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-32789",
+      "title": "All data (including email and attachments) sent over the wireless link between the mobile email client and MEM server located on the DoD network must be encrypted using AES. ",
+      "description": "AES is the DoD standard for unclassified data encryption.  When other encryption algorithms are used (non-type-1) the level of trust that sensitive DoD data cannot be compromised is not available.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32790",
+      "title": "The MEM server and client must encrypt all data using a FIPS 140-2 validated cryptographic module. ",
+      "description": "FIPS 140-2 validated encryption is the DoD standard for unclassified data encryption. When non-FIPS validated encryption modules are used (other than Type 1) the required level of trust that sensitive DoD data cannot be compromised is not available.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32791",
+      "title": "The MEM client must be capable of providing S/MIME v3 (or later version) encryption of email. ",
+      "description": "Sensitive DoD data could be exposed if the required setting is not configured on the Good server. If S/MIME support is not configured on the server, the user will not be able to view critical encrypted email or be able to encrypt email with sensitive DoD information.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32792",
+      "title": "The MEM client S/MIME must be fully interoperable with DoD PKI.",
+      "description": "Without DoD PKI interoperability, the S/MIME feature would not work and could not meet DoD S/MIME requirements.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-32793",
+      "title": "The MEM client S/MIME encryption algorithm must support both 3DES and AES. ",
+      "description": "DES and AES are the DoD standard for unclassified data encryption based on DoD PKI certificates. AES is preferred but some DoD CACs only support the 3DES encryption algorithm.  When other encryption algorithms are used (non-type-1) the level of trust that sensitive DoD data cannot be compromised is not available.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32794",
+      "title": "The MEM client S/MIME cryptographic module must be FIPS 140-2 validated. ",
+      "description": "FIPS 140-2 validated encryption is the DoD standard for unclassified data encryption.  When non-FIPS validated encryption modules are used (other than Type 1) the level of trust that sensitive DoD data cannot be compromised is not available.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32795",
+      "title": "The MEM client must provide the capability to save public certificates of contacts in an acceptable method.",
+      "description": "This capability is required to support S/MIME encryption of email.  Without S/MIME, end-to-end data encryption is not possible and sensitive DoD data could be compromised.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32796",
+      "title": "The MEM client must not cache the certificate status of signed emails that have been received on the handheld device beyond the expiration period of the revocation data. ",
+      "description": "If the revocation status of the certificate is not cached, the email client would need to retrieve the status every time a user opens a signed email, which would cause a usability issue of the mobile email feature and possibly cause the user to begin to ignore the status of signing certificates in received email.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32797",
+      "title": "The MEM client must set the Smart Card or Certificate Store Password caching timeout period to no more than 120 minutes, if Smart Card or Certificate Store Password caching is available.",
+      "description": "The certificate/key store contents must not remain unencrypted indefinitely; otherwise, the encryption keys and PKI certificates stored in the store could be compromised. The store must re-encrypt contents of the store on or before the required timeout period.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32798",
+      "title": "The MEM client must provide the mobile device user the capability to digitally sign and/or encrypt outgoing email messages using software or hardware based digital certificates. ",
+      "description": "The email client must support signing and encrypting email using both software and hardware PKI certificates so that the DoD can use either certificate form factor based on current policy, security threats, and mission needs.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32799",
+      "title": "The MEM client must provide the mobile device user the capability to decrypt incoming email messages using software or hardware based digital certificates. \n",
+      "description": "The email client must support signing operations (verifying digital signatures) and decrypting email using both software and hardware PKI certificates so that the DoD can use either certificate form factor based on current policy, security threat, and mission needs.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32800",
+      "title": "The MEM client must provide a mechanism to provide certificate validation through a trusted OCSP, CRL, or SCVP. \n",
+      "description": "Certificate validation is a key requirement of a robust PKI; therefore, the mobile email server must support all DoD accepted processes for distributing certificate status information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32801",
+      "title": "The MEM client must provide a noticeable warning to the user if the CRL, SCVP, or OCSP server cannot be contacted or the revocation data provided cannot be verified. ",
+      "description": "Certificate validation is a key requirement of a robust PKI; therefore, the user must be notified if the status of a certificate on a signed email cannot be verified.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32802",
+      "title": "The MEM client must support retrieving encryption certificates not stored in the local trust anchor store for S/MIME purposes. ",
+      "description": "S/MIME operations cannot be performed if the device user cannot access public encryption certificates for email recipients; therefore, if encryption certificates are not stored in the contacts list or other local certificate store, S/MIME must be able to retrieve the certificates from the GAL, GDS, or other non-local DoD sources.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32803",
+      "title": "The MEM client must support SHA2 or later signing operations. ",
+      "description": "SHA2 or later signing is required because earlier signing algorithms have been compromised and do not provide the required level of trust.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32804",
+      "title": "The MEM client must either block or convert all active content in email (HTML, RTF, etc.) to text before the email is forwarded to the mobile device. ",
+      "description": "HTML email and inline images in email can contain malware or links to websites with malware.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-32805",
+      "title": "The MEM client must support SHA2 signature verification. ",
+      "description": "SHA2 or later signing is required because earlier signing algorithms have been compromised and do not provide the required level of trust.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-32806",
+      "title": "All email sent to the mobile device must be managed by the  mobile email server.  Desktop or Internet controlled email redirection are not authorized.\n",
+      "description": "Desktop or Internet controlled mobile email redirection does not allow the mobile email to be managed by a mobile email management server; therefore, email security policies cannot be enforced.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32807",
+      "title": "The MEM client must enable a system administrator to select which data fields in the contacts data base will be available to applications outside of the contact database.",
+      "description": "Sensitive contact information could be exposed to unauthorized people.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-33231",
+      "title": "The master AES encryption key used to encrypt data between the management server and the agent on the mobile device must be changed every 30 days or less. ",
+      "description": "There are two primary methods for generating the encryption key used to encrypt data between the management server and the server agent installed on the mobile device.  The first method is to use a shared secret and the second is to generate the master encryption key based on PKI key generation.  When a shared secret is used, if the master encryption key is not rotated periodically, and it is compromised, all future data sent between the mobile management server and the agent located on the mobile device would be compromised. Limiting the compromise to no more than a specific period of data is a security best practice.",
+      "severity": "low"
+    }
+  ]
+}

data/standards/stig_mobile_operating_system_security_requirements_guide.json ADDED

@@ -0,0 +1,1943 @@
+{
+  "name": "stig_mobile_operating_system_security_requirements_guide",
+  "date": "2013-07-03",
+  "description": "The Mobile OS Security Requirements Guide (SRG) is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the NIST SP 800-53 and related documents. 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.",
+  "title": "Mobile Operating System Security Requirements Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-32906",
+      "title": "The operating system must provide automated support for account management functions.",
+      "description": "A comprehensive account management process that includes automation helps to ensure the accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to using automation to take action on multiple accounts designated as inactive, suspended or terminated, or by disabling accounts located in non-centralized account stores, such as, multiple servers.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32907",
+      "title": "The operating system must automatically terminate temporary accounts after an organization defined time period for each type of account.",
+      "description": "When temporary and emergency accounts are created, there is a risk the temporary account may remain in place and active after the need for the account no longer exists.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32908",
+      "title": "The operating system must automatically disable inactive accounts after an organization defined time period.",
+      "description": "Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32910",
+      "title": "The operating system must support the requirement to automatically audit on account creation.",
+      "description": "Auditing of account creation is a method and best practice for mitigating the risk of an attacker creating a persistent method of re-establishing access. A comprehensive account management process will ensure an audit trail which documents the creation of accounts and if required notifies administrators. Such a process greatly reduces the risk of accounts being created outside the normal approval process and provides logging that can be used for forensic purposes. Additionally, the audit records of account creation can be compared to the known approved account creation list.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32911",
+      "title": "The operating system must dynamically manage user privileges and associated access authorizations.",
+      "description": "While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. The operating system needs to be able to dynamically manage user privileges and access authorization decisions.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32912",
+      "title": "The operating system must enforce dual authorization, based on organizational policies and procedures for organization defined privileged commands.",
+      "description": "Dual authorization mechanisms require two distinct approving authorities to approve the use of the command prior to it being invoked. An organization may determine certain commands or configuration changes require dual-authorization before being activated. The operating system must have the ability to enforce this dual authorization.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32913",
+      "title": "The mobile operating system must enforce a mandatory access control (MAC) policy that prohibits any application, user, or process from modifying software in the trusted computing base with the exception of protected processes dedicated to performing updates to particular trusted computing base components.",
+      "description": "The trusted computing base includes the OS, device drivers, system and security configuration files, and key material. OS functions include audit and security policy enforcement mechanisms. In the context of this requirement, an update process is protected if is not modifiable by other processes and requires cryptographic authentication before performing updates. When access control to trusted computing base components is discretionary, a malicious user or program who obtains the necessarily privileges can circumvent security controls on the device. This likely enables the malicious user or process to obtain sensitive data and launch attacks on other systems. Privilege elevation on discretionary access control (DAC) systems can occur in a variety of ways that cannot be detected by the operating system or intrusion detection software. MAC systems preclude the possibility of this sort of privilege elevation by design and therefore greatly reduce the risk of system security breaches.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32915",
+      "title": "The mobile operating system must enforce a mandatory access control (MAC) policy that prohibits any application from having both write and execute permissions to a file on the device.",
+      "description": "System integrity is dependent on properly controlling what software is executable. When programs are permitted to create or modify files and then subsequently execute those same files, this enables these programs to circumvent controls on the system designed to prevent malicious code execution. A rogue application that has the ability to both write and execute a file can perform a variety of unauthorized actions that could not have been anticipated when the application was authorized for installation. Such actions might include the ability to exfiltrate sensitive data on the device and to perform attacks on other systems. Preventing this behavior through the implementation of an appropriate MAC policy greatly mitigates the risk of this attack.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32916",
+      "title": "The mobile operating system must enforce a mandatory access control (MAC) policy that prohibits any application from accessing the data or code of another application unless such data or code has been expressly allowed by the policy to be a shared resource.",
+      "description": "When an application has the ability to access the data and code of another application, it may use that access improperly to obtain sensitive DoD data or perform unauthorized functions, including attacks on the mobile device and possibly remote systems as well. Most malware depends on this type of unauthorized access to carry out its malicious objectives. MAC-based application sandboxing or isolation greatly reduces the ability of malware to compromise system security.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32917",
+      "title": "The operating system must prevent access to organization defined security-relevant information except during secure, non-operable system states.",
+      "description": "Security-relevant information is any information within the information system potentially impacting the operation of security functions in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Organizations may define specific security relevant information requiring protection.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32918",
+      "title": "The operating system must enforce information flow control using explicit security attributes on information, source, and destination objects as a basis for flow control decisions.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32919",
+      "title": "The operating system must enforce information flow control using protected processing domains (e.g., domain type enforcement) as a basis for flow control decisions.",
+      "description": "Protected processing domains can be used to separate different data types. The operating system must enforce information flow control to ensure information does not pass into domains that are not authorized to process it.\n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32920",
+      "title": "The operating system must enforce dynamic information flow control based on policy that must allow or disallow information flows based upon changing conditions or operational considerations.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32921",
+      "title": "The operating system must prevent encrypted data from bypassing content checking mechanisms.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32922",
+      "title": "The operating system must enforce organization defined limitations on the embedding of data types within other data types.",
+      "description": "The operating system must enforce organization defined limitations on the embedding of data types within other data types.\n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32923",
+      "title": "The operating system must enforce information flow control on metadata.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32924",
+      "title": "The operating system must support organization defined one-way flows using hardware mechanisms.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32925",
+      "title": "The operating system must enforce information flow control using organization defined security policy filters as a basis for flow control decisions.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32926",
+      "title": "The operating system must provide the capability for a privileged administrator to enable/disable organization defined security policy filters.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32927",
+      "title": "The operating system must provide the capability for a privileged administrator to configure the organization defined security policy filters to support different security policies.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32929",
+      "title": "The operating system must implement separation of duties through assigned information system access authorizations.",
+      "description": "Separation of duties is a prevalent Information Technology control implemented at different layers of the information system, including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires the person accountable for approving an action is not the same person who is tasked with implementing or carrying out the action. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32930",
+      "title": "The mobile operating system must audit any use of privileged accounts, or roles, with access to organization defined security functions or security relevant information, when accessing other system functions.",
+      "description": "This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32932",
+      "title": "The operating system must enforce the organization defined limit of consecutive invalid access attempts by a user during the organization defined time period.",
+      "description": "Anytime an authentication method is exposed, allowing for the utilization of an operating system, there is a risk that attempts will be made to obtain unauthorized access. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001383, which requires purging information from the device after multiple unsuccessful unlock attempts to the mobile device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32933",
+      "title": "The operating system, when the maximum number of unsuccessful attempts is exceeded, must automatically lock the account for an organization defined time period or must lock the account until released by an administrator IAW organizational policy.",
+      "description": "Anytime an authentication method is exposed to allow for the utilization of an operating system, there is a risk that attempts will be made to obtain unauthorized access. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001383, which requires purging information from the device after multiple unsuccessful unlock attempts to the mobile device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32934",
+      "title": "The mobile operating system must display the DoD warning banner exactly as specified at startup device unlock.",
+      "description": "The operating system is required to display the DoD approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. \n\nSystem use notification messages can be displayed when individuals log in to the information system. The approved DoD text must be used as specified in the DoD CIO memorandum dated 9 May 2008 (see the check text for required wording).",
+      "severity": "low"
+    },
+    {
+      "id": "V-32935",
+      "title": "The mobile operating system must retain the notification message or banner on the screen preventing further activity until the user executes a positive action to manifest agreement by selecting a box indicating acceptance.",
+      "description": "To establish acceptance of system usage policy, a click-through banner at startup device unlock is required. The banner must prevent further activity on the application unless and until the user executes a positive action to manifest agreement by clicking the indicated acceptance. By preventing access to the system until the user accepts the conditions, legal requirements are met to protect the DoD and to remind users the device is designed and implemented for business use.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32936",
+      "title": "The mobile operating system, upon successful startup unlock, must display to the user the date and time of the last successful unlock or access.",
+      "description": "Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the date and time of their last successful startup unlock allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32939",
+      "title": "The mobile operating system, upon successful unlock, must display to the user the number of unsuccessful unlock attempts since the last successful device unlock.",
+      "description": "Users need to be aware of activity that occurs regarding their mobile device. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32941",
+      "title": "The operating system must limit the number of concurrent sessions for each account to an organization defined number of sessions.",
+      "description": "Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. The organization may define the maximum number of concurrent sessions for an information system account globally, by account type, by account, or a combination thereof. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32943",
+      "title": "The mobile operating system must retain the device lock until the user reestablishes access using established identification and authentication procedures.",
+      "description": "The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.\n\nA device lock is a temporary action taken when a user stops work but does not want to log out because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.\n\nThe operating system must enforce a device lock function. This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information. The identification and authentication procedure configuration must be set by a Mobile Device Management (MDM) service and be sufficiently complex to protect sensitive data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32944",
+      "title": "The mobile operating system must lock the device following a minimum, organizationally-defined period of inactivity.",
+      "description": "The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.\n\nA device lock is a temporary action taken when a user stops work but does not want to shut down because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.\n\nThe operating system must lock the device after the organizationally-defined time period. This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information. A device lock mitigates the risk that an adversary can access data on an unattended mobile device but only after the minimum, organizationally-defined period of inactivity.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32945",
+      "title": "The mobile operating system must permit the user to directly initiate device lock.",
+      "description": "The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.\n\nA device lock is a temporary action taken when a user stops work but does not want to log out because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.\n\nThe operating system must lock the device when the user determines it necessary (e.g., the device will temporarily be outside of the user's possession). This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32946",
+      "title": "The mobile operating system device lock, when activated on a device, must place a publicly viewable pattern onto the associated display, hiding what was previously visible on the screen.",
+      "description": "The device lock function prevents further access to the system by initiating a session lock after a period of inactivity or upon receiving a request from a user. The device lock is retained until the user reestablishes access using established identification and authentication procedures.\n\nA device lock is a temporary action taken when a user stops work but does not want to log out because of the temporary nature of the hiatus. During the device lock a publicly viewable pattern is visible on the associated display, hiding what was previously visible on the screen. Once invoked, the device lock shall remain in place until the user re-authenticates. No other system activity aside from re-authentication can unlock the system.\n\nThe operating system must lock the device with a publicly viewable pattern visible on the associated display, hiding what was previously visible on the screen. This prevents others from gaining access to the device when not in the user's possession and accessing sensitive DoD information. Publicly viewable patterns can include screen saver patterns, photographic images, solid colors, or a blank screen, so long as none of those patterns convey sensitive information. Non-sensitive device information, such as battery life, signal strength, and time/date, may be viewable as part of a publically viewable pattern. However, system notifications, user or contact information must not be viewable because they may reveal owner or organizational information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32948",
+      "title": "The operating system must employ automated mechanisms to facilitate the monitoring and control of remote access methods.",
+      "description": "Remote network access is accomplished by leveraging common communication protocols to establish a remote connection. \n\nRationale for non-applicability: When the mobile OS is performing remote access to a DoD network, remote access limitations are enforced at the enclave boundary, not on the mobile OS. In some cases, the mobile OS will support remote access of other devices to the device running the mobile OS (e.g., the personal hotspot use case, and USB tethering). SRG-OS-000229-MOS-000117 (corresponding to CCI-000370) better addresses this case. Automated mechanisms to monitor these special cases of remote access are not necessary given authentication requirements and the highly localized nature of the remote access.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32949",
+      "title": "The mobile operating system must use cryptography to protect the confidentiality of remote access sessions.",
+      "description": "Remote network access is accomplished by leveraging common communication protocols to establish a remote connection. These connections typically will occur over the public Internet.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32950",
+      "title": "The operating system must monitor for unauthorized connections of mobile devices to organizational information systems.",
+      "description": "Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, audio recording devices). \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32951",
+      "title": "The mobile operating system must not automatically execute applications without user direction.",
+      "description": "Auto execution vulnerabilities can result in malicious programs being automatically executed. Examples of information system functionality providing the capability for automatic execution of code are Auto Run and Auto Play. Auto Run and Auto Play are components of the Microsoft Windows operating system that dictate what actions the system takes when a drive is mounted. This requirement is designed to address vulnerabilities that arise when mobile devices are automatically mounted and applications are automatically invoked without user knowledge or acceptance.\n\nApplications that can be executed without user (or mobile device management) direction may be used to access sensitive information or otherwise compromise system integrity to launch subsequent attacks. Requiring the user take action to permit the execution of an application makes it more likely that malware will be identified and kept off of mobile devices.",
+      "severity": "high"
+    },
+    {
+      "id": "V-32952",
+      "title": "The operating system must employ automated mechanisms to enable authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared.",
+      "description": "Depending on the information sharing circumstance, the sharing partner may be defined at the individual, group, or organization level and information may be defined by specific content, type, or security categorization.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32953",
+      "title": "The mobile operating system must produce audit records containing the severity level of each recorded event.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nWithout sufficient information establishing what type of audit events occurred, investigation into the severity of events is severely hindered. As defined in RFC 5424 \"The Syslog Protocol\", event severity levels allow system administrators and IA personnel to more easily identify critical system issues.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32954",
+      "title": "The mobile operating system must produce audit records containing date and timestamps (to one second resolution) for every event.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nWithout sufficient information establishing when the audit events occurred, investigation into the cause of events is severely hindered. The inclusion of timestamps enables correlation of events across disparate systems, which can be critical to isolating IA incidents and developing appropriate countermeasures. Date and timestamp should be from a global time reference format to ensure geographic changes do not distort records.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32955",
+      "title": "The mobile operating system must include the software component (e.g., user application, or operating system security module) that generated each event in audit logs.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nWithout sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered. The inclusion of software component generating each event in the audit logs enables system administrators and IA personnel to identify where the audit events occurred.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32956",
+      "title": "The operating system must produce audit records containing sufficient information to establish the sources of the events.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000132, which is functionally indistinguishable from CCI-000133.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32957",
+      "title": "The mobile operating system must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nSuccess and failure indicators ascertain the outcome of a particular event. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32958",
+      "title": "The mobile operating system must include organization defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nThe audit configuration must be adaptable to include organization defined additional, more detailed information in the audit records for audit events identified by type, location, or subject. Examples of this information include VPN state, communications interface, and duration of event.\n\nRationale for non-applicability: The DoD value of full-text recording of privileged commands or the individual identities of group account users is written primarily for traditional OS (particularly UNIX systems) and typically does not apply in the mobility context where shell commands and group accounts might not be available.  Furthermore, this requirement is adequately covered by the following three requirements: \n\nSRG-OS-000037-MOS-000013\nSRG-OS-000049-MOS-000015\nSRG-OS-000041-MOS-000016\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-32959",
+      "title": "The mobile operating system must transfer audit logs to remote log or management servers.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nCentralized management of audit records and logs provides for efficiency in maintenance of records, as well as, the backup and archiving of those records. When organizations define application components that require requiring centralized audit log management, operating systems need to support the requirement.\n\nThe ability to transfer audit records from the mobile device to a remote log or management server protects their integrity and provides a centralized location to analyze their contents.",
+      "severity": "high"
+    },
+    {
+      "id": "V-32960",
+      "title": "The mobile operating system must allocate sufficient audit record storage capacity for 24 hours of operation.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nIt is imperative the operating system configured, allocate storage capacity to contain audit records. Without adequate storage for audit records, there is the potential that critical audit records will be lost or overwritten. An adversary may be able to take advantage of lack of audit storage capacity to avoid detection. Allocating sufficient audit record storage capacity for 24 hours allows the device to capture critical events even if it is unable to reach the MDM for a full day, such as when an employee may be temporarily in a remote location. The mobile operating system must be capable of allocating sufficient record storage capacity for mission needs. Make sure that the reserved audit capacity is greater than the log size for the day with the greatest log activity. It is advised that the allocated storage capacity be at least 150% of that needed for the most active day observed. Also use other available information resources (e.g., vendor documentation) to determine appropriate required capability based on industry norms.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32961",
+      "title": "The mobile operating system must send alerts to the mobile device management server when the audit log size reaches an organization defined critical percentage of capacity and full capacity.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nCare must be taken to evaluate that the audit records being produced do not exceed the storage capacity. Alerting the mobile device management server when audit log size thresholds are exceeded helps appropriate personnel to respond to heavy activity in a timely manner. Failure to alert increases the probability that an adversary's actions will go undetected.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32962",
+      "title": "The mobile operating system must alert the mobile device management server in the event of an audit processing failure.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.\n\nWhen an audit process failure occurs, it is imperative for the mobile device management (MDM) server to be notified, which can direct this information to the appropriate person or process.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32963",
+      "title": "The mobile operating system must overwrite the oldest audit log entries when audit logs reach capacity.",
+      "description": "It is critical when a system is at risk of failing to process audit logs as required; it detects and takes action to mitigate the failure. Overwriting the oldest audit log entries is the best course of action in the context of the limited resources available on a mobile device that may not have network connectivity.\n\nThe mobile operating system must continue generating audit records while overwriting the oldest audit records in a first-in, first-out manner in the event the audit service failure was caused by the lack of audit record storage capacity. Mobile devices send event audit records to remote log or management servers. Should communications with this server be lost or the server fails, the mobile operating system must queue audit records locally until communications is restored or until the audit records are retrieved manually.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32964",
+      "title": "The mobile operating system must provide a warning to the mobile device management server when allocated audit record storage volume reaches an organization defined percentage of maximum audit record storage capacity.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. \n\nIf audit log capacity were to be exceeded then events that subsequently occur will not be recorded. By warning the mobile device management server that storage space for audit records has reached or exceeded the organizationally defined percentage, appropriate personnel and processes can take corrective action. The mobile operating system should also notify the user in the event intermittent network connectivity is causing the queued audit records to exceed local storage space.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32965",
+      "title": "The mobile operating system must provide a real-time alert to the mobile device management server when organization defined audit failure events occur.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. \n\nOrganizations must define audit failure events requiring an alarm. When those defined events occur, the mobile operating system must provide a real-time alert to the mobile device management server. By warning the mobile device management server that an audit failure event occurred, appropriate personnel and processes can take corrective action. The mobile operating system should also notify the user in the event intermittent network connectivity is causing the audit failure event.\n\nRationale for non-applicability: a Mobile Operating System does not have a persistent connection; some parts of the Operating System are not always active, and thus cannot perform real-time checks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32966",
+      "title": "The operating system must support the capability to centralize the review and analysis of audit records from multiple components within the system.",
+      "description": "Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000136, which deals with central log management for the remote log or management server to combine the records, not the mobile device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32967",
+      "title": "The operating system must support an audit reduction capability.",
+      "description": "Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000136, which covers this on central log management because log servers will perform report generation and audit reduction.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32968",
+      "title": "The operating system audit records must be able to be used by a report generation capability.",
+      "description": "Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify a network element that has been configured improperly. In order to determine what is happening within the network infrastructure or to resolve and trace an attack, it is imperative to correlate the log data from multiple network elements to acquire a clear understanding as to what happened or is happening. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000136, which implicitly covers this on central log management because log servers will reformat log data as required to generate reports.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32970",
+      "title": "The operating system must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria.",
+      "description": "Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000136, which covers this on central log management because log servers will perform report generation and audit reduction.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32971",
+      "title": "The mobile operating system must use internal system clocks to generate timestamps for audit records.",
+      "description": "Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. \n\nTimestamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The internal system clock is an acceptable source to ensure consistency of time across functions that use time to generate audit records.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32972",
+      "title": "The mobile operating system must synchronize the internal clock on an organizationally-defined periodic basis with an authoritative time server or the Global Positioning System.",
+      "description": "Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events. \n\nPeriodically synchronizing internal clocks with an authoritative time source is needed in order to correctly correlate the timing of events that occur across the enterprise. The two authoritative time sources for mobile operating systems are an authoritative time server which is synchronized with redundant United States Naval Observatory (USNO) time servers as designated for the appropriate DoD network (NIPRNet or SIPRNet) or the Global Positioning System (GPS).\n\nTimestamps generated by the audit system in mobile operating systems shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32973",
+      "title": "The mobile operating system must protect audit information from unauthorized read access.",
+      "description": "If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. \n\nTo ensure the veracity of audit data the mobile operating system must protect audit information from unauthorized access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files have the proper file system permissions utilizing file system protections and limiting log data location. \n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity. Mobile device users will need read access to audit log records for troubleshooting and all records must be sent to a remote log or management server. Audit records must be protected from unauthorized read access through device interfaces.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32975",
+      "title": "The mobile operating system must protect audit information from unauthorized modification.",
+      "description": "If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. \n\nTo ensure the veracity of audit data the mobile operating system must protect audit information from unauthorized access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files have the proper file system permissions utilizing file system protections and limiting log data location. \n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity. Mobile device users must not have modification rights to audit information and all records must be sent to a remote log or management server. Audit records must be protected from unauthorized modification access through device interfaces.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32976",
+      "title": "The mobile operating system must protect audit information from unauthorized deletion.",
+      "description": "If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. \n\nTo ensure the veracity of audit data the mobile operating system must protect audit information from unauthorized access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files have the proper file system permissions utilizing file system protections and limiting log data location. \n\nAudit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity. Mobile device users must not delete audit log records and all records must be sent to a remote log or management server. Audit records must be protected from unauthorized deletion.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32977",
+      "title": "The operating system must produce audit records on hardware-enforced, write-once media.",
+      "description": "The protection of audit records from unauthorized or accidental deletion or modification requires the operating system produce audit records on hardware-enforced write-once media.\n\nRationale for non-applicability: Mobile devices operate outside of enclave boundary. They do not have access to hardware-based audit solutions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32978",
+      "title": "The operating system must protect against an individual falsely denying having performed a particular action.",
+      "description": "Non-repudiation of actions taken is required in order to maintain integrity. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account, which obviates the need for non-repudiation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32979",
+      "title": "The mobile operating system must provide audit record generation capability for the auditable events defined at the organizational level for the mobile device.",
+      "description": "The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events) for example, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nMobile operating systems must produce audit records for the events defined at the organizational level. Specifically, at a minimum, audit records must be produced for these events:\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels) by processes other than the operating system\n- Successful and unsuccessful unlock attempts\n- Privileged activities or other system level access\n- Starting and ending time for user access to the system\n- All application initiations\n- All application installation and removal\n- All account creations, modifications, disabling, and terminations\n- All kernel module load, unload, and restart",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32980",
+      "title": "The mobile operating system must allow organizational personnel through mobile device management services to select which auditable events are to be audited by the mobile operating system.",
+      "description": "The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). \n\nOrganizations will define the organizational personal accountable for selecting auditable events. The mobile operating system must allow the designated personnel to select the items to be audited through mobile device management services.\n\nRationale for non-applicability: It is unnecessary for the mobile operating system to perform this function because all the necessary selections and filtering can be performed by the MDM or audit system that retrieves the logs from the device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32981",
+      "title": "The mobile operating system must generate audit records for the DoD-required auditable events.",
+      "description": "The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events) for example, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nMobile operating systems must produce audit records for the events defined at the organizational level. Specifically, at a minimum, audit records must be produced for these events:\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels) by processes other than the operating system\n- Successful and unsuccessful unlock attempts\n- Privileged activities or other system level access\n- Starting and ending time for user access to the system\n- All application initiations\n- All application installation and removal\n- All account creations, modifications, disabling, and terminations\n- All kernel module load, unload, and restart",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32982",
+      "title": "The operating system must support the capability to compile audit records from multiple components within the system into a system-wide (logical or physical) audit trail that is time-correlated to within organization defined level of tolerance.",
+      "description": "Audit generation and audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000136, which deals with central log management. An MDM or log tool will combine the records, not the mobile device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32983",
+      "title": "The mobile operating system, for PKI-based authentication must validate certificates by querying the certification authority for revocation status of the certificate.",
+      "description": "Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Failure to verify a certificate's revocation status can result in the system accepting a revoked or otherwise unauthorized certificate resulting in installation of unauthorized software or connection to rogue networks. Querying for certificate revocation mitigates the risk that the system will accept an unauthorized certificate.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32985",
+      "title": "The mobile operating system must notify the user if it cannot verify the revocation status of the certificate.",
+      "description": "If the user is aware that the revocation status of a certificate could not be verified, the user is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence makes it more likely that an adversary can use revoked certificates without detection.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32986",
+      "title": "The mobile operating system must give the user the option to deny acceptance of a certificate if it cannot verify the certificates revocation status.",
+      "description": "When additional assurance is required, the system should deny acceptance of a certificate if it cannot verify its revocation status. Otherwise, there is the potential that it is accepting the credentials of an unauthorized system. Allowing the operating system or user to deny certificates with unverified revocation status mitigates the risk associated with the acceptance of such certificates.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32987",
+      "title": "The mobile operating system must alert the user when it receives a public-key certificate issued from an untrusted certificate authority.",
+      "description": "If the user is aware that a certificate has been issued from an untrusted certificate authority, the user can opt not to proceed or, alternatively, is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence each time it occurs makes it more likely that an adversary can launch an attack from an untrusted system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32989",
+      "title": "The mobile operating system must give the user the option to deny acceptance of a certificate if the certificate was issued by an untrusted certificate authority.",
+      "description": "When the operating system accepts the use of certificates issued from an untrusted certificate authority, there is the potential that the system presenting the certificate is malicious, and can compromise sensitive information or system integrity. Allowing the operating system or user to deny certificates from an untrusted certificate authority mitigates the risk associated with the acceptance of such certificates.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32990",
+      "title": "The mobile operating system must alert the user if it receives an invalid public-key certificate.",
+      "description": "If the user is aware that a certificate is invalid, the user can opt not to proceed or, alternatively, is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence each time it occurs makes it more likely that an adversary can launch an attack from an untrusted system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32991",
+      "title": "The mobile operating system must give the user the option to deny acceptance of a certificate if the mobile operating system determines that the certificate is invalid.",
+      "description": "If the user is aware that a certificate is invalid, the user can opt not to proceed or, alternatively, is better prepared to identify suspicious behavior that indicates an IA incident is in progress. Failure to notify the user of this occurrence makes it more likely that an adversary can launch an attack from an untrusted system. If the mobile operating system accepts the use of invalid certificates, the potential exists the system presenting the certificate is malicious, and can compromise sensitive information or system integrity. Allowing the operating system or user to deny invalid certificates mitigates the risk associated with the acceptance of such certificates.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32992",
+      "title": "The mobile operating system must not accept certificate revocation information without verifying its authenticity.",
+      "description": "If the operating system does not verify the authenticity of revocation information, there is the potential that an authorized system is providing false information. Acceptance of the false information could result in the installation of unauthorized software or connection to rogue networks, depending on the use for which the certificate is intended. Verifying the authenticity of revocation information mitigates this risk.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32993",
+      "title": "The mobile operating system must require authentication to access private keys saved in the key certificate store.",
+      "description": "The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user. \n\nAllowing unauthenticated access to private keys can enable an adversary in possession of the device to decrypt messages encrypted with the public key and to digitally sign data, thereby potentially enabling an adversary to impersonate the user in any application that uses that private key for user authentication. Requiring authentication to access keys saved in the certificate store mitigates the risk of unauthorized access. The passcode must be entered upon each access of the key store, although passcodes may be cached for a period of up to two hours.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32994",
+      "title": "The mobile operating system must enforce complexity requirements for the authentication to access private keys saved in the key certificate stores.",
+      "description": "The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can impersonate the authorized user. \n\nAllowing unauthenticated access to private keys can enable an adversary in possession of the device to decrypt messages encrypted with the public key and to digitally sign data, thereby potentially enabling an adversary to impersonate the user in any application that uses that private key for user authentication. Requiring complexity requirements for the authentication to access keys saved in the certificate store protects sensitive information. A weak password may enable an adversary to crack it, and give it the ability to use the private key to decrypt sensitive information or improperly impersonate the user of the device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32995",
+      "title": "The mobile operating system browser must support public-key certificate-based authentication to remote information systems.",
+      "description": "The cornerstone of the PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information. The authenticated identity must be mapped to an account for access and authorization decisions.\n\nThis capability strengthens authentication to remote information systems and thus makes it less likely that such systems will be compromised. Mobile devices without default PKI authentication capability in the browser may mitigate this through the use of authorized third-party browsers.",
+      "severity": "low"
+    },
+    {
+      "id": "V-32996",
+      "title": "The mobile operating system must disallow the device unlock password from containing less than an organizationally-defined minimum number of upper case alphabetic characters.",
+      "description": "Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Setting minimum numbers of certain types of characters increases password complexity, and therefore makes it more difficult for an adversary to discover the password. In the DoD, the expectation is that the setting will range from a minimum of 1 to 2 upper case alphabetic characters in the device unlock password. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32997",
+      "title": "The mobile operating system must disallow the device unlock password from containing an organizationally-defined minimum number of lower case alphabetic characters.",
+      "description": "Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Setting minimum numbers of certain types of characters increases password complexity, and therefore makes it more difficult for an adversary to discover the password. In the DoD, the expectation is that the setting will range from a minimum of 1 to 2 lower case characters in the device unlock password. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32998",
+      "title": "The mobile operating system must disallow the device unlock password from containing an organizationally-defined minimum number of numeric characters.",
+      "description": "Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Setting minimum numbers of certain types of characters increases password complexity, and therefore makes it more difficult for an adversary to discover the password. In the DoD, the expectation is that the setting will range from a minimum of 1 to 2 numeric characters in the device unlock password. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-32999",
+      "title": "The mobile operating system must force the user to change an organizationally-defined minimum number of characters of the device unlock password whenever the passcode is changed.",
+      "description": "If an adversary learns part or all of a password, the adversary can use this information to more easily crack a user's subsequent passwords if the passwords do not differ significantly from one to the next. Requiring a user to change a specified minimum of characters in the password is an effective way of preserving the protection provided by password complexity in this context.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33000",
+      "title": "The mobile operating system must encrypt passwords stored on the mobile device.",
+      "description": "Passwords need to be protected at all times and encryption is the standard method for protecting passwords while in storage so unauthorized users/processes cannot gain access. If an adversary obtains a password, the adversary can use it to compromise sensitive information. Encrypting passwords stored on the device mitigates the risk that the passwords will be compromised. Encryption methodologies such as secure hashing are suitable for DoD password encryption and are compliant with FIPS 140-2 security requirements. Super user access is typically required to access the password database. If a system administrator is able to obtain this level of privilege on the device, have the system administrator display the contents of the password database, often a simple file.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33001",
+      "title": "The mobile operating system must not transmit passwords in clear text.",
+      "description": "Transmission of passwords in clear text reveals the password to any adversary who can successfully eavesdrop on the communication. In the case of wireless communication, the ability to eavesdrop is available to anyone within the range of the device's radio signal, which in some cases can be miles. Once an adversary has obtained a password, the adversary may be able to use it to compromise sensitive DoD information or other DoD information systems. Using methods that avoid the transmission of passwords in clear text mitigates the risk of this attack. The OS may be reliant on an external function or that present in the OS’ browser to enforce the password encryption function.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33002",
+      "title": "The operating system must enforce minimum password lifetime restrictions.",
+      "description": "Passwords need to be changed at specific policy based intervals, however if the information system or application allows the user to immediately and continually change their password then the password could be repeatedly changed in a short period of time defeating the organization's policy regarding password reuse.\n\nRationale for non-applicability: Risk environment for mobility does not require minimum password age in the field.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33003",
+      "title": "The operating system must enforce maximum password lifetime restrictions.",
+      "description": "Passwords need to be changed at specific policy based intervals. Any password no matter how complex can eventually be cracked.\n\nRationale for non-applicability: Changing passwords regularly prevents an attacker who has compromised the password from re-using it to regain access. This is an unlikely scenario on a mobile device because these devices do not have a remote logon capability that would facilitate either stealth use of the device or a brute force or dictionary password attack.  Wiping the device after 10 unsuccessful logon attempts mitigates the risk of a password attack more effectively than a password rotation scheme.  Additionally, NSA guidance for CMDs no longer requires password aging and password history settings. NSA guidance for CMDs no longer requires password aging and password history settings.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33004",
+      "title": "The operating system must prohibit password reuse for the organization-defined number of generations.",
+      "description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute force attacks. The mobile operating system must prohibit a user from reusing any of the last five previously used device unlock passwords.\n\nRationale for non-applicability: Changing passwords regularly prevents an attacker who has compromised the password from re-using it to regain access. This is an unlikely scenario on a mobile device because these devices do not have a remote logon capability that would facilitate either stealth use of the device or a brute force or dictionary password attack.  Wiping the device after 10 unsuccessful logon attempts mitigates the risk of a password attack far more effectively than a password rotation scheme.  Additionally, NSA guidance for CMDs no longer requires password aging and password history settings. NSA guidance for CMDs no longer requires password aging and password history settings.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33005",
+      "title": "The mobile operating system must enforce a minimum length for the device unlock password.",
+      "description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute force attacks. The ability to crack a password is a function of how many attempts an adversary is permitted, how quickly an adversary can do each attempt, and the size of the password space. The longer the minimum length of the password is, the larger the password space.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33006",
+      "title": "The operating system must enforce approved authorizations for logical access to the system in accordance with applicable policy.",
+      "description": "Strong access controls are critical to securing data. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by the operating system when applicable to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the operating system.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33007",
+      "title": "The operating system, when transferring information between different security domains, must identify information flows by data type specification and usage.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33008",
+      "title": "The operating system, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33009",
+      "title": "The operating system must enforce security policies regarding information on interconnected systems.",
+      "description": "The operating system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33010",
+      "title": "The mobile operating system must notify mobile device management services of certificate failures related to digital signatures on software applications or components.",
+      "description": "A certificate failure related to a digital signature on software applications or components is strong evidence of a system breach. Notifying mobile device management services of such an occurrence allows the enterprise to assess the situation, contain the breach if one exists, and possibly invoke incident response procedures.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33011",
+      "title": "The mobile operating system must notify the user of certificate failures related to digital signatures on software applications or components.",
+      "description": "A certificate failure related to a digital signature on software applications or components is strong evidence of a system breach. Notifying the user of such an occurrence allows the user to notify the user's technical support personnel and IAO, as well as proceed with caution regarding activities performed on the device. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33012",
+      "title": "The operating system must provide the capability for a privileged administrator to configure organization defined security policy filters to support different security policies.",
+      "description": "In order to control changes in policy, a privileged administrator must be able to change policy filters to support different security policies.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000370, which deals with central management of security settings.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33013",
+      "title": "The mobile operating system must provide mutual authentication between the provisioning server and the provisioned device during a trusted over-the-air (OTA) provisioning session.",
+      "description": "Provisioning data includes operating system configuration, key material, and other initialization data. It may be sensitive and therefore must be adequately protected. An adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place. Proper use of cryptography provides strong assurance that provisioning data is protected against confidentiality attacks. \n\nWhen dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system. Mutual authentication ensures both that the device is authorized for provisioning and that a rogue provisioning server is not used to obtain software. In this context, provisioning refers to configuration elements specific to the organization and user, and not installation of the base mobile OS. One way to ensure authentication of the server is to require that the MOS point to a specified URL for the provisioning process, and authenticate the URL-specified server using SSL/TLS.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33014",
+      "title": "The mobile operating system must protect the confidentiality of the provisioning data while downloading to the mobile device during a trusted over-the-air (OTA) provisioning session.",
+      "description": "Provisioning data includes operating system configuration, key material, and other initialization data. It may be sensitive and therefore must be adequately protected. An adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place.\n\nAn adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place. Proper use of cryptography provides strong assurance that provisioning data is protected against confidentiality attacks.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33015",
+      "title": "The mobile operating system must protect the integrity of the provisioning data while downloading to the mobile device during a trusted over-the-air (OTA) provisioning session.",
+      "description": "Provisioning data includes operating system configuration, key material, and other initialization data. It may be sensitive and therefore must be adequately protected. An adversary within the general proximity of the mobile device can eavesdrop on OTA transactions, making them particularly vulnerable to attack if confidentiality protections are not in place.\n\nIt may be possible for an adversary within the general proximity of the mobile device to hijack provisioning sessions and modify data transmitted during the provisioning process. Proper use of cryptography provides strong assurance that provisioning data is protected against integrity attacks.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33016",
+      "title": "The mobile operating system must support the capability for the system administrator to disable over-the-air (OTA) provisioning.",
+      "description": "In some environments, the risk of OTA provisioning may outweigh any convenience benefit it offers. In such cases, the administrator should have the ability to disable OTA provisioning to ensure security breaches do not occur from use of this technique.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33050",
+      "title": "The operating system must employ automated mechanisms to enforce access restrictions.",
+      "description": "When dealing with access restrictions pertaining to change control, it should be noted that, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nRationale for non-applicability: This vulnerability is better addressed by implementing CCI-000370, which states the mobile operating system must employ the capability of a Mobile Device Manager (MDM) to centrally manage configuration settings, including security policies. These security policies include policy related to discretionary access controls.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33051",
+      "title": "The operating system must employ automated mechanisms to support auditing of the enforcement actions.",
+      "description": "Some operating system features, including security enforcement, may only be modified when the operating system is not running. Logging startup events provides valuable information on system problems and potential OS integrity issues.\n\nRationale for non-applicability: This IA control requirement is better addressed by CCI-000172, which includes audit functionality related to configuration management.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33052",
+      "title": "The mobile operating system must prevent the installation of applications that are not digitally signed with a DoD approved private key.",
+      "description": "Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Digital signatures on code provide assurance that the code comes from a known source and has not been modified.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33053",
+      "title": "The operating system must enforce a two-person rule for changes to organization defined information system components and system-level information.",
+      "description": "Regarding access restrictions for changes made to organization defined information system components and system level information. Any changes to the hardware, software, and/or firmware components of the operating system can potentially have significant effects on the overall security of the system. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. In this context, a two-person rule is not relevant. Changes resulting from MDM control of the device are within the scope of the MDM SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33054",
+      "title": "The operating system must employ automated mechanisms to centrally apply configuration settings.",
+      "description": "Configuration settings are the configurable security-related parameters of operating system. \n\nRationale for non-applicability: This vulnerability is better addressed by implementing CCI-000370, which states the mobile operating system must employ the capability of a Mobile Device Manager (MDM) to centrally manage configuration settings, including security policies. These security policies include policy related to discretionary access controls.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33055",
+      "title": "The operating system must employ automated mechanisms to centrally verify configuration settings.",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. \n\nRationale for non-applicability: This vulnerability is better addressed by implementing CCI-000370, which states the mobile operating system must employ the capability of a Mobile Device Manager (MDM) to centrally manage configuration settings, including security policies. These security policies include policy related to discretionary access controls.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33056",
+      "title": "The operating system must employ automated mechanisms to respond to unauthorized changes to organization defined configuration settings.",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001297, which addresses responding to unauthorized changes to software and data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33057",
+      "title": "The mobile operating system must not permit a user to remove organizationally required applications.",
+      "description": "Organizationally required applications are present on the device because they support the organization's mission. Therefore, their absence degrades mission performance. Preventing the removal of such applications provides mission assurance. The primary focus of this control concerns IA applications that monitor the integrity of software on the mobile device and enforce configuration controls. Removal of these applications would significantly degrade the IA posture of the device. Therefore, not permitting a user to remove them is critical to IA. In cases in which such applications cannot be removed, an acceptable alternative to mitigate risk is to prevent access to DoD resources when the required applications are not present.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33058",
+      "title": "The mobile operating system must not permit mobile service carriers to have privileged access to the operating system or perform any function not directed by the user.",
+      "description": "Permitting mobile service carriers access to the mobile operating system leaves the device vulnerable to breach from rogue elements within the carrier infrastructure. Mobile service carriers are not subject to the same personnel, operational, and technical controls as DoD organizations. For example, its employees in most cases do not have active DoD clearances. When a mobile service carrier must update software or configuration on a mobile device, these updates must come from a DoD approved source, which in many cases is the vendor of the MOS software. Preventing mobile service carrier access to mobile operating systems greatly mitigates the risk associated with this vulnerability.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33059",
+      "title": "The operating system must configure the information system to specifically prohibit or restrict the use of organization defined functions, ports, protocols, and/or services.",
+      "description": "Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions) or may present unacceptable risk into the information system environment.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001118, which refers to mobile device boundary protection, specifically with respect to the filtering of inbound and outbound traffic based on IP address and UDP/TCP port.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33060",
+      "title": "The mobile operating system must verify the integrity of application software before each instance of its execution.",
+      "description": "A common method to compromise system security is to modify application software to perform malicious functions that will execute when the user runs the application. Verifying the integrity of the software before execution protects against such an attack. This is typically accomplished by checking cryptographic hashes or digital signatures on software program files.\n\nRationale for non-applicability: the feature as described is more suited for a Mobile Device Manager (MDM) to implement as opposed to an OS. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33061",
+      "title": "The mobile operating system must detect the addition of unauthorized hardware components and peripherals at start up and when they are attached.",
+      "description": "Unauthorized hardware components and peripherals include memory cards, SIM cards, and USB attachments. If the user or an adversary is able to add or attach unauthorized components to a device, then those components may be used to compromise other components or perform prohibited functions. The addition of the unauthorized component may also cause the system to behave in unintended ways, perhaps degrading the performance of mission-critical applications. Detecting the addition of unauthorized components allows for roll-back to the previous state.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33062",
+      "title": "The operating system must conduct backups of user-level information contained in the operating system per organization defined frequency to conduct backups consistent with recovery time and recovery point objectives.",
+      "description": "Operating system backup is a critical step in maintaining data assurance and availability. \n\nRationale for non-applicability: Similar to user workstations and laptops, mobile devices are not expected to have backup of user-level data. On some mobile OS, backup is infeasible for anything other than shared data because applications are not permitted to access the data of other applications. Applications that require backup can include backup functionality within the application or use cloud-based storages solutions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33063",
+      "title": "The operating system must conduct backups of system-level information contained in the information system per organization defined frequency to conduct backups that are consistent with recovery time and recovery point objectives.",
+      "description": "Operating system backup is a critical step in maintaining data assurance and availability. \n\nRationale for non-applicability: Mobile devices do not have assured network connectivity. This type of documentation is readily available elsewhere.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33064",
+      "title": "The operating system must conduct backups of operating system documentation including security-related documentation per organization defined frequency to conduct backups that is consistent with recovery time and recovery point objectives.",
+      "description": "Operating system backup is a critical step in maintaining data assurance and availability. \n\nRationale for non-applicability: Mobile devices do not have assured network connectivity. This type of documentation is readily available elsewhere.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33066",
+      "title": "The operating system must implement transaction recovery for transaction-based systems.",
+      "description": "Recovery and reconstitution constitutes executing an operating system contingency plan comprised of activities to restore essential missions and business functions. \n\nRationale for non-applicability: A mobile OS typically is not transaction based.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33067",
+      "title": "The mobile operating system must prevent a user from installing unapproved applications.",
+      "description": "The operating system must enforce software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization. The installation and execution of unauthorized software on an operating system may allow the application to obtain sensitive information or further compromise the system. Preventing a user from installing unapproved applications mitigates this risk.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33069",
+      "title": "The mobile operating system must only permit download of software from a DoD approved source (e.g., DoD operated mobile device application store or MDM server).",
+      "description": "The mobile operating system must only permit download of software from a DoD approved source (e.g., DoD operated mobile device application store or MDM server).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33070",
+      "title": "The operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users).",
+      "description": "To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. In this context, there is no need to uniquely identify the user. Unique identification of application processes is inherent in other IA controls for application sandboxing under CCI-000022.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33081",
+      "title": "The operating system must use multifactor authentication for network access to non-privileged accounts.",
+      "description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33082",
+      "title": "The operating system must use multifactor authentication for local access to privileged accounts.",
+      "description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33083",
+      "title": "The operating system must use multifactor authentication for local access to non-privileged accounts.",
+      "description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33084",
+      "title": "The operating system must require individuals to be authenticated with an individual authenticator prior to using a group authenticator.",
+      "description": "To assure individual accountability and prevent unauthorized access, organizational users shall be individually identified and authenticated. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. In this context, the user would not have to use a group authenticator. This lone device user would not have pertinent organizational context on the device itself.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33085",
+      "title": "The operating system must use multifactor authentication for network access to privileged accounts where one of the factors is provided by a device separate from the information system being accessed.",
+      "description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system does not support remote network access to the device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33086",
+      "title": "The operating system must use multifactor authentication for network access to non-privileged accounts where one of the factors is provided by a device separate from the operating system being accessed.",
+      "description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system does not support remote network access to the device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33087",
+      "title": "The operating system must use organization defined replay-resistant authentication mechanisms for network access to privileged accounts.",
+      "description": "An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33088",
+      "title": "The operating system must use organization defined replay-resistant authentication mechanisms for network access to non-privileged accounts.",
+      "description": "An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Access to privileged accounts on mobile operating systems is prohibited.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33089",
+      "title": "The mobile operating systems Bluetooth module must enforce pairing using a randomly generated passkey size of at least 6 digits.",
+      "description": "When done properly, Bluetooth pairing prevents rogue devices from communicating with the operating system. If a rogue device is paired with the mobile device, then there is the potential for the rogue device to obtain sensitive information. Short passkeys make the pairing process vulnerable to brute force attacks. The use of known fixed passkeys makes the device even more vulnerable. The use of Bluetooth 2.1EDR or later technology greatly mitigates the risk of this attack because it relies on certificates in addition to the PIN to generate a secure pairing key. If device pairing is accomplished with a randomly generated 6-digit passkey, this greatly mitigates the risk of unauthorized pairing in all cases.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33090",
+      "title": "The mobile operating systems Bluetooth module must not permit any data transfer between devices prior to Bluetooth mutual authentication.",
+      "description": "Bluetooth mutual authentication provides assurance that both the mobile device and Bluetooth peripheral are legitimate. If the authentication does not occur immediately before permitting a network connection, there is the potential for a man-in-the-middle attack in which a third device intercepts the traffic between the two legitimate devices. Mutual authentication prevents this from occurring.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33091",
+      "title": "The operating system must authenticate devices before establishing remote network connections using bidirectional cryptographically based authentication between devices.",
+      "description": "Device authentication is a solution enabling an organization to manage devices. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000780, which is very similar but directly addresses wireless devices.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33092",
+      "title": "The mobile operating systems Wi-Fi module must be WPA2 certified (enterprise and personal).",
+      "description": "WPA2 is a Wi-Fi certification managed by the Wi-Fi Alliance, a trade association promoting technology based on the IEEE 802.11 communications standard. A product that has received WPA2 certification has demonstrated that it is compliant with the 802.11i amendment defining robust security networks. Products that have not received this certification are significantly more likely to have vulnerabilities associated with user and device authentication and the confidentiality and integrity of user data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33093",
+      "title": "The mobile operating systems Wi-Fi module must use EAP-TLS authentication when authenticating to DoD WLAN authentication servers.",
+      "description": "Without strong mutual authentication a mobile device may connect to an unauthorized network. In many cases, the user may falsely believe that the device is connected to an authorized network and then provide authentication credentials and other sensitive information. EAP-TLS is strong mutual authentication leveraging a public key infrastructure. Its use greatly mitigates risk associated with authentication transactions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33094",
+      "title": "The mobile operating system must authenticate devices before establishing remote network (e.g., VPN) connections using bidirectional cryptographically based authentication between devices.",
+      "description": "Without strong mutual authentication a mobile device may connect to an unauthorized network. In many cases, the user may falsely believe that the device is connected to an authorized network and then provide authentication credentials and other sensitive information. A strong bidirectional cryptographically based authentication method mitigates this risk.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33095",
+      "title": "The mobile operating system and mobile device management services must mutually authenticate each other using bi-directional PKI-based cryptographic authentication methods.",
+      "description": "Without strong mutual (bi-directional) authentication a mobile device may connect to an unauthorized mobile device management (MDM) server and obtain improper security policies or configuration commands from that server. This could, in turn, make the device vulnerable to a wide variety of other attacks that could reveal sensitive information and enable an adversary to obtain full control of the device. Cryptographic mutual authentication greatly mitigates this risk. Shared secret methods are an acceptable alternative to PKI-based authentication. The authentication need not be performed synchronously, but methods using asynchronous messages must still employ mutual authentication. For example, the MDM may digitally sign a configuration message encrypted with the mobile device's public key. This would, in effect, authenticate the mobile device because no other device would be able to access the configuration.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33096",
+      "title": "The mobile operating system VPN client must employ DoD PKI approved mechanisms for authentication when connecting to DoD networks.",
+      "description": "VPNs are vulnerable to attack if they are not supported by strong authentication. An adversary may be able gain access to network resources and sensitive information if they can compromise the authentication process. Common Access Card (CAC) authentication is a strong cryptographic two-factor authentication that greatly mitigates the risk of VPN authentication breaches. Other DoD approved PKI mechanisms provide similar levels of assurance.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33097",
+      "title": "The operating system must authenticate devices before establishing network connections using bidirectional cryptographically based authentication between devices.",
+      "description": "Device authentication is a solution enabling an organization to manage both users and devices. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-000780, which  directly relates to wireless technology.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33098",
+      "title": "The operating system must manage information system identifiers for users and devices by disabling the user identifier after an organization defined time period of inactivity.",
+      "description": "Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account, whose identifier would never be disabled. Some mobile operating systems also assign identifiers to applications, in which case there is a similar need for persistence regardless of usage patterns.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33099",
+      "title": "The operating system must dynamically manage identifiers, attributes, and associated access authorizations.",
+      "description": "Dynamic management of identities and association of attributes and privileges with these identities are anticipated and provisioned. Pre-established trust relationships and mechanisms with appropriate authorities to validate identities and related credentials are essential.\n\nRationale for non-applicability: NIST SP 800-53 IA-4 states that this control applies when service-oriented architectures establish identities at run time for entities that were previously unknown. Per the scope of the MOS SRG, mobile devices do not provide services to remote users and therefore do not provide identities for unknown entities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33100",
+      "title": "The operating system must use mechanisms for authentication to a cryptographic module meeting the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.",
+      "description": "Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms. \n\nRationale for non-applicability: This IA control is better addressed by CCI-001141 and CCI-001145, which focus on FIPS and NSA requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33101",
+      "title": "The operating system must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).",
+      "description": "Non-organizational users include all operating system users other than organizational users which include employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. The only process acting on behalf of a non-organizational user would be one of the carrier or OS vendor. In this case, CCI-00877 addresses the requirement for authentication of such processes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33102",
+      "title": "The operating system must implement a configurable capability to automatically disable the operating system if any of the organization defined lists of security violations are detected.",
+      "description": "When responding to a security incident a capability must exist allowing authorized personnel to disable a particular system if the system exhibits a security violation and the organization determines such an action is warranted. \n\nRationale for non-applicability: This CCI is not appropriate for a mobile device. Automatic disabling of devices poses a safety risk to mobile users who may have no other means of communication.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33103",
+      "title": "The operating system must automatically terminate emergency accounts after an organization defined time period for each type of account.",
+      "description": "When emergency accounts are created, there is a risk that the emergency account may remain in place and active after the need for the account no longer exists. To address this, in the event emergency accounts are required, accounts that are designated as temporary in nature must be automatically terminated after an organization defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Therefore, additional user accounts are not created for system administrators in emergencies.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33104",
+      "title": "The operating system must employ automated mechanisms to restrict the use of maintenance tools to authorized personnel only.",
+      "description": "The intent of this control is to address the security-related issues arising from the software brought into the operating system specifically for diagnostic and repair actions (e.g., a software packet sniffer introduced for the purpose of a particular maintenance activity). \n\nRationale for non-applicability: A mobile operating system typically does not have local audit or maintenance tools. The IA control corresponding to CCI-001803 addresses restricting users from performing system management functions. In many cases, diagnostic tools on mobile devices are accessible to anyone in possession of the device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33105",
+      "title": "The operating system must employ strong identification and authentication techniques in the establishment of non-local maintenance and diagnostic sessions.",
+      "description": "Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nRationale for non-applicability: A general assumption of the MOS SRG is that the MOS must not support non-local maintenance and diagnostic sessions. Therefore, this control is not applicable.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33106",
+      "title": "The operating system must terminate all sessions and network connections when non-local maintenance is completed.",
+      "description": "Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nRationale for non-applicability: A general assumption of the MOS SRG is that the MOS must not support non-local maintenance and diagnostic sessions. Therefore, this control is not applicable.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33107",
+      "title": "The operating system must audit non-local maintenance and diagnostic sessions.",
+      "description": "Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network, in order to conduct system diagnostics. \n\nRationale for non-applicability: A general assumption of the MOS SRG is that the MOS must not support non-local maintenance and diagnostic sessions. Therefore, this control is not applicable.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33108",
+      "title": "The operating system must protect non-local maintenance sessions through the use of a strong authenticator tightly bound to the user.",
+      "description": "Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. \"Maintenance\" is typically automated and is not associated with a human user account. Additionally, the IA control corresponding to CCI-000877 more clearly articulates the intent of this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33109",
+      "title": "The operating system must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.",
+      "description": "Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. To protect the integrity and confidentiality of non-local maintenance and diagnostics, all packets associated with these sessions must be encrypted.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. \"Maintenance\" is typically automated and is not associated with a human user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33110",
+      "title": "The mobile operating system must cryptographically bind the removable media to the mobile device so data stored on the removable media can only be read by that mobile device.",
+      "description": "When data is written to portable digital media, such as thumb drives, floppy diskettes, compact disks, and magnetic tape, etc., there is risk of data loss. Cryptographically binding the removable media to the mobile device renders the media useless when it is separated from the device. This greatly reduces the risk associated with removable media.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33111",
+      "title": "The operating system must employ cryptographic mechanisms to protect information in storage.",
+      "description": "When data is written to digital media, such as hard drives, mobile computers, external/removable hard drives, personal digital assistants, flash/thumb drives, etc., there is risk of data loss and data compromise.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33112",
+      "title": "The operating system must separate user functionality (including user interface services) from operating system management functionality.",
+      "description": "Operating system management functionality includes functions necessary to administer machine, network components, workstations, or servers, and typically requires privileged user access. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. This requirement is based on SC-2 with is application partitioning, a function of enterprise software.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33113",
+      "title": "The mobile operating system must prevent the user of the device from directly administering UIDs, file permissions, and system configuration files, and from starting and stopping system processes.",
+      "description": "If the user of the device can perform management functions, the user could modify the device configuration to degrade the IA posture of the device. Preventing such activity mitigates the risk of this vulnerability.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33114",
+      "title": "The operating system must isolate security functions from non-security functions.",
+      "description": "Operating system management functionality includes functions necessary to administer the operating, network components, workstations, or servers, and typically requires privileged user access. \n\nRationale for non-applicability: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33115",
+      "title": "The operating system must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions.",
+      "description": "The operating system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of the hardware, software, and firmware that perform those security functions.\n\nRationale for non-applicability: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33116",
+      "title": "The operating system must implement an information system isolation boundary to minimize the number of non-security functions included within the boundary containing security functions.",
+      "description": "The operating system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of the hardware, software, and firmware that perform those security functions. The operating system maintains a separate execution domain (e.g., address space) for each executing process.\n\nRationale for non-applicability: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33117",
+      "title": "The operating system must implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.",
+      "description": "The operating system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process.\n\nRationale for non-applicability: For the purposes of this IA control, a mobile OS is assumed to support a single user security domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33118",
+      "title": "The mobile operating system must prevent DoD applications from accessing non-DoD data when the device supports multiple user environments (e.g., work and personal) if such access has not been approved.",
+      "description": "When a device is used for more than one purpose (e.g., work and personal) there is the potential for information from one environment to migrate inappropriately over into another environment. Therefore it is critical for DoD applications and information be restricted from non-DoD applications and information. In many cases, the presence of non-DoD data on DoD information systems violates either local or department guidelines. \n\nIn the context of this IA control, a DoD application is an application that processes DoD data. The characteristics of being distributed through a DoD application store, or digitally signed or repackaged by a DoD entity do not by themselves make the application a DoD application. For example, a weather or map application signed and distributed from a DoD application store would not be a DoD application unless the weather, map, or other data was considered DoD data. \n\nThe mobile operating system must prevent this occurrence using appropriate technical controls to mitigate the risk of compromise of sensitive data. The objective is to provide appropriate separation between each environment on the device.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33119",
+      "title": "The mobile operating system must prevent non-DoD applications from accessing DoD data when the device supports multiple user environments (e.g., work and personal).",
+      "description": "When a device is used for more than one purpose (e.g., work and personal) there is the potential for information from one environment to migrate inappropriately over into another environment. Therefore, it is critical for DoD applications and information be restricted from non-DoD applications and information. In many cases, the presence of non-DoD data on DoD information systems violates either local or department guidelines. \n\nIn the context of this IA control, a DoD application is an application that processes DoD data. The characteristics of being distributed through a DoD application store, or digitally signed or repacked by a DoD entity do not by themselves make the application a DoD application. For example, a weather or map application signed and distributed from a DoD application store would not be a DoD application unless the weather, map, or other data was considered DoD data. \n\nThe mobile operating system must prevent this occurrence using appropriate technical controls to mitigate the risk of data leakage. The objective is to provide appropriate separation between each environment on the device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33120",
+      "title": "The operating system must not share resources used to interface with systems operating at different security levels.",
+      "description": "The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) obtaining access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the operating system. Shared resources include memory, input/output queues, and network interface cards.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile OS is assumed to support a single security domain. There is no interface to systems at a different security level.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33121",
+      "title": "The operating system must protect against or must limit the effects of the organization defined or referenced types of Denial of Service attacks.",
+      "description": "A variety of technologies exist to limit, or in some cases, eliminate the effects of Denial of Service (DoS) attacks. When it comes to DoS attacks, most attention is paid to ensuring the systems and applications are not victims of these attacks. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Carriers are in a much better position to mitigate the risk of and respond to DoS attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33122",
+      "title": "The operating system must restrict the ability of users to launch Denial of Service attacks against other information systems or networks.",
+      "description": "When it comes to Denial of Service (DoS) attacks, most of the attention is paid to ensuring the systems and applications are not victims of these attacks.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Carriers are in a much better position to mitigate the risk of and respond to DoS attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33123",
+      "title": "The operating system must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service attacks.",
+      "description": "In the case of Denial of Service attacks, care must be taken when designing the operating system so as to ensure the operating system makes the best use of system resources.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33124",
+      "title": "The operating system must limit the use of resources by priority.",
+      "description": "Priority protection helps prevent a lower-priority process from delaying or interfering with the operating system servicing any higher-priority process. Operating systems must limit potential high volume usage resources to protect against a Denial of Service.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33125",
+      "title": "The operating system must monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.",
+      "description": "The operating system must monitor and control communications at the boundary of the operating system.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001118, which refers to mobile device boundary protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33126",
+      "title": "The operating system must connect to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.",
+      "description": "The operating system must ensure traffic flows through only managed interfaces. For operating systems on the perimeter of the network (e.g., laptops connecting remotely) this helps protect the data on the endpoint.\n\nRationale for non-applicability: Mobile devices operate outside of enclave boundary. The arrangement of boundary protection devices is outside the scope of their control. The boundary protection devices will enforce strong authentication for VPN and other network connections.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33127",
+      "title": "The operating system must route organization defined internal communications traffic to organization defined external networks through authenticated proxy servers within the managed interfaces of boundary protection devices.",
+      "description": "A proxy server is designed to hide the identity of the client when making a connection to a server outside of its network. This prevents any hackers on the outside of learning IP addresses within the private network. With a proxy acting as the mediator, the client does not interact directly with the servers it is connecting to; the proxy server is in the middle handling both sides of the session.\n\nRationale for non-applicability: Routing of this type of traffic is enforced by the network infrastructure and not the mobile device. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33128",
+      "title": "The operating system, at managed interfaces, must deny network traffic and must audit internal users (or malicious code) posing a threat to external information systems.",
+      "description": "Detecting internal actions that may pose a security threat to external information systems is sometimes termed extrusion detection. Extrusion detection at the information system boundary includes the analysis of network traffic (incoming, as well as, outgoing) looking for indications of an internal threat to the security of external systems.\n\nRationale for non-applicability: Mobile devices operate outside of enclave boundary. The arrangement of boundary protection devices is outside the scope of their control. The boundary protection devices will enforce strong authentication for VPN and other network connections.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33129",
+      "title": "The operating system must check incoming communications to ensure the communications are coming from an authorized source and routed to an authorized destination.",
+      "description": "In the case of the operating system, the boundary may be the workstation on the public internet.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33130",
+      "title": "The mobile operating system must be able to filter both inbound and outbound traffic based on IP address and UDP/TCP port.",
+      "description": "Open ports provide an attack surface that an adversary can then potentially use to breach system security. If an adversary can communicate with the mobile device from any IP address, then the device may be open to any other device on the Internet. Reducing the attack surface through IP address and port restrictions mitigates this risk.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33131",
+      "title": "The operating system must route all networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.",
+      "description": "Managed interfaces employing boundary protection must be used for operating systems when using privileged accesses.\n\nRationale for non-applicability: Mobile devices do not have dedicated management interfaces.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33132",
+      "title": "The operating system must prevent discovery of specific system components (or devices) composing a managed interface.",
+      "description": "Allowing discovery of operating system resources, names, or components can lead to giving information to an attacker that may be used as an attack vector.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33133",
+      "title": "The operating system must employ automated mechanisms to enforce strict adherence to protocol format.",
+      "description": "Crafted packets not conforming to IEEE standards can be used by malicious people to exploit a host's protocol stack to create a Denial of Service or force a device reset.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33134",
+      "title": "The operating system must fail securely in the event of an operational failure of a boundary protection device.",
+      "description": "Fail secure is a condition achieved by the operating system employing a set of information system mechanisms to ensure, in the event of an operational failure of a boundary protection device at a managed interface, the system does not enter into an unsecure state where security properties no longer hold.\n\nRationale for non-applicability: Mobile devices operate outside of enclave boundary. Therefore, they are not protected by boundary protection devices.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33135",
+      "title": "The operating system must protect the integrity of transmitted information.",
+      "description": "Ensuring the integrity of transmitted information requires the operating system take feasible measures to employ transmission layer security. This requirement applies to communications across internal and external networks. \n\nRationale for non-applicability: This vulnerability is better addressed by another CCI. Methods for confidentiality also address integrity. The control implemented for CCI-001130 will also apply here.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33136",
+      "title": "The operating system must use multifactor authentication for network access to privileged accounts.",
+      "description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. While network access to privileged UID may be supported for carrier maintenance purposes, such access is automated and does not require two-factors. Two-factor authentication is more appropriate when authenticating human users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33137",
+      "title": "The operating system must employ cryptographic mechanisms to recognize changes to information during transmission unless otherwise protected by alternative physical measures.",
+      "description": "Ensuring the integrity of transmitted information requires operating systems take measures to employ some form of cryptographic mechanism in order to recognize changes to information. This is usually achieved through the use of checksums, cryptographic hash, or message authentication.\n\nRationale for non-applicability: This vulnerability is better addressed by another CCI. Methods for confidentiality also address integrity. The control implemented for CCI-001130 will also apply here.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33138",
+      "title": "The operating system must maintain the integrity of information during aggregation, packaging, and transformation in preparation for transmission.",
+      "description": "Ensuring the confidentiality of transmitted information requires the operating system take measures in preparing information for transmission. This can be accomplished via access control or encryption.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33139",
+      "title": "The mobile operating systems VPN client must use either IPSec or SSL/TLS when connecting to DoD networks.",
+      "description": "Use of non-standard communications protocols can affect both the availability and confidentiality of communications. IPSec and SSL/TLS are both well-known and tested protocols that provide strong assurance with respect to both IA and interoperability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33140",
+      "title": "The mobile operating systems Bluetooth stack must use 128-bit Bluetooth encryption when performing data communications with other Bluetooth devices.",
+      "description": "If data traffic is sent unencrypted, an adversary may be able to read it to obtain sensitive information. 128-bit Bluetooth encryption for data communications mitigates the risk of unauthorized eavesdropping. DoD has determined that FIPS 140-2 validated encryption is not required for voice communications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33141",
+      "title": "The mobile operating systems Wi-Fi module must use AES-CCMP encryption when connecting to a DoD network.",
+      "description": "If data traffic is sent unencrypted, an adversary may be able to read it to obtain sensitive information. Some WPA2 certified Wi-Fi implementations use Temporal Key Integrity Protocol (TKIP), which is not authorized for use in DoD. There are no publicly known breaches of AES-CCMP, which greatly mitigates the risk of unauthorized eavesdropping.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33142",
+      "title": "The mobile operating system must encrypt all data in transit using AES encryption when communicating with DoD information resources (128-bit key length is the minimum requirement; 256-bit desired).",
+      "description": "If data traffic is sent unencrypted, an adversary may be able to read it to obtain sensitive information. AES encryption with 128-bit (or longer) keys mitigates the risk of unauthorized eavesdropping. This requirement applies to both VPN connections and DoD messaging connections (email and authorized instant messaging applications).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33143",
+      "title": "The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of information during transmission unless otherwise protected by alternative physical measures.",
+      "description": "Ensuring the confidentiality of transmitted information requires operating systems take feasible measures to employ transmission layer security. This requirement applies to communications across internal and external networks. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001130, which deals with confidentiality in transit.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33144",
+      "title": "The operating system must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission.",
+      "description": "Confidentiality of the data must be maintained to ensure unauthorized users or processes do not have access to it. This can be accomplished via access control mechanisms or encryption.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33145",
+      "title": "The mobile operating system must terminate the network connection when an application requests termination, or after an organization defined time period of inactivity.",
+      "description": "If communications sessions remain open for extended periods of time even when unused, there is the potential for an adversary to highjack the session and use it to gain access to the device or networks to which it is attached. Terminating sessions after a certain period of inactivity is a method for mitigating the risk of this vulnerability.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33146",
+      "title": "The operating system must establish a trusted communications path between the user and organization defined security functions within the operating system.",
+      "description": "The user interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf. A trusted path shall be employed for high-confidence connections between the security functions of the information system and the user (e.g., for login).\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33147",
+      "title": "The mobile operating system must produce, control, and distribute cryptographic keys using NIST-approved or NSA-approved key management technology and processes if it produces, controls, or distributes cryptographic keys.",
+      "description": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. NIST technology and processes must be used for unclassified applications and data. NSA technology and processes must be used for classified applications and data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33148",
+      "title": "The operating system must produce, control, and distribute symmetric and asymmetric cryptographic keys using NSA approved key management technology and processes.",
+      "description": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. \n\nRationale for non-applicability: This control is being addressed by the control corresponding to CCI-1140.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33149",
+      "title": "The mobile operating system PKI certificate store must encrypt contents using AES encryption (AES 128 bit encryption key length is the minimum requirement; AES 256 desired).",
+      "description": "If an adversary can access the key store, it may be able to use the keys to perform a variety of unauthorized transactions. It may also be able to modify public keys in a way that it can trick the operating system into accepting invalid certificates. Encrypting the key store protects the integrity and confidentiality of keys. AES encryption with adequate key lengths provides assurance that the protection is strong. The electronic code book mode of AES is the most appropriate mode for encryption of the key store, but the implemented may select other AES modes if they are more appropriate in the given environment.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33150",
+      "title": "The mobile operating system must support both software-based and hardware-based asymmetric key technology (e.g., CAC/PIV).",
+      "description": "Software-based certificates are required to authenticate many web sites. Hardware-based tokens are embedded in the DoD Common Access Card (CAC). Without both software and hardware-based asymmetric key technology, there is the potential that critical authentication transactions cannot occur. This will either hinder performance of the mission or degrade the IA posture of one or more applications. If the operating system can support both software and hardware-based asymmetric key technology, this provides assurance that all required certificate-based transactions are supported.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33151",
+      "title": "The operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the users private key.",
+      "description": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. \n\nRationale for non-applicability: This control is primarily intended for systems that act as a certificate authority or server. Mobile operating systems are not intended for this role. Aspects of certificate control that are handled by a mobile device are addressed by other controls in the MOS SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33152",
+      "title": "The operating system must implement required cryptographic protections using cryptographic modules that comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms that are employed to encrypt the data. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001145, which focuses on FIPS validation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33153",
+      "title": "The cryptographic module supporting encryption of data in transit (including email and attachments) must be FIPS 140-2 validated.",
+      "description": "The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140-2 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS 140-2 validation is also a strict requirement for use of cryptography in the Federal Government. This general IA control is applicable to all wireless interfaces but is primarily targeted at interfaces other than Wi-Fi or Bluetooth, which have their own controls. STIGs for devices that have wireless interfaces other than Wi-Fi or Bluetooth only may use those controls in lieu of this one. For other wireless interfaces, this control must be applied.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33154",
+      "title": "The cryptographic module supporting encryption of data at rest must be FIPS 140-2 validated.",
+      "description": "The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.\n\nThis general IA control is applicable to all wireless interfaces but is primarily targeted at interfaces other than Wi-Fi or Bluetooth, which have their own controls. Guidance for mobile devices, which has wireless interfaces other than Wi-Fi or Bluetooth only, may use those controls in lieu of this one. For other wireless interfaces, this control must be applied.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33155",
+      "title": "The cryptographic module supporting the VPN client security functions must be FIPS 140-2 validated.",
+      "description": "The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33156",
+      "title": "The mobile operating system PKI certificate store must be FIPS 140-2 validated.",
+      "description": "The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140-2 validation provides assurance that the relevant cryptography has been implemented correctly. This particular control concerns the need for a strong password to be enforced on the actual certificate store in addition to the unlock code on the device. FIPS 140-2 validation is also a strict requirement for use of cryptography in the Federal Government.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33157",
+      "title": "The cryptographic module supporting Bluetooth data communications must be FIPS 140-2 validated.",
+      "description": "The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.\n\nNote: Bluetooth standards are being revised to specify cryptographic algorithms for which it is possible to obtain FIPS 140-2 validation for implementations of those algorithms. However, mobile devices are currently required to use Bluetooth modules that are FIPS 140-2 validated.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33158",
+      "title": "The cryptographic module supporting Wi-Fi security functions must be FIPS 140-2 validated.",
+      "description": "The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33159",
+      "title": "The mobile operating system must employ NSA approved cryptography to protect classified information.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or un-tested encryption algorithms undermines the purposes of utilizing encryption to protect data.\n\nThe most common vulnerabilities with cryptographic modules are those associated with poor implementation. NSA approval is required for cryptography for classified data and applications and provides assurance that the implementation is adequately protected against attack.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33160",
+      "title": "The operating system must employ FIPS validated cryptography to protect information when it must be separated from individuals who have the necessary clearances, yet lack the necessary access approvals.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. How that user obtains information without having the proper access approvals is an OPSEC concern, not a technical control on a mobile device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33161",
+      "title": "The mobile operating system must employ FIPS validated or NSA approved cryptography to implement digital signatures.",
+      "description": "The most common vulnerabilities with cryptographic modules are those associated with poor implementation. FIPS 140 validation and NSA approval provides assurance that the relevant cryptography has been implemented correctly. FIPS validation is also a strict requirement for use of cryptography in the Federal Government. Similarly, NSA approval of cryptography for classified data and applications is a strict requirement. The objective is to validate the implementation of the cryptography, not the cryptographic algorithm or mode.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33163",
+      "title": "The operating system must protect the integrity and availability of publicly available information and applications.",
+      "description": "The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications with such protection likely being implemented as part of other security controls.\n\nRationale for non-applicability: This control primarily applies to public web servers. A mobile OS typically does not host publically accessible data or services.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33164",
+      "title": "The mobile operating system must prohibit remote activation of collaborative computing functions, including microphones, cameras, and networked white boards without user concurrence.",
+      "description": "If an adversary can remotely activate collaborative computing functions, the adversary may be able to listen to the user's conversations, obtain visual data about the user's surroundings, or read sensitive information on the display of the user's device. To mitigate these risks, only a user in immediate possession of the device should be able to activate these functions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33165",
+      "title": "The Mobile OS must block both the inbound and outbound traffic between instant messaging clients that are independently configured by end users and external service providers or other unapproved DoD systems. ",
+      "description": "Many instant messaging systems have known vulnerabilities, some of which allow an adversary to install malware on the device. This malware can then be used to obtain sensitive information or further compromise DoD information systems. Restricting IM traffic to DoD authorized IM systems mitigates the risk of using IM technology.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33167",
+      "title": "The mobile operating system must grant a downloaded application only the permissions that DoD has authorized for that application.",
+      "description": "Mobile operating system applications that are able to perform unintended functions may be able to obtain sensitive information or otherwise compromise system security. The permissions that an application requires to perform its function may be delineated in a permissions manifest or in entitlements that are either bound to the application or embedded in its code. Enforcing these permissions limitations is necessary to ensure the application is not permitted to perform unintended functions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33168",
+      "title": "The mobile operating system must validate the integrity of a downloaded applications manifest before granting the application permissions on the device, if the operating system uses a manifest or similar mechanism external to application code to grant application permissions.",
+      "description": "If an adversary can modify an application's manifest (when the mobile OS supports this approach), then the adversary can add additional permissions that would enable it to perform unauthorized functions. These functions could enable the adversary to obtain sensitive information or compromise other aspects of system security. Validating the integrity of the manifest or similar technology mitigates the risk that an adversary has modified its contents. The SHA-1, SHA-224, SHA-256, and SHA-512 secure hash algorithms are acceptable mechanisms for verifying integrity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33169",
+      "title": "Only DoD PKI issued or DoD approved software authentication certificates may be installed on DoD mobile operating system devices.",
+      "description": "If unauthorized software authentication certificates are installed on the device, then the operating system would not block malware signed by the entity that published these certificates. Such malware could be used to obtain sensitive DoD information or to further breach system security. Eliminating unapproved software authentication certificates greatly mitigates the risk of malware passing authentication controls.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33171",
+      "title": "Only DoD PKI issued or DoD approved server authentication certificates must be installed on DoD mobile operating system devices.",
+      "description": "If unauthorized device authentication certificates are installed on the device, there is the potential that the device may connect to a rogue device or network. Rogue devices can mimic the behavior of authorized equipment to trick the user into providing authentication credentials, which could then in turn be used to compromise DoD information and networks. Restricting device authentication certificates to an authorized list mitigates the risk of attaching to rogue devices and networks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33172",
+      "title": "The operating system must implement detection and inspection mechanisms to identify unauthorized mobile code.",
+      "description": "Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nRationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33173",
+      "title": "The operating system must prevent the execution of prohibited mobile code.",
+      "description": "Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nRationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33174",
+      "title": "The operating system must prevent the download of prohibited mobile code.",
+      "description": "Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nRationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG. Proxy servers also provide a layer of defense against malicious mobile code.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33175",
+      "title": "The operating system must prevent the automatic execution of mobile code in organization defined software applications and must require organization defined actions prior to executing the code.",
+      "description": "Decisions regarding the employment of mobile code within operating systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nRationale for non-applicability: Mobile code protections are addressed in the Mobile Applications SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33176",
+      "title": "The operating system must fail to an organization defined known state for organization defined types of failures.",
+      "description": "Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. It helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving system state information facilitates system restart and return to the operational mode of the organization with less disruption of mission/business processes.\n\nRationale for non-applicability: As per the MOS SRG IA control corresponding to CCI-001383, the mobile operating system must wipe the device after an organization defined number of incorrect passcode attempts. No other failure states are defined at this time. The applicability of this control may be reconsidered at a future date if it is determined that certain failure conditions require failure to specific known states.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33177",
+      "title": "The operating system must protect the confidentiality and integrity of information at rest.",
+      "description": "This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive). The operating system must ensure the data being written to these devices is protected. In most cases, this is done via encryption.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001200, which includes cryptographic mechanisms to protect confidential and integrity of data at rest.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33178",
+      "title": "The operating system must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission.",
+      "description": "Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at information aggregation or protocol transformation points. It is therefore imperative the operating system take steps to validate and assure the integrity of data while at these stages of processing.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33179",
+      "title": "The operating system at organization defined information system components must load and execute the operating environment from hardware-enforced, read-only media.",
+      "description": "Organizations may require the information system to load the operating environment from hardware-enforced read-only media. The term operating environment is defined as the code upon which applications are hosted, for example, a monitor, executive, operating system, or application running directly on the hardware platform. Hardware-enforced, read-only media includes CD-R/DVD-R disk drives. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image.\n\nRationale for non-applicability: Mobile OS devices must be flash upgradable in order to implement patches to vulnerabilities. The small form factor of a mobile device does not easily allow for multiple forms of storage. Therefore, the persistent memory on a mobile device must be writeable and cannot support this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33180",
+      "title": "The operating system must employ organization defined information system components with no writeable storage that are persistent across component restart or power on/off.",
+      "description": "Organizations may require operating systems to be non-modifiable or to be stored and executed on non-writeable storage (e.g., there are no CD-ROM drives common on PCs). Use of non-modifiable storage ensures the integrity of the program from the point of creation of the read-only image and eliminates the possibility of malicious code insertion.\n\nRationale for non-applicability: Mobile OS devices must be flash upgradable in order to implement patches to vulnerabilities. The small form factor of a mobile device does not easily allow for multiple forms of storage. Therefore, the persistent memory on a mobile device must be writeable and cannot support this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33181",
+      "title": "The operating system must install software updates automatically.",
+      "description": "Security faults with software applications and operating systems are discovered daily and vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security relevant software updates (e.g., patches, service packs, hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously.\n\nRationale for non-applicability: This IA control conflicts with another IA requirement that users must accept software updates, thereby precluding full automation. In some instances, software updates must be downloaded directly from vendors without DoD evaluation. In this environment, fully automated updates pose an IA risk because the updates could contain malware that circumvents other IA controls. In the mobility context, the mechanism for enforcing currency of IA-related patches is to prohibit a mobile device from accessing DoD information resources if it does not have DoD-required security updates. This capability would typically be implemented using automated MDM features and enables DoD to decide which security updates are mandatory independently from the release schedule of patches from mobile OS vendors.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33182",
+      "title": "The mobile operating system must detect and report the version of the operating system, device drivers, and application software when queried by an authorized entity.",
+      "description": "Organizations are required to identify information systems containing software affected by recently announced software flaws (and potential vulnerabilities resulting from those flaws) and report this information to an MDM system or other system with similar functionality. To support this requirement, an automated process or mechanism is required.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33183",
+      "title": "The mobile operating system must support automated patch management tools to facilitate flaw remediation of all software components on the device.",
+      "description": "The organization (including any contractor to the organization) must promptly install security relevant software updates (e.g., patches, service packs, hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed. Left un-patched, software may be vulnerable to a variety of exploits that could disclose sensitive information or lead to subsequent security breaches. An automated patch management system can mitigate this risk.\n\nIn the context of this IA control, automation is interpreted broadly and covers patch management systems that involve user acknowledgement of patches or user initiated patches after automatic notification of the availability of a patch. Automation is from the perspective of the commercial mobile device (CMD) user; system administrators may still need to perform several manual steps to prepare patches for distribution and modify CMD configuration to be able to receive patches.\n\nHowever, patch systems that require CMD users to take additional steps beyond a one-step acknowledgment or request for the patch in order to locate, download, install, or verify the patch are not considered automated.\n\nSome user involvement in the patch process is a defense-in-depth measure to protect CMD and DoD networks. In particular, it mitigates the risk of carrier-initiated patches that have been known to include malware.  \n\nMobile device management (MDM) systems also mitigate the risk of un-patched CMD. If a user does not install a required patch for whatever reason, the MDM system may deny the CMD access to DoD networks and, when the risk warrants it, remotely disable the device.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33184",
+      "title": "The operating system must have malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means.",
+      "description": "In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated prior to entering protected enclaves via operating system entry and exit points. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001668, which corresponds to NIST Special Publication 800-53 control SI-3, specifically mentions mobile devices.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33185",
+      "title": "The mobile operating system must prevent non-privileged users from circumventing malicious code protection capabilities.",
+      "description": "A common tactic of malware is to identify the type of malicious code protection software running on the system and deactivate it, which enables subsequent attacks. If malicious code protection is itself protected, then it will prevent a non-privileged user or malicious software from disabling the protection mechanism. Ensuring that any security feature is protected against bypass, tampering, or disablement is best met by a mandatory access control mechanism in the mobile OS.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33186",
+      "title": "The operating system must not allow users to introduce removable media into the information system.",
+      "description": "Malicious code is known to propagate via removable media such as floppy disks, USB or flash drives, and removable hard drives. \n\nRationale for non-applicability: Mobile OS devices use removable media (i.e., SD cards) for many storage purposes and may be required for operation in some cases. This precludes a prohibition on removable media. However, to help ensure proper use of the removable media, the MOS SRG requires that removable media be cryptographically bound to the operating system and that all data on the removable media be encrypted. This prevents the removable media from being used on another device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33187",
+      "title": "The operating system must provide a near real-time alert when any of the organization defined list of compromise or potential compromise indicators occurs.",
+      "description": "When an intrusion detection security event occurs it is imperative the operating system that has detected the event immediately notify the appropriate support personnel so they can respond accordingly.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001274, which addresses alerts in case of integrity check failure.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33188",
+      "title": "The mobile operating system must prevent non-privileged users from circumventing intrusion detection and prevention capabilities.",
+      "description": "Intrusion detection and prevention capabilities must be architected and implemented to prevent non-privileged users from circumventing such protections. Ensuring that any security feature is protected against bypass, tampering, or disablement is best met by a mandatory access control mechanism. However, limited protection may also be accomplished through the use of user roles and systems permissions.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33189",
+      "title": "The mobile operating system must prevent a user from using a browser that does not direct its traffic to a DoD proxy server.",
+      "description": "Proxy servers can inspect traffic for malware and other signs of a security attack. Allowing a mobile device to access the public Internet without proxy server inspection, forgoes the protection the proxy server would otherwise provide. Malware downloaded onto the device could have a wide variety of malicious consequences, including loss of sensitive DoD information. Forcing traffic to flow through a proxy server greatly mitigates the risk of access to public Internet resources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33190",
+      "title": "The mobile operating system must protect information obtained from intrusion and integrity monitoring tools from unauthorized access, modification, and deletion.",
+      "description": "If an adversary can modify or delete information obtained from intrusion and integrity tools, then the adversary can hide evidence of an attack. Mechanisms to protect such data are necessary to mitigate the risk of these attacks and ensure they are detected in a timely manner.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33191",
+      "title": "The operating system must verify the correct operation of security functions in accordance with organization defined conditions and in accordance with organization defined frequency (if periodic verification).",
+      "description": "Security functional testing involves testing the operating system for conformance to the operating system security function specifications, as well as, for the underlying security model. The need to verify security functionality applies to all security functions. The conformance criteria state the conditions necessary for the operating system to exhibit the desired security behavior or satisfy a security property for example, successful login triggers an audit entry.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Additionally, the IA control corresponding to CCI-1297 requires that the integrity of the security enforcement mechanisms be validated at startup and every six hours thereafter. This provides reasonable assurance that security functions are performing properly even the functions themselves are not tested at these times.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33192",
+      "title": "The operating system must provide notification to an external device and halt the boot cycle if the OS detects tampering or fails operating system security tests.",
+      "description": "Automated security tests performed by the mobile operating system are critical in the detection of IA attacks. Such checks include verification of the integrity of operating system files, device drivers, and security enforcement mechanisms by the operating system or third-party applications. However, users and systems administrators can only benefit from the security tests if they are notified in case of failure. A notification mechanism reduces the risk that a security breach will go undetected.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33193",
+      "title": "The operating system must provide automated support for the management of distributed security testing.",
+      "description": "The need to verify security functionality applies to all security functions.\n\nRationale for non-applicability: This requirement is better addressed by CCI-001294, which states the requirement to report the results of security test failures. The requirement for distributed security testing is within the scope of the MDM SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33194",
+      "title": "The mobile operating system must conduct a device integrity scan on a minimum organizationally-defined periodic basis.",
+      "description": "Unauthorized changes to the operating system software or information on the system can possibly result in integrity or availability concerns. In order to quickly react to this situation, the operating system must detect these changes. One aspect of detection is the frequency at which the scans occur. The ability to set an appropriate frequency mitigates the risk that an attack will go without detection longer than the scanning interval.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33195",
+      "title": "The mobile operating system must verify the integrity of all operating system files, device drivers, and security enforcement mechanisms at startup and at least every six hours thereafter using one or more DoD approved cryptographic mechanisms that compare attributes of the operating system configuration to a known good baseline.",
+      "description": "One of the most significant indicators of an IA attack is modification of operating system files, device drivers, or security enforcement mechanisms. An integrity verification capability or tool detects unauthorized modifications to files or permissions and either prevents further operation or reports its findings so an appropriate response can occur.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33196",
+      "title": "The operating system must check the validity of information inputs.",
+      "description": "Invalid user input occurs when a user inserts data or characters the system is unprepared to process. This results in unanticipated behavior that could lead to a compromise.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control. Additionally, several more specific input controls are included in the Mobile Applications SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33197",
+      "title": "The operating system must identify potentially security relevant error conditions.",
+      "description": "The structure and content of error messages need to be carefully considered by the organization. The extent to which the operating system is able to identify and handle error conditions is guided by organizational policy and operational requirements.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001274, which more directly addresses specific alerts to be sent to mobile device management.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33198",
+      "title": "The mobile operating system must not include authentication credentials or other sensitive information in audit records.",
+      "description": "Any operating system providing too much information in error logs and in administrative messages to the screen, risks compromising the data and security of the structure and content of error messages needs to be carefully considered by the organization.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33199",
+      "title": "The operating system must reveal error messages to authorized personnel only.",
+      "description": "If the operating system provides too much information in error logs and administrative messages to the screen, it could lead to compromise. The structure and content of error messages need to be carefully considered by the organization.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. The user requires access to error messages when disconnected from the enterprise network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33200",
+      "title": "The operating system must support the requirement that organizations, if an information system component failure is detected, must activate an organization defined alarm and/or automatically shuts down the operating system.",
+      "description": "Predictable failure prevention requires organizational planning to address system failure issues. If a subsystem of the operating system, hardware, or the operating system itself, is key to maintaining systems and security fails to function, the system could continue operating in an insecure state. The organization must be prepared for and the operating system must support capability that alarms for such conditions and/or automatically shuts down the operating system or the subsystem of the operating system.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33201",
+      "title": "The operating system must associate the identity of the information producer with the information.",
+      "description": "Non-repudiation supports audit requirements to provide the appropriate organizational officials the means to identify who produced specific information in the event of an information transfer.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33202",
+      "title": "The mobile operating system must validate the digital signature on signed software components or applications.",
+      "description": "Digital signatures on software components and applications are primary means to determine that the code comes from a trusted source and has not been modified. If the operating system does not validate these digital signatures, then there is the potential for malware to infiltrate the device. Validating digital signatures assures that the digital signature control properly mitigates the risk that malware will be installed or execute on the system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33203",
+      "title": "The operating system must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released.",
+      "description": "When it comes to data review and data release, there must be a correlation between the reviewed data and the person who performs the review. If the reviewer is a human or if the review function is automated but separate from the release/transfer function, the operating system associates the identity of the reviewer of the information to be released with the information and the information label.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Therefore, the chain of custody is not relevant to activities on the device itself. Chain of custody is critical to the handling of audit records in the context of the enterprise audit logging system. The Mobile Device Management SRG addresses enterprise logging requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33204",
+      "title": "The operating system must validate the binding of the reviewers identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain.",
+      "description": "This non-repudiation control enhancement is intended to mitigate the risk that information could be modified between review and transfer/release particularly when the transfer is occurring between security domains.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile OS is assumed to support a single security domain and a single user.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33205",
+      "title": "The operating system must invoke a system shutdown in the event of an audit failure, unless an alternative audit capability exists.",
+      "description": "It is critical when an operating system is at risk of failing to process audit logs as required it takes action to mitigate the failure. If the system were to continue processing without auditing enabled, actions can be taken on the system that cannot be tracked and recorded for later forensic analysis. \n\nRationale for non-applicability: This CCI is not appropriate for a mobile device. Automatic disabling of devices poses a safety risk to mobile users who may have no other means of communication.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33206",
+      "title": "The mobile operating system must alert the Mobile Device Management or Intrusion Detection and Prevention System when it detects integrity check failures.",
+      "description": "Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. Alerting the Mobile Device Management (MDM) or Intrusion Detection and Prevention System (IDPS) mitigates the potential for attacks triggering integrity failures to have further consequences to the enterprise.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33207",
+      "title": "The operating system must back up audit records on an organization defined frequency onto a different system or media than the system being audited.",
+      "description": "Protection of log data includes assuring the log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited, on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained.\n\nRationale for non-applicability: Combined consideration of storage resource constraints and the required relationship between auditing, logging, and back-end MDM servers this functionality is more appropriately required of the back-end MDM server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33208",
+      "title": "The operating system must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format.",
+      "description": "Audits records can be generated from various components within the operating system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events).\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33209",
+      "title": "The operating system must monitor for atypical usage of operating system accounts.",
+      "description": "Atypical account usage is behavior that is not part of normal usage cycles, e.g., accounts logging in after hours or on weekends.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account that may use the device at any time without a predictable usage pattern. Usage will vary depending on the mission and may change whenever the mission requires a rapid response.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33210",
+      "title": "The operating system must enforce an organization defined Discretionary Access Control (DAC) policy that must allow users to specify and control sharing by named individuals or groups of individuals, or by both.",
+      "description": "Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the operating system. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. This single human user on the device does not need to set up sharing with other users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33211",
+      "title": "The operating system must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information.\n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33212",
+      "title": "The operating system, when transferring information between different security domains, must implement policy filters constraining data structure and content to organization defined information security policy requirements.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33213",
+      "title": "The operating system, when transferring information between different security domains, must detect unsanctioned information.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33214",
+      "title": "The operating system, when transferring information between different security domains, must prohibit the transfer of unsanctioned information in accordance with the security policy.",
+      "description": "Information flow control regulates where information is allowed to travel within an operating system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33215",
+      "title": "The operating system must uniquely identify source domains for information transfer.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33232",
+      "title": "The operating system must uniquely authenticate source domains for information transfer.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross-domain solutions not within the scope of this SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33233",
+      "title": "The mobile operating system must wipe all storage media after an organization defined number of consecutive, unsuccessful attempts to unlock the mobile device.",
+      "description": "Mobile devices present additional risks related to attempted unauthorized access. If they are lost, stolen, or misplaced, attempts can be made to unlock the device by guessing the password. Once unlocked, an adversary may be able to obtain sensitive data on the device. Wiping storage media renders all such data permanently inaccessible.\n\nThere are two acceptable methods to wipe the device. The first is to overwrite the data on the media several times, so it is not longer recoverable. In this case, the device should implement DoD 5220.22-M (E) (3pass), in which the media is overwritten three times. The second is to delete the locally stored encryption key on a device that encrypts all data stored on the device. In this case, the key must be wiped using a method complying with DoD 5220.22-M (ECE) (7 pass), in which all storage sectors containing the key are overwritten seven times. When the mobile device employs flash media, alternative methods consistent with those described in NIST SP 800-88 (as revised) are acceptable.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33234",
+      "title": "The mobile operating system must wipe data on both embedded storage and removable media when performing a data wipe function.",
+      "description": "Sensitive data may be resident on both embedded and removable memory. If the operating system only performs the wipe function on one type of memory, then this will leave the other vulnerable. Ensuring the wipe occurs on both embedded and removable memory mitigates this risk.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33235",
+      "title": "The mobile operating system maximum number of consecutive unsuccessful unlock attempts must be configurable within a range from 5 to 10.",
+      "description": "The recommended setting for the maximum number of consecutive unsuccessful unlock attempts is 10. In some environments, a lower number may be needed to provide greater protection of sensitive information. Allowing for configuration enables the local command to enforce greater protection when it is deemed necessary. If the limit is not configurable, then it is permissible for a site to procure and deploy devices that enforce the limit specified by the organization, so long as that limit does not exceed 10.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33236",
+      "title": "The operating system for publicly accessible systems must display the system use information when appropriate, before granting further access.",
+      "description": "Requirement applies to publicly accessible systems. System use notification messages can be implemented in the form of warning banners displayed when individuals log in to the information system. System use notification is intended only for information system access including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist.\n\nRationale for non-applicability: A mobile OS typically does not host publically accessible data or services.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33237",
+      "title": "The mobile operating system must employ mobile device management services to centrally manage security relevant configuration and policy settings.",
+      "description": "Security related parameters are those parameters impacting the security state of the system and include parameters related to the implementation of other IA controls. If these controls are not implemented, the system may be vulnerable to a variety of attacks. The use of mobile device management (MDM) allows an organization to assign values to security related parameters across all the devices it manages. This provides assurance that the required mobile OS security controls are being enforced, and that the device user or an adversary has not modified or disabled the controls. It also greatly increases efficiency and manageability of devices in a large scale environment relative to an environment in which each device must be configured separately. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33238",
+      "title": "The mobile operating system must encrypt all data on the mobile device using AES encryption (AES 128 bit encryption key length is the minimum requirement; AES 256 desired).",
+      "description": "If data at rest is unencrypted, it is vulnerable to disclosure. Even if the operating system enforces permissions on data access, an adversary can remove non-volatile memory and read it directly, thereby circumventing operating system controls. Encrypting the data ensures that confidentiality is protected even when the operating system is not running. AES encryption with appropriate key lengths provides assurance that the cryptography is adequate.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33239",
+      "title": "The mobile operating system must require a valid password be successfully entered before the mobile device data is unencrypted.",
+      "description": "Encryption is only effective if the decryption procedure is protected. If an adversary can easily access the private key (either directly or through a software application), sensitive DoD data is likely to be disclosed. Password protection is one method to reduce the likelihood of such an occurrence.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33240",
+      "title": "The mobile operating system must re-encrypt all device data when the device is locked.",
+      "description": "Data at rest refers to all stored data on a mobile device that will include the address book and other PII, data created by a user when using some applications, as well as data received, such as emails. If data is not encrypted upon the lock of the device, there is the potential for an adversary to remove non-volatile memory from the device and read it directly using tools for that purpose. This attack would render other operating system controls useless. Encrypting all data at rest provides assurance that it will be protected even when memory is physically removed from the device.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33241",
+      "title": "The mobile operating system must prohibit wireless remote access connections except for personal hotspot service.",
+      "description": "The device acts as a personal hotspot when it accepts remote connections on a local area network interface for the purposes of routing traffic to a wide area network interface. The most common implementation is to accept local area Wi-Fi connections to reach ISP service provided by a cellular data carrier. The objective is to ensure the remote devices are not able to access any applications, data, or other operating system functionality on the device. A core assumption of the MOS SRG is that mobile devices do not serve applications to remote devices. This control concerns remote access to the devices OS; if remote access to applications and data were feasible, this would open up a wide variety of vulnerabilities in which an adversary with a remote wireless capability could breach system security. Precluding this possibility greatly mitigates the risk of such an attack.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33242",
+      "title": "The mobile operating system must authenticate tethered connections to the device.",
+      "description": "Authentication may occur either by reentry of the device unlock passcode at the time of connection, through another passcode with the same or stronger complexity, or through PKI certificates. Authentication mitigates the risk that an adversary who obtains physical possession of the device is not able to use the tethered connection to access sensitive data on the device or otherwise tamper with its operating system or applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33243",
+      "title": "The mobile operating system must use automated mechanisms to detect the presence of unauthorized software on organizational information systems and notify designated organizational officials in accordance with the organization defined frequency.",
+      "description": "Unauthorized software poses a risk to the device because it could potentially perform malicious functions, including but not limited to gathering sensitive information, searching for other system vulnerabilities, or modifying log entries. A mechanism to detect unauthorized software and notify officials of its presence assists in the task of removing such software to eliminate the risks it poses to the device and the networks to which the device attaches.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33244",
+      "title": "The operating system must notify the user of the number of successful logins/accesses that occur during the organization defined time period.",
+      "description": "Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of successful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33245",
+      "title": "The operating system must notify the user of the number of unsuccessful login/access attempts that occur during organization defined time period.",
+      "description": "Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.\n\nRationale for non-applicability: This control is better addressed by CCI-000053, which also covers notification to users of unsuccessful logon attempts. CCI-001392 incorporates the notion of a time period that is not utilized in mobile OS.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33246",
+      "title": "The operating system must notify the user of organization defined security-related changes to the users account that occur during the organization defined time period.",
+      "description": "Some organizations may define certain security events as events requiring user notification. An organization may define an event such as a password change to a user's account occurring outside of normal business hours as a security related event that requires the user be notified. In those instances where organizations define such events, the operating system must notify the affected user or users.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33247",
+      "title": "The mobile operating system must maintain the binding of digital signatures on software components and applications in storage.",
+      "description": "Digital signatures enable the system to verify the integrity of the signed object and authenticate the object's signatory. Failure to maintain the binding of digital signatures on software components and applications in storage makes it more likely that an adversary could modify or replace those objects. Conversely, the bindings enable the operating system to verify the software's integrity and source with a high degree of assurance whenever necessary.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33248",
+      "title": "The mobile operating system must maintain the binding of digital signatures on software components and applications in process.",
+      "description": "Digital signatures enable the system to verify the integrity of the signed object and authenticate the object's signatory. Failure to maintain the binding of digital signatures on software components and applications in process makes it more likely that an adversary could modify or replace those objects when the software is executed. The bindings enable the operating system to verify the software's integrity and source just before the execution process.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33249",
+      "title": "The operating system must support and maintain the binding of organization defined security attributes to information in transmission.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33250",
+      "title": "The operating system must automatically audit account modification.",
+      "description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Traditional auditing of account management functions is not required in this context.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33251",
+      "title": "The operating system must automatically audit account disabling actions.",
+      "description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Traditional auditing of account management functions is not required in this context.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33252",
+      "title": "The operating system must automatically audit account termination.",
+      "description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Traditional auditing of account management functions is not required in this context.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33253",
+      "title": "The operating system must enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33254",
+      "title": "The operating system must dynamically reconfigure security attributes in accordance with an identified security policy as information is created and combined.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nRationale for non-applicability: Digitally signed attributes on software objects are never modified.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33255",
+      "title": "The operating system must only allow authorized entities to change security attributes.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nRationale for non-applicability: Digitally signed attributes on software objects are never modified.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33256",
+      "title": "The operating system maintains the binding of security attributes to information with sufficient assurance that the information attribute association can be used as the basis for automated policy actions.",
+      "description": "The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as: the means used to associate a set of security attributes with a specific information object as part of the data structure for that object.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33257",
+      "title": "The operating system must only allow authorized users to associate security attributes with information.",
+      "description": "The term security label is often used to associate a set of security attributes with a specific information object as part of the data structure for that object (e.g., user access privileges, nationality, affiliation as contractor). A security label is defined as the means used to associate a set of security attributes with a specific information object as part of the data structure for that object.\n\nRationale for non-applicability: Digitally signed attributes on software objects are never modified.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33258",
+      "title": "The operating system must display security attributes in human-readable form on each object output from the system to system output devices to identify an organization identified set of special dissemination, handling, or distribution instructions using organization identified human-readable, standard naming conventions.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects, objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nRationale for non-applicability: Security attributes will not be displayed to a user of a mobile device outside of a mobile application. The Mobile Application SRG includes this IA control.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33259",
+      "title": "The operating system must disable the use of organization defined networking protocols within the operating system deemed to be nonsecure except for explicitly identified components in support of specific operational requirements.",
+      "description": "Some networking protocols may not meet security requirements to protect data and components. The organization can either make a determination as to the relative security of the networking protocol or base the security decision on the assessment of other entities. Based on that assessment some may be deemed to be nonsecure except for explicitly identified components in support of specific operational requirements.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001118, which requires host-based firewall with same functionality as described here.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33260",
+      "title": "The operating system must enforce the organization defined time period during which the limit of consecutive invalid access attempts by a user is counted.",
+      "description": "By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.\n\nRationale for non-applicability: Mobile devices are more likely to be lost or stolen, and therefore more likely to be subjected to a slow password attack. Therefore, users will not be permitted to engage in further attempts after a defined time period. Per CCI 1383, if the user cannot successfully authenticate within an organization defined number of attempts, the mobile device is wiped regardless of the time period. In effect, the required time period is infinite.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33261",
+      "title": "The operating system must use cryptography to protect the integrity of remote access sessions.",
+      "description": "Remote access is any access to an organizational operating system by a user (or an information system) communicating through an external, non-organization-controlled network. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001145, which addresses general remote access requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33262",
+      "title": "The mobile operating system must log an audit event for each instance when a remote process uses MDM mechanisms for accessing the device security configuration settings.",
+      "description": "Mobile device management (MDM) provides IA services to mobile devices but it also represents a threat to those devices. If an adversary were able to take control of the MDM or masquerade as the MDM, then it could use that ability to relax IA controls and breach the mobile device. Logging MDM events enables better traceability to mistaken or unauthorized MDM transactions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33263",
+      "title": "The operating system must provide the capability to capture/record and log all content related to a user session.",
+      "description": "Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33264",
+      "title": "The operating system must enforce a Discretionary Access Control (DAC) policy that includes or excludes access to the granularity of a single user.",
+      "description": "Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the operating system. \n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33265",
+      "title": "The operating system must initiate security auditing at system start-up.",
+      "description": "The audit capability is most effective if it is running at all times. Otherwise there may be time gaps in the audit logs in which an adversary can hide malicious behavior. Initiating security auditing at system start-up mitigates the risk that there will be time periods in which auditing is not active.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33266",
+      "title": "The mobile operating system must produce audit records containing sufficient information to establish the identity of any user or subject associated with the event.",
+      "description": "Operating system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nWithout sufficient information establishing what type of audit events occurred, investigation into the severity of events is severely hindered. As defined in RFC 5424 \"The Syslog Protocol\", event severity levels allow system administrators and IA personnel to more easily identify critical system issues.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33267",
+      "title": "The operating system must protect audit tools from unauthorized access.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nRationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33268",
+      "title": "The operating system must protect audit tools from unauthorized modification.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nRationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33269",
+      "title": "The operating system must protect audit tools from unauthorized deletion.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nRationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33270",
+      "title": "The mobile operating system must prohibit modifications to software libraries unless performed as part of a software installation or update from a trusted source.",
+      "description": "When dealing with change control issues, it should be noted that any changes to the hardware, software, and/or firmware components of the operating system can potentially have significant effects on the overall security of the system. \n\nOnly authorized individuals must be allowed to obtain access to mobile device components for purposes of initiating changes, including upgrades and modifications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33271",
+      "title": "The mobile operating system must disable the mobile device upon the MDM agents instruction, permitting someone in possession of the device to make emergency 911 calls only.",
+      "description": "Under some conditions, a compromised device represents a threat to other computing resources on the network. For example, a compromised device may attempt to conduct a denial of service attack on other devices, or may be executing a mechanism to spread malware before a countermeasure has been put in place. In these situations, it is critical that mobile device management (MDM) be able to disable the device to protect other network resources. Disabling the device means disabling all user functionality with the exception of making emergency 911 calls. Disabling the device may, but needs not, render the device or resident data permanently inaccessible. For example, the MDM may lock the device such that it cannot be unlocked without an additional MDM instruction, but preserve data and applications if the device is later unlocked. Actions to restore the device to factory defaults still permit user functionality and therefore do not qualify as disabling the device.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33272",
+      "title": "The operating system uniquely must identify destination domains for information transfer.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross domain solutions and are not within the scope of the Mobile Operating System SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33273",
+      "title": "The operating system uniquely must authenticate destination domains for information transfer.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that the information. \n\nRationale for non-applicability: This control maps to NIST SP 800-53 AC-4, which has been determined to apply to cross domain solutions and are not within the scope of the Mobile OS SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33274",
+      "title": "The operating system must track problems associated with the information transfer.",
+      "description": "When an operating system transfers data, there is the chance an error or problem with the data transfer may occur. The operating system needs to track failures and any problems encountered when performing data transfers, so problems can be identified and remediated. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33275",
+      "title": "The operating system must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights.",
+      "description": "Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the operating system. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33276",
+      "title": "The operating system must ensure unauthorized, security relevant configuration changes detected are tracked.",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001297, which deals with detection of unauthorized changes to software and data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33277",
+      "title": "The operating system must enforce password complexity by the number of special characters used.",
+      "description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting guessing and brute force attacks. Requiring a minimum number of special characters is one way to increase the complexity of the password and make it less likely that it will be compromised. The parameter should be selected based on a risk assessment that weighs factors, such as the environments the device will be located and operational requirements for users to access data in a timely manner.\n\nRationale for non-applicability: Given the inconvenience of entering special characters on some keyboards of mobile devices, a risk assessment determined that it would be acceptable to have device unlock passwords without special characters.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33278",
+      "title": "The operating system must protect non-local maintenance sessions by separating the maintenance session from other network sessions with the information system by either physically separated communications paths or logically separated communications paths.",
+      "description": "This is a requirement that maintenance needs to be done on a separate interface or encrypted channel to segment maintenance activity from regular usage. When performing non-local maintenance, there is a possibility of the session being monitored and replayed to gain unauthorized access into a system.\n\nRationale for non-applicability: Authentication requirements for device connections and software updates provide adequate IA in this context. The existence of out of band connections is not particularly meaningful in the context of a wireless communications device where all wireless interfaces share the same medium of the electromagnetic spectrum. Management of the mobile device does not occur over a separate physical or virtual network. If management sessions are authenticated and protected by cryptography, separating the session into a separate virtual network is unnecessary.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33279",
+      "title": "The operating system must take corrective actions, when unauthorized mobile code is identified.",
+      "description": "Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation. The handling of unauthorized mobile code is within the scope of the Mobile Application SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33280",
+      "title": "The operating system must preserve organization defined system state information in the event of a system failure.",
+      "description": "Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the operating system or a component of the system. \n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of all IA functions. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control and the applications and data typically on the device justify its implementation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33281",
+      "title": "The mobile operating system must employ malicious code protection mechanisms to detect and eradicate malicious code from installing and executing.",
+      "description": "In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can result in the disclosure of sensitive information or cause a denial of service. Anti-virus applications are not common on mobile operating systems but one or more methods to mitigate the risk of malware must be in place to protect DoD information and networks.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33282",
+      "title": "The operating system must take organization defined list of least disruptive actions to terminate suspicious events.",
+      "description": "System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action the operating system takes to terminate suspicious events. The least disruptive actions may include initiating a request for human response.\n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001274, which defines \"least disruptive\" response in this context.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33283",
+      "title": "The operating system must respond to security function anomalies in accordance with organization defined responses and alternative action(s).",
+      "description": "The need to verify security functionality applies to all security functions. \n\nRationale for non-applicability: This vulnerability is better addressed by CCI-001297, which addresses responding to unauthorized changes to software and data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33284",
+      "title": "The operating system must enforce requirements for the connection of mobile devices to operating systems.",
+      "description": "Wireless access introduces security risks which must be addressed through implementation of strict controls and procedures, such as authentication, encryption, and defining what resources that can be accessed. The organization will define the requirements for connection of mobile devices. In order to ensure the connection provides adequate integrity and confidentiality of the connection, the operating system must enforce these requirements.\n\nRationale for non-applicability: A mobile OS typically does not serve applications to remote clients.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33285",
+      "title": "The operating system must notify, as required, appropriate individuals when accounts are created.",
+      "description": "Monitoring account creation is critical to ensure only appropriate personnel have access to the operating system. This reduces the possibility a rogue account will be created. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is created.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33286",
+      "title": "The operating system must notify, as required, appropriate individuals when accounts are modified.",
+      "description": "Monitoring account modification is critical to ensure only appropriate personnel have access to the operating system. This reduces the possibility that an account will be given more access than is intended. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is modified.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33287",
+      "title": "The operating system must notify, as required, appropriate individuals when an account is disabled.",
+      "description": "Monitoring account disabling is critical to ensure a denial of service situation does not exist on the operating system. An unexpected account deletion can also be a sign that there is a rogue administrator account that may be deleting traces of activity. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is disabled.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33288",
+      "title": "The operating system must notify, as required, appropriate individuals for account termination.",
+      "description": "Monitoring account termination is critical to ensure a denial of service situation does not exist on the operating system. An unexpected account termination can also be a sign that there is a rogue administrator account that may be deleting traces of activity. In order to facilitate the monitoring, the operating system must notify designated personnel when an account is terminated.\n\nRationale for non-applicability: For the purposes of this SRG, a mobile operating system is assumed to support a single human-accessible user account. Alerts to IT operators are within the scope of the MDM SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33289",
+      "title": "The operating system must use cryptographic mechanisms to protect the integrity of audit tools.",
+      "description": "Auditing and logging are key components of any security architecture. It is essential security personnel know what is being done, what attempted to be done, where it was done, when it was done, and by whom in order to compile an accurate risk assessment. Cryptographic mechanisms must be used to protect the integrity of the audit tools used for audit reduction and reporting.\n\nRationale for non-applicability: A mobile OS typically does not have local audit or maintenance tools. Audit tool functionality is required in the MDM SRG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33290",
+      "title": "The mobile operating system must disallow more than an organizationally-defined quantity of sequential numbers (e.g., 456) in the device unlock password.",
+      "description": "Password complexity or strength refers to how difficult it is to determine a password using a dictionary or brute force attack. Passwords with sequential numbers (e.g., 456 or 987) are considered easier to crack than random patterns. Therefore, disallowing sequential numbers makes it more difficult for an adversary to discover the password.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33291",
+      "title": "The mobile operating system must not permit a user to disable the password-protected lock feature on the device.",
+      "description": "If the user is able to disable the password-protected lock feature, the user can change the configuration of the device to allow access without a password. The modified configuration would enable an adversary with access to the device to obtain DoD information and possibly other information resources on other systems. An operating system that does not allow a user to disable this feature mitigates the risk of this attack. In cases in which the mobile operating system relies on another application for protected data storage (e.g., if FIPS 140-2 validated encryption for unclassified use is not native to the device), then this requirement applies to both the device lock password and the password to the data storage application.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33292",
+      "title": "The mobile operating system must not permit a user to disable or modify the security policy or enforcement mechanisms on the device.",
+      "description": "The integrity of the security policy and enforcement mechanisms is critical to the IA posture of the operating system. If a user can modify a device's security policy or enforcement mechanisms, then a wide range of subsequent attacks are possible, including unauthorized access to information and networks. Access controls that prevent a user from making modifications, such as these, mitigate the risk of operating system compromise.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33293",
+      "title": "The mobile operating system must not cache smartcard or certificate store passwords for more than an organizationally-defined time period.",
+      "description": "The longer passwords remain in the cache, the more likely it is that malware or other mechanisms will discover them. Once an adversary has obtained a password from the cache, the adversary can further compromise the device and networks to which the device is attached. Minimizing the time passwords are stored in the cache mitigates the risk of this attack. The absence of caching altogether eliminates the risk. If caching is available, the caching period should be configurable with organizations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33294",
+      "title": "The mobile operating system must wipe the device upon the MDM agents instruction.",
+      "description": "If a system has been known to have been lost or stolen, there is increased risk that an adversary could obtain DoD data residing on the device. Similarly, in some cases system administrators may know or strongly suspect that a device contains malware or is compromised in a manner that poses a significant threat to the enterprise network. In such circumstances, the IAO may determine that the safest course of action is to have a systems administrator remotely issue a command to wipe all data on the device. This action would render the device inoperable and prevent anyone from accessing the data stored on it.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33295",
+      "title": "The mobile operating system must disable access to the devices contact database when the device is locked.",
+      "description": "On some devices, users can access the device's contact database to obtain phone numbers and other information using voice-activated Bluetooth peripherals even when the mobile device is locked. Often this information is personally identifiable information (PII), which is considered sensitive. It could also be used by an adversary to profile the user or engage in social engineering to obtain further information from other unsuspecting users. Disabling access to the contact database in these situations mitigates the risk of this attack. The DAA may waive this requirement with written notice if the operational environment requires this capability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33296",
+      "title": "The mobile operating system must enable a system administrator to (i) select which data fields will be available to applications outside of the contact database application and (ii) limit the number of contact database fields accessible outside of a work persona in the case of dual persona phones.",
+      "description": "The contact database often contains a significant amount of information beyond each person's name and phone number. The records may contain addresses and other identifying or sensitive information that should not be revealed. There may be cases in which an organization has determined that it is an acceptable risk to distribute parts of person's contact record but not others. Enabling the system administrator to select which fields are available outside the contact database application (or to applications outside the work persona in the case of a dual persona device) assists with management of the risk.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33778",
+      "title": "The operating system must prevent public access into an organizations internal networks, except as appropriately mediated by managed interfaces employing boundary protection devices.",
+      "description": "Access into an organization's internal network and to key internal boundaries must be tightly controlled and managed. In the case of the operating system, the key boundary may be the workstation on the public internet.\n\nRationale for non-applicability: Mobile devices operate outside of enclave boundary. The arrangement of boundary protection devices is outside the scope of their control. The boundary protection devices will enforce strong authentication for VPN and other network connections.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33779",
+      "title": "The mobile operating systems Bluetooth module must support the capability for a system administrator to create a non-user-modifiable white list of Bluetooth devices that are authorized to pair to the mobile device.",
+      "description": "If a rogue device can connect to the mobile device, there is the potential for the rogue device to obtain sensitive information. One mechanism for preventing this occurrence is to enforce a white list of devices that are permitted to pair to the mobile device. Devices not on the white list will not be able to pair with the mobile device and therefore cannot communicate with it or obtain sensitive information from it.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33780",
+      "title": "The operating system must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communication path with resources in external networks.",
+      "description": "This control enhancement is implemented within the remote device (e.g., notebook/laptop computer) via configuration settings not configurable by the user of the device. An example of a non-remote communications path from a remote device is a virtual private network (VPN). When a non-remote connection is established using a VPN, the configuration settings prevent split-tunneling. Split-tunneling might otherwise be used by remote users to communicate with the information system as an extension of the system and to communicate with local resources, such as a printer or file server. Since the remote device, when connected by a non-remote connection, becomes an extension of the information system allowing dual communications paths, such as split-tunneling, in effect allowing unauthorized external connections into the system. This is a split-tunneling requirement that can be controlled via the operating system by disabling interfaces.\n\nRationale for non-applicability: The use of commercial mobile devices as personal hotspots to connect to DoD networks is a critical user functionality. This configuration enables routing between the VPN traffic on one interface and authenticated client device access on another interface. A prohibition on split-tunneling would disable this feature. Strong authentication of remote network connections mitigates the risk that an unauthorized process on the non-VPN interface will be able to access the VPN interface.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33781",
+      "title": "The mobile device operating system must have access to DoD root and intermediate PKI certificates when performing DoD PKI related transactions.",
+      "description": "DoD root and intermediate PKI certificates are used to verify the authenticity of PKI certificates of users and web services. If the root and intermediate certificates are not available, an adversary could falsely sign a certificate in such a way that it could not be detected. Providing access to the DoD root and intermediate PKI certificates greatly diminishes the risk of this attack.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33782",
+      "title": "The operating system at organization defined information system components must load and execute organization defined applications from hardware-enforced, read-only media.",
+      "description": "Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Organizations may require the information system to load specified applications from hardware-enforced read-only media. Hardware-enforced, read-only media includes CD-R/DVD-R disk drives.\n\nRationale for non-applicability: Mobile OS devices must be flash upgradable in order to implement patches to vulnerabilities. The small form factor of a mobile device does not easily allow for multiple forms of storage. Therefore, the persistent memory on a mobile device must be writeable and cannot support this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33783",
+      "title": "The operating system must use cryptographic mechanisms to protect the integrity of audit information.",
+      "description": "Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry established standard used to protect the integrity of audit data.\n\nRationale for non-applicability: Resource constraints on mobile devices preclude implementation of this specific IA function. The applicability of this control may be reconsidered at a future date if subsequent generations of mobile devices are better able to support this control.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33784",
+      "title": "The operating system must protect the audit records resulting from non-local accesses to privileged accounts and the execution of privileged functions.",
+      "description": "Protection of audit records and audit data is of critical importance. Care must be taken to ensure privileged users cannot circumvent audit protections put in place. Auditing might not be reliable when performed by an operating system which the user being audited has privileged access to. The privileged user could inhibit auditing or directly modify audit records. To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus, limiting the users with audit-related privileges.\n\nRationale for non-applicability: This control is better addressed by another CCI. CCI-000162 and CCI-00163 together protect the audit logs from unauthorized access and modification.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33785",
+      "title": "The mobile operating system must obscure passwords on the devices display when they are entered on the device.",
+      "description": "To prevent the compromise of authentication information, such as passwords during the authentication process, the feedback from the operating system shall not provide any information allowing an unauthorized user to compromise the authentication mechanism. Otherwise, someone nearby the user (a.k.a., \"shoulder surfer\") may be able to obtain the password through visual observation.",
+      "severity": "low"
+    }
+  ]
+}