kriterion 0.0.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +2 -0
- data/.ruby-version +1 -0
- data/.travis.yml +5 -0
- data/Dockerfile +18 -0
- data/Gemfile +12 -0
- data/Gemfile.lock +62 -0
- data/LICENSE.txt +21 -0
- data/README.md +58 -0
- data/Rakefile +6 -0
- data/bin/setup +8 -0
- data/bin/update_stigs.rb +42 -0
- data/criterion.gemspec +31 -0
- data/docker-compose.yml +14 -0
- data/exe/kriterion +16 -0
- data/lib/kriterion.rb +16 -0
- data/lib/kriterion/api.rb +27 -0
- data/lib/kriterion/backend.rb +13 -0
- data/lib/kriterion/backend/mongodb.rb +235 -0
- data/lib/kriterion/cli.rb +28 -0
- data/lib/kriterion/cli/api.rb +35 -0
- data/lib/kriterion/cli/worker.rb +35 -0
- data/lib/kriterion/event.rb +36 -0
- data/lib/kriterion/item.rb +42 -0
- data/lib/kriterion/logs.rb +14 -0
- data/lib/kriterion/metrics.rb +22 -0
- data/lib/kriterion/object.rb +50 -0
- data/lib/kriterion/report.rb +69 -0
- data/lib/kriterion/resource.rb +60 -0
- data/lib/kriterion/section.rb +32 -0
- data/lib/kriterion/standard.rb +65 -0
- data/lib/kriterion/version.rb +3 -0
- data/lib/kriterion/worker.rb +280 -0
- data/standards/cis_red_hat_enterprise_linux_7.json +34 -0
- data/standards/stig_a10_networks_adc_alg.json +209 -0
- data/standards/stig_a10_networks_adc_ndm.json +233 -0
- data/standards/stig_active_directory_domain.json +257 -0
- data/standards/stig_active_directory_forest.json +41 -0
- data/standards/stig_active_directory_service_2003.json +173 -0
- data/standards/stig_active_directory_service_2008.json +167 -0
- data/standards/stig_adobe_acrobat_pro_xi.json +167 -0
- data/standards/stig_adobe_acrobat_reader_dc_classic_track.json +179 -0
- data/standards/stig_adobe_acrobat_reader_dc_continuous_track.json +179 -0
- data/standards/stig_adobe_coldfusion_11.json +611 -0
- data/standards/stig_airwatch_mdm.json +185 -0
- data/standards/stig_aix_5.3.json +3095 -0
- data/standards/stig_aix_6.1.json +3047 -0
- data/standards/stig_akamai_ksd_service_impact_level_2_alg.json +209 -0
- data/standards/stig_akamai_ksd_service_impact_level_2_ndm.json +155 -0
- data/standards/stig_android_2.2_dell.json +311 -0
- data/standards/stig_apache_2.2_serverwindows.json +347 -0
- data/standards/stig_apache_2.2_sitewindows_security_implementation_guide.json +179 -0
- data/standards/stig_apache_server_2.0unix.json +341 -0
- data/standards/stig_apache_server_2.0windows.json +341 -0
- data/standards/stig_apache_server_2.2unix.json +347 -0
- data/standards/stig_apache_server_2.2windows.json +347 -0
- data/standards/stig_apache_site_2.0unix.json +185 -0
- data/standards/stig_apache_site_2.0windows.json +179 -0
- data/standards/stig_apache_site_2.2unix.json +185 -0
- data/standards/stig_apache_site_2.2windows.json +179 -0
- data/standards/stig_apple_ios6.json +341 -0
- data/standards/stig_apple_ios_10.json +245 -0
- data/standards/stig_apple_ios_11.json +269 -0
- data/standards/stig_apple_ios_4_good_mobility_suite_interim_security_configuration_guide_iscg.json +257 -0
- data/standards/stig_apple_ios_5.json +329 -0
- data/standards/stig_apple_ios_6.json +335 -0
- data/standards/stig_apple_ios_6_interim_security_configuration_guide_iscg.json +371 -0
- data/standards/stig_apple_ios_7.json +185 -0
- data/standards/stig_apple_ios_8_interim_security_configuration_guide.json +251 -0
- data/standards/stig_apple_ios_9_interim_security_configuration_guide.json +245 -0
- data/standards/stig_apple_os_x_10.10_yosemite_workstation.json +851 -0
- data/standards/stig_apple_os_x_10.11.json +725 -0
- data/standards/stig_apple_os_x_10.12.json +737 -0
- data/standards/stig_apple_os_x_10.8_mountain_lion_workstation.json +1241 -0
- data/standards/stig_apple_os_x_10.9_mavericks_workstation.json +809 -0
- data/standards/stig_application_layer_gateway_alg_security_requirements_guide_srg.json +911 -0
- data/standards/stig_application_layer_gateway_security_requirements_guide.json +911 -0
- data/standards/stig_application_security_and_development.json +1745 -0
- data/standards/stig_application_security_and_development_checklist.json +959 -0
- data/standards/stig_application_security_requirements_guide.json +1961 -0
- data/standards/stig_application_server_security_requirements_guide.json +791 -0
- data/standards/stig_arcgisserver_10.3.json +143 -0
- data/standards/stig_arista_mls_dcs-7000_series_l2s.json +53 -0
- data/standards/stig_arista_mls_dcs-7000_series_ndm.json +197 -0
- data/standards/stig_arista_mls_dcs-7000_series_rtr.json +143 -0
- data/standards/stig_bind_9.x.json +431 -0
- data/standards/stig_bind_dns.json +317 -0
- data/standards/stig_blackberry_10.2.x_os.json +179 -0
- data/standards/stig_blackberry_10_os.json +227 -0
- data/standards/stig_blackberry_bes_12.3.x_mdm.json +65 -0
- data/standards/stig_blackberry_bes_12.5.x_mdm.json +65 -0
- data/standards/stig_blackberry_device_service_6.2.json +425 -0
- data/standards/stig_blackberry_enterprise_mobility_server_2.x.json +149 -0
- data/standards/stig_blackberry_enterprise_server,_part_1.json +35 -0
- data/standards/stig_blackberry_enterprise_server,_part_2.json +155 -0
- data/standards/stig_blackberry_enterprise_server,_part_3.json +647 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_1.json +35 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_2.json +155 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_3.json +653 -0
- data/standards/stig_blackberry_enterprise_service_v10.1.x_blackberry_device_service.json +317 -0
- data/standards/stig_blackberry_enterprise_service_v10.2.x_blackberry_device_service.json +263 -0
- data/standards/stig_blackberry_handheld_device.json +125 -0
- data/standards/stig_blackberry_os_10.3.x.json +257 -0
- data/standards/stig_blackberry_os_7.x.json +107 -0
- data/standards/stig_blackberry_os_7.x.x.json +101 -0
- data/standards/stig_blackberry_os_version_5-7.json +107 -0
- data/standards/stig_blackberry_playbook.json +65 -0
- data/standards/stig_blackberry_playbook_os_nea_mode.json +65 -0
- data/standards/stig_blackberry_playbook_os_v2.1.json +197 -0
- data/standards/stig_blackberry_uem_12.7.json +59 -0
- data/standards/stig_bluetoothzigbee.json +35 -0
- data/standards/stig_ca_api_gateway_alg.json +497 -0
- data/standards/stig_cisco_css_dns.json +71 -0
- data/standards/stig_cisco_ios_xe_release_3_ndm.json +395 -0
- data/standards/stig_cisco_ios_xe_release_3_rtr.json +149 -0
- data/standards/stig_cmd_management_server_policy.json +53 -0
- data/standards/stig_commercial_mobile_device_cmd_policy.json +83 -0
- data/standards/stig_csfc_campus_wlan_policy_security_implementation_guide.json +95 -0
- data/standards/stig_database_security_requirements_guide.json +767 -0
- data/standards/stig_dbn-6300_idps.json +107 -0
- data/standards/stig_dbn-6300_ndm.json +359 -0
- data/standards/stig_defense_switched_network.json +683 -0
- data/standards/stig_defense_switched_network_dsn.json +653 -0
- data/standards/stig_desktop_applications_general.json +41 -0
- data/standards/stig_dns_policy.json +155 -0
- data/standards/stig_domain_name_system_dns_security_requirements_guide.json +599 -0
- data/standards/stig_draft_aix.json +3503 -0
- data/standards/stig_edb_postgres_advanced_server.json +665 -0
- data/standards/stig_email_services_policy.json +137 -0
- data/standards/stig_exchange_2010_client_access_server.json +179 -0
- data/standards/stig_exchange_2010_edge_transport_server.json +389 -0
- data/standards/stig_exchange_2010_hub_transport_server.json +269 -0
- data/standards/stig_exchange_2010_mailbox_server.json +209 -0
- data/standards/stig_f5_big-ip_access_policy_manager_11.x.json +149 -0
- data/standards/stig_f5_big-ip_advanced_firewall_manager_11.x.json +41 -0
- data/standards/stig_f5_big-ip_application_security_manager_11.x.json +89 -0
- data/standards/stig_f5_big-ip_device_management_11.x.json +467 -0
- data/standards/stig_f5_big-ip_local_traffic_manager_11.x.json +407 -0
- data/standards/stig_final_draft_general_wireless_policy.json +71 -0
- data/standards/stig_firewall.json +449 -0
- data/standards/stig_firewall_-_cisco.json +449 -0
- data/standards/stig_firewall_security_requirements_guide.json +257 -0
- data/standards/stig_forescout_counteract_alg.json +83 -0
- data/standards/stig_forescout_counteract_ndm.json +239 -0
- data/standards/stig_free_space_optics_device.json +143 -0
- data/standards/stig_general_mobile_device_policy_non-enterprise_activated.json +113 -0
- data/standards/stig_general_mobile_device_technical_non-enterprise_activated.json +59 -0
- data/standards/stig_general_purpose_operating_system_srg.json +1199 -0
- data/standards/stig_general_wireless_policy.json +71 -0
- data/standards/stig_good_mobility_suite_server_android_os.json +203 -0
- data/standards/stig_good_mobility_suite_server_apple_ios_4_interim_security_configuration_guide_iscg.json +209 -0
- data/standards/stig_good_mobility_suite_server_windows_phone_6.5.json +449 -0
- data/standards/stig_goodenterprise_8.x.json +401 -0
- data/standards/stig_google_chrome_browser.json +209 -0
- data/standards/stig_google_chrome_current_windows.json +215 -0
- data/standards/stig_google_chrome_draft.json +281 -0
- data/standards/stig_google_chrome_v23_windows.json +275 -0
- data/standards/stig_google_chrome_v24_windows.json +263 -0
- data/standards/stig_google_chrome_v24_windows_benchmark.json +227 -0
- data/standards/stig_google_search_appliance.json +209 -0
- data/standards/stig_harris_secnet_11_54.json +89 -0
- data/standards/stig_hp-ux_11.23.json +3215 -0
- data/standards/stig_hp-ux_11.31.json +3155 -0
- data/standards/stig_hp-ux_smse.json +431 -0
- data/standards/stig_hpe_3par_storeserv_3.2.x.json +131 -0
- data/standards/stig_ibm_datapower_alg.json +401 -0
- data/standards/stig_ibm_datapower_network_device_management.json +395 -0
- data/standards/stig_ibm_db2_v10.5_luw.json +575 -0
- data/standards/stig_ibm_hardware_management_console_hmc.json +221 -0
- data/standards/stig_ibm_hardware_management_console_hmc_policies.json +35 -0
- data/standards/stig_ibm_maas360_v2.3.x_mdm.json +59 -0
- data/standards/stig_ibm_zvm_using_ca_vm:secure.json +473 -0
- data/standards/stig_idps_security_requirements_guide_srg.json +1865 -0
- data/standards/stig_idsips.json +257 -0
- data/standards/stig_iis6_server.json +221 -0
- data/standards/stig_iis6_site.json +263 -0
- data/standards/stig_iis_7.0_web_server.json +155 -0
- data/standards/stig_iis_7.0_web_site.json +299 -0
- data/standards/stig_iis_8.5_server.json +293 -0
- data/standards/stig_iis_8.5_site.json +347 -0
- data/standards/stig_infoblox_7.x_dns.json +419 -0
- data/standards/stig_infrastructure_l3_switch.json +599 -0
- data/standards/stig_infrastructure_l3_switch_-_cisco.json +659 -0
- data/standards/stig_infrastructure_l3_switch_secure_technical_implementation_guide_-_cisco.json +659 -0
- data/standards/stig_infrastructure_router.json +479 -0
- data/standards/stig_infrastructure_router_-_cisco.json +539 -0
- data/standards/stig_infrastructure_router_-_juniper.json +485 -0
- data/standards/stig_infrastructure_router__cisco.json +539 -0
- data/standards/stig_infrastructure_router__juniper.json +485 -0
- data/standards/stig_internet_explorer_8.json +821 -0
- data/standards/stig_internet_explorer_9.json +815 -0
- data/standards/stig_intrusion_detection_and_prevention_systems_idps_security_requirements_guide.json +371 -0
- data/standards/stig_ipsec_vpn_gateway.json +521 -0
- data/standards/stig_java_runtime_environment_jre_6_unix.json +65 -0
- data/standards/stig_java_runtime_environment_jre_6_win7.json +65 -0
- data/standards/stig_java_runtime_environment_jre_6_windows_xp.json +77 -0
- data/standards/stig_java_runtime_environment_jre_6_winxp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_unix.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_win7.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_winxp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_version_6_unix.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_6_windows_7.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_6_windows_xp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_version_7_unix.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_7_windows_7.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_7_winxp.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_8_unix.json +107 -0
- data/standards/stig_java_runtime_environment_jre_version_8_windows.json +107 -0
- data/standards/stig_jboss_eap_6.3.json +413 -0
- data/standards/stig_juniper_srx_sg_alg.json +155 -0
- data/standards/stig_juniper_srx_sg_idps.json +179 -0
- data/standards/stig_juniper_srx_sg_ndm.json +443 -0
- data/standards/stig_juniper_srx_sg_vpn.json +185 -0
- data/standards/stig_keyboard_video_and_mouse_switch.json +269 -0
- data/standards/stig_l3_kov-26_talon_wireless_role.json +77 -0
- data/standards/stig_layer_2_switch.json +347 -0
- data/standards/stig_layer_2_switch_-_cisco.json +365 -0
- data/standards/stig_lg_android_5.x_interim_security_configuration_guide.json +245 -0
- data/standards/stig_lg_android_6.x.json +281 -0
- data/standards/stig_mac_osx_10.6_workstation.json +1319 -0
- data/standards/stig_mac_osx_10.6_workstation_draft.json +1319 -0
- data/standards/stig_mainframe_product_security_requirements_guide.json +1115 -0
- data/standards/stig_mcafee_application_control_7.x.json +203 -0
- data/standards/stig_mcafee_move_2.63.6.1_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_2.63.6.1_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_2.6_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_2.6_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_3.6.1_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_3.6.1_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_agentless_3.03.6.1_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_agentless_3.0_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_agentless_3.0_vsel_1.9sva.json +203 -0
- data/standards/stig_mcafee_move_agentless_3.6.1_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_av_agentless_4.5.json +155 -0
- data/standards/stig_mcafee_move_av_multi-platform_4.5.json +215 -0
- data/standards/stig_mcafee_virusscan_8.8_local_client.json +533 -0
- data/standards/stig_mcafee_virusscan_8.8_managed_client.json +533 -0
- data/standards/stig_mcafee_vsel_1.92.0_local_client.json +245 -0
- data/standards/stig_mcafee_vsel_1.92.0_managed_client.json +239 -0
- data/standards/stig_mdm_server_policy.json +47 -0
- data/standards/stig_microsoft_access_2003.json +47 -0
- data/standards/stig_microsoft_access_2007.json +77 -0
- data/standards/stig_microsoft_access_2010.json +119 -0
- data/standards/stig_microsoft_access_2013.json +113 -0
- data/standards/stig_microsoft_access_2016.json +107 -0
- data/standards/stig_microsoft_dot_net_framework_4.0.json +101 -0
- data/standards/stig_microsoft_excel_2003.json +47 -0
- data/standards/stig_microsoft_excel_2007.json +155 -0
- data/standards/stig_microsoft_excel_2010.json +287 -0
- data/standards/stig_microsoft_excel_2013.json +293 -0
- data/standards/stig_microsoft_excel_2016.json +257 -0
- data/standards/stig_microsoft_exchange_2010_client_access_server_role.json +71 -0
- data/standards/stig_microsoft_exchange_2010_core_server.json +47 -0
- data/standards/stig_microsoft_exchange_2010_edge_transport_server_role.json +233 -0
- data/standards/stig_microsoft_exchange_2010_hub_transport_server_role.json +125 -0
- data/standards/stig_microsoft_exchange_2010_mailbox_server_role.json +107 -0
- data/standards/stig_microsoft_exchange_server_2003.json +647 -0
- data/standards/stig_microsoft_groove_2013.json +71 -0
- data/standards/stig_microsoft_ie_version_6.json +599 -0
- data/standards/stig_microsoft_ie_version_7.json +749 -0
- data/standards/stig_microsoft_infopath_2003.json +41 -0
- data/standards/stig_microsoft_infopath_2007.json +167 -0
- data/standards/stig_microsoft_infopath_2010.json +155 -0
- data/standards/stig_microsoft_infopath_2013.json +149 -0
- data/standards/stig_microsoft_internet_explorer_10.json +857 -0
- data/standards/stig_microsoft_internet_explorer_11.json +839 -0
- data/standards/stig_microsoft_internet_explorer_9.json +821 -0
- data/standards/stig_microsoft_lync_2013.json +29 -0
- data/standards/stig_microsoft_office_system_2007.json +221 -0
- data/standards/stig_microsoft_office_system_2010.json +233 -0
- data/standards/stig_microsoft_office_system_2013.json +293 -0
- data/standards/stig_microsoft_office_system_2016.json +131 -0
- data/standards/stig_microsoft_onedrivebusiness_2016.json +89 -0
- data/standards/stig_microsoft_onenote_2010.json +77 -0
- data/standards/stig_microsoft_onenote_2013.json +71 -0
- data/standards/stig_microsoft_onenote_2016.json +71 -0
- data/standards/stig_microsoft_outlook_2003.json +65 -0
- data/standards/stig_microsoft_outlook_2007.json +479 -0
- data/standards/stig_microsoft_outlook_2010.json +515 -0
- data/standards/stig_microsoft_outlook_2013.json +497 -0
- data/standards/stig_microsoft_outlook_2016.json +359 -0
- data/standards/stig_microsoft_powerpoint_2003.json +47 -0
- data/standards/stig_microsoft_powerpoint_2007.json +131 -0
- data/standards/stig_microsoft_powerpoint_2010.json +191 -0
- data/standards/stig_microsoft_powerpoint_2013.json +251 -0
- data/standards/stig_microsoft_powerpoint_2016.json +233 -0
- data/standards/stig_microsoft_project_2010.json +83 -0
- data/standards/stig_microsoft_project_2013.json +95 -0
- data/standards/stig_microsoft_project_2016.json +95 -0
- data/standards/stig_microsoft_publisher_2010.json +107 -0
- data/standards/stig_microsoft_publisher_2013.json +101 -0
- data/standards/stig_microsoft_publisher_2016.json +101 -0
- data/standards/stig_microsoft_sharepoint_designer_2013.json +71 -0
- data/standards/stig_microsoft_skypebusiness_2016.json +29 -0
- data/standards/stig_microsoft_sql_server_2005_database.json +167 -0
- data/standards/stig_microsoft_sql_server_2005_instance.json +1001 -0
- data/standards/stig_microsoft_sql_server_2012_database.json +179 -0
- data/standards/stig_microsoft_sql_server_2012_database_instance.json +929 -0
- data/standards/stig_microsoft_visio_2013.json +89 -0
- data/standards/stig_microsoft_visio_2016.json +89 -0
- data/standards/stig_microsoft_windows_10_mobile.json +215 -0
- data/standards/stig_microsoft_windows_2008_server_domain_name_system.json +269 -0
- data/standards/stig_microsoft_windows_2012_server_domain_name_system.json +551 -0
- data/standards/stig_microsoft_windows_phone_8.1.json +161 -0
- data/standards/stig_microsoft_windows_server_2012_domain_controller.json +2633 -0
- data/standards/stig_microsoft_windows_server_2012_member_server.json +2411 -0
- data/standards/stig_microsoft_word_2003.json +47 -0
- data/standards/stig_microsoft_word_2007.json +119 -0
- data/standards/stig_microsoft_word_2010.json +221 -0
- data/standards/stig_microsoft_word_2013.json +221 -0
- data/standards/stig_microsoft_word_2016.json +215 -0
- data/standards/stig_mobile_application_management_mam_server.json +95 -0
- data/standards/stig_mobile_application_security_requirements_guide.json +233 -0
- data/standards/stig_mobile_device_integrity_scanning_mdis_server.json +119 -0
- data/standards/stig_mobile_device_management_mdm_server.json +125 -0
- data/standards/stig_mobile_device_manager_security_requirements_guide.json +2555 -0
- data/standards/stig_mobile_email_management_mem_server.json +197 -0
- data/standards/stig_mobile_operating_system_security_requirements_guide.json +1943 -0
- data/standards/stig_mobile_policy.json +35 -0
- data/standards/stig_mobile_policy_security_requirements_guide.json +437 -0
- data/standards/stig_mobileiron_core_v9.x_mdm.json +89 -0
- data/standards/stig_mobility_policy.json +65 -0
- data/standards/stig_mozilla_firefox.json +161 -0
- data/standards/stig_ms_exchange_2013_client_access_server.json +209 -0
- data/standards/stig_ms_exchange_2013_edge_transport_server.json +443 -0
- data/standards/stig_ms_exchange_2013_mailbox_server.json +437 -0
- data/standards/stig_ms_sharepoint_2010.json +269 -0
- data/standards/stig_ms_sharepoint_2013.json +245 -0
- data/standards/stig_ms_sharepoint_designer_2013.json +71 -0
- data/standards/stig_ms_sql_server_2014_database.json +263 -0
- data/standards/stig_ms_sql_server_2014_instance.json +575 -0
- data/standards/stig_ms_sql_server_2016_database.json +185 -0
- data/standards/stig_ms_sql_server_2016_instance.json +731 -0
- data/standards/stig_ms_windows_defender_antivirus.json +257 -0
- data/standards/stig_multifunction_device_and_network_printers.json +131 -0
- data/standards/stig_network_device_management_security_requirements_guide.json +863 -0
- data/standards/stig_network_devices.json +389 -0
- data/standards/stig_network_infrastructure_policy.json +455 -0
- data/standards/stig_network_security_requirements_guide.json +1961 -0
- data/standards/stig_operating_system_security_requirements_guide.json +1961 -0
- data/standards/stig_oracle_10_database_installation.json +527 -0
- data/standards/stig_oracle_10_database_instance.json +569 -0
- data/standards/stig_oracle_11_database_installation.json +527 -0
- data/standards/stig_oracle_11_database_instance.json +551 -0
- data/standards/stig_oracle_database_10g_installation.json +527 -0
- data/standards/stig_oracle_database_10g_instance.json +581 -0
- data/standards/stig_oracle_database_11.2g.json +1229 -0
- data/standards/stig_oracle_database_11g_installation.json +527 -0
- data/standards/stig_oracle_database_11g_instance.json +575 -0
- data/standards/stig_oracle_database_12c.json +1217 -0
- data/standards/stig_oracle_http_server_12.1.3.json +1703 -0
- data/standards/stig_oracle_linux_5.json +3431 -0
- data/standards/stig_oracle_linux_6.json +1583 -0
- data/standards/stig_oracle_weblogic_server_12c.json +443 -0
- data/standards/stig_palo_alto_networks_alg.json +311 -0
- data/standards/stig_palo_alto_networks_idps.json +185 -0
- data/standards/stig_palo_alto_networks_ndm.json +251 -0
- data/standards/stig_pda.json +83 -0
- data/standards/stig_pdasmartphone.json +95 -0
- data/standards/stig_perimeter_l3_switch.json +923 -0
- data/standards/stig_perimeter_l3_switch_-_cisco.json +1001 -0
- data/standards/stig_perimeter_router.json +803 -0
- data/standards/stig_perimeter_router_cisco.json +881 -0
- data/standards/stig_perimeter_router_juniper.json +803 -0
- data/standards/stig_postgresql_9.x.json +677 -0
- data/standards/stig_red_hat_enterprise_linux_5.json +3437 -0
- data/standards/stig_red_hat_enterprise_linux_6.json +1565 -0
- data/standards/stig_red_hat_enterprise_linux_7.json +1451 -0
- data/standards/stig_remote_access_policy.json +317 -0
- data/standards/stig_removable_storage_and_external_connection_technologies.json +143 -0
- data/standards/stig_removable_storage_and_external_connections.json +137 -0
- data/standards/stig_rfid_scanner.json +35 -0
- data/standards/stig_rfid_workstation.json +23 -0
- data/standards/stig_riverbed_steelhead_cx_v8_alg.json +83 -0
- data/standards/stig_riverbed_steelhead_cx_v8_ndm.json +371 -0
- data/standards/stig_router_security_requirements_guide.json +575 -0
- data/standards/stig_samsung_android_os_5_with_knox_2.0.json +365 -0
- data/standards/stig_samsung_android_os_6_with_knox_2.x.json +377 -0
- data/standards/stig_samsung_android_os_7_with_knox_2.x.json +443 -0
- data/standards/stig_samsung_android_with_knox_1.x.json +293 -0
- data/standards/stig_samsung_android_with_knox_2.x.json +371 -0
- data/standards/stig_samsung_knox_android_1.0.json +167 -0
- data/standards/stig_sharepoint_2010.json +269 -0
- data/standards/stig_sharepoint_2013.json +245 -0
- data/standards/stig_smartphone_policy.json +131 -0
- data/standards/stig_solaris_10_sparc.json +3029 -0
- data/standards/stig_solaris_10_x86.json +3065 -0
- data/standards/stig_solaris_11_sparc.json +1427 -0
- data/standards/stig_solaris_11_x86.json +1421 -0
- data/standards/stig_solaris_9_sparc.json +2915 -0
- data/standards/stig_solaris_9_x86.json +2915 -0
- data/standards/stig_sun_ray_4.json +185 -0
- data/standards/stig_sun_ray_4_policy.json +77 -0
- data/standards/stig_suse_linux_enterprise_server_v11system_z.json +3311 -0
- data/standards/stig_symantec_endpoint_protection_12.1_local_client_antivirus.json +689 -0
- data/standards/stig_symantec_endpoint_protection_12.1_managed_client_antivirus.json +695 -0
- data/standards/stig_tanium_6.5.json +461 -0
- data/standards/stig_tanium_7.0.json +803 -0
- data/standards/stig_test_and_development_zone_a.json +167 -0
- data/standards/stig_test_and_development_zone_b.json +179 -0
- data/standards/stig_test_and_development_zone_c.json +143 -0
- data/standards/stig_test_and_development_zone_d.json +143 -0
- data/standards/stig_traditional_security.json +917 -0
- data/standards/stig_unix_srg.json +3287 -0
- data/standards/stig_video_services_policy.json +497 -0
- data/standards/stig_video_teleconference.json +47 -0
- data/standards/stig_video_teleconference_vtc.json +12 -0
- data/standards/stig_vmware_esx_3_policy.json +155 -0
- data/standards/stig_vmware_esx_3_server.json +3791 -0
- data/standards/stig_vmware_esx_3_virtual_center.json +257 -0
- data/standards/stig_vmware_esx_3_virtual_machine.json +53 -0
- data/standards/stig_vmware_esxi_server_5.0.json +809 -0
- data/standards/stig_vmware_esxi_v5.json +5177 -0
- data/standards/stig_vmware_esxi_version_5_virtual_machine.json +317 -0
- data/standards/stig_vmware_nsx_distributed_firewall.json +83 -0
- data/standards/stig_vmware_nsx_distributed_logical_router.json +35 -0
- data/standards/stig_vmware_nsx_manager.json +191 -0
- data/standards/stig_vmware_vcenter_server.json +179 -0
- data/standards/stig_vmware_vcenter_server_version_5.json +149 -0
- data/standards/stig_vmware_vsphere_esxi_6.0.json +659 -0
- data/standards/stig_vmware_vsphere_vcenter_server_version_6.json +311 -0
- data/standards/stig_vmware_vsphere_virtual_machine_version_6.json +269 -0
- data/standards/stig_voice_and_video_over_internet_protocol_vvoip_policy.json +407 -0
- data/standards/stig_voice_video_endpoint_security_requirements_guide.json +395 -0
- data/standards/stig_voice_video_services_policy.json +671 -0
- data/standards/stig_voice_video_session_management_security_requirements_guide.json +329 -0
- data/standards/stig_voicevideo_over_internet_protocol.json +419 -0
- data/standards/stig_voicevideo_over_internet_protocol_vvoip.json +263 -0
- data/standards/stig_voicevideo_services_policy.json +569 -0
- data/standards/stig_web_policy.json +95 -0
- data/standards/stig_web_server.json +317 -0
- data/standards/stig_web_server_security_requirements_guide.json +587 -0
- data/standards/stig_win2k3_audit.json +761 -0
- data/standards/stig_win2k8_audit.json +1085 -0
- data/standards/stig_win2k8_r2_audit.json +1637 -0
- data/standards/stig_win7_audit.json +1613 -0
- data/standards/stig_windows_10.json +1691 -0
- data/standards/stig_windows_2003_domain_controller.json +893 -0
- data/standards/stig_windows_2003_member_server.json +845 -0
- data/standards/stig_windows_2008_domain_controller.json +1475 -0
- data/standards/stig_windows_2008_member_server.json +1301 -0
- data/standards/stig_windows_7.json +1781 -0
- data/standards/stig_windows_8.json +2399 -0
- data/standards/stig_windows_88.1.json +2273 -0
- data/standards/stig_windows_8_8.1.json +2297 -0
- data/standards/stig_windows_defender_antivirus.json +239 -0
- data/standards/stig_windows_dns.json +185 -0
- data/standards/stig_windows_firewall_with_advanced_security.json +137 -0
- data/standards/stig_windows_paw.json +155 -0
- data/standards/stig_windows_phone_6.5_with_good_mobility_suite.json +65 -0
- data/standards/stig_windows_server_2008_r2_domain_controller.json +1961 -0
- data/standards/stig_windows_server_2008_r2_member_server.json +1745 -0
- data/standards/stig_windows_server_20122012_r2_domain_controller.json +2255 -0
- data/standards/stig_windows_server_20122012_r2_member_server.json +2045 -0
- data/standards/stig_windows_server_2012_2012_r2_domain_controller.json +2279 -0
- data/standards/stig_windows_server_2012_2012_r2_member_server.json +2075 -0
- data/standards/stig_windows_server_2012_domain_controller.json +2471 -0
- data/standards/stig_windows_server_2012_member_server.json +2249 -0
- data/standards/stig_windows_server_2016.json +1661 -0
- data/standards/stig_windows_vista.json +1517 -0
- data/standards/stig_windows_xp.json +893 -0
- data/standards/stig_wireless_keyboard_and_mouse.json +23 -0
- data/standards/stig_wireless_management_server_policy.json +53 -0
- data/standards/stig_wireless_remote_access_policy_security_implementation_guide.json +29 -0
- data/standards/stig_wlan_access_point_enclave-niprnet_connected.json +227 -0
- data/standards/stig_wlan_access_point_internet_gateway_only_connection.json +209 -0
- data/standards/stig_wlan_access_point_policy.json +17 -0
- data/standards/stig_wlan_authentication_server.json +29 -0
- data/standards/stig_wlan_bridge.json +209 -0
- data/standards/stig_wlan_client.json +65 -0
- data/standards/stig_wlan_controller.json +215 -0
- data/standards/stig_wlan_ids_sensorserver.json +23 -0
- data/standards/stig_wman_access_point.json +263 -0
- data/standards/stig_wman_bridge.json +209 -0
- data/standards/stig_wman_subscriber.json +65 -0
- data/standards/stig_zos_acf2.json +1451 -0
- data/standards/stig_zos_bmc_control-dacf2.json +53 -0
- data/standards/stig_zos_bmc_control-dracf.json +59 -0
- data/standards/stig_zos_bmc_control-dtss.json +65 -0
- data/standards/stig_zos_bmc_control-macf2.json +59 -0
- data/standards/stig_zos_bmc_control-mracf.json +65 -0
- data/standards/stig_zos_bmc_control-mrestartacf2.json +23 -0
- data/standards/stig_zos_bmc_control-mrestartracf.json +23 -0
- data/standards/stig_zos_bmc_control-mrestarttss.json +23 -0
- data/standards/stig_zos_bmc_control-mtss.json +71 -0
- data/standards/stig_zos_bmc_control-oacf2.json +53 -0
- data/standards/stig_zos_bmc_control-oracf.json +59 -0
- data/standards/stig_zos_bmc_control-otss.json +65 -0
- data/standards/stig_zos_bmc_ioaacf2.json +53 -0
- data/standards/stig_zos_bmc_ioaracf.json +59 -0
- data/standards/stig_zos_bmc_ioatss.json +65 -0
- data/standards/stig_zos_bmc_mainviewzosacf2.json +47 -0
- data/standards/stig_zos_bmc_mainviewzosracf.json +53 -0
- data/standards/stig_zos_bmc_mainviewzostss.json +59 -0
- data/standards/stig_zos_ca_1_tape_managementacf2.json +65 -0
- data/standards/stig_zos_ca_1_tape_managementracf.json +77 -0
- data/standards/stig_zos_ca_1_tape_managementtss.json +77 -0
- data/standards/stig_zos_ca_auditoracf2.json +29 -0
- data/standards/stig_zos_ca_auditorracf.json +29 -0
- data/standards/stig_zos_ca_auditortss.json +29 -0
- data/standards/stig_zos_ca_common_servicesacf2.json +23 -0
- data/standards/stig_zos_ca_common_servicesracf.json +29 -0
- data/standards/stig_zos_ca_common_servicestss.json +29 -0
- data/standards/stig_zos_ca_micsacf2.json +23 -0
- data/standards/stig_zos_ca_micsracf.json +23 -0
- data/standards/stig_zos_ca_micstss.json +23 -0
- data/standards/stig_zos_ca_mimacf2.json +41 -0
- data/standards/stig_zos_ca_mimracf.json +47 -0
- data/standards/stig_zos_ca_mimtss.json +47 -0
- data/standards/stig_zos_ca_vtapeacf2.json +29 -0
- data/standards/stig_zos_ca_vtaperacf.json +35 -0
- data/standards/stig_zos_ca_vtapetss.json +35 -0
- data/standards/stig_zos_catalog_solutionsacf2.json +23 -0
- data/standards/stig_zos_catalog_solutionsracf.json +23 -0
- data/standards/stig_zos_catalog_solutionstss.json +23 -0
- data/standards/stig_zos_clsupersessionacf2.json +53 -0
- data/standards/stig_zos_clsupersessionracf.json +65 -0
- data/standards/stig_zos_clsupersessiontss.json +71 -0
- data/standards/stig_zos_compuware_abend-aidacf2.json +47 -0
- data/standards/stig_zos_compuware_abend-aidracf.json +53 -0
- data/standards/stig_zos_compuware_abend-aidtss.json +53 -0
- data/standards/stig_zos_cssmtpacf2.json +23 -0
- data/standards/stig_zos_cssmtpracf.json +29 -0
- data/standards/stig_zos_cssmtptss.json +29 -0
- data/standards/stig_zos_fdracf2.json +23 -0
- data/standards/stig_zos_fdrracf.json +23 -0
- data/standards/stig_zos_fdrtss.json +23 -0
- data/standards/stig_zos_hcdacf2.json +29 -0
- data/standards/stig_zos_hcdracf.json +29 -0
- data/standards/stig_zos_hcdtss.json +29 -0
- data/standards/stig_zos_ibm_cics_transaction_serveracf2.json +17 -0
- data/standards/stig_zos_ibm_cics_transaction_serverracf.json +17 -0
- data/standards/stig_zos_ibm_cics_transaction_servertss.json +17 -0
- data/standards/stig_zos_ibm_health_checkeracf2.json +23 -0
- data/standards/stig_zos_ibm_health_checkerracf.json +29 -0
- data/standards/stig_zos_ibm_health_checkertss.json +29 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsfacf2.json +53 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsfracf.json +59 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsftss.json +53 -0
- data/standards/stig_zos_icsfacf2.json +29 -0
- data/standards/stig_zos_icsfracf.json +35 -0
- data/standards/stig_zos_icsftss.json +35 -0
- data/standards/stig_zos_netviewacf2.json +41 -0
- data/standards/stig_zos_netviewracf.json +47 -0
- data/standards/stig_zos_netviewtss.json +53 -0
- data/standards/stig_zos_quest_nc-passacf2.json +35 -0
- data/standards/stig_zos_quest_nc-passracf.json +41 -0
- data/standards/stig_zos_quest_nc-passtss.json +47 -0
- data/standards/stig_zos_racf.json +1415 -0
- data/standards/stig_zos_roscoeacf2.json +47 -0
- data/standards/stig_zos_roscoeracf.json +53 -0
- data/standards/stig_zos_roscoetss.json +59 -0
- data/standards/stig_zos_srrauditacf2.json +23 -0
- data/standards/stig_zos_srrauditracf.json +23 -0
- data/standards/stig_zos_srraudittss.json +23 -0
- data/standards/stig_zos_tadzacf2.json +29 -0
- data/standards/stig_zos_tadzracf.json +35 -0
- data/standards/stig_zos_tadztss.json +35 -0
- data/standards/stig_zos_tdmfacf2.json +23 -0
- data/standards/stig_zos_tdmfracf.json +23 -0
- data/standards/stig_zos_tdmftss.json +23 -0
- data/standards/stig_zos_tss.json +1523 -0
- data/standards/stig_zos_vssracf.json +29 -0
- metadata +691 -0
|
@@ -0,0 +1,1229 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_oracle_database_11.2g",
|
|
3
|
+
"date": "2018-01-02",
|
|
4
|
+
"description": "Developed by Oracle in coordination with DISA for the DoD. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
|
|
5
|
+
"title": "Oracle Database 11.2g Security Technical Implementation Guide",
|
|
6
|
+
"version": "1",
|
|
7
|
+
"item_syntax": "^\\w-\\d+$",
|
|
8
|
+
"section_separator": null,
|
|
9
|
+
"items": [
|
|
10
|
+
{
|
|
11
|
+
"id": "V-52125",
|
|
12
|
+
"title": "DBA OS accounts must be granted only those host system privileges necessary for the administration of the DBMS.",
|
|
13
|
+
"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\nDBAs, if assigned excessive OS privileges, could perform actions that could endanger the information system or hide evidence of malicious activity.",
|
|
14
|
+
"severity": "high"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"id": "V-52133",
|
|
18
|
+
"title": "The DBMS must protect the integrity of publicly available information and applications.",
|
|
19
|
+
"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\nDatabases designed to contain publicly available information, though not concerned with confidentiality, must still maintain the integrity of the data they house. If data available to the public is not protected from unauthorized modification, then it cannot be trusted by those accessing it.",
|
|
20
|
+
"severity": "medium"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "V-52135",
|
|
24
|
+
"title": "The DBMS must terminate user sessions upon user logout or any other organization or policy-defined session termination events, such as idle time limit exceeded.",
|
|
25
|
+
"description": "This requirement focuses on communications protection at the application session, versus network packet, level. \n\nSession IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session.\n\nDatabase sessions must be terminated when no longer in use in order to prevent session hijacking.",
|
|
26
|
+
"severity": "medium"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "V-52137",
|
|
30
|
+
"title": "The DBMS must provide a logout functionality to allow the user to manually terminate the session.",
|
|
31
|
+
"description": "Manually terminating an application session allows users to immediately depart the physical vicinity of the system they are logged into without the risk of subsequent system users reactivating or continuing their application session. Users who log into applications must have the ability to manually terminate their application session.\n\nWithout an observable manual logout capability provided by the application, the user will have no means of manually terminating their application session. Their session could remain active until which time the inactivity period expires and the application automatically logs the user out. This increases the likelihood that the next subsequent user of the system could pick up on the previous user's session and continue utilizing the application as the previous user.",
|
|
32
|
+
"severity": "medium"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "V-52141",
|
|
36
|
+
"title": "The DBMS must preserve any organization-defined system state information in the event of a system failure.",
|
|
37
|
+
"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 information system or a component of the system.\n\nPreserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes.",
|
|
38
|
+
"severity": "medium"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "V-52143",
|
|
42
|
+
"title": "The DBMS must take needed steps to protect data at rest and ensure confidentiality and integrity of application data.",
|
|
43
|
+
"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) within an organizational information system. Applications and application users generate information throughout the course of their application use. \n\nUser-generated data and application specific configuration data both need to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, and filtering routers and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. \n\nIf the confidentiality and integrity of application data is not protected, the data will be open to compromise and unauthorized modification.",
|
|
44
|
+
"severity": "medium"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "V-52145",
|
|
48
|
+
"title": "The DBMS must employ cryptographic mechanisms preventing the unauthorized disclosure of information at rest.",
|
|
49
|
+
"description": "This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices. If the data is not encrypted, it is subject to compromise and unauthorized disclosure.",
|
|
50
|
+
"severity": "medium"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "V-52147",
|
|
54
|
+
"title": "The DBMS must isolate security functions from non-security functions by means of separate security domains.",
|
|
55
|
+
"description": "Security functions are defined as \"the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based\".\n\nDevelopers and implementers can increase the assurance in security functions by employing well-defined security policy models, structured, disciplined, and rigorous hardware and software development techniques, and sound system/security engineering principles.\n\nDatabase Management Systems typically separate security functionality from non-security functionality via separate databases or schemas. Database objects or code implementing security functionality should not be commingled with objects or code implementing application logic. When security and non-security functionality is commingled, users who have access to non-security functionality may be able to access security functionality.",
|
|
56
|
+
"severity": "medium"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"id": "V-52149",
|
|
60
|
+
"title": "The DBMS must automatically terminate emergency accounts after an organization-defined time period for each type of account.",
|
|
61
|
+
"description": "Emergency application accounts are typically created due to an unforeseen operational event or could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support-related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left.\n\nIn the event emergency application accounts are required, the application must ensure accounts that are designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or application data compromised.\n\nNote: User authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.\n\nIf it is possible for any temporary emergency accounts to be created and managed by Oracle, then the DBMS or application must provide or utilize a mechanism to automatically terminate such accounts after an organization-defined time period.\n\nEmergency database accounts must be automatically terminated after an organization-defined time period in order to mitigate the risk of the account being misused.",
|
|
62
|
+
"severity": "medium"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-52151",
|
|
66
|
+
"title": "The DBMS must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event.",
|
|
67
|
+
"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\nDatabase software is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly who performed a given action. If user identification information is not recorded and stored with the audit record, the record itself is of very limited use.",
|
|
68
|
+
"severity": "medium"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-52153",
|
|
72
|
+
"title": "The DBMS must employ automated mechanisms to alert security personnel of inappropriate or unusual activities with security implications.",
|
|
73
|
+
"description": "Applications will typically utilize logging mechanisms for maintaining a historical log of activity that occurs within the application. This information can then be used for diagnostic purposes, forensics purposes, or other purposes relevant to ensuring the availability and integrity of the application.\n\nWhile it is important to log events identified as being critical and relevant to security, it is equally important to notify the appropriate personnel in a timely manner, so they are able to respond to events as they occur.\n\nSolutions that include a manual notification procedure do not offer the reliability and speed of an automated notification solution. Applications must employ automated mechanisms to alert security personnel of inappropriate or unusual activities that have security implications. If this capability is not built directly into the application, the application must be able to integrate with existing security infrastructure that provides this capability.\n\nDatabase management systems that do not automatically alert security personnel of unusual activities run the risk of security incidents going unnoticed for long periods of time. This can allow security breaches to be ongoing and more serious.",
|
|
74
|
+
"severity": "medium"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-52155",
|
|
78
|
+
"title": "The DBMS must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.",
|
|
79
|
+
"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\nIn addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events. These events may be identified by type, location, or subject. \n\nAn example of detailed information the organization may require in audit records is full-text recording of privileged commands or the individual identities of group account users.\n\nSome organizations may determine that more detailed information is required for specific database event types. If this information is not available, it could negatively impact forensic investigations into user actions or other malicious events.",
|
|
80
|
+
"severity": "medium"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "V-52157",
|
|
84
|
+
"title": "The DBMS must prevent unauthorized and unintended information transfer via shared system resources.",
|
|
85
|
+
"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) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.\n\nData used for the development and testing of applications often involves copying data from production. It is important that specific procedures exist for this process, so copies of sensitive data are not misplaced or left in a temporary location without the proper controls.",
|
|
86
|
+
"severity": "medium"
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "V-52159",
|
|
90
|
+
"title": "The DBMS itself, or the logging or alerting mechanism the application utilizes, must provide a warning when allocated audit record storage volume reaches an organization-defined percentage of maximum audit record storage capacity.",
|
|
91
|
+
"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 subsequently occurring would not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80% of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel.\n\nA failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions. This can be an alert provided by the database, a log repository, or the OS when a designated log directory is nearing capacity.",
|
|
92
|
+
"severity": "medium"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-52161",
|
|
96
|
+
"title": "The DBMS must protect against or limit the effects of the organization-defined types of Denial of Service (DoS) attacks.",
|
|
97
|
+
"description": "A variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization's internal network from being directly affected by DoS attacks.\n\nEmploying increased capacity and bandwidth combined with service redundancy may reduce the susceptibility to some DoS attacks.\n\nSome of the ways databases can limit their exposure to DoS attacks are through limiting the number of connections that can be opened by a single user and database clustering.",
|
|
98
|
+
"severity": "medium"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"id": "V-52163",
|
|
102
|
+
"title": "The DBMS must provide a real-time alert when organization-defined audit failure events occur.",
|
|
103
|
+
"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 subsequently occurring would not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80% of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel. \n\nA failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions. This can be an alert provided by the database, a log repository, or the OS when a designated log directory is nearing capacity.\n\nIf Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an alert can be sent to a designated administrator.",
|
|
104
|
+
"severity": "medium"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"id": "V-52165",
|
|
108
|
+
"title": "The DBMS must check the validity of data inputs.",
|
|
109
|
+
"description": "Invalid user input occurs when a user inserts data or characters into an application's data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior, potentially leading to an application or information system compromise. Invalid user input is one of the primary methods employed when attempting to compromise an application.\n\nAll applications need to validate the data users attempt to input to the application for processing. Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, acceptable values) are in place to verify inputs match specified definitions for format and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally interpreted as commands.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.",
|
|
110
|
+
"severity": "medium"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-52167",
|
|
114
|
+
"title": "The DBMS must alert designated organizational officials in the event of an audit processing failure.",
|
|
115
|
+
"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\nA failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions.\n\nIf Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an alert can be sent to a designated administrator.",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-52169",
|
|
120
|
+
"title": "The DBMS must verify there have not been unauthorized changes to the DBMS software and information.",
|
|
121
|
+
"description": "Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes), and to use tools to automatically monitor the integrity of the information system and the applications it hosts.\n\nThe DBMS opens data files and reads configuration files at system startup, system shutdown, and during abort recovery efforts. If the DBMS does not verify the trustworthiness of these files, it is vulnerable to malicious alterations of its configuration or unauthorized replacement of data.",
|
|
122
|
+
"severity": "medium"
|
|
123
|
+
},
|
|
124
|
+
{
|
|
125
|
+
"id": "V-52171",
|
|
126
|
+
"title": "The system must provide the capability to automatically process audit records for events of interest based upon selectable event criteria.",
|
|
127
|
+
"description": "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\nThis is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups.\n\nAn audit reduction capability provides support for near real-time audit review and analysis based on policy requirements regarding what must be audited on the system and after-the-fact investigations of security incidents. It is important to recognize audit reduction does not alter original audit records.\n\nAudit reduction and reporting tools do not alter original audit records.\n\nTo leverage the complete capability of audit reduction, the application must possess the ability to specify and automatically process certain event criteria that are selectable in nature. In other words, a system administrator (SA) may be performing a manual review of audit data to identify a particular problem. The SA has determined that backup activity and network connections from a particular host comprise the bulk of the events. However, these events are not related to the activity being investigated. The application must be able to automatically process these audit records for audit reduction purposes rather than making the administrator manually process them.\n\nThe lack of audit reduction and reporting in a database can require the DBA, or others responsible for reviewing audit logs, to sort through large amounts of data in order to find relevant records. This can cause important audit records to be missed.\n\nOracle offers the choice of storing audit data internally in database tables, or in external files. The WHERE clause in the SELECT statement provides the necessary functionality for a table-based audit. For an audit based on external files (or for a table-based audit trail archived to external files) Oracle Database does not provide tools for retrieving and managing the data once written. Therefore, an external tool is needed.",
|
|
128
|
+
"severity": "medium"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"id": "V-52173",
|
|
132
|
+
"title": "The DBMS must identify potentially security-relevant error conditions.",
|
|
133
|
+
"description": "The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. \n\nDatabase logs can be monitored for specific security-related errors. Any error that can have a negative effect on database security should be quickly identified and forwarded to the appropriate personnel. If security-relevant error conditions are not identified by the DBMS, they may be overlooked by the personnel responsible for addressing them.",
|
|
134
|
+
"severity": "medium"
|
|
135
|
+
},
|
|
136
|
+
{
|
|
137
|
+
"id": "V-52175",
|
|
138
|
+
"title": "Attempts to bypass access controls must be audited.",
|
|
139
|
+
"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\nDetection of suspicious activity, including access attempts and successful access from unexpected places, during unexpected times, or other unusual indicators can support decisions to apply countermeasures to deter an attack. Without detection, malicious activity may proceed without hindrance.",
|
|
140
|
+
"severity": "medium"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-52177",
|
|
144
|
+
"title": "The DBMS must only generate error messages that provide information necessary for corrective actions without revealing organization-defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited.",
|
|
145
|
+
"description": "Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team.\n\nThe extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. Sensitive information includes account numbers, social security numbers, and credit card numbers.\n\nDatabases can inadvertently provide a wealth of information to an attacker through improperly handled error messages. In addition to sensitive business or personal information, database errors can provide host names, IP addresses, user names, and other system information not required for troubleshooting but very useful to someone targeting the system.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed, and must document what has been discovered.",
|
|
146
|
+
"severity": "medium"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-52179",
|
|
150
|
+
"title": "The DBMS must protect audit information from any type of unauthorized access.",
|
|
151
|
+
"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. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc.\n\nThis requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. \n\nAdditionally, applications with user interfaces to audit records must not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.",
|
|
152
|
+
"severity": "medium"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "V-52181",
|
|
156
|
+
"title": "The DBMS must restrict error messages, so only authorized personnel may view them.",
|
|
157
|
+
"description": "If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.\n\nSome default DBMS error messages can contain information that could aid an attacker in, among others things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information. It is important that error messages are displayed only to those who are authorized to view them.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.",
|
|
158
|
+
"severity": "medium"
|
|
159
|
+
},
|
|
160
|
+
{
|
|
161
|
+
"id": "V-52183",
|
|
162
|
+
"title": "The DBMS must support taking organization-defined list of least disruptive actions to terminate suspicious events.",
|
|
163
|
+
"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 application takes to terminate suspicious events. A least disruptive action may include initiating a request for human response rather than blocking traffic or disrupting system operation.\n\nIn order to preserve availability, it is important for the DBMS to terminate suspicious events with the least disruptive action possible. If suspicious events are not terminated, an attacker may gain entry into the system; however, if the system overreacts to a suspicious event and takes an overly disruptive action, a Denial of Service (DoS) may occur.",
|
|
164
|
+
"severity": "medium"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "V-52185",
|
|
168
|
+
"title": "The DBMS must protect audit information from unauthorized modification.",
|
|
169
|
+
"description": "If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. \n\nThis requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions and limiting log data locations. \n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n\nModification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.",
|
|
170
|
+
"severity": "medium"
|
|
171
|
+
},
|
|
172
|
+
{
|
|
173
|
+
"id": "V-52187",
|
|
174
|
+
"title": "The DBMS must notify appropriate individuals when accounts are created.",
|
|
175
|
+
"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 create a new account.\n\nNotification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle.\n\nNotwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon account creation within Oracle. Indeed, in a configuration where accounts are managed externally, the creation of an account within Oracle may indicate hostile activity.",
|
|
176
|
+
"severity": "medium"
|
|
177
|
+
},
|
|
178
|
+
{
|
|
179
|
+
"id": "V-52189",
|
|
180
|
+
"title": "The DBMS must protect audit information from unauthorized deletion.",
|
|
181
|
+
"description": "If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n\nTo ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design. \n\nSome commonly employed methods include: ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access; and backing up log data to ensure log data is retained. \n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n\nDeletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.",
|
|
182
|
+
"severity": "medium"
|
|
183
|
+
},
|
|
184
|
+
{
|
|
185
|
+
"id": "V-52191",
|
|
186
|
+
"title": "The DBMS must notify appropriate individuals when accounts are modified.",
|
|
187
|
+
"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 modify an existing account for later use.\n\nNotification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners that they exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle.\n\nNotwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon account modification within Oracle. Indeed, in a configuration where accounts are managed externally, the manipulation of an account within Oracle may indicate hostile activity.",
|
|
188
|
+
"severity": "medium"
|
|
189
|
+
},
|
|
190
|
+
{
|
|
191
|
+
"id": "V-52193",
|
|
192
|
+
"title": "The DBMS must protect audit tools from unauthorized access.",
|
|
193
|
+
"description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. \n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.\n\nAudit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. \n\nIf an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.",
|
|
194
|
+
"severity": "medium"
|
|
195
|
+
},
|
|
196
|
+
{
|
|
197
|
+
"id": "V-52195",
|
|
198
|
+
"title": "The DBMS must notify appropriate individuals when account disabling actions are taken.",
|
|
199
|
+
"description": "When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. \n\nIn order to detect and respond to events that affect user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. \n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle.\n\nNotwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon the disabling of an account within Oracle. Indeed, in a configuration where accounts are managed externally, the manipulation of an account within Oracle may indicate hostile activity.",
|
|
200
|
+
"severity": "medium"
|
|
201
|
+
},
|
|
202
|
+
{
|
|
203
|
+
"id": "V-52197",
|
|
204
|
+
"title": "The DBMS must protect audit tools from unauthorized modification.",
|
|
205
|
+
"description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. \n\nIf the tools are compromised it could provide attackers with the capability to manipulate log data. It is, therefore, imperative that audit tools be controlled and protected from unauthorized modification. \n\nAudit tools include, but are not limited to, OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. \n\nIf an attacker were to gain access to audit tools he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.",
|
|
206
|
+
"severity": "medium"
|
|
207
|
+
},
|
|
208
|
+
{
|
|
209
|
+
"id": "V-52199",
|
|
210
|
+
"title": "The DBMS must notify appropriate individuals when accounts are terminated.",
|
|
211
|
+
"description": "When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. \n\nIn order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals when an account is terminated so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. \n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle.\n\nNotwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon account termination within Oracle. Indeed, in a configuration where accounts are managed externally, the manipulation of an account within Oracle may indicate hostile activity.",
|
|
212
|
+
"severity": "medium"
|
|
213
|
+
},
|
|
214
|
+
{
|
|
215
|
+
"id": "V-52201",
|
|
216
|
+
"title": "The DBMS must protect audit tools from unauthorized deletion.",
|
|
217
|
+
"description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. \n\nIt is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. \n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.\n\nAudit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. \n\nIf an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.",
|
|
218
|
+
"severity": "medium"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "V-52203",
|
|
222
|
+
"title": "The DBMS must implement separation of duties through assigned information access authorizations.",
|
|
223
|
+
"description": "Separation of duties is a prevalent Information Technology control that is 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 that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action.\n\nAdditionally, the person or entity accountable for monitoring the activity must be separate as well. To meet this requirement, applications, when applicable, shall be divided where functionality is based on roles and duties. Examples of separation of duties include: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles.\n\nPrivileges granted outside the context of the application user job function are more likely to go unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment.",
|
|
224
|
+
"severity": "low"
|
|
225
|
+
},
|
|
226
|
+
{
|
|
227
|
+
"id": "V-52205",
|
|
228
|
+
"title": "The DBMS must support the requirement to back up audit data and records onto a different system or media than the system being audited on an organization-defined frequency.",
|
|
229
|
+
"description": "Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto media separate from the system being audited on an organizational-defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained.",
|
|
230
|
+
"severity": "medium"
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "V-52209",
|
|
234
|
+
"title": "The DBMS must provide an audit log reduction capability.",
|
|
235
|
+
"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\nThis is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. Audit reduction does not alter original audit records. \n\nAn audit reduction capability provides support for near real-time audit review and analysis requirements and after-the-fact investigations of security incidents.\n\nThe lack of audit reduction in a database can require the DBA, or others responsible for reviewing audit logs, to sort through large amounts of data in order to find relevant records. This can cause important audit records to be missed.",
|
|
236
|
+
"severity": "low"
|
|
237
|
+
},
|
|
238
|
+
{
|
|
239
|
+
"id": "V-52211",
|
|
240
|
+
"title": "The DBMS must protect audit data records and integrity by using cryptographic mechanisms.",
|
|
241
|
+
"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. An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography. \n\nNon-repudiation protects individuals against later claims by an author of not having performed a particular action, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document.",
|
|
242
|
+
"severity": "medium"
|
|
243
|
+
},
|
|
244
|
+
{
|
|
245
|
+
"id": "V-52213",
|
|
246
|
+
"title": "The DBMS must provide a report generation capability for audit reduction data.",
|
|
247
|
+
"description": "In support of Audit Review, Analysis, and Reporting requirements, audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review. \n\nBefore a security review is conducted, information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. \n\nIn order to identify and report on what (repetitive) data has been removed via the use of audit reduction, the application must provide a capability to generate reports containing what values were removed by the audit reduction. \n\nAudit reduction does not alter original audit records. An audit reduction capability provides support for near real-time audit review and analysis based on policy-based requirements and after-the-fact investigations of security incidents. \n\nReporting tools employing audit reduction methods must not alter the original audit data. An example of a tool employing audit reduction methods is the Windows Event Viewer tool which is used to view and analyze audit logs on Windows systems.\n\nThe lack of reporting tools for audit reduction can require the DBA, or others responsible for reviewing audit logs, to sort through large amounts of data in order to find relevant records. This can cause important audit records to be missed.",
|
|
248
|
+
"severity": "low"
|
|
249
|
+
},
|
|
250
|
+
{
|
|
251
|
+
"id": "V-52215",
|
|
252
|
+
"title": "The DBMS must protect the audit records generated, as a result of remote access to privileged accounts, and the execution of privileged functions.",
|
|
253
|
+
"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. \n\nAuditing might not be reliable when performed by an information system which the user being audited has privileged access to. \n\nThe 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\nReducing the risk of audit compromises by privileged users can also be achieved, for example, by performing audit activity on a separate information system where the user in question has limited access or by using storage media that cannot be modified (e.g., write-once recording devices).\n\nIf an attacker were to gain access to audit tools he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.",
|
|
254
|
+
"severity": "medium"
|
|
255
|
+
},
|
|
256
|
+
{
|
|
257
|
+
"id": "V-52217",
|
|
258
|
+
"title": "The DBMS must restrict the ability of users to launch Denial of Service (DoS) attacks against other information systems or networks.",
|
|
259
|
+
"description": "When it comes to DoS attacks, most of the attention is paid to ensuring that systems and applications are not victims of these attacks.\n\nWhile it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks.\n\nFor example, boundary protection devices can filter certain types of packets to protect devices from being directly affected by DoS attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks.\n\nApplications and application developers must take the steps needed to ensure users cannot use these applications to launch DoS attacks against other systems and networks. An example would be designing applications to include mechanisms that throttle network traffic so users are not able to generate unlimited network traffic via the application.\n\nThe methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.",
|
|
260
|
+
"severity": "low"
|
|
261
|
+
},
|
|
262
|
+
{
|
|
263
|
+
"id": "V-52219",
|
|
264
|
+
"title": "The DBMS must support enforcement of logical access restrictions associated with changes to the DBMS configuration and to the database itself.",
|
|
265
|
+
"description": "When dealing with access restrictions pertaining to change control, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. \n\nModifications to the DBMS settings, the database files, database configuration files, or the underlying database application files themselves could have catastrophic consequences to the database. Modification to DBMS settings could include turning off access controls to the database, the halting of archiving, the halting of auditing, and any number of other malicious actions.\n",
|
|
266
|
+
"severity": "medium"
|
|
267
|
+
},
|
|
268
|
+
{
|
|
269
|
+
"id": "V-52221",
|
|
270
|
+
"title": "The DBMS must manage resources to limit the effects of information flooding types of Denial of Service (DoS) incidents.",
|
|
271
|
+
"description": "In the case of application DoS incidents, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time.\n\nThe methods employed to meet this requirement will vary depending upon the technology the application utilizes. However, a variety of technologies exist to limit, or in some cases, eliminate the effects of application-related DoS incidents. Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS problems.\n\nDatabases are particularly susceptible to SQL-related DoS issues. Databases that do not protect against resource-intensive SQL queries may experience dramatic slowdowns from malicious attacks or accidental DoS incidents related to SQL queries. What constitutes a resource-intensive query has to be determined locally, taking into account the purpose of the database and the needs of the various classes of user.",
|
|
272
|
+
"severity": "low"
|
|
273
|
+
},
|
|
274
|
+
{
|
|
275
|
+
"id": "V-52223",
|
|
276
|
+
"title": "Database objects must be owned by accounts authorized for ownership.",
|
|
277
|
+
"description": "Within the database, object ownership implies full privileges to the owned object including the privilege to assign access to the owned objects to other subjects. Unmanaged or uncontrolled ownership of objects can lead to unauthorized object grants and alterations, and unauthorized modifications to data. \n\nIf critical tables or other objects rely on unauthorized owner accounts, these objects can be lost when an account is removed.\n\nIt may be the case that there are accounts that are authorized to own synonyms, but no other objects. If this is so, it should be documented.",
|
|
278
|
+
"severity": "medium"
|
|
279
|
+
},
|
|
280
|
+
{
|
|
281
|
+
"id": "V-52225",
|
|
282
|
+
"title": "The DBMS must limit the use of resources by priority and not impede the host from servicing processes designated as a higher-priority.",
|
|
283
|
+
"description": "Priority protection helps prevent a lower-priority process from delaying or interfering with the information system servicing any higher-priority process. This control does not apply to components in the information system for which there is only a single user/role. The application must limit the use of resources by priority.\n\nThe DBMS is often running queries for multiple users. If lower-priority processes are utilizing a disproportionately high amount of database resources, this can severely impact higher-priority processes.",
|
|
284
|
+
"severity": "low"
|
|
285
|
+
},
|
|
286
|
+
{
|
|
287
|
+
"id": "V-52227",
|
|
288
|
+
"title": "The DBMS must support organizational requirements to employ automated patch management tools to facilitate flaw remediation to organization-defined information system components.",
|
|
289
|
+
"description": "The organization (including any contractor to the organization) shall promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, shall also be addressed expeditiously. Due to information system integrity and availability concerns, organizations shall give careful consideration to the methodology used to carry out automatic updates.\n\nAutomated patch management can be useful in ensuring that appropriate patches are scheduled and applied to databases as required. DBAs often support multiple databases in different environments and with different classification levels. This can lead to confusion if patch management is not automated, leading to inconsistent patching.",
|
|
290
|
+
"severity": "low"
|
|
291
|
+
},
|
|
292
|
+
{
|
|
293
|
+
"id": "V-52229",
|
|
294
|
+
"title": "The DBMS must enforce requirements for remote connections to the information system.",
|
|
295
|
+
"description": "Applications that provide remote access to information systems must be able to enforce remote access policy requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Examples of policy requirements include, but are not limited to, authorizing remote access to the information system, limiting access based on authentication credentials, and monitoring for unauthorized access. \n\nIf databases allowing remote connections do not enforce requirements for remote access, an attacker may gain access to the database and may, through the database, gain access to other components of the information system.",
|
|
296
|
+
"severity": "medium"
|
|
297
|
+
},
|
|
298
|
+
{
|
|
299
|
+
"id": "V-52231",
|
|
300
|
+
"title": "Default demonstration and sample databases, database objects, and applications must be removed.",
|
|
301
|
+
"description": "Information 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).\n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plugins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDemonstration and sample database objects and applications present publicly known attack points for malicious users. These demonstration and sample objects are meant to provide simple examples of coding specific functions and are not developed to prevent vulnerabilities from being introduced to the DBMS and host system.\n",
|
|
302
|
+
"severity": "medium"
|
|
303
|
+
},
|
|
304
|
+
{
|
|
305
|
+
"id": "V-52233",
|
|
306
|
+
"title": "Unused database components, DBMS software, and database objects must be removed.",
|
|
307
|
+
"description": "Information 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). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDemonstration and sample database objects and applications present publicly known attack points for malicious users. These demonstration and sample objects are meant to provide simple examples of coding specific functions and are not developed to prevent vulnerabilities from being introduced to the DBMS and host system.\n\nUnused and unnecessary DBMS components increase the attack vector for the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced.",
|
|
308
|
+
"severity": "medium"
|
|
309
|
+
},
|
|
310
|
+
{
|
|
311
|
+
"id": "V-52235",
|
|
312
|
+
"title": "Unused database components that are integrated in the DBMS and cannot be uninstalled must be disabled.",
|
|
313
|
+
"description": "Information 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). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused, unnecessary DBMS components increase the attack surface of the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced. Components of the system that are unused and cannot be uninstalled must be disabled.",
|
|
314
|
+
"severity": "medium"
|
|
315
|
+
},
|
|
316
|
+
{
|
|
317
|
+
"id": "V-52237",
|
|
318
|
+
"title": "Use of external executables must be authorized.",
|
|
319
|
+
"description": "Information 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). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plugins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDBMS's may spawn additional external processes to execute procedures that are defined in the DBMS, but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than the DBMS and provide unauthorized access to the host system.",
|
|
320
|
+
"severity": "medium"
|
|
321
|
+
},
|
|
322
|
+
{
|
|
323
|
+
"id": "V-52239",
|
|
324
|
+
"title": "The DBMS must support the organizational requirements to specifically prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services.",
|
|
325
|
+
"description": "Information 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). \n\nAdditionally, it is sometimes convenient to provide multiple services from a single component of an information system (e.g., email and web services), but doing so increases risk by constraining the ability to restrict the use of functions, ports, protocols, and/or services. \n\nTo support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.\n\nDatabase Management Systems using ports, protocols, and services deemed unsafe are open to attack through those ports, protocols, and services. This can allow unauthorized access to the database and through the database to other components of the information system.",
|
|
326
|
+
"severity": "medium"
|
|
327
|
+
},
|
|
328
|
+
{
|
|
329
|
+
"id": "V-52241",
|
|
330
|
+
"title": "Recovery procedures and technical system features must exist to ensure recovery is done in a secure and verifiable manner.",
|
|
331
|
+
"description": "Application recovery and reconstitution constitutes executing an information system contingency plan comprised of activities that restore essential missions and business functions. \n\nDatabase management systems and transaction-based processing systems are examples of information systems that are transaction-based. Transaction rollback and transaction journaling are examples of mechanisms supporting transaction recovery. \n\nA DBMS may be vulnerable to use of compromised data or other critical files during recovery. Use of compromised files could introduce maliciously altered application code, relaxed security settings or loss of data integrity. Where available, DBMS mechanisms to ensure use of only trusted files can help protect the database from this type of compromise during DBMS recovery. \n",
|
|
332
|
+
"severity": "medium"
|
|
333
|
+
},
|
|
334
|
+
{
|
|
335
|
+
"id": "V-52245",
|
|
336
|
+
"title": "Oracle must back up user-level information per a defined frequency.",
|
|
337
|
+
"description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD-defined frequency. \n\nDatabases that do not backup information regularly risk the loss of that information in the event of a system failure. Most databases contain functionality to allow regular backups; it is important that this functionality is enabled and configured correctly to prevent data loss.",
|
|
338
|
+
"severity": "medium"
|
|
339
|
+
},
|
|
340
|
+
{
|
|
341
|
+
"id": "V-52247",
|
|
342
|
+
"title": "Database backup procedures must be defined, documented, and implemented.",
|
|
343
|
+
"description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD-defined frequency.\n\nDatabase backups provide the required means to restore databases after compromise or loss. Backups help reduce the vulnerability to unauthorized access or hardware loss.",
|
|
344
|
+
"severity": "medium"
|
|
345
|
+
},
|
|
346
|
+
{
|
|
347
|
+
"id": "V-52249",
|
|
348
|
+
"title": "Database recovery procedures must be developed, documented, implemented, and periodically tested.",
|
|
349
|
+
"description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD-defined frequency.\n\nProblems with backup procedures or backup media may not be discovered until after a recovery is needed. Testing and verification of procedures provides the opportunity to discover oversights, conflicts, or other issues in the backup procedures or use of media designed to be used.",
|
|
350
|
+
"severity": "medium"
|
|
351
|
+
},
|
|
352
|
+
{
|
|
353
|
+
"id": "V-52251",
|
|
354
|
+
"title": "DBMS backup and restoration files must be protected from unauthorized access.",
|
|
355
|
+
"description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD-defined frequency.\n\nLost or compromised DBMS backup and restoration files may lead to not only the loss of data, but also the unauthorized access to sensitive data. Backup files need the same protections against unauthorized access when stored on backup media as when online and actively in use by the database system. In addition, the backup media needs to be protected against physical loss. Most DBMS's maintain online copies of critical control files to provide transparent or easy recovery from hard disk loss or other interruptions to database operation.",
|
|
356
|
+
"severity": "medium"
|
|
357
|
+
},
|
|
358
|
+
{
|
|
359
|
+
"id": "V-52253",
|
|
360
|
+
"title": "DBMS must conduct backups of system-level information per organization-defined frequency that is consistent with recovery time and recovery point objectives.",
|
|
361
|
+
"description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nSystem-level information includes: system-state information, operating system and application software, and licenses. \n\nBackups shall be consistent with organizational recovery time and recovery point objectives. \n\nDatabases that do not back up information regularly risk the loss of that information in the event of a system failure. Most databases contain functionality to allow regular backups; it is important that this functionality is enabled and configured correctly to prevent data loss.",
|
|
362
|
+
"severity": "medium"
|
|
363
|
+
},
|
|
364
|
+
{
|
|
365
|
+
"id": "V-52255",
|
|
366
|
+
"title": "The DBMS must use multifactor authentication for network access to privileged accounts.",
|
|
367
|
+
"description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric). \n\nA privileged account is defined as an information system account with authorizations of a privileged user. \n\nNetwork access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet).\n\nThe lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system.",
|
|
368
|
+
"severity": "medium"
|
|
369
|
+
},
|
|
370
|
+
{
|
|
371
|
+
"id": "V-52257",
|
|
372
|
+
"title": "The DBMS must use multifactor authentication for network access to non-privileged accounts.",
|
|
373
|
+
"description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric). \n\nA non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. \n\nNetwork access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet).\n\nThe lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system.",
|
|
374
|
+
"severity": "medium"
|
|
375
|
+
},
|
|
376
|
+
{
|
|
377
|
+
"id": "V-52259",
|
|
378
|
+
"title": "The DBMS must use multifactor authentication for local access to privileged accounts.",
|
|
379
|
+
"description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric). \n\nA privileged account is defined as an information system account with authorizations of a privileged user. \n\nLocal Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.\n\nThe lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system.",
|
|
380
|
+
"severity": "medium"
|
|
381
|
+
},
|
|
382
|
+
{
|
|
383
|
+
"id": "V-52263",
|
|
384
|
+
"title": "The DBMS must ensure users are authenticated with an individual authenticator prior to using a group authenticator.",
|
|
385
|
+
"description": "To assure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated. \n\nA group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. An example of a group authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\nFor example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a group authenticator.\n\nSome applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.\n\nThere may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server which contains publicly releasable information. These types of accesses are allowed but must be explicitly identified and documented by the organization.\n\nWhen group accounts are utilized without another means of identifying individual users, users may deny having performed a particular action.",
|
|
386
|
+
"severity": "medium"
|
|
387
|
+
},
|
|
388
|
+
{
|
|
389
|
+
"id": "V-52265",
|
|
390
|
+
"title": "The DBMS must use organization-defined replay-resistant authentication mechanisms for network access to privileged accounts.",
|
|
391
|
+
"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\nTechniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. \n \nReplay attacks, if successfully used against a database account, could result in unfettered access to the database settings and data. A successful replay attack against a privileged database account could result in a complete compromise of the database.\n\nOracle Database enables you to encrypt data that is sent over a network. There is no distinction between privileged and non-privileged accounts.\n\nEncryption of network data provides data privacy so that unauthorized parties are not able to view plain-text data as it passes over the network. Oracle Database also provides protection against two forms of active attacks.\n\nData modification attack: An unauthorized party intercepting data in transit, altering it, and retransmitting it is a data modification attack. For example, intercepting a $100 bank deposit, changing the amount to $10,000, and retransmitting the higher amount is a data modification attack.\n\nReplay attack: Repetitively retransmitting an entire set of valid data is a replay attack, such as intercepting a $100 bank withdrawal and retransmitting it ten times, thereby receiving $1,000.\n\nAES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\nThe DES algorithm uses a 56-bit key length. ",
|
|
392
|
+
"severity": "medium"
|
|
393
|
+
},
|
|
394
|
+
{
|
|
395
|
+
"id": "V-52267",
|
|
396
|
+
"title": "The DBMS must use organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts.",
|
|
397
|
+
"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\nTechniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. \n \nReplay attacks, if successfully used against a database account, could result in access to database data. A successful replay attack against a non-privileged database account could result in a compromise of data stored on the database.\n\nOracle Database enables you to encrypt data that is sent over a network. There is no distinction between privileged and non-privileged accounts.\n\nEncryption of network data provides data privacy so that unauthorized parties are not able to view plain-text data as it passes over the network. Oracle Database also provides protection against two forms of active attacks.\n\nData modification attack: An unauthorized party intercepting data in transit, altering it, and retransmitting it is a data modification attack. For example, intercepting a $100 bank deposit, changing the amount to $10,000, and retransmitting the higher amount is a data modification attack.\n\nReplay attack: Repetitively retransmitting an entire set of valid data is a replay attack, such as intercepting a $100 bank withdrawal and retransmitting it ten times, thereby receiving $1,000.\n\nAES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode.\n\nThe DES algorithm uses a 56-bit key length. ",
|
|
398
|
+
"severity": "medium"
|
|
399
|
+
},
|
|
400
|
+
{
|
|
401
|
+
"id": "V-52269",
|
|
402
|
+
"title": "The DBMS must disable user accounts after 35 days of inactivity.",
|
|
403
|
+
"description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals. \n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. \n\nUnused or expired DBMS accounts provide a means for undetected, unauthorized access to the database.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
404
|
+
"severity": "medium"
|
|
405
|
+
},
|
|
406
|
+
{
|
|
407
|
+
"id": "V-52271",
|
|
408
|
+
"title": "The DBMS must support organizational requirements to enforce minimum password length.",
|
|
409
|
+
"description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals. \n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. \n\nWeak passwords are a primary target for attack to gain unauthorized access to databases and other systems. Where username/password is used for identification and authentication to the database, requiring the use of strong passwords can help prevent simple and more sophisticated methods for guessing at passwords.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.\n\n",
|
|
410
|
+
"severity": "medium"
|
|
411
|
+
},
|
|
412
|
+
{
|
|
413
|
+
"id": "V-52273",
|
|
414
|
+
"title": "The DBMS must support organizational requirements to prohibit password reuse for the organization-defined number of generations.",
|
|
415
|
+
"description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals. \n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. \n\nPassword reuse restrictions protect against bypass of password expiration requirements and help protect accounts from password guessing attempts.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
416
|
+
"severity": "medium"
|
|
417
|
+
},
|
|
418
|
+
{
|
|
419
|
+
"id": "V-52275",
|
|
420
|
+
"title": "The DBMS must support organizational requirements to enforce password complexity by the number of upper-case characters used.",
|
|
421
|
+
"description": "Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
422
|
+
"severity": "medium"
|
|
423
|
+
},
|
|
424
|
+
{
|
|
425
|
+
"id": "V-52277",
|
|
426
|
+
"title": "The DBMS must support organizational requirements to enforce password complexity by the number of lower-case characters used.",
|
|
427
|
+
"description": "Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
428
|
+
"severity": "medium"
|
|
429
|
+
},
|
|
430
|
+
{
|
|
431
|
+
"id": "V-52279",
|
|
432
|
+
"title": "The DBMS must support organizational requirements to enforce password complexity by the number of numeric characters used.",
|
|
433
|
+
"description": "Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
434
|
+
"severity": "medium"
|
|
435
|
+
},
|
|
436
|
+
{
|
|
437
|
+
"id": "V-52281",
|
|
438
|
+
"title": "The DBMS must support organizational requirements to enforce password complexity by the number of special characters used.",
|
|
439
|
+
"description": "Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
440
|
+
"severity": "medium"
|
|
441
|
+
},
|
|
442
|
+
{
|
|
443
|
+
"id": "V-52283",
|
|
444
|
+
"title": "The DBMS must support organizational requirements to enforce the number of characters that get changed when passwords are changed.",
|
|
445
|
+
"description": "Passwords need to be changed at specific policy-based intervals.\n\nIf the information system or application allows the user to consecutively reuse extensive portions of their password when they change their password, the end result is a password that has not had enough elements changed to meet the policy requirements.\n\nChanging passwords frequently can thwart password-guessing attempts or re-establish protection of a compromised DBMS account. Minor changes to passwords may not accomplish this since password guessing may be able to continue to build on previous guesses, or the new password may be easily guessed using the old password.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
446
|
+
"severity": "medium"
|
|
447
|
+
},
|
|
448
|
+
{
|
|
449
|
+
"id": "V-52285",
|
|
450
|
+
"title": "The DBMS must support organizational requirements to enforce password encryption for storage.",
|
|
451
|
+
"description": "Applications must enforce password encryption when storing passwords. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised.\n\nDatabase passwords stored in clear text are vulnerable to unauthorized disclosure. Database passwords must always be encoded or encrypted when stored internally or externally to the DBMS.",
|
|
452
|
+
"severity": "medium"
|
|
453
|
+
},
|
|
454
|
+
{
|
|
455
|
+
"id": "V-52287",
|
|
456
|
+
"title": "Procedures for establishing temporary passwords that meet DoD password requirements for new accounts must be defined, documented, and implemented.",
|
|
457
|
+
"description": "Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nNew accounts authenticated by passwords that are created without a password or with an easily guessed password are vulnerable to unauthorized access. Procedures for creating new accounts with passwords should include the required assignment of a temporary password to be modified by the user upon first use.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP With respect to Oracle, this requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
458
|
+
"severity": "medium"
|
|
459
|
+
},
|
|
460
|
+
{
|
|
461
|
+
"id": "V-52289",
|
|
462
|
+
"title": "DBMS passwords must not be stored in compiled, encoded, or encrypted batch jobs or compiled, encoded, or encrypted application source code.",
|
|
463
|
+
"description": "Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nThe storage of passwords in application source or batch job code that is compiled, encoded, or encrypted prevents compliance with password expiration and other management requirements, as well as provides another means for potential discovery.\n\nThis requirement applies equally to those accounts managed by Oracle and those managed and authenticated by the OS or an enterprise-wide mechanism.\n\nThis requirement should not be construed as prohibiting or discouraging the encryption of source code, which remains an advisable precaution.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.",
|
|
464
|
+
"severity": "medium"
|
|
465
|
+
},
|
|
466
|
+
{
|
|
467
|
+
"id": "V-52291",
|
|
468
|
+
"title": "The DBMS must enforce password maximum lifetime restrictions.",
|
|
469
|
+
"description": "Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nThe “PASSWORD_LIFE_TIME” parameter defines the number of days a password remains valid. This can, but must not be, set to “UNLIMITED”. Further, the “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another small integer).\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. With respect to Oracle, this requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
470
|
+
"severity": "medium"
|
|
471
|
+
},
|
|
472
|
+
{
|
|
473
|
+
"id": "V-52293",
|
|
474
|
+
"title": "The DBMS, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor.",
|
|
475
|
+
"description": "A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. \n\nWhen there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be for example a Certification Authority (CA). A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. \n\nPath validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. \n\nStatus information for certification paths includes certificate revocation lists or online certificate status protocol responses. \n\nDatabase Management Systems that do not validate certificates to a trust anchor are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database.\n",
|
|
476
|
+
"severity": "medium"
|
|
477
|
+
},
|
|
478
|
+
{
|
|
479
|
+
"id": "V-52295",
|
|
480
|
+
"title": "The DBMS must ensure that PKI-based authentication maps the authenticated identity to the user account.",
|
|
481
|
+
"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.\n\nWhen including the DBMS in the Private Key Infrastructure, the authenticated user must map directly to a user account in the DBMS. If the user account is not directly tied to the authenticated identity, there is no way to know which, if any, database user account has been authorized.",
|
|
482
|
+
"severity": "medium"
|
|
483
|
+
},
|
|
484
|
+
{
|
|
485
|
+
"id": "V-52297",
|
|
486
|
+
"title": "The DBMS must use NIST-validated FIPS 140-2-compliant cryptography for authentication mechanisms.",
|
|
487
|
+
"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\nApplications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. \n\nFIPS 140-2 is the current standard for validating cryptographic modules, and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based encryption modules.\n\nAuthentication modules with weak encryption could allow an attacker to gain access to data stored in the database and to the administration settings of the DBMS.",
|
|
488
|
+
"severity": "medium"
|
|
489
|
+
},
|
|
490
|
+
{
|
|
491
|
+
"id": "V-52299",
|
|
492
|
+
"title": "The DBMS must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.",
|
|
493
|
+
"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\nThe act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. \n\nWhen applications provide a remote management capability inherent to the application, the application needs to ensure the communication channels used to remotely access the system are adequately protected. If the communication channel is not adequately protected authentication information, application data, and configuration information could be compromised.",
|
|
494
|
+
"severity": "medium"
|
|
495
|
+
},
|
|
496
|
+
{
|
|
497
|
+
"id": "V-52301",
|
|
498
|
+
"title": "The DBMS must employ strong identification and authentication techniques when establishing non-local maintenance and diagnostic sessions.",
|
|
499
|
+
"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\nThe act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. \n\nWhen applications provide a remote management capability inherent to the application, the application needs to ensure the identification and authentication techniques used to remotely access the system are strong enough to protect the system. If the communication channel is not adequately protected, authentication information, application data, and configuration information could be compromised.",
|
|
500
|
+
"severity": "medium"
|
|
501
|
+
},
|
|
502
|
+
{
|
|
503
|
+
"id": "V-52303",
|
|
504
|
+
"title": "Databases employed to write data to portable digital media must use cryptographic mechanisms to protect and restrict access to information on portable digital media.",
|
|
505
|
+
"description": "When data is written to portable digital media, such as thumb drives, floppy diskettes, compact disks, magnetic tape, etc., there is risk of data loss. \n\nAn organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. \n\nOrganizations need to document in policy and procedures the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. \n\nIn these situations, it is assumed the physical access controls where the media resides provide adequate protection. The decision whether to employ cryptography is the responsibility of the information owner/steward, who exercises discretion within the framework of applicable rules, policies, and law.\n\nThe selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. \n\nThe strength of mechanisms is commensurate with the classification and sensitivity of the information. \n\nWhen the organization has determined the risk warrants it, data written to portable digital media must be encrypted. When information written to digital media is not encrypted, it can be compromised.",
|
|
506
|
+
"severity": "medium"
|
|
507
|
+
},
|
|
508
|
+
{
|
|
509
|
+
"id": "V-52305",
|
|
510
|
+
"title": "The DBMS must support organizational requirements to encrypt information stored in the database, and information extracted or derived from the database and stored on digital media.",
|
|
511
|
+
"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/or compromise. \n\nAn organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. \n\nFewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. \n\nAs part of a defense-in-depth strategy, the organization considers routinely encrypting information at rest on selected secondary storage devices. The decision whether to employ cryptography is the responsibility of the information owner/steward, who exercises discretion within the framework of applicable rules, policies, and law. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information.\n\nThe strength of mechanisms is commensurate with the classification and sensitivity of the information.\n\nInformation at rest, when not encrypted, is open to compromise from attackers who have gained unauthorized access to the data files.",
|
|
512
|
+
"severity": "medium"
|
|
513
|
+
},
|
|
514
|
+
{
|
|
515
|
+
"id": "V-52307",
|
|
516
|
+
"title": "The DBMS must terminate the network connection associated with a communications session at the end of the session or after 15 minutes of inactivity.",
|
|
517
|
+
"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\nThe act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data.\n\nWhen applications provide a remote management capability inherent to the application, the application needs to ensure all sessions and network connections are terminated when non-local maintenance is completed.\n\nWhen network connections are left open after the database session has closed, the network session is open to session hijacking.\n\nThe Oracle Listener inherently meets most of this SRG requirement. When a user logs off, or times out, or encounters an unrecoverable network fault, the Oracle Listener terminates all sessions and network connections. The remaining aspect of the requirement, the timeout because of inactivity, is configurable.",
|
|
518
|
+
"severity": "medium"
|
|
519
|
+
},
|
|
520
|
+
{
|
|
521
|
+
"id": "V-52309",
|
|
522
|
+
"title": "The DBMS must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.",
|
|
523
|
+
"description": "Use of cryptography to provide confidentiality and non-repudiation is not effective unless strong methods are employed. Many earlier encryption methods and modules have been broken and/or overtaken by increasing computing power. The NIST FIPS 140-2 cryptographic standards provide proven methods and strengths to employ cryptography effectively.\n\nDetailed information on the NIST Cryptographic Module Validation Program (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html.\n\nNote: this does not require that all databases be encrypted. It specifies that if encryption is required, then the implementation of the encryption must satisfy the prevailing standards.",
|
|
524
|
+
"severity": "medium"
|
|
525
|
+
},
|
|
526
|
+
{
|
|
527
|
+
"id": "V-52311",
|
|
528
|
+
"title": "Database data files containing sensitive information must be encrypted.",
|
|
529
|
+
"description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. \n\nUse of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. \n\nData files that are not encrypted are vulnerable to theft. When data files are not encrypted they can be copied and opened on a separate system. The data can be compromised without the information owner's knowledge that the theft has even taken place.",
|
|
530
|
+
"severity": "medium"
|
|
531
|
+
},
|
|
532
|
+
{
|
|
533
|
+
"id": "V-52327",
|
|
534
|
+
"title": "Vendor-supported software must be evaluated and patched against newly found vulnerabilities.",
|
|
535
|
+
"description": "Security faults with software applications and operating systems are discovered daily. 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, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously. \n\nAnytime new software code is introduced to a system there is the potential for unintended consequences. There have been documented instances where the application of a patch has caused problems with system integrity or availability. Due to information system integrity and availability concerns, organizations must give careful consideration to the methodology used to carry out automatic updates. \n\nUnsupported software versions are not patched by vendors to address newly discovered security versions. An unpatched version is vulnerable to attack.",
|
|
536
|
+
"severity": "high"
|
|
537
|
+
},
|
|
538
|
+
{
|
|
539
|
+
"id": "V-52329",
|
|
540
|
+
"title": "DBMS default accounts must be assigned custom passwords.",
|
|
541
|
+
"description": "Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nDBMS default passwords provide a commonly known and exploited means for unauthorized access to database installations.",
|
|
542
|
+
"severity": "high"
|
|
543
|
+
},
|
|
544
|
+
{
|
|
545
|
+
"id": "V-52331",
|
|
546
|
+
"title": "The DBMS, when using PKI-based authentication, must enforce authorized access to the corresponding private key.",
|
|
547
|
+
"description": "The cornerstone of the PKI is the private key used to encrypt or digitally sign information.\n\nIf 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\nBoth the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.\n\nAll access to the private key of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to the DBMS's private key, an attacker could gain access to the primary key and use it to impersonate the database on the network.\n\nTransport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.",
|
|
548
|
+
"severity": "high"
|
|
549
|
+
},
|
|
550
|
+
{
|
|
551
|
+
"id": "V-52333",
|
|
552
|
+
"title": "The DBMS must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission unless the transmitted data is otherwise protected by alternative physical measures.",
|
|
553
|
+
"description": "Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel.\n\nAlternative physical protection measures include Protected Distribution Systems (PDS). PDS are used to transmit unencrypted classified NSI through an area of lesser classification or control. Inasmuch as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS.\n\nInformation in transmission is particularly vulnerable to attack. If the DBMS does not employ cryptographic mechanisms preventing unauthorized disclosure of information during transit, the information may be compromised.",
|
|
554
|
+
"severity": "high"
|
|
555
|
+
},
|
|
556
|
+
{
|
|
557
|
+
"id": "V-52337",
|
|
558
|
+
"title": "The DBMS must limit the number of concurrent sessions for each system account to an organization-defined number of sessions.",
|
|
559
|
+
"description": "Application management includes the ability to control the number of users and user sessions utilizing an application. Limiting the number of allowed users, and sessions per user, is helpful in limiting risks related to Denial of Service attacks.\n\nThis requirement addresses concurrent session control for a single information system account and does not address concurrent sessions by a single user via multiple system accounts. \n\nUnlimited concurrent connections to the DBMS could allow a successful Denial of Service (DoS) attack by exhausting connection resources.\n\nThe organization will need to define the maximum number of concurrent sessions by account type, by account, or a combination thereof. In deciding on the appropriate number, it is important to take into account the work requirements of the various types of user. For example, 2 might be an acceptable limit for general users accessing the database via an application; but 10 might be too few for a database administrator using a database management GUI tool, where each query tab and navigation pane may count as a separate session.",
|
|
560
|
+
"severity": "medium"
|
|
561
|
+
},
|
|
562
|
+
{
|
|
563
|
+
"id": "V-52345",
|
|
564
|
+
"title": "The DBMS must ensure remote sessions that access an organization-defined list of security functions and security-relevant information are audited.",
|
|
565
|
+
"description": "Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.\n\nRemote network and system access is accomplished by leveraging common communication protocols to establish a remote connection. These connections will typically originate over either the public Internet or the Public Switched Telephone Network (PSTN). Neither of these internetworking mechanisms is private or secure and they do not by default restrict access to networked resources once connectivity is established.\n \nNumerous best practices are employed to protect remote connections, such as utilizing encryption to protect data sessions and firewalls to restrict and control network connectivity. In addition to these protections, auditing must also be utilized in order to track system activity, assist in diagnosing system issues, and provide evidence needed for forensic investigations after a security incident.\n \nWhen organizations define security-related application functions or security-related application information, it is incumbent upon the application providing access to that data to ensure auditing of remote connectivity to those resources occurs in support of organizational requirements.\n \nRemote access to security functions (e.g., user management, audit log management, etc.) and security-relevant information requires the activity be audited by the organization. Any application providing remote access must support organizational requirements to audit access or organization-defined security functions and security-relevant information.\n\nDatabase security features accessed through remote methods must be audited to ensure the access is authorized and appropriate.",
|
|
566
|
+
"severity": "medium"
|
|
567
|
+
},
|
|
568
|
+
{
|
|
569
|
+
"id": "V-52347",
|
|
570
|
+
"title": "The DBMS must support the disabling of network protocols deemed by the organization to be non-secure.",
|
|
571
|
+
"description": "This requirement is related to remote access, but more specifically to the networking protocols allowing systems to communicate. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. \n\nSome networking protocols allowing remote access may not meet security requirements to protect data and components. Bluetooth and peer-to-peer networking are examples of less than secure networking protocols. \n\nThe DoD Ports, Protocols, and Services Management (PPSM) program provides implementation guidance on the use of IP protocols and application and data services traversing the DoD Networks in a manner supporting net-centric operations. \n\nApplications implementing or utilizing remote access network protocols need to ensure the application is developed and implemented in accordance with the PPSM requirements. In situations where it has been determined that specific operational requirements outweigh the risks of enabling an insecure network protocol, the organization may pursue a risk acceptance.\n\nUsing protocols deemed non-secure would compromise the ability of the DBMS to operate in a secure fashion. The database must be able to disable network protocols deemed non-secure.",
|
|
572
|
+
"severity": "medium"
|
|
573
|
+
},
|
|
574
|
+
{
|
|
575
|
+
"id": "V-52349",
|
|
576
|
+
"title": "The system must employ automated mechanisms for supporting Oracle user account management.",
|
|
577
|
+
"description": "A comprehensive application account management process that includes automation helps to ensure 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\nEnterprise environments make application user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight.\n\nAutomated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization's automated account management requirements.\n\nDatabases can have large numbers of users in disparate locations and job functions. Automatic account management can help mitigate the risk of human error found in manually managing database access.\n\nNote that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
578
|
+
"severity": "medium"
|
|
579
|
+
},
|
|
580
|
+
{
|
|
581
|
+
"id": "V-52351",
|
|
582
|
+
"title": "The DBMS must provide a mechanism to automatically identify accounts designated as temporary or emergency accounts.",
|
|
583
|
+
"description": "Temporary application accounts could be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support-related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. \n\nTo address this, in the event temporary application accounts are required, the application must ensure accounts designated as temporary in nature shall automatically terminate these accounts 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\nNote: User authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.\n\nTemporary database accounts must be identified in order for the system to recognize and terminate them after a given time period. The DBMS and any administrators must have a means to recognize any temporary accounts for special handling.",
|
|
584
|
+
"severity": "medium"
|
|
585
|
+
},
|
|
586
|
+
{
|
|
587
|
+
"id": "V-52353",
|
|
588
|
+
"title": "The DBMS must provide a mechanism to automatically terminate accounts designated as temporary or emergency accounts after an organization-defined time period.",
|
|
589
|
+
"description": "Temporary application accounts could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. \n\nTo address this, in the event temporary application accounts are required, the application must ensure accounts designated as temporary in nature shall automatically terminate these accounts 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\nUser authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.\n\nTemporary database accounts must be automatically terminated after an organization-defined time period in order to mitigate the risk of the account being used beyond its original purpose or timeframe.",
|
|
590
|
+
"severity": "medium"
|
|
591
|
+
},
|
|
592
|
+
{
|
|
593
|
+
"id": "V-52357",
|
|
594
|
+
"title": "The DBMS must support the requirement to automatically audit account creation.",
|
|
595
|
+
"description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account.\n\nAuditing of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application owners that they exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.\n\nNote that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP.\n\nHowever, notwithstanding how accounts are managed, Oracle auditing must always be configured to capture account creation.",
|
|
596
|
+
"severity": "medium"
|
|
597
|
+
},
|
|
598
|
+
{
|
|
599
|
+
"id": "V-52359",
|
|
600
|
+
"title": "The DBMS must support the requirement to automatically audit account modification.",
|
|
601
|
+
"description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply modify an existing account. \n\nAuditing of account modification is one method and best practice for mitigating this risk. A comprehensive application account management process ensures an audit trail automatically documents the modification of application user accounts and, as required, notifies administrators, application owners, and/or appropriate individuals. Applications must provide this capability directly, leveraging complementary technology providing this capability or a combination thereof.\n\nAutomated account auditing processes greatly reduces the risk that accounts will be surreptitiously modified and provides logging that can be used for forensic purposes. \n\nNote that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP.\n\nHowever, notwithstanding how accounts are managed, Oracle auditing must always be configured to capture account modification.",
|
|
602
|
+
"severity": "medium"
|
|
603
|
+
},
|
|
604
|
+
{
|
|
605
|
+
"id": "V-52361",
|
|
606
|
+
"title": "The DBMS must automatically audit account disabling actions, to the extent such information is available.",
|
|
607
|
+
"description": "When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves.\n\nIn order to detect and respond to events affecting user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals so they can investigate the event.\n\nSuch a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.\n\nNote that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP.\n\nHowever, notwithstanding how accounts are managed, Oracle auditing must always be configured to capture account-disabling actions, to the extent such information is available.\n\nNote that some Oracle architectural details limit the ability to capture this information. There is a difference between actions taken by a user that generate an audit record and actions by the database itself, which do not generate an audit record. If an account is locked because of an expiration event, it is done by the database without involving the action of a user. Failed logins are logged user interactions, but the subsequent locking of the account, although initiated by user actions, is a function of the database.",
|
|
608
|
+
"severity": "medium"
|
|
609
|
+
},
|
|
610
|
+
{
|
|
611
|
+
"id": "V-52363",
|
|
612
|
+
"title": "The DBMS must automatically audit account termination.",
|
|
613
|
+
"description": "When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. \n\nIn order to detect and respond to events affecting user accessibility and application processing, applications must audit account terminating actions and notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. \n\nNote that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP.\n\nHowever, notwithstanding how accounts are managed, Oracle auditing must always be configured to capture account termination.",
|
|
614
|
+
"severity": "medium"
|
|
615
|
+
},
|
|
616
|
+
{
|
|
617
|
+
"id": "V-52365",
|
|
618
|
+
"title": "The DBMS must enforce approved authorizations for logical access to the system in accordance with applicable policy.",
|
|
619
|
+
"description": "Strong access controls are critical to securing application 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 applications, 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 information system. \n\nConsideration should be given to the implementation of an audited, explicit override of automated mechanisms in the event of emergencies or other serious events.\n\nIf the DBMS does not follow applicable policy when approving access it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and may be in conflict with applicable policy.",
|
|
620
|
+
"severity": "medium"
|
|
621
|
+
},
|
|
622
|
+
{
|
|
623
|
+
"id": "V-52367",
|
|
624
|
+
"title": "The DBMS must enforce Discretionary Access Control (DAC) policy allowing users to specify and control sharing by named individuals, groups of individuals, or by both, limiting propagation of access rights and includes or excludes access to the granularity of a single user.",
|
|
625
|
+
"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). \n\nDAC is a type of access control methodology serving as a means of restricting access to objects and data based on the identity of subjects and/or groups to which they belong. It is discretionary in the sense that application users with the appropriate permissions to access an application resource or data have the discretion to pass that permission on to another user either directly or indirectly.\n\nData protection requirements may result in a DAC policy being specified as part of the application design. Discretionary access controls would be employed at the application level to restrict and control access to application objects and data thereby providing increased information security for the organization. \n\nWhen DAC controls are employed, those controls must limit sharing to named application users, groups of users, or both. The application DAC controls must also limit the propagation of access rights and have the ability to exclude access to data down to the granularity of a single user.\n\nDatabases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information. If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.",
|
|
626
|
+
"severity": "medium"
|
|
627
|
+
},
|
|
628
|
+
{
|
|
629
|
+
"id": "V-52369",
|
|
630
|
+
"title": "DBMS processes or services must run under custom, dedicated OS accounts.",
|
|
631
|
+
"description": "Separation of duties is a prevalent Information Technology control that is 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 that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action. \n\nThe DBMS must run under a custom dedicated OS account. When the DBMS is running under a shared account, users with access to that account could inadvertently or maliciously make changes to the DBMS's settings, files, or permissions.",
|
|
632
|
+
"severity": "medium"
|
|
633
|
+
},
|
|
634
|
+
{
|
|
635
|
+
"id": "V-52371",
|
|
636
|
+
"title": "The DBMS must restrict grants to sensitive information to authorized user roles.",
|
|
637
|
+
"description": "Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nUnauthorized access to sensitive data may compromise the confidentiality of personnel privacy, threaten national security, or compromise a variety of other sensitive operations. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user.",
|
|
638
|
+
"severity": "medium"
|
|
639
|
+
},
|
|
640
|
+
{
|
|
641
|
+
"id": "V-52373",
|
|
642
|
+
"title": "A single database connection configuration file must not be used to configure all database clients.",
|
|
643
|
+
"description": "Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nMany sites distribute a single client database connection configuration file to all site database users that contains network access information for all databases on the site. Such a file provides information to access databases not required by all users that may assist in unauthorized access attempts.",
|
|
644
|
+
"severity": "medium"
|
|
645
|
+
},
|
|
646
|
+
{
|
|
647
|
+
"id": "V-52375",
|
|
648
|
+
"title": "The DBMS must be protected from unauthorized access by developers.",
|
|
649
|
+
"description": "Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nDevelopers granted elevated database and/or operating system privileges on production databases can affect the operation and/or security of the database system. Operating system and database privileges assigned to developers on production systems must not be allowed.",
|
|
650
|
+
"severity": "medium"
|
|
651
|
+
},
|
|
652
|
+
{
|
|
653
|
+
"id": "V-52377",
|
|
654
|
+
"title": "The DBMS must be protected from unauthorized access by developers on shared production/development host systems.",
|
|
655
|
+
"description": "Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nDevelopers granted elevated database and/or operating system privileges on systems that support both development and production databases can affect the operation and/or security of the production database system. Operating system and database privileges assigned to developers on shared development and production systems must be restricted.",
|
|
656
|
+
"severity": "medium"
|
|
657
|
+
},
|
|
658
|
+
{
|
|
659
|
+
"id": "V-52379",
|
|
660
|
+
"title": "The DBMS must restrict access to system tables and other configuration information or metadata to DBAs or other authorized users.",
|
|
661
|
+
"description": "Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nAdministrative data includes DBMS metadata and other configuration and management data. Unauthorized access to this data could result in unauthorized changes to database objects, access controls, or DBMS configuration.",
|
|
662
|
+
"severity": "medium"
|
|
663
|
+
},
|
|
664
|
+
{
|
|
665
|
+
"id": "V-52383",
|
|
666
|
+
"title": "Administrative privileges must be assigned to database accounts via database roles.",
|
|
667
|
+
"description": "Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nPrivileges granted outside the context of the application user job function are more likely to go unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment.",
|
|
668
|
+
"severity": "medium"
|
|
669
|
+
},
|
|
670
|
+
{
|
|
671
|
+
"id": "V-52387",
|
|
672
|
+
"title": "Administrators must utilize a separate, distinct administrative account when performing administrative activities, accessing database security functions, or accessing security-relevant information.",
|
|
673
|
+
"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\nTo limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nWhen privileged activities are not separated from non-privileged activities, the database can be subject to unauthorized changes to settings and data that a standard user would not normally have access to, outside of an authorized maintenance session.",
|
|
674
|
+
"severity": "medium"
|
|
675
|
+
},
|
|
676
|
+
{
|
|
677
|
+
"id": "V-52389",
|
|
678
|
+
"title": "All use of privileged accounts must be audited.",
|
|
679
|
+
"description": "This is intended to limit exposure, by making it possible to trace any unauthorized access, by a privileged user account or role that has permissions on security functions or security-relevant information, to other data or functionality.",
|
|
680
|
+
"severity": "medium"
|
|
681
|
+
},
|
|
682
|
+
{
|
|
683
|
+
"id": "V-52393",
|
|
684
|
+
"title": "The DBA role must not be assigned excessive or unauthorized privileges.",
|
|
685
|
+
"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\nAudit of privileged activity may require physical separation employing information systems on which the user does not have privileged access.\n\nTo limit exposure and provide forensic history of activity when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nIf feasible, applications must provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged.\n\nDBAs, if assigned excessive privileges, could perform actions that endanger the information system or hide evidence of malicious activity.",
|
|
686
|
+
"severity": "medium"
|
|
687
|
+
},
|
|
688
|
+
{
|
|
689
|
+
"id": "V-52395",
|
|
690
|
+
"title": "Applications must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.",
|
|
691
|
+
"description": "To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism. \n\nObfuscation of user-provided information when typed into the system is a method used in addressing this risk. \n\nFor example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.\n\nDatabase applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing.\n\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.",
|
|
692
|
+
"severity": "high"
|
|
693
|
+
},
|
|
694
|
+
{
|
|
695
|
+
"id": "V-52397",
|
|
696
|
+
"title": "When using command-line tools such as Oracle SQL*Plus, which can accept a plain-text password, users must use an alternative login method that does not expose the password.",
|
|
697
|
+
"description": "The SRG states: \"To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism.\"\n\n\"Obfuscation of user-provided information when typed into the system is a method used in addressing this risk.\"\n\n\"For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.\"\n\n\"Database applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing.\"\n\nSQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot be configured not to accept a plain-text password. Since the typical SQL*Plus user is a database administrator, the consequences of password compromise are particularly serious. Therefore, the use of plain-text passwords must be prohibited, as a matter of practice and procedure.",
|
|
698
|
+
"severity": "high"
|
|
699
|
+
},
|
|
700
|
+
{
|
|
701
|
+
"id": "V-52399",
|
|
702
|
+
"title": "OS accounts utilized to run external procedures called by the DBMS must have limited privileges.",
|
|
703
|
+
"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\nTo limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nUse of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.\n\nExternal applications called or spawned by the DBMS process may be executed under OS accounts with unnecessary privileges. This can lead to unauthorized access to OS resources and compromise of the OS, the DBMS or any other services provided by the host platform.",
|
|
704
|
+
"severity": "medium"
|
|
705
|
+
},
|
|
706
|
+
{
|
|
707
|
+
"id": "V-52405",
|
|
708
|
+
"title": "DBMS default accounts must be protected from misuse.",
|
|
709
|
+
"description": "The Security Requirements Guide says, \"Default accounts are usually accounts that have special privileges required to administer the database. Well-known DBMS account names are targeted most frequently by attackers and are thus more prone to providing unauthorized access to the database.\n\n\"If default account names are not changed, an attacker has a predefined list of accounts to target. Since most default accounts are administrative in nature, the compromise of a default account can have catastrophic consequences, including the complete loss of control over the information system.\"\n\nHowever, Oracle does not provide for changing user names directly. Workarounds to achieve the effect of a name change are cumbersome. In addition, names of essential system accounts such as SYS are \"baked into\" the product, with thousands of dependencies involved. Making such a change would risk making the DBMS inoperative, and would interfere with getting support from Oracle.\n\nThe Check and Fix, therefore, relate to good practices for protecting the essential system accounts from misuse.",
|
|
710
|
+
"severity": "medium"
|
|
711
|
+
},
|
|
712
|
+
{
|
|
713
|
+
"id": "V-52407",
|
|
714
|
+
"title": "The DBMS must specify an account lockout duration that is greater than or equal to the organization-approved minimum.",
|
|
715
|
+
"description": "Anytime an authentication method is exposed, to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access.\n\nTo defeat these attempts, organizations define the number of times a user account may consecutively fail a logon attempt. The organization also defines the period of time in which these consecutive failed attempts may occur.\n\nBy limiting the number of failed logon 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\nUser authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
716
|
+
"severity": "medium"
|
|
717
|
+
},
|
|
718
|
+
{
|
|
719
|
+
"id": "V-52409",
|
|
720
|
+
"title": "Disk space used by audit trail(s) must be monitored; audit records must be regularly or continuously offloaded to a centralized log management system.",
|
|
721
|
+
"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. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Applications are required to be capable of either directly performing or calling system-level functionality performing defined actions upon detection of an application audit log processing failure.\n\nThe Security Requirements Guide says, \"A failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. The database must be capable of taking organization-defined actions to avoid either a complete halt to processing or processing transactions in an unaudited manner.\"\n\nThis STIG requirement mandates the implementation of a method to mitigate Oracle's inability to automatically reuse audit trail space on a first-in, first-out basis.",
|
|
722
|
+
"severity": "medium"
|
|
723
|
+
},
|
|
724
|
+
{
|
|
725
|
+
"id": "V-52425",
|
|
726
|
+
"title": "Use of the DBMS software installation account must be restricted.",
|
|
727
|
+
"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\nTo limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nUse of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.\n\nThe DBMS software installation account may require privileges not required for database administration or other functions. Use of accounts configured with excess privileges may result in the loss or compromise of data or system settings due to elevated privileges that bypass controls designed to protect them.",
|
|
728
|
+
"severity": "medium"
|
|
729
|
+
},
|
|
730
|
+
{
|
|
731
|
+
"id": "V-52427",
|
|
732
|
+
"title": "Database software, applications, and configuration files must be monitored to discover unauthorized changes.",
|
|
733
|
+
"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.\n\nIf the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.",
|
|
734
|
+
"severity": "medium"
|
|
735
|
+
},
|
|
736
|
+
{
|
|
737
|
+
"id": "V-52429",
|
|
738
|
+
"title": "The OS must limit privileges to change the DBMS software resident within software libraries (including privileged programs).",
|
|
739
|
+
"description": "When dealing with change control issues, it should be noted, 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\nIf the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nThis requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable as in the case of interpreted languages.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nThe DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in malicious alteration. This may in turn jeopardize data stored in the DBMS and/or operation of the host system.",
|
|
740
|
+
"severity": "medium"
|
|
741
|
+
},
|
|
742
|
+
{
|
|
743
|
+
"id": "V-52431",
|
|
744
|
+
"title": "The DBMS must have the capability to limit the number of failed login attempts based upon an organization-defined number of consecutive invalid attempts occurring within an organization-defined time period.",
|
|
745
|
+
"description": "Anytime an authentication method is exposed, to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. \n\nTo defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. \n\nBy 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\nMore recent brute force attacks make attempts over long periods of time to circumvent intrusion detection systems and system account lockouts based entirely on the number of failed logins that are typically reset after a successful login.\n\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.\n\nNote also that a policy that places no limit on the length of the timeframe (for counting consecutive invalid attempts) does satisfy this requirement.",
|
|
746
|
+
"severity": "medium"
|
|
747
|
+
},
|
|
748
|
+
{
|
|
749
|
+
"id": "V-52433",
|
|
750
|
+
"title": "The DBMS must provide the ability to write specified audit record content to a centralized audit log repository.",
|
|
751
|
+
"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 but is not limited: timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, access control or flow control rules invoked. \n\nCentralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as, the backup and archiving of those records. When organizations define application components requiring centralized audit log management, applications need to support that requirement.\n\nDatabase audit records not stored in a centralized audit log management tool may be overlooked during investigation of a security incident or may be subject to intentional or accidental manipulation by privileged users of the database.",
|
|
752
|
+
"severity": "medium"
|
|
753
|
+
},
|
|
754
|
+
{
|
|
755
|
+
"id": "V-52435",
|
|
756
|
+
"title": "The DBMS, when the maximum number of unsuccessful attempts is exceeded, must automatically lock the account/node for an organization-defined time period or lock the account/node until released by an administrator IAW organizational policy.",
|
|
757
|
+
"description": "Anytime an authentication method is exposed, to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. \n\nTo defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. \n\nBy 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\nNote that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.",
|
|
758
|
+
"severity": "medium"
|
|
759
|
+
},
|
|
760
|
+
{
|
|
761
|
+
"id": "V-52437",
|
|
762
|
+
"title": "The DBMS software installation account must be restricted to authorized users.",
|
|
763
|
+
"description": "When dealing with change control issues, it should be noted, 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\nIf the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nThis requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable, as in the case of interpreted languages.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nDBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a greater impact on database security and operation. It is especially important to grant access to privileged accounts to only those persons who are qualified and authorized to use them.\n",
|
|
764
|
+
"severity": "medium"
|
|
765
|
+
},
|
|
766
|
+
{
|
|
767
|
+
"id": "V-52441",
|
|
768
|
+
"title": "Database software directories, including DBMS configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.",
|
|
769
|
+
"description": "When dealing with change control issues, it should be noted, 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\nMultiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to host system directories can most likely lead to a compromise of all applications hosted by the same system. Database software not installed using dedicated directories both threatens and is threatened by other hosted applications. Access controls defined for one application may by default provide access to the other application's database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.",
|
|
770
|
+
"severity": "medium"
|
|
771
|
+
},
|
|
772
|
+
{
|
|
773
|
+
"id": "V-52445",
|
|
774
|
+
"title": "The DBMS software libraries must be periodically backed up.",
|
|
775
|
+
"description": "Information system backup is a critical step in maintaining data assurance and availability.\n\nSystem-level information includes: system-state information, operating system and application software, and licenses.\n\nBackups shall be consistent with organizational recovery time and recovery point objectives.\n\nThe DBMS application depends upon the availability and integrity of its software libraries. Without backups, compromise or loss of the software libraries can prevent a successful recovery of DBMS operations.",
|
|
776
|
+
"severity": "medium"
|
|
777
|
+
},
|
|
778
|
+
{
|
|
779
|
+
"id": "V-52447",
|
|
780
|
+
"title": "The DBMS must have its auditing configured to reduce the likelihood of storage capacity being exceeded.",
|
|
781
|
+
"description": "Applications need to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, applications should detect and determine if adequate storage capacity has been allocated for audit logs.\n\nDuring the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient to meet storage requirements.\n\nLogging must be configured appropriately. If the logs generated outstrip the amount of space reserved for those logs, the system may shut down or take other measures to stop processing in order to protect transactions from continuing unlogged.",
|
|
782
|
+
"severity": "medium"
|
|
783
|
+
},
|
|
784
|
+
{
|
|
785
|
+
"id": "V-52449",
|
|
786
|
+
"title": "The DBMS must have allocated audit record storage capacity.",
|
|
787
|
+
"description": "Applications need to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, applications should detect and determine if adequate storage capacity has been allocated for audit logs. \n\nDuring the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient to meet storage requirements.\n\nWhen insufficient space in directories is allocated for audit records, database audit logs can fill up and begin to overwrite earlier logs, database activity can stop altogether, or auditing could fail and crucial tracking data could be lost.",
|
|
788
|
+
"severity": "medium"
|
|
789
|
+
},
|
|
790
|
+
{
|
|
791
|
+
"id": "V-52451",
|
|
792
|
+
"title": "The DBMS must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).",
|
|
793
|
+
"description": "To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. \n\nOrganizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). \n\nUsers (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization which outlines specific user actions that can be performed on the information system without identification or authentication.",
|
|
794
|
+
"severity": "medium"
|
|
795
|
+
},
|
|
796
|
+
{
|
|
797
|
+
"id": "V-52453",
|
|
798
|
+
"title": "Databases utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights.",
|
|
799
|
+
"description": "Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment.\n\nDAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. DAC models have the potential for the access controls to propagate without limit, resulting in unauthorized access to said objects.\n\nWhen applications provide a discretionary access control mechanism, the application must be able to limit the propagation of those access rights.\n\nThe DBMS must ensure the recipient of permissions possesses only the access intended. The database must enforce the ability to limit rights propagation if that is the intent of the grantor. If the propagation of access rights is not limited, users with rights to objects they do not own can continue to grant rights to those objects to other users without limit.\n\nThis is default for behavior for Oracle.",
|
|
800
|
+
"severity": "medium"
|
|
801
|
+
},
|
|
802
|
+
{
|
|
803
|
+
"id": "V-52455",
|
|
804
|
+
"title": "The DBMS must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).",
|
|
805
|
+
"description": "Non-organizational users include all information system users other than organizational users which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations).\n\nNon-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server.\n\nAccordingly, a risk assessment is used in determining the authentication needs of the organization.\n\nScalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation.",
|
|
806
|
+
"severity": "medium"
|
|
807
|
+
},
|
|
808
|
+
{
|
|
809
|
+
"id": "V-52457",
|
|
810
|
+
"title": "A DBMS utilizing Discretionary Access Control (DAC) must enforce a policy that includes or excludes access to the granularity of a single user.",
|
|
811
|
+
"description": "DAC is based on the notion that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment.\n\nDAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions.\n\nIncluding or excluding access to the granularity of a single user means providing the capability to either allow or deny access to objects (e.g., files, folders) on a per single user basis.\n\nDatabases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information. If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.",
|
|
812
|
+
"severity": "medium"
|
|
813
|
+
},
|
|
814
|
+
{
|
|
815
|
+
"id": "V-52459",
|
|
816
|
+
"title": "The DBMS must separate user functionality (including user interface services) from database management functionality.",
|
|
817
|
+
"description": "Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. \n\nThe separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. \n\nAn example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. \n\nThis may include isolating the administrative interface on a different domain and with additional access controls.\n\nIf administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.",
|
|
818
|
+
"severity": "medium"
|
|
819
|
+
},
|
|
820
|
+
{
|
|
821
|
+
"id": "V-52461",
|
|
822
|
+
"title": "The DBMS must prevent the presentation of information system management-related functionality at an interface utilized by general (i.e., non-privileged) users.",
|
|
823
|
+
"description": "Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access.\n\nThe separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate.\n\nAn example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls.\n\nIf administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.",
|
|
824
|
+
"severity": "medium"
|
|
825
|
+
},
|
|
826
|
+
{
|
|
827
|
+
"id": "V-52463",
|
|
828
|
+
"title": "The DBMS must provide audit record generation capability for organization-defined auditable events within the database.",
|
|
829
|
+
"description": "Audit records can be generated from various components within the information system. (e.g., network interface, hard disk, modem, etc.). From an application perspective, certain specific application functionalities may be audited as well.\n\nThe 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, 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\nOrganizations define which application components shall provide auditable events. \n\nThe DBMS must provide auditing for the list of events defined by the organization or risk negatively impacting forensic investigations into malicious behavior in the information system. Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well.\n\nThe 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, 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\nOrganizations may define the organizational personnel accountable for determining which application components shall provide auditable events.\n\nAuditing provides accountability for changes made to the DBMS configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability.\n\nThe Department of Defense has established the following as the minimum set of auditable events. Most can be audited via Oracle settings; some may require OS settings.\n\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels). \n\n- Successful and unsuccessful logon attempts, privileged activities or other system level access\n\n- Starting and ending time for user access to the system, concurrent logons from different workstations.\n\n- Successful and unsuccessful accesses to objects.\n\n- All program initiations.\n\n- All direct access to the information system.\n\n- All account creations, modifications, disabling, and terminations. \n\n- All kernel module loads, unloads, and restarts. ",
|
|
830
|
+
"severity": "medium"
|
|
831
|
+
},
|
|
832
|
+
{
|
|
833
|
+
"id": "V-52465",
|
|
834
|
+
"title": "The DBMS must protect against an individual using a group account from falsely denying having performed a particular action.",
|
|
835
|
+
"description": "Non-repudiation of actions taken is required in order to maintain application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. \n\nNon-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. \n\nGroup authentication does not provide individual accountability for actions taken on the DBMS or data. Whenever a single database account is used to connect to the database, a secondary authentication method that provides individual accountability is required. This scenario most frequently occurs when an externally hosted application authenticates individual users to the application and the application uses a single account to retrieve or update database information on behalf of the individual users.\n\nWhen group accounts are utilized without another means of identifying individual users, users may deny having performed a particular action.\n\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.",
|
|
836
|
+
"severity": "low"
|
|
837
|
+
},
|
|
838
|
+
{
|
|
839
|
+
"id": "V-52467",
|
|
840
|
+
"title": "The DBMS must allow designated organizational personnel to select which auditable events are to be audited by the database.",
|
|
841
|
+
"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, 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\nIf the list of auditable events is not configurable, events that should be caught by auditing may be missed. This may allow malicious activity to be overlooked.",
|
|
842
|
+
"severity": "medium"
|
|
843
|
+
},
|
|
844
|
+
{
|
|
845
|
+
"id": "V-52469",
|
|
846
|
+
"title": "The DBMS must generate audit records for the DoD-selected list of auditable events, to the extent such information is available.",
|
|
847
|
+
"description": "Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well.\n\nThe 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, 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\nOrganizations may define the organizational personnel accountable for determining which application components shall provide auditable events.\n\nAuditing provides accountability for changes made to the DBMS configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability.\n\nThe Department of Defense has established the following as the minimum set of auditable events. Most can be audited via Oracle settings; some may require OS settings.\n\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels). \n\n- Successful and unsuccessful logon attempts, privileged activities or other system level access\n\n- Starting and ending time for user access to the system, concurrent logons from different workstations.\n\n- Successful and unsuccessful accesses to objects.\n\n- All program initiations.\n\n- All direct access to the information system.\n\n- All account creations, modifications, disabling, and terminations. \n\n- All kernel module loads, unloads, and restarts. ",
|
|
848
|
+
"severity": "medium"
|
|
849
|
+
},
|
|
850
|
+
{
|
|
851
|
+
"id": "V-52471",
|
|
852
|
+
"title": "The DBMS must produce audit records containing sufficient information to establish what type of events occurred.",
|
|
853
|
+
"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\nDatabase software is capable of a range of actions on data stored within the database. It's important, for accurate forensic analysis, to know exactly what actions were performed. This requires specific information regarding the event type an audit record is referring to. If event type information is not recorded and stored with the audit record, the record itself is of very limited use.",
|
|
854
|
+
"severity": "medium"
|
|
855
|
+
},
|
|
856
|
+
{
|
|
857
|
+
"id": "V-52473",
|
|
858
|
+
"title": "The DBMS must produce audit records containing sufficient information to establish when (date and time) the events occurred.",
|
|
859
|
+
"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\nDatabase software is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly when specific actions were performed. This requires the date and time an audit record is referring to. If date and time information is not recorded and stored with the audit record, the record itself is of very limited use.",
|
|
860
|
+
"severity": "medium"
|
|
861
|
+
},
|
|
862
|
+
{
|
|
863
|
+
"id": "V-52475",
|
|
864
|
+
"title": "The DBMS must produce audit records containing sufficient information to establish where the events occurred.",
|
|
865
|
+
"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\nWithout sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.",
|
|
866
|
+
"severity": "medium"
|
|
867
|
+
},
|
|
868
|
+
{
|
|
869
|
+
"id": "V-52477",
|
|
870
|
+
"title": "The DBMS must produce audit records containing sufficient information to establish the sources (origins) of the events.",
|
|
871
|
+
"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, but is not limited to: timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, access control or flow control rules invoked. \n\nWithout information establishing the source of activity, the value of audit records from a forensics perspective is questionable.",
|
|
872
|
+
"severity": "medium"
|
|
873
|
+
},
|
|
874
|
+
{
|
|
875
|
+
"id": "V-52479",
|
|
876
|
+
"title": "The DBMS must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.",
|
|
877
|
+
"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, but is not limited to: timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, 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. Without knowing the outcome of audit events, it is very difficult to accurately recreate the series of events during forensic analysis.",
|
|
878
|
+
"severity": "medium"
|
|
879
|
+
},
|
|
880
|
+
{
|
|
881
|
+
"id": "V-53281",
|
|
882
|
+
"title": "Processes (services, applications, etc.) that connect to the DBMS independently of individual users, must use valid, current DoD-issued PKI certificates for authentication to the DBMS.",
|
|
883
|
+
"description": "Just as individual users must be authenticated, and just as they must use PKI-based authentication, so must any processes that connect to the DBMS.\n\nThe DoD standard for authentication of a process or device communicating with another process or device is the presentation of a valid, current, DoD-issued Public Key Infrastructure (PKI) certificate that has previously been verified as Trusted by an administrator of the other process or device.\n\nThis applies both to processes that run on the same server as the DBMS and to processes running on other computers.\n\nThe Oracle-supplied super-user account, SYS, is an exception. It cannot currently use certificate-based authentication. For this reason among others, use of SYS should be restricted to where it is truly needed.",
|
|
884
|
+
"severity": "medium"
|
|
885
|
+
},
|
|
886
|
+
{
|
|
887
|
+
"id": "V-53959",
|
|
888
|
+
"title": "Audit trail data must be retained for one year.",
|
|
889
|
+
"description": "Without preservation, a complete discovery of an attack or suspicious activity may not be determined. DBMS audit data also contributes to the complete investigation of unauthorized activity and needs to be included in audit retention plans and procedures.",
|
|
890
|
+
"severity": "medium"
|
|
891
|
+
},
|
|
892
|
+
{
|
|
893
|
+
"id": "V-53961",
|
|
894
|
+
"title": "Access to default accounts used to support replication must be restricted to authorized DBAs.",
|
|
895
|
+
"description": "Replication database accounts are used for database connections between databases. Replication requires the configuration of these accounts using the same username and password on all databases participating in the replication. Replication connections use fixed user database links. This means that access to the replication account on one server provides access to the other servers participating in the replication. Granting unauthorized access to the replication account provides unauthorized and privileged access to all databases participating in the replication group.",
|
|
896
|
+
"severity": "medium"
|
|
897
|
+
},
|
|
898
|
+
{
|
|
899
|
+
"id": "V-53963",
|
|
900
|
+
"title": "Oracle instance names must not contain Oracle version numbers.",
|
|
901
|
+
"description": "Service names may be discovered by unauthenticated users. If the service name includes version numbers or other database product information, a malicious user may use that information to develop a targeted attack.",
|
|
902
|
+
"severity": "medium"
|
|
903
|
+
},
|
|
904
|
+
{
|
|
905
|
+
"id": "V-53965",
|
|
906
|
+
"title": "Fixed user and public database links must be authorized for use.",
|
|
907
|
+
"description": "Database links define connections that may be used by the local database to access remote Oracle databases. These links provide a means for a compromise to the local database to spread to remote databases in the distributed database environment. Limiting or eliminating use of database links where they are not required to support the operational system can help isolate compromises to the local or a limited number of databases.",
|
|
908
|
+
"severity": "medium"
|
|
909
|
+
},
|
|
910
|
+
{
|
|
911
|
+
"id": "V-53967",
|
|
912
|
+
"title": "A minimum of two Oracle control files must be defined and configured to be stored on separate, archived disks (physical or virtual) or archived partitions on a RAID device.",
|
|
913
|
+
"description": "Oracle control files are used to store information critical to Oracle database integrity. Oracle uses these files to maintain time synchronization of database files as well as at system startup to verify the validity of system data and log files. Loss of access to the control files can affect database availability, integrity and recovery.",
|
|
914
|
+
"severity": "low"
|
|
915
|
+
},
|
|
916
|
+
{
|
|
917
|
+
"id": "V-53969",
|
|
918
|
+
"title": "A minimum of two Oracle redo log groups/files must be defined and configured to be stored on separate, archived physical disks or archived directories on a RAID device.",
|
|
919
|
+
"description": "The Oracle redo log files store the detailed information on changes made to the database. This information is critical to database recovery in case of a database failure.",
|
|
920
|
+
"severity": "medium"
|
|
921
|
+
},
|
|
922
|
+
{
|
|
923
|
+
"id": "V-53971",
|
|
924
|
+
"title": "The Oracle WITH GRANT OPTION privilege must not be granted to non-DBA or non-Application administrator user accounts.",
|
|
925
|
+
"description": "An account permission to grant privileges within the database is an administrative function. Minimizing the number and privileges of administrative accounts reduces the chances of privileged account exploitation. Application user accounts should never require WITH GRANT OPTION privileges since, by definition, they require only privileges to execute procedures or view / edit data.",
|
|
926
|
+
"severity": "medium"
|
|
927
|
+
},
|
|
928
|
+
{
|
|
929
|
+
"id": "V-53973",
|
|
930
|
+
"title": "Execute permission must be revoked from PUBLIC for restricted Oracle packages.",
|
|
931
|
+
"description": "Access to the following packages should be restricted to authorized accounts only.\n\nUTL_FILE: allows Oracle accounts to read and write files on the host operating system.\nUTL_SMTP: allows messages to be sent from an arbitrary user.\nUTL_TCP: allows arbitrary data to be sent from the database server.\nUTL_HTTP: allows the database server to send and receive data via HTTP.\nDBMS_RANDOM: allows encrypting of data without requiring safe management of encryption keys.\nDBMS_LOB: allows users access to files stored outside the database.\nDBMS_SQL: allows users to write dynamic SQL procedures.\nDBMS_SYS_SQL: allows users to execute SQL with DBA privileges.\nDBMS_JOB: allows users to submit jobs to the database job queue.\nDBMS_BACKUP_RESTORE: allows users to backup and restore database data.\nDBMS_OBFUSCATION_TOOLKIT: allows users access to encryption and decryption functions.",
|
|
932
|
+
"severity": "medium"
|
|
933
|
+
},
|
|
934
|
+
{
|
|
935
|
+
"id": "V-53975",
|
|
936
|
+
"title": "The Oracle REMOTE_OS_AUTHENT parameter must be set to FALSE.",
|
|
937
|
+
"description": "Setting this value to TRUE allows operating system authentication over an unsecured connection. Trusting remote operating systems can allow a user to impersonate another operating system user and connect to the database without having to supply a password. If REMOTE_OS_AUTHENT is set to true, the only information a remote user needs to connect to the database is the name of any user whose account is setup to be authenticated by the operating system.",
|
|
938
|
+
"severity": "high"
|
|
939
|
+
},
|
|
940
|
+
{
|
|
941
|
+
"id": "V-53977",
|
|
942
|
+
"title": "The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.",
|
|
943
|
+
"description": "Setting REMOTE_OS_ROLES to TRUE allows operating system groups to control Oracle roles. The default value of FALSE causes roles to be identified and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user could impersonate another operating system user over a network connection.",
|
|
944
|
+
"severity": "high"
|
|
945
|
+
},
|
|
946
|
+
{
|
|
947
|
+
"id": "V-53979",
|
|
948
|
+
"title": "The Oracle SQL92_SECURITY parameter must be set to TRUE.",
|
|
949
|
+
"description": "The configuration option SQL92_SECURITY specifies whether table-level SELECT privileges are required to execute an update or delete that references table column values. If this option is disabled (set to FALSE), the UPDATE privilege can be used to determine values that should require SELECT privileges.\n\nThe SQL92_SECURITY setting of TRUE prevents the exploitation of user credentials with only DELETE or UPDATE privileges on a table from being able to derive column values in that table by performing a series of update/delete statements using a where clause, and rolling back the change. In the following example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on the scott.emp table is able to derive that there is one employee with a salary greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from attempting to derive a value.\n\nSQL92_SECURITY = FALSE\nSQL> delete from scott.emp where sal > 3000;\n1 row deleted\nSQL> rollback;\nRollback complete\n\nSQL92_SECURITY = TRUE\nSQL> delete from scott.emp where sal > 3000;\ndelete from scott.emp where sal > 3000\n *\nERROR at line 1:\nORA-01031: insufficient privileges",
|
|
950
|
+
"severity": "medium"
|
|
951
|
+
},
|
|
952
|
+
{
|
|
953
|
+
"id": "V-53981",
|
|
954
|
+
"title": "The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to EXCLUSIVE or NONE.",
|
|
955
|
+
"description": "The REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of \"EXCLUSIVE\" allows for auditing of individual DBA logins to the SYS account. If not set to \"EXCLUSIVE\", remote connections to the database as \"internal\" or \"as SYSDBA\" are not logged to an individual account.",
|
|
956
|
+
"severity": "medium"
|
|
957
|
+
},
|
|
958
|
+
{
|
|
959
|
+
"id": "V-53983",
|
|
960
|
+
"title": "System privileges granted using the WITH ADMIN OPTION must not be granted to unauthorized user accounts.",
|
|
961
|
+
"description": "The WITH ADMIN OPTION allows the grantee to grant a privilege to another database account. Best security practice restricts the privilege of assigning privileges to authorized personnel. Authorized personnel include DBAs, object owners, and, where designed and included in the application's functions, application administrators. Restricting privilege-granting functions to authorized accounts can help decrease mismanagement of privileges and wrongful assignments to unauthorized accounts.",
|
|
962
|
+
"severity": "medium"
|
|
963
|
+
},
|
|
964
|
+
{
|
|
965
|
+
"id": "V-53985",
|
|
966
|
+
"title": "System Privileges must not be granted to PUBLIC.",
|
|
967
|
+
"description": "System privileges can be granted to users and roles and to the user group PUBLIC. All privileges granted to PUBLIC are accessible to every user in the database. Many of these privileges convey considerable authority over the database and are granted only to those persons responsible for administering the database. In general, these privileges should be granted to roles and then the appropriate roles should be granted to users. System privileges should never be granted to PUBLIC as this could allow users to compromise the database.",
|
|
968
|
+
"severity": "medium"
|
|
969
|
+
},
|
|
970
|
+
{
|
|
971
|
+
"id": "V-53987",
|
|
972
|
+
"title": "Oracle roles granted using the WITH ADMIN OPTION must not be granted to unauthorized accounts.",
|
|
973
|
+
"description": "The WITH ADMIN OPTION allows the grantee to grant a role to another database account. Best security practice restricts the privilege of assigning privileges to authorized personnel. Authorized personnel include DBA's, object owners, and, where designed and included in the application's functions, application administrators. Restricting privilege-granting functions to authorized accounts can help decrease mismanagement of privileges and wrongful assignments to unauthorized accounts.",
|
|
974
|
+
"severity": "medium"
|
|
975
|
+
},
|
|
976
|
+
{
|
|
977
|
+
"id": "V-53989",
|
|
978
|
+
"title": "Object permissions granted to PUBLIC must be restricted.",
|
|
979
|
+
"description": "Permissions on objects may be granted to the user group PUBLIC. Because every database user is a member of the PUBLIC group, granting object permissions to PUBLIC gives all users in the database access to that object. In a secure environment, granting object permissions to PUBLIC should be restricted to those objects that all users are allowed to access. The policy does not require object permissions assigned to PUBLIC by the installation of Oracle Database server components to be revoked (with the exception of the packages listed in O112-BP-021800).",
|
|
980
|
+
"severity": "medium"
|
|
981
|
+
},
|
|
982
|
+
{
|
|
983
|
+
"id": "V-53991",
|
|
984
|
+
"title": "The Oracle Listener must be configured to require administration authentication.",
|
|
985
|
+
"description": "Oracle listener authentication helps prevent unauthorized administration of the Oracle listener. Unauthorized administration of the listener could lead to DoS exploits; loss of connection audit data, unauthorized reconfiguration or other unauthorized access. This is a Category I finding because privileged access to the listener is not restricted to authorized users. Unauthorized access can result in stopping of the listener (DoS) and overwriting of listener audit logs.",
|
|
986
|
+
"severity": "high"
|
|
987
|
+
},
|
|
988
|
+
{
|
|
989
|
+
"id": "V-53993",
|
|
990
|
+
"title": "Application role permissions must not be assigned to the Oracle PUBLIC role.",
|
|
991
|
+
"description": "Application roles have been granted to PUBLIC. Permissions granted to PUBLIC are granted to all users of the database. Custom roles should be used to assign application permissions to functional groups of application users. The installation of Oracle does not assign role permissions to PUBLIC.",
|
|
992
|
+
"severity": "medium"
|
|
993
|
+
},
|
|
994
|
+
{
|
|
995
|
+
"id": "V-53995",
|
|
996
|
+
"title": "Oracle application administration roles must be disabled if not required and authorized.",
|
|
997
|
+
"description": "Application administration roles, which are assigned system or elevated application object privileges, should be protected from default activation. Application administration roles are determined by system privilege assignment (create / alter / drop user) and application user role ADMIN OPTION privileges.",
|
|
998
|
+
"severity": "medium"
|
|
999
|
+
},
|
|
1000
|
+
{
|
|
1001
|
+
"id": "V-53997",
|
|
1002
|
+
"title": "Connections by mid-tier web and application systems to the Oracle DBMS from a DMZ or external network must be encrypted.",
|
|
1003
|
+
"description": "Multi-tier systems may be configured with the database and connecting middle-tier system located on an internal network, with the database located on an internal network behind a firewall and the middle-tier system located in a DMZ. In cases where either or both systems are located in the DMZ (or on networks external to DoD), network communications between the systems must be encrypted.",
|
|
1004
|
+
"severity": "medium"
|
|
1005
|
+
},
|
|
1006
|
+
{
|
|
1007
|
+
"id": "V-53999",
|
|
1008
|
+
"title": "Database job/batch queues must be reviewed regularly to detect unauthorized database job submissions.",
|
|
1009
|
+
"description": "Unauthorized users may bypass security mechanisms by submitting jobs to job queues managed by the database to be run under a more privileged security context of the database or host system. These queues should be monitored regularly to detect any such unauthorized job submissions.",
|
|
1010
|
+
"severity": "medium"
|
|
1011
|
+
},
|
|
1012
|
+
{
|
|
1013
|
+
"id": "V-54001",
|
|
1014
|
+
"title": "Unauthorized database links must not be defined and active.",
|
|
1015
|
+
"description": "DBMS links provide a communication and data transfer path definition between two databases that may be used by malicious users to discover and obtain unauthorized access to remote systems. Database links between production and development DBMSs provide a means for developers to access production data not authorized for their access or to introduce untested or unauthorized applications to the production database. Only protected, controlled, and authorized downloads of any production data to use for development should be allowed. Only applications that have completed the configuration management process should be introduced by the application object owner account to the production system.",
|
|
1016
|
+
"severity": "medium"
|
|
1017
|
+
},
|
|
1018
|
+
{
|
|
1019
|
+
"id": "V-54003",
|
|
1020
|
+
"title": "Sensitive information from production database exports must be modified before being imported into a development database.",
|
|
1021
|
+
"description": "Data export from production databases may include sensitive data. Application developers do not have a need to know to sensitive data. Any access they may have to production data would be considered unauthorized access and subject the sensitive data to unlawful or unauthorized disclosure. See DODD 8500.1 for a definition of Sensitive Information.",
|
|
1022
|
+
"severity": "medium"
|
|
1023
|
+
},
|
|
1024
|
+
{
|
|
1025
|
+
"id": "V-54005",
|
|
1026
|
+
"title": "Application user privilege assignment must be reviewed monthly or more frequently to ensure compliance with least privilege and documented policy.",
|
|
1027
|
+
"description": "Users granted privileges not required to perform their assigned functions are able to make unauthorized modifications to the production data or database. Monthly or more frequent periodic review of privilege assignments assures that organizational and/or functional changes are reflected appropriately.",
|
|
1028
|
+
"severity": "medium"
|
|
1029
|
+
},
|
|
1030
|
+
{
|
|
1031
|
+
"id": "V-54007",
|
|
1032
|
+
"title": "Audit trail data must be reviewed daily or more frequently.",
|
|
1033
|
+
"description": "Review of audit trail data provides a means for detection of unauthorized access or attempted access. Frequent and regularly scheduled reviews ensure that such access is discovered in a timely manner.",
|
|
1034
|
+
"severity": "medium"
|
|
1035
|
+
},
|
|
1036
|
+
{
|
|
1037
|
+
"id": "V-54009",
|
|
1038
|
+
"title": "Only authorized system accounts must have the SYSTEM tablespace specified as the default tablespace.",
|
|
1039
|
+
"description": "The Oracle SYSTEM tablespace is used by the database to store all DBMS system objects. Other use of the system tablespace may compromise system availability and the effectiveness of host system access controls to the tablespace files.",
|
|
1040
|
+
"severity": "medium"
|
|
1041
|
+
},
|
|
1042
|
+
{
|
|
1043
|
+
"id": "V-54011",
|
|
1044
|
+
"title": "Application owner accounts must have a dedicated application tablespace.",
|
|
1045
|
+
"description": "Separation of tablespaces by application helps to protect the application from resource contention and unauthorized access that could result from storage space reuses or host system access controls. Application data should be stored separately from system and custom user-defined objects to facilitate administration and management of its data storage. The SYSTEM tablespace should never be used for application data storage in order to prevent resource contention and performance degradation.",
|
|
1046
|
+
"severity": "medium"
|
|
1047
|
+
},
|
|
1048
|
+
{
|
|
1049
|
+
"id": "V-54013",
|
|
1050
|
+
"title": "The directories assigned to the LOG_ARCHIVE_DEST* parameters must be protected from unauthorized access.",
|
|
1051
|
+
"description": "The LOG_ARCHIVE_DEST parameter is used to specify the directory to which Oracle archive logs are written. Where the DBMS availability and recovery to a specific point in time is critical, the protection of archive log files is critical. Archive log files may also contain unencrypted sensitive data. If written to an inadequately protected or invalidated directory, the archive log files may be accessed by unauthorized persons or processes.",
|
|
1052
|
+
"severity": "medium"
|
|
1053
|
+
},
|
|
1054
|
+
{
|
|
1055
|
+
"id": "V-54015",
|
|
1056
|
+
"title": "The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to FALSE.",
|
|
1057
|
+
"description": "The _TRACE_FILES_PUBLIC parameter is used to make trace files used for debugging database applications and events available to all database users. Use of this capability precludes the discrete assignment of privileges based on job function. Additionally, its use may provide access to external files and data to unauthorized users.",
|
|
1058
|
+
"severity": "medium"
|
|
1059
|
+
},
|
|
1060
|
+
{
|
|
1061
|
+
"id": "V-54017",
|
|
1062
|
+
"title": "Application object owner accounts must be disabled when not performing installation or maintenance actions.",
|
|
1063
|
+
"description": "Object ownership provides all database object permissions to the owned object. Access to the application object owner accounts requires special protection to prevent unauthorized access and use of the object ownership privileges. In addition to the high privileges to application objects assigned to this account, it is also an account that, by definition, is not accessed interactively except for application installation and maintenance. This reduced access to the account means that unauthorized access to the account could go undetected. To help protect the account, it should be enabled only when access is required.",
|
|
1064
|
+
"severity": "medium"
|
|
1065
|
+
},
|
|
1066
|
+
{
|
|
1067
|
+
"id": "V-54019",
|
|
1068
|
+
"title": "DBMS production application and data directories must be protected from developers on shared production/development DBMS host systems.",
|
|
1069
|
+
"description": "Developer roles should not be assigned DBMS administrative privileges to production DBMS application and data directories. The separation of production DBA and developer roles helps protect the production system from unauthorized, malicious or unintentional interruption due to development activities.",
|
|
1070
|
+
"severity": "medium"
|
|
1071
|
+
},
|
|
1072
|
+
{
|
|
1073
|
+
"id": "V-54021",
|
|
1074
|
+
"title": "Use of the DBMS installation account must be logged.",
|
|
1075
|
+
"description": "The DBMS installation account may be used by any authorized user to perform DBMS installation or maintenance. Without logging, accountability for actions attributed to the account is lost.",
|
|
1076
|
+
"severity": "medium"
|
|
1077
|
+
},
|
|
1078
|
+
{
|
|
1079
|
+
"id": "V-54023",
|
|
1080
|
+
"title": "Remote administrative access to the database must be monitored by the IAO or IAM.",
|
|
1081
|
+
"description": "Remote administrative access to systems provides a path for access to and exploit of DBA privileges. Where the risk has been accepted to allow remote administrative access, it is imperative to instate increased monitoring of this access to detect any abuse or compromise.",
|
|
1082
|
+
"severity": "medium"
|
|
1083
|
+
},
|
|
1084
|
+
{
|
|
1085
|
+
"id": "V-54025",
|
|
1086
|
+
"title": "The database must not be directly accessible from public or unauthorized networks.",
|
|
1087
|
+
"description": "Databases often store critical and/or sensitive information used by the organization. For this reason, databases are targeted for attacks by malicious users. Additional protections provided by network defenses that limit accessibility help protect the database and its data from unnecessary exposure and risk.",
|
|
1088
|
+
"severity": "medium"
|
|
1089
|
+
},
|
|
1090
|
+
{
|
|
1091
|
+
"id": "V-54027",
|
|
1092
|
+
"title": "The IAM must review changes to DBA role assignments.",
|
|
1093
|
+
"description": "Unauthorized assignment of DBA privileges can lead to a compromise of DBMS integrity. Providing oversight to the authorization and assignment of privileges provides the separation of duty to support sufficient oversight.",
|
|
1094
|
+
"severity": "medium"
|
|
1095
|
+
},
|
|
1096
|
+
{
|
|
1097
|
+
"id": "V-54029",
|
|
1098
|
+
"title": "Plans and procedures for testing DBMS installations, upgrades and patches must be defined and followed prior to production implementation.",
|
|
1099
|
+
"description": "Updates and patches to existing software have the intention of improving the security or enhancing or adding features to the product. However, it is unfortunately common that updates or patches can render production systems inoperable or even introduce serious vulnerabilities. Some updates also set security configurations back to unacceptable settings that do not meet security requirements. For these reasons, it is a good practice to test updates and patches offline before introducing them in a production environment.",
|
|
1100
|
+
"severity": "medium"
|
|
1101
|
+
},
|
|
1102
|
+
{
|
|
1103
|
+
"id": "V-54031",
|
|
1104
|
+
"title": "Procedures and restrictions for import of production data to development databases must be documented, implemented, and followed.",
|
|
1105
|
+
"description": "Data export from production databases may include sensitive data. Application developers may not be cleared for or have need-to-know to sensitive data. Any access they may have to production data would be considered unauthorized access and subject the sensitive data to unlawful or unauthorized disclosure.",
|
|
1106
|
+
"severity": "medium"
|
|
1107
|
+
},
|
|
1108
|
+
{
|
|
1109
|
+
"id": "V-54033",
|
|
1110
|
+
"title": "Sensitive data stored in the database must be identified in the System Security Plan and AIS Functional Architecture documentation.",
|
|
1111
|
+
"description": "A DBMS that does not have the correct confidentiality level identified or any confidentiality level assigned is not being secured at a level appropriate to the risk it poses.",
|
|
1112
|
+
"severity": "medium"
|
|
1113
|
+
},
|
|
1114
|
+
{
|
|
1115
|
+
"id": "V-54039",
|
|
1116
|
+
"title": "Credentials stored and used by the DBMS to access remote databases or applications must be authorized and restricted to authorized users.",
|
|
1117
|
+
"description": "Credentials defined for access to remote databases or applications may provide unauthorized access to additional databases and applications to unauthorized or malicious users.",
|
|
1118
|
+
"severity": "medium"
|
|
1119
|
+
},
|
|
1120
|
+
{
|
|
1121
|
+
"id": "V-54041",
|
|
1122
|
+
"title": "The DBMS must not share a host supporting an independent security service.",
|
|
1123
|
+
"description": "The Security Support Structure is a security control function or service provided by an external system or application. An example of this would be a Windows domain controller that provides identification and authentication that can be used by other systems to control access. The associated risk of a DBMS installed on a system that provides security support is significantly higher than when installed on separate systems. In cases where the DBMS is dedicated to local support of a security support function (e.g. a directory service), separation may not be possible.",
|
|
1124
|
+
"severity": "medium"
|
|
1125
|
+
},
|
|
1126
|
+
{
|
|
1127
|
+
"id": "V-54043",
|
|
1128
|
+
"title": "Access to DBMS software files and directories must not be granted to unauthorized users.",
|
|
1129
|
+
"description": "The DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in malicious alteration or planting of operational executables. This may in turn jeopardize data stored in the DBMS and/or operation of the host system.",
|
|
1130
|
+
"severity": "medium"
|
|
1131
|
+
},
|
|
1132
|
+
{
|
|
1133
|
+
"id": "V-54045",
|
|
1134
|
+
"title": "Replication accounts must not be granted DBA privileges.",
|
|
1135
|
+
"description": "Replication accounts may be used to access databases defined for the replication architecture. An exploit of a replication on one database could lead to the compromise of any database participating in the replication that uses the same account name and credentials. If the replication account is compromised and it has DBA privileges, the database is at additional risk to unauthorized or malicious action.",
|
|
1136
|
+
"severity": "medium"
|
|
1137
|
+
},
|
|
1138
|
+
{
|
|
1139
|
+
"id": "V-54047",
|
|
1140
|
+
"title": "Network access to the DBMS must be restricted to authorized personnel.",
|
|
1141
|
+
"description": "Restricting remote access to specific, trusted systems helps prevent access by unauthorized and potentially malicious users.",
|
|
1142
|
+
"severity": "medium"
|
|
1143
|
+
},
|
|
1144
|
+
{
|
|
1145
|
+
"id": "V-54051",
|
|
1146
|
+
"title": "Changes to configuration options must be audited.",
|
|
1147
|
+
"description": "The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of actions taken by the user SYS. The SYS user account is a shared account by definition and holds all privileges in the Oracle database. It is the account accessed by users connecting to the database with SYSDBA or SYSOPER privileges.",
|
|
1148
|
+
"severity": "medium"
|
|
1149
|
+
},
|
|
1150
|
+
{
|
|
1151
|
+
"id": "V-54055",
|
|
1152
|
+
"title": "Remote DBMS administration must be documented and authorized or disabled.",
|
|
1153
|
+
"description": "Remote administration may expose configuration and sensitive data to unauthorized viewing during transit across the network or allow unauthorized administrative access to the DBMS to remote users.\n\nFor the purposes of this STIG, \"Remote\" means \"outside the DoDIN.\" However, use of an approved and properly configured VPN counts as inside the DoDIN.",
|
|
1154
|
+
"severity": "medium"
|
|
1155
|
+
},
|
|
1156
|
+
{
|
|
1157
|
+
"id": "V-54067",
|
|
1158
|
+
"title": "DBMS symmetric keys must be protected in accordance with NSA- or NIST-approved key management technology or processes.",
|
|
1159
|
+
"description": "Symmetric keys used for encryption protect data from unauthorized access. However, if not protected in accordance with acceptable standards, the keys themselves may be compromised and used for unauthorized data access.",
|
|
1160
|
+
"severity": "medium"
|
|
1161
|
+
},
|
|
1162
|
+
{
|
|
1163
|
+
"id": "V-54069",
|
|
1164
|
+
"title": "Changes to DBMS security labels must be audited.",
|
|
1165
|
+
"description": "Some DBMS systems provide the feature to assign security labels to data elements. If labeling is required, implementation options include the Oracle Label Security package, or a third-party product, or custom-developed functionality. The confidentiality and integrity of the data depends upon the security label assignment where this feature is in use. Changes to security label assignment may indicate suspicious activity.",
|
|
1166
|
+
"severity": "medium"
|
|
1167
|
+
},
|
|
1168
|
+
{
|
|
1169
|
+
"id": "V-54071",
|
|
1170
|
+
"title": "Remote database or other external access must use fully-qualified names.",
|
|
1171
|
+
"description": "The Oracle GLOBAL_NAMES parameter is used to set the requirement for database link names to be the same name as the remote database whose connection they define. By using the same name for both, ambiguity is avoided and unauthorized or unintended connections to remote databases are less likely.",
|
|
1172
|
+
"severity": "medium"
|
|
1173
|
+
},
|
|
1174
|
+
{
|
|
1175
|
+
"id": "V-54073",
|
|
1176
|
+
"title": "The /diag subdirectory under the directory assigned to the DIAGNOSTIC_DEST parameter must be protected from unauthorized access.",
|
|
1177
|
+
"description": "<DIAGNOSTIC_DEST>/diag indicates the directory where trace, alert, core and incident directories and files are located. The files may contain sensitive data or information that could prove useful to potential attackers.",
|
|
1178
|
+
"severity": "medium"
|
|
1179
|
+
},
|
|
1180
|
+
{
|
|
1181
|
+
"id": "V-54075",
|
|
1182
|
+
"title": "Remote administration must be disabled for the Oracle connection manager.",
|
|
1183
|
+
"description": "Remote administration provides a potential opportunity for malicious users to make unauthorized changes to the Connection Manager configuration or interrupt its service.",
|
|
1184
|
+
"severity": "medium"
|
|
1185
|
+
},
|
|
1186
|
+
{
|
|
1187
|
+
"id": "V-54077",
|
|
1188
|
+
"title": "The SQLNet SQLNET.ALLOWED_LOGON_VERSION parameter must be set to a value of 11 or higher.",
|
|
1189
|
+
"description": "Unsupported Oracle network client installations may introduce vulnerabilities to the database. Restriction to use of supported versions helps to protect the database and helps to enforce newer, more robust security controls.",
|
|
1190
|
+
"severity": "medium"
|
|
1191
|
+
},
|
|
1192
|
+
{
|
|
1193
|
+
"id": "V-54079",
|
|
1194
|
+
"title": "The DBMS host platform and other dependent applications must be configured in compliance with applicable STIG requirements.",
|
|
1195
|
+
"description": "The security of the data stored in the DBMS is also vulnerable to attacks against the host platform, calling applications, and other application or optional components.",
|
|
1196
|
+
"severity": "medium"
|
|
1197
|
+
},
|
|
1198
|
+
{
|
|
1199
|
+
"id": "V-57615",
|
|
1200
|
+
"title": "The directory assigned to the AUDIT_FILE_DEST parameter must be protected from unauthorized access and must be stored in a dedicated directory or disk partition separate from software or other application files.",
|
|
1201
|
+
"description": "The AUDIT_FILE_DEST parameter specifies the directory where the database audit trail file is stored (when AUDIT_TRAIL parameter is set to ‘OS’, ‘xml’ or ‘xml, extended’ where supported by the DBMS). Unauthorized access or loss of integrity of the audit trail could result in loss of accountability or the ability to detect suspicious\nactivity. This directory also contains the audit trail of the SYS and SYSTEM accounts that captures privileged database events when the database is not running (when AUDIT_SYS_OPERATIONS parameter is set to TRUE).",
|
|
1202
|
+
"severity": "medium"
|
|
1203
|
+
},
|
|
1204
|
+
{
|
|
1205
|
+
"id": "V-59855",
|
|
1206
|
+
"title": "Owners of privileged accounts must use non-privileged accounts for non-administrative activities.",
|
|
1207
|
+
"description": "Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts, if used for non-administration application development or application maintenance, can lead to excessive privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.",
|
|
1208
|
+
"severity": "medium"
|
|
1209
|
+
},
|
|
1210
|
+
{
|
|
1211
|
+
"id": "V-60141",
|
|
1212
|
+
"title": "Access to external executables must be disabled or restricted.",
|
|
1213
|
+
"description": "The Oracle external procedure capability provides use of the Oracle process account outside the operation of the DBMS process. You can use it to submit and execute applications stored externally from the database under operating system controls. The external procedure process is the subject of frequent and successful attacks as it allows unauthenticated use of the Oracle process account on the operating system. As of Oracle version 11.1, the external procedure agent may be run directly from the database and not require use of the Oracle listener. This reduces the risk of unauthorized access to the procedure from outside of the database process.",
|
|
1214
|
+
"severity": "medium"
|
|
1215
|
+
},
|
|
1216
|
+
{
|
|
1217
|
+
"id": "V-68861",
|
|
1218
|
+
"title": "Logic modules within the database (to include packages, procedures, functions and triggers) must be monitored to discover unauthorized changes.",
|
|
1219
|
+
"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. This includes the logic modules implemented within the database, such as packages, procedures, functions and triggers.\n\nIf the DBMS were to allow any user to make changes to these, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database logic modules can lead to unauthorized or compromised installations.",
|
|
1220
|
+
"severity": "medium"
|
|
1221
|
+
},
|
|
1222
|
+
{
|
|
1223
|
+
"id": "V-75031",
|
|
1224
|
+
"title": "The DBMS must use multifactor authentication for local access to non-privileged accounts.",
|
|
1225
|
+
"description": "Multifactor authentication is defined as using two or more factors to achieve authentication. \n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or \n(iii) Something a user is (e.g., biometric). \n\nA non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. \n\nLocal Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.\n\nThe lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system.",
|
|
1226
|
+
"severity": "medium"
|
|
1227
|
+
}
|
|
1228
|
+
]
|
|
1229
|
+
}
|