Code-Less Securing of SQL Server Argenis Fernandez SurveyMonkey

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) 2012-2013 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

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

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

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

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?

Demo – sa honeypot

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

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

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!”

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!”

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?

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

Demo – Contained Databases

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

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!

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

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

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

How To Get In Touch With Me Twitter: @DBArgenis Blog: http://sqlblog.com/blogs/argenis_fernandez (tag: Security) E-Mail: Argenis@SurveyMonkey.com PASS Security Virtual Chapter: http://security.sqlpass.org For access to many other SQL Server professionals, use the #SQLHelp hashtag on Twitter