Hiring a company to perform security testing often compared to hiring a software development firm. Perhaps this is because they are both thought of as a group of technology nerds performing a specialized task. 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 delays at the beginning of the project can have a significant impact on the effort put into an assessment. In addition, even if our client might be fine with the test sliding into the next week, that doesn't mean the tester will be available. He or she may already be lined up to conduct 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 weekends 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
We will need accounts. Almost always 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
Be aware 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 your perimeter controls. If scope and time permits, the tester can also run additional tests toward the end of the assessment that include perimeter controls such as WAFs and firewalls.
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, this means they will, at a minimum, need access to the binary application bundles, 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. Some examples could be:
- You need to connect in through a VPN but your VPN provisioning process is slow.
- The testing can only happen during a change window which is limited
- It might be best to open it the day before the start of the test.
- Your development 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.
