29 January 2020
Companies are increasingly dreading the risks of cyberattacks in 2020. In order to validate the quality and resilience of their various protection tools, some firms have set up penetration tests.

According to IBM’s 2019 Cost of a Data Breach Report, the cost of a data breach is now estimated at 3.92 million USD on average.

Another major finding of the article is that businesses that not only have incident response teams and procedures in place but also test these response plans perceive 1.23 million USD less cost on average in the event of a data breach. 

So how can you check whether your company’s security measures are up to the task? How can you make sure that the new mobile app you’re waiting to roll out will not leak confidential data, or that your SOC team really are able to detect a threat in real time?

The solution: penetration testing. This article – the first in a series – will walk you through the basics of penetration testing, and how to derive the most added value from the process.


Pentest is:

A pentest (short for penetration test), also known as “ethical hacking” or “intrusion testing”, is a method used to evaluate the security of a given information system by performing intrusions that mimic a real attack. Pentesters (the individuals performing the pentest) often employ a multi-stage approach, based on multi-vector attack scenarios that first identify security vulnerabilities before attempting to exploit them.

A pentest can be used for a wide range of targets such as a web app, thick applications, mobile apps, a complete IT network, a company’s physical offices, payment terminals on motorways – and many more.

The objectives of a pentest can be just as varied: to test the response and processes of in-house security teams in the event of an attack, to verify the security of a new app, to validate a regulatory requirement (mandatory for  PCI DSS or HIPAA compliance for exemple), to identify vulnerabilities in your current security measures, to test the security of new head office premises, etc.

To be effective, a pentest must identify the real risks of your organisation suffering a cyberattack AND the potential impact of such an attack on the key aspects of the company and its business.

In this article, we will be focussing specifically on pentests for web and mobile apps and infrastructures. 


Pentest is not:

A quick aside about terminology: 

A pentest is not to be confused with a security audit. Security audits are often wider in scope and can have an organisational or technical parts. Generally speaking, if the test does not cover the exploitability of the identified security vulnerabilities, then you can’t call it pentesting.

Similarly, vulnerability scans are only one component of pentests. This technique will list the vulnerabilities found at a given point in time, but will not go on to analyse them or ascertain how they could be exploited (and can therefore generate false positives).

Neither is pentesting a magic solution for safeguarding your company’s IT system. It is one component – albeit an important one – in an continious cycle of IT security improvements aiming to validate the effectiveness of or to identify weaknesses in the strategies and methodologies you have put in place.




For example, it would not be advisable to spend your security budget on a pentest, only to read in the test report that “your network was penetrated because of  missing software and equipment updates” because you have no patch management policy in place. 

You would be better advised to make earlier investments in:

  • Educating users through e-training, workshops, test campaigns (e.g. phishing).
  • A risk analysis and asset inventory.
  • An up-to-date and well-deployed antivirus solution.
  • Email protection software (with anti-spam and anti-malware filters) and a secure email gateway configuration.
  • A back-up solution (offline if possible).
  • A vulnerability scanner licence and the time to run scans, identify high-criticality issues (and the reasons why they exist) and correct them. Repeat this regularly.
  • An effective and continuous patch management policy. Remember to include network equipment, peripheral devices (such as printers) and mobile devices.
  • Log centralisation, protection, correlation and analysis tools.
    These tools will also be of use during the pentest process to train your security staff about detection and response in the event of real attacks.

Only once all these aspects have been addressed is it worth calling in the intrusion experts.

And to round off this chapter, if a pentest is performed in two man-days, then it is probably not a pentest. If a service provider sells you this type of services, it is likely to be a straightforward vulnerability scan dressed up in a glossy report. 


Pentest scoping : 

The first question to ask is “Why are we running this pentest?”.

This might reveal quite a specific target for the pentest:

  • Within the context of deploying a new web or mobile app:
    • To pentest the app and the back-end infrastructure to make sure that sensitive data is well safeguarded, is the logical answer.
  • To meet certification requirements:
    • Generally speaking, if a certification requires pentesting, the scope will be compulsory (for PCI DSS, for example, this involves the entire CDE or Cardholder Data Environment).
  • Subsequent to a major change in the infrastructure (e.g. deployment of WiFi network)
    • Does this change expose the internal network to new threats?

Sometimes the reason for pentesting is less specific:

  • To test the incident response procedures or the readiness of security teams
  • To identify gaps in the security measures in place
  • etc.

In these cases, for all that the exercise might prove quite insightful, pentesting all of your internet-facing assets might not be the best approach.

To increase the benefit of a pentest, you need to think in terms of the critical assets and processes within your organisation and designate them as “trophies”. When the objective of the pentest is to access a confidential customer database or to disrupt a critical activity, the impact can be more easily translated in business terms and shared with decision-makers.

This will also avoid the distraction of technical pedantry, i.e. identifying technical flaws that are technically very interesting yet not easilyexploitable in a real attack situation.

Even within a wider scope (all internet-facing assets), it is still important to place identified vulnerabilities in their context.

Example : If a UAT web server is compromised, but is totally isolated within a DMZ (demilitarised zone, e.g. buffer zone between local network and Internet) and the lateral propagation is impossible, the impact for the company and business is not significant.

Another way to increase the benefit of the pentest is to use it as an opportunity to improve your monitoring. It is not every day that your security teams will be pre-warned of an attack; capture as much logs as possible on the pentest targets and your security tools, set up appropriate protections and alerts to identify similar future attacks then apply these findings to other potential targets. 

As a closing point, if the scope of the pentest is too narrow, then you risk overlooking large security gaps in other parts of your IS, hence the relevance of targeting your critical assets. 

If, however, the scope is too wide, this presents other issues in itself:

  • The cost of the pentest will escalate, both during the preparation and execution phases. 
  • The volume of data reported will also increase, which can sometimes drown out the most pertinent information.


Pentest preparation and conditions definition:

With the pentest objectives clearly defined and the targets identified, the next step is to determine the execution conditions of the pentest.



The right time to perform a pentest will depend on how your company organization. It would, for example, be advisable for an e-commerce company to avoid the peak end-of-year period when IT teams are working at full capacity, or a software publisher may prefer to perform a pentest before an application goes live. 

Factoring in these types of milestones will also leave time for the technical teams to correct any flagged vulnerabilities.

In all cases, the pentest dates will need to be approved by the affected business owners and at senior level in order secure support from management.

Internal staff involved: 

As well as the business onwers mentioned above, it may be relevant to involve your admin / IT security or development teams. They will have additional information and inputs to contribute during discussions with the pentesters. 

You should also remember to appoint emergency contacts (business and technical) and ensure these individuals have the authority to make decisions and take action to resolve any questions raised or to manage any technical setbacks during the pentest process.

External parties affected: 

Remember to confirm the legal and technical possibility of performing pentests with your external partners and service providers if they are affected.

If, for example, you want to pentest your online storefront, but this is hosted by an external service provider, you will need to seek their agreement and double-check for any prohibited attack scenarios. 

One example specific to AWS: standard pentests on application layers are authorised by default, but distributed denial of service (DDoS) type testing is prohibited. (https://aws.amazon.com/fr/security/penetration-testing/)

Technical environments:

Let’s not forget that despite the precautions taken by pentesters to limit the impact of penetration testing (except in specific cases where the objective is to test the resilience of the target), unexpected side-effects may still occur. 

There are several possible solutions to limit the impact of any such side-effects.

The number one recommendation that we make to our customers is to perform the pentests on a test or pre-production environment.

Pentesters will then be able to run more aggressive attack scenarios using automated tools, which significantly increases the extent and the quality of the testing. It is important though that the test environments resemble the production environment as closely as possible. 

Another recommendation is that you make (and test) backups of the targets, even within a test environment. Doing so means it will be easier to roll back to pre-test conditions once the pentest is complete. 

It can be counter-productive, however, to attempt to conceal the real picture (or, as some might say, to put lipstick on a pig!) by tightening the security of your targets specifically for the pentest – the whole point after all is to test under near-real operating conditions. 

There are, however, a few basic checks that will give you a good head start: 

  • Patch your assets.
  • Delete forgotten or unused assets.
  • Check that passwords are sufficiently complex and change any default passwords.
  • Restrict access to admin interfaces on a “need to know” basis.


Coming next:

In this article, we have looked at what a pentest is, when is the right time to run one, how to target pentesting to increase its benefit and how to prepare ahead of discussions with your pentest service provider. 

In our next article, we will explore the different types of pentests together with their pros and cons, the seven key steps of a pentest accordingly to the PTES methodology, and what you should expect from the final pentest deliverables.



About the author, Pavel Chvets


With a range of experience in demanding, critical sectors such as industrial production and banking, including projects in foreign countries, I am now utilising my full skillset in IT security, project management and governance to address cybersecurity challenges within AUSY and to develop this as a service we offer to our customers.





Don’t hesitate to check out web page on cybersecurity and software testing.

Let’s discuss your projects together.