Why are you spending a lot of money on cybersecurity and still getting hacked? Because you’re spending too much money on the wrong thing. And what is that wrong thing? Defect discovery.
Too Much Money on the Wrong Thing
Whether you’re developing your own application, buying an off-the-shelf application (or SaaS) or integrating two pieces of software, you do need to do some defect discovery. There is definitely a time and place for code reviews, static analysis, pen testing, vulnerability scanning, composition analysis, container security, etc. The problem arises when that’s all or most of what you do to ensure security.
There are a few challenges inherent with defect discovery. First, you’re not likely to find 100% of the defects, which means you’re still vulnerable. Second, defect discovery tools tend to be very noisy and produce a lot of findings. And third, most defect discovery tools don’t help much with prioritization.
At first, it might seem like a good idea to know about all one thousand defects in your cloud configuration file, until you realize you don’t have the resources to address them all and you don’t know which ones to address first.
But perhaps the biggest challenge to over reliance on defect discovery is that it only helps you detect problems. It doesn’t do anything to help you avoid them.
Problem Avoidance vs Problem Discovery
As a way of analogy, consider the challenge of constructing a wooden fence around your property. Once it’s complete, just like with software, you’ll have to continually perform defect discovery. Is the wood rotting anywhere? Is the paint peeling anywhere? Have any insects made a home there?
If, on the other hand, you prioritized problem avoidance rather than problem detection, even before you build the fence, you’ll ask yourself, how do I avoid all those previously mentioned problems? And the answer would come back, build a plastic fence.
The truth is, a lot of problems surfaced during defect discovery can be eliminated altogether by making better decisions in the design phase. And making decisions in the design phase to avoid cyber threats has a very particular name: threat modeling.
The best way to avoid a lot of cyber threats, so you don’t have to discover so many, is to augment your defect discovery toolbox with a threat modeling tool.
Threat Modeling and Problem Avoidance
Threat modeling is the ultimate “shift left” technique because you invoke it when you’re planning to change your architecture. Compare that to defect discovery which occurs during or after you’ve changed your architecture.
Not only that, but threat modeling occurs where most developers have experience (i.e., during architecture design), rather than where they’re less likely to have experience (i.e., security analysis). It’s not that developers don’t want secure code, they do, but they tend to have a bunch of competing priorities and the one that’s least clear tends to be security.
The bottom line is you can spend your time looking for all the lines of code that have cross site scripting vulnerabilities or SQL injection vulnerabilities, but you’ll miss the opportunity to make design choices that eliminate the need to even worry about those.
If you really want to minimize your chances of getting hacked, you’ll augment your defect discovery tools with a threat modeling tool. And if you’re not sure which threat modeling tool to choose, how about your consider ThreatModeler.
ThreatModeler is a threat modeling platform which dramatically simplifies threat modeling. It’s as close to one-click threat modeling as the industry has to offer. If you’d like to learn more about ThreatModeler, we’d be happy to answer any questions you have right here.