1. Use a specific user account or domain account rather than a shared account for SQL Server services.
2. Use a separate account for each service.
3. Do not give any special privileges to the SQL Server service account; they will be assigned by group membership.
4. Manage privileges through the SQL Server supplied group account rather than through individual service user accounts.
5. Always use SQL Server Configuration Manager to change service accounts.
6. Change the service account password at regular intervals.
7. Use Credentials to execute job steps that require specific privileges rather than adjusting the privilege to the SQL Server Agent service account.
8. If an agent user needs to execute a job that requires different Windows credentials, assign them a proxy account that has just enough permission to get the task done.

Best practices for authentication mode:

1. Always use Windows Authentication mode if possible.
2. Use Mixed Mode Authentication only for legacy applications and non-Windows users.
3. Use the standard login DDL statements instead of the compatibility system procedures.
4. Change the sa account password to a known value if you might ever need to use it. Always use a strong password for the sa account and change the sa account password periodically.
5. Do not manage SQL Server by using the sa login account; assign sysadmin privilege to a knows user or group.
6. Rename the sa account to a different account name to prevent attacks on the sa account by name.

Best practices for network connectivity

1. Limit the network protocols supported.
2. Do not enable network protocols unless they are needed.
3. Do not expose a server that is running SQL Server to the public Internet.
4. Configure named instances of SQL Server to use specific port assignments for TCP/IP rather than dynamic ports.
5. If you must support SQL logins, install an SSL certificate from a trusted certificate authority rather than using SQL Server 2005 self-signed certificates.
6. Use “allow only encrypted connections” only if needed for end-to-end encryption of sensitive sessions.
7. 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.

Best practices for system stored procedures

1. Disable xp_cmdshell unless it is absolutely needed.
2. Disable COM components once all COM components have been converted to SQLCLR.
3. Disable both mail procedures (Database Mail and SQL Mail) unless you need to send mail from SQL Server. Prefer Database Mail as soon as you can convert to it.
4. Use SQL Server Surface Area Configuration to enforce a standard policy for extended procedure usage.
5. Document each exception to the standard policy.
6. Do not remove the system stored procedures by dropping them.
7. Do not DENY all users/administrators access to the extended procedures.

Best practices for password policy

1. Mandate a strong password policy, including expiration and a complexity policy for your organization.
2. If you must use SQL logins, ensure that SQL Server 2005 runs on the Windows Server 2003 operating system and use password policies.
3. Outfit your applications with a mechanism to change SQL login passwords.
4. Set MUST_CHANGE for new logins.

Best practices for administrator privileges

1. Use administrator privileges only when needed.
2. Minimize the number of administrators.
3. Provision admin principals explicitly.
4. Have multiple distinct administrators if more than one is needed.
5. Avoid dependency on the built-in\administrators Windows group.

Best practices for database ownership and trust

1. Have distinct owners for databases; not all databases should be owned by sa.
2. Minimize the number of owners for each database.
3. Confer trust selectively.
4. Leave the Cross-Database Ownership Chaining setting off unless multiple databases are deployed at a single unit.
5. Migrate usage to selective trust instead of using the TRUSTWORTHY property.

Best practices for using schemas

1. Group like objects together into the same schema.
2. Manage database object security by using ownership and permissions at the schema level.
3. Have distinct owners for schemas.
4. Not all schemas should be owned by dbo.
5. Minimize the number of owners for each schema.

Best practices for database object authorization

1. Encapsulate access within modules.
2. Manage permissions via database roles or Windows groups.
3. Use permission granularity to implement the principle of least privilege.
4. Do not enable guest access.
5. Use users without logins instead of application roles

Best practices for catalog security

1. The catalog views are secure by default. No additional action is required to secure them.
2. Grant VIEW DEFINITION selectively at the object, schema, database, or server level to grant permission to view system metadata without conferring additional permissions.
3. Review legacy applications that may depend on access to system metadata when migrating the applications to SQL Server 2005.

Best practices for remote data source execution

1. Phase out any remote server definitions.
2. Replace remote servers with linked servers.
3. Leave ad hoc queries through linked servers disabled unless they are absolutely needed.
4. Use constrained delegation if pass-through authentication to a linked server is necessary.

Best practices for execution context

1. 1.        Set execution context on modules explicitly rather than letting it default.
2. 2.        Use EXECUTE AS instead of SETUSER.
3. 3.        Use WITH NO REVERT/COOKIE instead of Application Roles.
4. 4.       Consider using code signing of procedural code if a single granular additional privilege is required for the procedure.

Best practices for data encryption

1. Encrypt high-value and sensitive data.
2. Use symmetric keys to encrypt data, and asymmetric keys or certificates to protect the symmetric keys.
3. Password-protect keys and remove master key encryption for the most secure configuration.
4. Always back up the service master key, database master keys, and certificates by using the key-specific DDL statements.
5. Always back up your database to back up your symmetric and asymmetric keys.

Best practices for auditing

1. Auditing is scenario-specific. Balance the need for auditing with the overhead of generating addition data.
2. Audit successful logins in addition to unsuccessful logins if you store highly sensitive data.
3. Audit DDL and specific server events by using trace events or event notifications.
4. DML must be audited by using trace events.
5. Use WMI to be alerted of emergency events.
6. Enable C2 auditing or Common Criteria compliance only if required.

Best practice analysis utilities recommendations

1. Run BPA against SQL Server 2005.
2. Regularly run MBSA 2.0 to ensure latest SQL Server 2005 patch level
3. Regularly run MBSA 2.0 for SQL Server 2000 instances

SQL Server service accounts recommendations:

1. Use a specific user account or domain account rather than a shared account for SQL Server services.
2. Use a separate account for each service.
3. Do not give any special privileges to the SQL Server service account; they will be assigned by group membership.
4. Manage privileges through the SQL Server supplied group account rather than through individual service user accounts.
5. Always use SQL Server Configuration Manager to change service accounts.
6. Change the service account password at regular intervals.
7. Use Credentials to execute job steps that require specific privileges rather than adjusting the privilege to the SQL Server Agent service account.
8. If an agent user needs to execute a job that requires different Windows credentials, assign them a proxy account that has just enough permission to get the task done.

Best practices for authentication mode:

1. Always use Windows Authentication mode if possible.
2. Use Mixed Mode Authentication only for legacy applications and non-Windows users.
3. Use the standard login DDL statements instead of the compatibility system procedures.
4. Change the sa account password to a known value if you might ever need to use it. Always use a strong password for the sa account and change the sa account password periodically.
5. Do not manage SQL Server by using the sa login account; assign sysadmin privilege to a knows user or group.
6. Rename the sa account to a different account name to prevent attacks on the sa account by name.

Best practices for network connectivity

1. Limit the network protocols supported.
2. Do not enable network protocols unless they are needed.
3. Do not expose a server that is running SQL Server to the public Internet.
4. Configure named instances of SQL Server to use specific port assignments for TCP/IP rather than dynamic ports.
5. If you must support SQL logins, install an SSL certificate from a trusted certificate authority rather than using SQL Server 2005 self-signed certificates.
6. Use “allow only encrypted connections” only if needed for end-to-end encryption of sensitive sessions.
7. 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.

Best practices for system stored procedures

1. Disable xp_cmdshell unless it is absolutely needed.
2. Disable COM components once all COM components have been converted to SQLCLR.
3. Disable both mail procedures (Database Mail and SQL Mail) unless you need to send mail from SQL Server. Prefer Database Mail as soon as you can convert to it.
4. Use SQL Server Surface Area Configuration to enforce a standard policy for extended procedure usage.
5. Document each exception to the standard policy.
6. Do not remove the system stored procedures by dropping them.
7. Do not DENY all users/administrators access to the extended procedures.

Best practices for password policy

1. Mandate a strong password policy, including expiration and a complexity policy for your organization.
2. If you must use SQL logins, ensure that SQL Server 2005 runs on the Windows Server 2003 operating system and use password policies.
3. Outfit your applications with a mechanism to change SQL login passwords.
4. Set MUST_CHANGE for new logins.

Best practices for administrator privileges

1. Use administrator privileges only when needed.
2. Minimize the number of administrators.
3. Provision admin principals explicitly.
4. Have multiple distinct administrators if more than one is needed.
5. Avoid dependency on the built-in\administrators Windows group.

Best practices for database ownership and trust

1. Have distinct owners for databases; not all databases should be owned by sa.
2. Minimize the number of owners for each database.
3. Confer trust selectively.
4. Leave the Cross-Database Ownership Chaining setting off unless multiple databases are deployed at a single unit.
5. Migrate usage to selective trust instead of using the TRUSTWORTHY property.

Best practices for using schemas

1. Group like objects together into the same schema.
2. Manage database object security by using ownership and permissions at the schema level.
3. Have distinct owners for schemas.
4. Not all schemas should be owned by dbo.
5. Minimize the number of owners for each schema.

Best practices for database object authorization

1. Encapsulate access within modules.
2. Manage permissions via database roles or Windows groups.
3. Use permission granularity to implement the principle of least privilege.
4. Do not enable guest access.
5. Use users without logins instead of application roles

Best practices for catalog security

1. The catalog views are secure by default. No additional action is required to secure them.
2. Grant VIEW DEFINITION selectively at the object, schema, database, or server level to grant permission to view system metadata without conferring additional permissions.
3. Review legacy applications that may depend on access to system metadata when migrating the applications to SQL Server 2005.

Best practices for remote data source execution

1. Phase out any remote server definitions.
2. Replace remote servers with linked servers.
3. Leave ad hoc queries through linked servers disabled unless they are absolutely needed.
4. Use constrained delegation if pass-through authentication to a linked server is necessary.

Best practices for execution context

1. Set execution context on modules explicitly rather than letting it default.
2. Use EXECUTE AS instead of SETUSER.
3. Use WITH NO REVERT/COOKIE instead of Application Roles.
4. Consider using code signing of procedural code if a single granular additional privilege is required for the procedure.

Best practices for data encryption

1. Encrypt high-value and sensitive data.
2. Use symmetric keys to encrypt data, and asymmetric keys or certificates to protect the symmetric keys.
3. Password-protect keys and remove master key encryption for the most secure configuration.
4. Always back up the service master key, database master keys, and certificates by using the key-specific DDL statements.
5. Always back up your database to back up your symmetric and asymmetric keys.

Best practices for auditing

1. Auditing is scenario-specific. Balance the need for auditing with the overhead of generating addition data.
2. Audit successful logins in addition to unsuccessful logins if you store highly sensitive data.
3. Audit DDL and specific server events by using trace events or event notifications.
4. DML must be audited by using trace events.
5. Use WMI to be alerted of emergency events.
6. Enable C2 auditing or Common Criteria compliance only if required.

Best practice analysis utilities recommendations

1. Run BPA against SQL Server 2005.
2. Regularly run MBSA 2.0 to ensure latest SQL Server 2005 patch level
3. Regularly run MBSA 2.0 for SQL Server 2000 instances