Making sure your SQL Servers are secured against malicious users is difficult. How can you know that you’ve done enough? How do you know you’re protected from the things that actually worry you?
The United States Defense Information Systems Agency (DISA) publishes a set of guidelines for organizations securing different pieces of software that connect to the US Department of Defense’s networks (DoD). Whether you’re working with the DoD or not, these Security Technical Implementation Guides (STIGs) are a good resource to help you understand potential security vulnerabilities and mitigate them.
Using STIGs; Why should you care?
Look, securing SQL Server is hard. There’s a lot to think about beyond simply setting a complex administrator password. Having a guide that examines potential vulnerabilities is key to successfully securing your environment. STIGs are a good tool for understanding and mitigating any risks you may encounter while securing SQL Server.
STIGs are broken down into a series of potential vulnerabilities. Each vulnerability targets a specific issue you might encounter in SQL Server. There’s a format to the rules that makes it easy to quickly review each vulnerability and determine if you shoud be concerned:
- Heading – gives each vulnerability an ID and severity (CAT-I is the highest severity).
- Title – A short overview of what the rule covers. E.g. SQL Server must limit the number of concurrent sessions to an organization-defined number per user for all accounts and/or account types.
- Discussion – More details about the potential vulnerability. This explains why you care.
- Check Text – Instructions and/or queries to find out if you’re vulnerable.
- Fix Text – Become less vulnerable with this one trick!
- References – Not surprisingly, this is a list of references where you can learn more. Some of the references are just government document identifiers which will require some spelunking on your part.
While the format is dry, it provides a strong language for communicating and understanding security risks.
Finding the STIG
Navigate to the Document Library and then locate the STIG for SQL Server. It you want an easier time of this, you can narrow the scope of the library view to only databases. Expand the Application Security node in the navigation tree on the right and then check the Databases box. There are STIGs available for SQL Server 2014 and 2016 at the time this article was published.
How do you view the STIG?
Each STIG is made up of some XML, an XML stylesheet, and maybe some images. You can’t easily view them in your browser without changing a security setting that’s supposed to keep you safe from malicious files. Let’s not get a virus while securing the SQL Server. Instead of weakening your browser security, I suggest you download the STIG Viewer directly from the DoD Cyber Exchange (this place sounds way cooler than it actually is).
Download the STIG Viewer for your platform and decompress it. On Windows, there’s a helpful batch file to start up the STIG viewer. Once the STIG Viewer is running, you’ll be able bo use the familiar File -> Open to open up the STIG. For SQL Server 2016, the STIG has a memorable name like
Ta da! Now you can view the STIG:
What should you do with a STIG?
I start by reviewing each vulnerability. Read the Rule Title and Discussion. Separate the STIGs into two categories: Yes and Maybe. Review everything in the Maybe category with the primary stakeholders for the databases that would be affected. Not all systems need the same level of protection.
Why only a Yes and Maybe category? Some of the vulnerabilities will be obvious things for a DBA to configure. Others will require additional thought before the right mitigation is put in place. The important thing is that the STIG provides a good starting location for thinking about security – vulnerabilities are listed with a discussion of risk and both detection and mitigation tools are provided. Reviewing STIGs is a first step toward securing your environment.
Was this article helpful?