I started my career back in the days when we hosted servers in the basement of the office. At the time, we never really thought much about security until we deployed the code (which pretty much meant FTPing a bunch of files to a server). Security was handled at the router first, blocking malicious traffic from getting in the door. Then, we locked down the firewall on the server itself. (No, you can’t telnet from outside the building.)
Skip forward 15 to 20 years. We like to think in the days of solid development cycles and continuous integration/continuous deployment, we have this whole security thing nailed. But to be honest, we, as an industry, still pretty much treat security as the thing you do in production. We treat our dev boxes an awfully lot like my team treated servers back in the day — it’s okay, it’s inside the firewall.
Only it’s not okay.
There is no inside or outside anymore. I’m not just talking on-prem vs. cloud — developers use libraries that are part of the whole CI/CD process. A client recently had to deal with an intrusion because one of their developers chose to include a library from a git repo that ended up getting compromised. Then Docker grabbed a fresh, compromised copy and deployed it to the data center. Even if it’s bad practice, it’s the sort of thing that happens with CI/CD and scaling on the fly.
Then there’s the fact that Chrome extensions can be compromised, and then your laptop – inside the firewall, or maybe even behaving as the firewall – is compromised. Malicious attacks look for the easy way in, and your code should never be easy.
And you can say, “But it’s just dev, it’s not like they’re getting access to production data!” To which I say, “How often do you refresh your dev environment with prod data for testing? If not dev, definitely QA.” The real intellectual property and personal private data may very well be available to your compromised dev environment.
Zero Trust starts way back in the pipeline. You don’t trust anything. Not your code, not your tools, not your firewall, not anything. Which means you have to protect your code from itself and all of its friends.
First, get your microservice architecture in shape. Monoliths that act as Swiss army knives have too many tools and too much access. Think of it this way: a CRM database is composed of separate services: organizations, people, products, licenses, invoices…if you have that all in one big system, you have a LOT to lose if someone gets in there.
But, if you break those into separate services, and wrap those services in a security mesh before you even deploy, it’s a lot harder for a backdoor to be unlocked. Not only that, but your smoke tests and your formal QA are now testing the security as well as the functionality of your code. Because your security is part of the functionality, not a bolt-on at the edge.