Why an open source SIEM for public sector starts with the logging tiers
An agency security lead has to answer three questions before choosing a self-hosted SIEM: can the logs be produced for oversight, can the agency SOC search them from one central place, and can the platform run inside an accredited or air-gapped boundary. The sizing baseline comes from the OMB M-21-31 event logging tiers and the retention requirement of 12 months active plus 18 months cold. Confirm the agency's assigned tier and its authorization boundary first, because those decide the event volume, the log sources in scope and the storage the platform must hold. A change in tier can mean resizing indexes and storage, so the tier record should be settled before any hardware is quoted.
On the short answer, Wazuh fits broad host coverage and compliance reporting. Its agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, its dashboard includes prebuilt views for NIST 800-53, and its offline installation guide covers systems without internet connectivity. Security Onion fits network-centric monitoring, combining Suricata and Zeek with Elastic Fleet agents, and its airgap documentation covers full installs on networks without internet access. Security Onion 3 supports only Oracle Linux 9 and x86-64 processors, so an agency standardized on another distribution must confirm that constraint before selecting it. Both are candidates only after the agency confirms its tier and boundary, and the final design may combine them.
Map the NIST SP 800-53 AU (audit and accountability) and SI (system and information integrity) control families to the confirmed tier before writing the design. Ask the authorizing official and the assessor which AU and SI controls apply at the agency's baseline, since the low, moderate and high baselines select different numbers of controls. Also confirm whether the SOC sits inside the same accreditation boundary as the logs, and whether any cloud component would fall under FedRAMP scope. Record the answers in a written tier and boundary statement, because every sizing figure, retention setting and access rule downstream depends on it. Any partner quote should reference that statement directly.
Which public sector requirements shape the SIEM build
This table maps the public sector requirements that most affect a self-hosted SIEM to what each one means for the build and the evidence an assessor will ask for. Read each row against your system categorization and authorizing official's decision, since the applicable baseline and overlays set the actual control set.
| Requirement | What it means for the SIEM build | Confirm with your authorizing official |
|---|---|---|
| NIST SP 800-53 Rev. 5 AU family (audit and accountability) | Define which events each in-scope system must log, set retention, protect log integrity and alert on audit processing failures. The SIEM itself becomes an in-scope system holding audit records. | Which events, retention periods and review frequency your baseline requires, and whether the SIEM inherits controls from the agency enterprise |
| NIST SP 800-53 Rev. 5 SI family (system and information integrity) | Feed monitoring tools with system alerts, malicious code and intrusion indicators, and tie detection output to flaw remediation and incident response records. | Which SI enhancements apply, and how alerts map to the agency incident handling process |
| SP 800-53B baselines: low (149), moderate (287), high (370) | The baseline selected for the system sets how many controls and enhancements the SIEM and its log sources must satisfy. Higher baselines add encryption, redundancy and more detailed review requirements. | Which baseline applies to the system the SIEM protects and to the SIEM itself, using the Release 5.2.0 profiles |
| FISMA oversight by Inspectors General | Inspectors General independently assess agency system security and report to OMB, so the SIEM must produce logs, review records and alert histories that an independent assessor can sample. | What evidence format and sampling period the agency IG and CIO office expect |
| FedRAMP scope under OMB M-24-15 | A cloud-hosted SIEM that collects or stores federal information on behalf of an agency falls within FedRAMP scope. A single-agency system on cloud infrastructure that is not offered as a shared service may fall outside it. | Whether the hosting cloud and the SIEM service carry a FedRAMP authorization, and whether the agency treats the deployment as in scope |
| FBI CJIS Security Policy v6.1 (effective 26 June 2026) | Logs that contain or describe criminal justice information need FIPS 140-3 validated cryptographic modules or AES with at least 256-bit keys in transit and at rest outside physically secure locations. Vulnerability scanning must run at least monthly across the SIEM and its hosts. | Which CJIS requirements apply to log content, and which FIPS 140-3 module certificates your chosen components use |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 for CUI | When a federal agency requires CUI protection on a non-federal system, NIST SP 800-171 is the default set of requirements unless the CUI category prescribes other safeguards. Contractor-operated SIEMs holding CUI logs fall under this rule. | Whether the CUI category sets its own safeguards, and which contract clauses govern log storage by a contractor or partner |
Which open source SIEM platforms fit agency SOCs and why
Agency SOCs usually choose between a host-based and log-centric platform, a network-focused sensor stack, and the licenses that legal must clear for each. The cards below separate the components, the deployment and offline limits, and the licensing questions that decide which combination an agency can run and defend under NIST SP 800-53 audit and system integrity controls.
Wazuh as the core log and detection layer
Wazuh is distributed under GPL-2.0, and its four components are the indexer, the server, the dashboard and the agents on endpoints. The dashboard includes prebuilt views for NIST 800-53, which helps map collected events to audit and system integrity controls. Confirm with your environment that the agent coverage (Linux, Windows, macOS and others) matches your server fleet, and that agentless syslog collection covers firewalls and devices that cannot run agents.
Wazuh offline operation for restricted networks
Wazuh documents an offline installation guide for systems without internet connectivity. Vulnerability detection can run from an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Agencies with classified or isolated enclaves should confirm how they will refresh that repository, who approves each import, and how the import is logged as evidence.
Security Onion and its Elastic License 2.0
Security Onion is licensed under the Elastic License 2.0, a source-available license rather than an OSI-approved open source license. Agency legal should approve that license before any deployment, including whether modifications and redistribution to contractors are permitted. Security Onion 2.4 reached end of life on October 1, 2026, so any new deployment should start on the 3.x line, which supports only Oracle Linux 9.
Security Onion Distributed deployment
The Distributed deployment, with a manager node, sensor nodes and search nodes, is the recommended design for production. The architecture documentation warns that if the manager goes down, search nodes stop indexing because they cannot reach Redis, so receiver nodes and manager resilience belong in the design review. Confirm that the agency's hardware meets the minimums for each node type and that x86-64 processors are available.
Security Onion Pro for agency governance
Security Onion Pro is a paid edition sold on 1 to 5 year terms. It adds OIDC single sign-on to the Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance and professional support. For agencies that must show FIPS-validated cryptography and STIG-aligned hosts, confirm the exact module status and the scope of support in the written quote, because the free edition does not include these features.
Suricata and Zeek as sensor components
Suricata is a GPL-2.0 intrusion detection and network security monitoring engine, with version 8.0.7 published on September 15, 2026. Zeek is a network analysis framework under a BSD-style license, with version 9.0.0 published on August 21, 2026. Both feed network evidence into the SIEM rather than acting as a full SIEM alone. Agencies should confirm sensor placement, packet capture storage and whether Zeek logs need separate retention under the agency's records schedule.
Deployment patterns for agency SOC access and log tiers
Agency SOC designs differ mainly in how the SIEM scales, how its components depend on one another, who can reach the logs, and where older records sit. The cards below cover the Wazuh and Security Onion layouts that support those decisions, the failure modes to plan around, and the hot and cold storage split that a 12 month active and 18 month cold target implies.
Clustered Wazuh server and indexer
The Wazuh server can run as a cluster for horizontal scaling, and it pushes agent configuration and upgrades from a central point. The Wazuh indexer stores alerts, so ingest growth shows up there first. Confirm how many agents and daily events the agency expects, how the indexer nodes are sized, and whether the cluster will run in a boundary network with no internet access. Plan an upgrade path for the 4.14 line, which has shipped patch releases roughly every one to two months.
Security Onion distributed design
The Distributed deployment type, with a manager node, one or more sensor nodes and one or more search nodes, is the recommended design for production. Sensors capture network traffic close to the monitored segments, while search nodes hold indexed data for the SOC. Confirm the number and placement of sensors for each enclave, the minimum hardware for each role, and that every platform component is x86-64, since Security Onion does not support other processors.
Manager dependency and indexing stops
In a Security Onion distributed design, search nodes stop indexing if the manager goes down because they cannot reach Redis. For an agency SOC, this means one manager outage can halt search and investigation across every sensor's data. Ask the implementation partner how the manager is protected, how it is restored, what backup and rebuild steps are documented, and how the SOC would handle alerts during an outage. Document the recovery time target in the agency's own continuity plan, not in the vendor's default settings.
Receiver nodes for pipeline redundancy
The Security Onion architecture documentation notes that receiver nodes add pipeline redundancy and load balancing. For public sector sites with many log sources or remote offices, receivers keep collection running when a single ingest path is busy or unavailable. Confirm which receiver layout the chosen Security Onion version supports, how log forwarders fail over between receivers, and how receiver traffic is protected in transit. Test failover against real log sources before the SOC depends on it.
Centralized SOC access through single sign-on
A shared SOC needs one place to grant, review and remove analyst access, which points to single sign-on tied to the agency directory. Wazuh documents single sign-on for its user administration. Security Onion Pro adds OIDC single sign-on to the Console as part of a paid edition. Confirm which identity provider the agency uses, whether the SIEM console supports the required protocol in its edition, how role mapping works for analysts and administrators, and how emergency local accounts are controlled and logged.
Hot and cold storage tiers
The target split is 12 months of active, searchable retention and 18 months of cold retention. Hot indices serve daily investigation, while cold data stays available for audit requests at lower cost. The split must be written into index lifecycle rules and storage sizing before deployment. Confirm which tier the Wazuh indexer or Security Onion search nodes use for each period, how cold data is restored and searched, who can access it, and how deletion is logged. Ask for these settings in writing so the agency can show auditors how retention is enforced.
How a public sector SIEM rollout moves from boundary to evidence
This sequence takes an agency from a confirmed logging tier and system boundary to a SIEM that produces assessable evidence for NIST SP 800-53 AU and SI controls, with each phase closing on a named output.
Confirm the logging tier and system boundary
The agency's security lead, system owner and DeployOpen's architect agree which information systems fall inside the SIEM boundary, which logging tier applies to each, and which systems are cloud services that must meet FedRAMP scope tests before they send data. Confirm whether the SIEM itself will hold federal information, since that determines the hosting and authorization questions that follow. The output is a signed boundary and log source inventory with the controls each system inherits or owns. Confirm the current OMB logging requirements with the agency's CIO office, because this page does not restate them.
Size ingest and storage for the retention split
Using the log source inventory, the team estimates daily ingest per source, then divides storage into an active tier that stays searchable and a cold tier that holds older records for the retention period the agency's policy and assessor require. Compute and storage sizing scale with ingest rate, index replicas and search load, so the team also sets the Wazuh indexer or OpenSearch node count and the Security Onion topology, including whether a distributed design is needed for production. Hardware minimums for Security Onion nodes are published in the vendor documentation, and the team checks them against the estimate. The output is a sizing workbook with ingest, storage and node assumptions that the agency signs off on.
Build the isolated environment and offline media
DeployOpen's engineers build the SIEM inside the agency's approved network segment, using the agency's hypervisor, data center or accredited cloud account. Where the segment has no internet access, the team installs from offline media: Security Onion airgap ISO packages and rule sets, or the Wazuh offline installation guide with an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Access to the management plane, time sources and update channels is restricted to named administrators. The output is a running, hardened environment with a documented update path, verified by a rule and package version inventory that matches the media used.
Onboard priority log sources and time sources
The team connects the highest priority systems first: identity and authentication logs, administrative actions, firewall and boundary devices, and key application servers. Agents are deployed where the platform supports them, and agentless devices send syslog. Every source is checked for consistent time synchronization against the agency's approved time source, and timestamps are verified in the dashboard. The output is a source-by-source onboarding record showing that each system is sending events, its parsing status and its time offset, which feeds the AU control evidence later.
Write and tune detections and map dashboards to AU and SI
DeployOpen's detection engineers write or adapt rules for the agency's threat scenarios, set alert thresholds, and suppress known benign noise with documented tuning decisions. Alerts are routed to the agency SOC queue and to audit failure notifications, so a stopped log source or full storage raises an alert. Wazuh's regulatory views, including the NIST 800-53 view, and Security Onion's detection management are configured to map events to AU and SI control families. The output is a versioned detection set, a tuning log and dashboards that show which control each view supports.
Centralize access for the agency SOC
The agency's identity provider and role model are connected to the SIEM so analysts sign in with unique accounts, receive least-privilege roles, and access to log data is limited to the teams that need it. Administrative actions on the SIEM are themselves logged and forwarded to the same tier. The output is a role matrix, a test record showing that analysts can search but not change retention or rules without approval, and an access review schedule the agency adopts.
Run an assessment dry run
Before the assessor arrives, DeployOpen and the agency's compliance lead walk through the controls as an assessor would: pulling sampled audit records, showing time synchronization, demonstrating alert handling and showing that logs cannot be altered by ordinary administrators. Gaps are logged with owners and fixed or formally accepted. The output is a readiness report that lists each AU and SI control, the artifact that supports it, and any open finding. DeployOpen prepares this evidence but does not issue an assessment result, which comes from the authorizing official and independent assessors.
Hand over runbooks and evidence packs
DeployOpen delivers operating runbooks for log onboarding, rule changes, upgrades, backups, offline update procedures and incident handling, and packages the evidence set the agency will keep for each assessment cycle. Training is provided to the agency SOC on the runbooks and the dashboards. Support and upgrade coverage after go-live are agreed separately in writing, usually as a retainer. The output is an accepted handover package and a named owner for each runbook inside the agency.
Evidence assessors and inspectors general ask for from the SIEM
This table lists the records an assessor or inspector typically asks to see from a self-hosted SIEM, which component produces each one, and where the evidence tends to be thin. Use it to plan what the platform must retain and export before an assessment begins. DeployOpen prepares these systems, controls and records for your assessment, but it does not issue any audit report, attestation or certification.
| Evidence item | Producing component | What the assessor checks | Where it usually fails |
|---|---|---|---|
| Audit log configuration records | Wazuh server and agent configuration, Security Onion manager and Elastic Fleet policies | Which sources are enabled, which event types are captured and that changes are logged | Agent groups drift from the documented baseline and changes are made without a record |
| Retention settings and index lifecycle policies | Wazuh indexer or OpenSearch index lifecycle management, Security Onion Elasticsearch settings | Hot period, cold or archive period and deletion rules match the agency's stated requirement | Policies exist in the console but no exported copy or change history is kept |
| Access records for SOC accounts | Wazuh dashboard and API logs, Security Onion Console audit trail, Keycloak or other SSO admin events | Named accounts, role assignments, logins and privileged actions are attributable to individuals | Shared analyst accounts or local accounts bypass the central identity provider |
| Alert and review records | Wazuh alerts index and case workflow, Security Onion Console alerts and Detections history, ticketing system | Alerts were generated, triaged and closed with a reviewer and a timestamp | Reviews happen in chat or email, so no durable record links alert to decision |
| Time synchronization evidence | Time source configuration on the Wazuh server, indexer, agents and Security Onion nodes | All components use an authorized time source and clock drift is monitored | Virtual machines or sensors on isolated networks have no documented time source |
| Integrity controls for stored logs | Indexer or cluster snapshots, hash or signing workflow, restricted write roles | Stored logs cannot be altered or deleted by ordinary SOC or administrator roles | Retention relies on the same administrators who can edit or purge the index |
| FIPS and encryption configuration | Operating system and cryptographic module settings, TLS settings on the indexer, dashboard and agents, Security Onion Pro FIPS mode and LUKS encryption | Modules and key lengths match the agency's cryptographic requirement for data in transit and at rest | FIPS mode is assumed rather than verified, and Pro-only features are assumed to be in use without a license record |
What public sector teams ask before a self-hosted SIEM build
What drives the cost of a self-hosted SIEM for an agency?
Cost follows daily ingest volume, how long logs stay searchable and archived, the hardware or virtual capacity that stores and searches them, and the detection engineering time needed to write and tune rules. Storage and compute scale with ingest and retention, so an agency that keeps logs for the full period its tiers require pays for more capacity than one that keeps only recent data hot. Paid editions add cost. Security Onion Pro, for example, is sold on 1 to 5 year terms and adds OIDC single sign-on, LUKS encryption, FIPS mode and professional support. Ask any quote to separate one-time build work from recurring hardware, licensing, support and rule maintenance, and to show the ingest and retention assumptions behind each line.
How long does a self-hosted SIEM build take in government?
The duration depends on the number of log sources, how many sites and enclaves the SIEM must reach, the boundary and approval steps the agency runs, and whether the team is starting from an existing tool. Agencies usually lose the most time to approvals, network changes and access to source systems rather than to installing the platform. Fixed-scope work starts with a written scope that lists sources, deliverables and milestones, so the timeline can be agreed before work begins. Ask for the schedule to be tied to named dependencies such as firewall change windows and authorization reviews, not only to installation dates.
What must the agency supply before a SIEM project starts?
The agency has to make boundary and placement decisions, grant access to log sources, approve network flows and provide staff who can act on decisions. In practice that means:
- A system boundary decision that names which enclaves, cloud accounts and sites send logs
- Named owners for each source, such as identity, endpoint, network and application teams, with change access
- Approvals for collection paths, service accounts and any storage location for logs that contain personal or case data
- Staff time from the SOC, system owners and the security authorization office for review and sign-off
Missing items in these four areas are the most common causes of delay, so confirm them before the scope is signed.
Can our internal staff run a self-hosted SIEM after go-live?
Internal staff can run it if they have the skills and time to operate the platform, tune detections and handle upgrades, but those tasks are continuous and need named people. Wazuh, Security Onion and the OpenSearch-based platforms each need someone who can manage indexes, storage, agents or sensors and rule changes. Operating a SIEM also means reviewing alerts on a schedule that an auditor can sample. Ask whether the agency wants full in-house operation, a partner who implements and hands over documentation, or a retainer for ongoing support and upgrades. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the split of duties should be written into the scope.
Does FedRAMP or CJIS apply to a SIEM run by an agency?
FedRAMP usually does not apply to a SIEM that an agency operates for its own use on its own infrastructure, because FedRAMP's scope covers cloud products and services offered to agencies, and single-agency systems on cloud infrastructure that are not offered as a shared service are out of scope. CJIS does apply when the SIEM collects or stores criminal justice information. Under CJIS Security Policy version 6.1, which took effect on June 26, 2026, CJI in transit and at rest outside physically secure locations requires FIPS 140-3 certified modules or AES with at least 256-bit keys, and vulnerability scanning at least monthly. Confirm with the agency's CJIS Systems Officer and its FedRAMP program office whether any log data is CJI and whether any cloud service is involved.
How do upgrades and the Security Onion 2.4 end of life affect planning?
Security Onion 2.4 reached end of life on October 1, 2026, so any deployment still on 2.4 needs a path forward. Installations on Oracle Linux 9 can upgrade to 3 after full packet capture moves from Stenographer to Suricata, while other distributions need a fresh install. Security Onion 3.0.0 was released on March 31, 2026 and supports only Oracle Linux 9, and the latest tagged release is 3.3.0, published September 11, 2026. Wazuh follows a 4.14 patch cadence, with 4.14.9 released October 14, 2026. Plan for recurring patch windows, a test environment, and an upgrade budget in the retainer or internal plan. Ask the partner to show how upgrades are rehearsed, rolled back and documented for the authorization file.
Which NIST SP 800-53 controls should a SIEM evidence first?
The audit and accountability family (AU) and the system and information integrity family (SI) carry most of the SIEM's evidence. AU controls cover what events are logged, how log storage is protected, how audit failures are alerted, and how logs are reviewed and reported. SI controls cover monitoring of system events and malicious code and alerting on indicators of compromise. The control baselines differ in how many enhancements apply: SP 800-53B selects 149 controls and enhancements for low, 287 for moderate and 370 for high. Ask which baseline the agency's system is categorized at and map each AU and SI control to a specific log source, rule or report. The Wazuh dashboard includes a NIST 800-53 view that can help organize the mapping, but the agency's assessor decides what counts as sufficient.
Does a SIEM for agency logs need Wazuh or Security Onion?
Choose the platform by the sources, sensors and operating model the agency needs, not by brand. Wazuh combines host-based agents, a log analysis server, a search indexer and a dashboard, and it supports agentless syslog collection for devices that cannot run an agent. Security Onion bundles network monitoring with Suricata and Zeek, with an Elastic-based stack, and it requires x86-64 hardware and a Linux distribution that the project supports. Security Onion is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved, so check that license against the agency's procurement rules. Many agencies compare both during a design review and decide whether network sensors, endpoint agents or both are needed first.
What to ask an implementation partner for an agency SIEM
Start by asking for the written scope, deliverables and acceptance criteria before any work begins. For an agency SIEM, acceptance should be tested against the retention and access rules you already carry, not against a generic checklist. Ask the partner to show, in writing, how daily ingest was estimated for the 12-month active tier and the 18-month cold tier, which index lifecycle settings move data between them, and how the sizing changes if a log source is added later. Ask how they prove immutability to an auditor, including where the cold copies live, who holds the keys, and how a test restore is recorded. Confirm that the partner will support the retention evidence your Inspector General or assessor will sample, rather than only the dashboard view.
Next, press on the encryption, access and detection questions that CJIS-scoped and federal systems raise. Ask whether the partner will configure FIPS-validated cryptography for transport and storage and how they confirm the modules named in the CJIS Security Policy version 6.1 requirements apply to the components you run, including the Wazuh indexer and dashboard or the Security Onion FIPS mode, which is a Pro edition feature. Ask who writes and tunes detections, who approves suppressions, and whether the rule changes are logged. For offline operation, ask how they deliver updates for an airgapped enclave: whether Security Onion soup updates arrive from new ISO media, and how Wazuh offline vulnerability data is refreshed. Request the update cadence in writing.
Finally, ask how upgrades and post-go-live support are handled. Ask how the partner tests each Wazuh 4.14 patch release before it reaches production, and how they treat the Security Onion 2.4 end-of-life date and any move to a 3.x major version, including whether a fresh install is required on your distribution. Ask who holds the on-call and patch responsibilities after acceptance, what the support hours and response targets are in the signed agreement, and how the partner documents changes for your change board. Confirm all figures against the signed proposal, because DeployOpen does not publish a price list and quotes follow from the written scope.
