Other settings

There are a number of other settings in the Center for Internet Security (CIS) Security Benchmark for SQL Server relating to surface area reduction that should be considered:

• Set is_trustworthy settings for each database in sys.databases to off (2.10 in CIS SQL Server 2008R2; 2.9 in CIS SQL Server 2012)
• Disable unnecessary SQL Server protocols (2.11 in CIS SQL Server 2008R2; 2.10 in CIS SQL Server 2012)
• Configure SQL Server to use non-standard ports (2.12 in CIS SQL Server 2008R2; 2.11 in CIS SQL Server 2012)
• Set the “Hide Instance” option to Yes for Production SQL Server instances (2.13 in CIS SQL Server 2008R2; 2.12 in CIS SQL Server 2012)
• Disable the sa Login Account by setting is_disabled in sys.server_principals to yes where sid is 0×01 (2.14 in CIS SQL Server 2008R2; 2.13 in CIS SQL Server 2012)
• Rename the sa Login Account (2.15 in CIS SQL Server 2008R2; 2.14 in CIS SQL Server 2012)

Set is_trustworthy setting is off for each database

Using the catalog view of databases (sys.databases), check whether the database is trusted or not using the “is_trustworthy_on”. Here we want to ensure that databases are considered not trusted and set to disabled (0).

Note: The msdb database is excluded as disabling the trustworthy setting may cause unexpected behaviour in SQL Server components that use information from the msdb database.

A query can be constructed as follows:

SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb' AND state = 0;

The Trustworthy setting can also be observed using SQL Server Management Studio.

• Within the Object Explorer, navigate to the SQL Server Instance and expand the path to “Databases”
• Right-click on each database under ‘Databases’ and ‘Databases\System databases’ and select properties
• Click on “Options” page and scroll down in the right pane to “Miscellaneous” where “Trustworthy” is seen

Trustworthy option for database in SQL Server Management Studio

Disable unnecessary SQL Server protocols

Ideally the number of SQL Server protocols enabled should be reduced. It is noted that CIS Security Benchmark do not score this particular issue.

The list of SQL Server Protocols can be found in SQL Server Configuration Manager. To see the settings:

• Go to the SQL Server Network Configuration in object explorer and navigate to “Protocols for”
• Ensure that only required protocols are enabled

Note: Microsoft does not specify exactly which protocols should be disabled. However, the setting for a default installation of SQL Server 2008R2 for example appears to be.

• NP (Named Pipes) – Disabled
• SM (Shared Memory) – Enabled
• TCP – Enabled
• Via – Disabled

The following is query that performs a check on the protocols by checking the registry entry for each of the 4 possible protocols, NP (Named Pipes), SM (Shared Memory), TCP and Via. Note: It makes 4 separate queries for each protocol by finding whether registry entry is enabled or not with the results combined together using a union.

DECLARE @InstanceName nvarchar(50)
DECLARE @MajorVersion decimal
DECLARE @RegKey_Instance nvarchar(500)
DECLARE @RegValue_Instance VARCHAR(100)

DECLARE @RegKey nvarchar(500)
DECLARE @Value_Sm int
DECLARE @Display_Sm VARCHAR(20)
DECLARE @Value_Np int
DECLARE @Display_Np VARCHAR(20)
DECLARE @Value_TCP int
DECLARE @Display_TCP VARCHAR(20)
DECLARE @Value_Via int
DECLARE @Display_Via VARCHAR(20)

-- Get the Instance Name. Default is 'MSSQLSERVER'
SET @InstanceName=CONVERT(nVARCHAR,isnull(SERVERPROPERTY('INSTANCENAME'),'MSSQLSERVER'))

-- Get the Major version number. 8=SQL2000, 9=SQL2005, 10=SQL2008, 11=SQL2012
-- Convert first 2 characters ('8.', '9.', '10', '11'). Convert to Decimal
SET @MajorVersion=CONVERT(decimal,CONVERT(varchar(2),(SERVERPROPERTY('ProductVersion'))))

-- Get the RegKey for Instance Name (e.g. 'MSSQLSERVER')
SET @RegKey_Instance='SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL'

-- Get the RegValue for Instance Name (e.g. 'MSSQL10_50.MSSQLSERVER')
EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey_Instance,
  @value_name = @InstanceName,
  @value = @RegValue_Instance OUTPUT

-- Get the RegKey for SM (Shared Memory) and whether protocol is enabled
SET @RegKey='SOFTWARE\Microsoft\Microsoft SQL Server\'+@RegValue_Instance+'\MSSQLServer\SuperSocketNetLib\Sm'
EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'Enabled',
  @value = @Value_Sm OUTPUT

EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'DisplayName',
  @value = @Display_Sm OUTPUT

-- Get the RegKey for Np (Named Pipes) and whether protocol is enabled
SET @RegKey='SOFTWARE\Microsoft\Microsoft SQL Server\'+@RegValue_Instance+'\MSSQLServer\SuperSocketNetLib\Np'
EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'Enabled',
  @value = @Value_Np OUTPUT

EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'DisplayName',
  @value = @Display_Np OUTPUT

-- Get the RegKey for TCP and whether protocol is enabled
SET @RegKey='SOFTWARE\Microsoft\Microsoft SQL Server\'+@RegValue_Instance+'\MSSQLServer\SuperSocketNetLib\TCP'
EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'Enabled',
  @value = @Value_TCP OUTPUT

EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'DisplayName',
  @value = @Display_TCP OUTPUT

-- Get the RegKey for Via and whether protocol is enabled
SET @RegKey='SOFTWARE\Microsoft\Microsoft SQL Server\'+@RegValue_Instance+'\MSSQLServer\SuperSocketNetLib\Via'
EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'Enabled',
  @value = @Value_Via OUTPUT

EXECUTE xp_regread
  @rootkey = 'HKEY_LOCAL_MACHINE',
  @key = @RegKey,
  @value_name = 'DisplayName',
  @value = @Display_Via OUTPUT

SELECT @Display_Np as DisplayName, @Value_Np as Enabled
UNION SELECT @Display_Sm, @Value_Sm
UNION SELECT @Display_TCP, @Value_TCP
UNION SELECT @Display_Via, @Value_Via

The following is a sample result from a SQL Server 2008R2 database instance:

DisplayName          Enabled
-------------------- -----------
Named Pipes                    0
Shared Memory                  1
TCP/IP                         1
VIA                            0

Check port is running for SQL Server

An ideal practice is to configure the SQL server instance to not use the default TCP port of 1433. Using a non-default port helps protect the database from attacks directed to the default port. It is noted that CIS Security Benchmark do no score this particular issue.

This can be checked using netstat and looking for port 1433 in command prompt:

C:\>netstat -ano

Or with PowerShell:

C:\>netstat -ano | select-string 1433.+listening

Alternatively, SQL Server Configuration Manager can be used to see what port is set:

• Go to the SQL Server Network Configuration in object explorer and navigate to “Protocols for”
• Right-click on “TCP”
• Click on the “IP Protocols” tab
• Observe the IP address and port that has been set

You should also ensure the interface for each IP address (particularly Internet interface) is not enabled.

A query that uses the registry settings for the TCP service used by SQL Server can be made and the port returned as follows:

DECLARE @InstanceName nvarchar(50)
DECLARE @RegKey VARCHAR(100)
DECLARE @PortNumber VARCHAR(20)

-- Get the Instance Name. Default is 'MSSQLSERVER'
SET @InstanceName=CONVERT(nVARCHAR,isnull(SERVERPROPERTY('INSTANCENAME'),'MSSQLSERVER'))

SET @RegKey = 'SOFTWARE\MICROSOFT\MSSQLServer\'+@InstanceName+'\Supersocketnetlib\TCP'
EXEC xp_regread
  @rootkey='HKEY_LOCAL_MACHINE', @key=@RegKey,
  @value_name='Tcpport', @value=@PortNumber OUTPUT

SELECT @InstanceName as Instance, @PortNumber as Port

Hidden option

Another good practice is to configure SQL Server instances within production environments as hidden to prevent advertisement by the SQL Server Browser service.

The “Hide Instance” state can be found in SQL Server Configuration Manager. To see the settings:

• Go to the SQL Server Network Configuration in object explorer and navigate to “Protocols for”
• Right-click “Protocols for”, and then select “Properties”
• On the “Flags” tab, observe the “Hide Instance” box
• In the “Hide Instance” box, select Yes to enable hiding the server instance

The following query can be used to determine if the server instance is hidden:

DECLARE @InstanceName nvarchar(50)
DECLARE @MajorVersion decimal
DECLARE @RegKey_Instance nvarchar(500)
DECLARE @RegValue_Instance VARCHAR(100)</pre>
DECLARE @RegKey nvarchar(500)
DECLARE @Value int

-- Get the Instance Name. Default is 'MSSQLSERVER'
SET @InstanceName=CONVERT(nVARCHAR,isnull(SERVERPROPERTY('INSTANCENAME'),'MSSQLSERVER'))

-- Get the Major version number. 8=SQL2000, 9=SQL2005, 10=SQL2008, 11=SQL2012
-- Convert first 2 characters ('8.', '9.', '10', '11'). Convert to Decimal
SET @MajorVersion=CONVERT(decimal,CONVERT(varchar(2),(SERVERPROPERTY('ProductVersion'))))

-- Get the RegKey for Instance Name (e.g. 'MSSQLSERVER')
SET @RegKey_Instance='SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL'

-- Get the RegValue for Instance Name (e.g. 'MSSQL10_50.MSSQLSERVER')
EXECUTE xp_regread
@rootkey = 'HKEY_LOCAL_MACHINE',
@key = @RegKey_Instance,
@value_name = @InstanceName,
@value = @RegValue_Instance OUTPUT

-- Get the RegKey for SM (Shared Memory) and whether protocol is enabled
SET @RegKey='SOFTWARE\Microsoft\Microsoft SQL Server\'+@RegValue_Instance+'\MSSQLServer\SuperSocketNetLib'
EXECUTE xp_regread
@rootkey = 'HKEY_LOCAL_MACHINE',
@key = @RegKey,
@value_name = 'HideInstance',
@value = @Value OUTPUT

SELECT @InstanceName as 'InstanceName', @Value as 'HideInstance'

Check sa account has been disabled

A good practice is to have the widely known system admin account sa disabled. Enforcing this control reduces the probability of an attacker executing brute force attacks.

The following query shows the name of the system admin account, which sa by default and whether it is disabled:

SELECT name, is_disabled
FROM sys.server_principals
WHERE sid = 0x01;

Check sa account has been renamed

A good practice is to have the widely known system admin account sa disabled. It is more difficult to launch password-guessing and brute-force attacks against the sa account if the username is not known.

The following query lists the name of the system admin account:

SELECT name
FROM sys.server_principals
WHERE sid = 0x01;

Summary

In this article, you have seen a few more settings that can be used to configure to reduce the surface area of attack and improve the security of the SQL Server following good practices and the CIS Security Benchmark.

You can audit manually looking at SQL Server Management Studio and SQL Server Configuration Manager. You can also create a query that will read the catalog information for the databases and the registry to gather the information about the server instance.

The post MS SQL Server audit: Surface area reduction (part 2) appeared first on Portcullis Labs.

• Some might say they are stored procedures with extra functionality
• Some might say they can cause problems to a database if misused
• Some simply say they are stored procedures with a prefix of xp_

This post will hopefully give a better understanding of what Extended Stored Procedures are, how to identify them and how to restrict public access to them. Also this post will look at identifying permissions upon tables, views and functions to ensure it is not possible for users to directly modify data.

Assessing XP stored procedures

Extended Stored Procedures are stored procedures that call functions from Dynamic-Link Library (DLL) files. However these features are deprecated in SQL Server 2012 and may not be supported in future versions of SQL Server. CLR integration should be installed instead if required. In the CIS benchmarks for SQL Server 2008R2 and SQL Server 2012, item 2.2 CLR Integration should be disabled with CLR enabled configuration setting set to 0.

In general, Extended Stored Procedures should not be enabled as good practice. In Centre for Internet Security (CIS) Benchmark for SQL Server 2008r2 and 2012, for the Extended Stored Procedures listed, the recommendation is for those stored procedures to be disabled.

Extended Stored Procedures can be observed using SQL Server Management Studio. Within the Object Explorer, navigate to the SQL Server Instance and expand the path following:

Databases\System Databases\master\Programmability\Extended Stored Procedures\System Extended Stored Procedures

Locate any of the Extended Stored Procedures and look at their properties. The CIS Benchmark for SQL Server 2008R2 and SQL Server 2012 identifies the following are audited:

• 3.1 xp_availablemedia
• 3.2 xp_cmdshell
• 3.3 xp_dirtree
• 3.4 xp_enumgroups
• 3.5 xp_fixeddrives
• 3.6 xp_servicecontrol
• 3.7 xp_subdirs
• 3.8 xp_regaddmultistring
• 3.9 xp_regdeletekey
• 3.10 xp_regdeletevalue
• 3.11 xp_regenumvalue
• 3.12 xp_regremovemultistring
• 3.13 xp_regwrite
• 3.14 xp_regread

For example, to look at xp_dirtree:

1. Locate xp_dirtree (labelled sys.xp_dirtree) in the object explorer, right click and select Properties
2. Select the Permissions tab
3. Look in the Users or Roles listing, If the public entry does not exist, then it complies with the CIS Benchmark (and you can skip further steps)
4. If public entry does exist, select the it within the Users or Roles listing
5. If the Grant checkbox for the Execute permission is checked, the Public role has Execute permission on the procedure

You should remove the the public entry.

Permissions for xp_dirtree

A useful query can be constructed that gathers the permissions granted to public for all XP stored procedures. The query looks at the database permissions table and identifies the associated objects that are extended stored procedures (XP) with it assigned permissions which applies to PUBLIC.

select OBJECT_NAME(major_id) as 'extended_procedure', permission_name, 'PUBLIC' as 'to_principal'
from sys.database_permissions where OBJECT_NAME(major_id) like 'XP_%'
AND [type] = 'EX' AND grantee_principal_id = 0
order by 'extended_procedure';

Table & View Privileges

In CIS Benchmark for SQL Server 2008R2 and SQL Server 2012, there is a recommendation to sanitise the database and application user input. To help to perform this, a good idea is to gather all the permissions for tables, views, stored procedures and functions including the columns for each of these object types. Note for each user with the permissions to access these object types, the aim is to eliminate any permissions to INSERT, DELETE or UPDATE to non-administrative users (i.e. user that do not require these permissions).

The following query gathers all objects of the above type and their columns and identifies which users can access them with what permission for each database.

sp_msforeachdb 'USE ? SELECT ''?'', cast(o.name as char) AS ObjectName,
CASE o.type WHEN "U" THEN "Table" WHEN "V" THEN "View" WHEN "P" THEN "Stored Proc" WHEN "FN" THEN "Function" ELSE o.type END AS ObjectType,
cast(u.name as char) AS UserName, p.state_desc, p.permission_name, USER_NAME(o.schema_id) AS SchemaName,
CASE WHEN cl.column_id IS NULL THEN "--" ELSE cl.name END AS ColName,
CASE WHEN p.state = "W" THEN "X" ELSE "--" END AS IsGrantOption
FROM sys.objects AS o
INNER JOIN
sys.database_permissions AS p ON p.major_id = o.object_id
INNER JOIN
sys.database_principals AS u ON p.grantee_principal_id = u.principal_id
LEFT JOIN
sys.columns AS cl
ON cl.column_id = p.minor_id AND cl.object_id = p.major_id
WHERE o.type in ("U", "V", "P", "FN")
ORDER BY u.name, p.state_desc ASC, p.permission_name ASC'

Summary

In this article, we have looked Extended Stored Procedures and how to identify them. In general, Extended Stored Procedures are not required for the running of a SQL Server and should be disabled from use. Good practices from Microsoft and CIS support this.
We also looked at constructing a query that can evaluate what permissions are assigned to users for objects that can be applied to sensitive data, such as tables, views, stored procedures and functions.

The post MS SQL Server Audit: Extended Stored Procedures / Table Privileges appeared first on Portcullis Labs.

This post discusses the following:

• Surface area reduction using Microsoft SQL server-wide configuration (sys.configurations) using the Center for Internet Security (CIS) SQL Server guidelines as a benchmark
• SQL Server Policy to reduce surface area configuration
• Which Services should be disabled
• Surface area reduction using other tables and views using Center for Internet Security (CIS) SQL Server guidelines as a benchmark

Note: The queries mentioned in this article are based on SQL Server 2008 R2. They all should be applicable to SQL Server 2012. Older versions of SQL Server may have different syntax.

Server-wide configuration

Microsoft SQL Server has amongst all of its features, catalog views that return information used by its database engine. One particular catalog information that provides details about all the server wide configuration values is “sys.configurations”. Such information covered include: audit modes, language settings, memory usage, tracing and type of stored procedures enabled.

The following SQL query displays all the server-wide configuration values:

SELECT name, cast(value_in_use as char) FROM sys.configurations;

In general, to reduce the surface area, you should disable as many unnecessary features and services as possible without affecting the performance and functionality of your SQL Server Database Engine. Furthermore, some audit features should be enabled to be log access yo your SQL Server Database Engine. Fortunately, the Center for Internet Security provide security benchmarks for SQL Server that can be followed to cover off disabling unnecessary features.

CIS have written security benchmark guides for SQL Server 2005, 2008 and 2012. It is noted that the SQL Server 2008R2 and 2012 are very similar in layout and recommendation.

Based on the CIS security benchmarks recommended for SQL Server 2008R2 and 2012, for surface area reduction, the following configuration settings relating to the server-wide configuration (sys.configurations) should be disabled for compliance.

1. Ad Hoc Distributed Queries
2. CLR Enabled
3. Cross DB Ownership Chaining
4. Database Mail XPs
5. OLE Automation Procedures
6. Remote Access
7. Remote Admin Connections
8. Scan For Startup Procs
9. SQL Mail XPs

Note: the last configuration setting, “SQL Mail XPs” is not covered in the CIS Microsoft SQL Server 2012 Database as that setting was deprecated in that version with “Database Mail XPs” as its replacement.

Other configuration settings of interest:

• Agent XPs – Extended Stored Procedures for SQL Server Agent should be disabled. Default value is ’0′ (disabled)
• C2 Audit Mode – Logs both successful and successful attempts to access statements and objects (superceded by Common Criteria Compliance). C2 Audit Mode should be enabled
• Common Criteria Compliance Enabled – Replacement for ‘C2 Audit Mode’ (only available for Enterprise/Developer versions). Common Criteria Compliance should be enabled
• SMO and DMO XPs – Extended Stored Procedures for SQL Server Management Objects (SMO) and Database Management Objects (DMO) ideally should be disabled. However, Default value is ’1′ (enabled). If disabled, SQL Server Management Studio will not see the database instance and to load the database instance force this setting to be re-enabled
• Default Trace Enabled – Tracing should be enabled. Default value is ’1′ (enabled)

The remediation covered by the CIS security benchmark is to show advanced options and then configure the configuration setting, with 0 (for disable) as appropriate.

For example to disable “Scan For Startup Procedures”:

EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'Scan for startup procs', 0;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;

SQL Server policy

Microsoft recommend that policy-based management for SQL Server is used. In earlier versions of SQL Server, this was covered using Surface Area Configuration. This was removed from SQL Server 2008 and its functionality was moved into policy management facets in SQL Server Management Studio.

Using SQL Server Management Studio, within the Object Explorer, navigate to the SQL Server Instance and expand the path following:

Management\Policy Management\Facets

The following facets should be disabled (disabled by default) according to Microsoft:

• Surface Area Configuration
• Surface Area Configuration for Analysis Services
• Surface Area Configuration for Reporting Services

As seen in the following screenshot example:

Surface Area Configuration Facet in SQL Server Management Studio

Services

Microsoft also recommend turning off any unneeded services by setting the service to either manual startup or disabled using SQL Server Configuration Manager.

Microsoft do not specify exactly which services that should be disabled. Obviously, you want the core SQL Server service but you could in theory run without the other services. Double check if you need other services such SQL Server analysing and SQL Server reporting services.

To see what services are currently running or disabled, in SQL Server Configuration Manager:

1. Click on SQL Server Services
2. In Details Pane, right-click on a service and choose properties
3. To change the start mode, select “service” tab and edit the start mode entry

As seen in the following screenshot example:

Disable SQL Services using SQL Server Configuration Manager

Summary

In this post, we have had a look at reducing surface area by:

• Modifying the server-wide configuration (sys.configurations view)
• Applying SQL Server policies
• Turning off unneeded SQL services

In the second part of the article, we will look at other features and SQL queries that can be used to reduce the surface area and comply with good security practices.

The post MS SQL Server audit: Surface area reduction (part 1) appeared first on Portcullis Labs.

Introduction

Microsoft has a SQL Server – Best Practices section on their technet web site. Specifically, a couple of good practice documents of interest are:

• Microsoft SQL Server 2008 R2 Best Practices Analyzer Whitepaper
• Microsoft SQL Server 2012 Best Practices Analyzer Whitepaper

Microsoft also has available a Best Practices Analyser (BPA) for each version of SQL Server which is a diagnostics tool that trawls through a given SQL Server instance and reports the configurations and any differences against Microsoft’s recommended good practices.

The Center for Internet Security (CIS) is the non-profit organisation focused on enhancing the cyber security readiness and response of public and private sector entities. One of its divisions deals with setting Security Benchmarks for a number of systems and frameworks. There are specific security benchmark documents for each major version of SQL Server up to 2012.

Security Technical Implementation Guide (STIG) is a methodology for standardised secure installation and maintenance of computer software and hardware. It was originally defined by the Defense Information Systems Agency (DISA) which created configuration documents in support of the US Department of Defence (DoD). The resource for STIG documents can be found on DISA’s Information Assurance Support Environment.

Looking in particular at Microsoft SQL Server Best Practice and CIS security benchmark, there are a few sections that are covered:

• Compliance
• Encryption
• Access Control
• Authentication
• Network Security
• Auditing

Compliance

For compliance, a number of items have been identified to help improve the security for a SQL Server and used as a benchmark setting. The following are areas for compliance

• Surface Area Reduction – Configure settings on SQL server to disable unnecessary features and services
• Policy-Based Management – Configure a policy on SQL server
• Service Account Selection and Management – Configure and disable unnecessary services
• SQL Server Best Practices Analyzer and other analysis utilities – Run SQL tools to assist in auditing the SQL Server (such as SQL Server Best Practices Analyzer, Microsoft Baseline Security Analyser (MBSA), Microsoft Security Compliance Manager (SCM), Anti-Virus.
• Patching and Automatic Windows Update – Ensure underlying system is patched up to date.

Encryption

For encryption, the following should be considered:

• Encryption of Data and Database
• SSL Encryption of client connections

Access Control

For access control, the following should be considered:

• Administrator Privileges
• Database Ownership and Trust
• Lockdown of System Stored Procedures
• Schemas
• Authorization
• Catalog Security
• Execution Context
• Remote Data Source Execution

Authentication

For authentication, the following should be considered:

• Authentication Modes and Logins
• Password Policy
• Contained Databases and Authentication

Network Security

For network security, the following should be considered:

• Limiting the network protocols used
• Configuring and enabling a firewall
• Avoiding expose a server that is running SQL Server to the public Internet

Auditing

For auditing, it is scenario-specific but in general to configure your server to audit as much detail as possible without making the server inoperable.
Generally, you should look at:

• Auditing is scenario-specific. Balance the need for auditing with the overhead of generating addition data
• Use the SQL Server 2008/2012 Audit feature for the most secure, performant, and granular
• Audit successful logins in addition to unsuccessful logins if you store highly sensitive data
• Audit DDL and specific server events by using trace events or event notifications
• DML can be audited by using trace events or SQL Server Audit
• Use WMI to be alerted of emergency events

Summary

As we have seen there are a number of security benchmark and guideline articles available. Examples include Microsoft, Center for Information Security (CIS) and Security Technical Implementation Guide (STIG). We looked at the general areas covered in these examples. In the next post, we shall look further at the first of these areas, reducing the surface area for vulnerabilities and attack.

The post MS SQL Server Audit: Introduction appeared first on Portcullis Labs.