What is CIS Controls?

CIS describes the Controls as a prescriptive, prioritized and simplified set of best practices, made of Safeguards that each require you to do one thing. They started as the SANS Critical Security Controls, better known as the SANS Top 20, and SANS handed maintenance to CIS in 2015. Version 8, launched at RSA Conference on 18 May 2021, cut the list from 20 Controls to 18 and regrouped the Safeguards, because physical devices and fixed network boundaries matter less once workloads sit in the cloud and staff work from home.

Version 8.1 followed in June 2024 and is still the current release. It keeps the 18 Controls and the 153 Safeguards, adds a Governance security function to line up with the Govern function of NIST CSF 2.0, revises the asset classes and clarifies a few Safeguard descriptions that CIS itself called anemic. CIS says v8.1 is backwards compatible, so a program built on v8 carries over.

The 18, in CIS numbering

• (1) Inventory and Control of Enterprise Assets
• (2) Inventory and Control of Software Assets
• (3) Data Protection
• (4) Secure Configuration of Enterprise Assets and Software
• (5) Account Management
• (6) Access Control Management
• (7) Continuous Vulnerability Management
• (8) Audit Log Management
• (9) Email and Web Browser Protections
• (10) Malware Defenses
• (11) Data Recovery
• (12) Network Infrastructure Management
• (13) Network Monitoring and Defense
• (14) Security Awareness and Skills Training
• (15) Service Provider Management
• (16) Application Software Security
• (17) Incident Response Management
• (18) Penetration Testing

Inventory comes first because a laptop missing from the asset list is also missing from vulnerability scans, log collection and EDR coverage, so every later Control inherits the gap.

Implementation Groups decide the order of work

• IG1 is 56 Safeguards that CIS defines as essential cyber hygiene, the minimum every enterprise should apply against common, non-targeted attacks, sized for a team with limited security expertise.
• IG2 adds 74 Safeguards (130 in total) for enterprises with more operational complexity, some of which need enterprise-grade technology and specialist skills.
• IG3 adds the last 23 to reach all 153 and assumes staff who specialize in areas such as risk management and penetration testing.

The split is uneven across Controls. In the CIS Controls Navigator, Control 8 has 12 Safeguards with 3 in IG1, Control 10 has 7 with 3, Control 17 has 9 with 3, and Control 13, Network Monitoring and Defense, has 11 Safeguards and none in IG1. So an organization can meet every IG1 Safeguard with no network detection at all.

Control 8, Audit Log Management, is the Control a SOC works inside

CIS states its purpose as collecting, alerting on, reviewing and retaining audit logs that could help detect, understand or recover from an attack. The IG1 part is short: a documented log management process (8.1), logging enabled across enterprise assets (8.2) and enough storage at the logging destination (8.3). IG2 carries the detail:

• at least two synchronized time sources (8.4),
• detailed logs with event source, username, timestamp and addresses on assets holding sensitive data (8.5),
• DNS query logs (8.6),
• URL request logs (8.7),
• command-line logs from PowerShell, Bash and remote administration terminals (8.8),
• centralized collection, with a SIEM as CIS's own example (8.9),
• retention for at least 90 days (8.10)
• and log reviews weekly or more often (8.11).

IG3 adds service provider logs such as authentication, data creation and user management events (8.12).

On Windows, 8.8 maps onto two sources. Security event 4688 records each new process, but its Process Command Line field stays empty until the Group Policy setting Include command line in process creation events is turned on. PowerShell script block logging writes event 4104 with the script text. For 8.10, check retention if you run Microsoft Sentinel. Azure Monitor documents that tables in a Log Analytics workspace keep data for 30 days by default, apart from a set of tables with a 90-day default. A table nobody configured can sit 60 days short of the Safeguard.

The auditor asks for evidence

A simulated walk-through generated by SOCSimulator Research (the workspace, hosts and results are invented): an IG2 assessment samples Safeguards 8.2, 8.8 and 8.10 and asks the SOC to show each one in the data rather than in a policy document. The analyst answers with three Microsoft Sentinel queries. Table and column names follow Microsoft's Azure Monitor table reference; these queries have not been run against a live workspace by SOCSimulator.

For 8.2, hosts whose monitoring agent went quiet in the last month:

Heartbeat
| where TimeGenerated > ago(30d)
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where LastHeartbeat < ago(24h)

For 8.8, hosts that log process creation without the command line:

SecurityEvent
| where TimeGenerated > ago(7d) and EventID == 4688
| summarize Events = count(), WithCommandLine = countif(isnotempty(CommandLine)) by Computer
| where WithCommandLine < Events

For 8.10, how far back each source actually reaches:

union withsource=SourceTable SecurityEvent, Syslog, CommonSecurityLog
| where TimeGenerated > ago(365d)
| summarize Oldest = min(TimeGenerated) by SourceTable
| extend DaysHeld = datetime_diff('day', now(), Oldest)

In the example, the first query returns two file servers silent since a patch weekend. The second returns a jump host whose 4688 events all have an empty CommandLine, because it sits in an OU the audit policy never reached. The third shows Syslog reaching back 30 days while SecurityEvent reaches 90. The evidence pack is those three results plus the fix for each.

Two caveats belong in it. A host silent for longer than the query window does not appear at all, so the list to compare against is the Control 1 asset inventory, not the SIEM. And a short DaysHeld can also mean a source was onboarded recently, so check the table's retention setting before calling it a finding.

Control 13 is the network side of detection

Its IG2 Safeguards ask for:

• centralized security event alerting, where CIS names a SIEM with correlation alerts as best practice (13.1),
• host and network intrusion detection (13.2, 13.3),
• traffic filtering between network segments (13.4),
• access control for remote assets based on anti-malware, configuration and patch state (13.5),
• and network flow logs to review and alert on (13.6).

IG3 adds:

• host and network intrusion prevention, with an EDR client as one of CIS's examples (13.7, 13.8),
• 802.1X port-level access control (13.9),
• application layer filtering (13.10)
• and tuning of alert thresholds monthly or more often (13.11).

A SOC already measures 13.11 as false positives per rule. If analysts classify incidents when they close them, the monthly review can start from this list:

SecurityIncident
| where CreatedTime > ago(30d)
| summarize arg_max(TimeGenerated, Status, Classification, Title) by IncidentNumber
| where Status == "Closed"
| summarize Closed = count(), FalsePositives = countif(Classification == "FalsePositive") by Title
| extend FalsePositivePct = round(100.0 * FalsePositives / Closed, 1)
| sort by FalsePositives desc

The rules at the top are the meeting's agenda, and the dated notes of what changed are the 13.11 evidence.

Control 10, Malware Defenses, leaves its trail in the Microsoft Defender Antivirus log

• 1116 and 1117 are a detection and the action taken on it.
• 2000 and 2001 are a signature update that succeeded or failed, which is the day-to-day proof for automatic signature updates (10.2, IG1).
• 5001 means real-time protection was turned off and 5007 means the configuration changed: those are the events to alert on when anti-malware is supposed to be centrally managed (10.6, IG2).

Control 17, Incident Response Management, is mostly process, and its evidence lives in the ticketing system

• IG1 asks for a named incident handler with a backup (17.1), current contact details for everyone who has to be told (17.2) and a documented way for staff to report incidents (17.3).
• IG2 adds a written response process, assigned roles, primary and secondary communication channels (CIS warns that email itself can be affected during an incident), exercises at least once a year and post-incident reviews (17.4 to 17.8).
• IG3 asks for written thresholds that separate an event from an incident (17.9), the same call a tier-1 analyst makes on every alert.

CIS Controls, CIS Benchmarks and NIST CSF answer different questions

• The Controls say what an organization should do.
• The CIS Benchmarks are prescriptive configuration recommendations for more than 25 vendor product families, the per-product detail behind Control 4, Secure Configuration.
• NIST CSF 2.0 describes outcomes and, in NIST's words, does not prescribe how they should be achieved.

The Controls are one way to reach those outcomes, and v8.1 realigned its security function mappings to CSF 2.0.