The Dirty Business of Auditing Auditing SQL Server K. Brian Kelley PASS Security Virtual Chapter

Short Bio Database Administrator / Architect Infrastructure and security architect Incident response team lead Certified Information Systems Auditor (CISA) SQL Server security columnist / blogger

Contact Information Mail: kbriankelley@acm.org Twitter: @kbriankelley Blogs: https://truthsolutions.wordpress.com/ https://gkdba.wordpress.com/

Agenda for Today SQL Server (and OS) Surface Area Server Level Auditing Database Level Auditing

Surface area concerns “Outside” of SQL Server

What to look for (OS) Who are the members of local Administrators? What shares are exposed? What other applications are installed? Is the server being properly patched and maintained?

What to Look For (specific to SQL Server) What network protocols are you using? What ports is SQL Server is listening on? Are remote connections allowed? Are you configured for Kerberos authentication? Are you using encrypted connections?

Questions to ask What needs to connect to SQL Server? How does it need to connect? What risk is there for the personnel in Administrators? What risk do the other apps pose?

Things to consider Can I restrict network access to just the SQL Server port? Can I reduce the # of admins on the server? Can I remove any of the additional applications? If the server isn’t patched properly, how do you get it so?

Server Level Concerns “Inside” SQL Server

Server level security Logins Roles Permissions

What to Look For in logins Windows users (not service accounts) A lot of SQL Server logins Windows logins that no longer exist (requires lookup against Active Directory) Non-hardened sa account (active & not re-named)

Logins a little deeper Password policy enforcement (SQL Logins) Server role membership Server-level permissions

More on Server Roles Look for User-Defined Server Roles Check for Permissions Determine if any “replace” the built-in roles

Visualizing Permissions

Diving into Permissions CONTROL permission at Server level IMPERSONATE of sa or sysadmin logins Remember inheritance of permissions because of scopes

Questions to Ask Who needs to connect? What permissions are actually needed? Do the cascading permissions cause issues at the DB level?

Things to consider Goal is the Principle of Least Privilege Legitimate user accounts are targets Undocumented permissions / roles could be a sign of malicious activity, but not necessarily.

Database Level Concerns User Databases

Database First Steps How database users map to server logins Use of guest user (except system DBs) Database Owner (according to sys.database_principals) Database Owner (according to sys.databases)

Database roles Fixed roles User-defined roles db_owner db_securityadmin db_ddladmin db_datareader db_datawriter User-defined roles Check permissions Check nesting

Carry those to permissions Permissions at database securable level Permissions at schema securable level

If Encryption is involved Key Escrow Who has permissions? VARBINARY and NVARCHAR columns

Questions to ask If an application uses a login that’s the database owner, does it need to? Corollary: 3rd party product – Will the 3rd party support? Do end users have too many permissions? Do service accounts have too many permissions?

Things to consider If db_datareader and db_datawriter are in use, can user- defined roles with explicit permissions be used? Who has access to sensitive data? If permissions are identified as too much, how can the model be simplified and permissions tightened?

Agenda for Today SQL Server (and OS) Surface Area Server Level Auditing Database Level Auditing

Questions? Mail: kbriankelley@acm.org Twitter: @kbriankelley Blogs: https://truthsolutions.wordpress.com/ https://gkdba.wordpress.com/