CISA’s Logging Reference Architecture Through a SOC Leader’s Lens

Security Operations Centers have two primary objectives: detect and respond. To do so, SOCs need to be able to investigate alerts, proactively hunt for threats, write detections, respond to incidents and more. All those capabilities need to be supported by data. That’s where CISA’s recent Logging Reference Architecture comes in.

LRA provides guidance on how to establish what is essentially a security data strategy. It converts the M-26-14 memorandum into a guideline for architecture and engineering decisions around logging and goes over:

- Logging coverage, fidelity and architecture

- Logging infrastructure and its security

- Operational use-cases

-  Maturity model

and more.

The goal is to have federal agencies refer to the LRA when designing their logging architectures, creating Agency Logging Plans, driving continuous improvements of the logging capabilities, and, finally, supporting the governance of AI as far as enhancing logging capabilities is concerned.

This is an extensive document that frequently goes over concepts that a SOC leader should know. We’re explaining the new and interesting concepts it brings forward without the unnecessary context:

1. Focus on security outcomes

Section 3 comes right after the introduction, scope and intended use sections and contains the first interesting bit. While M-21-31 (the previous memorandum, now replaced by M-26-14) was strictly focused on logging levels (i.e. how much are you logging), the LRA based on M-26-14 is focused on security outcomes.

It asks whether you can achieve two objectives:

- CEM – continuous event monitoring. That’s detection, one of the two core objectives of a SOC

- THIRF – threat hunting, investigation, response and forensics. That’s response (a bit of detection too), the second SOC objective

This is essentially saying that your logging strategy needs to support detection and response.

SOC Leader's Perspective:

Probably the most common SIEM anti-pattern is overcollection and that is caused by thinking about what data to collect first and then trying to determine what security outcomes can be achieved with it. By flipping this approach and focusing on detection and response targets first we’re able to sidestep the biggest obstacle to a cost effective SIEM.

Good start.

2. Strict evaluation criteria for logging capability readiness

Another interesting part of Section 3 goes over the minimum baseline for measuring logging capability readiness. It is:

- Cost: Weigh the full cost of a log source, including labor, licensing and operations, against the risk it actually reduces.

- Coverage: Confirm the sources that matter for your mission and risk profile are represented, rather than assuming everything must be collected.

- Timeliness: Events have to arrive fast enough to support the outcome they serve.

- Fidelity: Records need the fields and context required to correlate, scope and reconstruct.

- Integrity: Nothing should be altered outside of planned collection, ingestion and normalization.

- Searchability and retrievability: Analysts must be able to search and retrieve data inside the expected windows.

- Data quality: Timestamps reliable, required fields populated, mappings stable, parser failures visible.

- Operational usability: Analysts should be able to pivot and investigate without manual reconciliation, with attributes that support correlation within and across sources.

- Forensic readiness: Designated datasets are protected and handled to evidentiary standard where needed.

-  Validation maturity: The agency actively tests whether the capability stays complete, usable and resilient.

This reads as an aspirational process, and yet the document clearly states that this is what agencies should measure “at minimum”.

SOC Leader's Perspective:

This is considerably more mature than what a typical security data strategy would involve. On one hand, there’s nothing wrong with a high bar for a process maturity, on the other  you’d have hard time finding a SOC that measures their logging capabilities across all those criteria. This alone could generate more work than a SOC can absorb.

‍

3. Data pipeline specification

We talked a lot about this one in our blog earlier in the week, CISA's Logging Reference Architecture is a Data Pipeline Spec in Disguise. Section 4 goes over architectural decisions for a security monitoring strategy. It reinforces that SOCs should first consider security outcomes, meaning detection and response, and then identify telemetry to support them. It calls out an anti-pattern of ingesting as much as possible or choosing log sources currently available or easy to integrate.

SOC Leader's Perspective:

We know to identify data supporting our detection and response efforts, but what data is this exactly? Section 4 doesn't answer that. Section 9 does, and the method it gives is good, but it only applies to logging above the baseline. I'll come back to that.

Another interesting part called out as the key design constraint covered by the LRA is to collect security-relevant events as close to the authoritative source as practical. The LRA states that “(…) agencies should prefer authoritative log sources over derived or partially processed copies when doing so materially improves accuracy, attribution, and investigative value. For example, native control-planes or administrative audit records are usually more authoritative than downstream summaries generated by another platform.”.

SOC Leader's Perspective:

This is very interesting and not how many SOCs choose to operate in practice. We rely heavily on downstream security tools to pre-process raw data and turn it into telemetry. Endpoint Detection and Response tools are a very good example. Many SOCs choose not to collect raw endpoint logs – or at least not from all systems – and instead rely on EDR telemetry for investigations and detections[1].

Section 4 goes on to introduce technical terms that are typically not that well understood among SOC leaders. It is slightly unusual that the LRA simply lists the requirements and doesn’t explain what those are in detail. Here is what is being prescribed with explanations.

-  Durable handoff: A record is not considered sent until the next stage confirms it received it.

- Buffering: Hold data locally when a destination is slow or down so the outage does not become a permanent gap.

- Checkpointing: Track your position in the stream so a restart resumes instead of skipping or duplicating.

- Replay: Resend telemetry from a known point after a parser fix, schema change, or silent rejection.

- Back pressure: Slow the producers when downstream cannot keep up, instead of silently dropping records under load.

-  Partial failure: One broken destination or source should not take the rest of the pipeline with it.

- Monitoring of queue or transport health: Watch lag, queue depth and delivery failures, because a connected source is not the same as a working one.

The LRA goes on to prescribe the tagging, segmentation, redaction, routing, access control and outbound sharing is managed through a centralized policy enforcement mechanism. And finally emphasized the need of data tiering, normalization, enrichment, schema enforcement, operational monitoring and validation.

SOC Leader's Perspective:

Those are all very strict requirements which can’t be satisfied without either building or buying a security data pipeline. The entire Section 4 reads like a security data pipeline specification and, practically, is one.

‍

4. SIEM no longer the default destination

Section 5 covers deployment patterns. It lists several of them neutrally and then, in 5.4.4, does something you rarely see in federal guidance – it names the pattern most agencies are actually running and explains why it does not hold.

The SIEM-first pattern, where everything lands in the SIEM and the SIEM is also the data store, is described as tending to get costly and inflexible as telemetry volume and retention expectations grow. The LRA notes it may weaken fidelity and points out that practitioner guidance has been warning against treating a SIEM as the central repository for years. Section 4.5 backs this up as well and states that “not all telemetry has to remain in the SIEM”

Repository-first and selective-feed patterns get a friendlier treatment.

SOC Leader's Perspective:

This is a step in the right direction. Treating SIEMs like the default log repository is an outdated thinking that doesn’t match up to the modern technology which allows for flexibility in choosing a log storage technology.

‍

5. Baseline logging requirements

A source can exist in the environment and still fail operationally if the events are delayed, too sparse, improperly parsed, missing key context, or unavailable to the teams that need them. – section 6

The document starts with a generic directive of how security data strategy should support the SOC’s objectives – i.e. detections and response. At times, however, it gets pretty specific. For example, when discussing AI systems, the LRA calls out the need to log:

-  User prompts

- System prompts

-  Model outputs

Then in section 6.1 it calls out 8 specific detection targets that the security data strategy needs to support:

‍

“Alerts are useful signals, but they are not substitutes for the underlying event data needed to validate, scope, and reconstruct activity” – section 6.2.6

The LRA continues to describe the minimum required fields and fidelity requirements of data, listing what should be preserved at minimum:

- A reliable timestamp

- An identifiable event or action type

- Identity or system context, where applicable

- The affected device, resource, service, or dataset, where applicable

- The result or outcome, where applicable

- Where the record originates from

SOC Leader's Perspective:

This document is both prescriptive and not when it comes to baseline logging requirements. It starts with – “collect identity, network, storage, audit logs, downstream tool alerts and enough telemetry for IOC matching” and “ensure those specific fields are in place”, to then say “collect enough data to know how an incident progressed and what systems were impacted by it”, which can be literally any data. 

‍

6. Finally… a framework?

Section 9.3 – Method for determining above baseline logging is probably the most valuable part of the LRA from a SecOps perspective. At the same time it only describes logging above the baseline or in other words – additional logging once the baseline requirements are met.

It lays down a 5 step process:

Step 1: Identify mission-critical assets and services.

What would cause significant mission or operational harm if compromised. HVAs, cloud identity systems, enterprise authentication, public-facing mission systems, OT.

Step 2: Map relevant threat scenarios to those assets.

Credential theft, cloud privilege escalation, data exfiltration, misuse of administrative access, lateral movement, OT disruption.

Step 3: Identify the investigative questions the agency must be able to answer.

The LRA gives examples – can you reconstruct credential use across cloud and on-premises, can you determine who changed a privileged role assignment and from where, can you measure the scope and timing of exfiltration.

Step 4: Translate those questions into telemetry, fields, fidelity and retention.

Specific log sources, specific fields, timing expectations, and a decision on whether the data must be searchable, retrievable, or handled with stronger integrity protections.

Step 5: Integrate into architecture, validation and cost management. The LRA is blunt here – above-baseline “telemetry that exists only on paper or only in one enclave is not a reliable enterprise capability”.

Or in a simple graph:

SOC Leader's Perspective:

Mature SOCs typically work based on a threat and / or risk driven frameworks similar to the one suggested by the LRA. It is unfortunate that this only covers the “additional logging”, but is still a mature, repeatable framework that should be taken into consideration despite its optional nature.

‍

7. Portability and governance as part of the requirements

The entire section 7 of the LRA goes over expectations agencies should address so that data remains usable across different tools, environments and services. It specifies a minimum standards for normalization while highlighting how it can’t destroy the underlying context of data. Makes perfect sense – sometimes data is normalized so much that it’s difficult to tell which system it originates from.

In practical terms, it explains that post-normalization, the minimum required fields are:

- Event time

- Event or action type

- Identity or system context

- Affected device, resource, service, or dataset

- Outcome or result

- Where the data comes from

Then it goes over to define the governance requirements around data onboarding, by prescribing that it should define:

- How new sources are onboarded

- What fields are required for each baseline category

- How mappings are validated before and after deployment

- How parser failures, unmapped values, and drift are detected

- How downstream content that depends on those fields is identified and tested

- How rollback is handled if a change degrades operational use

Still, the most interesting part of the entire section 7 is portability:

“agencies need to avoid becoming operationally dependent on proprietary structures that make it difficult to export, validate, or reinterpret security-relevant data” – section 7.4

Organizations typically use multiple security tools to achieve their security objectives. Each of them has its own, proprietary schema. Trying to reconstruct events spanning multiple tools without normalization to a common schema is difficult. CISA’s LRA calls that out and required agencies to know what a normalized event record looks like and how authorized shareable subsets of data are produced and governed.

SOC Leader's Perspective:

CISA essentially asks to normalize data, establish governance around security data-related changes and build a process for supporting request for logs from CISA, FBI, courts or legal counsel. Compared to a regular SOC this is both mature and reasonable. Governance and change control around security data is often a missing piece that gets added only after a disruptive, operational incident

‍

8. Logging infrastructure is a target

“From an Agency Logging Plan perspective, the resilience question should be written directly: How does the agency detect degradation, recover missed data, preserve trust during partial failure, and validate that required datasets remain complete and usable over time? A mature answer to that question is one of the clearest indicators that the logging capability is more than a collection stack.” – Section 8.3

Section 8 shifts attention from the data to the system carrying it, which is where the document gets more mature than most enterprise security data strategies.

8.1 states that treating only the SIEM as the critical asset is too narrow, and tells agencies to evaluate whether their logging infrastructure meets their own high-value asset criteria. Hard to argue with as anything sitting in the middle of the telemetry path is a critical failure point that needs to be secure.

8.2 sets an evidentiary bar: cryptographic hashing on upload, movement and access, signing, write-once handling, auditable transfer paths, documented acquisition procedures and preserved transformation history.

8.3 lists the anti-patterns agencies should avoid:

- Overreliance on point-to-point integrations

- Polling as the default collection method

- Centralizing all telemetry into a single fragile pipeline

- Normalization that discards investigative context

- Unmanaged policy bypass

- Vendor-dependent handling that leaves essential telemetry outside agency control

SOC Leader's Perspective:

Section 8 essentially asks SOC leaders – “is security data pipeline one of your crown jewel assets?”. This is an approach that many security organizations don’t take as high value assets are derived from the business’s perspective rather than from the security teams’ POV. Still, depending on how high value assets are defined security data pipelines may make the list – this will be highly dependent on an organization.

‍

9. AI as derived data and never the record

Section 5.5 covers logging AI systems. Section 10 covers AI used inside the logging capability itself and specified strict boundaries.

Model outputs are derived data. They are never authoritative event content. Agencies have to preserve the relationship between the original record and the derived output, and record enough metadata to support review, reproduction and challenge of the result.

Forensics gets the strictest line in the document. AI must not alter source evidence, must not replace chain-of-custody controls, and must never become the authoritative record.

Every SOC is putting AI somewhere in the triage path right now, and very few have a written position on what the model output actually is. Is it an enrichment, an assessment, or a finding? Can an analyst close a case on it? Section 10 answers that, and the answer is better than what most teams would have written for themselves.

10. The new maturity model

Section 11 covers maturity. M-26-14 replaced the old EL0 to EL3 tiering with a five-level model scored across inventory visibility, collection coverage, collection operations, data retention and log management:

The timeline is aggressive for an initiative like this: Agency Logging Plan within 90 days of publication, Basic maturity level within 120, Intermediate within 180, Advanced within 320. That is roughly eleven months, against the two years M-21-31 allowed.

11. Appendices

It’s at times difficult to derive specific recommendations from the body of the Logging Reference Architecture as it alternates between prescriptive and non-prescriptive language. Luckily, the appendices provide a simple to follow checklist and for those with limited time I’d suggest reading them first.

Appendix C is a review checklist for the Agency Logging Plan, organised by decision area – outcome alignment, scope, fidelity, collection, transport, schema, storage, access, validation, above-baseline decisions and maturity. It's written for a reviewer rather than an author, so it works reasonably well as a self-assessment.

Appendix D is a quick reference for each of the nine baseline categories. For every one it lists the operational purpose, minimum usable fidelity, additional fidelity often needed, and common operational failure modes. The failure mode lists are the useful part. They're specific enough to test against, and most of them will be familiar. Identities that can't be correlated across systems. Network records that can't be tied to hosts. Changes recorded but not attributable to an actor. Alerts that exist without access to the underlying event context.

Appendix E covers validation. It works through scope, source presence, timeliness, fidelity, schema, searchability, usability, integrity, pipeline health, change management and gap tracking. Each item is scored as validated, partially validated, not yet validated, or a known gap with a remediation plan, and it asks for evidence rather than assertion – synthetic tests, replay exercises, search demonstrations, drills.

The Logging Reference Architecture

The LRA is a better document than the memo it implements. It asks whether you can use the data when something happens rather than how much of it you're keeping. It says collecting everything isn't feasible or cost effective, that a SIEM isn't the right place to keep all of it, and that a connected source isn't the same as a working one.

The one thing that comes to mind is just how strict some of those requirements are. From a SOC leadership perspective – achieving that level of maturity when it comes to security data strategy in the timespan given to federal agencies (11 months) is difficult even for mature and well-staffed teams.

At Abstract we spend most of our time in these problem areas, from pipeline design and storage tiering to normalization, fidelity and validation. If you're putting an Agency Logging Plan together or working on your security data strategy more broadly, we're happy to help.

‍

[1] Often the approach is to rely primarily on EDR telemetry while collecting raw logs, Sysmon, syslog etc. from critical systems

‍