To deliver technology products and services, companies use multiple technology environments so that changes, updates, and testing can be completed in a controlled way without interrupting customer experience. This is a best practice approach that maintains high levels of system stability, uptime and security. These “non-production”, or test environments should ideally be completely disconnected from production environments to prevent security incidents and bugs. In fact typically, a company's test environments are only known about internally and not at all revealed to the public. However, in our security research, we often find exposed credentials to test environments, which can lead to far more serious consequences.
How Test Credentials Can Be Misused
Despite not being associated with production environments, test credentials should be protected as if they did. There are several ways non-production environments can overlap with production, provide a gateway into production systems, or simply be the source of a major breach. Attackers utilize stepping stones to gain greater access to systems within an organization, either via technology or social engineering. Each foothold provides more information and more access to valuable data and resources.
A simple scenario that illustrates the risks: an attacker uses leaked test credentials to access your test environment. They find a trove of production data that has been loaded into the test environment to help with debugging a complex issue, as your support team determined that the issue could not be easily replicated with faked data. This data includes customer information, and the exposure leads to a massive data breach that hurts your company’s reputation and results in a regulatory fine.
Ways To Securely Manage Risk From Test Credentials
Breaches like this occur all the time. However, you can take steps to reduce your risk, and also decrease the impact in case your company is breached in this way.
Test environments should always use different credentials from production, so that even if leaked, test credentials simply cannot be used to access production.
Test credentials should follow the principle of least privilege, so attackers could only use test credentials to have limited access to your test environment and nothing else.
Enable multi-factor authentication (MFA) in test environments, to create another line of defense to hold back an attacker from accessing your systems.
Avoid using real (production) data in your test environments, and sanitize it if you must. It can be challenging to simulate real-world conditions in test environments, especially when debugging complex issues that depend on large datasets to replicate. For this reason, production data is sometimes loaded into test environments. Production data can be sanitized before being important into test environments.
Better yet, use or develop tools to generate fake data for your test environments.
Implement technical controls, such as network segmentation. Even though an environment may be for testing or development, it still reveals a great deal about how digital business is done for an organization. This system information is invaluable to attackers, as it can help to pinpoint vulnerabilities and assists in social engineering attempts by making the attackers better informed. Although this control is not strictly related to test credentials, robust network security is a must for preventing and containing this type of breach.
Vendor Risk from Poorly Secured Test Credentials
In addition to managing the risks posed by your own people and technology, you should also consider your third-party vendors and their approach to managing test environments. Your vendors could expose your company to the risks highlighted in this article in a number of ways:
- By exposing test credentials to their systems.
- By exposing test credentials to your systems.
- By exposing test credentials to their vendors systems. This is fourth-party risk.
You should ask your third-party vendors to implement strong controls, and verify that they do using security questionnaires. You should also monitor your vendors in case of a degradation in their security posture, or a breach. Otherwise your risk is as good as their risk.
Test credentials are just one type of data breach we often see caused by companies and their third-party vendors.
This article is one of a 6-part deep-dive series on different types of data breaches that we've seen from third-party vendors. Click here to read more in this series.
