1. Dynamic data masking deep dive
Bill Portman, Global Database Manager, Urban Science
02/24/2018

2. About me Bill Portman, Global DBA Manager, Urban Science
Urban Science is a data analytics company specializing in the automotive industry headquartered in Detroit MI
900+ employees worldwide
530 SQL Servers,
13k databases, 230tb of data, 2 Mongo servers
20 years experience in database technologies
IBM AS400 (My first SQL statement)
SQL Server versions: 6.5 through current
Network manager, web master, software engineer, DBA
LinkedIn:
Michigan summers, Florida winters

3. Security Survey By a raise of hands…
How many of you are DBAs versus Database & Software Developers?
How many of you manage sensitive data (PII, health care, payment card)?
How many of you have a data protection plan?
How many of you support international data and/or heard of EU GDPR?
Data regulations and privacy laws are not getting simpler
More and more complex (HIPAA/PCI/GDPR)
More and more time consuming to manage
As a DBA or data custodian, it is up to you to protect that data
Team Data Defenders – the voice of the data
Before we get started let’s take a few short surveys
What is GDPR – The EU General Data Protection Regulation
The EU General Data Protection Regulation (GDPR) replaces the Data Protection Directive 95/46/EC and was designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens data privacy and to reshape the way organizations across the region approach data privacy.

4. Why is Data Protection Important?
Failure to protect the data can result in:
Why is data protection so important?
Well, if data is leaked,
You could be terminated
You and your company could be sued
You company could lose business and it’s reputation damaged
While rare, potential criminal actions could be taken against you
Your career is on the line
You and your company could suffer financial losses that result in bankruptcy,
My team’s name is The Data Defenders. The team’s name brings to the forefront the importance of data protection. Every decision my team makes, it makes based on protecting the data. Be the voice of the data
GDPR Penalties
Up to €20 million, or 4% annual global turnover
Gives rights to impacted parties to also sue

5. Data Protection Plan Contents
The technology stack of a data protection plan is made up of several technologies:
Data Encryption
Transparent Data Encryption (TDE) - Prevents attaching the MDF/NDF/LDF and restoring databases from backups w/o the encryption certificate and private key. Data is still readable via SSMS and not encrypted in-flight
Column Level Encryption - data not readable using query unless symmetric key is open and decrypted by the certificate. May require extensive code updates
Always encrypted - Protects data in-flight
Backup encryption
Least privileges – assigning only the permissions needed for the job
Row level security, database hardening, proper user security role management and approval process
Data obfuscation – Masking or scrambling the data to make it unreadable to audiences who should not see the real data.
Today’s companies should have a data protection plan.
The data protection plan is made up of many different facets
- Who has access to the data, what level of access do they have? What is your backup process? When are consistency checks run? And so on
From a technology standpoint, it should include these topics:
Data Encryption – how will we encrypt the data
Backup encryption, retention, & storage
Least privilege security model
Data storage and acceptable use guidelines
Data obfuscation – masking or scrambling

6. SQL Server Security Features
Prior Versions
TDE
Backup Encryption
Auditing
SQL 2016 Additions
Row-level security
Always Encrypted
Dynamic data masking
TDE requires Enterprise
SSMS 17.x
Who knows what were the latest security features introduced?
Beginning in version 2008, Microsoft began investing heavily into more and more security features within SQL Server
In 2008 R2, TDE was introduced. I think auditing was also introduced in 2008 too
In 2014, backup encryption was introduced
And most recently, In 2016, Row-Level security, Always encrypted and dynamic data masking were introduced
SQL2016 SP1 unlocked more editions to use these features
Data privacy/protection is not getting any easier
More and more regulations are being introduced (GDPR)
Today we are going to be discussing Dynamic Data Masking. If time permits, we can discuss other security measures you can take to protect your data

7. What is Data Masking?
Data masking may also called data obfuscation, sanitization, scrambling, de-identification and many other terms
It is the process of taking data and making it unreadable so end user’s cannot see the actual data values
Data masking is generally applied to sensitive data that if leaked could expose you and your company to lost business, embarrassment, and/or civil or criminal penalties
Two different approaches to masking data
DML - replacing the actual data (test data set) – Grid Tools
DDL – change definition of a table to mask the data. Data values do not change – MS implementation
SQL Server DDM is considered a masking or obfuscation solution, not scrambling or de-identification
Data is real data on disk
If your end user needs accurate data, you should not mask that data

8. Types of Data to Mask
Personally Identifiable Information (PII) Data – Data that uniquely identifies a person such as:
Full name, address, phone, address, SSN or national health care number, passport number, date of birth, driver’s license number
Vehicle Identification Number (VIN) – yep, VIN is PIII according to NHTSA
Payment card industry (PCI)
Credit card number, expiration date, security code, etc.
Health care data
Health Insurance Portability and Accountability Act of (HIPAA) defines the protection requirements of Protected Health Information (PHI).
Any data that will help you achieve GDPR compliance

9. SQL Server Dynamic Data Masking
First introduced in SQL Server 2016
Available in all editions of SQL Server (Web/Express requires SP1)
“Helps” prevent unauthorized access to sensitive data (Remember - only one part of a total data protection plan)
Obfuscates the data by applying masking rules (functions) to the result set.
Strictly a DDL statement. The underlying data does not change
Easy to implement, part of column definition
Possible DDM use cases
HIPAA, PCI compliance, GDPR
Personally identifiable information (PII)
Credit card, SSN, etc.

10. Four available masking functions
Default() – full masking to the data type of the field
String data types – Masks values with X’s (char, nchar, varchar, nvarchar, text, ntext)
Numeric data types - Uses the value of zero (bigint, int, decimal, int, money, numeric, smallint, smallmoney, tinyint, float, real)
Date and time data types - Uses :00: (date, datetime2, datetime, datetimeoffset, smalldatetime, time)
Binary data types – uses a single byte of ASCII value 0 (binary, varbinary, image) ()
Exposes the first letter of the address, X’s the remaining out with constant value of .com for suffix
Random()
Used for numberic data types. Returns a random numeric value within a specified range
Partial()/Custom String
Used to display only parts of a string based on the arguments passed into the function
Most commonly used for fixed length fields like SSN, credit card number, etc.

11. Permissions / Security Concerns
To define a mask, you must have CREATE TABLE and ALTER on the schema
Adding, replacing, modifying the mask of a column requires ALTER ANY MASK and ALTER permission on the table & schema.
Users with SELECT, db_datareader will see the masked data when issuing queries
UNMASK permission needed to see the unmasked data (DBO’s have this permission by default but can be revoked)
The CONTROL permission on the database includes both ALTER ANY MASK and UNMASK
Caution – all data touch points must be reviewed to make sure the proper masking rule is or is not applied. Failure to do so could result in that touch point receiving unmasked data when it is not supposed to.
Application interfaces, reports, services, users with direct query access, etc.

12. Data Masking FYI’s/Gotchas/Limitations
Masking does not prevent updates to a column. Members with UPDATE permission or higher can make updates even though they may see masked data
Using SELECT INTO or INSERT INTO or using the import/export wizard to copy data from a masked column to another table or file results in masked data in the target table or file if that user does not have the UNMASK permission. Applies to #temp and ##temp tables also.
Limitations – a masking rule cannot be applied to the following
Always Encrypted and FILESTREAM columns
Computed columns. However, if the computed column depends on a column with a mask, then the computed column will be returned masked data
COLUMN_SET or a sparse column that is part of a column set.
A column with data masking cannot be a key for a FULLTEXT index
In some cases, cannot be performed on a column with dependencies (ex: an index). You must remove the dependency first, add the data masking, and recreate the dependency

13. More Gotchas
Brut force techniques may be used to determine the real values or ranges (example later on)
SELECT * FROM Employees WHERE Salary BETWEEN AND
Microsoft’s own documentation states:
“The purpose of dynamic data masking is to limit exposure of sensitive data, preventing users who should not have access to the data from viewing it. Dynamic data masking does not aim to prevent database users from connecting directly to the database and running exhaustive queries that expose pieces of the sensitive data. Dynamic data masking is complementary to other SQL Server security features (auditing, encryption, row level security) and it is highly recommended to use this feature in conjunction with them in addition in order to better protect the sensitive data in the database.”

14. Dynamic Data Masking DDL Statements
CREATE TABLE – use the MASK WITH clause and specify the function
ALTER TABLE ALTER COLUMN – use the ADD MAKED WITH clause and specify the function
DROP MASK – to drop masking use the DROP MASKED clause on the ALTER TABLE ALTER COLUMN command

15. Demo Create DDM database and populate an employee table
Apply DEFAULT(), RANDOM(), (), and PARTIAL() functions to various fields using:
CREATE table and ALTER table commands
Test it using two different users – reader and DBO user
Use brut force techniques to determine real values
Test various data anomalies ( not being , data does not conform to expected lengths, etc.)
Granting UNMASK to read user and revoking from DBO user
Test some of the limitations
Computed column, sparse data, etc.
Test views, stored procedures, etc.
Move some data around
Review metadata and how to prevent updates to masking rules

16. Dynamic Data Masking Use Cases
Can be used in your application to mask sensitive data for the application front end, provided that:
All data touch points are analyzed to ensure the UNMASK permission is set appropriately for application logins (Application, reports, services, etc.)
Tightly controlled servers by dedicated DBA team – Only DBA team can manage servers
Users do not have direct query access through SSMS or other non managed ad-hoc tool
Where shouldn’t you use dynamic data masking
Protecting loosely controlled DEV/QA servers not a good candidate (everyone has DBO or DDL ADMIN) that have sensitive production data on it
People have SSMS access and can directly query the data
Easy to use brute force
Unencrypted databases with sensitive data

17. New SSMS (17.x) Features Vulnerability Assessment (17.4)
Security Dashboard and scan engine to report on possible database security issues
Support for SQL up within SSMS
SQL Data Discovery and Classification (17.5)
SSMS Tool for discovery, classifying, labeling and reporting on sensitive data in your database

18. Questions & Discussion

19. References