Do I Need to Use a Dev Environment for a Penetration Test?

Organizations have varying levels of concern when it comes to a penetration test. Many of them have been through this process many times before, have had a multitude of different tests performed, and are not concerned in the slightest that testing will cause any sort of disruption. On the other side of the spectrum, some clients may be having a penetration test performed for the first time and have no idea what to expect, having only the “worst-case scenario” horror stories they’ve read online to go off. Whatever the case may be, we’ve talked through ways to avoid potential problems with penetration tests in some of other blogs, such as how to prevent problems during a penetration test and what can go wrong during an internal penetration test. One of those ways that we talk about a lot is using a development or cloned environment for some types of testing, so let’s talk through in a little more detail when it may or may not make sense to use a dev environment for a penetration test.

Cases Where You Should Consider a Dev Environment for a Penetration Test

So let’s start with when using a dev or cloned environment might make sense and help to reduce some of the risk associated with penetration testing in a production environment. The most common case where we recommend this approach is when we’re performing web application penetration testing. In this type of assessment, we’re performing application-level testing from both an unauthenticated and authenticated perspective. While our engineers performing these assessments have a lot of experience in this realm and are adept at avoiding areas of potential concern, to perform a full test we’ve got to submit forms, generate application input, and use the target application fully. This is potentially going to submit some erroneous data to back-end databases, trigger internal processes, or generate automated emails from the system.

So to avoid the clean-up or headache associated with some of these issues while still performing a thorough test, we prefer to test in a cloned or development environment that mirrors production as closely as possible. By doing this, we avoid any business disruptions or clean-up activities for the client organization. And as a bonus, we can test as thoroughly and efficiently as possible, uncovering all vulnerabilities without being hindered by restrictive rules of engagement or concern for application load.

In addition to web applications, there are certain scenarios where a cloned or development environment might be necessary for other types of testing, as well. Sometimes if a system or set of systems is extremely critical to the business or very fragile but the customer still needs to assess the associated risks, we’ll perform a portion of testing on a dev environment. This way, we can lower the level of risk associated with testing while still uncovering significant vulnerabilities that the organization should still address.

When Does a Dev Environment Not Make Sense?

The main idea behind using a dev environment for a penetration test is to lower the associated risk of the testing being performed while still finding vulnerabilities on the systems. The key point here is that the dev environment has to be as close to production as possible to ensure the testing is valid and useful (and that things in production aren’t missed). But for a lot of types of penetration testing, the risk of any kind of business disruptions are already extremely low. We perform assessments with great care, with the goal that you don’t even know we’re there (unless of course you’re monitoring SIEM alerts like you should be). Over 95% of assessments don’t have any negative effects whatsoever on the target organization, and the ones that do experience issues are usually because of a significant misconfiguration or security vulnerability.

Additionally, you don’t want to use a dev environment for most network-level assessments because it’s almost impossible to guarantee an identical configuration between assets in different testing environments. The chance of missing potential misconfigurations in production are too high and the risk of disruption is too low to justify using a separate environment for testing. Particular for an external penetration test, these assets are already exposed to the Internet so they should be pretty resilient or you’d already be seeing issues with them!

So you shouldn’t be overly concerned about an external penetration test, internal penetration test, wireless penetration test, etc. causing network-level disruptions. If you want to make sure you’re actively addressing the potential for business disruptions, consider the following steps:

• Talk to your penetration testing team during the Project Kickoff meeting when you’re going over the rules of engagement. Mention any particular concerns or critical areas of your network.
• Note any business critical systems, legacy systems, or fragile systems (i.e. mainframes, SCADA) during Project Kickoff. Your penetration test team ALWAYS wants to know about these systems to avoid hitting them with certain types of scans.
• In certain cases, off-hours testing may be necessary for those critical systems. Or a cloned/dev environment could be used for testing certain systems. Discuss these items with your testing team to arrive at a mutual beneficial solution.
• Monitor your network throughout a testing engagement. Communicate with your test team regarding any alerts or unusual activity on the network during that time. Not only will this help you identify a real attack in the future, but it could help uncover availability-related concerns during testing.