Threat and Vulnerability Matrix (Database Engine)
Although SQL Server includes a variety of security mechanisms, every system has features that could be exploited for malicious purposes. Each feature that exposes data or other information can be viewed as a risk, if it is implemented incorrectly.
Although each feature might represent a risk, all risks are not equal. Some require a change in practice, others in settings, and still others in code. The following tables explain the risks and the proactive steps that you can take to lessen the risks.
Process Threats and Vulnerabilities
Threat or vulnerability |
Definition |
Mitigation |
|---|---|---|
Security policies |
A security policy is a record of the processes and procedures that an organization will follow to prevent, track, and respond to security threats. It contains policies involving the appropriate access to systems, patching, and firewalls, and virus-prevention mechanisms. |
Create, review, distribute, and maintain an effective security policy. For more information about how to create a security policy, see Securing SQL Server. |
Principal of "least privilege" |
The "least privilege" principal states that a system should allow for only the required level of access to a securable object. In addition, access should be enabled only to those with a direct need, and only for a specified time. Applications can be coded to provide more access than necessary and accounts might have too much access. |
Review and implement security according to the principal of least privilege. For more information about how to develop applications that use least privilege concepts, see Best Practices in a Least Privileged Environment on MSDN. |
Security bulletins |
Microsoft releases security information as soon as it is verified and tested on various platforms. Organizations that do not monitor these bulletins put their systems at risk by not implementing appropriate security guidelines. |
Review and track SQL Server security bulletins. For more information, see Microsoft Security Bulletin Search on TechNet. |
Platform Threats and Vulnerabilities
Threat or vulnerability |
Definition |
Mitigation |
|---|---|---|
System not updated (software updates not applied) |
Microsoft releases software updates to make SQL Server more secure. Not tracking or applying these software updates leaves the system more vulnerable to attack. |
Review and apply all service packs and hotfixes as they become available. For more information, see the Downloads page on the SQL Server TechCenter. |
Network port exploits |
The network is the primary source of access for attacks against SQL Server. Leaving standard ports open to the Internet can invite attack. |
Use a firewall on the server if it is exposed to the Internet, and use the SQL Server Configuration Manager tool to set the network configuration. Also consider using the Secure Sockets Layer (SSL) for stronger security. For more information about firewalls and SQL Server, see How to: Configure a Windows Firewall for Database Engine Access. For more information about how to configure network settings, see SQL Server Configuration Manager. For more information about how to use the Secure Sockets Layer in SQL Server, see Encrypting Connections to SQL Server. |
Inappropriate service account settings |
The service accounts for SQL Server are often granted more access to the platform or network than is necessary. |
The service accounts for SQL Server should operate under the principal of least privilege, and should have strong passwords. For more information about service accounts, see Setting Up Windows Service Accounts. For more information about passwords, see Strong Passwords. |
Surface area too broad |
The features and capabilities of SQL Server can be exposed when not necessary. |
Use the SQL Server Configuration Manager and the Policy-Based Management to control features and other components. For more information, see Understanding Surface Area Configuration. |
Unnecessary stored procedures enabled |
Some extended stored procedures allow for access to the operating system or registry. |
Do not enable stored procedures that allow for access to the operating system or registry unless absolutely necessary. For more information, see Understanding Surface Area Configuration. |
Authentication Threats and Vulnerabilities
Threat or vulnerability |
Definition |
Mitigation |
|---|---|---|
Weak passwords |
Simple passwords are at risk to brute-force or dictionary attacks. |
Always use strong, complex passwords. For more information, see Strong Passwords. Also see the CHECK_POLICY and CHECK_EXPIRATION options on the CREATE LOGIN (Transact-SQL) and ALTER LOGIN (Transact-SQL) statements. |
User accounts not audited |
Users (principals) often change positions or leave an organization. If the access for a user account is not changed, the system can still be accessed with the previous permissions level. |
User accounts should be audited frequently to make sure that appropriate access to database servers and objects is enabled. For more information about how to audit SQL Server access, see Monitoring the Error Logs. |
Programming Threats and Vulnerabilities
Threat or vulnerability |
Definition |
Mitigation |
|---|---|---|
SQL injection |
The practice of embedding a malicious query in a legitimate one. |
For more information about dealing with SQL injection attacks, see SQL Injection. |
Embedded passwords |
Some applications save connection strings in the program or configuration files. |
Do not store passwords or sensitive connection information in a program, the registry, or a configuration file. For more information, see Password Policy. |
Data Access Threats and Vulnerabilities
Threat or vulnerability |
Definition |
Mitigation |
|---|---|---|
Encryption inappropriately applied |
Encryption obfuscates the data or connection information in SQL Server. Not encrypting when it is required, or adding encryption when not necessary, poses unnecessary risk and complexity. |
Understand and correctly implement SQL Server encryption. For more information, see SQL Server Encryption. |
Certificates inappropriately applied |
Certificates are a mechanism to verify authentication. SQL Server can use certificates for a variety of purposes, from connections to data. Improper use of self-certification and extended validation periods reduces the strength of your overall security. |
Understand and correctly implement SQL Server certificates. For more information, see SQL Server Certificates and Asymmetric Keys. |
SQL Server keys not backed up |
A SQL Server instance and the databases it contains can have keys that are used for various security purposes. This includes encryption. |
Server keys (also known as service master keys) and database keys should be backed up and stored securely. They should also be periodically changed. For more information, see SQL Server and Database Encryption Keys (Database Engine). |