Why do Pentesters seem so demanding?

Penetration testing can often feel like a rather intense exercise. There can often be various hiccups along the way including not having all the pre-test paperwork completed, systems not being accessible, or the client just not being ready for testing when it has been scheduled. Many tests can run smoothly when everything has been set up and signed off properly beforehand.

Things that testers need prior to testing and why some of these might seem odd to a client

There are usually quite a few things that need to be in place prior to a penetration test starting which the client may find unexpected:

Paperwork – consent
More paperwork – informing any hosting providers
User accounts – web app tests
Test credit/debit cards
Allowing access to IP addresses and disabling IPS systems and WAFs
Consideration of CDNs

A couple of further items should also be discussed with the client before the test, including:

Sample/test data within the application
No code changes to be made during testing

Paperwork – consent

A consent form is required for any test, regardless of its type. Consent forms for remote or internal tests targeting digital assets (so as not to contravene the Computer Misuse Act) need to include the URIs of the web application(s), the IP addresses of the systems on which they are hosted (or just the IPs if it’s an infrastructure test) and a date range over which the test is going to be carried out.

Problems can also arise during the test especially where web apps are concerned because some sections of websites go off to other servers within the domain, which, whilst they may still be in scope for the test, are not on the consent form. Sometimes this is not picked up when the consent form is initially completed by the client. Other types of testing still require consent forms but their exact contents will vary.

More paperwork – informing any hosting providers

Clients are often unaware that if their systems are hosted by external providers, they must inform them of the tests. This can cause problems for both testers and clients because some hosting providers require several days’ notice of the test prior to it starting.

This can halt things and result in the test being delayed, but they need to be informed to prevent any unpleasant surprises coming up along the way, such as the provider believing they’re being subject to a real attack. This will usually require some form of ticket/reference number or acknowledgement email from the provider.

User accounts – web app tests

Sometimes organisations don’t really consider insider attacks as a threat, because many employees are trusted. On the contrary, employees can actually present a substantially higher threat than anyone on the outside because they already have access to the system and are familiar with it, so have a better idea of where they can cause the damage.

Moreover, since there are usually multiple user levels within organisations, testers also require multiple user accounts for testing, ideally, two per user level to accurately simulate nefarious actions or intentions from users of differing levels.The user accounts should also be checked by the client to ensure they’re working prior to an engagement; sometimes accounts are provided but simply don’t work, which again delays things.

Test credit or debit cards

These are ideal for web tests that include testing checkout or payment functionality. If the client has any test card details available, for example for UAT systems, these should be provided. If not, real payment cards can be used. Normally when this happens, the client should expect test orders to be placed and then be able to cancel these on the backend.

Allowing access to IP addresses and disabling IPS systems and WAFs

Although it ultimately depends what the client wants, the focus of a penetration test against digital assets is intended to evaluate the systems’/services’/applications’ susceptibility to exploitation assuming any defence systems in front had already been bypassed. Why? It again comes down to time. Real-world threat actors can, depending on their devotion and objectives spend weeks, months or however long trying to bypass defences and break into systems.

Since penetration tests are commercially constrained and therefore don’t have the liberty of massive amounts of time, they essentially have to simulate having already hopped past the perimeter defences to see what of the client’s assets are exposed to the Internet.

A similar situation arises where web applications are concerned. Web applications should implement Web Application Firewalls as an added layer of defence, but these can also therefore cause problems for penetration testers., it really depends on what the client wants but ideally, clients should look to disabling any WAFs (as long as it’s only for the testers’ IP addresses if the application is already public) in order to give a clear picture of the application’s attack surface behind it.

CDNs

CDNs or Content-Delivery Networks are a means of handling high levels of traffic to an application on a global scale. Think of CDNs as basically globalised load balancers for speeding up the connection of a user who is located at the other side of the world from where the application is physically hosted.

These can present problems for penetration testers because the way they work means that all (including pen testers’) traffic is directed towards these load balancers, or ‘edge nodes’ as they are known, instead of the ‘real’ ‘origin’ server, which is where the application under test is actually hosted. The problem is that these CDNs can often implement their own WAFs, which can interfere with test results. So, for the most accurate results, clients should provide the IP addresses of the actual ‘origin’ server.

Sample/test data within the application

This is important because it allows for a realistic simulation of what an attacker could do to business-critical data, if they’re in a position to launch an attack.

Although a lot of the time sample data is provided in the application at the start of the test, this is not always the case. Clients should understand that in order for penetration testers to provide the most realistic simulation of an attack, they need to have access to data that’s representative of what would be accessible to normal users, regardless of privilege level. Put simply, if there’s no sample data within the application, a proper assessment of what an attacker could do with this data, such as the impact or what the damage would be of business-critical data being changed or deleted, cannot be carried out.

Although this request is understood and actioned by clients when testers ask for it, it is not always obvious to clients that such data needs to be in place for the test. This can especially be the case if it’s a new application or one that’s in a test environment.

Last but not least – No changes during testing…

“We have some maintenance that we need to carry out during testing, will this affect your testing?”

Yes, it might…

Although this doesn’t happen too often, any changes applied during testing can invalidate the results, so whenever a client asks about this, they need to be aware of the impact this might have on testing. This applies equally to web applications and infrastructure.

Final Thoughts

Providing that all, or at least most of the above is in place, penetration tests should go relatively smoothly. Clients just need to be prepared for various unusual requests from the testers.