SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Before You Begin Auditing...

There is a fine line between auditing and attacking. The line actually is one built based on authorization. Same tools, same techniques. So before you begin auditing anything, make sure you have authorization to do so from someone who is imbued by the organization to legally give it. You want to get this in writing, whether on an actual signed letter, or at least an email. You do not want to rely on verbal okay. Should you not get authorization in writing, you may end up like Randal Schwartz, who fought a lengthy legal battle to get his name cleared when he tested passwords while working for Intel. At the time, this was a "given" for good system administrators to do.

Among the things that you should get permission to do before you do it:

  • Any sort of network scans, even if you're using an automated tool (like scanning for SQL Servers in the environment).
  • Any sort of password testing, even if it's against "your" server.
  • Running any sort of tool that could be considered a hacking tool, to include packet sniffers like Wireshark or Network Monitor.
  • Attempting any sort of physical or social engineering penentration test.
  • Running any sort of tools that simulate exploits to see if a system is vulnerable to an attack.

This sort of authorization may be built into your job description. When I was a systems and security architect, it was in mine. I frequently did limited security tests of systems as well as evaluated the reports coming back from automated systems that did vulnerability scans. However, now that I sit as a DBA again, before I perform a security test, I ensure that not only my manager but also the head of our security folks both know what I'm doing and that I have written confirmation that it is okay to proceed. While I held the role in the past and I certainly have the skill set to run the tests, I no longer have the authorization to do it on an ad hoc basis.

The bottom line is to ensure you're covered legally. If it's not in your primary job duties to do these sorts of tasks, insist that you get permission first. This is a great example of where you're security analysts, security administrators, and/or internal auditors are the folks to turn to. If you aren't authorized to run said scan, and the powers that be don't want you running said scan, they'll be able to step in and tell whoever is asking you to do so that you can't. Of course, always seek to resolve this diplomatically. For instance, if it's your boss asking you to run the scan, let him or her know that you're going to let the security folks know first so that if their systems trip, they know it's a legitimate security event and not a security incident which bears further investigating (and likely your boss will agree that not telling them and having a security sensor trip is a bad idea). Then contact them, explain what you're up to, and if they need to push back, bring your boss into the conversation.


K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.


Posted by Hugo Shebbeare on 7 July 2010

Very good points!  I fully agree with this approach.

Paper trails, authorisation, confirmation and documentation of what was said at every step of the way is your best bet to avoid a nasty charge was Randal received.

Most organisations don't like to hear that they are doing something wrong, so in any documentation you provide tread lightly and make it look as if it is normal to 'overlook' things instead of, as you say, attacking - it works much better.

I happen to be in a similar situation as Randal, but went on the offensive against the government organisation after a deparment head threw me out for doing my job (firing the whistleblower is illegal in Canada, but rarely enforced). Now I have two governmental organisations and the association of retirees on my side against this poor performing institutional fund manager:


Nobody wants to do Auditing jobs that I know of, it takes a load of guts to survive the worst case scenario.

Thanks again for your great post, my fellow SQL MVP :)

Posted by AjarnMark on 9 July 2010

Excellent points, Brian!  Especially the part about how you previously had implicit permission, but no longer do.  That scenario of changing jobs and not realizing that your former permissions no longer apply has been playing out in various forms in our company.  In particular, a former member of the helpdesk that has moved to the business side keeps getting asked to perform helpdesk activity by his coworkers and his boss wants us to restore his higher security access.  We are holding the line firmly that it is inappropriate, and although we are short-staffed, they still need to send their requests for help to the currently active helpdesk.

Leave a Comment

Please register or log in to leave a comment.