Steps for Hardening SQL Server 2016: The Defensive Dozen

In March of 2018 DISA published the Secure Technical Implementation Guide (STIG) for SQL Server 2016. Over the span of the previous year, Microsoft Services completed the Security Requirements Guide (SRG) vendor-response form offering guidance to DISA on how-to secure and harden SQL Server 2016 to meet the NIST requirements. While DISA solely owns and manages the STIGs, many vendors do have concerns how their products are portrayed by the Federal Government and how NIST & the DoD mandate products secure configuration. For this iteration of the SQL STIG, Microsoft US Public Sector Services was able to recommend a significant amount of technical guidance for securing SQL Server 2016. In this 12-part blog series we will summarize and present some of that guidance for all Microsoft customer and partners to reference for hardening their SQL Servers and keeping data secure.

This blog series offers security and hardening guidance summarized and grouped into 12 “facets” or a dozen general categories. Our recommendation is for customers to review and understand each of the 12 facets and to address the recommendations of each facet in order to improve the security posture of their SQL Server. Most of the vulnerabilities identified by DISA in the SQL 2016 STIG fall into one of these facets or groupings. The facets summarize the features and components that can be used to achieve compliance within that grouping or general category of vulnerabilities.

As many security frameworks and certifications describe, properly securing information systems requires the application of Physical, Administrative, and Technical controls in order to achieve the organizations desired level of Confidentiality, Integrity, and Availability (CIA) for the system. In this blog series our guidance assume the systems are physical controlled and physically secure. The series will focus on and recommend a number of administrative controls and associated technical controls for each major facet of DBMS security.

Administrative controls are “soft controls” or policies and procedures to harden a service, system, or organization. Administrative controls are often workflow or paperwork processes designed to ensure the mindful, explicit, cognizant identification and implementation of a process of control. Technical controls are measurable, actual, “bit-flip” configurations managed in the product or operating system, specifically intended to configure or secure the product. Technical controls often provide automated protection from unauthorized access/misuse/abuse and facilitate detection of control violation or access violations.

Please note, hardening a system is by definition muting, auditing, and restricting features and functionality so as to reduce risk and/or attack surface associated with running the systems. By its very nature, hardening a system and applying the DISA SQL STIGs either correctly or incorrectly may jeopardize or void the product support. Always review and test any guidance or code before adopting and implementing it. As mentioned above, the STIGs are solely owned and published by DISA. As well, the STIGs are openly published and offered by DISA and the SQL Server STIG is available for use by all the Federal, State, and Local government as well as the general public. However, per all DISA STIG overview warnings, "DISA accepts no liability for the consequences of applying specific configuration settings made on the basis of the SRGs/STIGs." Microsoft also in no way supports the SQL STIGs or the posture of a STIG-compliant SQL Server as recommended by DISA. With that being said, Microsoft Services does offers input for the SRG Vendor Response (as well as this blog information) in the interest of helping customer configure and ensure the highest level of trust and privacy for all Microsoft customers around the world. The information and references presented in this blog series are general best practices for securing SQL Server. Microsoft’s official published guidance and “best practices” for hardening SQL will be noted and referenced throughout this series.

Customers should note the risk associated with hardening a system including accidentally locking themselves out of a system or corrupting the system to the point where it is unsalvageable. Correctly or incorrectly hardening a system can also reduce performance in such a way the system becomes unresponsive or unavailable (for example, correctly or incorrectly setting verbose auditing, alerting, or connection limits). Customers are encouraged to plan, test, and review all recommendations before making any changes to their system. As well, customer are encouraged to backup the operating system and SQL Server out-of-the-box "baseline" before and after any changes. Baseline recovery and service restoration are very critical to the availability (A in CIA) of the DBMS. This includes the administrative controls and processes associated with recovery and restoration of the DBMS. To emphasize how important, we will devote special mention and offer many recommendations for the baseline and recovery the system before and after hardening. In a future series, we will also discuss technologies like Desired State Configuration and DevOps that can be paired with hardening of a system to increases and protect CIA of the DBMS.

As mentioned above, CIA of a information system requires weighing the cost or impact of hardening the service or component against the risk associated with that change or running the system on a/the network. In the industry, this process is commonly referred to as Risk Management. Risk Management is the identification, assessment, and prioritization of risks (defined in ISO 31000 [https://www.iso.org/iso/home/standards/iso31000.htm]) followed by coordinated application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities.

The scope of risk management regarding the DISA STIGs is as follows:

• Sharing or Transferring Risk– Transferring risk typically involves documenting risk to and offloading the risk to another party. Typically risk transference is a type of insurance policy for the customer where the customer has a process or service agreement built to address a risk that they must reduce.
• Avoiding Risk – A customer may choose to avoid a risk by eliminating a feature or function of a service. For example, if there is a security risk to the service during an evening maintenance routine; it may be better to take the system offline during the evening maintenance routine, thereby limiting the availability of the system to avoid the risk. Another example of risk avoidance is choosing to not keep SSN data so as not to carry the risk associated with having that data.
• Reducing Risk– Risk reduction is the process of reducing a significant risk to a less significant risk or reducing the probability of a risk being realized. Configuration related SQL STIG vulnerabilities deal with reducing risk. For example, setting or disabling a feature to reduce the attack surface of the system.
• Accepting Risk– This is commonly referred to as Risk Acceptance. Risk acceptance is typically the last step and last resort of risk management. It should be noted there is always some level of risk acceptance when running a server or information system. It is impossible to eliminate all risk associated with having a server or service online.

For any questions about the SQL STIGs or it's interpretation please contact DISA per their documents and website at disa.stig_spt@mail.mil.

We hope this series and these recommendation help you, your business, and your customer secure SQL Server and keep your data safe!