Why You Should Secure Your Test Environments

Koby Meir

Why You Should Secure Your Test Environments

Koby Meir


Share on linkedin
Share on facebook
Share on twitter

While test environments are a vital part of the deployment process, when it comes to security they are not treated equally. The need to secure your production environment is a given but unfortunately, test environments often suffer from low to no security and in some cases are unnecessarily exposed to the web.

A typical deployment pipeline includes three non-production test environments each serving its own purpose.

Development: This is where the initial magic happens. It is the workspace in which developers can deploy and test code and make frequent changes per need.

QA (also referred to as Testing): In this test environment, testers focus on bug fixes and on ensuring that each component in the application is working properly.

Staging: This environment is used for the final stages of testing before the release to production. Out of all the test environments, staging typically mimics the production environment and oftentimes, real data is used in order to ensure the application is reliable and will not fail in production.

Such test environments may contain source code of future features that are not yet meant to be publicly available. In addition, they often include real production data and API keys. Such exposed test environments pose weak entry points into internal networks and can lead to data exposure and leaks.

In addition to potential leaks, since most test environments are not regularly monitored, attackers could “practice” their exploits on exposed staging environments until they are ready and able to take down your live application in one shot.

Every week, Reposify’s attack surface management platform discovers millions of exposed test environments including development, QA and staging environments which were left unprotected and can be easily accessed online and exploited by attackers.

Here Are The Most Common Types Test Environments Exposures:

1. Test environments with no login pages
This is by far the worst type of exposure we come across for test environments. In such cases the servers are completely open to the internet with guest or admin permissions by default. Anyone with an internet connection can access them. Attackers will be able to gain access to the system, view and steal sensitive data.

2. Misconfigured test environments with default login credentials
Oftentimes, developers want a quick and easy access to their workspaces and will leave the login pages with default credentials (User name: admin password: admin) in order to make their life easier. The problem is that it also makes the attackers’ lives very easy.

3. Test environments’ login pages with no MFA
When such login pages are left exposed to the internet instead of being placed behind a VPN they can be easily discovered by malicious actors and compromised via brute force attacks or credential stuffing.

4. Old test environments that were forgotten
In some cases, developers forget to teardown the test environment after testing was completed. In addition to incurring unnecessary charges, such shadow cloud environments can also accumulate vulnerabilities and pose a risk for the organization.

Why Does This Happen?

Agile Development:
Development teams tear down and spin up new test environments very frequently. In continuous integration environments this can happen on a daily basis. Fast development cycles, continuous integration and deployment all increase the chance of human errors and system misconfigurations. Mistakes are inevitable.

Ease of use:
Developers are focused on speedy deliveries and therefore, will look for simple ways to quickly access the servers from anywhere. This leads to creating shortcuts and bypassing security policies.  For example, QA testers often prefer to spin up a new environment rather than to clone an old one in order to ensure a clean baseline and reduce errors and inconsistencies that may be carried over. But, setting up security measures such as MFA from scratch for every new environment can become a headache which they prefer to avoid. For the same reason, developers tend to use weak passwords which are easy to remember. In other cases, passwords are used by automation bots and therefore are left weak on purpose.

Lack of visibility
In many cases, test environments are spun up on servers which are not regularly monitored by IT and security teams and therefore also no updated on time. This lack of visibility is a major barrier for discovering such non-compliant exposures and eliminating them before attackers can find and exploit them.

How To Secure Your Test Environments & Avoid Unnecessary Exposures:

There is always an inherent tension between the desired ease of use versus the need to secure your assets. Unsecured test environments are weak entry points which attackers are well aware of and can easily find.

Here are some practical tips that can help you boost your cyber hygiene and reduce the risk of data leaks.

1. Treat test environments equally and apply the same level of security hygiene and standards that you would use for your production environments.

2. Ensure that the type of servers used for your test environments will be similar to the type of servers used for production (e.g.PHP, Apache). This will make it easier to keep good cyber hygiene.

3. When setting remote access to your test environments ensure to allow access to the server only via a secure VPN.

4. Install MFA for the login pages of your test environments. MFA solutions which are based on email tokens can be a good option as they are relatively simple to set  up.

5. Avoid the use of real data in your test environments and use mock data instead. If not possible, anonymize the data so it won’t be recognizable in case of an exposure.

6. Setup SSO logins to your test environments in order to reduce risks

7. Consider isolating your test environments from the internal network by configuring them as silos (VPC or VLAN) in order to reduce the potential risk

8. Lastly, ensure IT and security teams have complete and ongoing visibility of all your company’s test environments so these servers can be monitored and patched on time.

Want to make sure you are aware of all your exposed environments?

Contact us today to get a complete and real time view of your attack surface.

New call-to-action
Koby Meir

Koby Meir is an expert software engineer with close to two decades of experience. Koby has a diverse and well-rounded background ranging from assembly to complex web applications written in Python. Prior to founding Reposify, Koby led various software development and devops teams at both mid-size and international corporations including Conduit, Ajilion and Elbit Systems. Koby is an alumnus of the IDF’s elite C4I Corps where he served for over four years as an embedded system developer and team leader.


Share on linkedin
Share on facebook
Share on twitter

Ready to discover your External Attack Surface?

Read Next

Why Only EASM can provide the protection necessary to guard against RCE threat

In April, VMware issued a series of patches to guard against vulnerabilities in a number of products. Among the most critical is CVE-2022-22954, a remote code execution RCE threat that puts organizations at risk of cyber attack. Only EASM can provide thorough cybersecurity protection against remote code execution hacks, with real-time asset monitoring and identification and clear, actionable insights for immediate intervention.

Detect to protect: Reposify’s EASM flags exposed assets vulnerable to Microsoft SMB (CVE-2022-26809)

Microsoft covered more than 100 vulnerabilities in April's security update, among them patches to critical remote code execution (RCE) vulnerabilities located in Microsoft’s SMB. In response Reposify's EASM platform scanned and identified 800,000+ nodes with open SMB protocol on both patched and unpatched systems. Read our latest blog and learn how Reposify's EASM can detect unknown exposed assets vulnerable to Microsoft’s SMB.

Security teams: here’s why you should choose EASM over Shodan?

If you are using Shodan to search for your company’s assets or perform reconnaissance as part of blue or red teams routines - you need to keep reading.