Security Checklist

Here is a SQL Server Security Checklist to help you get started

SQL Injection Checks

Check	Description
	Input passed to data access methods that originates outside the current trust boundary is constrained. Sanitization of input is only used as a defense in depth measure.
	Stored procedures that accept parameters are used by data access code. If stored procedures are not used, type safe SQL parameters are used to construct SQL commands.
	Least-privileged accounts are used to connect to the database.

Authentication

Check	Description
	Windows authentication is used to connect to the database.
	Strong passwords are used and enforced.
	If SQL Server authentication is used, the credentials are secured over the network by using IPSec or SSL, or by installing a database server certificate.
	If SQL Server authentication is used, connection strings are encrypted by using DPAPI and are stored in a secure location.
	Application connects using a least-privileged account. The sa account or other privileged accounts that are members of the sysadmin or db_owner roles are not used for application logins.

Authorization

Check	Description
	Calling users are restricted using declarative or imperative principal permission checks (normally performed by business logic).
	Calling code is restricted using identity permission demands in scenarios where you know and want to limit the calling code.
	Application login is restricted in the database and can only execute selected stored procedures. Application’s login has no direct table access.

Configuration Management

Check	Description
	Windows authentication is used to avoid credential management.
	Connection strings are encrypted and encrypted data is stored securely, for example, in a restricted registry key.
	OLE DB connection strings do not contain Persist Security Info=”true” or “yes”.
	UDL files are secured with restricted ACLs.

Sensitive Data

Check	Description
	Sensitive data is encrypted in the database using strong symmetric encryption (for example, 3DES).
	Symmetric encryption keys are backed up and encrypted with DPAPI and stored in a restricted registry key.
	Sensitive data is secured over the network by using SSL or IPSec.
	Passwords are not stored in custom user store databases. Password hashes are stored with salt values instead.

Exception Management

Check	Description
	ADO.NET exceptions are trapped and logged.
	Database connections and other limited resources are released in case of exception or completion of operation.
	ASP.NET is configured with a generic error page using the <customErrors> element.

Deployment Considerations

Check	Description
	Firewall restrictions ensure that only the SQL Server listening port is available on the database server.
	A method for maintaining encrypted database connection strings is defined.
	The application is configured to use a least-privileged database login.
	SQL server auditing is configured. Failed login attempts are logged at minimum.
	Data privacy and integrity over the network is provided with IPSec or SSL.