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. Sometimes our clients simply don’t understand what is required for the type of penetration or other security test they have requested. Other times clients are waiting on one of their own internal processes to get us access, or accounts, or binaries (in the case of a mobile application test).
Hiring a company to perform security testing is too often compared to hiring a software development firm. Perhaps this is because they are both thought of as technology nerds. But most security testing takes place in relatively short projects of anywhere from a couple of days to a couple of weeks, compared to the months or years of engagement for a typical software development project. For security testing, even a day or two of delay at the beginning of the project can have a significant impact. Our client might be fine with the test sliding into the next week but the tester often isn’t because next week is another test for another client, which means we will have to finish up one test while starting the next one. This usually results in working some weekend or late night hours. And the reality is that no matter how good the tester is, this is going to impact the quality of the test.
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
There is an extra ‘s’ on that title for a reason. We will need accounts. Sometimes several of them. 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 we may need six or eight or even ten accounts. Without these we cannot properly test for vertical and horizontal escalation of privileges. This being said, if your administrative role allows us to create our own user accounts then we are happy to create them as we need them.
Code Stability
You have decided you should get ahead of the game and get your security testing done before code goes to production (go you!). Just make sure 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. Any security company worth their salt can find a way past perimeter controls given enough time and unlimited scope, but is that really the goal of the test? It is often a waste of your time and money for us to spend half of our test circumventing your WAF or firewall rules. If you want us to specifically focus on the host or application security on your network, it will be much more efficient to whitelist us in these controls. If scope and time permits, the tester can also run additional tests toward the end of the testing window with your WAF in place.
Testing Assets
This can apply to any test but schedule delay issues are most prevalent around mobile applications and web services. In most cases, security testers will need the same information and capabilities to perform security testing as would QA. For mobile applications, they will need access to the binaries, so if the test is on a pre-production build you will need to provision 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. It is unlikely that you care about whether or not we can guess what format your web service will accept. If you want a good security test of a web service, make sure we start with a good map of what is considered “normal”. This can be in the form of 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 but your VPN provisioning process is slow. Perhaps you have to open a change window to start the test, and your organization only allows windows to open at a certain time each day (e.g. we have had clients with windows that opened mid-afternoon), in which case it might be best to open it the day before the start of the test. Or 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.
We would love for each penetration test to run on schedule from beginning to end, but the reality is testing engagements don’t all run so smoothly. The most important factors to ensuring a test starts on time are preparation and clear communication. The first morning of testing is usually too late to submit a form that could take a couple of days to process. It is best to leave a bit of runway and have all the provisioning ready to go a week before the testing. Also make sure you get a kick-off call with the testing team you have engaged. It is normal for the consultants to reach out to a client to schedule a kick-off call in advance. If they have not done so and your test is only a week away, give them a nudge.
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.