Tools to enhance SQL Server security, analyze that!

There are various methods you could apply to secure SQL Server platform, that includes the areas of physical hardware and networking systems connecting clients to the database servers, and the binary files that are used to process database requests!

It is not that easy to implement the strict measures of security when the databases are spread out in an enterprise-wide network. There are tons of information about best practices for physical security strictly limit access to the physical server and hardware components. But it is not possible in all the occassions. Implementing physical network security starts with keeping unauthorized users off the network, a single-step to ensure the level of access is restricted. Next level is surface area reduction, a security measure that involves stopping or disabling unused components. This helps improve security by providing fewer avenues for potential attacks on a system and key to limiting the surface area of SQL Server includes running required services that have "least privilege" by granting services and users only the appropriate rights.  Most of this topic is available and I refer to Books Online and suggest to go through the pages of information on Security topic and also various blogs on web.

Next in the picture comes about client connection and authentication to SQL Server instance, instantly the TCP/IP protocol comes into consideration. By default, clients are configured to try all protocols until one of them works. If the TCP/IP protocol is disabled, clients continue with the next protocol. If TCP/IP is enabled but the endpoint is stopped, the connection attempt is not rejected, so the client does not try other protocols, but the stopped connection cannot be used. In this case, you must explicitly connect to a active endpoint and any additional user-defined endpoints behave the same way as default endpoints. Also BOL refers that When an endpoint is created for an IP address (or all IP addresses, by using IP_ANY) and a specific TCP port, permission to connect to the endpoint is granted to users in a process called provisioning. They retain the provisioning regardless of whether or not the server is actually listening on the IP address/TCP port combination.

You can restrict access to an endpoint to EVERYONE group, which is a good practice using DENY CONNECT statement when the SQL Server instance is accessed over internet or between enterprise domains. The best method is to grant permission to specific individuals or roles using GRANT CONNECT statment, but do not attempt to use GRANT CONNECT permission to the PUBLIC group unless you are assured about the accessibility and privileges.

Same in the series of GRANT and DENY permissions you can control the SQL Server login accessibility and enforce the password policies, say when your SQL Server has not be enabled with NT authentication which is by default. It is a bonus that SQL Server does provide such an option of enforcing password policy for SQL logins too. Password complexity policies are designed to deter brute force attacks by increasing the number of possible passwords. When password complexity policy is enforced, the new password must meet these changes, also when SQL is running on Windows Server 2003 or later, SQL Server can use Windows password policy mechanisms.. Say when creating a SQL Login you can specify CHECK_POLICY=ON and again BOL refers certain conditions to enforce this policy:

• When CHECK_POLICY is changed to ON, the following behaviors occur:
  
• CHECK_EXPIRATION is also set to ON unless it is explicitly set to OFF.
• The password history is initialized with the value of the current password hash.
  
• When CHECK_POLICY is changed to OFF, the following behaviors occur:
  
  
  • CHECK_EXPIRATION is also set to OFF.
  • The password history is cleared.
  • The value of lockout_time is reset.
    

Some combinations of policy options are not supported.

• If MUST_CHANGE is specified, CHECK_EXPIRATION and CHECK_POLICY must be set to ON. Otherwise, the statement will fail.
• If CHECK_POLICY is set to OFF, CHECK_EXPIRATION cannot be set to ON. An ALTER LOGIN statement that has this combination of options will fail.
  

As per the BOL server operating system (Windows 2003 and later) takes care of policy, and in the case of Windows XP & 2000 systems the windows password policy only checks if the password is complex enough. As the policy of minimum length and history (based on security policy to use if the same password as previous N passwords), password minimum life and maximum life can be check within Windows 2003 and later systems, where CHECK_EXPIRATION policy will take care and in such cases the login can be locked out by default when there 3 wrong attempts. By default both of these options are off on SQL Server and you can enforce whenever required by using ALTER LOGIN statement. Just a note from BOL (again) about known issue in Windows 2003 operating system that it prevent the bad password count from resetting after the Account Lockout threshold has been reached. This could cause an immediate lockout on subsequent failed login attempts. You can manually reset the bad password count by briefly setting CHECK_POLICY = OFF, followed by CHECK_POLICY = ON. For more information about the Account Lockout threshold, see Your User Account May Be Prematurely Locked Out article.

How about finding the vulnerabilities and security issues from the code?