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

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

3. Contact Information
Mail:
Blogs:

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

5. Surface area concerns
“Outside” of SQL Server

6. 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?

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

8. 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?

9. 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?

10. Server Level Concerns
“Inside” SQL Server

11. Server level security
Logins
Roles
Permissions

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

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

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

15. Visualizing Permissions

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

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

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

19. Database Level Concerns
User Databases

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

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

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

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

24. 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?

25. 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?

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

27. Questions? Mail: kbriankelley@acm.org Twitter: @kbriankelley Blogs: