SQL Server must protect against a user falsely repudiating by ensuring the NT AUTHORITY SYSTEM account is not used for administration.
From MS SQL Server 2016 Instance Security Technical Implementation Guide
Part of SRG-APP-000080-DB-000063
Associated with:
CCI-000166
SV-93835r1_rule
SQL Server must protect against a user falsely repudiating by ensuring the NT AUTHORITY SYSTEM account is not used for administration.
Vulnerability discussion
Non-repudiation of actions taken is required in order to maintain data 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. Non-repudiation protects against later claims by a user of not having created, modified, or deleted a particular data item or collection of data in the database. In designing a database, the organization must define the types of data and the user actions that must be protected from repudiation. The implementation must then include building audit features into the application data tables and configuring the DBMS's audit tools to capture the necessary audit trail. Design and implementation also must ensure that applications pass individual user identification to the DBMS, even where the application connects to the DBMS with a standard, shared account. Any user with enough access to the server can execute a task that will be run as NT AUTHORITY\SYSTEM either using task scheduler or other tools. At this point, NT AUTHORITY\SYSTEM essentially becomes a shared account because the operating system and SQL Server are unable to determine who created the process. Prior to SQL Server 2012, NT AUTHORITY\SYSTEM was a member of the sysadmin role by default. This allowed jobs/tasks to be executed in SQL Server without the approval or knowledge of the DBA because it looked like operating system activity.
Check content
In SQL Server Management Studio:
Navigate in the tree to Security >> Logins.
Right-click on "NT AUTHORITY\SYSTEM" and click "Properties".
Select "Server Roles".
If any roles other than public are selected, this is a finding.
Select User Mapping.
If any databases are selected, this is a finding.
Select Securables.
If any permissions are granted other than "Connect SQL", this is a finding.
Fix text
Unselect any roles, mappings, or permissions that were not identified as allowed in the check content.
To grant permissions to services or applications, utilize the Service SID of the service or a domain service account.
Pro Tips
Lavender hyperlinks in small type off to the right (of CSS
class id, if you view the page source) point to
globally unique URIs for each document and item. Copy the
link location and paste anywhere you need to talk
unambiguously about these things.
You can obtain data about documents and items in other
formats. Simply provide an HTTP header Accept:
text/turtle or
Accept: application/rdf+xml.
Powered by sagemincer