Test servers: information security pitfalls

[Father]

When working with information systems and software development, testing on test servers is an integral part of the process. Test servers are designed to conduct experiments, test new features and updates without the risk of damage or disruption to the main system.

However, due to the specifics of their purpose, test servers also carry certain information security risks. This article will analyze the main cybersecurity risks associated with the operation of test servers, as well as possible ways to protect them.

What's the problem anyway?​

Most developers do not consider test servers to be part of the company's infrastructure, so it is not terrible if these servers "fall", are compromised or attacked, because this will not affect the performance of the "main" infrastructure in any way. On the other hand, the company's information security department very rarely provides a high level of security for test servers-since they have a lower priority relative to the main infrastructure of the company, which is "covered" by security tools, technical and organizational.

At the same time, various sensitive data is often used for testing and debugging – from configuration elements of the main infrastructure, to personal data of customers or employees.

As a result, there is a situation when developers use sensitive data in conditions of minimal control (or its complete absence), and the information security department does not have the technical ability (and resources) to ensure the security of this process. With this approach, an incident is a matter of time, not probability.

Known incidents involving test servers​

Since the test server is almost always less secure than the main infrastructure of the company, they often become targets for intruders. First of all, because during a cyber attack on a test server, you can find an "entry point" to the main infrastructure, or real company data. In addition, hacking the test infrastructure can always be presented as a successful attack on the entire company's infrastructure. Here are some notable examples:

1. In 2016, Uber faced a major security breach related to their test server. Attackers were able to gain access to Uber's GitHub repository, where archived files with the app's code were stored. As a result of this incident, the attackers gained access to confidential data, including users 'personal information and drivers' data.
2. In 2019, Sberbank reported a security breach related to their test server. As a result of the leak, the bank's customers ' personal data was compromised.
3. In 2013, Facebook faced a data leak due to an insecure configuration and configuration of the test server. Attackers were able to gain access to a test server containing various development and testing tools. As a result of this incident, the personal data of more than 6 million users was compromised.
4. In 2020, the social network VKontakte, popular in Russia, faced a security breach due to an error in setting up a test server. Because of this incident, some users may have accessed other users ' private messages and other sensitive information.
5. In 2018, British Airways experienced a security breach that affected their test server. Attackers were able to intercept data, including personal and financial information of more than 380,000 customers, by injecting malicious code into the company's test server.

From the case studies, we can conclude that the problem with test servers is relevant for companies from a wide variety of industries. And it is not always necessary for the implementation of an incident that there is a hacker or an attacker.

Problem points and protection methods​

As a rule, test servers are configured "to please the IT department", with all the classic problems, starting with weak passwords and ending with the lack of access control. This approach, of course, provides a high level of comfort for developers, but negatively affects the level of information security.

Igor Landyrev
Head of Security Analysis, Awillix

A practical example: the customer's company made an application on Bitrix with a personal account. During the security analysis of this application, its test service was detected. Hacking it was much easier to sell, since it was not under WAF and everyone forgot about it. The test service was easily hacked, we got access to the database and admin passwords, and then reused them on the prod.

Conclusion – when migrating from a test to prod, you need to be not lazy and change passwords, as well as cover with protection, including test segments of services, if they are available from the Internet.

Standard problems related to the security of test servers include::

1. Sensitive data. Many companies neglect to work on masking the data that is used in testing. Also, there are common cases when passwords from the test infrastructure in prod remain unchanged.
2. Protection level. Regular servers have a higher level of protection and are used for processing and storing important data. They are usually equipped with special protection mechanisms, such as firewalls, intrusion detection systems, and intrusion prevention systems. Unlike" working " servers, test servers often do not have the same powerful security mechanisms. They are configured for simplified operation and testing, and often belong to a separate network infrastructure with a lower level of protection.
3. Access control. In the case of test servers, cases where all users have the same high level of rights are common. At the same time, developer passwords can be either simple or duplicate passwords from the main infrastructure.
4. Vulnerabilities and errors. Test servers are often used to test new features and updates, and may often contain earlier versions.

If we talk about ways to protect test servers, the main one is not to use sensitive data in a "clean" form. Data masking is certainly quite resource-intensive, but it can significantly reduce the criticality of a possible leak.

Grigory Revenko
Director of the R-Vision Expertise Center

The key recommendations for protecting test servers are:

• compliance with access rights control (prohibited, everything that is not allowed, and not vice versa). This applies to both network traffic (brandmap) and users;
• event monitoring (logs);
• regular software updates, as well as timely detection and elimination of vulnerabilities;
• use of "classic" password policies designed to ensure sufficient complexity, password length, and frequency of password changes;
• host protection (for example, endpoint protection using EDR tools).

No less important is the organizational element of ensuring information security – the presence of clear and structured regulations allows, at minimal cost and provided that these regulations are observed, to seriously strengthen the security of the test infrastructure.

Results​

Ensuring the security of test servers is an integral part of the entire development and testing process. Working with test servers presents certain risks that may have negative consequences for the company and its users. However, by applying appropriate security measures, these risks can be significantly reduced.

Isolating test servers in a separate network, using strong authentication and authorization mechanisms, regularly updating and configuring servers, restricting access to test data, and regularly checking for vulnerabilities are all important steps to ensure the security of test servers.

Keep in mind that security should be a priority at all stages of development and testing. With strong security measures and best practices in place, you can minimize the risks associated with test servers and ensure data privacy and integrity. Regularly updating security policies and following the latest information security trends will help protect your company from possible threats and incidents related to test servers.