Security in Testing Environments

When it comes to creating applications, there is a need for multiple environments to support the development process. It typically starts on the developers own computer, then on to an integration environment, a QA testing environment, possibly a UAT (User Acceptance Testing) environment, and then finally production. Depending on your organization, you may have some, none, or all of these different environments.

When it comes to security, the focus is typically on the production environment. This is where the instances that all of the users use are on a daily basis. This has all the “real” data. It is where real credit card numbers or social security numbers may reside. There is a lot of effort put on securing the production environment.

What about the test environments?

If your testing environments are externally exposed, the security of those environments are just as important. Anything exposed externally is a target and needs to be considered. Just recently there was an article about a test database being exposed that resulted in leaked data. This is an opportunity for us to look at our own systems to understand what we are doing with our test environments.

Some things to think about within your test environments:

• What do we actually have exposed externally – Keep an inventory of the software, services and devices that are exposed. This includes any databases, web servers, ports, etc.
• Ensure the endpoints are properly locked down – Make sure that your systems are not left wide-open. Don’t leave default passwords in place, make sure they are changed to be unique. If you are running some form of database server, make sure it is not exposed and that it has authentication enabled on it.
• Check the validity of data – What type of data do you use in your test environment? Are you using a straight copy of production (shame on you)? What type of data scrubbing are you performing? Are you performing data scrubbing? What types of sensitive information may be stored in the environment.
• Who has access to the environment – Is the environment limited to specific IP addresses or clients? Is it open to anyone that has a valid username and password? Who should it be open to?
• Where are the servers – Consider where these servers are located. Are they in the same environment as the production servers? What about the corporate network?

These lower-level environments produce risk and should be tracked accordingly. Don’t discount them just because they are “test”.