Security+ Topic - Penetration Testing Authorization

At some point in an IT administrators career they do a little dabbling in penetration testing of systems that they have access to. Sometimes these tests start as a simple check of vulnerabilities on their own system and sometimes it ends up being a test against the companies production servers simply because they are curious. What most of these casual or introductory penetration testers do not take into account, is that some of those test could cause a server to stop responding. If the administrator is working against a lab environment or a couple of servers that are not in production, this is usually not a big deal. A simple reboot and then things are back up and running. Things get a bit messier when that same thing happens against the production environment. The owners of a company do not usually take kindly to when their production servers go offline. Let's talk about using a test lab for a moment. Generally speaking a company will have enough resources for an IT administrator to setup a test lab. Some will have a fully virtualized environment that the administrator can simply spin up a few virtual machines into a separate VLAN to do their testing. On the other end of the spectrum is a tight budget IT department with scrutinized purchases. No matter where you are on the spectrum, there is still room for making sure that your penetration testing is not initially on production systems. The reason for these environments is pre-planning in regards to getting authorization for penetration testing on production systems. If you were to go to your management with an idea of penetration testing your production environment and they asked you what the impact would be, the only realistic answer would be that you do not know. Management wouldn’t take too kindly to not knowing if their servers were to go down and because you were the one to take them offline, you are the one getting fired. Doing testing within a lab environment gives you the pushing power for completing tests in a production environment. Company implementations of their server setup are unique and the tests in your lab environment must match that environment as close as possible. After the tests have been completed in the lab environment with proof of what may or may not happen, then you can go to management with a plan for the production environment. Sometimes you may find that a certain vulnerability test identifies an issue in the lab environment and a simple patch corrects the issue. After applying the patch in the lab and verifying functionality, it can then be pushed to the production environment. Once this is completed a plan can be presented to management for a specific vulnerability test in which you confirm the patch is in place and you would like to confirm that the correction is working properly. A lot of what this boils down to is making sure you have permission. Without permission, when something goes wrong it is you who takes the brunt of management. With an outlined plan for what you would like to do and how it is going to be implemented, management can sign off on the process which frees you from repercussions if something happens. Making sure to have all your documentation in place and a plan for what is happening is key to correct authorization.