Security Onion Cases for incident investigation

Analysts should escalate a finding into a case when it needs a shared record of investigation, evidence and decisions, and close or tune it when its cause is known and benign. Make that line explicit before the queue grows. A useful test is whether another analyst would need the reasoning to make the next decision. If the answer is yes, the finding belongs in a case. If the activity is explained and will recur, it belongs in a tuning change instead. Confirm in your installed version which action in Alerts or Hunt creates a case, and whether that action carries over the event fields, the rule that fired and the related events, or whether you must add them by hand.

Findings that usually justify a case include suspected host compromise, lateral movement between internal systems, data sent to destinations your organization does not expect, and rule hits that only make sense with context from several sources. Hunt results that show the same pattern across multiple hosts often belong in one case that groups those hosts, rather than in separate cases per event. Single hits with a clear, approved explanation can be closed with a note. For example, an illustrative nightly backup job that trips a data-volume rule should be closed with the job name and schedule recorded, so the next reviewer can see why it was dismissed.

Tuning happens in the Detections interface, and it determines how much noise reaches Cases. For NIDS rules loaded into Suricata, analysts can modify a rule, suppress it for specified sources or destinations, or set thresholds that control how many matches are needed before an alert is generated. For Sigma rules loaded into ElastAlert, custom filters remove matching events before they produce alerts. Suppression is the most powerful tool and the easiest to misuse. A suppression scoped to one known scanner is defensible. A suppression scoped to an entire subnet can hide the activity you most need to see. Keep each suppression as narrow as the known cause allows, and confirm in your version whether suppressions apply per sensor or across the deployment.

Treat tuning as a controlled change. Record who approved each suppression, threshold or filter, the reason and the review date, and test the change against recent Hunt results before it goes live, so you can see what it removes. Check whether your suppressions, thresholds and custom filters survive updates. Confirm this with the documentation for your release before any upgrade, including a move from Security Onion 2.4 to 3, because the interface and the way rule changes are retained may differ between versions. After each upgrade, review the tuned rules first, since a change that was once correct may no longer match the traffic it was written for.

Observables are the indicators a case is built around, and the choices a team makes about how analysts add, enrich and store them decide whether the case can be trusted later. In Security Onion Cases, observables are typically values such as IP addresses, domains, file hashes and file names, pulled from an alert, a Hunt result or a packet capture and linked to the case. The supported observable types depend on the Security Onion version and configuration in use, so confirm the exact list in your release before writing analyst procedures around it. Map each common observable type to the source it usually comes from in your environment, so analysts know where to copy it from.

Analyzers enrich an observable by sending it to a service and returning the result to the case. Before enabling any analyzer, decide which ones are permitted, who may run them and what each one sends out. Submitting an internal IP address, a hostname or a file hash to an external reputation service is a data disclosure decision that your privacy and legal contacts should approve. Confirm the analyzer catalog for your version, the credentials each analyzer needs, the network egress rules those lookups require and whether results are stored with the case. On air-gapped installs, which Security Onion supports, expect few or no external analyzers, so plan manual enrichment steps instead.

Evidence attachments include items such as exported logs, packet capture excerpts, screenshots and files extracted by Strelka. The case history is the record of what changed, when and by whom. Confirm in your version whether history captures who added, edited or removed an observable or attachment, and whether those entries can be altered or deleted by anyone with case access. Also confirm the file types and size limits the upload accepts. If a full packet capture is too large to attach, the case should instead record the time range, sensor and file location so an investigator can retrieve it from the capture store under the same controls.

Four decisions need an owner before the first live case. First, who may attach raw packet captures or extracted files, since these can contain credentials, personal data or regulated records. Second, whether material must be redacted or minimized before attachment, and who performs that step. Third, how long attachments are kept, measured against the retention set for full packet capture and the search indices, and whether attachments are removed when a case closes. Fourth, which roles can view, edit and export sensitive attachments. Write these rules down, test them with a tabletop case, and confirm each control in the version you run.

Keep a separate case management or SOAR system when the investigation process needs more than a case record in Security Onion. Four situations usually drive that decision: approvals that span several teams, service levels tied to a ticket queue, automated response actions that change systems outside the SOC, and enrichment that pulls from many tools at once. Before you build anything, list which of these apply to your analysts today. If none apply, Security Onion Cases may be enough on its own, and the extra platform is overhead you do not need to run.

Cross-team approvals and ticket-driven service levels are the most common reasons teams add a second system. If legal, IT operations or a third-party provider must approve containment before an analyst acts, the case needs approval steps, owners outside the SOC and timers that keep the request moving. Ask whether your existing ITSM platform already owns the service-level clock and the approval record. In many organizations that system stays the source of truth, and the case in Security Onion holds the investigation evidence and links back to the ticket. Confirm this split with the people who own the ticket queue before you decide.

Shuffle is a security automation platform, and it fits the automation and enrichment cases. Its server side has three parts: a frontend, a Go backend API listening on port 5001, and an OpenSearch document database. Separately, Orborus runtimes poll the backend for jobs and start a worker for each workflow execution, and that worker starts the containers for each app the workflow calls. This split matters for placement. The runtimes need network paths to the systems they act on, and the server needs paths to the analysts and to Security Onion. Map those paths on a diagram before you place either component.

Any integration between Shuffle and Security Onion Cases must be designed and confirmed, not assumed. Confirm with the vendors which interfaces Cases exposes, how authentication works, who owns the service account, and which events can trigger workflows. Shuffle's high availability guidance adds components you will need to operate: an OpenSearch cluster, optionally Memcached for a shared cache, NFS for shared files when several backends run, and more than one Orborus node so workflows continue if one fails. Secrets handling is the second design constraint. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER value. Losing or changing that value breaks every saved app authentication, so store it in your secrets manager and include it in your recovery plan.

Cost and effort depend on how much automation you plan and which edition you need. Shuffle prices licensing on app runs, meaning actions that execute in a workflow, while triggers and skipped actions are not counted. Automation volume therefore drives the recurring cost, and it should be estimated from the workflows you plan to build. Shuffle states that all features are in the open-source edition and that paid tiers differ in limits, scaling and support, so check which limits your workflows will hit. Ask any implementation partner for a written scope that covers the Cases integration design, the high availability layout, secrets handling, workflow testing and handover, and the recurring tasks that follow, such as Shuffle upgrades and OpenSearch maintenance.