If you thought “Security by Obscurity”, “Security by Isolation”, and “Security by Default” were the only models crashing the cybersecurity party… think again.
Turns out, the “Security by” (first uncovered in Part 1 of this series) family tree has a few more colorful cousins, the kind that only show up late to the party, wearing niche distro hoodies and carrying encrypted USB drives. They may not be household names like SaaS or PaaS (and they certainly don’t rhyme), but trust me, they bring their own brand of weird… and sometimes wonderful security vibes.
These models don’t always follow industry buzzwords. They aren’t trending on Hacker News. But behind the scenes, they’ve helped protect sensitive systems, dodge mass attacks, and keep threats guessing. They’re the oddballs, the security underdogs but don’t mistake them for weak links.
So, grab your cyber-coffee, log out of root, update your threat model… and let’s meet the next batch of “Security by” models.
Security by Design
“Build it right the first time, or spend a lifetime patching it.”
Security by Design is the grown-up in the group, the one who plans their retirement while you’re still figuring out how to install Docker.
This model is all about baking security into the system from the first line of code. It’s not a feature. It’s the foundation.
Real-world examples:
- Threat modeling during application architecture.
- Secure coding principles (OWASP Top 10 fans, rise up).
- Enforcing role-based access from the get-go.
My 2 cents:
This model is beautiful in theory and powerful in practice, if you can afford the upfront discipline and cost. Otherwise, you’re backfilling security like trying to install airbags after the crash.
Security by Diversity
“Don’t put all your exploits in one OS.”
This model thrives on difference. Instead of standardizing every environment like a cookie-cutter DevOps shop, it intentionally mixes things up to avoid systemic risk.
Real-world examples:
- Mixing Linux, BSD, Windows across your infra.
- Using multiple antivirus or firewall engines.
- Diversity in coding languages (Python for one app, Go for another).
My 2 cents:
It’s like not using the same password everywhere at scale. It complicates attack automation, but yes, your sysadmins might lose a few hairs juggling documentation and configs.
Security by Minority
“Fly under the radar by not being interesting enough to hack.”
Sometimes, not being popular is your best defense. This model suggests that less common platforms or tools are less likely to be targeted by mass automated attacks.
Real-world examples:
- Running obscure Linux distros or self-built apps.
- Choosing a CMS that’s not WordPress.
- Custom ports, exotic file structures.
My 2 cents:
Security by Minority can give you some “security through irrelevance,” but don’t assume obscurity equals invincibility. One zero-day in your rare app and you’ll be wishing you had mainstream patches.
Security by Redundancy
“One is none, two is one, three is sleep-at-night.”
Not all security models are about blocking threats, some are about bouncing back. Redundancy is your safety net when all else fails.
Real-world examples:
- Backup DNS servers.
- Offline backups (bless the air-gapped USB drive).
- Redundant VPNs or authentication methods.
My 2 cents:
This model’s less sexy but incredibly effective. It’s the equivalent of walking into battle wearing armor and carrying a spare, just in case the armor’s made in… you know where.
Bonus Round: “Security by Legal Compliance” (Teaser for Part 3?)
“If you can’t make it secure, at least make it compliant.”
Ever heard of someone passing a security audit because the box was ticked… but the system was still Swiss cheese? Yup, we’ll save that mess for the next post.
Wrapping It Up: Choose Your Fighters Wisely
Each “Security by” model has its place and its pitfalls. You wouldn’t rely only on Diversity, or only on Redundancy. Like good lasagna, it’s all about the layers.
Use them to complement, not substitute, real security practices.
Blend them. Question them. Contextualize them. And above all, don’t trust anything blindly.
The goal isn’t just safety. It’s resilience.
In a nutshell…!
If you’re still reading, congrats; you’ve just met the rest of the “Security by” crew.
What’s next?
I’m thinking a Part 3 where we go into Security by Compliance, Security by Deception (Honeypots, anyone?), and maybe Security by Anonymity. Let’s see how far this rabbit hole goes.
Interesting read