The Operational Controls: Accounts, Vulnerability, Logs, and Malware
Every CIS Control has a review cadence problem. An assessor can ask whether a policy exists, whether a tool is deployed, whether a configuration was correct on the day someone last checked. Most organizations can answer those questions adequately. The harder question — and the one that determines whether the control actually reduces risk — is whether it was enforced continuously over the last 90 days, not just on the days someone was looking.
For some controls, the gap between periodic review and continuous enforcement is mostly a documentation problem. For Controls 5 through 10, it is a threat model problem. These six controls cover account management, access control, vulnerability management, audit log management, email and browser protection, and malware defenses. They share a common characteristic: the threats they defend against move faster than any human review cadence can detect. Vulnerabilities are disclosed daily. Account privileges accumulate silently. Log retention gaps appear without warning. Malware establishes persistence in minutes.
The phrase “we do that quarterly” is not a compliance answer for these controls. It is an admission that the threat operates on a timeline you are not on.
The Review Cycle Is Architecturally Insufficient
A monthly review of privileged accounts does not detect the temporary elevation that was never revoked. A quarterly vulnerability scan does not catch the CVE disclosed in the third week of the quarter and exploited in the fourth. A monthly log audit does not identify the retention failure that started on day three and left a 27-day gap. A weekly malware scan does not find the persistent scheduled task that ran its first beacon within minutes and has been calling home every four hours since.
These are not edge cases. They are the ordinary behavior of these threat categories. Credentials are abused, vulnerabilities are disclosed, log settings drift, and malware persists on timelines measured in minutes to days — not calendar quarters. A control framework built around monthly or quarterly human review is betting that the threats it defends against operate more slowly than the people reviewing for them. For Controls 5 through 10, that bet is consistently wrong.
The only architecturally sufficient answer is continuous enforcement with automated detection and response.
CIS Controls 5 and 6: Account Management and Access Control
The account problem at MSP scale is not that accounts are created carelessly. It is that they accumulate state over time in ways no one is actively watching. A technician who needed local admin two months ago may still have it. A service account granted broad permissions for a migration project may still hold those permissions after the project closed. An employee who changed roles has accumulated rights from three positions and no one has reviewed the full set.
None of this appears in an alert queue. It accumulates silently.
BE-17 addresses this through just-in-time privilege elevation. When a technician — or the AI brain — needs elevated rights, the request specifies a reason, a duration (15 minutes to 8 hours), and a scope. It goes through an approval workflow: explicit org admin approval or auto-approval within a defined policy. The agent grants the elevation and a revocation timer starts. The revocation is a failsafe, not an assumption: it works even if the API is unreachable. What remains is a full audit trail — who requested, who approved, what was done, when it expired.
The brain’s role is to make this narrated and legible: “I need to install a custom driver on DESKTOP-019. Requesting 30-minute elevation. Auto-approved per policy. You now have local admin for 30 minutes — I’ll revoke automatically at 3:45pm.”
BE-8 tracks active sessions — who is on what device, session state (active, idle, locked, away), login time, session type. This is the “is it safe to act?” check before any disruptive action. Before rebooting for a critical patch: “DESKTOP-019 has an active user session — jsmith, logged in two hours ago, currently active. I’ll wait until after hours.”
BE-31 generates user risk scores from behavioral data: phishing click rate, software violations, sensitive data exposure, training completion, elevation request frequency, USB violations, login anomalies. This is continuous behavioral telemetry, not an annual awareness survey. It surfaces the users who warrant closer attention before they become an incident.
CIS Control 7: Vulnerability Management
The vulnerability management problem is a data freshness problem. NVD publishes new CVEs daily. The window between disclosure and active exploitation in the wild has compressed — in high-severity cases, it is now measured in days. A monthly vulnerability scan means a device can be exposed and exploitable for the better part of a month before the scan confirms it. A quarterly scan means up to 90 days.
BE-16 starts with the software inventory that every managed device already reports every 15 minutes — not a separate scan cycle, but a continuous data feed. That inventory is correlated against NVD daily, mapping software name and version pairs to known CVEs with CVSS scores and exploitability metadata. When a new CVE is published against Apache Log4j 2.17.0, the platform already knows which devices are running that version. Exposure is identified without waiting for a scan.
The brain surfaces this with context a raw scan result doesn’t provide: “CVE-2026-1234 (CVSS 9.8) affects Apache Log4j 2.17.0. Six servers in your fleet are running affected versions. An exploit is publicly available. A patch exists. Given the severity, I recommend immediate deployment — not waiting for the next maintenance window.”
The difference between BE-16 and a traditional vulnerability scanner is the difference between a data correlation layer and a scheduled scan. The scanner tells you what is broken. The correlation layer tells you what is broken, how badly, which devices, and can initiate patch deployment without a technician opening a separate console.
CIS Control 8: Audit Log Management
Control 8 is routinely underinvested because logs feel retrospective rather than protective. They are not preventing threats — they are recording what happened.
That framing understates two distinct risks. First, log evidence is what determines whether an incident is containable or catastrophic. An organization that cannot reconstruct the blast radius of a compromise cannot close the incident with confidence. Second, many devices are not logging the right categories to begin with. The logs exist; they simply do not contain the events an investigation would need. Both risks are silent — neither generates an alert.
BE-21 addresses the second risk directly. Many Windows machines ship with inadequate audit policies — Account Logon failures not logged, Object Access auditing disabled, Event Log max size set to 1MB. BE-21 applies CIS Level 1 audit policy baselines across non-compliant devices and enforces them continuously. When a device drifts from the defined policy — because an update reset a setting, or an application modified registry values — the drift is detected and corrected.
BE-20 addresses the first risk with fleet-wide full-text log search across Windows Event Logs, macOS system.log, and Linux syslog and journald. The aggregation capability is what converts a single-device search into a fleet-level pattern: 38 of 47 “Application Error” events referencing outlook.exe with the same exception code, starting at 2pm — correlating with an Office update deployed at 1:45pm. “Recommend pausing deployment and rolling back.” A technician reviewing individual device logs would work the first ticket. The fleet-level correlation changes what question gets asked.
BE-14 ships agent operational logs centrally. When an agent misbehaves, the brain can diagnose without opening a remote session: “Agent on SERVER-003 hasn’t sent a heartbeat in 15 minutes. Last log entry: WebSocket connection refused, retry 5/10. This is an API-side issue, not agent-side.”
CIS Control 9: Email and Browser Protection
Browser extensions are one of the quieter initial access vectors in enterprise endpoint security. An extension requesting all_urls, webRequest, and cookies can intercept every form submission on every site a user visits. It requires no exploit, no malware signature — just a user installing a browser extension. Sideloaded extensions bypass even the limited review process that official stores provide.
BE-27 maintains a continuous extension inventory across the managed fleet, cataloguing each extension’s declared permissions, installation source, and risk classification. Policy enforcement can block extensions that exceed a defined risk threshold or originate from unapproved sources.
BE-28 integrates with DNS filtering providers — Cisco Umbrella, Cloudflare Gateway, DNSFilter, Pi-hole — and ingests blocked queries and threat category data. The value is correlation, not raw DNS data. DNS filtering alone tells you that a device attempted to reach a blocked domain. Correlated with Breeze device context, it tells you which process initiated that query and what else has changed on that device: “DESKTOP-033 attempted to reach known C2 server 47 times in the last 24 hours. Requests coming from svchost-helper.exe — the suspicious startup item I flagged in the boot performance analysis.” Without the correlation, that is a DNS alert. With it, that is a compromised device.
CIS Control 10: Malware Defenses
No RMM should attempt to replicate what Huntress or SentinelOne have built. Persistent foothold detection, behavioral analysis, and MITRE ATT&CK mapping require dedicated investment and research infrastructure. The correct approach is first-class integration that treats EDR data as part of unified device context rather than an external feed to display in a dashboard.
BE-22 integrates with Huntress — pulling incidents, agent status, and summary data through the REST API, correlating each Huntress agent with its corresponding Breeze device record. When Huntress detects a persistent foothold — a scheduled task named “WindowsUpdateCheck” running encoded PowerShell every four hours, matching a known CobaltStrike beacon pattern — the response runs from a single context: “I’ve isolated SERVER-002, captured the encoded command, created a P1 ticket.”
BE-23 integrates with SentinelOne bidirectionally. Threat data flows in with MITRE ATT&CK mappings. Actions flow out — isolate, kill process, quarantine file, rollback — through the same approval workflow as any other mutating platform action. A unidirectional integration that only reads threat data still requires a technician to pivot to the SentinelOne console to act. The response latency is not just travel time between dashboards — it is the window in which the threat continues to operate.
The cross-tool correlation is where integrated malware defense produces its real value. SentinelOne detects Emotet.Trojan. Breeze correlates: this user received three phishing emails this week. invoice.pdf.exe was downloaded 20 minutes before the detection. The recommended response is not “run a full S1 scan” — it is “full S1 scan already triggered, force password reset for this user, review which other devices this user authenticated to today.” None of those steps are derivable from the SentinelOne alert alone.
The Gap Is Widest Where It Costs the Most
Every MSP running a reasonable security stack has tools that touch account management, vulnerability scanning, log collection, and endpoint protection. The gap is not in those tools individually. It is in what happens between them — and in the enforcement model that expects humans to close that gap on monthly or quarterly cycles.
An account accumulating standing privilege does not appear in any tool’s alert queue. A vulnerability disclosed after the last scan window and exploited before the next generates no detection event. A log policy that drifts from baseline produces no alert — it produces nothing at all. Malware that establishes persistence in minutes has already run by the time the next scheduled scan checks.
These are enforcement model failures. A tool that surfaces data to a human and waits for action is not designed for threats that operate faster than review cycles. Continuous automated enforcement is not a feature — it is the minimum viable architecture for these controls. The organizations that build around this distinction will be able to answer the assessor’s question about 90 days of continuous evidence with something other than quarterly snapshots and a story.
LanternOps surfaces the continuous enforcement data from these controls in a format designed for security review workflows — normalized, queryable, and exportable for audit purposes. The next post in this series covers Controls 11 through 13: data recovery, network infrastructure management, and network monitoring.