1. Code-Less Securing of SQL Server
Argenis Fernandez
SurveyMonkey

2. About Me
Member of the Database Engineering team at SurveyMonkey (We’re hiring!)
Former Senior Consultant: SQL Server Core, Microsoft Consulting Services
Microsoft Certified Master: SQL Server 2008 and Microsoft Certified Solutions Master: Data Platform (Charter)
Idera SQL Server ACE
DBA/Dev & SysAdmin for 15 years
Love OS, SQL internals/Security
Frequent Speaker (PASS Summit, SQLRally, 24HOP, SQLBits, TechEd)
Twitter enthusiast, rather infrequent blogger
Founder, PASS Security Virtual Chapter
2 |
9/18/2018
The Secret Life of an INSERT Statement

3. Why Bother?
Security is hard
It’s hardly convenient
This is why…

4. Please visit Troy Hunt’s web site for more information on SQL injection: http://www.troyhunt.com/

5. Agenda The sa account Database Firewalls Active Directory IPSec
Transparent Data Encryption (TDE)
Auditing
Contained Databases
Server Core
Things to do
Things to avoid

6. The sa account Omnipotent account Rename it Disable it
Don’t ever use it
Forget that it even exists
What sa account are you talking about?

7. Demo – sa honeypot

8. Database/Application Firewalls
Can prevent SQL injection attacks at the app level
Can also inspect every TDS packet sent to the server
Can work alongside agents to further secure access to the database

9. Active Directory security
Use AD Groups whenever possible
Use GPOs to enforce strength/password expiration (careful!) policies for service accounts
Isolate Dev/Test/QA/Prod under individual OUs, or better yet: isolate on different domains/forests

10. IPSec Provides network-level encryption
Can be restricted to a set of hosts
Easier to setup than app/web level
Any host affected by the policy is automatically protected
“We need to encrypt data on the fly!”

11. Transparent Data Encryption (TDE)
Provides storage-level encryption
It’s managed on a per-instance basis
Can have a significant performance impact
“We need to encrypt data at rest!”

12. Auditing You should (at the very least) audit DDL
You might be forced to audit for compliance
Forensic trail
The transaction log is a gold mine
Default trace (in deprecation path now)
Audit successful logins?

13. Contained Databases
Logins contained in the database, not kept in master
Standard logins/users can be made contained
You want to use this feature if you’re using AlwaysOn Availability Groups and/or Database Mirroring
Careful! There are gotchas

14. Demo – Contained Databases

15. Windows Server Core Reduced surface area Less Patching!
Less “let me login to the server and do stuff!”

16. Things to Do
SANITIZE all of your inputs. TWICE if you must (app layer/SQL layer)
LOCK YOUR WORKSTATION
SCAN your network periodically for new SQL instances
HIRE A PROFESSIONAL to do a penetration test that includes social engineering attacks
EDUCATE your Developers/Vendors!

17. More Things to Do ENFORCE Principle of Least Privilege
REDUCE your exposure (surface area)
LOCKDOWN Production!

18. Things to Avoid
SQL Servers sitting on boxes with routable IP addresses
xp_cmdshell
TRUSTWORTHY
Using the same service accounts/passwords across Dev/Test/QA/Prod
Use non-standard port numbers – makes things worse

19. Get This Book!
Denny Cherry: “Securing SQL Server”, 2nd Edition

20. How To Get In Touch With Me
Blog: (tag: Security)
PASS Security Virtual Chapter:
For access to many other SQL Server professionals, use the #SQLHelp hashtag on Twitter