1. Securing Data with SQL Server 2016
By G.R. Prithiviraj Kulasingham
Principal DBA, Pearson Lanka

2. Introduction Data is the new Oil – Information is money
One side is to make use of data
Other side is securing the data
Over 480 million data records are stolen in 2015
57% of crimes conducted by outsiders
It means 43% by insiders
Mobile phone is identified as the weakest link

3. What Attackers Do?
Intruders try to login using commonly used passwords, defaults
They gather related information from Linked-In, Facebook etc.
SQL Server uses the machine name and port 1433 on default installation
They may look for backup files as they are less secured generally
Gather useful information like Passwords, Personal Data, Financial Data etc.
Sell to competitors, Impersonate, or publish
Disrupt operations by removing logins, altering schema or dropping tables
SQL injection
Some send “heavy requests” or loads of requests to lead to Denial of Service(DOS)

4. Identify the Attackers
Hackers including Criminals
They scan the internet/ open networks
Local users
Legitimate users but go beyond their limit
People Have access for one purpose but use for different purpose
Can a windows admin check a database?
Can a database Admin check the benefits of the CEO?

5. SQL Server Security Overview
How many have used SQL Server 2000 or before?
Initially it allowed blank password for “sa”
Following an attack, sp3 prevented it
SQL Server added many features in SQL Server 2005
User/Schema separation
Passwords to follow security policy, expiration – prevents Intruders
Encryption of sensitive data
Surface area configuration
Granular Permissions

6. SQL Server Security Overview
SQL Server 2008 came with added feature set
Policy Based Management
Transparent Data Encryption, Protected by Database Master Key & Service Master Key
Extended Protection Support
Secure Connection
Kerberos Authentication

7. SQL Server Security Overview
Database Audit – captures who did what
Adding automatic accounts is stopped
Encryption algorithms improved

8. Securing from Intruders
Security is not just DBAs job – Can’t rely just on application/Network security
What protocol to use?
Simple Applications & SQL Server on same machine: Can use shared memory
MDAC 2.8 or earlier cannot use shared memory protocol
Named pipes work well over LAN
Complex applications with queues, or over internet should use TCP/IP
Are you using default named pipes or default ports?
Keep the SQL Server Browser service disabled
Make sure database users have strong password and expiration policy
Including application users…

9. Securing from Intruders
Log and Monitor failed logins– Or to admins
Monitor long running queries –
They not only consume resources and lead to deny many other requests (DOS) but also trying to gather all the information you have
Use security best practices during database design too

10. Securing from Internal Users
Use secure connection
It has performance issues: Connection takes another roundtrip; Each packet goes through an encryption and decryption process
Highly recommended for databases managing credit cards, banking, stocks and other sensitive data
Secure connection is made at server level not database level

11. database design security best practices
Limit direct access to sensitive information
Either separate sensitive information or define views and access only through views
Stored Procedures provide better security than ad-hoc queries
Actual code and Tables are hidden to network
SQL Injection threat is minimized
Application user should run with minimum privileges (Use granular permissions)

12. database design security best practices
Don’t keep sensitive data in unencrypted form
EncryptByKey
EncryptByPassPhrase
EncryptByKey provides better security than EncryptByPassPhrase
Both needs code changes
Subject to exposure to admins

13. database design security best practices
SQL Server 2016 introduces Always encrypted
Data is stored always in encrypted form in the database
No need to change the client application except change of driver
Driver is responsible for encryption and decryption
Either deterministic or randomized algorithm could be used
Always Encrypted keeps the data encrypted and protect even from DBAs
It allows the Business users to have control over the data

14. How Always Encrypted differ with TDE?
TDE encrypts the data “in rest”
Decrypted at Read; Encrypted at Write
Travels in the network in unencrypted form unless SSL is used
DBAs can read the data by simply accessing
It prevents only from illegal copying, or stealing the backups
Database level setting
Always Encrypted keeps the data encrypted until the client application reads
Encryption/Decryption happens at client side
Unless the same key/certificate is used, data cannot be decrypted
Only selected columns are encrypted

15. Dynamic Data Masking
Dynamic Data Masking Allows users to read only part of the data
Not for Admins; But for people with lesser access
Need UNMASK permission to read the data

16. Row Level Security Now you can grant permission at granular level
Based on a property of data security could be defined.
FILTER PREDICATE controls the rows selected
BLOCK PREDICATE controls data changes

17. References
Row Level Security:
Dynamic Data Masking:
Always Encrypted:
Encrypting connections:

18. Questions
“Judge a man by his questions rather than by his answers.”  ― Voltaire
“He who knows all the answers has not been asked all the questions.” ― Confucius

19. Sponsors Platinum Sponsors Platinum Raffle Sponsors
Gold Sponsors
Gold Raffle Sponsors
Silver Raffle Sponsors
Bronze Sponsors
Bronze Raffle Sponsors
Crystal Raffle Sponsors

20. Thank you
Please evaluate this session: sqlsaturday.com/535/sessions/SessionEvaluation.aspx
Please evaluate the event at the end of SQLSaturday: sqlsaturday.com/535/EventEval.aspx