SQL Server Cybersecurity https://docs.microsoft.com/archive/blogs/securesql/feed.xml Microsoft's Guidance for SQL Server Security and Compliance in the US Public Sector Tue, 16 Apr 2019 05:27:47 GMT en-US hourly 1 The SQL Server Defensive Dozen - Part 3: Authentication and Authorization in SQL Server https://docs.microsoft.com/archive/blogs/securesql/the-sql-server-defensive-dozen-part-3-authentication-and-authorization-in-sql-server Tue, 21 Aug 2018 15:49:02 GMT https://blogs.msdn.microsoft.com/securesql/?p=205 Introduction In order to secure and harden SQL Server it is important to control who and/or what can authenticate to the system and what they have access to. This will satisfy regulatory needs such as the Secure Technical Implementation Guide (STIG). As a reminder from our Introduction to this series, hardening is the process of applying Administrative and Technical controls to a system. Every article in this series will review both Administrative Controls and Technical Controls needed to properly managed and harden a system. This article will discuss authentication configuration and documentation for hardening SQL Server.

Administrative Controls

Documentation is essential to the success of a secured SQL Server. Ideally, documentation should be created before SQL Server is even installed. This allows the DBA to build SQL Server tailored to the requirements of the project and should allow SQL Server to operate in a more secure state from start to finish. However, it is not always realistic to build the documentation prior to installing SQL Server. In such cases it is recommended to ensure the project is configured to a working state, then back down the permissions and turn off any feature which are not required. Once it is determined what the minimal level of permissions and features are required for operation, these can then be documented. Authorizing access to principals within SQL Server is vital to the success of maintaining a secure environment. Without thorough documentation, the DBA will have the difficult (if not impossible) task of keeping SQL Server secure. Thorough documentation ensures the DBA has written guidance on how the data is to be kept secure and provides accountability to the organization to ensure a least privilege model is maintained. Many hardening guides require the use of Windows Authentication (Microsoft's recommendation) coupled with password complexity requirements (typically inherited from Group Policy) for compliance. In the event that Mixed Mode Authentication is utilized, the information owners must choose whether to inherit the password complexity requirements from the Operating System (OS), or if they will implement password complexity requirements utilizing policies and procedures defined by the organization. All of these decisions must be documented. Additionally, documenting the authorized principals and permissions within SQL Server and regularly comparing them to a properly vetted baseline is essential to ensure unauthorized access is not granted. This can be accomplished using a tool like the SQL Server Vulnerability Assessment.

Technical Controls

The technical controls discussed in this section implement and enforce the administrative controls which were defined in the Administrative Controls section. These controls are settings which can be configured within SQL Server to ensure the written policy is enforced.

Authentication Mode

Configuring the authentication mode in accordance with system documentation is vital to the integrity and trustworthiness of the system. The following sections discuss various technical procedures which should be followed when implementing the Windows or Mixed authentication modes.

All Authentication Modes

  • Rename and disable the SA login to prevent attacks on the well-known login by account name.  Automated attacks will try to brute force the SA login as soon as a SQL instance is discovered. By renaming the SA login, most automated attacks will fail to brute force the database admin password.
  • Change SA password to a strong password. This is valuable even in Windows Authentication Mode in case Mixed Authentication Mode is enabled inadvertently or intentionally. Store the password in a secure location for a "break glass in case of emergency" situation.
  • Do not delete built-in principals. This will result in the loss of functionality and potentially an inaccessible system.
  • Use logon triggers for more granular control of the login process.
  • Using either local or Active Directory policies, implement a password policy including expiration and complexity requirements at a minimum.
  • Ensure passwords are encrypted when stored in client applications.

Windows Authentication

  • Windows authentication is the preferred and recommended form of authentication.
  • Use Windows groups to authorize users rather than Windows logins where possible to reduce the administrative overhead of managing access to the instance. It is important to note that each Windows user will be individually identified in the audit log, even if they are a member of a Window group. For example, if the domain user Contoso\Dan is a member of the domain group Contoso\DBA, the user Contoso\Dan will be identified in the SQL Server audit logs.

Mixed Mode Authentication

  • Use for users from untrusted domains/workgroups, cross-platform users, non-Windows applications, or legacy applications.
  • Do not use the SA login to manage SQL Server. Rather assign a known principal to the appropriate roles (e.g. sysadmin).
  • Outfit applications with a mechanism to change SQL login passwords.
  • Set MUST_CHANGE for new logins to ensure the end user changes the password to something only they know.

Baseline Logins and Users Principals and Permissions

Principals represent users, groups, services, and other entities which can access SQL Server resources. Principals gain permissions through direct assignment or role membership. Verifying and limiting the use of permissions and roles inside of SQL Server is a requirement of many hardening guides. Administrators are encouraged to baseline the documented role memberships and server-level permissions. Administrators are also advised to regularly review (audit) the baseline against production to verify nothing has changed. The SQL Server Vulnerability Assessment tool can be used to help with these actions. In most cases, the hardening guides mandate the permission or role membership must follow the Principle of Least Privilege. Best practices for implementing the principle of least privilege are: The following are queries to extract SQL Server permission and role information. These queries are useful for creating and validating baselines, creating and validating documentation, and investigating permissions granted to principals.

Login List

Obtain all logins of the following types:
  • Certificate Login
  • SQL Login
  • Windows Group
  • Windows Login
[sql]SELECT login.name, login.type_desc, CASE login.is_disabled WHEN 1 THEN 'disabled' ELSE 'enabled' END AS 'Status' FROM sys.server_principals login WHERE login.type IN ('C','G','S','U') ORDER BY login.name[/sql]

Direct Permissions Assignment to Logins

Obtain all the permissions for the logins of the following types:
  • Certificate Login
  • SQL Login
  • Windows Group
  • Windows Login
[sql]SELECT login.name, login.type_desc, perm.state_desc, perm.permission_name, perm.class_desc FROM sys.server_principals login JOIN sys.server_permissions perm ON login.principal_id = perm.grantee_principal_id WHERE login.type IN ('C','G','S','U') ORDER BY login.name[/sql]

Server Role Permissions Assignment

Obtain all the permissions for the server roles. [sql]SELECT role.name, CASE role.is_fixed_role WHEN 0 THEN 'False' ELSE 'True' END AS 'Built In Role', perm.state_desc, perm.permission_name, perm.class_desc FROM sys.server_principals role JOIN sys.server_permissions perm ON role.principal_id = perm.grantee_principal_id WHERE role.type = 'R' ORDER BY role.name[/sql]

Server Role Membership

Obtain the server principals which are members of the server roles. [sql]SELECT role.name AS 'Role', login.name AS 'Login' FROM sys.server_principals role JOIN sys.server_role_members rm ON role.principal_id = rm.role_principal_id JOIN sys.server_principals login ON rm.member_principal_id = login.principal_id ORDER BY role.name[/sql]

Shared Accounts

No accounts should access the system that cannot be individually identified and audited. Non-repudiation of actions taken is required to maintain system confidentiality, integrity, and availability. Non-repudiation protects against later claims by a user of not having created, modified, or deleted objects or data in the database or instance.

NT AUTHORITY\SYSTEM

Ensure the NT AUTHORITY\SYSTEM (SYSTEM) account is not privileged or otherwise documented as having elevated access. Rather than granting SYSTEM additional permissions for services running as SYSTEM, consider using a Service SID to grant permissions directly to the service itself. This is the method SQL Server uses to grant permissions to the SQL Server and SQL Agent services. This method has been adopted by Microsoft System Center Operations Manager (SCOM) administrators to grant permission to the HealthService within SQL server. Any user with enough access to the server can execute a task that will be run as SYSTEM either using task scheduler or other tools. At this point, SYSTEM essentially becomes a shared account because the operating system and SQL Server are unable to determine who created the process. This defeats non-repudiation as the actions taken by SYSTEM show in the audit logs as having been taken by SYSTEM, and not the user who invoked the command. Prior to SQL Server 2012, NT AUTHORITY\SYSTEM was a member of the sysadmin role by default. In more recent versions of SQL Server, NT AUTHORITY\SYSTEM is explicitly not given sysadmin access.

Database Ownership

Databases should be owned by a login which should have full control of the database. The database owner login is mapped to the dbo user in the database. The dbo user has full control in the database and cannot be limited. It is recommended to use a low-privilege login as the owner of the databases. A low-privilege login should have no administrative access to the instance. This is especially important in cases where TRUSTWORTHY is enabled on the database, because the use of TRUSTWORTHY combined with a high-privilege login can be used to escalate the privileges of a low-privilege user within the database. Use the ALTER AUTHORIZATION statement to change the owner of the database.

Contained Databases

SQL Server 2012 introduced the concept of contained databases. A contained database is a database which includes all the settings and metadata needed for its operation without dependencies on the instance. From a security perspective, a contained database makes it easier to have user accounts that are limited to a single database. Contained databases should only be enabled if they are required. As with the instance, Windows users or groups should be used when creating users within the contained database.

Discretionary Access Control (GRANT WITH GRANT)

Discretionary access control is based on the notion that principals are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is implicitly or explicitly defined during object creation. Discretionary access control allows the owner to determine who will have access to objects they control. The follow queries can be used to determine who has been granted GRANT with GRANT:

Server Level

[sql]SELECT who.name AS [Principal Name], who.type_desc AS [Principal Type], who.is_disabled AS [Principal Is Disabled], what.state_desc AS [Permission State], what.permission_name AS [Permission Name] FROM sys.server_permissions what INNER JOIN sys.server_principals who ON who.principal_id = what.grantee_principal_id WHERE what.state_desc= 'GRANT_WITH_GRANT_OPTION'[/sql]

Database Level

[sql]USE [DatabaseName] GO SELECT who.name AS [Principal Name], who.type_desc AS [Principal Type], what.state_desc AS [Permission State], what.permission_name AS [Permission Name] FROM sys.database_permissions what INNER JOIN sys.database_principals who ON who.principal_id = what.grantee_principal_id WHERE what.state_desc= 'GRANT_WITH_GRANT_OPTION'[/sql]

Proxies and External Access

Customers may have designated administration user and/or service accounts on the operating system. Typically, this is an administration account with which they automate complex maintenance routines (such as automatically adding a database to an Availability Group). SQL Server provides highly-secure features (also capable of being permissioned) to perform tasks. Please see How to: Create a Credential (SQL Server Management Studio) and Creating SQL Server Agent Proxies for more information. Remove any SQL Agent Proxy accounts and credentials that are not authorized.

Conclusion

This completes the facet and considerations related to securing SQL Server authentication and authorization. Please stay tuned for the next topic in the series discussing modules management and programmability for SQL Server.]]> The SQL Server Defensive Dozen Part 2 - SQL Server Encryption, Key Management, And Data-At-Rest Encryption https://docs.microsoft.com/archive/blogs/securesql/the-sql-server-defensive-dozen-part-2-sql-server-encryption-key-management-and-data-at-rest-encryption Fri, 06 Jul 2018 08:09:34 GMT https://blogs.msdn.microsoft.com/securesql/?p=235 Introduction In order to properly secure and harden SQL Server, the use of encryption provides many benefits including safeguarding data, separation of duties, and satisfying regulatory needs such as the Secure Technical Implementation Guide (STIG) or General Data Protection Regulation (GDPR). Within SQL Server there are several types of encryption: Channel encryption (encrypting login/data packets over the wire), Transparent Data Encryption (TDE) of data at rest, and Always Encrypted for data in use. SQL Server encrypts data with a hierarchical encryption and key management infrastructure. Each layer encrypts the layer below it by using a combination of certificates, asymmetric keys, and symmetric keys. As a reminder from our Introduction to this series, hardening can be thought of as the process of applying Administrative and Technical controls to a system. Every article in this series will review both Administrative Controls and Technical Controls needed to properly managed and harden a system. This article will discuss encryption and key management settings for hardening SQL Server.

Administrative Controls

Many of these checks require the encryption components be documented and referenced for check compliance. For example, one must check the server documentation to see if encryption-at-rest or transmission is required for the databases. The technical controls below should match the customer's documented posture. Customer should list all encryption requirements for the SQL Instance and any encryption components configured based on the respective vulnerability. The correct controls need to be configured for each check.

Technical Controls

Service Master Key

Encrypting data requires secure encryption keys and key management.  The Service Master Key (SMK) is the root of the encryption hierarchy. It is the entry point for any kind of encryption within SQL Server. The SMK is encrypted by SQL Server Setup using both the SQL Server Service accout and also the machine key. Both encryptions use the Windows Data Protection API (DPAPI). It is critical to backup the SMK and store in a secure, off-site location. Creating this backup should be one of the first administrative actions performed on the server. The following code can be used to back up the Service Master Key: [sql]BACKUP SERVICE MASTER KEY TO FILE = 'filePath' ENCRYPTION BY PASSWORD = 'password'[/sql]

Database Master Key

The database master key is a symmetric key used to protect the private keys of certificates and asymmetric keys that are present in the database. When it is created, the master key is encrypted by using the AES_256 algorithm and a user-supplied password. In SQL Server 2008 and SQL Server 2008 R2, the Triple DES algorithm is used. To enable the automatic decryption of the master key, a copy of the key is encrypted by using the service master key and stored in both the database and in master. The copy stored in master is silently updated whenever the master key is changed. To create a Database Master Key and then the necessary backup to be stored offsite, reference the following code: [sql]CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password' BACKUP MASTER KEY TO FILE = 'filePath' ENCRYPTION BY PASSWORD = 'password'[/sql]

Asymmetric Key Management

An asymmetric key is a securable entity at the database level. In its default form, this entity contains both a public key and a private key. When executed without the FROM clause, CREATE ASYMMETRIC KEY generates a new key pair. When executed with the FROM clause, CREATE ASYMMETRIC KEY imports a key pair from a file or imports a public key from an assembly. By default, the private key is protected by the database master key. If no database master key has been created, a password is required to protect the private key. If a database master key does exist, the password is optional. The private key can be 512, 1024, or 2048 bits long. If asymmetric keys are being used, they should be documented, secured properly (as documented), and backed-up. An asymmetric key can be used to encrypt a symmetric key for storage in a database.

Transparent Database Encryption (TDE)

Various hardening guides require SQL Server data files containing sensitive information to be encrypted. As well, system documentation must state whether the database handles classified or sensitive information. Some options for encrypting data in SQL are:
  • Transparent Database Encryption can be used to encrypt data at rest
  • Cell-level encryptioncan be used to encrypt specific columns or even cells of data with different encryption keys.
  • 3rd party server-side encryption or encryption outside of SQL Server via Encrypting File System (EFS folders), EFS is usually not recommended by Microsoft due to the way I/O’s are forced to be performed synchronously and how security works and ACL changes impacts the data availability.
  • BitLocker volumes.
  • SQL Server Always Encrypted (see Always Encrypted).
SQL Server’s Transparent Database Encryption (TDE) protects data-at-rest by encrypting all the user data in a database’s data files (.mdf and .ndf’s), in the log file (.ldf), a database snapshot (.ss), and in the database backup files (.bak, .trn). Tempdb is also encrypted when at least one database is enabled for encryption. TDE does not require applications to be changed to gain this protection. Transparent data encryption (TDE) performs real-time I/O encryption and decryption of the data and log files. It is also possible to use Extensible Key Management solutions to manage TDE keys. To simplify the use and management of TDE it is possible to use or share the same key (or TDE “thumbprint”) across multiple servers, especially for High Availability and Disaster Recovery. The TDE certificate must be installed on all servers:
  • in which the database is a member of a database mirroring session
  • or which are replicas of an Always On Availability Group (AG)
Note, the key can be altered at any time with SQL Server Management Studio (SSMS) or T-SQL.

There are four steps to enable TDE on a user database:

  1. Create the DMK. If it does not already exist, create the Database Master Key (DMK) in the master database.
[sql]IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name = '##MS_DatabaseMasterKey##') CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password';[/sql]
  1. Create the TDE certificate in the master database. The name of the TDE certificate should be a descriptive name. The “WITH SUBJECT” parameter is optional.
[sql]CREATE CERTIFICATE DatabaseTDECertificate WITH SUBJECT = 'TDE Certificate for the Database';[/sql]
  1. Create the DEK in the user database. It’s possible to encrypt the DEK with an asymmetric key instead of your TDE certificate, but doing so will make it difficult or impossible to restore the database backup to another instance of SQL Server. There are also other encryption algorithms that can be used, but AES_256 is the strongest option. While weaker algorithms may provide faster performance, using TDE sacrifices performance for maximum security, so the strongest possible DEK might as well be used.
[sql]CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE DatabaseTDECertificate[/sql]
  1. Set encryption on. Just creating all the keys and the certificate does not enable TDE; The ALTER DATABASE command must be used to complete the process.
[sql]ALTER DATABASE [DatabaseName] SET ENCRYPTION ON[/sql]

Backup the TDE Certificate

TDE uses certificate (thumbprints) and a database encryption key (DEK) to encrypt the database. It is important to back up the customer's unique TDE configuration, certificates, and passwords. The .cer, .pvk, and passwords should be backed up immediately after implementation of TDE (and at regular intervals for safety).   Since the certificate may be critical for a recovery of the database, these backups should be stored offline and off-site.  The following example backups up the certificate and private key [sql]BACKUP CERTIFICATE DatabaseTDECertificate TO FILE = 'C:\Folder\DatabaseTDECertificate.cer' WITH PRIVATE KEY ( FILE = 'C:\Folder\DatabaseTDECertificate.pvk', ENCRYPTION BY PASSWORD = 'Password');[/sql] When switching certificates for a database, it is important to retain older keys/certificates for some time as portions of the log may still be encrypted with the older certificate. Use the following to switch a certificate: [sql]USE [DatabaseName]; ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER CERTIFICATE [NewCertificateName][/sql]

Always Encrypted

Always Encrypted (new in SQL Server 2016) is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers (e.g. U.S. social security numbers), stored in Azure SQL Database or SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine (either Cloud-based SQL Database or SQL Server on-premises). Additionally, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should not have access). It ensures that sensitive data is never exposed in plain-text inside the database, protecting it from DBAs and admins of the machine hosting the system. This allows organizations to encrypt data at rest and in use for storage in Azure, to enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff. There are some nuances with Always Encrypted which need to be considered including certain column types (e.g. text, image, and ntext) and transactional replication are not supported. Always Encrypted makes encryption transparent to applications. An Always Encrypted-enabled driver installed on the client computer achieves this by automatically encrypting and decrypting sensitive data in the client application. The driver encrypts the data in sensitive columns before passing the data to the Database Engine, and automatically rewrites queries so that the semantics to the application are preserved. Similarly, the driver transparently decrypts data, stored in encrypted database columns, contained in query results. The customer can use Always Encrypted feature of SQL 2016 to meet the encryption at-rest and in-transit requirements of the SQL STIG. The process for using Always Encrypted is as follows: 1.  Create a column master key for client applications that use the MSSQL_CERTIFICATE_STORE provider [sql]CREATE COLUMN MASTER KEY ColMasterKey WITH ( KEY_STORE_PROVIDER_NAME = 'MSSQL_CERTIFICATE_STORE', KEY_PATH = 'Current User/Personal/f2260f28d909d21c642a3d8e0b45a830e79a1420' );[/sql] 2. Create a column encryption key [sql]CREATE COLUMN ENCRYPTION KEY ColEncryptionKey WITH VALUES ( COLUMN_MASTER_KEY = ColMasterKey, ALGORITHM = 'RSA_OAEP', ENCRYPTED_VALUE = [The encrypted CEK value BLOB] );[/sql] 3. Create/modify table to reference column encryption key for any fields to be encrypted [sql]CREATE TABLE Payroll ( EmployeeName nvarchar(60) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = ColEncryptionKey, ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'), SSN varchar(11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = ColEncryptionKey, ENCRYPTION_TYPE = DETERMINISTIC , ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'), Department int NULL );[/sql]

Channel Encryption

In order to ensure data-in-transit (login/data packets) is encrypted, SQL Server supports TLS (Transport Layer Security) and SSL (Secure Sockets Layer).  When a SQL Server is configured with TLS or SSL and a client requests an encrypted connection, an initial handshake takes place to negotiate the cipher suite for future communications.  Once agreed, SQL sends its TLS/SSL certificate to the client, which the client must validate and then trust against its copy of the Certificate Authority certificate.  A secure connection is established if the certificate is trusted and meets all requirements. The latest SQL STIG for SQL 2016 requires using TLS as Microsoft has changed the security guidance to move to TLS 1.2 for secure communications.The STIG requires a DOD Certificate to enhance the encryption. Use the following to setup channel encryption:
  1. Install a certificate in the Windows certificate store of the server computer.
  2. Click Start, in the Microsoft SQL Server program group, point to Configuration Tools, and then click SQL Server Configuration Manager.
  3. Expand SQL Server Network Configuration, right-click the protocols for the server you want, and then click Properties.
  4. On the Certificate tab, configure the Database Engine to use the certificate. If enabling for a Failover Cluster Instance (FCI), the Certificate's thumbprint must be added to the registry for each node in the FCI.
  5. On the Flags tab, view or specify the protocol encryption option. The login packet will always be encrypted. When the ForceEncryption option for the Database Engine is set to Yes, all client/server communication is encrypted and clients that cannot support encryption are denied access. When the ForceEncryption option for the Database Engine is set to No, encryption can be requested by the client application but is not required. SQL Server must be restarted after you change the ForceEncryption setting.
  6. To test if encryption is working you should get TRUE, when running the following script.
[sql]SELECT encrypt_option FROM sys.dm_exec_connections WHERE sessionId = @@SPID[/sql]

Encryption Best Practices

Best practices for data encryption:
  • Encrypt high-value and sensitive data.
  • Use symmetric keys to encrypt data, and asymmetric keys or certificates to protect the symmetric keys.
  • Password-protect keys and remove master key encryption for the most secure configuration.
  • Do not delete pre-provisioned system certificates in the master database
  • Always back up the service master key, database master keys, and certificates by using the key-specific DDL statements.
  • Always back up your database to back up your symmetric and asymmetric keys.
  • TDE is recommended for encrypting existing applications or for performance sensitive applications.
  • Cell-level encryption can be used for defense in depth both for a database encrypted by TDE and for limited access control using passwords.
  • Use Always Encrypted to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine or Database Administrators
  • Retain older keys for some time. Portion of log may still be encrypted with the older certificate.
  • Dynamic data masking limits (DDM) sensitive data exposure by masking it to non-privileged users. It can be used to greatly simplify the design and coding of security in your application.

Conclusion

This completes the facet and considerations related to securing SQL Server Encryption, Key Management, And Data-At-Rest Encryption. Please stay tuned for the next topic in the series discussing authentication and authorization for SQL Server.]]> The SQL Server Defensive Dozen Part 1 - Hardening SQL Network Components https://docs.microsoft.com/archive/blogs/securesql/the-sql-server-defensive-dozen-part-1-hardening-sql-network-components Fri, 09 Mar 2018 09:30:07 GMT https://blogs.msdn.microsoft.com/securesql/?p=25 Introduction In order to properly secure and harden SQL Server, one should review many items related to the server communications, network library settings, and ports/protocols configurations. As a reminder from our Introduction to this series, hardening can be thought of as the process of applying Administrative and Technical controls to a system. Every article in this series will review both Administrative Controls and Technical Controls needed to properly managed and harden a system. This article will discuss network component and network-related settings for hardening SQL Server.

Administrative Controls

The primary administrative control for network communications related security is documenting the network communication settings and PKI components. Settings include, documenting SQL ports, IP addresses, anticipated or regular communication paths/routes, communication certificate, and machine names. As well, anything of importance related to network communication (possibly including any reliance on other network devices or components) should be documented. The documentation should define and reflect the current baseline (all settings) of the system. Sidebar: three of the most important concepts for properly managing and hardening a server are:
  1. Documenting (and understanding) everything about the system baseline.
  2. Limit functionality (settings/authentication/authorization) to allow only authorized workloads.
  3. Extensive Auditing and logging (reviewing all logs and enable alerting).

Technical Controls

Below are common technical controls for review and compliance settings. Often, for a system to pass an audit (such as a Cyber Readiness Inspection) these items and settings need to be specifically addressed and documented.

Set Ports and Protocols

SQL Server can be configured to use static, non-standard ports. Dynamic ports should not be used as they require a SQL Browser service and additional UDP broadcast traffic and listener to point users to the service. In a hardened environment, no listening or browsing services (network enumeration services or network enumeration protocols) should be enabled. All connections and ports should be explicitly configured; broadcast traffic is typically blocked. SQL can be configured to communicate over non-standard ports (not 1433), as many notorious SQL attacks (such as the SQL Slammer Worm) exploit the use of standard 1433 SQL port to search for any SQL Service on a network. It should be noted in certain organizations most services have assigned and approved ports for communication. SQL Server’s designated port is 1433 and network traffic inspected for appropriate Tabular Data Stream (TDS) content on this port, therefore TCP settings should be configured to run across all interfaces on port 1433 or per the enclave posture documentation. Below are some Microsoft recommended best practices for network settings.
  • Enable Windows Firewall and limit the network protocols supported.
  • Do not enable network protocols unless they are needed.
  • Disable NETBIOS and SMB protocol unless specifically needed.
  • Do not expose a server that is running SQL Server to the public Internet.
  • Configure named instances of SQL Server to use specific port assignments for TCP/IP rather than dynamic ports.
  • Use extended protection in SQL Server 2012 if the client and operating system support it.
  • Grant CONNECT permission only on endpoints to logins that need to use them. Explicitly deny CONNECT permission to endpoints that are not needed by users or groups.

Use the Designated and Trusted PKI of the Organization to Identify the Server

The server computer must have a certificate provisioned, and the client machine must be set up to trust the certificate's root authority in the PKI domain (the DISA .mil domain). Provisioning is the process of installing a certificate by importing it into Windows. The certificate must be issued for server authentication. The name of the certificate must be the fully qualified domain name (FQDN) of the computer. Many organizations have processes for requesting PKI (DISA in the DoD for example). Please review the customer’s processes for more information on obtaining the proper PKI certificated for the servers and services.

Install Certificates

PKI certificated are essential for guarantee of the validity of a server in the DoD PKI infrastructure. The certificate will also be used to secure the data-in-transit communication. Request the certificate from your organizations PKI, once the certificate is received back from the request process, install it on the nodes or member servers. To provision (install) a certificate on the server follow the directions in the article "How to enable SSL encryption for an instance of SQL Server by using Microsoft Management Console". For SQL Server Failover Cluster Instance (FCI) see the guidance in "Enable a certificate for SSL on a SQL Server clustered installation" section of the article. Just a note, one could walk through the Certificate Import Wizard to import the certificate or use PowerShell to import it. Note, if the service account is not a local administrator and Force Encryption is enabled, the service will not start. The service SID (or service account, not preferred) will need permissions to the machine certificate in the Certificate Store. Please refer to this article for more information. https://support.microsoft.com/kb/318605 (older article but still helpful for troubleshooting and configuration advise).

Configure SSL or TLS for Encryption-in-Transit

Protecting data in transit is an essential part of the data protection strategy or "System Posture". Since data will be moving between many locations, the general recommendation is that you always use SSL/TLS protocols to exchange data across different locations (to secure data in-transit). To configure the server to accept encrypted connections
  1. In SQL Server Configuration Manager, expand SQL Server Network Configuration, right-click Protocols for <server instance>, and then select Properties.
  2. In the Protocols for<instance name> Properties dialog box, on the Certificate tab, select the desired certificate from the drop down for the Certificate box, and then click OK.
  3. On the Flags tab, in the Force Encryption box, select Yes, and then click OK to close the dialog box.
  4. Restart the SQL Server service.
To configure the client to request encrypted connections
  1. Copy either the original certificate or the exported certificate file to the client computer.
  2. On the client computer, use the Certificates snap-in to install either the root certificate or the exported certificate file.
  3. In the console pane, right-click SQL Server Native Client Configuration, and then click Properties.
  4. On the Flags page, in the Force protocol encryption box, click Yes.
To encrypt a connection from SQL Server Management Studio
  1. On the Object Explorer toolbar, click Connect, and then click Database Engine.
  2. In the Connect to Server dialog box, complete the connection information, and then click Options.
  3. On the Connection Properties tab, click Encrypt connection.
Several known vulnerabilities have been reported against SSL and earlier versions of Transport Layer Security (TLS). DISA recommends customers upgrade and configure TLS 1.2 for secure communication. If you have an errors after you configure it, check here.

Review SQL Alias Configurations to Verify Network Names

An Alias is an alternate name that can be used to make a connection to a data source. Please see the following links for more information Create or Delete a Server Alias for Use by a Client (SQL Server Configuration Manager) and Set a SQL Server Alias for the SQL Server Agent Service (SQL Server Management Studio). Please note, a SQL Server with a static, non-standard port will need to have clients create aliases or advanced connection string configurations in order to connect to the instance Please see the following for more information SQL Alias for SharePoint .

Establishing the Identity SQL Server for Secure Authentication Using Kerberos

A Service Principal Name (SPN) must be registered for the SQL Server service account to allow clients to identify and authenticate the service using secure Kerberos authentication. The SetSPN utility can be used to register an SPN for the site database server SQL Server service account. The SetSPN utility must be run on a computer that resides in the SQL Server's domain and it must be run using Domain Administrator credentials. To properly configure an SPN for the SQL Server service account using the SetSPN utility, follow the steps in these procedures. One can also use the Kerberos Configuration Manager to set the SPNs in a single Domain Forest. Note the service account should not have the checkbox set that states “Account is sensitive and cannot be delegated". How to use Kerberos authentication in SQL Server, contains information about how to grant read or write permission to an SPN for an account that is not a Domain Administrator. When the Database Engine service starts, it attempts to register the Service Principal Name (SPN). If the account starting SQL Server doesn’t have permission to register a SPN in Active Directory Domain Services, this call will fail and a warning message will be logged in the Application event log as well as the SQL Server error log. To register the SPN, the Database Engine must be running under a built-in account, such as Local System (not recommended), or NETWORK SERVICE, or an account that has permission to register an SPN see "Configure the SQL Server service to create SPNs dynamically for the SQL Server instances". Security Note: Always run SQL Server services by using the lowest possible user rights. As well, one can note the permission need to allow the computer to register it's SPN. When SQL Server is running on the Windows 7 or Windows Server 2008 R2 operating system, you can run SQL Server using a virtual account or a managed service account (MSA). Both virtual accounts and MSA’s can register an SPN. If SQL Server is not running under one of these accounts, the SPN is not registered at startup and the domain administrator must register the SPN manually.

Consider Disabling Dynamic Ports and the SQL Browser Service

As mentioned above, In a hardened environment, no listening or browsing services (or enumeration protocols) should be enabled. All communication and port access should be explicitly configured; broadcast traffic should be limited or blocked. When an instance of SQL Server starts, if the TCP/IP protocol is enabled for SQL Server, the server is assigned a TCP/IP port. If the named pipes protocol is enabled, SQL Server listens on a specific named pipe. This port, or "pipe," is used by that specific instance to exchange data with client applications. During installation, TCP port 1433 and pipe \sql\query are assigned to the default instance, but those can be changed later by the server administrator using SQL Server Configuration Manager. Because only one instance of SQL Server can use a port or pipe, different port numbers and pipe names are assigned for named instances, including SQL Server Express. By default, when enabled, both named instances and SQL Server Express are configured to use dynamic ports, that is, an available port is assigned when SQL Server starts. If you want, a specific port can be assigned to an instance of SQL Server. When connecting, clients can specify a specific port; but if the port is dynamically assigned, the port number can change anytime SQL Server is restarted, so the correct port number is unknown to the client. Upon startup, SQL Server Browser starts and claims UDP port 1434. SQL Server Browser reads the registry, identifies all instances of SQL Server on the computer, and notes the ports and named pipes that they use. When a server has two or more network cards, SQL Server Browser returns the first enabled port it encounters for SQL Server. SQL Server Browser support ipv6 and ipv4. When SQL Server clients request SQL Server resources, the client network library sends a UDP message to the server using port 1434. SQL Server Browser responds with the TCP/IP port or named pipe of the requested instance. The network library on the client application then completes the connection by sending a request to the server using the port or named pipe of the desired instance. See the following article SQL Server Browser Service for more information.

Conclusion

This completes the facet and considerations related to securing SQL Server network configurations related to SQL STIG Compliance. Please stay tuned for the next topic in the series discussing encryption, key management, and data-at-rest security for SQL Server.]]> Steps for Hardening SQL Server 2016: The Defensive Dozen https://docs.microsoft.com/archive/blogs/securesql/steps-for-hardening-sql-server-2016-the-defensive-dozen Fri, 09 Mar 2018 09:28:47 GMT https://blogs.msdn.microsoft.com/securesql/?p=45 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!]]>