This document provides an overview of 10 steps to secure Microsoft SQL Server databases. It discusses establishing physical security, isolating protected data, reducing the attack surface, using least privileged access, maintaining secure connections, categorizing data, protecting against SQL injection, conducting vulnerability assessments, encrypting data, and implementing row-level security. The document also includes demonstrations of SQL Server vulnerability assessment and transparent data encryption features. It emphasizes that securing SQL Server is an ongoing and continuous process.

1. Overview of Microsoft
SQL Server Security
 Gary Manley

2. Threat Landscape

3. Threat Landscape:
Public Sector
Frequency 22,788 Incidents, 304 with
confirmed data disclosure
Patterns
identified
Cyber-Espionage, Privilege
Misuse, Everything Else, Web
Applications, and
Miiscellanious Errors
represent 92% of breaches
Threat Actors External (67%), Internal (34%,
Partner (2%), Multiple parties
(3%)
Actor motives 44% Espionage, 36%
Financial, 14% Fun
0 20 40 60 80 100 120
Internal
Credentials
Medical
Secrets
Personal
Top 5 Data Compromised in
Public Sector
Type

4. Threat Landscape:
Public Sector
Takeaways
 Cyber Espionage or Cyber War
 Amount of phishing exploits shows
a lack of cyber resilience in the
public sector
 Attackers enter through
compromised system and move
laterally
 DBAs must assume breach
0 20 40 60 80
Vulnerability
Downloader
Password dumper
Spyware/
Keylogger
C2
Backdoor
Phishing
Cyber Espionage Actions
Type

5. 10 Steps to Secure SQL

6. 1. Establish a physical security presence

7. 2. Isolate Protected Data

8. 3. Reduce your attack surface
A. Rename SA account, set password
B. Only install necessary features in SQL Server
(xp_cmdshell)
C. Only install necessary programs in O/S
D. Close unused ports
E. Update, Update, Update

9. 4. Use least privileged access
A. Read access to views instead of tables
B. Use Windows groups to restrict access
C. Restrict access to DB processes (maintenance
acct, not admin)

10. 5. Maintain Secure Connections
A. Use encrypted connections
B. Listen on non-standard ports

11. 6. Categorize your Data
Military Classification Business Classification
Top Secret Confidential/Private
Secret Sensitive
Confidential Internal
Unclassified Public

12. 7. Protect against SQL Injection
 Use of Prepared Statements (with Parameterized Queries)
 Use of Stored Procedures
 Escaping All User Supplied Input
 Enforcing Least Privilege
 Performing White List Input Validation as a Secondary Defense

13. 8. Conduct Vulnerability Assessment
 Cybersecurity Risk Frameworks
 (NIST, ISO 27000 series, COBIT)
 ISACA Audit/Assurance Program
 SSMS Vulnerability Assessment

14. SSMS Vulnerability Assessment
Demo

15. 9. Data Encryption
 Bitlocker (drive encryption)
 NTFS Encryption (Folder encryption)
 TDE Encryption (File Encryption)
 Back up encryption (File Encryption)

16. How it Works
SQL Server or SQL Database
ADO .NET
Name
Wayne Jefferson
Name
0x19ca706fbd9a
Result SetResult Set
Client
Name SSN Country
0x19ca706fbd9a 0x7ff654ae6d USA
dbo.Customers
ciphertext
"SELECT Name FROM Customers WHERE SSN = @SSN",
0x7ff654ae6d
ciphertext
"SELECT Name FROM Customers WHERE SSN = @SSN",
"111-22-3333"
Encrypted sensitive data and
corresponding keys are never seen
in plaintext in SQL Server
trust boundary

17. SSMS TDE
Demo

18. Row-Level Security

19. Customer Benefit
Fine-grained
Access Control
Keeping multi-tenant
databases secure by limiting
access by other users who
share the same tables.
Application
Transparency
RLS works transparently at
query time, no app changes
needed.
Compatible with RLS in other
leading products.
Centralized
Security Logic
Enforcement logic resides
inside database and is
schema-bound to the table it
protects providing greater
security. Reduced application
maintenance and complexity.
Store data intended for many consumers in a single database/table while at the
same time restricting row-level read & write access based on users’ execution
context.

20. RLS Concepts
 User-defined inline table-valued function (iTVF) implementing security logic
 Can be arbitrarily complicated, containing joins with other tables
 Applies a predicate function to a particular table (SEMIJOIN APPLY)
 Two types: filter predicates and blocking predicates
 Collection of security predicates for managing security across multiple tables
CREATE SECURITY POLICY mySecurityPolicy
ADD FILTER PREDICATE dbo.fn_securitypredicate(wing, startTime, endTime)
ON dbo.patients

21. Row-Level Security Demo

22. 10. Rinse and Repeat
A continuous process

23. Resources
Security Center for SQL Server Database
& SQL Database
 https://msdn.microsoft.com/en-us/bb510589.aspx
SQL Server Security Blog
 Additional examples, useful tips and tricks
 http://blogs.msdn.com/b/sqlsecurity/
ISACA Audit/Assurance Program
 http://isacala.org/doc/WAPMSQL_Server_DB_Research_7July2011.pdf