- I don’t want to spend too much time on a lengthy introduction; the topic around SQL server deployment and healthcare security is very important to cover.
However, consider the fact that 2015 and 2016 were pretty awful years when it comes to data breaches in the healthcare world. A recent analysis pointed out that the largest healthcare data breaches of 2016 were nowhere near the scale of those seen in 2015 – 16,471,765 records were exposed compared to 113,267,174 records in 2015. However, more covered entities reported breaches than in any other year since OCR started publishing breach summaries.
To that extent, let’s focus in on the data repositories housing our critical healthcare data. Specifically, Microsoft SQL Server.
These next few sections will walk you through deployment scenarios and where to create security best practices around your SQL architecture.
Securing your SQL Platform
If you’re leveraging a standalone physical server (or blade) for your SQL ecosystem, it’s important to have some good security practices in place. For good physical security, make sure the server is isolated, in a locked room – where access is constantly controlled. Restricted access to database servers is a must. Furthermore, take extra caution when working with physical backup media. Ensure that disks or tapes are stored securely on and off site. Physical network security also ensures that unauthorized users will stay away from the network that your SQL environment leverages.
You absolutely have the capability to deploy SQL as a VM. However, it’s important to take similar precautions as when working with a physical environment. Ensure that your physical VM hosts are isolated and in a secured environment. Furthermore, take extra caution around HIPAA-compliant data. If you have VMs that shouldn’t be mixing with a SQL Server housing HIPPA data, consider using a different host for those VMs. Otherwise, SQL VMs should be isolated, locked down, and monitored as needed. Virtualization allows you to create some powerful isolation policies and add extra visibility via database monitoring tools.
Securing the OS
Windows Operating Systems
Ensure that your OS is up-to-date with all critical updates and patches. From there, you want to reduce your risk surface area as much as possible. This means turning off or disabling unused components within the Windows OS, controlling privileges for services running on the OS, and leveraging native firewalls to increase security. For example, if your SQL environment is using IIS, you’ll need to take extra precautions around securing that site and your data base.
Firewalls are extremely useful when it comes to SQL security. First of all, next-generation firewalls can help with data loss prevention and even help control data flow. Furthermore, you can divide your network into security zones to ensure SQL traffic is monitored and isolated. This multi-tiered environment helps create monitored subnets, and helps isolate traffic flow. Finally, a good security architecture, leveraging a firewall platform, can help prevent SQL injections and even cross-site scripting attacks.
Isolate Windows and SQL services
This part is simple, but important – make sure to leverage separate SQL Server services under separate Windows accounts. Low-rights SQL or Windows accounts help prevent unauthorized access and limits risk.
It’s best to use NTFS when deploying a SQL platform. You have more security capabilities with an NTFS architecture. For example, you can leverage things like access control lists (ACLs) for files and directories. And, you can use Encrypting Files System (EFS) for file encryption requirements.
Authentication and Service Accounts
There’s two ways to set up SQL authentication. Bottom line, you should use Windows Authentication for maximum security and access. From there, you’ll have service accounts that you will need to lockdown. Make sure to secure you sysadmin account and always use complex passwords for you SA account and other SQL-specific logins. A few other good best practices will be to always enable password policy checking to ensure strength and expiration of the password. Strong passwords should be required for all SQL login accounts.
Permissions and user access
Go ahead and just revoke guest user access. You do not want public server role members to ever access the databases on SQL Server.
Controlling the SQL footprint
Don’t install features you will never use and disable unwanted functions after your installation. Also, make sure you don’t have rogue instances of SQL installed somewhere in your network. Policy-based Management can help you create very specific control mechanisms for one, or more, of your SQL instances.
Securing the network
For critical SQL deployments, it’s recommended to disable things like NetBIOS and Server Message Block (SMB). These can be considered unnecessary protocols and can be removed. From there, you can create subnets, isolated network environments, and even network monitoring for your SQL deployments.
Secure logs and registry keys specific to SQL
Absolutely lock down your logs. In an NTFS ecosystem, your logs can reveal quite a bit about your SQL deployment. Ensure that this is locked down with proper access rights.
Encryption and using SSL certificates
There are some good arguments as to why you should use certificates within your SQL deployment. Remember, encryption won’t solve an access issue. However, if unauthorized access is gained, the data may be useless to the intruder as it will be encrypted.
Always…always use strong passwords for your SA and all SQL Server login accounts.
Please don’t install SQL on a domain controller
Simply put – just don’t do this. There will be several security-related limitations you’ll have to battle with. For example, you won’t be able to set up a SQL Server failover cluster, you won’t be able to create specific security groups, you won’t be able to run SQL services using local service accounts, and you’ll have to uninstall SQL entirely to make other types of changes.
SQL Server data access
You can have the best possible SQL security environment, but what about the apps and services accessing your databases? Very simply, ensure that you have very strong and secure client access policies for your applications. There are powerful ways to configure client access to ensure security.
On-going Testing and Maintenance
There are always multiple admins working on various parts of your healthcare environment. Make sure that there are no rogue accounts, that permissions are all accounted for, and that all policies are actively in place an operating. These types of policy reviews help create a proactive approach to infrastructure security.
It’s always great to review your SQL and database environment on consistent basis. Hiring a partner or security firm to do quarterly reviews can help a lot. Even a single misconfigured user access account can cause a headache and a breach. Testing your security polices can go a long way in reducing headaches later on.
Proper SQL deployment can aid healthcare data security
When it comes to SQL Server security, it’s important to see this as an ever-evolving process. Your users will change, your apps will evolve, and you will undoubtedly require access to more data tools. SQL allows you to control and even optimize the delivery of this data.
However, you can’t just treat this as another server running in your environment. You must leverage security best practices when deploying your SQL ecosystem to ensure optimal performance and data integrity.
Another good piece of advice is that you do not have to do this alone. Leveraging a partner who’s very familiar with both SQL, as well as various deployment strategies can really help out.
Bottom line, it’s much easier to employ good security practices now rather than have to do this in an emergency situation – facing a data breach.