This is a follow-on post to You Must Trust Someone. My point in that post was to establish that being able to and and actually trusting your account and server administrators is a necessity. I didn't go into the business aspect of that, but basically it boils down to having a good selection process for candidates, checking out their references, their backgrounds, doing the proper security and criminal background checks, etc., and getting to know them not only during the interview process but especially after they have come on board. Even if you do all of that, you should still put good measures in place to ensure someone has to make an overt act to breach security and even then, have proper auditing set up to hopefully document that breach. SQL Server MVP Arnie Rowland expanded on that a bit with respect to network engineers in his blog post.

My ealier post focused on account and server administrators. Now let's turn that focus on DBAs. Allen Kinsel (Twitter: sqlinsaneo) and I traded a few comments on Twitter, and I did the same with Russ Johnson (Twitter: russjohnson). I asked a simple question and that was if anyone audited jobs created for SQL Server Agent. Not very glamorous, I know. But a job can be set to be owned by a sysadmin level user, such as sa. And SQL Server Agent will run it under the context of that login, even if it is disabled. Which leads to the following attack mechanism:

1. Rogue DBA create a new SQL Server Agent job owned by sa that does the following:

1. Creates a new SQL Server-based login.

2. Issues a GRANT CONTROL SERVER to that login (in case you're only auditing for additions to members of the sysadmin fixed server role).

3. Creates a new job owned by the login which runs the data retrieval.

4. Deletes itself upon successful completion.

2. The second job does the following:

1. Queries the sensitive table(s) and gets it out of SQL Server. One way would be to use Database Mail and push the results of the query to an anonymous Internet email account provider (especially if the organization isn't blocking these).

2. Creates a new job owned by sa which deletes the login.

3. Deletes itself upon successful completion.

3. The third job does the following:

1. Deletes the created login.

2. Deletes itself upon successful completion.

If you're auditing 100% of the commands the DBAs execute, you'll audit this attack. But the question is, with the amount of events to sift through, will you pick it up quickly? Eventually, yes, you should, if you're watching for unusual queries against sensitive tables/views. You'll see the unknown login making the query and you'll back-track. But unless you've got really tight control on your SQL Server Agent jobs, you'll not bat an eye at the fact that a job is being created by a DBA. This is because it happens frequently enough that the watchers get desensitized to it. And the automated processes which try to mine out which events are of concern and which aren't will likely be tuned back on SQL Agent job creations. I've seen this with a could of the IDS packages I've looked at. For instance, they have a signature that says if they see xp_cmdshell running across the URL for an HTTP request, to flag it. The problem is, legitimate requests can cause that signature to be matched and for the IDS to fire. Don't believe me? Check out the video I did on xp_cmdshell execution and once you go there, look closely at the URL. Notice the xp_cmdshell in there? It causes that signature to fire. After a few false positives like that, whoever is managing the IDS will either (a) tell the IDS not to fire on that signature or (b) ignore the alert when the IDS does fire. That's desensitization.

So that means the whole alerting process starts when the unusual query is noticed. But how long will it take? Again, even if caught, the DBA has gotten the data and had time to do something with it. The repercussions I listed in the earlier post are the same. So at the end of the day you've got to trust the DBA. Yes, you still must audit, but you definitely must have DBAs you can trust. And keep in mind, I've listed just one attack pattern here which looks to evade detection, if only for a short time. If someone really wants to get in and that person is good enough, that person will find a way. However, good security measures and auditing practices will stop most folks, even if they're smart, and smart enough to figure out the limitations of the security you've put in place.