SQL Server Database Security Audit (Part 1): What to expect?

By:   |   Comments (10)   |   Related: > Auditing and Compliance


Problem

I am new to Database Administration and have been asked to prepare data for an audit. I know there are a lot of different metrics I can pull from SQL Server, but I am not exactly sure where to begin.  What items would you suggest to look into to make sure that we have information for the audit?

Solution

A SQL Server security review should be part of the DBAs regular activity. Some people do this once a month and others more often. You can also have this completely or partially automated (using server level DDL triggers, alerts, third party tools etc.).

The checklist below will help you to be ready to answer some security related questions for your next audit.

What do you need to check in first place?

  • Logins
    • You should enable at least the failed logins audit. This will help you to identify brute force or unauthorized login attempts. 
    • Refer to this tip for more information.
  • Members of "Local Administrators" group on SQL Server:
    • This check is required to make sure that only authorized users are members of the group.
    • Refer to this tip for more information.
  • Sysadmin server role members (and other server level roles):
    • This check is required to make sure that only authorized logins are members of the server groups (you may need to justify each case).
    • Refer to this tip for more information.
  • Db_owner database role members:
    • This check is required to make sure that only authorized users are in this role. This role should be used for the database administration only. Developers, application accounts should be given only permissions required to perform their tasks.
    • Refer to this tip for more information.
  • Password policies and expiration for the SQL logins are enabled:
    • This check is required to make sure that the passwords are strong and cannot be easily compromised.
    • Refer to this tip for more information.
  • Builtin/Adminstrators group removed from sysadmin's server role (not this is removed by default in the latest versions of SQL Server):
    • One of the reasons to check this is that DBAs don't always have control of this group's membership. Another reason for this is separation of duties. Only DBAs should be members of the sysadmin's role.
    • Refer to this tip for more information.
  • Production and Test databases are segregated (on different SQL Servers):
    • One of the reasons is potential access of the production database due to hard coded database names (cross-database queries). Production database could be accidentally updated during the testing if database names have not been updated in test stored procedures. Also, testing can be resource intensive and may affect production databases.
  • Sample databases (AdventureWorks, Pubs etc.) are not present on Production SQL Servers:
    • These databases are not production databases and should not be installed on production SQL Servers. A security review is required for each of these databases if they are used.
  • Set strong password for "sa" login, disable "sa" login, or possibly rename "sa" login if there are no legacy applications that depend on it (change database connection to use less privileged account):
    • Most attackers will try to use "sa" login first.
    • Refer to this tip for more information.
  • Review initialization parameters (sp_configure settings) -
    • Ad Hoc Distributed Queries
      • Disable if not required. There is a possibility of somebody using SQL Server authentication with it where the provider string will contain an embedded password.
    • clr enabled
      • Disable if not used to reduce number of the enabled features and therefore narrow down patching and potential attack surface.
    • cross db ownership chaining:
      • Disable if not required. This option allows for the bypassing of permissions between databases.
    • Database Mail XPs
      • Disable if not required. To reduce the number of the enabled features and therefore narrow down patching and potential attack surface.
    • xp_cmdshell
      • To avoid network and OS related attacks through the OS commands. This is disabled by default.
  • CONNECT permissions to the guest user
    • Make sure that CONNECT permissions are denied on all databases for this user except master and tempdb (especially if you have SQL Server 2012 with contained databases).
  • Restrict access to backup files to System Administrators and/or DBAs:
    • This has to be done to make sure that company's sensitive data is not available to anybody else.
    • Refer to this tip for more information.
  • SQL Server Security settings:
    • Set to Windows Authentication (which is more secure) where possible. Justify your SQL security mode and prove that it has to be mixed if it is set to mixed (for example, legacy applications requirements).
    • Refer to this tip for more information.
    • SQL Server build:
      • Be ready to answer the questions about your database system patch level and patching procedures. Make sure that the latest security fixes have been applied.
      • Refer to this tip for more information.

What else can you expect?

  • Auditors may ask you for documentation for the following processes:
    • Review of databases users
    • When accounts are created and deleted
    • List of permissions via GRANT
  • You may need to provide the following information:
    • Where data and transaction logs are located
      • best practice - make sure they are on separate partitions
    • What network protocols are enabled
      • best practice - disable Named Pipes if not used
    • SQL Server services startup mode
      • best practice - make sure it is automatic
    • List of Application roles
    • List of remote and linked servers (including security configuration)
      • best practice - replace remote servers with linked servers and use Windows authentication
  • Make sure you have database diagrams for the most important databases and/or list the names of the most important tables.
  • You may need to provide the evidence for the following:
  • Successful and/or failed backups and related notifications
  • Server/database/objects audit (all or some of the events, for all databases or just for critical databases):
    • Audit Add DB User Event
    • Audit Add Role Event
    • Audit Add Login to Server Role
    • Audit Addlogin Event
    • Audit Add Member to DB Role
    • Audit App Role Change Password
    • Audit Change Audit
    • Audit Change Database Owner
    • Audit Database Scope GDR
    • Audit Database Management
    • Audit Database Object GDR
    • Audit Database Operation
    • Audit Database Object Management
    • Audit Database Principal Impersonation
    • Audit Database Principal Management
    • Audit Database Scope GDR
    • Audit Login Change Password
    • Audit Login Change Property
    • Audit Login GDR Event
    • Audit Object Derived Permission Event
    • Audit Schema Object GDR
    • Audit Schema Object Management
    • Audit Schema Object Take Ownership
    • Audit Server Alter Trace
    • Audit Server Object GDR
    • Audit Server Object Management
    • Audit Server Object Take Ownership
    • Audit Server Operation
    • Audit Server Principal Impersonation
    • Audit Server Principal Management
    • Audit Server Scope GDR
    • Audit Database Object Take Ownership
  • You may need to review SQL Server folders permissions, but be careful here. First of all make sure that service account and DBAs have access to the folders. To get a list of the permissions that are granted by SQL Server setup use this URL: http://msdn.microsoft.com/en-us/library/ms143504(v=sql.105).aspx#Reviewing_ACLs.
  • You may need to provide the list of logins with specific OS rights (for example, "Log on as a service").
  • Remove logins without permissions.
  • Remove orphaned database users (where there is no SQL Server logins exist).
  • Fix broken database users (SQL logins mapping) with "ALTER USER" statement or with sp_change_users_login stored procedure.
    • Refer to this tip for more information.

Every company has different requirements for the audit, so the list could be longer or shorter. Make sure you know these requirements, know what tables you need to audit, know where sensitive data is stored and how it accessed. Also, find out what are your company's industry standards. I hope this will help you to be ready for your next audit.

Note: All security changes you are planning to make should be tested first on your test servers to make sure that there are no dependencies (applications specific requirements, legacy applications etc.) and that applications are still functioning properly.

Next Steps
  • Build a checklist that works for your environment
  • Have your scripts ready and start collecting data.
  • Check your servers and databases.
  • Read more tips on SQL Server Auditing and Compliance.


sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip



About the author
MSSQLTips author Svetlana Golovko Svetlana Golovko is a DBA with 13 years of the IT experience (including SQL Server and Oracle) with main focus on performance.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips



Comments For This Article




Saturday, July 16, 2016 - 10:06:32 PM - Svetlana Back To Top (41902)

No, the database size shouldn't increase. Audit files could be saved on a file system or in the Event log. There is no option to save them in the database out of box.


Friday, July 15, 2016 - 2:20:21 AM - Vin Chacko Chandy Back To Top (41895)

 Hi Team,

 If a database audit is enabled, is their any possibilites for increasing the database size? I have re-directed the audit log to the application log for windows. Can you please comment

 


Monday, January 27, 2014 - 8:08:28 PM - Jfay_dba Back To Top (29245)

You should also check things like the owner of each database and if the database(s) are set to trustworthy.  Having an effective mapping of users / logins to effective permissions will always help.  


Friday, March 8, 2013 - 6:52:04 PM - Svetlana Golovko Back To Top (22675)

Thank you, Jeff!

That's a big list - 190 points! I tried to cover here the best practices, but every company has different security requirements.

You can check this URL if you woulld like to contribute to the site: http://www.mssqltips.com/contribute.asp.


Friday, March 8, 2013 - 9:44:42 AM - Jeff Back To Top (22667)

I am also new to the DBA world and liked your article.  My first and main assignment at this job is to secure all our production and test databases.  I was given a 190 point checklist that I must follow to secure these databases.  Please let me know if you guys would like me to post the list

I think that maybe we should have a resources item on this site dedicated to SQL Security since it is a very important subject.  Often it’s not the check that is difficult, but the repercussions of executing what the check is asking for that can be the problem and experienced DBA’s can help with that. 

Please let me know what you think 

Jeff


Monday, November 26, 2012 - 11:55:21 AM - Svetlana Golovko Back To Top (20543)

Thank you, SJ. These items are definitely important.


Thursday, November 22, 2012 - 7:21:58 PM - WEB Back To Top (20479)

Good article! Looking forward to part 2.


Wednesday, November 21, 2012 - 9:49:38 AM - SJ Back To Top (20457)

As a current Security and IT Compliance manager and a former SQL Server DBA, I would also add the following items to the things to audit for:  

1) Encryption (Transparent Data Encryption or other disk based encryption) as data at rest is becoming more and more of a requirement and the Key Management Processes.  

2) Disaster Recovery or Business Continuity Process documentation.  Have you documented/tested your failover processes? What is the Recovery Point Objective (RPO or the amount of acceptable data loss) and Recovery Time Objective (RTO or the amount of time allowed to come back online) and do these values match the business requirements?  

3) Restore tests.  I don't ask about backups, I ask about restores!  Backups are no good unless the restore works!  

Thanks!

SJ


Wednesday, November 21, 2012 - 3:09:45 AM - Gopalakrishnan Arthanarisamy Back To Top (20448)

Excellent Checklist to perform Audit on SQL Server Instances.


Wednesday, November 21, 2012 - 2:26:05 AM - Devi Prasad Back To Top (20446)

First I would like to welcome you to the world of DBAs. Good Article!

 

 















get free sql tips
agree to terms