Software ships to be easy to install, not hard to attack. Default accounts stay enabled. Services nobody asked for listen on every interface. Logging is off because logging costs disk. Attackers know the defaults for every major platform, and checking for them is cheaper than writing an exploit.
CIS configuration is the practice of aligning system settings to the security benchmarks published by the Center for Internet Security. This article covers what CIS configuration means in practice and how CIS Benchmarks and CIS Controls fit together. It also covers what the L1, L2 and STIG levels are for, and how to implement and verify all of it without breaking production.
What Is CIS Configuration?
CIS configuration means implementing system settings that conform to CIS Benchmarks, the consensus-driven security guidance developed and maintained by the Center for Internet Security. Consensus is doing real work in that sentence. Each benchmark is built by practitioners, vendors, and government contributors who argue over individual settings until they agree on one.
In practice, aligning to CIS standards is unglamorous. You disable default accounts that shipped enabled. You remove services nobody uses. You enforce access controls, require encryption in transit, and turn on audit logging. Then you verify each of those settings against a documented standard. A setting you believe is correct and a setting you have checked are two different things.
CIS Benchmarks vs. CIS Controls: Understanding the Difference
Readers mix these up constantly, and the distinction is worth two minutes. CIS Controls tell you what your organization should do. CIS Benchmarks tell you how to do it on a specific technology.
Control 4 says you need a secure configuration process for your enterprise assets. The CIS Benchmark for Ubuntu tells you which line in sshd_config to change. One is policy, the other is a work order. Teams that adopt the Controls alone end up with documented intent and unhardened servers.
What CIS Control 4 Covers
Control 4, Secure Configuration of Enterprise Assets and Software, is the control that owns this problem. It calls for a continuous process covering endpoints, servers, cloud resources, mobile devices, and the software running on all of them. Continuous is the operative word. Secure configuration is not a state you reach, it is a state you maintain.
The control carries 12 safeguards, which group into a few themes:
- Baseline process: establish and maintain secure configuration processes for enterprise assets and for network infrastructure.
- Session and device control: automatic session locking, and lockout on portable end-user devices.
- Firewall management: firewalls on servers and on end-user devices, not only at the perimeter.
- Reducing what runs: uninstall or disable unnecessary services, and manage default accounts.
- Trusted infrastructure and mobile: trusted DNS servers, remote wipe, and separated enterprise workspaces on mobile devices.
Not every safeguard applies to every organization. CIS sorts them into three implementation groups: IG1 for basic cyber hygiene, IG2 for organizations with more risk and more resources, and IG3 for the most advanced. Each group includes the ones below it. A ten-person MSP and a regional bank should not be working from the same list.
What CIS Benchmarks Add to the Picture
A benchmark is where Control 4’s intent becomes a line you can copy. The CIS Benchmark for Ubuntu tells you to set PermitRootLogin no, cap MaxAuthTries, and disable X11Forwarding on servers that have no use for it. The CIS Benchmark for Windows Server names the Group Policy settings that enforce the account lockout threshold and the machine inactivity limit.
Every recommendation ships with a rationale, an audit procedure, and a remediation. That structure is what makes benchmarks useful in an argument. An engineer will ask why they should change a setting that currently works. “Here is the control, here is the rationale, here is the risk” beats “the scanner flagged it.” CIS secure configuration work lives at this layer, and this is the layer teams skip.
CIS Benchmark Levels Explained: L1, L2 and STIG
Most CIS Benchmarks ship with more than one profile, and choosing the wrong one is how hardening projects earn their bad reputation. The profile decides how aggressive the recommendations get.
Level 1: Essential Security for Every System
Level 1 is the floor. These recommendations go in quickly, carry minimal performance impact, and are designed to cut attack surface while keeping the machine usable. Nothing at this level should break a normal workload.
If you are starting from nothing, Level 1 across every system beats Level 2 on your three favorite servers. Breadth first.
Level 2: Stronger Controls for Sensitive Environments
Level 2 is defense in depth, built for environments where security outweighs convenience. It lines up well with what HIPAA, PCI DSS, and ISO 27001 expect of systems handling regulated data. It is the usual target for security-conscious organizations.
It also carries real operational risk. CIS states plainly that Level 2 recommendations can hurt an environment if applied without due care. Test them somewhere safe. For most teams the honest target is Level 2 on sensitive systems and Level 1 everywhere else.
STIG: The Federal and Defense Standard
The STIG profile covers Security Technical Implementation Guide requirements published by the US Department of Defense. It replaced what CIS used to call Level 3.
The profile carries the STIG-specific recommendations, with overlapping Level 1 and Level 2 items included where they apply. A system configured to a CIS STIG Benchmark satisfies both standards at once. If you are not selling into federal or defense environments, you almost certainly do not need this tier.
Which Systems and Platforms Do CIS Benchmarks Cover?
CIS publishes secure configuration guidance for more than 140 technologies, which is broader than most teams assume. If it runs in your environment, there is a fair chance a benchmark exists for it.
The main families:
- Operating systems: Windows Server, RHEL, Ubuntu, macOS, and the other major distributions.
- Cloud platforms: AWS, Azure, and GCP account baselines, which is what most cloud posture tools score you against.
- Network devices: routers, firewalls, and switches.
- Server software: databases, web servers, container platforms, and hypervisors.
- Desktop and mobile: browsers, office suites, iOS, and Android.
The benchmarks are free to download as PDFs. Coverage is the point here. CIS configuration standards are not a server-only concern. The browser on a developer’s laptop sits in the same threat model as the database that laptop can reach.
How CIS Configuration Supports Regulatory Compliance
Auditors recognize CIS. That one fact does more work than any technical argument in this article.
CIS maps its benchmarks and controls to the NIST Cybersecurity Framework, PCI DSS, HIPAA, and ISO 27001. Most of those frameworks state configuration requirements that land close to benchmark recommendations. A documented benchmark audit therefore does two jobs at once. It hardens the system, and it produces the evidence that you hardened it.
The benefit shows up in the room. “Our servers are configured securely” is an assertion. “Here is the benchmark, here is the audit output, here are the four controls we deviated from and why” is due diligence. Compliance findings often come down to missing documentation rather than missing security.
How to Implement CIS Configuration Across Your Infrastructure
Knowing the standard is not implementing it. The sequence below is the one that survives contact with an operations team.
Step 1: Identify Your Assets and Select the Right Benchmarks
Map your infrastructure to the benchmarks that actually apply. A Windows Server running Active Directory, an Ubuntu web server, and an AWS account each need a different benchmark. The AWS benchmark will tell you nothing about the EC2 instances running inside the account.
Start with the systems that are internet-facing and business-critical. If your public web server and your internal wiki both need work, the web server goes first.
Step 2: Establish a Documented Security Baseline
Record the current state of each system before you change anything. That record is your security baseline, and it does three jobs. It gives drift something to be measured against. It gives auditors a starting point. It tells you what to restore when a change breaks something at 2am.
Skipping this is the most common mistake in the whole process. Without a baseline, your first audit is a snapshot, and so is every audit after it.
Step 3: Apply Secure Settings Before Systems Go to Production
Harden before deployment, not after. Applying CIS baseline configuration to a system already carrying production traffic turns every setting into a change ticket with a rollback plan attached.
Build the hardened state into your golden image or your provisioning code. A server that arrives hardened costs nothing to harden. The same server hardened eighteen months into its life costs a maintenance window and a nervous evening.
Step 4: Audit Each System Against the Benchmark
Run a hardening audit against the benchmark and record each control as compliant, non-compliant, or not applicable. Not applicable is not a loophole. It is the honest answer for controls that do not fit the system in front of you.
Then prioritize, and not by count. Two questions set the order. Is this a setting that should be on by default almost everywhere, or one where a real business reason might justify the deviation? And how exposed is the asset it sits on? A deviation needing justification on an internet-facing database outranks a default-everywhere setting on a lab box.
Step 5: Monitor for Configuration Drift
Configuration drift is what happens between audits. A package upgrade rewrites a config file. An engineer opens a port to debug something and never closes it. A new admin creates an account with more privilege than the job needs.
Re-audit on a schedule and after every significant change: migrations, upgrades, new deployments. The interval matters less than the trigger. A quarterly audit that also fires on every change beats a monthly audit that ignores them.
Common Pitfalls When Applying CIS Configuration Standards
Failed CIS programs tend to fail the same handful of ways.
- Over-hardening. Applying every available control regardless of the environment’s actual risk breaks functionality and burns your credibility with operations. Benchmarks are designed to be tailored. The team that disabled a service the billing system needed does not get invited back.
- Treating configuration as a one-time task. A system hardened once and never revisited drifts quietly for a year. System hardening is a maintained state, not a milestone.
- Applying one benchmark to every asset. Controls that make sense on a domain controller are noise on a container host. Review applicability before you review compliance.
- Failing to document deviations. When a team keeps a setting for a business reason, that decision needs a written justification and a named owner. Six months later, an undocumented exception is indistinguishable from an oversight, including to you.
- Treating non-compliant as a paperwork problem. A misconfigured service is not a checkbox failure, it is an entry point.
autoindex onin an Nginx block is a benchmark deviation and a public listing of your backups, depending on who finds it first. Send non-compliant results into the same queue as the vulnerabilities from your CVE Watch, with owners and deadlines attached.
From CIS Configuration Standards to an Automated Audit With Panopsys
Knowing the standards is half the work. The other half is verifying your systems against them without disrupting production, installing agents, or handing your operations team a script nobody can read.
The Panopsys Hardening module audits Linux, Apache, Nginx, MySQL, and PostgreSQL against established hardening baselines. Every gap comes back sorted rather than piled:
- Baseline: Security best practices that should be applied by default in the vast majority of cases.
- Contextual: Misconfiguration for which legitimate business or operational justifications may exist.
Each gap is tied to the asset it was found on and prioritized by asset criticality, that is, by that asset’s real risk. That is the difference between a report and a work queue. Sign up for launch news on Hardening Audits
