In the following you find a compact catalog of steps which should be considered in a SQL Server environment.
It is a conclusion of information from different sources.

Check List
Installation & Patching

  • Are only required components installed? Additional components should be installed when required.
  • As Service Account a Local or Domain Account should be rather used than a System Account.
  • A separate account for each service should be used.
  • Service accounts should use standard privileges (no special). The privileges are applied per Group Membership (SQL Server supplied group accounts).
  • Service Accounts should be applied with SQL Server Configuration Manager.
  • Always the most recent updates should be used.
  • Do not apply automatic updates. Rather test them before on a test environment.

Configuration: Surface Area Reduction

  • Surface Area Configuration Tool: only required features should be enabled.
  • Only Required Services should be set to Auto startup. Others should be set to Manual startup. Also consider to set some Services to Disabled startup.
  • If not needed supported Network protocols should be disabled in Configuration Manager.
  • If not needed, SQL Server should not be exposed to all networks (e.g. the Internet).
  • For some Configurations it is easier if named instances use fixed ports, rather than dynamic ports.
  • Surface Area Configuration Tool: the xp_cmdshell should be disabled unless it is absolutely needed.
  • Surface Area Configuration Tool: COM components should be disabled once all COM components have been converted to SQLCLR.
  • Surface Area Configuration Tool: both mail procedures (database mail and SQL mail) should be disabled unless it required to send mails from SQL Server. Rather use database mail.
  • Surface Area Configuration Tool: standard policy should be enforced for extended procedure usage.
  • No system stored procedure should be removed by dropping it.
  • User or Administrator access should not be denied to the extended procedures by using DENY all.
  • Surface Area Configuration Tool: All exceptions to the above statements should be documented here.

SQL Server Agent

  • In order to apply special privileges to Jobs, Credentials should be used, instead of adjusting the privileges of SQL Server Agent service account.
  • In order to execute a Job with different Windows credentials, Proxy accounts should be used.

Security: Authentication (general)

  • Always Windows Authentication should be used. Mixed Authentication should be used only for Non-Windows accounts or incompatible applications.
  • The sa account should have a strong and known password.
  • If possible, the sa account should be renamed.
  • The SQL Server Management should not be done using the sa account. Rather use a known login and assign the sysadmin privilege to it.

Security: Authentication (administrative access)

  • Use administrative privileges only when needed to access SQL Server.
  • The number of administrators should be as low as possible.
  • Administrative logins should not be linked to the BuiltIn\Administrators group.

Security: Authorisation

  • Permissions on DB objects should be managed using Database roles or Windows groups.
  • Guest access should not be enabled.

Security: Scanner Tools

  • Use Microsoft Best Practices Analyser to identiy possible weak points in SQL Server 2005.
  • Use Microsoft Baseline Security Analyser to identify weak points in your operating System.

Security: Password Policy

  • Set up a strong password policy, including an expiration and a complexity policy. E.g. use the company password policy.
  • If using SQL logins, SQL Server should run on Windows Server 2003 OS. Also password policies should be mandatory.
  • Application should support the change procedure for SQL Login passwords.
  • New SQL Logins should have the property MUST_CHANGE_ON_FIRST_ACCESS on true.
  • Security on Database objects should be managed by using schemas.

Database Properties

  • Databases should have distinct owners. The sa user should not own all databases.
  • The number of owners per Database should be as low as possible.

Schema Properties

  • Similar SQL objects should be grouped into the same schema.
  • Schemas should not be owned only by dbo.
  • The number of schema owners should be minimized.

Catalog Views

  • Catalog views are secure by default, so no additional action is required to secure them.

Remote Data Source Execution

  • Instead of Remote server definitions rather Linked Servers should be used.
  • Ad hoc queries through Linked Servers should be disabled if not needed.

Execution Context

  • Rather use EXECUTE AS instead of SETUSER.
  • Rather use WITH NO REVERT/COOKIE instead of Application Roles.

Data Encryption

  • Information which is classified as secret (or confidential) should be encrypted.
  • Data encryption should be done with symmetric keys which are protected by using asymmetric keys or certificates.
  • Keys should be password-protected and the master key encryption should be removed for the most secure configuration.
  • The service master key, database master keys, and certificates should be backed-up by using the key-specific DDL statements.

Auditing

  • The amount of auditing data (detail level) should be project specific.
  • C2 auditing should be enabled only if explicitly needed.
  • DDL and specific server events should be audited by using trace events or event notifications.
  • DML must be audited by using trace events.
  • WMI should ber used to be alerted of emergency events.

Fazit
My recommendation is to use following Test Protocol in order to check the several steps.

Download: SQL Server: Check List Best Practices