1. Securing your SQL Server
Installation
Charley Hanania, QS2 AG
B.Sc (Computing), MCP, MCDBA, MCITP, MCTS, MCT, Microsoft MVP: SQL Server
Senior Database Specialist

3. My Background
• Now:
– Microsoft MVP: SQL Server
– Database Consultant (again, and very happy) at QS2 AG
• Formerly:
– Production Product Owner of MS SQL Server Platform at UBS Investment Bank
• ITIL v3 Certified
• SQL Server Certified since 1988
– On SQL Server since 1995
– Version 4 on OS/2
• IT Professional since 1992
• PASS
– Chapter Leader – Switzerland
– Regional Mentor – Europe
– European PASS Conference Lead
– Event Speaker
– Database Days Conference Switzerland

4. Contact Info
• Email: Charley.Hanania@sqlpass.org
• Website: http://www.sqlpass.ch
• Twitter: http://www.twitter.com/CharleyHanania
• Blog: http://blogs.mssqltips.com/blogs/charleyhanania
• Linked-in: http://www.linkedin.com/in/charleyhanania

5. Session Outline
• General areas of focus dealing with Security
• Windows & SQL Server – “Secure By Default”
• 80 :: 20 – Simple items that make big difference
• How Much Security is Enough?
• Practices to Consider

6. General Areas
• Areas Generally looked at when speaking about security
– Physical Access
– Network
– Application
– Operating System
– DBMS
– Intellectual Property (IP)
– Data Privacy (Customer Data Usage)
– Segregation of duties
• Privileged access
• Privileged information

7. Windows Server – “Secure By Default”
• Since Windows 2008, Microsoft focussed on the
idea of Secure by Default.
• When Windows is installed
– Only the Roles and Features needed are installed
– Only essential connections are enabled
– Password Policies are more explicit

8. SQL Server – “Secure By Default”
• Since SQL Server 2005, Microsoft focussed on
the idea of Secure by Default.
• When SQL Server is installed
– Only the features needed to run are enabled
– Only essential connections are configured
– Connection Methodologies are also influenced.

9. Scopes of Protection
Windows Server
SQL Server Instance
SQL Server Instance
SQL Server Instance
SQL Server System
Databases
SQL Server User
Databases
Schemas
Objects
Schemas
Objects
Accounts
Groups
Rights
Permissions
Roles
EndpointsLogins
Roles
Users Roles
Users
Permissions Permissions

10. DEMO
• Obfuscation
• Change the RDP Port
• Rename the Windows Administrator Account
• Use Non-Default Instance / Port
• Rename the SA Account

11. {
DEMO
Obfuscation :: Changing the RDP Port

12. Windows Disables RDP by default.
Enabling requires firewall port opening too…

13. Windows Firewall

14. Enabling RDP App (& Port)

15. - Open Regedt32
- Search For “PortNumber”

16. - Change the port number
- Create a new firewall rule for the new Port
- Reboot

17. Use RDP with “<Server>:<PortNumber>”

19. DEMO
• Obfuscation
• Change the RDP Port
• Rename the Windows Administrator Account
• Use Non-Default Instance / Port
• Rename the SA Account

20. {
DEMO
Obfuscation :: Rename Win Admin Account

21. Open Computer Management
 Local Users and Groups
 Users

22. Rename the Account

23. Open Properties
Change the Account Details

25. DEMO
• Obfuscation
• Change the RDP Port
• Rename the Windows Administrator Account
• Use Non-Default Instance / Port
• Rename the SA Account

26. {
DEMO
Obfuscation :: Changing Instance & Port

27. During SQL Server Install
 Select an instance instead of default

28. Named Instance…

29. Network Protocols…

30. This Stops SQL Browser from Broadcasting the
Instance Name

31. Network Port for TCP/IP…

32. Change the Port (review free ports first!)

33. Effects ::
- No (local) Instance
- Instance Listens on New Port

35. DEMO
• Obfuscation
• Change the RDP Port
• Rename the Windows Administrator Account
• Use Non-Default Instance / Port
• Rename the SA Account

36. {
DEMO
Obfuscation :: Rename SA Account

37. Basically, we change the login label (external)

38. Rename the Account

40. Additionally – Strong Passwords
• Renaming Accounts is a great 1st step
• Disable the account from being useable for
login.
– Enable when needed…
• Additionally, you should ensure the password
is VERY strong.
– Why? Because shorter/simple passwords are
cracked easily
• Ref: Electrical Alchemy Information Security
– See http://www.goodpassword.com/

41. How Much Security is Enough?
1. Estimate value of data and objects
– Intellectual Property
– Customer Data
– Marketing/Sales plans
– Cost to redevelop
– Corporate image
– Compliance
2. Estimate risk of being compromised
3. Estimate cost of implementation
4. Estimate cost of on-going operations

42. How Much Security is Enough?
1. Estimate value of data and objects
2. Estimate risk of being compromised
– Closed System vs External Facing
– High Street Brand vs Bunkered Back
Operations
– New Hair Growth vs Lemon Stand Formula
– China / Russia vs Switzerland
3. Estimate cost of implementation
4. Estimate cost of ongoing operations

43. How Much Security is Enough?
1. Estimate value of data and objects
2. Estimate risk of being compromised
3. Estimate cost of implementation
– Layered Security Expert Team at the NSA
(Personnel)
– Mixed Hardware / Software Implementation
(Complexity)
– Existing vs Customised Solutions (Expense)
– Three Month vs Three Year Fulfillment (Time)
4. Estimate cost of ongoing operations

44. How Much Security is Enough?
1. Estimate value of data and objects
2. Estimate risk of being compromised
3. Estimate cost of implementation
4. Estimate cost of ongoing operations
– Fail-safes vs Recoverability
– Secure Backup (on and off-site)
– Personnel needed for maintenance and
sustainability
– Troubleshooting issues
– Performance Tuning

45. Practices to Consider
• Physical Security
– Limiting access to the machine itself, backups, and copies of data
– Encryption of data files and backups – Transparent Data Encryption
• Authentication
– Logins – Windows Authentication, SQL Server Authentication
• Strong passwords, password expiration policies
– Endpoints – restrict connections by protocol, login, etc.
– Encryption – More needed than just to get in.
• Authorization
– Separation of duties
• Permissions, users, roles, access through SPs or views only
– No direct access to tables
– No permissions directly to users; grant to roles and put users in roles
– Separation of data
• Instances, databases, schemas, views – or perhaps encrypt it with certificates or keys
– Principle of least privilege
• from service accounts to users and execution contexts
• Auditing
– tracking who did what when – Built into SQL Server 2008

46. Summary
• Security is an Operational Consideration
• Data Security is a cornerstone of Security Operations
• SQL Server and Windows employ various techniques to
secure the database environment
• Obfuscation is Step One
• How much Security?
– It Depends!

47. Links and Resources
• SQL Server Security Team Blog
• http://blogs.msdn.com/sqlsecurity
• Microsoft Patterns and Practices
• http://msdn.microsoft.com/en-gb/practices/default.aspx
• SQL Server Security Website
• http://www.sqlsecurity.com
• Security Best Practices - Operational and Administrative Tasks.
• http://sqlcat.com/whitepapers/archive/2007/12/16/sql-server-2005-security-best-practices-operational-
and-administrative-tasks.aspx
• SQL Server Security Forum
• http://social.msdn.microsoft.com/forums/en-US/sqlsecurity/threads
• How to Change the RDP Port
• http://support.microsoft.com/kb/306759