Maybe combine it with Honey Accounts: as well as the real accounts, you have lot of accounts which have insufficient privilege to do anything interesting, and audit successful logins as well as failed ones on those accounts. Give some of those accounts nice tempting names.

That is probably true, but if you have a billion users, you can probably only afford to have a few honeypot accounts, and therefore it is a one-in-a-million chance that you will detect a particular hack attempt. The way that this was described, (I read about it yesterday on another site) you use circa ten honey-passwords for each account, which doesn't use much space, and you have a ten-to-one chance (in your favour) of detecting a hacking attempt.

Rename sa, create a new "sa" account, track all attempts to log into it?

One would think that most hackers that are attempting to hack a SQL server would try the sa account first. Heck I can't even count how many times as a consultant I would come in and log right in with sa and no password (ok so that has been a while...).

If the production server should only be accessable by an admin or service accounts, then there is no reason why login attempts should be routinely failing with invalid account name or password. The same goes for 'invalid object' errors. That would imply ad-hoc logins and querying, so on the first failed attempt, an email should be sent to the administrators. Perhaps on investigation it would be explained by a misconfigured application change or a buggy stored procedure, but in any event, it's something out of the ordinary and worth looking into right away.

There could also be honeypot tables. For example, the DBA could create tables with enticing names like [Employee_Salary] or [Customer_CreditCard] and then place an audit event with email notifications. Even an internal hacker who gains access with a proper account name and password could fall for that one.

Eric M Russell (5/16/2013)...There could also be honeypot tables. For example, the DBA could create tables with enticing names like [Employee_Salary] or [Customer_CreditCard] and then place an audit event with email notifications. Even an internal hacker who gains access with a proper account name and password could fall for that one.

Eric M Russell (5/16/2013)...There could also be honeypot tables. For example, the DBA could create tables with enticing names like [Employee_Salary] or [Customer_CreditCard] and then place an audit event with email notifications. Even an internal hacker who gains access with a proper account name and password could fall for that one.

Oohh, I like that. A great idea.

Taking it another step forward, there could even be honeypot data. For example, a corporation concerned about hackers (or internal employees) stealing confidential financial information could populate tables with bogus revenue, sales projections, or executive salaries. Or the banks could post bogus credit card numbers on the web. When someone attempts to make a purchase using one of these account numbers, it would alert local police. Theives may even come to conclusion that databases of "stolen" account numbers are not worth the risk.

Two factor authentication would be nice, perhaps even some sort of approval process enabled that required multiple approvals for some changes.

It's funny that you mentioned this Steve, I'm actually in the middle of putting a demo system for exactly those two things at the minute. Once it's done, and if I get approval from above, I can put a post together for fellow SSC'ers to read about.