11 generalist mental models applied to cyber: CISOs’ and founders’ guide
A set of generalist frameworks (mental models, principles, or whatever you want to call them) that 100% apply to cyber.
Cyber is absolutely unique, but the laws of physics very much apply to it. The way all this plays out in real life is kind of fascinating. On one hand, security is unique in that, first and foremost, it is a horizontal, not a vertical, meaning security touches all industries, tech stacks, market segments, categories of customers, and you name it. Cyber is unique because there is a motivated adversary who is always learning, adapting, and trying to overcome whatever obstacles we put in front of them to achieve their goals.
On the other hand, the very same laws and principles that apply to other industries and areas of life more broadly do apply to security. It’s easy to forget, but that is just a fact. In this piece, I am talking about 11 frameworks (mental models, principles, or whatever you want to call them) that 100% apply to cyber.
This issue is brought to you by... Panther.
Chatbots close alerts. Agents with native access to detections close the loop.
Most AI SOC tools speed up alert triage but stop after closing the alert. This webinar digs into what happens to that judgment: does it feed back into your detection logic, or does it just evaporate? Jack Naglieri (Panther CEO), Spencer McGalliard (AVP of Cyber Defense & Engineering at HealthEquity), and Francis Odum (Software Analyst Cyber Research founder) come at this from three angles: the platform building the closed loop, the security team living inside it, and the analyst tracking where the industry is headed. Together, they make the case that triage without feedback is still toil, and walk through what it actually looks like when investigation outcomes feed back into detection logic, shrink alert volume, and pull teams out of perpetual firefighting.
Generalist mental models applied to cyber: CISOs’ and founders’ guide
Sturgeon’s Law
Sturgeon’s law states, “Ninety percent of everything is crap”. This law, created by the American science fiction author and critic Theodore Sturgeon, very much applies to cybersecurity.
Think about it this way: most alerts, findings, threat intel, vulnerabilities, and even security products provide limited value. I often see that people get frustrated and take it to social media to say that security products are garbage, but it’s not only that security products are garbage; it’s also most of everything. Most conference talks are just repeating the same basic “knowledge” that everyone has read 1,000 times. Most books are not worth reading, as are most newsletters (although I surely hope that somehow my newsletter is different, following the same Sturgeon’s law even 90% of my blog is also crap). This is just the fact of life.
Pareto Principle
The vast majority of people know this as the “80/20 rule”, which says that 80% of outcomes come from 20% of causes. This rule most definitely holds well in cyber.
There are over 5,000 security vendors and probably more than 100 categories, but still only a handful of controls drive the majority of security outcomes. Any company that invests in asset inventory, MFA, EDR, firewalls, patching, backups, access management, and 1-2 more controls specific to the business, will get to like 90% coverage.
In security, it’s really common to see organizations spend disproportionate effort on edge cases and issues that are extremely unlikely to happen to them, while underinvesting in the basics. I just recently talked about this in my other pieces, Cybersecurity is really boring, and What works against Mythos today is what worked against ransomware 5 years ago, and malware 10-15 years ago.
The Law of Diminishing Returns
This one is pretty self-explanatory, and it kind of extends the Pareto Principle, but I think this is the one that founders struggle with the most. All CISOs are very familiar with this, I just feel like many are hesitant to just tell founders how it is.
The first, most fundamental security investments produce enormous value, but as time goes by, additional controls produce progressively smaller gains. Think this way: going from no MFA to MFA and from no EDR to EDR is transformative. But, after you have implemented an EDR, an MFA, a network firewall, an identity and access management platform, a SIEM, and a few other fundamental controls, any new additions will (maybe) improve your security by a fraction of a percent. Once again, that doesn’t make these new additions useless; it just means that they don’t come with the same ROI as foundational controls.
Goodhart’s Law
Goodhart’s Law says, “When a measure becomes a target, it ceases to be a good measure.” Once you understand what this means, you can never unsee this.
Take compliance frameworks as an example. In theory, they are designed to make sure that companies have some baseline to work against. The creators of these frameworks look at the threat landscape, try to figure out what controls are effective and which, at least according to Sturgeon’s Law, are crap, and then put forward a set of ideas. What do companies do? Exactly. In 9 out of 10 cases, the “measure becomes a target”, and so instead of thinking about how to level up their security posture, companies are just doing the minimum to check the boxes.
To be clear, compliance is just the most obvious (and I must admit, kind of a lazy) example. Teams optimize for vulnerabilities closed, alerts investigated, tickets resolved, and so on because those metrics are measured, even if doing these things doesn’t always mean a meaningful improvement in security.
Chesterton’s Fence
Just because an old rule, policy, or design seems useless or outdated doesn’t mean it is. The people who created it may have had insights or dealt with problems we simply don’t know about. Chesterton’s Fence is the principle that you should never remove or change an existing rule (or I guess configuration?) until you first understand exactly why it was put there in the first place.
In security, we see this all the time. Every security engineer has encountered a config, exception, or policy that looks useless until it breaks production when someone removes it. Today with AI, we finally have a way to correlate that context and serve it right at the time when people are making decisions, but it’s not magic, and if no context whatsoever exists, then even AI may not be able to help. A lot of (or most of?) security debt exists for forgotten reasons, which makes it critical to understand the context before making changes.
Conway’s Law
Conway’s Law says that organizations design systems that mirror their communication structures.
I think this is one of the biggest challenges in security. Security is naturally a cross-functional problem, but ownership is often spread across many different teams (way too many, I have to say). The security team is responsible for managing risk, but identity changes are handled by someone in IT, cloud controls are owned by the infrastructure team, and backup and recovery sit somewhere else entirely, to share a few examples.
Over time, org boundaries evolve into technical boundaries. Different teams use different tools, follow different processes, and have different priorities, even though they may all be making changes to the same infra. All this leads to fragmented controls, fragmented visibility, and fragmented ownership, and when nobody has a complete view of the environment, security suffers.
The Principle of Least Effort
Remember how I said that cybersecurity founders are generally pretty bad at understanding the law of diminishing returns, and the fact that “this awesome widget they built” doesn’t make as much difference as they think it would? Well, security professionals on their part tend to struggle with a different concept - the principle of least effort.
Very basically, humans, animals, and even machines will naturally choose the path of least resistance (a path that requires the least work). I often hear security engineers say that “people should behave more securely”, but really, people are just that - people. People will always re-use passwords if they don’t have a very easy to use password manager that pre-fills all of their passwords for them, people will always bypass an approval process if it’s too cumbersome, etc. If security controls are annoying, users will bypass them, but if they’re frictionless, adoption increases dramatically. Good security design works with human nature rather than against it, which really means that for people to consistently choose a secure way of getting their job done, the secure way has to also be the easiest way.
Occam’s Razor
Occam’s Razor says that when there could be multiple explanations of an event, the one that’s correct is usually the simplest one.
Security teams violate this principle all the time. A strange login? Must be an advanced persistent threat. A server doing something weird? Probably a sophisticated attacker. In reality, many incidents turn out to be a misconfigured system, a forgotten test account, a broken script, or a user doing something unexpected. The same applies to security architecture. We often build complex stacks of overlapping controls, workflows, and exceptions when a simpler design would be easier to secure and operate. Complexity creates risk, and in most cases, the simplest explanation and the simplest solution are the right ones.
Hanlon’s Razor
Hanlon’s Razor states: “Never attribute to malice that which is adequately explained by stupidity.”
Cybersecurity is built around thinking like an attacker, which is important, but sometimes it pushes people to assume malicious intent way too quickly. Many security incidents are not caused by advanced adversaries, they are caused by employees clicking the wrong button, developers making mistakes, administrators misconfiguring systems, or teams misunderstanding requirements. I would also argue that while security engineers like to say that “developers don’t care about security”, in reality, software is vulnerable not just because people are reckless, but because it is hard to build and maintain at scale. Security teams that understand this tend to focus less on blaming people and more on improving processes, building guardrails, and designing secure paths.
Most of the time, the biggest threats have nothing to do with malisious intent, and have everything to do with human error. One problem area where this is especially the case is data loss prevention (DLP) and insider threat. In 99% of cases, when an alert suggests that someone is exfiltrating data, it’s just a person trying to do their job (and sometimes stupidity, too).
The Lindy Effect
The Lindy Effect is the idea that the longer something has existed, the longer it is likely to continue existing. This can be counterintuitive for the industry where we have gotten used to coming up with “next-gen” ideas every two years, but when you think about it, it actually makes a lot of sense.
Even though every year we come up with new acronyms, new categories, and new promises to revolutionize the industry, when you look at what consistently works, it is usually the same concepts that have been around for decades. Security is boring, and as I’ve recently explained, what stops breaches and allows companies to be resilient are still things like least privilege, network segmentation, asset inventory, strong authentication and MFA, endpoint security, backups, and defense in depth. The fact that these ideas have survived for so long doesn’t mean that they are outdated, it just means that they work. The longer a security practice has been relevant, the more seriously we should take it.
The Jevons Paradox
The Jevons Paradox says that when something becomes more efficient and cheaper to use, people don’t use less of it, they use more. This is one of the most important ideas for understanding the impact AI will have on cybersecurity. Many people assume that if AI automation makes security work more efficient, security teams will have less work to do and so we’ll need to hire less people. In reality, that’s not at all what’s going to happen.
We have seen this movie before:
Storage became cheaper, so companies stored more data.
Compute became cheaper, so companies ran more workloads.
Cloud infrastructure became easier to provision, so organizations built larger and more complex environments.
In each of these cases, efficiency did not reduce consumption, it increased it.
If AI helps security analysts process twice as many alerts, companies won’t suddenly decide to process only half as many. Instead, they will collect even more logs, enable even more detections, and investigate even more signals. If AI makes vulnerability analysis easier, teams won’t stop scanning. They’ll scan even more systems, look for even more issues, and analyze even more findings…
The point is that AI will help security teams keep up, but it will also create even more systems, identities, applications, policies, and configurations that need to be protected. And as security teams can do more, they’ll be expected to do even more.
Closing thoughts
Once you understand these principles, you start seeing them everywhere. You see Sturgeon’s Law in security products and conference talks. You see the Pareto Principle in the few controls that actually make companies secure. You see Goodhart’s Law in compliance programs, Conway’s Law in how responsibilities for security are divided, and the Principle of Least Effort in almost every user interaction with security…
None of these frameworks will tell you exactly what to do, but they can help you think more clearly about why things happen the way they do. And, in a field where everyone is constantly looking for the next breakthrough, sometimes understanding a few timeless principles can be more valuable than learning the latest trend.
As I like to say, in security or otherwise, trends are temporary. Stick to fundamentals.
