You may want a pentest for a variety of reasons: in this blog we will discuss four common reasons for pentests of (web) applications or hardware and I will give you tips.
Above all: understand what your own reason is and communicate this with your pentest provider. It will improve your pentest experience, I promise!
The four common reasons are:
- SELL: you sell a product or service and customers or external rules require a test.
- RELEASE: you make a product and company policy dictates a pentest.
- USE: you want to buy and use a product and want to understand associated risks.
- IMPROVE: you make a product and what to reduce risks.
SELL
You approach a pentest provider to test your (web) application. Perhaps your customers asked you if it was tested, or there is an external rule or regulation that stipulates that it needs to be tested. To be clear: this is not a pentest you really want, but because of external reasons, you now have the need for a pentest.
Under these circumstances:
- You don’t want the pentest provider to spend a lot of time testing.
- You want to pay as little as possible.
- You want the application to come out “fine!”.
- You don’t want to provide the code to the provider.
In this case, a tightly time boxed black box pentest is most suitable.
Be aware though: there will be friction between you and the pentest provider. What you will consider “a good enough pentest” may be regarded as insufficient by your provider. This is not only because most pentest providers have a drive to carry out good and thorough tests. A test that is insufficient is actually a reputational risk for the provider if the results of said test are going to be used to show the world that an application is secure.
If you tell them, pentest providers will absolutely understand that you want a test because you have to. But no reputable pentest provider is going to agree to a pentest that is simply too tight to be meaningful. How tight is too tight and why? This will have to be part of the conversation that you are going to have with your provider.
Also, think ahead of the moment you are going to receive the pentest report. This report may describe issues in your application that need fixing before you can satisfy your customer’s question or comply with the external rule or regulation. Fixing is going to take time and will mean a delay in the process that you originally had in min.
RELEASE
In this scenario, you want a pentest because a new release of your application is ready, and your organisation has a policy in place that prescribes that a pentest is mandatory prior to release.
Under these circumstances:
- You don’t want the provider to spend too much time.
- You probably want to pay about the same as last time if you previously had a test done.
- You want the application to come out fine but need to know issues.
- You may or may not want to share code with the provider.
In this case, a time boxed test is suitable. White box is preferred.
You will be somewhat aligned with your provider although for you, the test is simply a tick in the box to keep on going. How much time needs to be spent testing will depend on changes in the application since the last tested release, so that is still an issue you will need to address with your provider. And finally, keep in mind that the report you will receive may describe issues in your application that need fixing before you can go ahead and release. This will mean a delay, something to be aware of.
USE
In this scenario, you ask your pentest provider for a pentest of a piece of software or hardware that you want to use.
Examples of these:
-
Software that you are going to run on premise and that you need to know the risks of.
-
Hardware such as IoT devices, or any other “smart” devices. In these cases you usually have additional questions that focus on privacy (“what kind of information does it store”, “what, if anything, does it send back to unknown servers on the internet?”.
Under these circumstances:
- You want to pay a reasonable price.
- You want to get an insight into security and privacy risks.
- You probably won’t be able to share code with your provider.
In this case, you will most likely end up getting a time boxed black box test.
However, depending on the object to be tested, in our experience it is always worth getting in touch with the vendor. Although not all vendors are equally eager to have their products tested, it is worth discussing your process, and whether you want to share results. And we have even seen cases where pentesting costs ended up being shared or shifted!
IMPROVE
In this scenario you want a pentest because you have a product and you want to know the risks, so that you can mitigate them.
Under these circumstances:
- You want to pay a reasonable price.
- You will probably supply the code unless you really cannot.
- You want a realistic view of the risks.
In this scenario, a white box test is suitable.
If your aim is to really improve your product, it is also worth looking at security earlier in the lifecycle of the product, if you don’t already do that. Implementing a secure development lifecycle will improve the quality of your product and reduce the number of findings in pentests. Usage of code analysis tools and code review practices have a direct impact on code quality.
Wrapping it all up
In conclusion, it helps to understand your own motivations for getting a pentest. Sharing your motivations with your pentest provider will improve the process and outcome of the test, whether you want to sell, release, use or improve!