A pattern repeats itself in IT departments of every size. Someone — a sysadmin, a manager, a newly minted security lead — imagines a threat. They picture an attacker doing something specific. They invent a control to stop that specific imagined thing. They roll the control out to every machine in the company. And then they call it security.
It is not security. It is fan fiction with administrative privileges, and it is making your environment worse.
The fix is not more imagination. The fix is to stop writing your own threat model from scratch when a hundred better ones already exist, peer-reviewed, free to download, and updated quarterly. Use the benchmarks. Use the controls. Stop guessing.
The shape of the problem
You have probably seen this play out, possibly from inside it. The story always rhymes:
- A user gets phished. The response is a blanket ban on a category of websites that had nothing to do with the phish.
- An executive reads an article about USB drops in parking lots. Every USB port in the building gets epoxied shut, including the ones on the conference room displays.
- Someone in finance forwards a chain email about “hackers.” The next week, password complexity rules require sixteen characters, four character classes, and ninety-day rotation, and the help desk drowns in resets.
- A vendor pitches a product. The product becomes the policy. The policy becomes the architecture. Nobody can explain what threat it actually mitigates.
The common shape is a leap from a vivid scenario directly to a control, with no checkpoint in the middle to ask whether the scenario is the actual risk, whether the control addresses it, and whether the cost to the user is proportional to the benefit. This is not threat modeling. It is anxiety expressed as Group Policy.
The cost falls on the user, who now cannot do something they used to do, for reasons IT cannot articulate beyond “security.” The user concludes IT is hostile or incompetent. The user routes around the control — personal email, personal device, personal cloud account, shadow IT — and now the actual security posture is worse than it was before anyone tried to “improve” it.
Why this happens
Inventing security feels like work. It feels like the kind of decisive action that justifies a job title. Reading a 400-page CIS Benchmark, scoring your environment against it, and slowly working through the gaps does not feel as satisfying as standing up in a meeting and announcing a new restriction.
There is also the trap of feeling you should know. Senior people, in particular, can be reluctant to admit that securing a Windows 11 fleet or an Ubuntu 24.04 server is a vast and specialized problem with hundreds of distinct decisions, and that nobody is supposed to be working those decisions out from first principles in their head. The benchmarks exist precisely because no individual is expected to.
And there is the dynamic of being the only security-aware person in the room. When everyone else is asking what you think, “I’m going to look up what the consensus standard recommends” can feel like a less impressive answer than a confident, off-the-cuff opinion. It is, however, the right answer.
What benchmarks actually are
A benchmark is a settled, version-controlled, consensus document that says, in concrete terms: for this operating system, in this version, here are the configurations that the security community has agreed are the baseline. Each setting is justified, mapped to the threats it addresses, and frequently mapped to higher-level frameworks (NIST CSF, PCI DSS, HIPAA, ISO 27001) so a single configuration choice can satisfy multiple compliance regimes simultaneously.
The two that matter most for general use:
CIS Benchmarks are produced by the Center for Internet Security. There are over 100 of them across more than 25 product families: Windows Server and client editions, every major Linux distribution, macOS, the big three cloud providers, Kubernetes, common databases, browsers, and more. They are free to download as PDFs for non-commercial use directly from cisecurity.org. Each benchmark is split into two profile levels — Level 1 is what most enterprises should start with, Level 2 adds higher-friction controls for environments that need them.
DISA STIGs (Security Technical Implementation Guides) are produced by the Defense Information Systems Agency for U.S. Department of Defense systems. They are more prescriptive than CIS, often more aggressive, and required if you are operating in or alongside DoD environments. For everyone else, STIGs are a useful reference point — if STIG and CIS disagree on a control, the disagreement itself is informative.
Above the per-system benchmarks sit the CIS Critical Security Controls (currently v8.1) — eighteen high-level control areas with 153 specific safeguards, organized into three Implementation Groups. IG1 is the foundational 56 safeguards, what CIS calls “essential cyber hygiene.” IG2 adds 74 more for organizations with sensitive data or regulatory obligations. IG3 covers the remaining 23 for environments facing sophisticated, targeted attackers. Most small and mid-size organizations should be working toward IG1 first, in full, before reaching for anything more exotic.
If you are a U.S. state, local, tribal, or territorial government — including school districts and public utilities — there is also the Multi-State Information Sharing and Analysis Center (MS-ISAC), operated by CIS. MS-ISAC provides threat intelligence, an Albert network monitoring service, incident response, and access to the same benchmarks and tooling under a single umbrella. As of October 1, 2025, MS-ISAC moved to a paid membership model after federal CISA funding ended, so it is no longer the free resource it once was; pricing is scaled to the size of the entity, and many states have purchased statewide memberships that extend to the local governments and school districts within their borders. If you qualify, it is worth the line item.
Why the benchmark beats your invention
Three reasons, each of them sufficient on its own.
The benchmark has been argued over. Every CIS Benchmark setting has been through a public consensus process involving practitioners, vendors, and security researchers. When a setting is in there, it is in there because dozens of people who do this for a living agreed it should be. Your invented control has been argued over by you, in the shower.
The benchmark explains itself. Every safeguard comes with a rationale, an audit procedure, a remediation procedure, and a description of the impact. When a user complains about a restriction, you can hand them a PDF that explains what the restriction does, what threat it addresses, and what the consensus standard says about it. You cannot do that with a control you invented.
The benchmark composes. The CIS Controls are mapped to NIST 800-53, NIST CSF, ISO 27001, PCI DSS, HIPAA, and several others. If you implement IG1 honestly, you have already done a meaningful chunk of the work for any compliance audit you might face later. Your invented control does not map to anything, because it does not exist anywhere outside your environment.
The user-relations dividend
The reason this is not just a security argument but an organizational one: users do not actually mind security. Users mind being told no for reasons that don’t make sense. The two are different problems with different solutions.
When IT says “we’ve disabled SMBv1 because it’s the global baseline for Windows hardening, here’s the document,” the user shrugs and moves on. When IT says “we’ve disabled SMBv1 because Mike thought it was a good idea after reading a blog post,” the user does not shrug. The user remembers, the user resents, and the user starts running a personal Dropbox.
Pointing to an external, authoritative source converts the conversation from “IT is being weird at me again” to “here is what every comparable organization is also doing.” That is a fundamentally different posture, and it is one that benchmarks make available to you for the cost of downloading a PDF.
What to actually do
Pick a system you actually run. Download the relevant CIS Benchmark from cisecurity.org. Read the executive summary and skim the full document.
Now compare your environment, honestly. Do not start with the controls you have invented; start with the gaps between your environment and Level 1. There will be more than you expect. Fix those first. They are settled questions, they are well-documented, and they will buy you more security per hour of effort than anything you could come up with on your own.
Once Level 1 is done, look at the CIS Controls v8.1 IG1 list. Audit your organization against those 56 safeguards. Most of what is missing will not be a tooling problem — it will be a process problem (asset inventory, account management, log review) and the benchmarks will tell you what good looks like.
Then, and only then, consider whether any of your homegrown controls are still doing useful work. Most of them, by this point, will have been quietly absorbed by the benchmark, made redundant by it, or revealed to have been addressing a problem that nobody actually has.
If you are a U.S. SLTT government, evaluate MS-ISAC membership. The threat intelligence and incident response are valuable on their own, and the membership pulls a lot of the framework alignment work into a single relationship.
The harder, quieter version of the job
Doing it this way is less dramatic. There is no announcement, no banner, no chance to be the person who figured out how to stop a specific imagined attack at a specific imagined moment. There is just a slow, plodding alignment of your environment to a published consensus standard, with the occasional satisfying realization that something you were worried about is already in the document, already addressed, already a settled question.
That is the job. The cairn is already built. You are not the first person to walk this path, and the people who walked it before you left a stack of rocks at every confusing fork. Stop trying to find your own way through. Read the document. Implement the safeguards. Spend the time you save on the parts of your environment that are genuinely unusual — because those parts exist, and they deserve actual thought, and you will not have any thought left to give them if you have spent it all reinventing controls that the rest of the industry settled in 2003.
The next person debugging your environment at 2am should not have to wonder why a setting is the way it is. The benchmark will tell them.
Footnotes and references
- CIS Benchmarks — the master list, free PDF downloads for non-commercial use.
- CIS Critical Security Controls v8.1 and Implementation Groups — start with IG1.
- CIS Controls Self-Assessment Tool (CSAT) — score your environment against the Controls without spinning up your own spreadsheet.
- MS-ISAC Membership FAQ — eligibility, current paid pricing, and what’s included.
- DISA STIGs — for DoD-aligned environments, or as a stricter reference baseline.
- Microsoft Azure Operational Compliance Considerations — Microsoft’s own framing of how compliance baselines map onto cloud landing zones, useful if your fleet is Azure-heavy.