Logging Under M-26-14

The pillar every other pillar reports to

Every mechanism this training built emits evidence: denied sign-ins (2.1), activation ceremonies (2.3), compliance flips (3.1), east-west denials (3.3), quarantine manifests (4.1), session revocations (4.3). Visibility is where those streams become detection, investigation, and — Module 6 will insist — proof. Tenet 7 said collect and improve; this lesson is the collection done right, under the rules that actually govern it in 2026.

Which rules matter, said carefully because Lesson 1.2’s trap lives here: the old federal logging memo with its EL0-EL3 tiers — the one most templates still cite — was rescinded in May 2026. The current model grades five levels (Ineffective → Optimal) across concrete elements — inventory visibility, collection coverage, collection operations, retention, log management — organized around two missions: continuous event monitoring (is the telemetry flowing and watched?) and threat hunting, investigation, response and forensics (can you answer questions about the past?). Commercial readers: you are graded on the same shape of rule under other names — PCI DSS (the card-payment security standard) and its one-year log retention, SOC 2 (the audit report your customers ask for) and its monitoring criteria, ISO 27001 (the international security-management certification) and its logging control, and increasingly your cyber-insurer’s renewal questionnaire. Use the five-level model as the rubric and map your own obligations onto its elements: the architecture below is one implementation you can evidence against each of them, with each framework’s specifics — PCI’s immediate-availability window, for instance — verified on its own terms.

Central by default — and the drift that fights it

The recurring real-world finding: estates accumulate scattered per-team, per-app log workspaces — each a silo the SOC can’t correlate across, each with its own retention accident. The honest observation from an audit of one production estate: no authority actually requires per-system separation; the maturity model points at centralized visibility; the scatter is inertia, not architecture. And scatter has a price nobody invoices: an investigator correlating one incident by hand across five consoles, and a retention accident in any one of them becoming the gap the auditor finds — central-by-default turns that into one query and one retention policy. The 2026 pattern that makes central affordable is split-tier storage: a hot analytics tier for the detections that need speed, and a cheap data-lake tier for the long-tail retention that forensics and the retention floors demand. The old excuse — “central costs too much at hot-tier prices” — died when the lake tier shipped; what remains is the migration.

Two implementation rules from the field: route by category, not by source — performance, availability, errors, security, administrative, self-monitoring — because category is what determines who gets paged and where it lands; and reference the central workspace by lookup, not hardcoded ID — a real estate was found with the workspace resource ID copy-pasted across five files, which is drift with a fuse (Module 6’s externalize-the-anchor rule, previewed).

The alert library: 17 rules and a canary

An infrastructure-health starter set for a small estate, drawn from a production library — note the shape more than the count, and note what it is not: the identity, device, and data-access detections come from your threat model, and Lesson 5.2’s detection library is where they grow:

Scheduled/analytic (8):  CPU, memory, disk, heartbeat-loss, app success-rate,
                         error-spike, ingestion-health, and a WORKSPACE-
                         SILENCE CANARY - the alert that fires when logging
                         itself goes quiet
Activity/audit (9):      resource-group deletion; policy write/delete; role-
                         assignment write/delete; NSG-rule write/delete;
                         ALERT-RULE TAMPER; service-health

The two capitalized rules are the assume-breach pair most libraries forget: an attacker’s first competent move is stopping the telemetry, so the pipeline watches itself — silence alarms, and so does editing the alarms. Every rule carries its control-ID tag (queryable, feeding Module 6’s evidence story), a severity, and a staffed notification route — a distribution list a team owns, never an individual’s inbox, and every environment beyond a developer sandbox hard-fails deployment if no notification route resolves: an alert with nowhere to go is a configuration error, not a silent no-op.

The witnessed-alert rule

The discipline this module keeps returning to, imported from a real adoption runbook and worth engraving: a rule that has never fired a notification a human witnessed is unverified, not done. Deployment ends with a deliberately-triggered test — fill the disk, stop the heartbeat, delete a canary resource group in the test sub — and a named human confirming the page arrived. Every step between “condition true” and “human notified” (query syntax, action group wiring, mail routing, the on-call schedule) can silently fail, and only the end-to-end test exercises them all. This is Lesson 2.1’s verifier-coupled-policy pattern applied to the monitoring itself — and Lesson 5.3 will generalize it to everything.

Design the logging architecture for this estate: (1) the central workspace
plan - split-tier layout, retention per tier honoring the current memo's
floors (cite its retention table by tier - they are dated facts, never
quoted from memory),
migration order for the scattered workspaces we found; (2) ingestion map -
every Module 2-4 control's stream, with the collection-coverage gaps named;
(3) the alert library instantiated - the 17-rule shape adapted to us, each
rule with category routing, control tag, severity, staffed route; (4) the
witnessed-test plan - how each rule gets its observed firing, and the
quarterly re-witness schedule for the canary pair.

💬Ingest bills are a design output, not a surprise

The classic failure: ingest everything at hot-tier prices, get the invoice, and “temporarily” drop the security streams — leaving the SOC blind by cost-cutting. The split-tier design exists so the answer to cost pressure is “move colder, never off”: detections keep their hot minutes; forensics keeps its lake years; nothing stops being collected. If a stream genuinely isn’t worth lake prices, that decision gets made in the design review with the threat model on the table — not in a billing panic.

KNOWLEDGE CHECK

Meridian's alert library deploys cleanly, dashboards are green, and the team marks the visibility milestone complete. Three months later a storage account is deleted at 2 a.m. and nobody is paged — the activity-log alert existed, but its action group pointed at a distribution list that was never created. Which discipline was skipped, and what would have caught it?

ℹPlatform names, decoded

This lesson’s nouns are Azure’s: a workspace is the central log store (Splunk index, Elastic cluster, or CloudWatch log group elsewhere); an action group is the routing rule that turns an alert into a page; an NSG is a network security group (a cloud firewall rule set); a DL is a distribution list; the SOC is the security operations center — the humans who watch. The architecture is the same on any platform; only the nouns change.

Practice status — among mature regulated delivery programs, commercial and federal

(a few rows carry a more specific status - principle, canon, suspended - where one of the five would mislead)

Practice	Status	Also called
five-level logging maturity model (M-26-14)	required (federal agencies) a benchmark for commercial readers; PCI / SOC 2 / ISO keep their own specifics	—
central, split-tier log platform	common baseline	hot / cold tiering
witnessed alerts	strong optional	alert fire drills / detection validation
monitoring the monitor	common baseline	heartbeat and silence detection
detection library in git	strong optional detection-as-code (Lesson 5.2)	—

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

Aim at the current rules (the five-level 2026 model — the EL tiers are dead), centralize with split-tier economics so cost pressure moves data colder instead of off, route by category to staffed destinations, watch the watchers with the silence-and-tamper pair, and let no rule count as done until a human has witnessed it fire. Collection is solved; next, the detections that ride on it — managed like code, graded like evidence.

LEADERSHIP DECISION   fund one central, split-tier log platform and a staffed
                      alert route - not per-team workspaces that each become a
                      retention accident
PRACTITIONER ACTION   centralize with split-tier retention, route every
                      control's stream, witness every alert fire once, monitor
                      the monitor
SUCCESS MEASURE       one incident reconstructed from one query; every alert
                      rule has a witnessed firing on record; ingest cost flat
                      while retention grows

What you'll learn

The pillar every other pillar reports to

Central by default — and the drift that fights it

The alert library: 17 rules and a canary

The witnessed-alert rule

Key takeaway