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,179 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_microsoft_sql_server_2012_database",
|
|
3
|
+
"date": "2018-03-01",
|
|
4
|
+
"description": "The Microsoft SQL Server 2012 Database Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
|
|
5
|
+
"title": "Microsoft SQL Server 2012 Database Security Technical Implementation Guide",
|
|
6
|
+
"version": "1",
|
|
7
|
+
"item_syntax": "^\\w-\\d+$",
|
|
8
|
+
"section_separator": null,
|
|
9
|
+
"items": [
|
|
10
|
+
{
|
|
11
|
+
"id": "V-40911",
|
|
12
|
+
"title": "SQL Server must protect data at rest and ensure confidentiality and integrity of data.",
|
|
13
|
+
"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, as well as, application-specific configuration data, needs to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, 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 SQL Server data is not protected, the data will be open to compromise and unauthorized modification.\n\nProtective measures include encryption, physical security of the facility where the storage devices reside, operating system file permissions, and organizational controls. Each of these should be applied as necessary and appropriate.",
|
|
14
|
+
"severity": "medium"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"id": "V-41389",
|
|
18
|
+
"title": "SQL Server must maintain and support organization-defined security labels on stored information.",
|
|
19
|
+
"description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.\n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy.\n\nOne example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but, either way, it is imperative these assignments are maintained while the data is in storage. If the security attributes are lost when the data is stored, there is the risk of a data compromise.\n\nThe sensitivity marking or labeling of stored data items promotes the correct handling and protection of data. Without such notification, the user may unwittingly disclose sensitive data to unauthorized users.\n\n(Earlier releases of this STIG suggested using the SQL Server Label Security Toolkit, from codeplex.com. However, codeplex.com has been shut down, and it is unclear whether the Toolkit is still supported. If the organization does have access to the Toolkit, it may still be used, provided the organization accepts responsibility for its support.)",
|
|
20
|
+
"severity": "medium"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "V-41391",
|
|
24
|
+
"title": "SQL Server must maintain and support organization-defined security labels on information in process.",
|
|
25
|
+
"description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.\n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy.\n\nOrganizations define the security attributes of their data (e.g., classified, FOUO). Applications generating and/or processing data assigned these organization-defined security attributes must maintain the binding of these attributes to the data when the data is transmitted.\n\nIf the application does not maintain the data security attributes when it transmits the data, there is a risk of data compromise.\n\nThe sensitivity marking or labeling of data items promotes the correct handling and protection of data. Without such notification, the user may unwittingly disclose sensitive data to unauthorized users. Security labels must be correctly maintained throughout transmission.\n\n(Earlier releases of this STIG suggested using the SQL Server Label Security Toolkit, from codeplex.com. However, codeplex.com has been shut down, and it is unclear whether the Toolkit is still supported. If the organization does have access to the Toolkit, it may still be used, provided the organization accepts responsibility for its support.)",
|
|
26
|
+
"severity": "medium"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "V-41392",
|
|
30
|
+
"title": "SQL Server must maintain and support organization-defined security labels on data in transmission.",
|
|
31
|
+
"description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.\n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy.\n\nOrganizations define the security attributes of their data (e.g., classified, FOUO). Applications generating and/or processing data assigned these organization-defined security attributes must maintain the binding of these attributes to the data when the data is transmitted.\n\nIf the application does not maintain the data security attributes when it transmits the data, there is a risk of data compromise.\n\nThe sensitivity marking or labeling of data items promotes the correct handling and protection of data. Without such notification, the user may unwittingly disclose sensitive data to unauthorized users. Security labels must be correctly maintained throughout transmission.\n\n(Earlier releases of this STIG suggested using the SQL Server Label Security Toolkit, from codeplex.com. However, codeplex.com has been shut down, and it is unclear whether the Toolkit is still supported. If the organization does have access to the Toolkit, it may still be used, provided the organization accepts responsibility for its support.)",
|
|
32
|
+
"severity": "medium"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "V-41393",
|
|
36
|
+
"title": "SQL Server must allow authorized users to associate security labels to information in the database.",
|
|
37
|
+
"description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.\n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions, or support other aspects of the information security policy.\n\nExamples of application security attributes are classified, FOUO, sensitive, etc.\n\nThroughout the course of normal usage, authorized users of applications that handle sensitive data will have the need to associate security attributes with information. Applications that maintain the binding of organization-defined security attributes to data must ensure authorized users can associate security attributes with information. For databases, this is accomplished via labeling.",
|
|
38
|
+
"severity": "medium"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "V-41394",
|
|
42
|
+
"title": "SQL Server utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights.",
|
|
43
|
+
"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 object permissions possesses only the access intended. The database must enforce the ability to limit unauthorized rights propagation. If propagation is not prevented, users can continue to grant rights to other users without limit.",
|
|
44
|
+
"severity": "medium"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "V-41395",
|
|
48
|
+
"title": "SQL Server must be protected from unauthorized access by developers.",
|
|
49
|
+
"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 should not be allowed.",
|
|
50
|
+
"severity": "medium"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "V-41396",
|
|
54
|
+
"title": "SQL Server must be protected from unauthorized access by developers on shared production/development host systems.",
|
|
55
|
+
"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.",
|
|
56
|
+
"severity": "medium"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"id": "V-41397",
|
|
60
|
+
"title": "Administrative privileges, built-in server roles and built-in database roles must be assigned to the DBMS login accounts that require them via custom roles, and not directly.",
|
|
61
|
+
"description": "SQL Server must 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 role 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.\n\nSQL Server built-in administrative privileges, built-in server roles and built-in database roles must not be assigned directly to administrative user accounts (that is, server logins and database users). If administrative user accounts have direct access to administrative roles, this access must be removed, with the exception of administrative roles that the DBMS assigns to the special database principal [dbo], and will not allow to be altered.\n\nThe built-in server role \"sysadmin\" is a partial exception. This cannot be granted to a user-defined role, only to a login account. Most (not necessarily all) database administrators will need to be members of sysadmin. Without this, most DBCC commands and the system stored procedures/functions listed below are unavailable. The users who require such access must be documented and approved.",
|
|
62
|
+
"severity": "medium"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-41399",
|
|
66
|
+
"title": "SQL Server job/batch queues must be reviewed regularly to detect unauthorized SQL Server job submissions.",
|
|
67
|
+
"description": "When dealing with unauthorized SQL Server job submissions, it should be noted any unauthorized job submissions to SQL Server job/batch queues can potentially have significant effects on the overall security of the system.\n\nIf SQL Server were to allow any user to make SQL Server job/batch queue submissions, then those submissions might lead to a compromise of system integrity and/or data. This requirement is contingent upon the SQL Server job/batch queue being review regularly for unauthorized submissions.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to submit SQL Server jobs. Job/batch queue submissions must adhere to an organization-defined job submission process. \n\nUnmanaged changes that occur to SQL Server job/batch queues can lead to a compromised system.",
|
|
68
|
+
"severity": "medium"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-41402",
|
|
72
|
+
"title": "SQL Server must provide audit record generation capability for organization-defined auditable events within the database.",
|
|
73
|
+
"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. Examples are auditable events, time stamps, 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.",
|
|
74
|
+
"severity": "medium"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-41403",
|
|
78
|
+
"title": "SQL Server must be monitored to discover unauthorized changes to functions.",
|
|
79
|
+
"description": "When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of SQL Server and/or application can potentially have significant effects on the overall security of the system.\n\nIf SQL Server 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 SQL Server components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the SQL Server software libraries or configuration, such as Functions, can lead to unauthorized or compromised installations.",
|
|
80
|
+
"severity": "medium"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "V-41404",
|
|
84
|
+
"title": "SQL Server must be monitored to discover unauthorized changes to triggers.",
|
|
85
|
+
"description": "When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of SQL Server and/or application can potentially have significant effects on the overall security of the system.\n\nIf SQL Server 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 SQL Server components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the SQL Server software libraries or configuration, such as Triggers, can lead to unauthorized or compromised installations.",
|
|
86
|
+
"severity": "medium"
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "V-41406",
|
|
90
|
+
"title": "SQL Server must be monitored to discover unauthorized changes to stored procedures.",
|
|
91
|
+
"description": "When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of SQL Server and/or application can potentially have significant effects on the overall security of the system.\n\nIf SQL Server 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 SQL Server components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the SQL Server software libraries or configuration, such as Stored Procedures, can lead to unauthorized or compromised installations.",
|
|
92
|
+
"severity": "medium"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-41407",
|
|
96
|
+
"title": "Database objects must be owned by accounts authorized for ownership.",
|
|
97
|
+
"description": "SQL Server database ownership is a higher level privilege that grants full rights to everything in that database, including the right to grant privileges to others. SQL Server requires that the owner of a database object be a user, and only one user can be the assigned owner of a database object. This tends to minimize the risk that multiple users could gain unauthorized access, except the one individual who is the owner.\n\nWithin 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 databases can lead to unauthorized granting of privileges and database alterations.",
|
|
98
|
+
"severity": "medium"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"id": "V-41409",
|
|
102
|
+
"title": "Unused database components and database objects must be removed.",
|
|
103
|
+
"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 every mission, yet cannot be disabled.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused and unnecessary SQL Server components increase the number of available attack vectors to SQL Server by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced.",
|
|
104
|
+
"severity": "medium"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"id": "V-41411",
|
|
108
|
+
"title": "SQL Server must encrypt information stored in the database.",
|
|
109
|
+
"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.",
|
|
110
|
+
"severity": "medium"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-41412",
|
|
114
|
+
"title": "SQL Server must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.",
|
|
115
|
+
"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\nUse of cryptography to provide confidentiality and non-repudiation is not effective unless strong methods are employed with its use. 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 the following website: http://csrc.nist.gov/groups/STM/cmvp/index.html.",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-41415",
|
|
120
|
+
"title": "The Database Master Key must be encrypted by the Service Master Key where required.",
|
|
121
|
+
"description": "When not encrypted by the Service Master Key, system administrators or application administrators may access and use the Database Master Key to view sensitive data that they are not authorized to view. Where alternate encryption means are not feasible, encryption by the Service Master Key may be necessary. To help protect sensitive data from unauthorized access by DBAs, mitigations may be in order. Mitigations may include automatic alerts or other audit events when the Database Master Key is accessed outside of the application or by a DBA account.",
|
|
122
|
+
"severity": "medium"
|
|
123
|
+
},
|
|
124
|
+
{
|
|
125
|
+
"id": "V-41416",
|
|
126
|
+
"title": "Database Master Key passwords must not be stored in credentials within the database.",
|
|
127
|
+
"description": "Storage of the Database Master Key password in a database credential allows decryption of sensitive data by privileged users who may not have a need-to-know requirement to access the\ndata.",
|
|
128
|
+
"severity": "medium"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"id": "V-41417",
|
|
132
|
+
"title": "Symmetric keys (other than the database master key) must use a DoD certificate to encrypt the key.",
|
|
133
|
+
"description": "Data within the database is protected by use of encryption. The symmetric keys are critical for this process. If the symmetric keys were to be compromised the data could be disclosed to unauthorized personnel.",
|
|
134
|
+
"severity": "medium"
|
|
135
|
+
},
|
|
136
|
+
{
|
|
137
|
+
"id": "V-41420",
|
|
138
|
+
"title": "SQL Server must employ cryptographic mechanisms preventing the unauthorized disclosure of information at rest.",
|
|
139
|
+
"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. If the data is not encrypted, it is subject to compromise and unauthorized disclosure.\n\nNote: the system databases (master, msdb, model, resource and tempdb) cannot be encrypted.\n\nThe 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.",
|
|
140
|
+
"severity": "medium"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-41421",
|
|
144
|
+
"title": "SQL Server must prevent unauthorized and unintended information transfer via shared system resources.",
|
|
145
|
+
"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.",
|
|
146
|
+
"severity": "medium"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-41422",
|
|
150
|
+
"title": "SQL Server must protect against or limit the effects of the organization-defined types of Denial of Service (DoS) attacks.",
|
|
151
|
+
"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 DoS 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\nThis requirement may be met via the application or by utilizing information system session control provided by a web server with specialized session management capabilities. If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application.\n\nThe organization will need to define the maximum number of concurrent sessions for SQL Server accounts by account type, by account, or a combination thereof and SQL Server shall enforce this requirement.\n\nUnlimited concurrent connections to SQL Server could allow a successful DoS attack by exhausting connection resources.",
|
|
152
|
+
"severity": "medium"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "V-41424",
|
|
156
|
+
"title": "SQL Server must check the validity of data inputs.",
|
|
157
|
+
"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\nSQL Server needs to validate the data user’s 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\nA poorly designed database system can have many problems. A common issue with these types of systems is the missed opportunity to use constraints.\n\nWhile this matter is of great importance to the secure operation of database management systems, the DBA in a typical installation will communicate with the application development/support staff to obtain assurance that this requirement is met.",
|
|
158
|
+
"severity": "medium"
|
|
159
|
+
},
|
|
160
|
+
{
|
|
161
|
+
"id": "V-60671",
|
|
162
|
+
"title": "In a database owned by a login not having administrative privileges at the instance level, the database property TRUSTWORTHY must be OFF unless required and authorized.",
|
|
163
|
+
"description": "SQL Server's fixed (built-in) server roles, especially [sysadmin], have powerful capabilities that could cause great harm if misused, so their use must be tightly controlled.\n\nThe SQL Server instance uses each database's TRUSTWORTHY property to guard against tampering that could enable unwarranted privilege escalation. When TRUSTWORTHY is 0/False/Off, SQL Server prevents the database from accessing resources in other databases. When TRUSTWORTHY is 1/True/On, SQL Server permits access to other databases (subject to other protections). SQL Server sets TRUSTWORTHY OFF when it creates a new database. SQL Server forces TRUSTWORTHY OFF, irrespective of its prior value, when an existing database is attached to it, to address the possibility that an adversary may have tampered with the database, introducing malicious code. To set TRUSTWORTHY ON, an account with the [sysadmin] role must issue an ALTER DATABASE command.\n\nAlthough SQL Server itself treats this property conservatively, application installer programs may set TRUSTWORTHY ON and leave it on. This provides an opportunity for misuse.\n\nWhen TRUSTWORTHY is ON, users of the database can take advantage of the database owner's privileges, by impersonating the owner. This can have particularly serious consequences if the database owner is the [sa] login (which may have been renamed in accordance with SQL2-00-010200, and disabled in accordance with SQL2-00-017100, but nonetheless can be invoked in an EXECUTE AS USER = 'dbo' statement, or CREATE PROCEDURE ... WITH EXECUTE AS OWNER ...). The [sa] login cannot be removed from the [sysadmin] role. The user impersonating [sa] - or another [sysadmin] account - is then able to perform administrative actions across all databases under the instance, including making any himself or any other login a member of [sysadmin].\n\nMost of the other fixed server roles could be similarly abused.\n\nTherefore, TRUSTWORTHY must not be used on databases owned by logins that are members of the fixed server roles. Further, if TRUSTWORTHY is to be used for any other database, the need must be documented and approved.\n\nThe system database [msdb] is an exception: it is required to be TRUSTWORTHY.",
|
|
164
|
+
"severity": "medium"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "V-60781",
|
|
168
|
+
"title": "In a database owned by [sa], or by any other login having administrative privileges at the instance level, the database property TRUSTWORTHY must be OFF.",
|
|
169
|
+
"description": "SQL Server's fixed (built-in) server roles, especially [sysadmin], have powerful capabilities that could cause great harm if misused, so their use must be tightly controlled.\n\nThe SQL Server instance uses each database's TRUSTWORTHY property to guard against tampering that could enable unwarranted privilege escalation. When TRUSTWORTHY is 0/False/Off, SQL Server prevents the database from accessing resources in other databases. When TRUSTWORTHY is 1/True/On, SQL Server permits access to other databases (subject to other protections). SQL Server sets TRUSTWORTHY OFF when it creates a new database. SQL Server forces TRUSTWORTHY OFF, irrespective of its prior value, when an existing database is attached to it, to address the possibility that an adversary may have tampered with the database, introducing malicious code. To set TRUSTWORTHY ON, an account with the [sysadmin] role must issue an ALTER DATABASE command.\n\nAlthough SQL Server itself treats this property conservatively, application installer programs may set TRUSTWORTHY ON and leave it on. This provides an opportunity for misuse.\n\nWhen TRUSTWORTHY is ON, users of the database can take advantage of the database owner's privileges, by impersonating the owner. This can have particularly serious consequences if the database owner is the [sa] login (which may have been renamed in accordance with SQL2-00-010200, and disabled in accordance with SQL2-00-017100, but nonetheless can be invoked in an EXECUTE AS USER = 'dbo' statement, or CREATE PROCEDURE ... WITH EXECUTE AS OWNER ...). The [sa] login cannot be removed from the [sysadmin] role. The user impersonating [sa] - or another [sysadmin] account - is then able to perform administrative actions across all databases under the instance, including making any himself or any other login a member of [sysadmin].\n\nMost of the other fixed server roles could be similarly abused.\n\nTherefore, TRUSTWORTHY must not be used on databases owned by logins that are members of the fixed server roles. Further, if TRUSTWORTHY is to be used for any other database, the need must be documented and approved.\n\nThe system database [msdb] is an exception: it is required to be TRUSTWORTHY.",
|
|
170
|
+
"severity": "medium"
|
|
171
|
+
},
|
|
172
|
+
{
|
|
173
|
+
"id": "V-70627",
|
|
174
|
+
"title": "Appropriate staff must be alerted when the amount of storage space used by the SQL Server transaction log file(s) exceeds an organization-defined value.",
|
|
175
|
+
"description": "It is important for the appropriate personnel to be aware if the system is at risk of failing to record transaction log data. The transaction log is the heart of a SQL Server database. If it fails, processing will stop. It must always have enough available storage space to cope with peak load. Administrators must be warned about abnormally high space consumption soon enough to take corrective action before all space is used up.",
|
|
176
|
+
"severity": "low"
|
|
177
|
+
}
|
|
178
|
+
]
|
|
179
|
+
}
|
|
@@ -0,0 +1,929 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_microsoft_sql_server_2012_database_instance",
|
|
3
|
+
"date": "2018-02-27",
|
|
4
|
+
"description": "The Microsoft SQL Server 2012 Database Instance Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
|
|
5
|
+
"title": "Microsoft SQL Server 2012 Database Instance Security Technical Implementation Guide",
|
|
6
|
+
"version": "1",
|
|
7
|
+
"item_syntax": "^\\w-\\d+$",
|
|
8
|
+
"section_separator": null,
|
|
9
|
+
"items": [
|
|
10
|
+
{
|
|
11
|
+
"id": "V-40905",
|
|
12
|
+
"title": "The system must activate an alarm and/or automatically shut SQL Server down if a failure is detected in its software components. ",
|
|
13
|
+
"description": "Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining system security fail to function, then SQL Server could continue operating in an unsecure state. The organization must be prepared, and the system must be configured, to send an alarm for such conditions and/or automatically shut SQL Server down.\n\nIf appropriate actions are not taken when component failures occur, a denial of service condition may occur. Appropriate actions can include conducting a graceful application shutdown to avoid losing information.\n\nFor the purposes of this requirement, \"component\" may be interpreted as meaning any of the Windows services that comprise a SQL Server instance. \"The system\" encompasses SQL Server itself, the Windows operating system, and any monitoring/management tools used to control the server.",
|
|
14
|
+
"severity": "medium"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"id": "V-40906",
|
|
18
|
+
"title": "SQL Server must identify potential security-relevant error conditions.",
|
|
19
|
+
"description": "The structure and content of SQL Server 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 SQL Server they may be overlooked by the personnel responsible for addressing them.",
|
|
20
|
+
"severity": "medium"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "V-40907",
|
|
24
|
+
"title": "SQL Server must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission.",
|
|
25
|
+
"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), VPN, or IPSEC tunnel. \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.",
|
|
26
|
+
"severity": "high"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "V-40908",
|
|
30
|
+
"title": "SQL Server must ensure, if Database Availability Groups are being used and there is a server failure, that none of the potential failover servers would suffer from resource exhaustion.",
|
|
31
|
+
"description": "SQL Server has a feature called 'Availability Group' which provides automatic failover from a primary SQL Server to a secondary server. This concept is not new, but because SQL Server does warn that if the secondary SQL Server is not dedicated 100% to being a backup server, that \"resource exhaustion\" may be an issue if there is some load balancing going on.\n\nIf the primary SQL Server has a backup/secondary server that is dedicated 100% to the primary server's process, this is not a finding. If, however, the processing of the primary SQL Server is loaded to a secondary server that is already partly resourced to process something other than that of the primary SQL Server responsibility, then there can be load balancing issues.\n\nLoad balancing for the purpose of sharing a secondary/backup SQL Server is often done to share and save on resources.",
|
|
32
|
+
"severity": "medium"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "V-40909",
|
|
36
|
+
"title": "SQL Server must limit the use of resources by priority and not impede the host from servicing processes designated as a higher priority.",
|
|
37
|
+
"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\nSQL Server often runs queries for multiple users at the same time. If lower priority processes are utilizing a disproportionately high amount of database resources, this can severely impact higher priority processes.\n\nEven if SQL Server's utilization is very small and there may seem to be no need to priority protection, often resources grow exponentially and must be implemented as part of an initial deployment.",
|
|
38
|
+
"severity": "low"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "V-40910",
|
|
42
|
+
"title": "SQL Server must isolate security functions from nonsecurity functions by means of separate security domains.",
|
|
43
|
+
"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 nonsecurity 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 nonsecurity functionality is commingled, users who have access to nonsecurity functionality may be able to access security functionality.",
|
|
44
|
+
"severity": "medium"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "V-40912",
|
|
48
|
+
"title": "SQL Server must associate and maintain security labels when exchanging information between systems.",
|
|
49
|
+
"description": "When data is exchanged between information systems, the security attributes associated with said data need to be maintained. \n\nSecurity attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information, typically associated with internal data structures (e.g., records, buffers, files) within the information system and used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nSecurity attributes may be explicitly or implicitly associated with the information contained within the information system. \n\nIf database security labels are not maintained as information moves between systems, handling instructions can be lost and data can be accidentally distributed to unauthorized individuals.",
|
|
50
|
+
"severity": "low"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "V-40913",
|
|
54
|
+
"title": "SQL Server must protect the integrity of publicly available information and SQL Servers configuration from unauthorized Server Roles access.",
|
|
55
|
+
"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. If SQL Server contains publicly available information, though not concerned with confidentiality, SQL Server must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it.\n\nThe user account associated with public access must not have access to the OS or SQL Server configuration information, include read access to schema information.\n\nThis requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.",
|
|
56
|
+
"severity": "medium"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"id": "V-40914",
|
|
60
|
+
"title": "SQL Server must protect the integrity of publicly available information and SQL Servers configuration from unauthorized User Mapping access.",
|
|
61
|
+
"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. If SQL Server contains publicly available information, though not concerned with confidentiality, SQL Server must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it.\n\nThe user account associated with public access must not have access to the OS or SQL Server configuration information, include read access to schema information. This access includes, but is not limited to, SQL Server 'User Mapping' assignments.\n\nSQL Server access to any of the three system databases (master, model, or msdb) is restricted from the publicly available user account, because this would grant more than read-only access to public information. Of the existing user-defined databases, privileges must be checked to allow only read access to publically available data.\n\nThis requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.",
|
|
62
|
+
"severity": "medium"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-40915",
|
|
66
|
+
"title": "SQL Server must protect the integrity of publicly available information and applications.",
|
|
67
|
+
"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. If SQL Server contains publicly available information, though not concerned with confidentiality, SQL Server OS must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it.\n\nThe user account associated with public access must not have access to the OS configuration information. Determine what publicly available user account is being used to access SQL Server and validate that the publicly available user account only has read access to the public data and nothing else.\n\nThe OS level 'Guests' role grants connection access to the server without granting any other privileges. SQL Server configuration settings are used to grant access to the publicly available information, but this control ensures that the OS only is granted connection access to the server.\n\nThis requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.",
|
|
68
|
+
"severity": "medium"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-40916",
|
|
72
|
+
"title": "SQL Server must protect the integrity of publicly available information and SQL Servers configuration from unauthorized Securables access.",
|
|
73
|
+
"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\nSQL Server must be configured to contain publicly available information. Though not concerned with confidentiality, SQL Server must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it. A publicly available user account must not have access to the OS or SQL Server configuration information, including read access to schema information. Determine what publicly available user account is being used to access SQL Server and validate that the publicly available user account only has read access to the public data and nothing else. This read-only access does not include SQL Server 'Securables' assignments.\n\nSQL Server 'Securables' assignments grant the assignee privileges that are beyond read access to data. No public user account must have SQL Server 'Securables' privileges. Any assigned 'Securables' privileges to the public user account must be removed.\n\nLikely the only 'Server roles' assignment for the publicly available user account would be 'public'. The only other 'Server roles' that could be authorized as read-only is a user-defined 'Server role'. It is more likely that read-only access is set up at the user database instance in role(s) specifically set up for this purpose. Assignment to the user database instances are made in the 'User Mapping' highlight within a user's properties.\n\nThis requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.",
|
|
74
|
+
"severity": "medium"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-40917",
|
|
78
|
+
"title": "SQL Server databases in the classified environment, containing classified or sensitive information, must be encrypted using approved cryptography.",
|
|
79
|
+
"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.\n\nNSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as:\n“Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed.\nDeveloped using established NSA business processes and containing NSA approved algorithms are used to protect systems requiring the most stringent protection mechanisms.”\n\nNSA-approved cryptography is required to be used for classified information system processing.\n\nSee FIPS Publication 140-2 and related documents for guidance on approved encryption techniques and certified encryption modules.",
|
|
80
|
+
"severity": "high"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "V-40918",
|
|
84
|
+
"title": "SQL Server must employ NSA-approved cryptography to protect classified information.",
|
|
85
|
+
"description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data.\n\nNSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as:\n“Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed.\nDeveloped using established NSA business processes and containing NSA approved algorithms are used to protect systems requiring the most stringent protection mechanisms.”\n\nNSA-approved cryptography is required to be used for classified information system processing.",
|
|
86
|
+
"severity": "medium"
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "V-40919",
|
|
90
|
+
"title": "SQL Server must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).",
|
|
91
|
+
"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\nThis may be accomplished by a code embedded within the userid, or via a flag or code columns in a table of users, or by some other means. In any case, the user must be individually identified to, and within, SQL Server via a mapping to an individual account and not mapping to a shared account. \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, and other organizations.",
|
|
92
|
+
"severity": "medium"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-40922",
|
|
96
|
+
"title": "SQL Server must enforce password encryption for storage.",
|
|
97
|
+
"description": "SQL Server 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\nPasswords stored in clear text are vulnerable to unauthorized disclosure. Database passwords should always be encoded or encrypted when stored internally or externally to SQL Server.",
|
|
98
|
+
"severity": "medium"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"id": "V-40923",
|
|
102
|
+
"title": "SQL Server must ensure users are authenticated with an individual authenticator prior to using a shared authenticator.",
|
|
103
|
+
"description": "To ensure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated.\n\nA shared authenticator is a generic account used by multiple individuals. Use of a shared authenticator alone does not uniquely identify individual users. An example of a shared authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'sa' account, or a 'helpdesk' account.\n\nLegitimate use of shared accounts includes, for example, connection pooling. Since this is insufficient to ensure non-repudiation, such shared accounts should be kept \"under the covers,\" be inaccessible directly to end users, be invoked only after successful individual authentication, be communicated to the DBMS by the application, and be recorded in all relevant audit contexts.\n\n(Shared accounts should not be confused with Windows groups, which are used in role-based access control.)",
|
|
104
|
+
"severity": "medium"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"id": "V-40924",
|
|
108
|
+
"title": "SQL Server must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).",
|
|
109
|
+
"description": "To ensure accountability and prevent unauthorized SQL Server 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 SQL Server without identification or authentication.",
|
|
110
|
+
"severity": "medium"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-40925",
|
|
114
|
+
"title": "SQL Server software libraries must be periodically backed up.",
|
|
115
|
+
"description": "SQL Server backups are 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 organization-defined recovery time and recovery point objectives.\n\nSQL Server 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 SQL Server operations.\n\nA mixture of full and incremental server-level backups by a third-party tool that backs up those software library directories would satisfy this requirement.",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-40926",
|
|
120
|
+
"title": "SQL Server backups of system-level information per organization-defined frequency must be performed that is consistent with recovery time and recovery point objectives.",
|
|
121
|
+
"description": "SQL Server backups are 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 organizationally defined recovery time and recovery point objectives.\n\nSQL Server depends upon the availability and integrity of its system-level information. Without backups, compromise or loss of system-level information can prevent a successful recovery of SQL Server operations. If SQL Server system-level information is not backed up regularly this risks the loss of SQL Server data in the event of a system failure.\n\nA mixture of full and incrementally server level backups that backup the system-level information would satisfy this requirement.",
|
|
122
|
+
"severity": "medium"
|
|
123
|
+
},
|
|
124
|
+
{
|
|
125
|
+
"id": "V-40927",
|
|
126
|
+
"title": "SQL Server backup and restoration files must be protected from unauthorized access.",
|
|
127
|
+
"description": "SQL Server backups are 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 SQL Server backup or restoration files may lead to not only the loss of data, but also the unauthorized access to sensitive data.\n\nSQL Server can maintain local copies of critical control files to provide transparent or easy recovery from hard disk loss or other interruptions to database operation.\n\nBackup files, both local to the SQL Server machine and not local to the machine, 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.",
|
|
128
|
+
"severity": "medium"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"id": "V-40928",
|
|
132
|
+
"title": "SQL Server recovery procedures that are documented must be implemented and periodically tested.",
|
|
133
|
+
"description": "SQL Server backups are a critical step in maintaining data assurance and availability.\n\nUser-level information is data generated by the 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 SQL Server 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.\n\nPart of an overall backup and recovery methodology includes regular recovery testing. This is very important and helps to expose any issue in the recovery process (e.g., hardware, procedures, etc.).",
|
|
134
|
+
"severity": "medium"
|
|
135
|
+
},
|
|
136
|
+
{
|
|
137
|
+
"id": "V-40929",
|
|
138
|
+
"title": "SQL Server backup procedures must be defined, documented, and implemented.",
|
|
139
|
+
"description": "SQL Server backup is a critical step in maintaining data assurance and availability.\n\nUser-level information is data generated by the 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 SQL Server or within any other storage media.\n\nApplications performing backups must be configured to back up user-level information per the DoD-defined frequency.\n\nSQL Server Database backups provide the required means to restore databases after compromise or loss. Backups help reduce the vulnerability to unauthorized access or hardware loss.",
|
|
140
|
+
"severity": "medium"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-40930",
|
|
144
|
+
"title": "SQL Server user-level information must be backed up based on a defined frequency.",
|
|
145
|
+
"description": "SQL Server backups are 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 SQL Server 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.",
|
|
146
|
+
"severity": "medium"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-40932",
|
|
150
|
+
"title": "SQL Server must recover to a known state that is verifiable.",
|
|
151
|
+
"description": "Application recovery and reconstitution constitutes executing an information system contingency plan comprising activities that restore essential missions and business functions.\n\nSQL Server utilizes transaction-based processing and is a good example of information systems that are transaction-based. Transaction rollback and transaction journaling are examples of mechanisms supporting transaction recovery.\n\nSQL Server 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. SQL Server mechanisms must be configured to protect all files that could compromise the system or its data during a SQL Server recovery.",
|
|
152
|
+
"severity": "high"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "V-40933",
|
|
156
|
+
"title": "SQL Server must support the organizational requirements to specifically prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services.",
|
|
157
|
+
"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 over limiting the services provided by any one component. \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.\n\nFor detailed guidance on Ports, Protocols, and Services Management (PPSM), refer to the PPSM section of the Information Assurance Support Environment (IASE) web site, at http://iase.disa.mil/ppsm/Pages/index.aspx.",
|
|
158
|
+
"severity": "medium"
|
|
159
|
+
},
|
|
160
|
+
{
|
|
161
|
+
"id": "V-40934",
|
|
162
|
+
"title": "SQL Server must specifically prohibit or restrict the use of unauthorized functions and services in each instance.",
|
|
163
|
+
"description": "SQL Server is 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 over limiting the services provided by any one component.",
|
|
164
|
+
"severity": "medium"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "V-40935",
|
|
168
|
+
"title": "Access to xp_cmdshell must be disabled.",
|
|
169
|
+
"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 every mission, but which cannot be disabled. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDBMSs 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.\n\nThe xp_cmdshell extended stored procedure allows execution of host executables outside the controls of database access permissions. This access may be exploited by malicious users who have compromised the integrity of the SQL Server database process to control the host operating system to perpetrate additional malicious activity.",
|
|
170
|
+
"severity": "medium"
|
|
171
|
+
},
|
|
172
|
+
{
|
|
173
|
+
"id": "V-40936",
|
|
174
|
+
"title": "SQL Server default account sa must be disabled.",
|
|
175
|
+
"description": "SQL Server's 'sa' account has special privileges required to administer the database. The 'sa' account is a well-known SQL Server account and is likely to be targeted by attackers and thus more prone to providing unauthorized access to the database.\n\nThis 'sa' default account is administrative and could lead to catastrophic consequences, including the complete loss of control over SQL Server.\n\nIf the 'sa' default account is not disabled, an attacker might be able to gain access through the account. SQL Server by default, at installation, disables the 'sa' account.\n\nSome applications that run on SQL Server require the 'sa' account to be enabled in order for the application to function properly. These applications that require the 'sa' account to be enabled are usually legacy systems.",
|
|
176
|
+
"severity": "medium"
|
|
177
|
+
},
|
|
178
|
+
{
|
|
179
|
+
"id": "V-40937",
|
|
180
|
+
"title": "Unused database components that are integrated in SQL Server and cannot be uninstalled must be disabled.",
|
|
181
|
+
"description": "SQL Server is 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 every mission, but which cannot be disabled.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused and unnecessary SQL Server components increase the number of available attack vectors to SQL Server 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.",
|
|
182
|
+
"severity": "medium"
|
|
183
|
+
},
|
|
184
|
+
{
|
|
185
|
+
"id": "V-40938",
|
|
186
|
+
"title": "SQL Server must have the SQL Server Analysis Service (SSAS) software component removed from SQL Server if SSAS is unused.",
|
|
187
|
+
"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 every mission, yet cannot be disabled. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused and unnecessary SQL Server components increase the number of available attack vectors to SQL Server by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced.\n\nSQL Server must have the SQL Server Analysis Service (SSAS) software component removed from SQL Server if SSAS is unused.",
|
|
188
|
+
"severity": "medium"
|
|
189
|
+
},
|
|
190
|
+
{
|
|
191
|
+
"id": "V-40939",
|
|
192
|
+
"title": "SQL Server must have the SQL Server Integrated Services (SSIS) software component removed from SQL Server if SSIS is unused.",
|
|
193
|
+
"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 every mission, yet cannot be disabled.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused and unnecessary SQL Server components increase the number of available attack vectors to SQL Server by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced.\n\nSQL Server must have the SQL Server Integrated Services (SSIS) software component removed from SQL Server if SSIS is unused.",
|
|
194
|
+
"severity": "medium"
|
|
195
|
+
},
|
|
196
|
+
{
|
|
197
|
+
"id": "V-40940",
|
|
198
|
+
"title": "SQL Server must have the SQL Server Reporting Service (SSRS) software component removed from SQL Server if SSRS is unused.",
|
|
199
|
+
"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 every mission, yet cannot be disabled.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused and unnecessary SQL Server components increase the number of available attack vectors to SQL Server by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced.\n\nSQL Server must have the SQL Server Reporting Service (SSRS) software component removed from SQL Server if SSRS is unused.",
|
|
200
|
+
"severity": "medium"
|
|
201
|
+
},
|
|
202
|
+
{
|
|
203
|
+
"id": "V-40941",
|
|
204
|
+
"title": "SQL Server must have the SQL Server Data Tools (SSDT) software component removed from SQL Server if SSDT is unused.",
|
|
205
|
+
"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 every mission, yet cannot be disabled. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\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.\n\n\nSQL Server must have the SQL Server Data Tools (SSDT) software component removed from SQL Server if SSDT is unused.",
|
|
206
|
+
"severity": "high"
|
|
207
|
+
},
|
|
208
|
+
{
|
|
209
|
+
"id": "V-40942",
|
|
210
|
+
"title": "SQL Server must have the publicly available AdventureWorks sample database removed.",
|
|
211
|
+
"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 and providing a wide array of functionality not required for every mission, but which cannot be disabled.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities. Even though the very popular \"AdventureWorks\" database is no longer available by default, it introduces a vulnerability to SQL Server and must be removed.\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 SQL Server and the OS.",
|
|
212
|
+
"severity": "medium"
|
|
213
|
+
},
|
|
214
|
+
{
|
|
215
|
+
"id": "V-40943",
|
|
216
|
+
"title": "SQL Server must have the publicly available NorthWind sample database removed.",
|
|
217
|
+
"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 and providing a wide array of functionality not required for every mission, but which cannot be disabled.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities. Even though the very popular \"NorthWind\" database is no longer available by default, it introduces a vulnerability to SQL Server and must be removed.\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 SQL Server and the OS.",
|
|
218
|
+
"severity": "medium"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "V-40944",
|
|
222
|
+
"title": "The OS must limit privileges to change SQL Server software resident within software libraries (including privileged programs).",
|
|
223
|
+
"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 can potentially have significant effects on the overall security of the system.\n\nIf any user were allowed 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. The DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in compromised installations. This may in turn jeopardize data stored in the DBMS and/or operation of the host system.\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\nOf particular note in this context is that any software installed for auditing and/or audit file management must be protected and monitored.",
|
|
224
|
+
"severity": "medium"
|
|
225
|
+
},
|
|
226
|
+
{
|
|
227
|
+
"id": "V-40945",
|
|
228
|
+
"title": "Vendor-supported software and patches must be evaluated and patched against newly found vulnerabilities.",
|
|
229
|
+
"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\nAny time 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\nIf SQL Server were no longer supported, no patches from Microsoft would address newly discovered security vulnerabilities. Unpatched software is vulnerable to attack.",
|
|
230
|
+
"severity": "high"
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "V-40946",
|
|
234
|
+
"title": "Database software directories, including SQL Server configuration files, must be stored in dedicated directories, separate from the host OS and other applications.",
|
|
235
|
+
"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 of one application can lead to an exploit of other applications sharing the same security context. For example, an exploit of 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 other applications’ database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.",
|
|
236
|
+
"severity": "low"
|
|
237
|
+
},
|
|
238
|
+
{
|
|
239
|
+
"id": "V-40947",
|
|
240
|
+
"title": "SQL Server software installation account(s) must be restricted to authorized users.",
|
|
241
|
+
"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 dependant. 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 SQL Server 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.",
|
|
242
|
+
"severity": "medium"
|
|
243
|
+
},
|
|
244
|
+
{
|
|
245
|
+
"id": "V-40948",
|
|
246
|
+
"title": "Software, applications, and configuration files that are part of, or related to, the SQL Server 2012 installation must be monitored to discover unauthorized changes.",
|
|
247
|
+
"description": "When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of applications and tools related to SQL Server can potentially have significant effects on the overall security of the system. Only qualified and authorized individuals shall be allowed to obtain access to components related to SQL Server for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the software libraries or configuration can lead to unauthorized or compromised installations.\n\nOf particular note in this context is that any software installed for auditing and/or audit file management must be protected and monitored.\n",
|
|
248
|
+
"severity": "high"
|
|
249
|
+
},
|
|
250
|
+
{
|
|
251
|
+
"id": "V-40949",
|
|
252
|
+
"title": "SQL Server must monitor for security-relevant configuration settings to discover unauthorized changes.",
|
|
253
|
+
"description": "When dealing with change control issues, it should be noted, any changes to security-relevant configuration settings of SQL Server can potentially have significant effects on the overall security of the system.\n\nIf SQL Server were to allow any user to make changes to configuration settings, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement is contingent upon the configuration of SQL Server's hosted application and the security-relevant configuration settings of SQL Server.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to these security-relevant configuration settings for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to SQL Server software libraries or configuration can lead to unauthorized or compromised installations.",
|
|
254
|
+
"severity": "medium"
|
|
255
|
+
},
|
|
256
|
+
{
|
|
257
|
+
"id": "V-40950",
|
|
258
|
+
"title": "SQL Server must support the employment of automated mechanisms supporting the auditing of the enforcement actions.",
|
|
259
|
+
"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\nAccordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. \n\nAccess restrictions for change also include software libraries. \n\nExamples of access restrictions include: physical access controls (such as locks and access cards), logical access controls (such as ACLs), automated auditing (logging) of logical access, workflow automation, media libraries, abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (e.g., changes occur only during specified times, making unauthorized changes outside the window easy to discover). \n\nThis requirement focuses on the auditing aspect of the protections.",
|
|
260
|
+
"severity": "medium"
|
|
261
|
+
},
|
|
262
|
+
{
|
|
263
|
+
"id": "V-40951",
|
|
264
|
+
"title": "SQL Server must support the organizational requirement to employ automated mechanisms for enforcing access restrictions.",
|
|
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 potentially have significant effects on the overall security of the system.\n\nOnly qualified and authorized individuals are allowed to obtain access to information system components for the purposes of initiating changes, upgrades, and modifications.\n\nAccess restrictions for change also include application software libraries.\n\nExamples of access restrictions include: physical and logical access controls, workflow automation, media libraries, abstract layers (i.e., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (i.e., changes occur only during specified times, making unauthorized changes outside the window easy to discover).\n\nMultiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit of one application can lead to an exploit of other applications sharing the same security context. For example, an exploit of 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 other applications’ database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.",
|
|
266
|
+
"severity": "medium"
|
|
267
|
+
},
|
|
268
|
+
{
|
|
269
|
+
"id": "V-40952",
|
|
270
|
+
"title": "SQL Server must protect audit information from unauthorized deletion.",
|
|
271
|
+
"description": "If audit data were to become compromised, competent forensic analysis and discovery of the true source of potentially malicious system activity would be 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 to make 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 or unauthorized modification of sensitive data stored in the database.",
|
|
272
|
+
"severity": "low"
|
|
273
|
+
},
|
|
274
|
+
{
|
|
275
|
+
"id": "V-40953",
|
|
276
|
+
"title": "SQL Server must protect audit information from unauthorized modification.",
|
|
277
|
+
"description": "If audit data were to become compromised, competent forensic analysis and discovery of the true source of potentially malicious system activity would be 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 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 or unauthorized modification of sensitive data stored in the database.",
|
|
278
|
+
"severity": "low"
|
|
279
|
+
},
|
|
280
|
+
{
|
|
281
|
+
"id": "V-41016",
|
|
282
|
+
"title": "SQL Server must protect audit information from any type of unauthorized access.",
|
|
283
|
+
"description": "If audit data were to become compromised, competent forensic analysis and discovery of the true source of potentially malicious system activity would be 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\nSQL Server and third-party tools are examples of applications that are easily able to view and manipulate audit file data. Additionally, applications with user interfaces to audit records should not allow unfettered manipulation of, or access to, those records via any application. If an application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access.\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\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.",
|
|
284
|
+
"severity": "medium"
|
|
285
|
+
},
|
|
286
|
+
{
|
|
287
|
+
"id": "V-41017",
|
|
288
|
+
"title": "SQL Server must protect the audit records generated as a result of remote access to privileged accounts and by the execution of privileged functions.",
|
|
289
|
+
"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 that 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, they 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.",
|
|
290
|
+
"severity": "medium"
|
|
291
|
+
},
|
|
292
|
+
{
|
|
293
|
+
"id": "V-41021",
|
|
294
|
+
"title": "SQL Server must audit attempts to bypass access controls.",
|
|
295
|
+
"description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes: time stamps, 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. In SQL Server's case, this is a combination of the standard audit trace, as well as the operating system logs. Only the SQL Server logs are validated for this check, as the other part is dependent upon the operating system.",
|
|
296
|
+
"severity": "medium"
|
|
297
|
+
},
|
|
298
|
+
{
|
|
299
|
+
"id": "V-41022",
|
|
300
|
+
"title": "SQL Server must shutdown immediately in the event of an audit failure, unless an alternative audit capability exists.",
|
|
301
|
+
"description": "It is critical that, when SQL Server is at risk of failing to process audit logs as required, it takes action to mitigate the failure. If the system were to continue processing without auditing enabled, actions could be taken on the system that could not be tracked and recorded for later forensic analysis.\n\nIn many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage. This places the onus on the DBMS to detect and take actions.\n\nA failure of SQL Server auditing will result in either the database continuing to function without auditing, or the halting of SQL Server operations. In this case, the database must cease processing immediately in order to not allow unlogged transaction to occur.\n\nNote that trace file rollover does not count as an audit failure, provided that the system is also configured to shut down when it runs out of space. Trace file rollover can be a useful technique for breaking the log into manageable pieces, for archiving, or for transfer to a log management system.",
|
|
302
|
+
"severity": "medium"
|
|
303
|
+
},
|
|
304
|
+
{
|
|
305
|
+
"id": "V-41023",
|
|
306
|
+
"title": "SQL Server 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.",
|
|
307
|
+
"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 will 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 a log repository or the OS when a designated log directory is nearing capacity.",
|
|
308
|
+
"severity": "low"
|
|
309
|
+
},
|
|
310
|
+
{
|
|
311
|
+
"id": "V-41024",
|
|
312
|
+
"title": "SQL Server auditing configuration maximum number of files must be configured to reduce the likelihood of storage capacity being exceeded, while meeting organization-defined auditing requirements.",
|
|
313
|
+
"description": "Configure SQL Server during the installation and/or configuration process to determine if adequate storage capacity has been allocated for audit logs.\n\nIf SQL Server audit logs that are being generated exceed the amount of space reserved for those logs, the system may shutdown or take other measures to stop processing in order to protect transactions from continuing unlogged.\n\nAfter the initial setup of SQL Server audit log configuration, it is best to check the available space frequently until the maximum number of files has been reached. Checking the available space can help determine the balance of online audit data with space required.",
|
|
314
|
+
"severity": "medium"
|
|
315
|
+
},
|
|
316
|
+
{
|
|
317
|
+
"id": "V-41025",
|
|
318
|
+
"title": "SQL Server auditing configuration maximum file size must be configured to reduce the likelihood of storage capacity being exceeded, while meeting organization-defined auditing requirements.",
|
|
319
|
+
"description": "Configure SQL Server during the installation and/or configuration process to determine if adequate storage capacity has been allocated for audit logs.\n\nIf SQL Server audit logs that are being generated exceed the amount of space reserved for those logs, the system may shutdown or take other measures to stop processing in order to protect transactions from continuing unlogged.\n\nAfter the initial setup of SQL Server audit log configuration, it is best to check the available space until the maximum number of files has been reached. SQL will overwrite the oldest files when the max_files parameter has been exceeded. Care must be taken to ensure that this does not happen, or data will be lost. Therefore, the combination of max_size and max_files must be monitored to ensure that overwriting does not occur. This must also coincide with the backup process of off-loading the files.",
|
|
320
|
+
"severity": "medium"
|
|
321
|
+
},
|
|
322
|
+
{
|
|
323
|
+
"id": "V-41026",
|
|
324
|
+
"title": "SQL Server must have allocated audit record storage capacity to meet the organization-defined requirements for saving audit record information.",
|
|
325
|
+
"description": "SQL Server does not have the ability to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, SQL Server 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. SQL Server is not able to send out notice based on adequate storage capacity allocated for the audit logs.",
|
|
326
|
+
"severity": "medium"
|
|
327
|
+
},
|
|
328
|
+
{
|
|
329
|
+
"id": "V-41027",
|
|
330
|
+
"title": "SQL Server must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.",
|
|
331
|
+
"description": "SQL Server auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nSQL Server does have a means available to add organizationally defined additional, more detailed information in the audit event records. These events may be identified by type, location, or subject. An example of more detailed information the organization may require in audit records could be the name of the application where the request is coming from.\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.",
|
|
332
|
+
"severity": "medium"
|
|
333
|
+
},
|
|
334
|
+
{
|
|
335
|
+
"id": "V-41028",
|
|
336
|
+
"title": "SQL Server must produce audit records containing sufficient information to establish the identity of any user/subject associated with the event.",
|
|
337
|
+
"description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes: time stamps, 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.",
|
|
338
|
+
"severity": "medium"
|
|
339
|
+
},
|
|
340
|
+
{
|
|
341
|
+
"id": "V-41029",
|
|
342
|
+
"title": "SQL Server must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.",
|
|
343
|
+
"description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nSQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know the outcome of attempted actions. This requires specific information regarding the outcome of the action or event that the audit record is referring to. If outcome status information is not recorded and stored with the audit record, the record itself is of very limited use.\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.\n\nIf auditing is enabled, SQL Server does capture the outcome status-specific information in all audit records.",
|
|
344
|
+
"severity": "medium"
|
|
345
|
+
},
|
|
346
|
+
{
|
|
347
|
+
"id": "V-41030",
|
|
348
|
+
"title": "SQL Server must produce audit records containing sufficient information to establish the sources (origins) of the events.",
|
|
349
|
+
"description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nSQL Server 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 what actions. This requires specific information regarding the source of the event an audit record is referring to. If the source of the event information is not recorded and stored with the audit record, the record itself is of very limited use.\n\nThe source of the event can be a user account and sometimes a system account when timed jobs are run. Without information establishing the source of activity, the value of audit records from a forensics perspective is questionable. If auditing is enabled, SQL Server does capture the source of the event-specific information in all audit records.",
|
|
350
|
+
"severity": "medium"
|
|
351
|
+
},
|
|
352
|
+
{
|
|
353
|
+
"id": "V-41031",
|
|
354
|
+
"title": "SQL Server must produce audit records containing sufficient information to establish where the events occurred.",
|
|
355
|
+
"description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nSQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly where actions were performed. This requires specific information regarding the event location an audit record is referring to. If event location information is not recorded and stored with the audit record, the record itself is of very limited use.\n\nAn event location can be a database instance, table, column, row, etc. Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered. If auditing is enabled, SQL Server does capture the event location-specific information in all audit records.",
|
|
356
|
+
"severity": "medium"
|
|
357
|
+
},
|
|
358
|
+
{
|
|
359
|
+
"id": "V-41032",
|
|
360
|
+
"title": "SQL Server must produce audit records containing sufficient information to establish when (date and time) the events occurred.",
|
|
361
|
+
"description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nSQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly when actions were performed. This requires specific information regarding 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.\n\nIf auditing is enabled, SQL Server does capture the date and time-specific information in all audit records.",
|
|
362
|
+
"severity": "medium"
|
|
363
|
+
},
|
|
364
|
+
{
|
|
365
|
+
"id": "V-41033",
|
|
366
|
+
"title": "SQL Server must produce audit records containing sufficient information to establish what type of events occurred.",
|
|
367
|
+
"description": "Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nSQL Server is capable of a range of actions on data stored within the database. It is 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.\n\nIf auditing is enabled, SQL Server does capture the event type-specific information in all audit records.",
|
|
368
|
+
"severity": "medium"
|
|
369
|
+
},
|
|
370
|
+
{
|
|
371
|
+
"id": "V-41034",
|
|
372
|
+
"title": "SQL Server must protect against an individual using a shared account from falsely denying having performed a particular action.",
|
|
373
|
+
"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\nUse of shared accounts 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 (as in connection pooling).\n\nWhen shared accounts are utilized without another means of identifying individual users, users may deny having performed a particular action.\n\n(Shared accounts should not be confused with Windows groups, which are used in role-based access control.)",
|
|
374
|
+
"severity": "low"
|
|
375
|
+
},
|
|
376
|
+
{
|
|
377
|
+
"id": "V-41035",
|
|
378
|
+
"title": "SQL Server must generate audit records for the DoD-selected list of auditable events.",
|
|
379
|
+
"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, time stamps, 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 SQL Server 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.",
|
|
380
|
+
"severity": "medium"
|
|
381
|
+
},
|
|
382
|
+
{
|
|
383
|
+
"id": "V-41036",
|
|
384
|
+
"title": "SQL Server must be configured to use Windows Integrated Security.",
|
|
385
|
+
"description": "SQL Server Authentication does not provide for many of the authentication requirements of the DoD. In some cases workarounds are present, but the authentication is not as robust and does not provide needed functionality. Without that functionality, SQL Server is vulnerable to authentication attacks. Consideration must be given to the placement of SQL server inside a forest to ensure evaluation of risk within the environment is considered. Risk includes introduction of risk to SQL Server from other applications or workstations as well as risk from introduction of SQL server itself into an established environment.\n\nThere may be situations where SQL Server Authentication must remain enabled, because of constraints imposed by a third-party application. In such a case, document the constraint in the system security plan, and obtain signed approval.",
|
|
386
|
+
"severity": "medium"
|
|
387
|
+
},
|
|
388
|
+
{
|
|
389
|
+
"id": "V-41037",
|
|
390
|
+
"title": "SQL Server default account sa must have its name changed.",
|
|
391
|
+
"description": "SQL Server's 'sa' account has special privileges required to administer the database. The 'sa' account is a well-known SQL Server account name and is likely to be targeted by attackers, and is thus more prone to providing unauthorized access to the database.\n\nSince the SQL Server 'sa' is administrative in nature, the compromise of a default account can have catastrophic consequences, including the complete loss of control over SQL Server. Since SQL Server needs for this account to exist and it should not be removed, one way to mitigate this risk is to change the 'sa' account name.",
|
|
392
|
+
"severity": "low"
|
|
393
|
+
},
|
|
394
|
+
{
|
|
395
|
+
"id": "V-41038",
|
|
396
|
+
"title": "Use of the SQL Server software installation account must be restricted to SQL Server software installation.",
|
|
397
|
+
"description": "This requirement is intended to limit exposure due to operating from within a privileged account. SQL Server does support the organizational requirement that users of information system accounts with access to an organization-defined list of security functions or security-relevant information use non-privileged accounts and 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 SQL Server installation account requires privileges not required for SQL Server 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.",
|
|
398
|
+
"severity": "medium"
|
|
399
|
+
},
|
|
400
|
+
{
|
|
401
|
+
"id": "V-41039",
|
|
402
|
+
"title": "DBA OS or domain accounts must be granted only those host system privileges necessary for the administration of SQL Server.",
|
|
403
|
+
"description": "SQL Server DBAs, if assigned excessive OS privileges, could perform actions that could endanger the information system or hide evidence of malicious activity.\n\nThis requirement is intended to limit exposure due to operating from within a privileged account or role. The check and fix are based on the assumption that Role-Based Access Control (RBAC) is in effect, as mandated by other STIG requirements. They further assume that, as mandated elsewhere, the privileged accounts discussed here are distinct from the accounts used by the same people when not performing privileged functions.",
|
|
404
|
+
"severity": "medium"
|
|
405
|
+
},
|
|
406
|
+
{
|
|
407
|
+
"id": "V-41040",
|
|
408
|
+
"title": "OS and domain accounts utilized to run external procedures called by SQL Server must have limited privileges.",
|
|
409
|
+
"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 an organization-defined list 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 misassignment 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 by SQL Server may be executed under OS or domain accounts with unnecessary privileges. This can lead to unauthorized access to OS resources and compromise of the OS, SQL Server, or any other services provided by the host platform.",
|
|
410
|
+
"severity": "medium"
|
|
411
|
+
},
|
|
412
|
+
{
|
|
413
|
+
"id": "V-41041",
|
|
414
|
+
"title": "SQL Server DBA roles must not be assigned excessive or unauthorized privileges.",
|
|
415
|
+
"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, SQL Server does support organizational requirements that users of information system accounts, or roles, with access to an organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nSQL Server provides access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged. DBAs, if assigned excessive privileges, could perform actions that endanger the information system or hide evidence of malicious activity.",
|
|
416
|
+
"severity": "medium"
|
|
417
|
+
},
|
|
418
|
+
{
|
|
419
|
+
"id": "V-41042",
|
|
420
|
+
"title": "All use of privileged accounts must be audited.",
|
|
421
|
+
"description": "This is intended to limit exposure, by making it possible to trace any unauthorized access to other data or functionality by a privileged user account or role that has permissions on security functions or security-relevant information.",
|
|
422
|
+
"severity": "medium"
|
|
423
|
+
},
|
|
424
|
+
{
|
|
425
|
+
"id": "V-41043",
|
|
426
|
+
"title": "Administrators must utilize a separate, distinct administrative account when performing administrative activities, accessing database security functions, or accessing security-relevant information within SQL Server.",
|
|
427
|
+
"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, SQL Server does support organizational requirements that users of information system accounts, or roles, with access to an organization-defined list 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, SQL Server could be subject to unauthorized changes of settings or data, which a standard user would not normally have access to outside of an authorized maintenance session. Often, administrator accounts have a unique prefix to help with identification. These accounts are located within SQL Server and may only provide access to one database instance or a limited number of database objects.",
|
|
428
|
+
"severity": "medium"
|
|
429
|
+
},
|
|
430
|
+
{
|
|
431
|
+
"id": "V-41044",
|
|
432
|
+
"title": "SQL Server must restrict access to system tables, other configuration information, and metadata to DBAs and other authorized users.",
|
|
433
|
+
"description": "The principle of Least Privilege must be applied to the ability of users to access system tables, system management information, other configuration information, and metadata. Unauthorized access to this data could result in unauthorized changes to database objects, access controls, or SQL Server configuration. Only database administrators and other authorized users must be allowed such access.\n\nTo aid in tracking and administering such permissions, individual logins must not be directly granted permissions or built-in server roles. Instead, user-defined server roles must be created, with the permissions and built-in server roles granted to them; the individual logins must be assigned to the appropriate user-defined server roles.\n\nThe built-in server role \"sysadmin\" is a partial exception. This cannot be granted to a user-defined role, only to a login account. Most (not necessarily all) database administrators will need to be members of sysadmin. Without this, most DBCC commands and the system stored procedures/functions listed below are unavailable. The users who require such access must be documented and approved. \n\nIn addition, if the site uses backup-restore software that connects to SQL Server via the Virtual Device Interface (VDI), the account used by that software must have the sysadmin role. (See Microsoft Knowledge Base article 2926557, http://support.microsoft.com/kb/2926557). If this applies, it must be documented and approved.\n\nStored procedures/functions available only to the sysadmin role:\nfn_yukonsecuritymodelrequired\nsp_add_agent_parameter\nsp_add_agent_profile\nsp_adddatatype\nsp_adddistributiondb\nsp_adddistributor\nsp_addqreader_agent\nsp_addsubscriber\nsp_addsubscriber_schedule\nsp_addtabletocontents\nsp_attachsubscription\nsp_cdc_cleanup_change_table\nsp_cdc_disable_db\nsp_cdc_disable_table\nsp_cdc_drop_job\nsp_cdc_enable_db\nsp_cdc_enable_table\nsp_cdc_restoredb\nsp_cdc_vupgrade\nsp_certify_removable\nsp_change_agent_parameter\nsp_change_agent_profile\nsp_change_subscription_properties\nsp_change_users_login\nsp_changedistpublisher\nsp_changedistributiondb\nsp_changedistributor_password\nsp_changedistributor_property\nsp_changemergesubscription\nsp_changeqreader_agent\nsp_changereplicationserverpasswords\nsp_changesubscriptiondtsinfo\nsp_checkinvalidivarticle\nsp_copysubscription\nsp_create_removable\nsp_cycle_errorlog\nsp_dbcmptlevel\nsp_dbmmonitoraddmonitoring\nsp_dbmmonitorchangealert\nsp_dbmmonitordropalert\nsp_dbmmonitordropmonitoring\nsp_dbmmonitorhelpalert\nsp_dbmmonitorhelpmonitoring\nsp_dbmmonitorresults\nsp_dbmmonitorupdate\nsp_dbremove\nsp_drop_agent_parameter\nsp_drop_agent_profile\nsp_dropdatatypemapping\nsp_dropdistpublisher\nsp_dropdistributiondb\nsp_dropdistributor\nsp_dropmergepullsubscription\nsp_droppullsubscription\nsp_dropsubscriber\nsp_dsninfo\nsp_enumdsn\nsp_flush_commit_table_on_demand\nsp_generate_agent_parameter\nsp_get_distributor\nsp_get_Oracle_publisher_metadata\nsp_getagentparameterlist\nsp_getdefaultdatatypemapping\nsp_grant_publication_access\nsp_help_agent_default\nsp_help_agent_parameter\nsp_help_agent_profile\nsp_helpdistpublisher\nsp_helpdistributor\nsp_helpmergesubscription\nsp_helpqreader_agent\nsp_helpreplicationdboption\nsp_identitycolumnforreplication\nsp_IHValidateRowFilter\nsp_IHXactSetJob\nsp_link_publication\nsp_monitor\nsp_MSadd_distribution_agent\nsp_MSadd_logreader_agent\nsp_MSadd_merge_agent\nsp_MSadd_snapshot_agent\nsp_MSadd_subscriber_schedule\nsp_MSadd_tracer_history\nsp_MSadd_tracer_token\nsp_MScdc_cleanup_job\nsp_MScdc_db_ddl_event\nsp_MScdc_ddl_event\nsp_MSchange_distribution_agent_properties\nsp_MSchange_logreader_agent_properties\nsp_MSchange_merge_agent_properties\nsp_MSchange_snapshot_agent_properties\nsp_MSchangedynamicsnapshotjobatdistributor\nsp_MSchangedynsnaplocationatdistributor\nsp_MScheck_pull_access\nsp_MScleanupmergepublisher_internal\nsp_MSclear_dynamic_snapshot_location\nsp_MScreate_dist_tables\nsp_MSdbuserpriv\nsp_MSdeletefoldercontents\nsp_MSdrop_6x_replication_agent\nsp_MSdrop_merge_agent\nsp_MSdrop_snapshot_dirs\nsp_MSdropmergedynamicsnapshotjob\nsp_MSdynamicsnapshotjobexistsatdistributor\nsp_MSenumallpublications\nsp_MSfetchAdjustidentityrange\nsp_MSfix_6x_tasks\nsp_MSforce_drop_distribution_jobs\nsp_MSget_agent_names\nsp_MSget_jobstate\nsp_MSget_oledbinfo\nsp_MSget_publication_from_taskname\nsp_MSgetdbversion\nsp_MSgetmaxsnapshottimestamp\nsp_MShelp_repl_agent\nsp_MShelp_replication_status\nsp_MShelp_snapshot_agent\nsp_MShelpconflictpublications\nsp_MShelpdynamicsnapshotjobatdistributor\nsp_MShelplogreader_agent\nsp_MShelpsnapshot_agent\nsp_MShelptranconflictcounts\nsp_MSinit_publication_access\nsp_MSreinit_failed_subscriptions\nsp_MSremoveoffloadparameter\nsp_MSrepl_backup_complete\nsp_MSrepl_backup_start\nsp_MSrepl_createdatatypemappings\nsp_MSrepl_dropdatatypemappings\nsp_MSrepl_enumarticlecolumninfo\nsp_MSrepl_enumpublications\nsp_MSrepl_enumpublishertables\nsp_MSrepl_enumsubscriptions\nsp_MSrepl_enumtablecolumninfo\nsp_MSrepl_getdistributorinfo\nsp_MSrepl_startup_internal\nsp_MSreplagentjobexists\nsp_MSreplcheck_permission\nsp_MSreplcheck_pull\nsp_MSreplcheck_subscribe\nsp_MSreplcheck_subscribe_withddladmin\nsp_MSreplcopyscriptfile\nsp_MSreplremoveuncdir\nsp_MSsetalertinfo\nsp_MSSetServerProperties\nsp_MSsetupnosyncsubwithlsnatdist\nsp_MSsetupnosyncsubwithlsnatdist_cleanup\nsp_MSsetupnosyncsubwithlsnatdist_helper\nsp_MSstartdistribution_agent\nsp_MSstartmerge_agent\nsp_MSstartsnapshot_agent\nsp_MSstopdistribution_agent\nsp_MSstopmerge_agent\nsp_MSstopsnapshot_agent\nsp_MSupdate_agenttype_default\nsp_oledbinfo\nsp_procoption\nsp_removedbreplication\nsp_removesrvreplication\nsp_replication_agent_checkup\nsp_replicationdboption\nsp_resetstatus\nsp_restoredbreplication\nsp_SetAutoSAPasswordAndDisable\nsp_setdefaultdatatypemapping\nsp_updatestats\nsp_validatelogins\nsp_vupgrade_mergeobjects\nsp_vupgrade_replication\nsp_vupgrade_replsecurity_metadata\nxp_repl_convert_encrypt_sysadmin_wrapper\n",
|
|
434
|
+
"severity": "medium"
|
|
435
|
+
},
|
|
436
|
+
{
|
|
437
|
+
"id": "V-41045",
|
|
438
|
+
"title": "A single SQL Server database connection configuration file (or a single set of credentials) must not be used to configure all database clients.",
|
|
439
|
+
"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 SQL Server 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 SQL Server databases not required by all users that may assist in unauthorized access attempts.",
|
|
440
|
+
"severity": "medium"
|
|
441
|
+
},
|
|
442
|
+
{
|
|
443
|
+
"id": "V-41046",
|
|
444
|
+
"title": "SQL Server must restrict access to sensitive information to authorized user roles.",
|
|
445
|
+
"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.",
|
|
446
|
+
"severity": "medium"
|
|
447
|
+
},
|
|
448
|
+
{
|
|
449
|
+
"id": "V-41047",
|
|
450
|
+
"title": "SQL Server processes or services must run under custom, dedicated OS or domain accounts.",
|
|
451
|
+
"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 concept of separation of duties extends to processes. The DBMS must run under a custom, dedicated OS or domain 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. Similarly, related services must run under dedicated accounts where this is possible. The SQL Server Browser and Writer services are exceptions: see http://msdn.microsoft.com/en-us/library/hh510203(v=sql.110).aspx and http://msdn.microsoft.com/en-us/library/ms175536(v=sql.110).aspx.",
|
|
452
|
+
"severity": "medium"
|
|
453
|
+
},
|
|
454
|
+
{
|
|
455
|
+
"id": "V-41202",
|
|
456
|
+
"title": "SQL Server must enforce separation of duties through assigned information access authorizations.",
|
|
457
|
+
"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 role 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.",
|
|
458
|
+
"severity": "medium"
|
|
459
|
+
},
|
|
460
|
+
{
|
|
461
|
+
"id": "V-41204",
|
|
462
|
+
"title": "SQL Server utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights.",
|
|
463
|
+
"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).\n\nThese DAC concepts extend to the server level. Server instances have the potential for the access controls to propagate without limit, resulting in unauthorized access.\n\nThe DBMS must ensure the recipient of server permissions possesses only the access intended. The DBMS must enforce the ability to limit unauthorized rights propagation. If propagation is not prevented, users can continue to grant rights to other users without limit.",
|
|
464
|
+
"severity": "medium"
|
|
465
|
+
},
|
|
466
|
+
{
|
|
467
|
+
"id": "V-41205",
|
|
468
|
+
"title": "SQL Server must enforce DAC policy allowing users to specify and control sharing by named individuals, groups of individuals, or by both; limiting propagation of access rights; and including or excluding access to the granularity of a single user.",
|
|
469
|
+
"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.",
|
|
470
|
+
"severity": "medium"
|
|
471
|
+
},
|
|
472
|
+
{
|
|
473
|
+
"id": "V-41206",
|
|
474
|
+
"title": "SQL Server must enforce access control policies to restrict the Unsafe assembly permission to only authorized roles.",
|
|
475
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Unsafe assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Unsafe assembly' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
476
|
+
"severity": "medium"
|
|
477
|
+
},
|
|
478
|
+
{
|
|
479
|
+
"id": "V-41207",
|
|
480
|
+
"title": "SQL Server must not grant users direct access to the Alter any endpoint permission.",
|
|
481
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts. If administrative user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
482
|
+
"severity": "medium"
|
|
483
|
+
},
|
|
484
|
+
{
|
|
485
|
+
"id": "V-41208",
|
|
486
|
+
"title": "SQL Server must not grant users direct access to the Alter any database permission.",
|
|
487
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
488
|
+
"severity": "medium"
|
|
489
|
+
},
|
|
490
|
+
{
|
|
491
|
+
"id": "V-41209",
|
|
492
|
+
"title": "SQL Server must not grant users direct access to the Alter Any Credential permission.",
|
|
493
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any credential' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
494
|
+
"severity": "medium"
|
|
495
|
+
},
|
|
496
|
+
{
|
|
497
|
+
"id": "V-41246",
|
|
498
|
+
"title": "SQL Server must not grant users direct access to the Alter any connection permission.",
|
|
499
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any connection' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
500
|
+
"severity": "medium"
|
|
501
|
+
},
|
|
502
|
+
{
|
|
503
|
+
"id": "V-41247",
|
|
504
|
+
"title": "SQL Server must not grant users direct access control to the Alter Any Availability Group permission.",
|
|
505
|
+
"description": "The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. \n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts. If administrative user accounts have direct access to administrative roles, this access must be removed.\n\n(The SQL Server installer gives this privilege to the system account \"NT AUTHORITY\\SYSTEM\", so this account is excluded from the Check. See article KB2847723 in the Microsoft knowledge base.)\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
506
|
+
"severity": "medium"
|
|
507
|
+
},
|
|
508
|
+
{
|
|
509
|
+
"id": "V-41248",
|
|
510
|
+
"title": "SQL Server must not grant users direct access to the Alter server state permission.",
|
|
511
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter server state' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
512
|
+
"severity": "medium"
|
|
513
|
+
},
|
|
514
|
+
{
|
|
515
|
+
"id": "V-41250",
|
|
516
|
+
"title": "SQL Server must not grant users direct access to the Alter any event notification permission.",
|
|
517
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
518
|
+
"severity": "medium"
|
|
519
|
+
},
|
|
520
|
+
{
|
|
521
|
+
"id": "V-41251",
|
|
522
|
+
"title": "SQL Server must enforce access control policies to restrict the View any database permission to only authorized roles.",
|
|
523
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'View any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'View any database' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
524
|
+
"severity": "medium"
|
|
525
|
+
},
|
|
526
|
+
{
|
|
527
|
+
"id": "V-41252",
|
|
528
|
+
"title": "SQL Server must not grant users direct access to the Alter any server audit permission.",
|
|
529
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any server audit' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
530
|
+
"severity": "medium"
|
|
531
|
+
},
|
|
532
|
+
{
|
|
533
|
+
"id": "V-41253",
|
|
534
|
+
"title": "SQL Server must enforce access control policies to restrict the Shutdown permission to only authorized roles.",
|
|
535
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Shutdown' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. , If the 'Shutdown' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
536
|
+
"severity": "medium"
|
|
537
|
+
},
|
|
538
|
+
{
|
|
539
|
+
"id": "V-41254",
|
|
540
|
+
"title": "SQL Server must enforce access control policies to restrict the External access assembly permission to only authorized roles.",
|
|
541
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'External access assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'External access assembly' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
542
|
+
"severity": "medium"
|
|
543
|
+
},
|
|
544
|
+
{
|
|
545
|
+
"id": "V-41255",
|
|
546
|
+
"title": "SQL Server must enforce access control policies to restrict the Create trace event notification permission to only authorized roles.",
|
|
547
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Create trace event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create trace event notification' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
548
|
+
"severity": "medium"
|
|
549
|
+
},
|
|
550
|
+
{
|
|
551
|
+
"id": "V-41256",
|
|
552
|
+
"title": "SQL Server must enforce access control policies to restrict the Create server role permission to only authorized roles.",
|
|
553
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Create server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. , If the 'Create server role' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
554
|
+
"severity": "medium"
|
|
555
|
+
},
|
|
556
|
+
{
|
|
557
|
+
"id": "V-41257",
|
|
558
|
+
"title": "SQL Server must enforce access control policies to restrict the Create endpoint permission to only authorized roles.",
|
|
559
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Create endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create endpoint' permissions are granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
560
|
+
"severity": "medium"
|
|
561
|
+
},
|
|
562
|
+
{
|
|
563
|
+
"id": "V-41258",
|
|
564
|
+
"title": "SQL Server must enforce access control policies to restrict the Create DDL event notification permission to only authorized roles.",
|
|
565
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Create DDL event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create DDL event notification' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
566
|
+
"severity": "medium"
|
|
567
|
+
},
|
|
568
|
+
{
|
|
569
|
+
"id": "V-41259",
|
|
570
|
+
"title": "SQL Server must enforce access control policies to restrict the Create availability group permission to only authorized roles.",
|
|
571
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Create availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create availability group' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
572
|
+
"severity": "medium"
|
|
573
|
+
},
|
|
574
|
+
{
|
|
575
|
+
"id": "V-41260",
|
|
576
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any server audit permission to only authorized roles.",
|
|
577
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any server audit' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any server audit' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
578
|
+
"severity": "medium"
|
|
579
|
+
},
|
|
580
|
+
{
|
|
581
|
+
"id": "V-41261",
|
|
582
|
+
"title": "SQL Server must enforce access control policies to restrict the View any definition permission to only authorized roles.",
|
|
583
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'View any definition' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'View any definition' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
584
|
+
"severity": "medium"
|
|
585
|
+
},
|
|
586
|
+
{
|
|
587
|
+
"id": "V-41262",
|
|
588
|
+
"title": "SQL Server must not grant users direct access to the Authenticate server permission.",
|
|
589
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Authenticate Server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
590
|
+
"severity": "medium"
|
|
591
|
+
},
|
|
592
|
+
{
|
|
593
|
+
"id": "V-41263",
|
|
594
|
+
"title": "SQL Server must not grant users direct access to the Administer bulk operations permission.",
|
|
595
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Administer bulk operations' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
596
|
+
"severity": "medium"
|
|
597
|
+
},
|
|
598
|
+
{
|
|
599
|
+
"id": "V-41264",
|
|
600
|
+
"title": "SQL Server must not grant users direct access to the Create endpoint permission.",
|
|
601
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Create endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
602
|
+
"severity": "medium"
|
|
603
|
+
},
|
|
604
|
+
{
|
|
605
|
+
"id": "V-41265",
|
|
606
|
+
"title": "SQL Server must not grant users direct access to the Create DDL event notification permission.",
|
|
607
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Create DDL event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
608
|
+
"severity": "medium"
|
|
609
|
+
},
|
|
610
|
+
{
|
|
611
|
+
"id": "V-41266",
|
|
612
|
+
"title": "SQL Server must not grant users direct access to the Create availability group permission.",
|
|
613
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Create availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.\n",
|
|
614
|
+
"severity": "medium"
|
|
615
|
+
},
|
|
616
|
+
{
|
|
617
|
+
"id": "V-41267",
|
|
618
|
+
"title": "SQL Server must not grant users direct access to the Create any database permission.",
|
|
619
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Create any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
620
|
+
"severity": "medium"
|
|
621
|
+
},
|
|
622
|
+
{
|
|
623
|
+
"id": "V-41268",
|
|
624
|
+
"title": "SQL Server must not grant users direct access to the Control server permission.",
|
|
625
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Control server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
626
|
+
"severity": "medium"
|
|
627
|
+
},
|
|
628
|
+
{
|
|
629
|
+
"id": "V-41269",
|
|
630
|
+
"title": "SQL Server must enforce access control policies to restrict the Administer bulk operations permission to only authorized roles.",
|
|
631
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Administer bulk operations' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Administer bulk operations' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
632
|
+
"severity": "medium"
|
|
633
|
+
},
|
|
634
|
+
{
|
|
635
|
+
"id": "V-41270",
|
|
636
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter resources permission to only authorized roles.",
|
|
637
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Alter resources' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter resources' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
638
|
+
"severity": "medium"
|
|
639
|
+
},
|
|
640
|
+
{
|
|
641
|
+
"id": "V-41271",
|
|
642
|
+
"title": "SQL Server must not grant users direct access to the Alter any linked server permission.",
|
|
643
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any linked server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
644
|
+
"severity": "medium"
|
|
645
|
+
},
|
|
646
|
+
{
|
|
647
|
+
"id": "V-41273",
|
|
648
|
+
"title": "SQL Server must not grant users direct control to the Alter any event session permission.",
|
|
649
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any event session' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
650
|
+
"severity": "medium"
|
|
651
|
+
},
|
|
652
|
+
{
|
|
653
|
+
"id": "V-41274",
|
|
654
|
+
"title": "SQL Server must not grant users direct access to the Alter trace permission.",
|
|
655
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter trace' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
656
|
+
"severity": "medium"
|
|
657
|
+
},
|
|
658
|
+
{
|
|
659
|
+
"id": "V-41275",
|
|
660
|
+
"title": "SQL Server must not grant users direct access to the Alter Settings permission.",
|
|
661
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter Settings' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
662
|
+
"severity": "medium"
|
|
663
|
+
},
|
|
664
|
+
{
|
|
665
|
+
"id": "V-41276",
|
|
666
|
+
"title": "SQL Server must not grant users direct access to the Create trace event notification permission.",
|
|
667
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Create trace event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
668
|
+
"severity": "medium"
|
|
669
|
+
},
|
|
670
|
+
{
|
|
671
|
+
"id": "V-41277",
|
|
672
|
+
"title": "SQL Server must not grant users direct access to the Alter resources permission.",
|
|
673
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter resources' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
674
|
+
"severity": "medium"
|
|
675
|
+
},
|
|
676
|
+
{
|
|
677
|
+
"id": "V-41278",
|
|
678
|
+
"title": "SQL Server must not grant users direct access to the External access assembly permission.",
|
|
679
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'External access assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
680
|
+
"severity": "medium"
|
|
681
|
+
},
|
|
682
|
+
{
|
|
683
|
+
"id": "V-41279",
|
|
684
|
+
"title": "SQL Server must not grant users direct access to the Alter any login permission.",
|
|
685
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any login' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
686
|
+
"severity": "medium"
|
|
687
|
+
},
|
|
688
|
+
{
|
|
689
|
+
"id": "V-41280",
|
|
690
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any availability group permission to only authorized roles.",
|
|
691
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles and users. If the 'Alter any availability group' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
692
|
+
"severity": "medium"
|
|
693
|
+
},
|
|
694
|
+
{
|
|
695
|
+
"id": "V-41281",
|
|
696
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any login permission to only authorized roles.",
|
|
697
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any login' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any login' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
698
|
+
"severity": "medium"
|
|
699
|
+
},
|
|
700
|
+
{
|
|
701
|
+
"id": "V-41283",
|
|
702
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any linked server permission to only authorized roles.",
|
|
703
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any linked server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any linked server' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
704
|
+
"severity": "medium"
|
|
705
|
+
},
|
|
706
|
+
{
|
|
707
|
+
"id": "V-41284",
|
|
708
|
+
"title": "SQL Server must not grant users direct access control to the Shutdown permission.",
|
|
709
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Shutdown' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts. If administrative user accounts have direct access to administrative roles, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
710
|
+
"severity": "medium"
|
|
711
|
+
},
|
|
712
|
+
{
|
|
713
|
+
"id": "V-41285",
|
|
714
|
+
"title": "SQL Server must enforce access control policies to restrict the View server state permission to only authorized roles.",
|
|
715
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'View server state' permission is a high server-level privilege that must only granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'View server state' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
716
|
+
"severity": "medium"
|
|
717
|
+
},
|
|
718
|
+
{
|
|
719
|
+
"id": "V-41286",
|
|
720
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter trace permission to only authorized roles.",
|
|
721
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Alter trace' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter trace' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
722
|
+
"severity": "medium"
|
|
723
|
+
},
|
|
724
|
+
{
|
|
725
|
+
"id": "V-41287",
|
|
726
|
+
"title": "SQL Server must not grant users direct access to the Unsafe assembly permission.",
|
|
727
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Unsafe assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
728
|
+
"severity": "medium"
|
|
729
|
+
},
|
|
730
|
+
{
|
|
731
|
+
"id": "V-41288",
|
|
732
|
+
"title": "SQL Server must enforce access control policies to restrict the Control server permission to only authorized roles.",
|
|
733
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Control server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Control server' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
734
|
+
"severity": "medium"
|
|
735
|
+
},
|
|
736
|
+
{
|
|
737
|
+
"id": "V-41289",
|
|
738
|
+
"title": "SQL Server must not grant users direct access to the Create server role permission.",
|
|
739
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Create server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
740
|
+
"severity": "medium"
|
|
741
|
+
},
|
|
742
|
+
{
|
|
743
|
+
"id": "V-41290",
|
|
744
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any server role permission to only authorized roles.",
|
|
745
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any server role' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
746
|
+
"severity": "medium"
|
|
747
|
+
},
|
|
748
|
+
{
|
|
749
|
+
"id": "V-41291",
|
|
750
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter Settings permission to only authorized roles.",
|
|
751
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Alter Settings' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter Settings' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
752
|
+
"severity": "medium"
|
|
753
|
+
},
|
|
754
|
+
{
|
|
755
|
+
"id": "V-41292",
|
|
756
|
+
"title": "SQL Server must enforce access control policies to restrict the Authenticate server permission to only authorized roles.",
|
|
757
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Authenticate server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Authenticate server' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
758
|
+
"severity": "medium"
|
|
759
|
+
},
|
|
760
|
+
{
|
|
761
|
+
"id": "V-41293",
|
|
762
|
+
"title": "SQL Server must enforce access control policies to restrict the Create any database permission to only authorized roles.",
|
|
763
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Create any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create any database' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
764
|
+
"severity": "medium"
|
|
765
|
+
},
|
|
766
|
+
{
|
|
767
|
+
"id": "V-41294",
|
|
768
|
+
"title": "SQL Server must not grant users direct access to the View server state permission.",
|
|
769
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'View server state' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
770
|
+
"severity": "medium"
|
|
771
|
+
},
|
|
772
|
+
{
|
|
773
|
+
"id": "V-41295",
|
|
774
|
+
"title": "SQL Server must not grant users direct access to the Alter any server role permission.",
|
|
775
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'Alter any server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
776
|
+
"severity": "medium"
|
|
777
|
+
},
|
|
778
|
+
{
|
|
779
|
+
"id": "V-41296",
|
|
780
|
+
"title": "SQL Server must not grant users direct access to the View any definition permission.",
|
|
781
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'View any definition' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
782
|
+
"severity": "medium"
|
|
783
|
+
},
|
|
784
|
+
{
|
|
785
|
+
"id": "V-41297",
|
|
786
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any connection permission to only authorized roles.",
|
|
787
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any connection' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any connection' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
788
|
+
"severity": "medium"
|
|
789
|
+
},
|
|
790
|
+
{
|
|
791
|
+
"id": "V-41298",
|
|
792
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any credential permission to only authorized roles.",
|
|
793
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any credential' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any credential' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
794
|
+
"severity": "medium"
|
|
795
|
+
},
|
|
796
|
+
{
|
|
797
|
+
"id": "V-41299",
|
|
798
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any database permission to only authorized roles.",
|
|
799
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles If the 'Alter any database' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
800
|
+
"severity": "medium"
|
|
801
|
+
},
|
|
802
|
+
{
|
|
803
|
+
"id": "V-41300",
|
|
804
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any endpoint permission to only authorized roles.",
|
|
805
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any endpoint' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
806
|
+
"severity": "medium"
|
|
807
|
+
},
|
|
808
|
+
{
|
|
809
|
+
"id": "V-41302",
|
|
810
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any event session permission to only authorized roles.",
|
|
811
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any event session' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any event session' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
812
|
+
"severity": "medium"
|
|
813
|
+
},
|
|
814
|
+
{
|
|
815
|
+
"id": "V-41303",
|
|
816
|
+
"title": "SQL Server must enforce access control policies to restrict Alter server state permissions to only authorized roles.",
|
|
817
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nSQL Server's 'Alter server state' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter server state' permissions are granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
818
|
+
"severity": "medium"
|
|
819
|
+
},
|
|
820
|
+
{
|
|
821
|
+
"id": "V-41304",
|
|
822
|
+
"title": "SQL Server must enforce non-DAC policies over users and resources where the policy rule set for each policy specifies access control information (i.e., position, nationality, age, project, time of day).",
|
|
823
|
+
"description": "Non-DAC controls are determined by policy makers and are managed centrally or by a central authority. These controls must not be changed at the discretion of ordinary application users. Data protection requirements may result in a non-DAC policy being specified as part of the application design. Non-DACs are employed at the application level to restrict and control access to application data, thereby providing increased information security for the organization.\n\nSQL Server Non-DAC is maintained through the use of Roles. Roles are set up within SQL Server to grant user accounts read and/or write permissions to system objects: databases, tables, columns, etc. After a role is created, user accounts can be assigned to a role granting them permissions of that role.\n\nIf users have permissions to database objects that they are not authorized to have, the user account that has access to the unauthorized database object must be removed from the role that grants that access. Policy rule sets would be developed to establish that each user receives only the information to which the user is authorized.\n\nFrequently, roles grant access to multiple privileges; if a user is authorized and determined to need access to authorized privilege granted by a role, and unauthorized for other privileges of that same role, it may be necessary to split the privileges of one role into two roles.",
|
|
824
|
+
"severity": "medium"
|
|
825
|
+
},
|
|
826
|
+
{
|
|
827
|
+
"id": "V-41305",
|
|
828
|
+
"title": "SQL Server must notify appropriate individuals when accounts are modified.",
|
|
829
|
+
"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 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\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",
|
|
830
|
+
"severity": "medium"
|
|
831
|
+
},
|
|
832
|
+
{
|
|
833
|
+
"id": "V-41306",
|
|
834
|
+
"title": "SQL Server must automatically audit account modification.",
|
|
835
|
+
"description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. \n\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, leverage complimentary technology providing this capability, or a combination thereof.\n\nAutomated account-auditing processes greatly reduce the risk that accounts will be surreptitiously modified, and provides logging that can be used for forensic purposes. \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.",
|
|
836
|
+
"severity": "medium"
|
|
837
|
+
},
|
|
838
|
+
{
|
|
839
|
+
"id": "V-41307",
|
|
840
|
+
"title": "SQL Server must ensure that remote sessions that access an organization-defined list of security functions and security-relevant information are audited.",
|
|
841
|
+
"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 post security incident.\n",
|
|
842
|
+
"severity": "medium"
|
|
843
|
+
},
|
|
844
|
+
{
|
|
845
|
+
"id": "V-41311",
|
|
846
|
+
"title": "The number of concurrent SQL Server sessions for each system account must be limited.",
|
|
847
|
+
"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\nOne way SQL Server can limit exposure to DoS attacks is to restrict the number of connections that can be opened by a single user. SQL Server supports this through the use of logon triggers. (Note, however, that this need not be the only, or even the principal, means for satisfying this requirement. Depending on the architecture and capabilities of the network and application, a network device or an application may be more suitable for providing this protection.)\n\nWhen determining the appropriate values for this limit, take the characteristics of the various kinds of user into account, and bear in mind that some applications and some users may need to have multiple sessions open. For example, while a standard account using a simple application may never need more than, say, five connections, a database administrator using SQL Server Management Studio may need significantly more, because each tab in that application counts as a distinct session.\n\nArchitectural note: In SQL Server, a count of active sessions by user can be obtained from one of the dynamic management views. For example:\n\n\tSELECT original_login_name, count(*) \n\tFROM sys.dm_exec_sessions\n\tWHERE is_user_process = 1\n\tGROUP BY original_login_name;\n\nHowever, for this to return an accurate count in a logon trigger, the user would have to have the View Server State privilege. (Without this privilege, the trigger sees information only about the current session, so would always return a count of one.) View Server State would give that user access to a wide swath of information about the server, violating SQL2-00-004100. One way to avoid this exposure is to create a summary table, and a view of that table that restricts each user to seeing his/her own count, and establish a frequently-run background job to refresh the table (using the above query or similar). The logon trigger then queries the view to obtain a count that is accurate enough for most purposes.",
|
|
848
|
+
"severity": "medium"
|
|
849
|
+
},
|
|
850
|
+
{
|
|
851
|
+
"id": "V-41419",
|
|
852
|
+
"title": "The Service Master Key must be backed up, stored offline and off-site.",
|
|
853
|
+
"description": "Backup and recovery of the Service Master Key may be critical to the complete recovery of the database. Not having this key can lead to loss of data during recovery.",
|
|
854
|
+
"severity": "medium"
|
|
855
|
+
},
|
|
856
|
+
{
|
|
857
|
+
"id": "V-43196",
|
|
858
|
+
"title": "Domain accounts used to manage a SQL Server platform must be different from those used to manage other platforms.",
|
|
859
|
+
"description": "Separate accounts used to manage the SQL Server platform help prevent a lateral move within an environment if SQL were to be compromised.",
|
|
860
|
+
"severity": "medium"
|
|
861
|
+
},
|
|
862
|
+
{
|
|
863
|
+
"id": "V-53877",
|
|
864
|
+
"title": "SQL Server databases in the unclassified environment, containing sensitive information, must be encrypted using approved cryptography.",
|
|
865
|
+
"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.",
|
|
866
|
+
"severity": "medium"
|
|
867
|
+
},
|
|
868
|
+
{
|
|
869
|
+
"id": "V-54859",
|
|
870
|
+
"title": "The OS must limit privileges to the SQL Server Data Root directory and its subordinate directories and files.",
|
|
871
|
+
"description": "Default database file locations should be protected from unauthorized access. The system databases, essential to SQL Server operation, are typically located here.",
|
|
872
|
+
"severity": "medium"
|
|
873
|
+
},
|
|
874
|
+
{
|
|
875
|
+
"id": "V-54879",
|
|
876
|
+
"title": "The OS must limit privileges to the SQL Server data directories and their subordinate directories and files.",
|
|
877
|
+
"description": "Database files must be protected from unauthorized access. Although default data locations are created at installation time, sites can, and will, use other directories for site-created database files to comply with best practices.",
|
|
878
|
+
"severity": "medium"
|
|
879
|
+
},
|
|
880
|
+
{
|
|
881
|
+
"id": "V-54881",
|
|
882
|
+
"title": "The OS must limit privileges to the SQL Server backup directories and files.",
|
|
883
|
+
"description": "Backups must be protected from unauthorized deletion and modification. They must also be protected from unauthorized use in database restoration.",
|
|
884
|
+
"severity": "medium"
|
|
885
|
+
},
|
|
886
|
+
{
|
|
887
|
+
"id": "V-55805",
|
|
888
|
+
"title": "SQL Server must not grant users direct access to the View Any Database permission.",
|
|
889
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. 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.\n\nPrivileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. 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.\n\nSQL Server's 'View Any Database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed.\n\nNote that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.",
|
|
890
|
+
"severity": "medium"
|
|
891
|
+
},
|
|
892
|
+
{
|
|
893
|
+
"id": "V-59857",
|
|
894
|
+
"title": "Owners of privileged accounts must use non-privileged accounts for non-administrative activities.",
|
|
895
|
+
"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.",
|
|
896
|
+
"severity": "medium"
|
|
897
|
+
},
|
|
898
|
+
{
|
|
899
|
+
"id": "V-59915",
|
|
900
|
+
"title": "SQL Server must enforce access control policies to restrict the Alter any event notification permission to only authorized roles.",
|
|
901
|
+
"description": "The concept of least privilege must be applied to SQL Server 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 SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS.\n\nUnauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. 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.\n\nSQL Server's 'Alter any event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any event notification' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed.\n\nAdditionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role.\n\nThe fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.",
|
|
902
|
+
"severity": "medium"
|
|
903
|
+
},
|
|
904
|
+
{
|
|
905
|
+
"id": "V-69169",
|
|
906
|
+
"title": "Software, applications, and configuration files that are part of, or related to, the SQL Server 2012 installation must be audited.",
|
|
907
|
+
"description": "When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of applications and tools related to SQL Server can potentially have significant effects on the overall security of the system. Only qualified and authorized individuals shall be allowed to obtain access to components related to SQL Server for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the software libraries or configuration can lead to unauthorized or compromised installations.\n\nOf particular note in this context is that any software installed for auditing and/or audit file management must be protected and audited.",
|
|
908
|
+
"severity": "medium"
|
|
909
|
+
},
|
|
910
|
+
{
|
|
911
|
+
"id": "V-70625",
|
|
912
|
+
"title": "The SQL Server Browser service must be disabled if its use is not necessary.",
|
|
913
|
+
"description": "The SQL Server Browser simplifies the administration of SQL Server, particularly when multiple instances of SQL Server coexist on the same computer. It avoids the need to hard-assign port numbers to the instances and to set and maintain those port numbers in client systems. It enables administrators and authorized users to discover database management system instances, and the databases they support, over the network.\n\nThis convenience also presents the possibility of unauthorized individuals gaining knowledge of the available SQL Server resources. Therefore, it is necessary to consider whether the SQL Server Browser is needed. Typically, if only a single instance is installed, using the default name (MSSQLSERVER) and port assignment (1433), the Browser is not adding any value. The more complex the installation, the more likely SQL Server Browser is to be helpful.\n\nThis requirement is not intended to prohibit use of the Browser service in any circumstances; rather, it calls for administrators and management to consider whether the benefits of its use outweigh the potential negative consequences.",
|
|
914
|
+
"severity": "low"
|
|
915
|
+
},
|
|
916
|
+
{
|
|
917
|
+
"id": "V-72413",
|
|
918
|
+
"title": "If SQL Server authentication, using passwords, is employed, SQL Server must enforce the DoD standards for password complexity.",
|
|
919
|
+
"description": "Windows domain/enterprise authentication and identification must be used (SQL2-00-023600). Native SQL Server authentication may be used only when circumstances make it unavoidable; and must be documented and AO-approved.\n\nThe DoD standard for authentication is DoD-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval.\n\nIn such cases, the DoD standards for password complexity must be implemented.\n\nThe requirements for password complexity are:\na. minimum of 15 Characters, 1 of each of the following character sets:\n- Upper-case\n- Lower-case\n- Numeric\n- Special characters (e.g. ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > <)];\nb. Minimum number of characters changed from previous password: 50% of the minimum password length (that is, 8).\n\nTo enforce this in SQL Server, configure each DBMS-managed login to inherit the rules from Windows.",
|
|
920
|
+
"severity": "medium"
|
|
921
|
+
},
|
|
922
|
+
{
|
|
923
|
+
"id": "V-72415",
|
|
924
|
+
"title": "If SQL Server authentication, using passwords, is employed, SQL Server must enforce the DoD standards for password lifetime.",
|
|
925
|
+
"description": "Windows domain/enterprise authentication and identification must be used (SQL2-00-023600). Native SQL Server authentication may be used only when circumstances make it unavoidable; and must be documented and AO-approved.\n\nThe DoD standard for authentication is DoD-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval.\n\nIn such cases, the DoD standards for password lifetime must be implemented.\n\nThe requirements for password lifetime are:\na. Password lifetime limits for interactive accounts: Minimum 24 hours, Maximum 60 days\nb. Password lifetime limits for non-interactive accounts: Minimum 24 hours, Maximum 365 days\nc. Number of password changes before an old one may be reused: Minimum of 5.\n\nTo enforce this in SQL Server, configure each DBMS-managed login to inherit the rules from Windows.",
|
|
926
|
+
"severity": "medium"
|
|
927
|
+
}
|
|
928
|
+
]
|
|
929
|
+
}
|