You write code to solve problems. The problems are unique, or you wouldn’t be writing custom code. This naturally leads you to build rules and business logic that help keep that custom code safe, but the line between business logic and security gets very blurry very fast.
There are a LOT of problems with embedding security in your custom code, including:
- Time to deployment
- Time to debug
- Time for enhancements
- Time to remedy
Time to Deployment
All too often, security testing happens in the last stages of development. You’ve written your code locally, tested it, moved it into an integration platform, and then we get to pre-production staging and testing, and hmm…A performance issue, an unexpected exploit, or a security problem simply breaks your application — or worse, you missed compliance rules that legal requires before signing off on the release.
The bits and bytes in your code and the way they interact with the bits and bytes in your colleagues’ code are all baked in. Now, you have to go back to test on your local stack, re-commit your code, and test again, often costing an entire sprint or more for something you didn’t expect (and honestly would rather not be working on).
If your code is separate from your security plane, it’s easy to have business stakeholders help with the testing before you get to a release. If your code is separate from the security, it’s easy to configure a change rather than code a change. And if it’s simply a business review and a configuration tweak, you can save hundreds of hours from reworking a frustrating oversight.
Time to Debug
We’ve all seen the statistics: breaches often go unnoticed. When found, they take a long time to fix. Most companies aim to find breaches within 100 days — that’s more than three months, and even then, a lot of the exploits go longer before they get fixed.
The non-technical folks in Congress are perplexed by this. Why does it take so long to figure out what’s gone wrong? Why does it take even longer to fix the problem? Because, you know, code. Hand-rolled, code-specific security solutions are piecemeal — that is, there are few ways to figure out which part of the ecosystem is failing. There’s no chain of evidence log, and there are so many things to check that just checking all the potential breaches gets overwhelming.
Now let’s add to the fact that if your code IS your security and your code is compromised, the bad actor can hide the trail. Like Invasion of the Body Snatchers or real-life espionage where you don’t know who to trust, your bad actor pretends to be your darling code, all the while infecting and spreading through your ecosystem, making it harder to root out the problem.
Separating your code from your security is imperative for understanding what’s going on. Security needs to be both a monitor and a cop — we need an independent system that not only reports on what’s talking to what, but also halts the chatter when needed. Plus, we need it today, not in 100 days after dollars have been lost or the company fails.
Time for Enhancements
The business side of the company will keep asking for new enhancements to security – new kinds of MFA enforcement, better tracking, record-level consent access, and more. Business needs and legal compliance may suddenly drive needs we hadn’t even thought of.
Baking security into your code makes this hard. Looking at our ecosystem, we remember some of our code is in Java, some is in Ruby, and oh yeah, there’s that .NET stack we’re not supposed to touch but need to add data record consent to.
Let’s be honest — no one likes security tasks. They end up at the bottom of the list and stay there. There are lots of reasons to put them off, so the enhancements either take a long time when you finally get around to them or they become so critical, you must bring in an offshore team, spending too much money addressing what shouldn’t have been a problem in the first place.
Using a configurable security plane means you don’t have to touch the .NET stack you’re supposed to keep out of. It means you only put the enhancements in once — you don’t need a Java, Ruby, and .NET developer, or a whole offshore team. Time to Market becomes Time to Configure.
Time to Remedy
The preceding time sinks – development, deployment, debugging, and enhancing – all end up in “How long will it take to fix it?” The bottom line of the entire code-versus-platform option boils down to a few issues that are big when custom code is involved and reasonable when configuring a security plane:
Business oversight: Security locked away in code is “black box” and doesn’t allow non-technical stakeholders to review early enough in the process.
Stealth breaches: Code that’s been compromised is worse than code that’s not secure: it becomes difficult to find the secret agent in your ecosystem.
Mixed language support: No ecosystem is a monoculture. Being able to add security to old and new architectures, despite a mix of languages, is critical to managing your data environments.
If you don’t address these areas, it will continue to take time, money, and possibly failure before you can address the basics of security, let alone the enhancements you need as new laws, new tech, and new breaches emerge.