A penetration testing exercise is always filled with challenges – both for the organization who is to undergo this and the team/organization who is conducting this. Both have different perspective of the challenges. The organization requesting a penetration test has to worry about its objective, scoping, vendor selection, planning and so on while the organization/team conducting the penetration test will have its own set of challenges in the form of selecting the right framework, planning and executing a controlled attack and more. One aspect which is common to both organization and team is – how do we ensure that there is no business disruption or at the least limited performance impact on the target network or systems due to the penetration test.
A successful exploit of certain type of vulnerability during penetration test has the potential to bring down the affected application or service. While this can be a proof-of-concept for the security organization and the team conducting the test to showcase that a real life attacker can also exploit this, the business unit may not appreciate the disruption in business caused by this exploit. The most common concern as well as ask of a customer is -
“Can you assure me that you will not cause any disruption to my production environment while conducting penetration test?” Or
“Can you schedule the penetration test in such a way that it causes least disruption to my production environment?”
The issue of unexpected downtime arising out of a successful exploitation of a vulnerability can be mitigated to an extent if not fully by scheduling potentially disruptive testing during off-business hours or better still during maintenance window.
It becomes somewhat easy to find a safe-to-run PT window of opportunity if the number of target hosts or application are fewer. But this eludes larger organization where the number of hosts and applications runs into hundreds or even thousands. In such a large penetration testing exercise it becomes extremely difficult to find and agree to a safe-to-run PT window across different business groups. The present era of globally distributed business operations and 24x7 operations does not help either. The penetration testing team/organization also has a limited time to execute the assignment. So, what do we do?
The answer lies in the penetration testing methodology itself. The penetration testing framework consists of multiple steps and not all of them involve attacks and not all of the attacks are disruptive in nature. The penetration testing team should break the testing stages into multiple work units classifying them as absolutely safe to execute, generally safe, potentially dangerous to execute etc. For example information gathering could be termed as absolutely safe as it does not involve intrusive tests. Port scanning and enumeration can be classified as generally safe if not performed aggressively. These tests can be scheduled even during normal business hours if the business unit of organization sponsoring the penetration test is convinced about the safety. The penetration testing team then can demand a relatively small time frame to conduct the testing of exploit having potential to cause disruption. This time frame can still be reduced if attacks are planned in advance and well-chosen instead of blind attack.
A few things which I learnt and which helped me get quick approvals of testing strategy/schedule from customer in large scale PT assessments:
- Stay methodical. Do not run wild with exploit frameworks against your customer’s network or application as there are safe and unsafe exploits that could seriously impact the targeted application or infrastructure’s availability.
- Give an indication to client about the type of exploit you are going to attempt and its potential consequences. Request them to monitor the targeted application and infrastructure during these times and report to you in case they see disruption. Stop all exploit testing immediately if requested.
- Always keep your customer updated about your next steps and what you are going to test. Stay in touch with the client constantly, be available at all times and make sure you are receptive to their needs.
- Build a trusting relationship with client, let them know that you feel their pain right along and would take all the steps necessary so as not to cause any unexpected disruptions to their application and infrastructure.
Authored by K Siddharth