What is the best environment for a pentest?

What is an environment?

In software development, an environment is a collection of components and parameters that surround and influence how a program or application runs. This generally includes the operating system, software libraries, environment variables, configuration files and other resources that may be required for a program to function properly.

Production environments are the real-time systems that provide a service to users and customers. They host critical applications, databases and services that are essential to the organisation’s operations. In addition to production environments, there are several other environments that are typically used for different phases of an application’s life cycle.

One example is the Development (or Dev) environment. This is the main environment where developers create and modify the application’s source code. It is often installed on the developers’ computers and includes the necessary development tools, such as code editors, compilers and debuggers.

Another important environment in the development cycle is the Test or QA (Quality Assurance) environment. This environment is used to test the application and check it is working as intended before it is released to production. Testers carry out functionality, performance and security tests in this environment. There are several other environments that the organisation will use where they are needed. They are essential for guaranteeing the quality, stability and security of software applications.

Production environment: the realm of reality

There are several reasons why a production environment might be the best choice for a pentest. Pentesting in a production environment provides a more accurate picture of an organisation’s actual security posture. This helps pinpoint vulnerabilities that cyberattackers can exploit and ensures that the tests reflect the organisation’s true level of risk.

Furthermore, production environments typically handle sensitive data, such as customer, financial or intellectual property data. The potential consequences of a security breach are higher, so the organisation must prioritise protecting these assets.

Organisations are also often subject to regulatory requirements to demonstrate the security and resilience of their production environments. Penetration tests in a production environment can help flag vulnerabilities that could lead to non-compliance. And a production environment will usually be more stable than another environment. By contrast, when testing in a Dev environment, services are often interrupted, making test conditions more challenging.

A frequent concern among companies is the potential repercussions of carrying out a pentest in a production environment. Although pentesting can involve risks, these are mitigated by the tester’s professional and ethical approach, and by working closely with the teams responsible for the system being tested. The tester’s goal is to support the company in the most effective way possible, to minimise any disruption to production activities.

Non-production environment: the controlled playground

If the company feels that the risks of running a pentest in production are too great, it may be wise to use a non-production environment (ideally pre-production).

Non-production environments offer greater flexibility to carry out in-depth security tests without impacting on users and customers. Penesters can carry out more intrusive tests, such as those that exploit vulnerabilities or simulate more aggressive attacks, without the same constraints as in a production environment. They can also save time by using automated testing tools.

Non-production environments are also ideal for iterative testing and continuous improvement. Organisations can perform pentests, apply corrective measures and retest, removing the immediate pressure of impacting on production and making the security testing process more iterative and efficient.

Production environments also use live data, and companies may wish to avoid any risk of exposing that data (to maintain compliance with the GDPR, for example). In addition, pentesters may have to create datasets to ensure that their testing does not change production data. They will then have to delete these data sets after testing is complete. Testing in non-production environments avoids these constraints.

Another advantage of testing in a non-production environment is that you can test without security devices such as firewalls. This means that more in-depth testing can be carried out to check, for example, what happens if a security tool fails, and whether vulnerabilities that would normally be protected by that tool become exploitable. A pentester can detect these vulnerabilities, which can then be corrected. It is also quite common to test both scenarios: one with active security controls (WAF, for example) and another without.

Choosing the best environment for a pentest

Ultimately, whether you choose to perform a pentest in a production or non-production environment depends on your organisation’s specific objectives, risks and constraints.

You need to strike a balance between the need for realistic assessments in a production environment and the potential impact on and sensitivity of the systems. Non-production environments give you a more secure and flexible testing environment, while production environments provide a more accurate representation of the real risks.

The ideal scenario would be to have a specific environment available for pentesting that mirrors the production environment as closely as possible. So to get the best of both worlds, you should create a dedicated pentest environment that is preferably a clone of the production environment, with realistic – but fictitious – data sets.

With this optimisation goal in mind, it’s also essential to put testers in contact with your staff so they can discuss technical aspects as necessary. The aim here is to share information on how certain functions or tools work. This approach means you can carry out realistic testing while minimising the risks to production.