SQL2-00-014400 - SQL Server must protect the audit records generated as a result of remote access to privileged accounts and by the execution of privileged functions.


Protection of audit records and audit data is of critical importance. Care must be taken to ensure privileged users cannot circumvent audit protections put in place.

Auditing might not be reliable when performed by an information system that the user being audited has privileged access to.

The privileged user could inhibit auditing or directly modify audit records. To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges.

Reducing 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).

If 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.


Modify audit file permissions to meet the requirement to protect against unauthorized access.

Navigate to the audit folder location(s) using a command prompt or Windows Explorer. Right-click on the file, click Properties.
On the Security tab, modify the security permissions to:
Users (none)
Audit Administrator(Full Control)
Auditors group (Read)
SQL Server Service SID OR Service Account (Full Control) [Notes 1, 2]
SQL Server SQL Agent Service SID OR Service Account, if SQL Server Agent is in use. (Read, Execute, Write) [Notes 1, 2]


Note 1: It is highly advisable to use a separate account for each service. When installing SQL Server in single-server mode, you can opt to have these provisioned for you. These automatically-generated accounts are referred to as virtual accounts. Each virtual account has an equivalent Service SID, with the same name. The installer also creates an equivalent SQL Server login, also with the same name. Applying folder and file permissions to Service SIDs, rather than to domain accounts or local computer accounts, provides tighter control, because these permissions are available only to the specific service when it is running, and not in any other context. (However, when using failover clustering, a domain account must be specified at installation, rather than a virtual account.) For more on this topic, see http://msdn.microsoft.com/en-us/library/ms143504(v=sql.110).aspx.

Note 2: Tips for adding a service SID/virtual account to a folder's permission list.
1) In Windows Explorer, right-click on the folder and select 'Properties.'
2) Select the 'Security' tab
3) Click 'Edit'
4) Click 'Add'
5) Click 'Locations'
6) Select the computer name
7) Search for the name
7.a) SQL Server Service
7.a.i) Type 'NT SERVICE\MSSQL' and click 'Check Names'. (What you have just typed in is the first 16 characters of the name. At least one character must follow 'NT SERVICE\'; you will be presented with a list of all matches. If you have typed in the full, correct name, step 7.a.ii is bypassed.)
7.a.ii) Select the 'MSSQL$<instance name>' user and click OK
7.b) SQL Agent Service
7.b.i) Type 'NT SERVICE\SQL' and click 'Check Names'
7.b.ii) Select the 'SQLAgent$<instance name>' user and click OK
8) Click OK
9) Permission like a normal user from here

See Also


Item Details


References: 800-53|AU-9(4), 800-53|CM-6b., CAT|II, CCI|CCI-000366, CCI|CCI-001351, Rule-ID|SV-53391r4_rule, STIG-ID|SQL2-00-014400, Vuln-ID|V-41017

Plugin: Windows

Control ID: 8b57577b206dfe9d52f0f8a407c7499754867d629cff3b442236c94d73f5c76a