Implementing the Most Common Security

Standard Regulations in SQL Server and

Azure

Michelle Gutzait
Principal Consultant at www.Pythian.com
gutzait@Pythian.com
Who are you?

 How many DBAs?

 How many sysadmins?

 How many developers?

 Other / Here by accident?

Understand security and privacy laws,
regulations and guidelines
Broadly applicable laws and regulations

 Sarbanes-Oxley Act (SOX)

 Payment Card Industry Data Security Standard (PCI DSS)
 Gramm-Leach-Bliley Act (GLB) Act
 Electronic Fund Transfer Act, Regulation E (EFTA)
 Customs-Trade Partnership Against Terrorism (C-TPAT)
 Free and Secure Trade Program (FAST)
 Children's Online Privacy Protection Act (COPPA)
 Fair and Accurate Credit Transaction Act (FACTA), including Red
Flags Rule; Federal Rules of Civil Procedure (FRCP)
Industry-specific guidelines and requirements

 Federal Information Security Management Act (FISMA)

 North American Electric Reliability Corp. (NERC) standards
 Title 21 of the Code of Federal Regulations (21 CFR Part 11)
Electronic Records
 Health Insurance Portability and Accountability Act (HIPAA)
 The Health Information Technology for Economic and Clinical
Health Act (HITECH)
 Patient Safety and Quality Improvement Act (PSQIA, Patient
Safety Rule)
 H.R. 2868: The Chemical Facility Anti-Terrorism Standards
Regulation
International laws

 The GDPR (General Data Protection

Regulation) data protection law framework
across the EU for personal data
 Personal Information Protection and
Electronic Documents Act (PIPED Act, or
PIPEDA) — Canada
 Law on the Protection of Personal Data Held
by Private Parties — Mexico
 European Union Data Protection Directive;
Safe Harbor Act
Specific regulation by zone

 State
 Province
 Country
 City
 …
Sarbanes-Oxley Act (SOX)
What Sarbanes-Oxley covers: Enacted in 2002, the
Sarbanes-Oxley Act is designed to protect investors
and the public by increasing the accuracy and
reliability of corporate disclosures. It was enacted
after the high-profile Enron and WorldCom financial
scandals of the early 2000s. It is administered by the
Securities and Exchange Commission, which
publishes SOX rules and requirements defining audit
requirements and the records businesses should
store and for how long.
Who is affected: U.S. public company boards,
management and public accounting firms.
SQL Server and SOX
 Data integrity ownership and responsibilities communicated to
appropriate business owners acceptance of responsibilities.
 Key database systems inventoried and owners identified
 Database Management staff understands and accepts their
responsibility regarding internal controls
 Division of roles and responsibilities, a segregation of duties
between logical DBAs (SQL Developers) and physical DBAs that
prevents single DBA from unauthorized alterations
 Review documented database management processes
 Review documented database management risks
 Documented database management process controls
 Testing of database management control methods
 Gap identification and controls improvement process
 Update database management processes and document
controls
Payment Card Industry Data Security
Standard (PCI DSS)
What it covers: The PCI DSS is a set of requirements for enhancing
security of payment customer account data. It was developed by
the founders of the PCI Security Standards Council, including American
Express, Discover Financial Services, JCB International, MasterCard
Worldwide and Visa to help facilitate global adoption of consistent data
security measures. PCI DSS includes requirements for security
management, policies, procedures, network architecture, software
design and other critical protective measures.
The Council has also issued requirements called the Payment
Application Data Security Standard (PA DSS) and PCI Pin
Transaction Security (PCI PTS).
Who is affected: Retailers, credit card companies, anyone handling
credit card data.
PCI DSS specifies 12 requirements, organized in
six basic objectives
 Objective 1: Build and Maintain a Secure Retail Point of Sale System
- Requirement 1: Install and maintain a firewall configuration to protect cardholder data
- Requirement 2: Do not use vendor-supplied defaults for system passwords and other security
parameters
 Objective 2: Protect Cardholder Data
- Requirement 3: Protect stored cardholder data
- Requirement 4: Encrypt transmission of cardholder data across open, public networks
 Objective 3: Maintain a Vulnerability Management Program
- Requirement 5: Use and regularly update anti-virus software
- Requirement 6: Develop and maintain secure systems and applications
 Objective 4: Implement Strong Access Control Measures
- Requirement 7: Restrict access to cardholder data by business need-to-know
- Requirement 8: Assign a unique ID to each person with computer access
- Requirement 9: Restrict physical access to cardholder data
 Objective 5: Regularly Monitor and Test Networks
- Requirement 10: Track and monitor all access to network resources and cardholder data
- Requirement 11: Regularly test security systems and processes
 Objective 6: Maintain an Information Security Policy
- Requirement 12: Maintain a policy that addresses information security
The Gramm-Leach-Bliley Act (GLBA) Act of
1999
What it covers: Also known as the Financial Modernization
Act of 1999, the GLB Act includes provisions to protect
consumers' personal financial information held by
financial institutions. There are three principal parts to the
privacy requirements: the Financial Privacy Rule, the
Safeguards Rule and pretexting provisions.
Who is affected: Financial institutions (banks, securities
firms, insurance companies), as well as companies providing
financial products and services to consumers (including
lending, brokering or servicing any type of consumer loan;
transferring or safeguarding money; preparing individual tax
returns; providing financial advice or credit counseling;
providing residential real estate settlement services; collecting
consumer debts).
How does GLBA affect IT?
The GLBA section 501 addresses protection of information

“501. PROTECTION OF NONPUBLIC PERSONAL INFORMATION.

 PRIVACY OBLIGATION POLICY.—It is the policy of the Congress
that each financial institution has an affirmative and continuing
obligation to respect the privacy of its customers and to protect the
security and confidentiality of those customers’ nonpublic personal
information.
 FINANCIAL INSTITUTIONS SAFEGUARDS.—In furtherance of the
policy in subsection (a), each agency or authority described” 1

In other words, it’s necessary to ensure a secure and controlled

environment.
Health Insurance Portability and
Accountability Act (HIPAA)
What it covers: Enacted in 1996, HIPAA is intended to
improve the efficiency and effectiveness of the health
care system. As such, it requires the adoption of national
standards for electronic health care transactions and code
sets, as well as unique health identifiers for providers, health
insurance plans and employers.
It does this by enforcing national standards to protect:
 Individually identifiable health information, known as the Privacy Rule.
 The confidentiality, integrity and availability of electronic protected health information, known as
the Security Rule.
Who is affected: Health care providers, health plans, health
clearinghouses and "business associates," including people
and organizations that perform claims processing, data
analysis, quality assurance, billing, benefits management, etc.
The Health Information Technology for
Economic and Clinical Health Act (HITECH)
The scope of HIPAA was extended with the enactment of the Health
Information Technology for Economic and Clinical Health (HITECH) Act.
Together, HIPAA and HITECH Act rules include:
 The HIPAA Privacy Rule, which focuses on the right of individuals to
control the use of their personal information, and covers the
confidentiality of PHI, limiting its use and disclosure.
 The HIPAA Security Rule, which sets the standards for administrative,
technical, and physical safeguards to protect electronic PHI from
unauthorized access, use, and disclosure. It also includes such
organizational requirements as Business Associate Agreements
(BAAs).

The HITECH Breach Notification Final Rule, which requires giving notice to
individuals and the government when a breach of unsecured PHI occurs.

More on HIPAA and HITECH:

https://www.microsoft.com/en-us/TrustCenter/Compliance/HIPAA
Our challenges
 Infrastructure and DBA teams have admin Access, also to
sensitive data
 Copy data from Production to test/QA/Dev
 Copy a lot of data for performance stress tests
 Working from home or remotely
 Protect database files
 Protect backup files
 Control instance and database Access
 Fight against Firewalls, Antiviruses and Security setup
 Struggle with application security constraints
 How to Audit security configuration setup and changes
 How to identify cyber attacks or security breaches
 Different versions and editions of Window and SQL Server
 …
From Windows and SQL Server Perspective

 We need to work with the security

configurations and features we have in hand
Security 911 for the DBA
Data can reside “anywhere”
• Data placed
“anywhere”
Most secured database – SQL Server 2016
Security areas
 Physical Security
 Network Security
 Attack Surface Minimization
 Service Accounts
 Restricting Use of Administrator Privileges
 Authentication
 Authorization
 SQL Injection
 Patching and security updates
 Disaster Recovery
 Auditing
Physical Security
Network security
 Ensure that the Windows server has proper network security
configured.
 Decide which network protocols to allow, and disable any that are not
required.
 Ensure there is a firewall set up (such as Windows Firewall) and
configure it to allow access to SQL Server.
 Decide whether to encrypt connections to SQL Server and configure
appropriately.
 If Kerberos will be used, register a Server Principal Name.
 Decide if SQL Server Browser Service will be used to help clients find
installed SQL Server instances
 Hiding an instance means client applications and users will need to
know the connection details of the SQL Server instance, but instance
will not appear in search
Attack Surface Minimization
 The more services and features that are enabled,
the more attack surface or surface area is enabled
 SQL Server 2005 took the "off by default" for surface
area configuration
 Disable xp_cmdshell, which allows to execute OS
commands from within SQL Server without special
permissions
 Use Policy-Based Management conditions to keep
xp_cmdshell disabled
 Use SQL Server Configuration Manager for
configuring services and network protocols
 The sp_configure stored procedure can be used for
configuring database engine features and options
Service Accounts

 Each service needs to have a Windows

account that is used to run the service
 Best practice is for the account to have the
least possible privileges required to allow
SQL Server to operate correctly
 Books Online topic "Setting Up Windows
Service Accounts" provides a comprehensive
list of service accounts, required privileges,
and resources
Restricting Use of Administrator Privileges

 Minimize the number of people who have access to the “sa”

account
 Restrict the membership of the sysadmin role (and other
privileged roles)
 Users should default to an account with less privileges even if
they have a second login with more privileges
 Disable “sa” account if possible or:
 Don't give out the “sa”password to anyone who wants temporary
access to SQL Server
 Create new SQL login and grant whatever privilege is required
 Better to have people as members of the sysadmin role rather
than using the “sa” account
 Removing the Windows BUILTIN/Administrators group from the
sysadmin role may cause issues so protect data otherwise
Authentication

 Windows Authentication uses

network/domain accounts to validate the
Windows account being used to connect to
SQL Server (preferable)
 If SQL Authentication is used, then all users
should have a strong password, especially
high privileged accounts
Authorization

SQL Server
permission system
Manage database permissions

 Restrict number of members of the db_owner

role
 Restrict permissions to the public role
 Only grant permissions to the lowest level
(user or role) to minimize direct access
 Restrict access to objects and tables
 Restrict access to data
 Encapsulate control through executables
SQL Injection
 Can take many forms, but the primary approach takes
advantage of code that uses dynamically constructed strings
and "injects" unexpected code into the construct
create table A_Table (A_Col varchar(1000))
go
insert into A_Table values ('A value')
insert into A_Table values ('To be deleted')
go
select * from A_Table
go
create proc sp_SQLInjection
@p_SQL varchar(1000)
As
exec ('select * from A_Table where A_Col = ''' + @p_SQL + '''')
go
exec sp_SQLInjection 'A value''; delete from A_Table; select * from
A_Table where A_Col = ''A value; print '
Disaster Recovery

 Possible issues:
 Logins have not been transferred to secondary
 Backups contain encrypted data and encryption
key not on secondary
 Backup is used with Transparent Data Encryption
(TDE) and the certificate has not been transferred
to secondary
Auditing
 Who is doing what
 Audit failed logins
 Use Policy based management
 Microsoft Baseline Security Analyzer (MBSA)
utility
 SQL Server Audit
 Extended Events
 Triggers
 SQL Traces
 ….
New and old security features
 Advanced Threat Analytics (New)
 SQL Server auditing
 Windows Authentication
 Row-level security (New)
 Dynamic data masking (New)
 Always Encrypted (New)
 Transparent Data Encryption
Advanced Threat Analytics

 On-premises platform
 Helps protect enterprise from cyber attacks
and insider threats
 Learns Network and User behavior
 Notifies when unusual activity detected
SQL Server Audit
 Since SQL 2008
 Audit an Instance or a Database
 Database audit – ENT edition only
 Tracking and logging events that occur on the Database
Engine
 You can create several levels of audits
 The audit event will occur every time that the auditable
action is encountered
 The results are sent to a target:
 A file
 Windows Security event log
 Windows Application event log
SQL Server Audit
Row-level security

 Allows a User/role to only view or update

specific rows based on a built-in function and
a policy created on a function and a table
 Beware of running some generic commands
from a user with row-level security enabled
 All info:
 https://docs.microsoft.com/en-us/sql/relational-
databases/security/row-level-security?view=sql-
server-2017
Dynamic data masking
 Limits sensitive data exposure by masking it to
non-privileged users
 SQL

 All info:
 https://docs.microsoft.com/en-us/sql/relational-
databases/security/dynamic-data-masking?view=sql-server-2017
Always Encrypted

 A feature designed to protect sensitive data, such as

credit card numbers
 Encrypt sensitive data inside client applications and
never reveal the encryption keys to the Database
Engine
 A separation between those who own the data (and
can view it) and those who manage the data
 All info:
 https://docs.microsoft.com/en-us/sql/relational-
databases/security/encryption/always-encrypted-database-
engine?view=sql-server-2017
Transparent Data Encryption (TDE)
 SQL Server 2008
 Encrypts database files for:
 SQL Server
 Azure SQL Database
 SQL Data Warehouse
 Database backups
 Known as encrypting data at rest
 Real-time I/O encryption and decryption of the data
and log files
 The encryption uses a database encryption key
(DEK), which is stored in the database boot record
for availability during recovery
Main rules for the implementation

 Refine your documentation to include mostly

crucial controls
 Security centralization and simplification
 Audits take a snapshot, but your business is
a motion picture, we need to ensure
processes are in place
 Keep up to date regarding regulation
changes
 Accept and absorb upfront costs
Links and next steps

 The security laws, regulations and

guidelines directory (by CSO)
 http://www.csoonline.com/article/2126072/compliance/complian
ce-the-security-laws-regulations-and-guidelines-directory.html

 Common SQL Server Security

Issues and Solutions (Tech
Magazine – by Paul S. Randal)
 https://technet.microsoft.com/en-us/library/2009.05.sql.aspx
Thank you!
gutzait@Pythian.com