Performing a pentest can be part of your objectives, without it being the priority of the moment. This for various reasons: developments are in progress, a migration is planned, a budget has not yet been allocated, etc. Given the different constraints and priorities that need to be respected, when is the right time to perform a pentest?
We will present various situations in which the question arises and give you some keys to identify the right time to perform a penetration test.
You are in the development phase of your product and waiting to have a stabilised version before performing a pentest.
For a project under development, it is indeed interesting to wait until the first version is more or less stabilised before carrying out a pentest.
But in some cases, especially projects where a large coding phase is planned, it can be useful to do some testing along the way, as soon as some core features are ready. This allows you to check part of the work in order to build on a healthy foundation. It also helps to guide the further development, in order to avoid reproducing some errors and to limit the time to be spent later on security fixes that could delay production.
For smaller projects, a penetration test can be planned only at the end of the development phase.
You have a server migration project. A penetration test is therefore not the priority
In general, it is more useful to test the new server configuration, when it is implemented, than to test a configuration that will soon no longer be used. However, the risks on the existing infrastructure need to be taken into account: when will the migration be carried out? In the meantime, what is the level of risk exposure?
The answers you provide to these questions will decide the right time in your situation.
It is good to know that in the case of a web application pentest, there are two phases: a test phase on the application layer and a test phase on the servers. It is possible to do these two phases at different times, in order to test the application if there is a short-term need and then the servers when the migration is completed.
It should also be noted that for this type of penetration test, the server testing phase represents only a small (but nevertheless critical) part of the total volume of tests to be planned.
You are planning to rebuild your application
If the old version of the application is going to be abandoned, the first thought is that it is not relevant to test its security. But this deserves careful consideration: what is the criticality level of the application? What is the deadline for the refactoring?
For budgetary reasons, it is often not possible to carry out an in-depth pentest on the old version of an application that is being rebuilt.
Performing a quick pentest on the old version is a possibility in order to get security feedback, which will enable to correct the most “obvious” flaws (from an attacker’s point of view), and which can also guide new developments (by making developers aware of certain security issues).
It will always be important to carry out a security audit on the new version of the application, if it becomes the main application for users. In some cases, having first conducted a quick pentest on the old version will also limit the time to be spent on correcting flaws in the new version, due to the transfer of security skills that will have been carried out.
You don’t yet have the budget for a penetration test
Budget is a factor that often hinders penetration test projects, for understandable reasons. However, beware of the common misconception that any pentest necessarily requires a budget of at least 10k€. In reality, it all depends on the scope and the level of depth expected for the tests.
Some clients choose to start with a first quick audit to respect a very limited budget (for less than €1500 for example) and to obtain a first feedback on on the security level.
This allows obtaining a first indicator, depending on the vulnerabilities that would be found with very reduced time means.
This is particularly relevant for young startups, who wish to set up security tests with a very small budget and then gradually increase the resources as they grow and their level of risk exposure increases.
You don’t have time for a pentest, the team is focused on other priorities
It is understandable that you do not want to add missions to the team. However, beware of the priorities that often go to the projects to be delivered and which always push security a little later. Do not postpone the pentest too much in order to do it “when the time is right” so that potential critical flaws are not ignored.
Moreover, a pentest does not involve the development team very much. Pentesters are relatively autonomous in carrying out the security audit. In some cases, they will need you to provide them with a test environment or even test accounts beforehand. Following the penetration test, depending on the vulnerabilities identified and the corrections required, the dev team may be more or less mobilised. However, you will be free to prioritise the corrections to be implemented, for example, by prioritising critical flaws and integrating the other corrections into your roadmap.
You want to first correct the security flaws that you already know about
By fixing the vulnerabilities you have already identified before performing a pentest, pentesters won’t “waste” time on known vulnerabilities and can focus on finding other vulnerabilities.
In these situations where vulnerabilities are known, however, we have seen a pitfall: postponing the pentest for a long time (sometimes months, sometimes more) to allow developers to fix the vulnerabilities. Sometimes this situation is extended because other priorities are established, unforeseen events have occurred or corrections are not 100% finalised.
In the meantime, there may be risks associated with unidentified vulnerabilities, or vulnerabilities that have been identified but whose impact is minimised. The penetration test provides an external view, with a prioritisation of flaws by criticality level. It does not matter if we find flaws that you already know about, the important thing is to provide you with visibility on all the flaws we have been able to find, on their impacts and their levels of criticality, and how to remedy them. You will then be able to decide on the order of priorities.
You first want to finish the correction following the previous pentest
Indeed, if you wish to deepen the tests on an already pentested area, by finishing the correction of a previous security audit, the pentesters will be able to go further in their research during the next one. They will also be able to check that the fixes implemented has not created any undesirable effects on other elements.
In other situations, for example, if you want to test another target, then the pentest can be conducted independently of the remediation in progress.
You are waiting to get your first clients to finance the pentest
Sometimes the budget for a pentest is only allocated if a certain sales amount is reached or if an end client finances it. This postpones the audit to an uncertain time.
However, clients are increasingly aware of the importance of the security of their data, following the numerous data leaks or cyberattacks that make the headlines. Being able to provide proof of security when dealing with prospects can help to win new clients, which will help to achieve business objectives.
Strengthening security becomes then an investment to win new business, not an expense. To go further on this point, we give you four keys that show the return on investment of a security audit.
You are starting a certification process, you will run a penetration test in a second time
If you have just started a certification process, it is possible that you will first be focused on other topics, such as risk analysis, protection reinforcement and process documentation… The pentest will come next, unless there is a particular urgency on your side, and in this case it is always possible to carry out several actions in parallel.
The pentest confronts the security analysis with the real threat, which is usually done in a second step, even if it is not an absolute rule. Performing a black box penetration test, with a limited time to attack different information system entry points, can also be a good start before tackling in-depth analysis and protection reinforcement work.
You are not exposed to attack risks for the moment, you will invest in security a bit later.
It is true that some activities are more exposed than others to cyberattacks that target them on purpose, for various reasons (types of data processed, expected financial gains…).
However, not all cyberattacks are targeted. Some bots scan the web on a large scale to find vulnerabilities, especially on servers or CMS. And, of course, there are mass phishing campaigns, for scams or to spread malware. It is therefore important to protect yourself a minimum against the main risks.
Testing and strengthening your security in a period when you are not very exposed allows you to build a healthy foundation, without waiting for the period to become critical, knowing that the investment will be less important if you are facing a non-critical level of risk.
For the moment, our clients don’t ask us to perform pentests, maybe this will come later
Performing a pentest before your clients demand it would show that you are proactive on the security topic. This would make it an argument in your favour to create a relationship of trust with your clients and partners, and to differentiate yourself from your competitors. Security then creates value to encourage sales.
On the other hand, it is always less complicated not to act in a hurry, and not to wait to be in a blocked sales process while waiting to be able to show a security audit report. A minimum of anticipation is advised, depending on the profile and potential requirements of your prospects.