It is day three of a five-day penetration test engagement and we still don’t have all the information we need to proceed with the test. This particular test was scoped to focus on internal applications and we were to gain access to those applications through the client’s VPN solution. But instead we find ourselves waiting on the process to get VPN credentials. This probably means we have some late nights ahead so we can catch up.
This and many similar scenarios are unfortunately all too familiar to third-party penetration testing teams. Below are a few things companies should consider when engaging a third party for penetration testing or other security testing. All of these tips assume gray-box testing, where the security testers are provided with some information in order to expedite the test and make better use of time and money:
User Accounts. For applications, the rule of thumb is a minimum of two accounts per major role. In the simplest of applications this usually means two user accounts and two administrative accounts. In more complex applications six or eight or even ten accounts may be needed. Without these tests for vertical and horizontal escalation of privileges cannot be implemented.
Code Stability. Ensure that by the time your security testers are looking at it, the code is more than half-baked. Much of the security testing you do too early will become invalid if your developers are still in the middle of building out features. If the code can’t pass your QA team, then it isn’t ready for third-party security testing.
Whitelist. Beware of what is your primary goal of the test. It is often a waste of your time and money to spend half the penetration test circumventing a WAF or firewall rules. If the emphasis is to specifically focus on the host or application security on your network, then it will be much more efficient to whitelist these controls. Additional tests, towards the end of the testing window can be performed with the WAF in place.
Testing Assets. For mobile applications, security testers may need access to the binaries, so if the test is on a pre-production build they will need access accordingly. If you have implemented certificate pinning in your mobile application, it is most efficient to provide security testers with a version of the app minus the certificate pinning. For web services, most likely your goal is to determine if your developers are implementing their code in a secure fashion. This can be done by running sample HTTP requests for valid web service calls, or valid requests saved in tool projects (such as SoapUI or Postman).
Other Administrative Headaches. A number of additional things can go wrong when preparing for security testing. Perhaps you need your third party to connect in through a VPN. Perhaps you have to open a change window to start the test. Perhaps your dev team runs an automatic deployment in the environment being tested at 10am every day, taking the server offline for an hour and creating a moving target for the testing team.
It is ultimately in the client’s best interest to start on schedule. If a client’s delay at the beginning of the week results in testers having to work extra hours late into the night or over a weekend, their fatigue could impact the quality of the test and report. And that is assuming the testers will work the necessary hours to complete the test. In many cases the SoW includes a clause that places the responsibility for these types of delays into the hands of the client and does not require the testing team to work past the end of the scheduled test, even if testing tasks are incomplete.