Skip to content
ATO Pathways
Log In
Overview
Search
Catalogs
SCAP
OSCAL
Catalogs
Profiles
Documents
References
Knowledge Base
Platform Documentation
Compliance Dictionary
Platform Changelog
About
Catalogs
XCCDF
MS SQL Server 2014 Instance Security Technical Implementation Guide
SRG-APP-000492-DB-000333
SRG-APP-000492-DB-000333
An XCCDF Group - A logical subset of the XCCDF Benchmark
Details
Profiles
Prose
SRG-APP-000492-DB-000333
1 Rule
<GroupDescription></GroupDescription>
SQL Server must produce Trace or Audit records when unsuccessful attempts to access security objects occur.
Medium Severity
<VulnDiscussion>Changes to the security configuration must be tracked. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. This requirement applies to situations where security data is retrieved or modified via data manipulation operations, as opposed to via SQL Server's built-in security functionality (GRANT, REVOKE, DENY, ALTER [SERVER] ROLE ... ADD/DROP MEMBER ..., etc.). In SQL Server, types of access include, but are not necessarily limited to: SELECT INSERT UPDATE DELETE EXECUTE Since the system views are read-only, and the underlying tables are kept hidden by SQL Server, the Insert, Update and Delete cases are relevant only where the database includes user-defined tables to support additional security functionality. Use of SQL Server Audit is recommended. All features of SQL Server Audit are available in the Enterprise and Developer editions of SQL Server 2014. It is not available at the database level in other editions. For this or legacy reasons, the instance may be using SQL Server Trace for auditing, which remains an acceptable solution for the time being. Note, however, that Microsoft intends to remove most aspects of Trace at some point after SQL Server 2016. Note also that Trace does not support auditing of SELECT statements, whereas Audit does. Use of SQL Server Audit's SCHEMA_OBJECT_ACCESS_GROUP causes capture of all accesses, successful and otherwise, to all schema-scoped objects. The [Succeeded] column in the audit output indicates the success or failure of the attempted action. Be aware, however, that it may report True in some cases where one would intuitively expect False. For example, SELECT 1/0 FROM SYS.ALL_OBJECTS will appear in the audit trail as successful, if the user has permission to perform that action, even though it contains an invalid expression. Some other actions that one would consider failures (such as selecting from a table that does not exist) may not appear at all.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>