sp_check: SQL Server Database Checks

Enabled sa login

What's the issue?

The sa login on your SQL Server instance is enabled.

Why is this a problem?

The sa login is a common attack point for SQL Server instances, as hackers know that by default every instance has an sa login and that login is in the all-powerful sysadmin role. Using password libraries to guess the password, someone with bad intentions could gain access using the sa login and do anything they want with your instance including changing other permissions or using a Windows shell to deploy malicious software.

What should you do about this?

The solution is as easy as disabling the login, since disabling only prevents the login from being used in a connection to SQL Server. Even though it is disabled, the sa login can (and should) still function internally by owning objects like databases and jobs.

If you are unsure about disabling the sa login, you can use tools like SQL Audit or Extended Events to see if the login is being used.

What do the Vulnerability Levels mean?

0 - Information only. This is stuff you should know about your instances like version and service account used, but if you don't know it…well, now you do.

1 - High vulnerability requiring action. These are the issues that could most likely lead to your company being front page news for all the wrong reasons. If your instances have any results at this level then we recommend cancelling that 3-martini lunch and instead huddling with your team to figure out when to address these issues.

2 - High vulnerability to review. These include settings and assigned permissions you should review soon, if not immediately. These findings may not necessarily indicate a clear vulnerability, but we've found unexpected vulnerabilities in these categories at many, many clients.

3 - Potential vulnerability to review. These are configurations or assigned permissions you may be using that could lead to problems for users. Or maybe they're just required for your applications. Either way, we recommend reviewing these to make sure these are correct.

4 – Low vulnerability with recommended action. These are typically security inconsistencies that should be addressed. They aren't likely to cause problems, but you should clean up the mess.