Open source SOAR for public sector

Open source SOAR for public sector: why government SOCs need different playbooks

A public body with a small security operations center, national reporting duties and data that cannot leave its jurisdiction needs automation that it can host, change and audit itself. Self-hosted Shuffle fits that situation: it can automate alert triage, enrichment and reporting steps while the agency controls where the platform runs, who changes each playbook and what evidence the workflow keeps. Shuffle is licensed under AGPL-3.0, so the agency can review the code and deploy it inside its own accounts or data center, and the platform typically sits beside sources such as Wazuh for detection, MISP for indicator sharing and Keycloak for single sign-on.

Public sector playbooks differ from commercial ones because the agency often does not decide alone who gets told about an incident and when. Reporting may run to a national CSIRT or to CISA, depending on the agency's jurisdiction and mandate, and the frameworks behind its systems may be FISMA with NIST SP 800-53 controls or a national equivalent. Inspectors General review federal system security under FISMA, so the agency needs to show how each automated step was approved and recorded. Where the data is controlled unclassified information (CUI) or criminal justice information (CJI), the enrichment apps that send indicators to external services may themselves be a compliance question. Confirm with your reporting authority and your assessor which notification timelines apply to you, because this page does not set them.

Before building anything, agree three decisions with your legal and compliance leads: which actions the platform may take without a human approval gate, which data may leave the boundary for enrichment, and who owns each playbook version after go-live. Record those answers as change-controlled configuration, not as tribal knowledge. Also confirm how Shuffle's saved app credentials are protected, since the SHUFFLE_ENCRYPTION_MODIFIER secret must be preserved for the lifetime of the platform, and whether your identity provider supports the OpenID Connect sign-on that Shuffle documents. Those checks determine whether the automation you build will still be defensible when an auditor or Inspector General asks for it.

Which public sector rules shape the SOAR build

This table maps the federal and criminal justice frameworks that most often reach an agency SOC automation build to what each one means for playbook data, credentials and logs. Read each row as a question to settle with your authority and assessor before the first playbook is built, since the applicable set depends on your agency's systems and data.

Framework	What it asks for	What it means for the Shuffle build
NIST SP 800-53 Rev. 5 baselines	Low, moderate and high baselines under SP 800-53B select 149, 287 and 370 controls and enhancements; Release 5.2.0 is current.	Confirm the impact level of the systems Shuffle touches. Map playbook actions to the access control, audit and incident response families your baseline selects.
FISMA and Inspector General review	Inspectors General independently assess agency system security and report to OMB.	Keep playbook versions, change records and run histories so an IG reviewer can trace what automated actions ran and who approved them.
NIST SP 800-171 via 32 CFR 2002.14(h)(2)	Where agencies set requirements for CUI on non-federal systems, NIST SP 800-171 applies unless the CUI category prescribes other safeguards.	If a contractor or partner hosts a Shuffle worker or case data holding CUI, confirm that host's scope and encrypt stored app credentials and logs accordingly.
FedRAMP scope under OMB M-24-15	Cloud products that create, process, store or maintain federal information on behalf of an agency fall in scope. Single-agency systems on cloud infrastructure, not offered as a shared service, are out of scope.	Any cloud-hosted Shuffle component, such as a managed backend or a cloud-hosted Orborus, needs a scope decision. Confirm with your authorizing official whether a FedRAMP authorization is required.
CJIS Security Policy v6.1 (effective 26 June 2026)	Requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly.	Playbooks that pull criminal justice data into enrichment need encrypted transport, AES-256 for the SHUFFLE_ENCRYPTION_MODIFIER secret, and monthly scans of the Shuffle hosts. Confirm FIPS validation of each module with your CJIS system officer.
Credential storage and key handling	Agency policy and the frameworks above expect strong key management and controlled access to connector credentials.	Shuffle encrypts saved app credentials with AES-256, but losing or changing the modifier breaks every saved authentication. Document key custody and recovery before go-live.
Log retention and audit trail	Audit controls and retention periods come from the agency's baseline and records schedule, not from the platform.	Set retention for workflow execution records, case notes and approval decisions to match your records schedule. Confirm the period with your records officer rather than the vendor default.
National CSIRT or CISA reporting	Reporting deadlines, formats and recipients are set by the national authority and the agency's own policy.	Confirm required deadlines and submission channels with your national CSIRT or CISA contact before building report steps. Do not hard-code timelines from other sectors.

Which open source platforms fit a government SOC

A government SOC automation stack usually combines an alert source, network signals, a threat intelligence exchange and an identity layer that controls who can run or change playbooks. Each component below does one job, and none of them removes the need to confirm connectors, sharing rules and access design in your own environment before you commit.

Shuffle as the automation layer

Shuffle is the orchestration layer that runs enrichment and response playbooks. It is licensed under AGPL-3.0, and its app catalogue and custom apps are built from OpenAPI specifications or the Python app SDK, each running as a versioned Docker container. Licensing is tied to app runs rather than users, so workflows that call many actions will drive cost. Confirm whether an app already exists for each agency tool, such as your ticketing system or the CSIRT reporting portal, and who maintains custom apps after go-live.

Wazuh as the alert source

Wazuh supplies endpoint and host telemetry that feeds triage playbooks. Its core repository is licensed under GPL-2.0, and it combines XDR and SIEM capabilities in one platform. Playbooks should be built around the alert rules your agency actually tunes, not default rule sets. Confirm how alerts are forwarded to Shuffle, whether a native connector or a webhook is used, and how alert volume is kept within the run limits you plan for.

Security Onion, Suricata and Zeek

Network sensors give the SOC signals that host logs cannot show. Security Onion bundles Suricata, Zeek, osquery and the Elastic stack, under the Elastic License 2.0, so its licensing terms differ from the GPL and AGPL components around it. Suricata (GPL-2.0) handles intrusion detection and Zeek provides protocol-level network records. Sensor placement depends on the segments an agency can mirror, and the sensors must be inside the accreditation boundary. Confirm license obligations with counsel before embedding these outputs in a shared service.

MISP for indicator exchange

MISP carries indicators to and from trusted communities. It is licensed under AGPL-3.0, is associated with CIRCL, and supports distribution levels and sharing groups down to individual attributes, plus exports such as STIX 1 and 2, Suricata and Zeek. For a government SOC, sharing rules often come from national or sector CSIRT agreements rather than from the tool itself. Confirm which sharing communities your agency may join, whether MISP 2.5 is the version your operations team will run, and how indicators are reviewed before they trigger automated blocking.

Keycloak or midPoint for access to Shuffle

An identity provider decides who can run, edit and approve playbooks. Keycloak (Apache-2.0) supports OpenID Connect, which Shuffle uses for per-tenant single sign-on, and midPoint adds identity governance where access reviews and joiner, mover and leaver processes are required. Keep playbook editing rights separate from run rights, and confirm that break-glass accounts exist outside the SSO path. Check whether your agency's directory is Active Directory or another source, and whether MFA is enforced at the identity provider before any playbook can change a control.

How a public sector SOAR rollout runs

The sequence moves from deciding what must be reported and where regulated data lives, through a hosting boundary and a self-hosted Shuffle deployment, to tested playbooks and change-approved response actions. Each phase closes with a document, configuration baseline or test record that the agency's security and compliance owners can review.

Map reporting bodies and regulated data
The agency's incident response lead, legal counsel and compliance owner list every body that receives incident reports, such as a national CSIRT, CISA or a state or sector regulator, along with the deadline and format each one requires. In the same exercise they identify which systems hold criminal justice information or controlled unclassified information and which contracts flow requirements down to the agency. The output is an authority and data map that names each report, its recipient, its trigger and the systems in scope. Confirm each requirement against the current text of the governing rule, since reporting obligations differ by jurisdiction and change over time.
Decide hosting and the security boundary
Using the authority and data map, the agency decides where Shuffle and its supporting services run: on agency-owned infrastructure, in a government cloud region, or in a hybrid model where only a local Orborus worker sits inside the boundary. This decision determines which cloud authorizations, encryption modules and vulnerability scanning cadence apply to the SOAR platform itself, because a system that stores or processes sensitive data inherits those obligations. The output is a signed boundary decision record listing hosting location, data flows, network paths and the compliance frameworks that apply. Confirm with the agency's authorizing official and counsel before any build starts.
Deploy Shuffle on agency infrastructure
The implementation team deploys Shuffle on the agency's chosen platform using one of the documented architectures: a single server with Docker Compose, distributed Docker Swarm, or Kubernetes with Helm charts. The team sets the encryption modifier used to protect saved app credentials, records where it is stored, and configures OpenSearch, backups and, for high availability, multiple Orborus nodes and a shared cache as the architecture docs describe. Each change is captured in version-controlled configuration. The output is a configuration baseline and a deployment record that show the chosen architecture, component versions and the location of the encryption secret. Confirm the exact version pin and Docker tag policy before deployment, since the docs recommend different tags for stable and experimental use.
Integrate identity and access controls
The agency connects Shuffle to its workforce identity provider using OpenID Connect or SAML, enforces single sign-on for every user, and assigns roles so that only designated responders can edit or approve workflows. Local administrator accounts are restricted and documented, and the team confirms that authentication events and administrative actions are logged to the agency's central log store. Access rules are mapped to the requirements from the authority and data map, including multi-factor authentication where applicable. The output is an access control matrix and a test record showing that sign-in, role restrictions and audit logging work as designed.
Build playbooks in a test workflow space
Analysts and engineers build playbooks first in a separate test environment with non-production connectors and sample alerts. Each playbook is tied to a specific reporting obligation or incident category from the authority map, and each step that touches a production system is marked for review. Integrations to the SIEM, case system and threat intelligence platform are tested with read-only actions before any write action is enabled. The output is a playbook register listing each workflow, its owner, its triggers, its connected apps and the test results that show the expected outputs, including the evidence it collects for reporting.
Promote response actions through change approval
Any workflow that changes a production system, such as isolating a host, disabling an account or blocking an address, moves to production only through the agency's change control process. The change record names the reviewer, the approval gate inside the workflow, the rollback step and the systems affected. Enrichment and notification actions may follow a lighter path if the change board agrees. Promotion is performed by a designated administrator rather than by the workflow author. The output is a change record for each promoted workflow and a log of approvals that an auditor can sample.
Run a tabletop exercise against the response plan
The agency runs a tabletop exercise that walks through a realistic but fictional incident scenario, using the agency's incident response plan as the script. Participants trigger the production playbooks in the test environment, check whether reports are drafted for the right bodies within their required timelines, and identify gaps in roles, approvals and evidence capture. Findings are assigned owners and tracked to closure. The output is an exercise report with a timeline, the decisions taken, the gaps found and the corrective actions, which becomes evidence of testing for the incident response plan.

What auditors and inspectors ask for from automated response

Which playbook version ran during an incident, and can you prove it?

The record of which workflow ran is held in Shuffle's OpenSearch document store, where each workflow execution is stored with its workflow identifier and the state of each action. Shuffle's documentation describes workflows as versioned objects that can be exported, so the agency should keep exported copies of every production workflow in its own version control system and tie each export to a change ticket. Auditors usually ask for the exact definition that was active on the incident date, not the current one, so the agency must confirm how long execution records and workflow exports are retained under its own records schedule.

How do approvals for destructive response actions get recorded?

Shuffle workflows can pause at a user input step, and the approver's response becomes part of the execution record that OpenSearch stores. Actions such as isolating a host, disabling an account or blocking an address should only run after an approval step has recorded who approved, when, and what they saw. The agency should confirm that its SOC runbook names the roles allowed to approve each action class, and that approver identities come from its central identity provider rather than shared accounts, so the approval can be tied to a named person during an inspection.

What does the audit trail of automated steps contain?

For each execution, the record should show the trigger, each action called in order, the inputs and outputs of those actions, the result of any conditional branch, and the timestamps. Shuffle stores this execution data in OpenSearch, and the connected tools (SIEM, EDR, identity provider) keep their own logs of the changes they received. An inspector will want both sides to agree. The agency must confirm which fields it needs to retain, whether any of them contain personal data that requires redaction, and how long OpenSearch indices are kept before rotation.

How are credentials for connected tools protected and recovered?

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the value of the SHUFFLE_ENCRYPTION_MODIFIER setting as the secret. The documentation warns that losing or changing this value breaks every saved app authentication, so the value must be stored in a secrets manager, backed up separately from the OpenSearch data, and recorded in the change process before any rotation. Restoring OpenSearch without the matching modifier leaves encrypted credentials unreadable. The agency should test a restore into a non-production environment and keep the evidence of that test.

How is change control on playbooks recorded?

Change control is produced by the agency's own process, supported by the tooling. Each workflow change should go through a ticket that records the requester, the reviewer who tested it in a non-production Shuffle instance, the approver, and the deployment date. Keeping workflow exports in Git gives a diff history, and the ticket number can be written into the workflow description. The Shuffle backend records edits, but it does not replace an approval record, so the agency should confirm with its auditor which evidence set it will accept.

Which component produces each piece of evidence for an inspection?

The evidence comes from several components, and an inspector will ask for each one separately:

Shuffle workflows and execution records, stored in OpenSearch, show which playbook ran and what each action did.
The approval step within a workflow shows who authorized a destructive action.
The SIEM, EDR and identity provider show the effect on the target systems.
The version control system and change tickets show how the playbook was approved and deployed.
The secrets manager records access to SHUFFLE_ENCRYPTION_MODIFIER and its backup.

The agency must confirm its retention periods for each source with its records officer and legal team before the platform is designed.

Can a partner prepare this evidence model for us, and what does that cost?

DeployOpen can plan, implement and document the workflow, approval, logging and backup design for a self-hosted Shuffle deployment within a fixed scope agreed in writing before work starts. Cost depends on the number of playbooks, the connected tools that need custom apps, the approval model, and how many environments must be kept in step. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any partner to show how it will test restores of the encryption secret and how it will document each playbook version.

Deployment options for government data boundaries

A single server running Shuffle under Docker Compose is the simplest model, and it keeps the entire platform, its OpenSearch document database and its workers inside one host in the agency's own environment. For a public body whose residency rules require that case data, enrichment results and stored credentials never leave its facilities, this is often the first option to evaluate because every component sits under one administrative boundary. It fits a pilot, a small SOC or a regional body that automates a limited set of playbooks.

Data location: the backend, frontend, OpenSearch and worker containers all run on hardware the agency controls.
Credential handling: saved app credentials are encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, which must be backed up separately.
Failure domain: one host means one point of failure, so a host outage stops all automation.
Scaling limit: capacity is bounded by one machine, which matters once many workflows run concurrently.
Upgrades: Compose upgrades usually require a maintenance window on the only node.

Confirm with the vendor's current configuration documentation which Docker tag you will pin, and whether your change control accepts a single-node platform for playbooks that take response actions.

How to put change control around automated response actions

An automated containment action needs the same change discipline as any other change to a government system. A playbook that disables an account, isolates a host or blocks an address can cause an outage or a missed mission function just as a firmware change can, and it will be audited the same way. Pin every Shuffle app to a specific version and record which Docker image tag each workflow runs against. Treat the latest tag as a production release channel and reserve the nightly tag for experiments in a non-production instance, since the Shuffle configuration docs describe nightly as experimental. Before promotion, run each changed workflow against test data and a lab environment, capture the results, and have the designated system owner and security lead sign off in your change system. Keep the previous app version and the previous workflow export so you can roll back a failed change without rebuilding it from memory.

Edition limits are a change control issue too. Shuffle states that all features are available in the open-source edition and that the paid tiers differ in feature limits, scaling and support, and since v2.1.1 those limits are actively enforced. Confirm with the vendor and in your own test instance which limits apply to your planned run volume and worker count before a playbook goes live, so an enforced limit does not stop containment mid-incident. Also protect the SHUFFLE_ENCRYPTION_MODIFIER secret as a controlled configuration item. The Shuffle docs warn that changing or losing it breaks every saved app authentication, so changes to it belong in a documented, approved procedure with a tested recovery path, and it should never be rotated casually during a change window.

Put these controls into a written standard that names who may approve a change to a destructive action, who may run an emergency change, and how that emergency change is reviewed afterward. Require an approval step inside any playbook that disables accounts or isolates systems that serve citizens, and log every approval and automated action to the case record. Ask your implementation partner to show how they version apps, how they test workflows before promotion and how they restore a previous state, because an auditor or inspector general will ask for exactly that evidence.

How much effort does public sector SOAR take and can our team do it alone?

What drives the total cost of public sector SOAR automation?

The total cost is driven mostly by the number of playbooks, the number and type of connectors, where the platform is hosted, and how much accreditation evidence the agency needs. Shuffle itself is open source under AGPL-3.0, so the software line is usually not the main expense. The larger costs are the people who design, build, test and maintain playbooks, the infrastructure for the Shuffle server and Orborus workers, and the time spent on change control and evidence for assessors. Ask any partner to price these components separately: playbook count by incident type, connector list with build and maintenance effort, hosting design for high availability, and the evidence package required by your authorizing body. Reporting integrations to a national CSIRT or CISA add scope that should be listed explicitly.

Can our agency's SOC team build public sector SOAR playbooks alone?

Some agencies can, especially where engineers already run Docker, Kubernetes or Linux services and know their SIEM, ticketing and identity tools well. Building a first set of enrichment playbooks is a reasonable in-house task. The harder work is building and maintaining OpenAPI or Python-based apps for each connector, keeping credentials stored correctly, testing workflows before production, and writing change control records for automated response actions. Those tasks require dependable staffing over time, because connectors break when vendors change their APIs. A practical test is whether your team can name an owner for each playbook, a second person who can take over, and a test environment that mirrors production. If not, a fixed-scope engagement for the first playbooks can be combined with internal ownership.

How long does it take to get the first playbook into production?

No fixed duration applies, because the time depends on the conditions that have to be in place before a playbook can run safely. The main drivers are the number of systems the playbook touches, whether service accounts and API credentials already exist, how quickly approvers can be named, and whether the change control process for automated actions is already defined. A read-only enrichment playbook is usually faster to approve than one that isolates a host or disables an account. Ask a partner to show the sequence for your first playbook: connector access, test cases, approval gates, a pilot period and sign-off. Scope and timeline should be written down before work starts.

What does the agency need to provide before a SOAR engagement starts?

The agency has to supply three things that cannot come from the implementer: an authority matrix, a system inventory and a named approver group. The authority matrix defines which automated actions can run without a human, which need approval and who gives it, aligned with incident handling roles in NIST SP 800-61 Rev. 3. The system inventory lists the alert sources, identity providers, ticketing tools and endpoints the playbooks will touch, with owners and access paths. The approver group must be available during business and out-of-hours incidents. Agencies should also provide the reporting obligations that apply to them, such as a CSIRT or CISA reporting path, so the playbooks can be designed around real deadlines.

Does Shuffle licensing change as we add more app runs?

Shuffle's open-source edition includes all features, but the paid tiers differ in feature limits, scaling and support. Shuffle's pricing article says its licensing is based on a single metric, app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Since version 2.1.1, the limits between the open-source and enterprise editions are actively enforced. Agencies should confirm with their procurement team which edition they are using and whether projected run volumes, including scheduled enrichment and high-volume alert handling, stay within the open-source limits. Recheck the current pricing and configuration documentation before you finalize a budget.

Does DeployOpen issue certifications for our public sector SOAR system?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors, assessors and certification bodies perform those functions. For a public sector SOAR deployment, DeployOpen can help configure logging of automated actions, document playbooks and change control records, and organize the evidence your assessor will request. Whether an authorization or accreditation applies to your agency, and at what baseline, is decided by your authorizing official and assessor. Confirm the applicable framework, such as the control baselines in NIST SP 800-53B, before scoping the work.

How DeployOpen scopes and supports public sector SOAR

Public sector SOAR projects touch case records, approvals and reporting obligations that agencies must be able to show later. The four areas below describe how DeployOpen defines the work, where the platform runs, how playbooks are tested, and how the platform is kept current after go-live.

Fixed scope agreed in writing

Each engagement starts with a written scope listing the alert sources, playbooks, connected tools and approval gates to be built. A quote follows from that scope, so the agency can see what is in and out before work begins. Check whether the scope names which automated response actions require a human approver and which reporting templates the playbooks must fill. Ask how changes to scope are handled once work has started.

Self-hosted inside your infrastructure

DeployOpen installs Shuffle in the agency's own cloud accounts, data centers or air-gapped networks, so case data, evidence and credentials for connected tools stay under agency control. Confirm where the OpenSearch document database, the backend and the Orborus workers will run, and whether any worker needs outbound connectivity to reach a national CSIRT or CISA endpoint. Ask who holds the encryption secret used for saved app credentials.

Testing playbooks and integrations

Playbooks and the Shuffle apps that call each tool are security tested before they reach production. The test scope covers the API integrations, the permissions granted to each app account, and the behavior of destructive actions such as host isolation or account disablement. Ask for test evidence per playbook, including the cases where an approval step is skipped or a connector returns an error.

Retainers for upgrades and support

Shuffle releases move quickly, and connected tools change their APIs. A retainer covers version upgrades, connector repairs and ongoing support after go-live, which is separate from the fixed-scope build. Confirm the release tag policy the agency will follow, since the Shuffle docs recommend the latest Docker tag for stable releases. Ask how upgrades are tested in a non-production environment before production changes.

Evidence for assessments, not certification

DeployOpen prepares systems, configuration records, playbook documentation and change logs that an assessor can review. DeployOpen does not issue audit reports, attestations or certifications; independent auditors, certification bodies and the relevant authorizing officials do that work. Agree in the scope which evidence items will be delivered and in what format, so the agency's assessment team knows what to expect.

Open source SOAR for public sector