SQL Server Security in an Insecure World

Gianluca Sartori@spaghettidbasqlconsulting.it

Say thank you to our Sponsors :

Gianluca Sartori

Independent SQL Server consultant

SQL Server MVP, MCTS, MCITP, MCT

Works with SQL Server since version 7

DBA @ Scuderia Ferrari

Blog: spaghettidba.com Twitter: @spaghettidba

Agenda

Security Matters What should I protect? How can I prevent attacks?

Data Breaches are Common

Data Breaches are Costly $450.000- $850.000 for large business $35.000 - $65.000 for small businesses + Reputational damage + Legal risks

-- Source: UK Government

Security Matters

Security Matters

Security must be considered from the start Securing afterwards is extremely costly Poorly secured ecosystems are not always possible to fix

Security is a process, not a product No single “magic” solution Ongoing process

Attackers get smarterSecurity must be stronger

Information Security Principles

CIA triad

Information Security Principles

Confidentiality Information cannot be disclosed to unauthorized individuals

Integrity Data cannot be modified in an unauthorized or undetected

manner

Availability Information must be available when needed

What happens to insecure systems?

Confidentiality Data leaks

Integrity Unauthorized data modifications Frauds

Availability Outages

Attack Methodology

1. Scan for Vulnerabilities / Access 2. Gain Access 3. Escalate Privileges 4. Maintain Access 5. Cover Tracks

Looks complicated? It’s not!

DEMO

How fast can a [poorly configured] system be compromised?

… damn fast!

How can I prevent it?

Implement security policies at all levels

Physical Security External Network Internal Network Host OS Application Database

Physical security

Disallow physical access to the infrastructure Servers

Console Ports Disks

Clients DBA workstation + L

What about the cloud?

Networking devices

Switches Routers Cables

Network Security

Exclude External network as far as possible

Implement proper network segmentation vLANs separate servers in groups

Role Sensitivity

Reduce “implied trust” relationships between servers Users / Servers is NOT proper segmentation

Encrypt communications

Host OS

Regular patching Antivirus Configuration security best practices

Shut down unneeded services Reduce attack surface

Permissions Least Privilege Auditing Logging

Application

Application is the most vulnerable component in the stack

Secure from the start Thorough design and code security review

Input validation Authentication Authorization Error handling Auditing Logging

SQL Injection

SQL Injection

SQL Injection

Has been known for years …yet N.1 in OWASP TOP 10 security risks Easy to detect with automated tools (SQLmap) …yet very common in the wild

Potentially destructive

Injection techniques

OR-based injection Stacked queries injection UNION-based injection Error-based injection Boolean-based blind injection Time-based blind injection

DEMO

Let’s sneak in!!

SQL Injection –Fixes

Use bind parameters Enforces parameter data type Is not affected by regional settings Allows complex input Aggressive input sanitation does not

SQL Injection – False fixes

ORMs do not avoid it Stored Procedures do not avoid it Input validation is not enough

Obfuscated attacks Headers / query strings can be manipulated

Not limited to web applications NoSQL is vulnerable as well! .NET’s String.Format is just plain concatenation!!!

DEMO

Let’s break things!!

What happened?

We damaged the database, the instance and the OS because we could

Apply least privilege At the Database level At the Instance level At the OS level … at every level!

Authenticate the user or the application?

Prefer Windows Authentication when possible No need to provide password No need to store passwords in config files

SQL Authentication is less secure Clear text < SQL2005 RC4 < SQL2012 Password policies

SQL Server Security - Authentication

SQL Server Security - Authentication

Passwords are problematic Users tend to forget

Sticky Notes Same password, multiple places Have I been pwnd?

Use passwords that you cannot remember Use a Password Safe

Keepass Password Safe

SQL Server Security - Authorization

Principle of least privilege: Users must be granted only the privileges essential for

their work

Typical scenario: users are granted sysadmin role users are granted db_owner role very common! users are granted built-in database roles

Security must be taken into account from the start!!!

SQL Server Security

Best Practices:1. Create application specific roles with no privileges2. Grant minimum needed permissions to roles3. Add users to roles4. Don’t grant permissions to users5. Use application roles to enhance security

Windows groups <> database roles NEVER, EVER grant server roles to “regular” users

SQL Server Security

Additional features:

TDE: Transparent Data EncryptionEncrypts database files and backup files

SSL Network EncryptionEncrypts the communications channel between SQL Server

and client computers

SQL Server 2016 New Security Features

Always Encrypted

Column-Level encryptionData is encrypted both at rest and in memoryDecryption happens on the client

Row-Level SecurityFilters rows available to users

Dynamic Data Masking Obfuscates sensitive information

Resources

OWASPhttp://www.owasp.org

Security checklist for the Database Enginehttp://msdn.microsoft.com/en-us/library/ff848778(v=SQL.105).aspx

Troy Hunt’s bloghttp://www.troyhunt.com

Troy Hunt’s free Pluralsight webinar: Why SQL Injection Remains the #1 Web Security Risk Today

http://www.troyhunt.com/2015/06/free-recorded-webinar-on-pluralsight.html

Q&A

Questions?

Stick around for RAFFLE and the AFTER EVENT!

All our volunteers and organisers do not get paid for organizing this event – If you see them, please: Give them a hug Shake their hand Say thank you Spread the word Get involved yourself

Don’t forget to thank the sponsors for their support Thank the speakers for donating their time, energy and expenses Don’t forget the feedback!