Choosing the right Penetration Testing provider for your business

How do you choose the right penetration tester who can not only identify weaknesses but also enhance your business's cyber security posture? It’s important to make sure you are choosing a provider that you trust.

Recently, we have noticed an increase in the number of calls we have with clients for application testing where we are asking common questions like:

• Does the application use Application Programming Interface (API) calls? Are these in scope?
• If the APIs are in scope, do you have documentation, like Postman/Swagger files and workflows?
• How many user levels do you have?
• Do you have a permission matrix for these users that we can test if it's functioning as expected?
• Etc.

Responses from clients include, "Other security service providers didn't ask us this", and "We have had a penetration test before, and they never asked us this". Unless these types of questions are being asked, sorry to be the bearer of bad news; you're unlikely to get, or have had, a penetration test.

However, we encourage doing your research to ensure you get a good price, even if it's a time-allocated best-effort approach due to budget constraints – it’s important to know what you're paying for. If it's just a Vulnerability Assessment (VA), but labelled as a penetration test, there is a good chance you're overpaying, despite thinking you got the best price.

We know we're not the only great cyber security service provider out there, so here are some questions you should expect to be asked to scope and deliver penetration testing.

First, general questions like;

• What do you see as your biggest risk and threat?
• What is your organisation's ‘crown jewels’?
• Have you had any cyber security events or incidents in the past?  
• What current security services do you have?

Then, you will be asked for clarification on what type of testing is expected and required. We think the amount of information shared before an engagement can optimise testing for all involved. The testing approach is usually defined as either White, Black, or Grey Box penetration testing.

White Box - This testing involves sharing full network and system information with the tester, including network maps, source code etc.

Black Box - In a black box penetration test, no information is provided to the tester (except the scope). Instead, the tester follows the approach of an unprivileged attacker.

Grey Box - Some information is shared with the tester. For example, credentials will be provided.

The most used approach is the Grey Box since it strikes a balance between depth and efficiency and can be used to simulate either an insider threat or an attack that has breached the perimeter, stripping out the potentially time-consuming phases of a test. However, we expect to work with you if you have specific requirements or want recommendations specific to your needs.  

Next, let's look at some different specific testing questions and considerations.

Infrastructure

Can you provide us with a specific list of targets, commonly a list of IPv4 or IPv6 addresses? A list of live hosts rather than a CIDR notation is better to enable the most cost-effective quote. Although, we can quote on CIDR, for example, /25, if required. It's worth noting that the time to test can drastically increase with a large CIDR or multiple ranges. Therefore, we recommend providing a list of live hosts rather than a CIDR notation.

Do you have any services that need extra consideration? An example would be a publicly available VPN. We would attempt to access various ways, including scaping users from OSINT and brute-forcing the application. Depending on the technical controls, this could result in many user lockouts. A solution could be for test credentials to be provided.

Do you have any monitoring or security solutions? We provide our testing IPs to allow lists and assist in log record tracking.

Another factor affecting the internal infrastructure testing timeframe is whether we can reach all hosts from one location. The more ranges we can reach from one location, the more time effective the test.

Another question for internal testing is how you would like us to access the network. If you do not have a practical solution for testing, we can provide multiple options.

Credentials - We recommend a set of user (domain joined if relevant) and admin credentials. This allows us to do a full vulnerability assessment whilst carrying out the penetration test, revealing hidden issues that an attacker could exploit if given enough time.

Web Application

What is the testing environment?

We recommend not testing in production if possible, and a duplicate test environment is created. This allows for more vigorous productive testing and prevents any negative impact on the production environment.

We can confirm the findings on the test application on production. However, it's not required if it's a complete copy of the production.

If sensitive data has been removed from the test application, we recommend implementing dummy data to provide a more realistic environment.

If testing on a production environment is required, considerations will be discussed prior, for example, only manual testing and no automation.

Some authentication questions;

Is the application being tested authenticated? We recommend all user levels are tested unless there are specific reasons not to test. For example, admin can only be accessed via IP allow listing, which we can still test much more time-efficiently.

How many user levels need to be tested? If the application is self-registered accounts only, these do not need to be created.

We request two sets for each user level credentials if the users are expected to see different data. This allows us to test horizontal and vertical segmentation.

Are there any security solutions, for example, a Web Application Firewall (WAF)? We recommend IP allow listing us to enable the application to be tested rather than the security solution. Since these could be bypassed within an unlimited timeframe and often fail open, meaning if they fail for any reason, the application is still publicly available, allowing previously hidden protected vulnerabilities to be accessible.

API

Ideally, provide us with a Postman/Swagger file for an accurate quote and to maximise the testing timeframe. Considering the testing timeframe, we also request that known good variables be included in the files if available. Several options usually exist if a Postman/Swagger file is unavailable. For example, we can conduct API endpoint fuzzing and create them from scratch, or if they can be interacted with on an HTML layer, endpoints can be collected.

Can we get any workflows and relevant documentation, i.e. authentication flow?

Similar questions to web applications around what the testing environment and authentication is.

Are there any security solutions, for example, a Web Application and API Protection (WAAP)? We recommend IP allow listing us to enable the application to be tested rather than the security solution. Since these could be bypassed within an unlimited timeframe and often fail open, meaning if they fail for any reason, the application is still publicly available, allowing previously hidden protected vulnerabilities to be exploited.

The above may seem daunting, and all the questions and considerations may not be relevant to what it is you’re looking for. However, ultimately, a good cyber security organisation will want to work with you and assess your needs and should be asking these sorts of questions to accurately quote and conduct your penetration test.

CYBAVERSE offers penetration testing services. As a CREST accredited organisation for penetration testing, CYBAVERSE offers the highest standards throughout, ensuring that you get the best value from your Penetration test.