Penetration testing – what we need to know from you and why

Sometimes, our clients are startled when, at the start of a new penetration test engagement, long before testing begins, they are asked questions about the test and what exactly they need. Many clients are confused that they cannot simply ask for a penetration test, pay for it, and receive it as they would another service or product. There are several reasons for this and most of them are for the safety of our clients and ourselves.

The first reason that we ask so many questions about the test is to clarify the scope. Getting this right is crucial and tricky, as not all of our clients have the same requirements. Not all of them are performing testing for the same reasons, and not all of them have the same level of technical understanding. Ensuring that both parties completely understand exactly what will be tested – and in what manner – will allow us to:

• Accurately estimate the time it will take to perform the test
• Ensure that the end result is what the client is expecting
• Ensure that the test will be performed safely

The other purpose of the scope questions is to ensure that the test will be performed safely and legally. This is a point of confusion for a lot of our clients, as it is likely they have never needed to think about the legality of penetration tests; we find that, to clarify this, it often helps to think of this using a physical analogy – as if we were locksmiths testing the locks on the client’s premises. Here are some of the questions we are regularly asked with explanations using this analogy:

‘Can’t you act as a real attacker would and just identify our websites/offices yourselves and attack them?’

If we employ the locksmith analogy here, imagine us walking up and down streets, looking in windows, testing locks on doors and attempting to gain entry. So much could go wrong.

We could misidentify a site as belonging to our client then break into a building that was not owned by our clients. Accident or not, this is obviously illegal. This would be akin to us accidentally testing a website that our client does not own, which is also illegal.

When testing the locks on the doors, we have no way of knowing if our clients actually own the premises, or if they rent the space inside from a landlord who owns the structure. This could result in us testing locks that we do not have permission to test. Furthermore, we could damage the locks or successfully gain entry without the permission of the owner – all of which would be illegal. This would equate to us testing a web application, hosted on a server in a rented rack space or cloud platform, without getting permission from the system’s host.

Additionally, even disregarding the prior issues, if any onlookers in the street witnessed us attempting to break into businesses, its likely they would likely call the police. This is similar to network equipment that may exist between the tester and the system.

‘It’s our website/office, why isn’t our permission enough to begin testing?’

Although this is touched on above and may be obvious to those with a technical knowledge base, it is worth further clarifying that the reason for this is although you may own the website or maybe even the system running the service, it is uncommon nowadays that you own and operate the physical hardware running that system; most web services exist only in data centres.

Similarly, although your office IP address may be assigned to your business alone, if your office exists in a managed office space it may ‘belong’ to a managing company, or your traffic may run through their network hardware – both of which would mean that their permission would be required in addition to yours.

To use the locksmith analogy once more – although you may own your office space and all objects within in, it is not a given that you own the locks and doors.

What does a tester need to know before starting?

Typically, penetration testers will want to know at least the following:

• The list of targets, in detail
• What the targets are (Network Infrastructure, Web Application, API, etc.)
• In the case of a web application or API, a rough approximation to the number of endpoints/pages
• The sensitivity of the data on the systems in scope
• Where the systems are situated
• If there are any third parties (web hosts, managed service providers)
• Who these third parties are, with written permission allowing testing
• The level of access you would like the testers to have

For more information, I previously wrote a blog post covering this, which you can read here.

That’s it really

Hopefully this article gives you a good understanding of why it’s important for us to ask you plenty of questions prior to your penetration test, and what those questions are likely to look like. We aren’t trying to be annoying – it’s just important that we’re all on the same page so we can deliver what you need while ensuring we all stay on the right side of the law.

Interested in finding out more about penetration testing?

You can find out more on the pentesting page of our website, or get in touch with our team to discuss your requirements.