Non-Prod Environments Must Have The Same Security Protections As Production
Your non-production environments must have the same security capabilities as your production environment.
This is probably another one of those posts that will annoy the development community.
My goal here is not to repeat everything that I’ve ever said about application security on this blog. So, please look at my various application security blog posts:
- Achieving Application Environment Isolation
- No, You Shouldn’t Use Production Data For Testing
- SOFTWARE SUPPLY CHAIN SECURITY: CI/CD/CT PIPELINES AND SECURITY TOOLS — PART 1
- SOFTWARE SUPPLY CHAIN SECURITY: CI/CD/CT PIPELINES AND SECURITY TOOLS — PART 2
- Prevent XSS and Other Common Attacks on Your App
- Authentication Series
- Authorization Series
- Static Credentials Must Not Be Used In The Browser
- Datastore Security Requirements
- Application Front-Ends Must Not Make Authorization Decisions
- Application Security Models
This is hardly an exhaustive study on the topic, but that just means there are still many topics for future blog posts.
Generally, no one is going to question the need for these security concepts to be applied in production environments. But, often, critical security capabilities are left out of non-prod environments out of concern for simplicity, cost, ease, etc. I often see this with WAFs, DDoS Prevention services, and IPS/IDS systems. It’s also common to skip TLS / HTTPS in the lower environments.
Don’t do this.
Each non-prod environment should have the same security capabilities that you have deployed to your production / live environment.
Why?
Because:
- You aren’t testing in a production-equivalent environment. What’s going to break when you get to production?
- What security capabilities are broken in production, but you never notice because there is no facility for regular testing / validation?
- Your automated test suite should contain tests for your security capabilities to the greatest extent possible — some edge cases, I admit, can get complicated here. If you are missing security capabilities in a test environment, it is hard to test that capability.
- If you ignore the prior advice about not using production data in lower environments and disable (or, otherwise, don’t bother deploying) security capabilities in those lower environments, you are setting yourself up for a data breach.
If you have automated the deployment / management of all your security capabilities, then there isn’t additional operational overhead. If you have manual tasks required to manage these security capabilities, now is a great time to introduce automation.
If you are doing this to save money, this is not the place to save a buck (euro, peso, whatever). In fact, there are typically architectural approaches that can allow for the security capabilities to be used across all environments and maintain environment isolation, while managing cost vs. complexity.
Each non-prod environment should have the same security capabilities that you have deployed to your production / live environment.
Notes
- Image generated with ChatGPT.
- AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
- I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now..
- Names have been changed to protect the guilty.
- None of the hostname or users used in examples actually exist.
- Feel free to post any comments or suggestions below.
Originally published on Medium.