What is the bare minimum an organization must get right in order to achieve “good cybersecurity”, expressed as clearly and concisely as possible?
I have not yet found a satisfactory answer to this question. There are many existing frameworks for judging cyber maturity, but the ones I know about appear to be primarily intended for auditing an organization. They often contain dozens or hundreds of individual items, while also sometimes using broad or vague terminology in an attempt to be comprehensive across many different scenarios. This preference for completeness over clarity makes them somewhat overwhelming to read in one sitting, and difficult to all keep in your head.
In contrast, what I’m looking for is a mental model: something simple and concise enough that I can remember it and intuitively understand it.
So I went ahead and made my own. I’m sure there are mistakes, but it has already proven useful to me: I’ve used it to more intuitively assess my own organization’s strengths and weaknesses, and as a framework for understanding how new security products or controls fit into the bigger picture.
Existing Frameworks
First let me briefly explain why the existing frameworks I know about fall short of my hopes for a mental model.
NIST 800–53 is a standard targeted toward US federal agencies, but adopted by many private sector organizations in the hope of better understanding their security postures. I am fairly certain it contains over 1000 individual practices or “controls” organizations should follow, broken up across 20 categories. (I had difficulty finding a concrete total, and I did not want to count them all myself).
Furthermore, I have found the individual controls to be occasionally difficult to understand. For example, here is an excerpt from the first control in the document:
Needless to say, NIST 800–53 does not seem well suited for a mental model.
Other frameworks are perhaps less overwhelming, but still complex:
- ISO 27001 contains 114 controls
- CMMC contains 110 practices
- C2M2 contains >350 practices
- CIS Critical Security Controls — to me this is the clearest of the lot; there are only 18 high-level categories, and only 60 lower-level controls (out of 150) are necessary to achieve “minimum cyber hygiene”.
…To be sure, cybersecurity is complicated. There are certainly a lot of things you need to get right. But amidst the complexity, is there also room for a simpler list of responsibilities for achieving “good security”?
Or to put it another way: what is the smallest number of items an organization must avoid really screwing up? Ideally every item on this list should be so critical that, if an organization were to fail completely to achieve even one of these items, it would not be unreasonable for it to experience a devastating cyberattack.
OK, so here’s what I came up with. I decided to phrase each item as a yes/no question — and my hope is that each question is specific and achievable enough that an organization could reasonably answer “yes” (or at least “mostly yes”) to it. I ended up with 33 questions, broken up into 15 categories.
Minimum Questions for Achieving Good Security
- Asset Management
- Do you know what devices and software your organization uses?
- Do you harden systems before you deploy them?
- Do you perform security review on new systems and meaningful system changes?
2. Network Access
- Do you know how your devices are connected?
- Are systems with different levels of trust separated into distinct networks, with minimal connections between them?
- Are those border connections restricted to only allow required use cases?
3. Physical Access
- Are critical systems only physically accessible to those who need access?
4. Authentication
- Do you make it difficult to guess passwords?
- Do you require MFA for key actions?
- Are credentials stored in a hardened and restricted location?
5. Privileges
- Do you limit privileges to only those needed to perform assigned duties?
- Do high privilege accounts receive additional scrutiny?
- Do you promptly remove access when no longer needed?
6. Patching
- Do systems regularly receive security updates?
7. Vulnerability Management
- Do you know which vulnerabilities affect your systems?
- Do you proactively escalate fixes based on risk?
8. Security Monitoring
- Do you have security monitoring tools running on your endpoints or on key network chokepoints?
- Do you send relevant logs to a central system?
- Do you have a security team that investigates alerts and anomalous behavior?
9. Incident Response
- Do you have a plan for what to do if you are compromised?
- Do you have people with the technical knowledge and organizational authority to investigate and respond to a compromise?
- Do you have mechanisms to block malicious artifacts and contain compromised systems?
10. Disaster Recovery
- Do you have plans for how you would recover from critical business outages?
- Do you keep regular backups of important systems?
- Are your backups stored separately from the systems they belong to?
11. User Behavior
- Do your users know to identify and report suspicious behavior?
- Are users discouraged from running unapproved software?
- Are users discouraged from connecting unapproved devices?
12. Data Security
- Do you have protections in place for particularly sensitive data?
13. Situational Awareness
- Do you stay informed on changes in the threat landscape that would likely affect you?
14. Assessments
- Do you validate your security through assessments?
15. Scenario-Driven Risk
- Have you identified your worst case cyber scenarios?
- Are you specifically prioritizing defenses that mitigate those particular scenarios?
That’s it! Still complicated; but hopefully small enough to sort of keep in your head.
How I Use the Model
Now let me walk you through some of the scenarios where I’ve found this mental model useful so far:
- Informally evaluating an organization’s security
- Understanding how a new security product fits into the landscape of known security products
- Understanding the layout of a new security team
When trying to understand, say, my own organization’s strengths and weaknesses, I’m not going to break out a 300-point checklist and go interrogate each team member; it’s much easier and more natural to use a mental model.
I’ll pick a question from the list above (let’s use “Do you make it difficult to guess passwords?”) and list all the individual defenses I can think of which apply to this question:
Password length and complexity requirements
Password rotation requirements
Password manager with built-in random password generator
Policy that users should only use unique passwords
Brute force prevention mechanisms (limiting login attempts, account lockout periods)
Password hash salting
Single Sign On (SSO)
Local Administrator Password Solution (LAPS)
Group Managed Service Accounts (GMSA)
Passwordless authentication (passkeys, certificates, etc)
Not revealing valid usernames on web forms
The examples I thought up range from organizational policies, to broad technical solutions, to OS-specific technical implementations.
Crucially, I do not think every organization needs to implement each of these controls. What I really care about is just whether they do enough, within their own unique risk landscape, to answer yes to that higher level question, “Do you make it difficult to guess passwords?”.
If I were auditing an organization, I certainly might push them for details on all of the specific controls they implement. But when informally or mentally evaluating an organization, I find it easier to look for evidence of just a few of these controls, compare that with my rough understanding of the risk landscape, and then move on to the next question.
Just for fun, here is another example: for the question “Are users discouraged from connecting unapproved devices?”, here are the controls I can think of so far:
Policies on allowed use of removable media and removable devices
MAC address filtering
Network access control
Host-based restrictions on connecting unapproved media
Malware scanning workflow for new media and devices
Physical port blockers on switches and endpoints
Smaller organizations with less risk exposure could address this question by simply creating a policy and communicating it clearly to employees, while larger organizations would likely want to implement some of these technical restrictions as well (or others I have not yet thought of).
I’ve also used this mental model to better understand a new security product. The framework can help me cut through the marketing buzz to see a product more clearly:
“OK, so this expensive new EDR looks like it will help me address 5 of these 33 points: asset inventory, vulnerability discovery, endpoint visibility, containment, removable media control.
That’s better than our current security monitoring tool, which has crappy vulnerability discovery, and doesn’t prevent unapproved removable media.
However, the new tool only runs on Windows and Linux endpoints — so we still need a separate way to track and get visibility into our mobile and network devices.”
Scenario-Driven Risk
I also want to point out the final category in my mental model, Scenario-Driven Risk. This is a recent addition to my understanding of good security practices (thanks to my old CEO Rob Lee at Dragos!), and now I feel it is one of the most important categories on the list.
The specifics for this category might change considerably for each organization. For example, a software company might identify as a worst-case scenario a targeted compromise of its build environment, which could then be used by an adversary to push malicious software to customers. Therefore, the software company should focus above all else on preventing unauthorized access to the build environment, and on detecting unauthorized additions to the production codebase.
This means issues that might be only a moderate concern on most devices (insufficient logging, local accounts with excessive privileges) suddenly become critical if they affect devices leading to the software build environment. The organization’s entire security strategy should to some extent revolve around preventing this and other worst-case scenarios. This is a reality that I’m not confident many existing security frameworks effectively capture.
Wrapping Up
I wrote this list to outline the requirements for “good security” — but I might argue it also does a decent job at outlining the requirements for “great security”. To put this another way: I think I can actually sort most of the security controls I’ve ever heard about into these existing categories.
Sure, there are definitely some categories that aren’t really addressed above: like methodically addressing supply chain risk, or managing an insider threat program.
But I would argue that many mature controls, including many fancy security buzzwords — zero trust access, application allowlisting, DMZs, air gaps, HSMs, PAM, XDR, RBAC, PAWs, threat intel feeds, threat hunting — already fall into the questions outlined above. Implementing the fancier controls just helps you answer “yes” to these existing questions more decisively.
Do you have any feedback on the list above? Anything you think should be added: a question that, should an organization fail to answer “yes”, would by itself seriously undermine their security? Anything that could be removed or simplified?
Or is there a different mental model that you yourself already use?
