There’s a theme going around that you should create secure products, not buy security products. And, as far as it goes, this is…
Well, actually it’s not good.
My initial response was “Why not both?” We need to secure the products we develop. There’s no doubt about that. And we need to mitigate mistakes. How do we do this? Spoiler… security products :-)
In response to this I got a message “If you have secure products, you do not need security products. And what you do not need, you definitely should not run!”
And at that point this rant was generated.
Rant
See, how do you know your product is secure? ‘Cos as sure as the sun will rise tomorrow (even if I might not see it ‘cos of the awful weather…) a developer will make a mistake; a core library will have a bug (hi, OpenSSL!), a service will be misconfigured, a subsystem will be left unsecured.
Is your code provably correct? Really?! Does it depend on any external libraries? Are those libraries secure? Will they remain secure? How many new CVEs are generated against code we consume as part of our development processes, and that may make our own code bad? We may write the most perfect code ever, but a vulnerability in a dependency can ruin it all.
And we all have dependencies in our code bases. For example, we sure don’t want developers creating their own encryption systems; that’s hard enough to get right for seasoned cryptographers (see, for example, some of the failings of the newer post-quantum algorithms; see, for example, how older algorithms are deprecated as attacks are discovered). But we even have more basic dependencies; how many maven libraries is your code bringing in? How much stuff has been cloned from github?
And the inescapable truth is that developers are human (and “AI” assistants are sub-human). Humans make mistakes.
So what do we need?
Obviously we need to help our developers create better code. We want to improve the skills of our developers and make their code better. So let’s alert them to mistakes they might be making. A plugin in their IDE? Some static code analysis? Hooks into the devops process to block bad code from being promoted? Even some training modules focused on discovered weaknesses? They’re all security products.
What about those dependencies? We need to track what modules a developer is using and ensure they have no known vulnerabilities or (better) that any known vulns aren’t in the execution path and so not impacted. So now we need tools that can do dependency analysis, compare what’s being used to what’s good, and preferably block bad modules from the build.
Oh, that module which was good last month… it has a new CVSS 10 vuln; do we know where that’s been deployed so we can target remediation? More tools.
What about identity and access management? What about new classes of attack (e.g. API issues)? What about…?
Security tools can even provide mitigation against lower level attacks, such as a DoS. Or provide protection for third-party tools. Do you put your ILOMs and DRACs and every other out-of-band interface on the internet? Or do you limit them - eg via subnet routing, firewalls, etc. Require a VPN with MFA to reach them… look, more security tools!
Reality
The reality is that we strive for perfect code. We all want to do the right thing. But we all can fail. The larger the product, the more developers, the increase in complexity… the greater the risk. And modern microservice architectures are complex.
Even the mythical 10x developer makes a mistake every now and then.
So we create standard architectures to try and limit the risk. We use security tools to provide “belts and braces”, to provide depth, to mitigate mistakes that will happen.
Sure, don’t run what you don’t need. But you do need the right security tools. You have limited resources, so pick wisely!