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.
