What log infrastructure actually means in a state context
Security event logging is the practice of recording what systems, users, and applications do — authentication attempts, file access, network connections, configuration changes, privilege escalations — and retaining those records long enough to support investigation, threat hunting, and compliance. Log infrastructure is the collection of systems, pipelines, storage, and analysis tools that make those records accessible and useful.
In the federal government, OMB Memorandum M-21-31 (August 27, 2021) established a tiered maturity framework for logging, issued in response to Executive Order 14028 on improving the nation's cybersecurity. The memo requires agencies to achieve progressively higher logging maturity across endpoint, network, and cloud systems, with defined retention periods and centralized collection obligations. Its relevance to state government is not as a binding requirement — it is a federal mandate — but as a detailed operational reference. Federal agencies discovered the same thing state agencies are discovering: logging was assumed to be working, and it frequently was not.
The NIST SP 800-92 "Guide to Computer Security Log Management" (September 2006) describes the foundational problem: logs are generated by nearly every IT component, but they are inconsistently configured, stored in different formats, retained for different durations, and rarely analyzed in aggregate. In state government, that fragmentation is compounded by the agency-by-agency structure: a state with 40 agencies often has 40 distinct logging configurations, 40 sets of retention decisions, and no central visibility into any of them.
The three capabilities that require log infrastructure first
Zero trust. The CISA Zero Trust Maturity Model v2.0 (April 2023) organizes zero trust across five pillars — Identity, Devices, Networks, Applications and Workloads, and Data — and describes progression from Traditional to Optimal maturity in each. Across all five pillars, achieving Advanced or Optimal maturity requires continuous monitoring: real-time verification of device health, user behavior, application access patterns, and network traffic. That monitoring is, mechanically, a log analysis problem. A state can implement multi-factor authentication, micro-segmentation, and conditional access policies. Without centralized logging and analysis, it cannot detect when those controls are being circumvented, when a credential is being misused, or when lateral movement is occurring. The access control layer of zero trust generates the logs; the analysis layer makes them actionable. States that have published zero trust transition plans but have not addressed log infrastructure have, in most cases, committed to the control layer without the analysis layer.
NIST SP 800-207 "Zero Trust Architecture" (August 2020) makes this dependency explicit: the Policy Decision Point at the center of a zero trust architecture relies on continuous signals from monitoring systems. Without those signals, access decisions revert to static policy — which is not zero trust, it is conventional access control with a different label.
AI-assisted threat detection. User and Entity Behavior Analytics (UEBA), anomaly detection, and AI-powered threat correlation all require the same input: a consistent, well-labeled stream of security events collected over time. A threat detection model trained on incomplete or inconsistently formatted log data will produce unreliable alerts. More fundamentally, threat detection models require a baseline — what normal authentication behavior, file access patterns, and network activity look like — that can only be established from historical logs. A state agency that begins collecting logs in earnest after a security incident is building a baseline on post-incident data, which is not the same thing. The value of AI-assisted detection scales with the quality, coverage, and history of the underlying log infrastructure.
Incident response. When CISA's "StopRansomware" guidance and FBI incident response playbooks describe the forensic work of understanding an intrusion — how the initial access occurred, which systems were touched, what data moved, how far lateral movement progressed — that work requires logs that predate the incident. The default retention periods on many systems (seven days of authentication logs, for example, or 30-day disk overwrites on endpoints without a SIEM) are insufficient to support investigation of intrusions that begin with low-and-slow credential harvesting weeks before an active ransomware deployment. NIST SP 800-92 identifies retention planning as one of the most consequential log management decisions, precisely because it determines what evidence will exist when it is needed.
What a credible log architecture requires
A state security log program needs to answer four structural questions before it can support the capabilities above:
Coverage. Which systems generate logs that matter, and are those logs being collected? The answer in most states is partial: cloud services, on-premises servers, endpoint software, network devices, authentication systems, and applications each generate relevant logs, but coverage is typically uneven. Authentication systems are usually logged; endpoint behavior is often not. Cloud workloads may log to platform-native tools that are not integrated with anything else.
Collection and normalization. Logs from different systems arrive in different formats. A SIEM or log aggregation platform converts them into a consistent schema that supports correlation and search. Without that normalization, an analyst investigating an incident cannot efficiently search across authentication logs, network flows, and endpoint events simultaneously.
Retention. Different log types require different retention periods depending on their investigative value and applicable regulations. NIST SP 800-92 identifies the organization's risk profile, regulatory environment, and operational storage capacity as the relevant factors. As a general reference point, M-21-31 requires federal agencies to retain certain high-priority log categories for 30 months; state requirements will vary but should be grounded in explicit retention decisions rather than defaults.
Access and analysis. Log data has limited value if it is retained but not accessible for timely analysis. A SIEM with tuned detection rules, or a managed security service with analyst access to state log data, provides the operational layer. States that retain logs but lack search and correlation capability have the evidence but cannot use it.
CISA resources and the SLCGP funding path
The State and Local Cybersecurity Grant Program (SLCGP), authorized under Section 70612 of the Infrastructure Investment and Jobs Act (Public Law 117-58, November 15, 2021) and administered by CISA, provides dedicated federal funding for cybersecurity improvements in state and local governments. SLCGP funding applications require a Cybersecurity Plan developed through a state Cybersecurity Planning Committee, with specific investment priorities identified in program guidance. Log infrastructure — including SIEM deployment, endpoint detection and response (EDR) tooling, and security data architecture — is eligible for SLCGP funding and consistent with CISA's identified priority areas.
CISA also offers several no-cost services relevant to log infrastructure, catalogued at cisa.gov/resources-tools/services, including network monitoring, vulnerability scanning, and cybersecurity assessments that can establish a baseline for identifying log coverage gaps. The MS-ISAC, administered through the Center for Internet Security (CIS) under a CISA cooperative agreement, provides security monitoring services for state and local governments and can serve as a managed log analysis option for states that are not ready to operate their own SIEM infrastructure.
Architecture choices and their operational tradeoffs
State CISOs facing the log infrastructure question have three practical architecture options:
Centralized state SIEM. The state operates a SIEM platform that ingests logs from all agencies. This provides maximum visibility and control, enables cross-agency correlation (detecting lateral movement that crosses agency boundaries), and supports state-level threat hunting. The cost and staffing requirements are significant: a SIEM without adequate staffing to tune and analyze it generates alert noise that erodes its value. States that have consolidated other IT infrastructure (shared data centers, centralized identity systems) are better positioned to extend that model to logging.
Managed security service. The state contracts with MS-ISAC or a commercial managed security service provider (MSSP) to collect and analyze logs. This reduces internal staffing requirements and leverages established detection content, but requires the state to ensure that its data governance requirements, incident notification obligations, and contractual access rights are addressed in the service agreement. Not all managed services provide the same visibility or retention; the state should specify coverage, retention periods, alert criteria, and data portability before contracting.
Hybrid. Core systems — authentication, privileged access, network perimeter, high-sensitivity applications — are logged to a state-operated or state-managed SIEM. Smaller agencies and lower-priority systems use managed services or existing tools with defined minimum standards. This approach manages cost while ensuring centralized visibility for the highest-priority targets.
The choice depends on the state's existing IT consolidation posture, available budget and staffing, and the timeline of other security investments. A state that is implementing zero trust controls across its major agencies in the next 18 months needs log infrastructure that can support continuous monitoring of those controls before the controls go live — not on the same schedule, but ahead of it.
The sequencing decision
Zero trust marketing and log infrastructure decisions are being made on parallel tracks in many states. Procurement for identity tools, micro-segmentation, and conditional access platforms is proceeding while log infrastructure sits in a later budget cycle. The operational consequence is that the controls go in but the analysis layer is not ready to confirm they are working. Detection of a sophisticated intrusion that circumvents a newly deployed control relies on the log infrastructure being able to see the circumvention.
The sequencing argument is not that log infrastructure must be complete before any zero trust investment begins. It is that states should map which zero trust controls they are deploying, what log sources those controls depend on for continuous monitoring, and whether that log infrastructure will be in place when the controls become operational. Gaps in that alignment are not budget-cycle slippage — they are security architecture gaps that leave deployed controls unmonitored.
State CISOs who have submitted zero trust transition plans to their executive leadership or to CISA under SLCGP program requirements should be explicit with those stakeholders about the log infrastructure dependency. A transition plan that shows zero trust control milestones without corresponding log infrastructure milestones is describing half an architecture.
Sources and further reading
- NIST SP 800-92: Guide to Computer Security Log Management (September 2006)
- NIST SP 800-207: Zero Trust Architecture (August 2020)
- CISA Zero Trust Maturity Model v2.0 (April 2023)
- OMB M-21-31: Improving the Federal Government's Investigative and Remediation Capabilities Related to Cybersecurity Incidents (August 2021)
- CISA State and Local Cybersecurity Grant Program
- Infrastructure Investment and Jobs Act, Section 70612 (Public Law 117-58, November 2021)
Spartan X's security advisory work with state government clients consistently surfaces the log infrastructure gap as a constraint on more ambitious security programs. Designing a log architecture that is proportionate to a state's risk profile and operational structure — and sequencing that investment relative to zero trust, AI-enabled monitoring, and SOC capability development — is the kind of technical planning work where experienced practitioners who have worked through these decisions operationally provide more useful guidance than a vendor's platform roadmap.
