How to Secure a Non-Production Environment (Webinar Recap)

"The code is fine, right?" 

"It should be..."

"Wait... but what about this configuration?"

"Fine, I'll test it in dev..."

This conversation sounds all too familiar, right? Your non-production environments are the foundation for the tools, applications, and services you provide to your customers. The history of every code deployment, mistake, and refinement made to create your product can be found there.

While test and dev environments serve a different purpose from production environments, they too, can be open to the outside world and introduce risk if not secured. Chances are, the data you're storing, analyzing, or processing in non-production environments are just as sensitive as the data you push out to production. So why skimp on security here just because it's not a production environment?

Recently, we hosted a brief webinar (led by our Chris Gervais, VP of Engineering) focusing on the importance of securing non-production environments and how to do so.

Security is about mitigating risk. If you don't have the same level of security hygiene in your test and dev environments compared to production, then you are introducing risk. Especially if your non-production environments accept outside connections, you need to be sure you're monitoring those. If you can implement the same security policies you use in production in your non-production systems and infrastructure, you can reduce risk - and make things easier on yourself.

Managing different levels of security in each environment can be time-consuming, so by streamlining security across the board, you can eliminate unnecessary insecurities and inefficiencies.

Ready to lock down your test and dev systems and infrastructure? Here's a step-by-step guide:

1. Replicate

As long as you're implementing the right security measures in production (here's a guide if you're not sure), they can easily be replicated to your dev and test. Especially if you have automated security using a tool, you should be able to easily template out infrastructure security across any environment. If you have security groups setup in production, for example, you can easily replicate those same groups in test and dev. And if you're using identity access management (IAM) and encryption in production, why not use them in non-production, too?

Especially if you regularly tear down and spin up new non-production environments, automating and replicating security measures is the easiest way to maintain good security hygiene no matter how fast you're running. This ensures that every environment is consistent and that policies and user behaviors are consistent as well. This can also go a long way towards reducing human error, with fewer changes to be made and more unification across the board.

By removing as many variabilities between environments as possible, you can reduce risk and increase security.

2. Control Access

Next, you want users to access test and dev environments the same way they would in production. If you're using a VPN and/or two-factor authentication in production, for example, it should be used in dev and test as well. And creating the same security groups across environments can also help you control access and find issues quicker.

Many companies don't do it this way (here's the data) because they feel their non-production environments are less risky. But the more variability between environments, the more risk actually increases.

3. Understand Your Workloads

Dev and test environments aren't just a good place to review code changes. They're also a good place to understand the behavior of workloads. If your workloads begin to talk to something new, for example, use this opportunity to profile those communications and identify potential leaks or vulnerabilities.

As the pace of development cycles continues to increase, it's becoming even more important to understand whether any components of your workloads are making connections to the outside world that could be malicious. For example, if you start testing a new ruby gem and it begins calling out to a server that you don't know about, how would you spot this without having security embedded in the process?

4. Improve Your Tests

Hardening your environments can begin as early on as in dev or test mode - in fact, this is preferable. If you can test for different security scenarios early on, you can be much more prepared when it comes time to push to production. For example, you can run tests for known access credentials to see whether they are returning the same level of access as they do in production, which can help you solidify a least privilege access policy (a best practice we recommend). Using a test environment to do this is safer and more proactive.

Do Your Test and Dev Environments Mirror Production?

Your cloud infrastructure is only as strong as its weakest link. Testing environments are notoriously the weakest link - and hackers know that. By locking down and mirroring security best practices like VPN, IAM, and monitoring pre-production, you can catch issues early on, solidify your security protocols, and save yourself a lot of unnecessary work along the way.

Do your environments look like this?

Production Environment

Testing/Dev Environment

Or This . . . .

Testing/Dev Environment

Part of being a responsible security organization is to look at security as a whole, and that includes environments that are "behind the scenes." You can use tools to not only look across production but test and dev as well to make sure your security is equalized across the board.