Security Onion customization services

What Security Onion customization covers

Customization is the layer you add on top of a working Security Onion grid. It covers custom Suricata, Sigma and YARA content managed through the Security Onion Console Detections interface, Elastic Fleet log source integrations, dashboards in the Console, retention settings and the playbooks analysts follow when an alert fires. The grid itself, meaning the nodes, storage and packet capture, is a separate layer. Keep the two apart when you scope work, because customization assumes the base platform is already stable.

Most teams start customizing for a few predictable reasons: a new network segment comes online and needs sensor coverage, a new log source such as a cloud service or endpoint fleet needs parsing, analysts ask for a view that does not exist yet, retention rules are set by policy, or the organization is moving off another monitoring tool and needs its existing use cases rebuilt. Each trigger creates a different mix of content, integration and configuration work, so list the triggers you expect in the next year before you estimate effort.

The practical split for most organizations is this. Your own analysts handle day-to-day content work, such as adding or adjusting a rule, changing a suppression or updating a dashboard panel. A partner is usually better placed for the first build, for detection and parser design, and for integrations that touch Elastic Fleet and the wider data pipeline. Ask any provider to name which items they own after handover and which your team owns, and to document that boundary in the scope.

What the work includes

Security Onion customization splits into content, data, and operations workstreams. Each one produces an artifact you keep after the engagement ends.

Log source inventory and onboarding

Each log source is listed with its host, network segment, and expected volume, then onboarded through Elastic Fleet integrations. Field mapping is checked against the data as it arrives, so that fields used by dashboards and Sigma rules are populated. Confirm which sources your platform team can enable without network changes.

Custom Suricata, Sigma and YARA content

Custom NIDS rules, Sigma rules and YARA rules are written and loaded through the Security Onion Console Detections interface. Modify, suppress, and threshold actions for NIDS rules are planned with the analysts who will receive the alerts. Confirm which rule sources your team already maintains so that new content does not duplicate them.

Dashboard and saved view design

Dashboards and saved views are designed around the questions your analysts ask during triage and hunting, not around default panels. Each view is documented with its purpose, owner, and the fields it depends on. Check that the views still work after log source changes.

Retention and storage per node role

Retention periods and storage settings are set separately for manager, search, and sensor roles, since each role holds different data. Storage needs follow the sensor placement and link speed chosen for your network. Confirm retention requirements with your legal and compliance owners before settings are applied.

Playbook design for response actions

Response playbooks define which alerts trigger which actions, who approves them, and what evidence is recorded. Automation is scoped to actions your team can reverse. Confirm which playbook features your edition provides before designing workflows that depend on them.

Version-controlled content and change records

Rules, dashboard exports, and configuration are kept in a version-controlled content repository with a change record for each release. Each change names the reviewer and the test grid where it was checked. Confirm where the repository will be hosted and who holds write access.

Edition-dependent features

Some customization depends on the edition you run. The Security Onion API and automation features are listed for Security Onion Pro, so any design that uses them needs a Pro license. Confirm the edition, license terms, and feature list with Security Onion Solutions before scoping automation work.

What drives cost and duration

This table lists the factors that change the effort of a Security Onion customization project, the direction each one pushes cost or schedule, and what to do to keep it contained.

Driver	Why it matters	How to keep it down
Number and parsing complexity of log sources	Each Elastic Fleet integration needs field mapping, parser checks and validation against real events. Effort rises with the number of sources and with how irregular their formats are.	Start with the sources that answer your priority investigations, reuse existing integrations where they fit, and confirm parsing against sample data before onboarding each new source.
Count and type of custom detections	Suricata NIDS rules, Sigma rules and YARA rules each need authoring, testing, suppression and threshold tuning. Sigma rules that depend on fields from unusual sources take longer to validate.	Define a short list of detections tied to specific threats, tune against a baseline period before enabling alerts, and retire rules that generate noise rather than adding them to the backlog.
Dashboard count and number of teams using them	Each dashboard needs design, query checks and access decisions. More teams with different views increase review cycles and role configuration work.	Agree on a small set of shared dashboards first, and add team-specific views only when an analyst workflow needs them.
Retention targets and storage per search node	Longer retention increases the data each search node must index and store, which drives disk size and the hardware needed for queries. Full packet capture adds to this load.	Set retention by data type, decide early whether full packet capture is needed and for how long, and confirm storage sizing with the hardware documentation before procurement.
Topology: standalone versus distributed grid	A distributed grid with manager, sensor and search nodes needs more build, networking and testing than a standalone node. Each added node role adds configuration and verification steps.	Match topology to the scale and availability you actually need, and avoid adding node roles that the current scope does not require.
Airgap operation with ISO media and soup updates	Packages and rule content must be carried in on ISO media, and updates depend on importing newer media through the soup update path. Planning, media handling and transfer checks add process overhead.	Plan the media transfer process and update cadence before the build, and document each import so later updates follow a repeatable procedure.
Playbook integrations with external systems and credentials	Each connection to a ticketing, email or threat intelligence system needs API access, credential handling, error testing and approval. Credentials must be stored and rotated under your policies.	Limit integrations to those that support defined response steps, use dedicated service accounts with narrow permissions, and test each playbook end to end before enabling it.
Edition choice (free versus Pro)	Pro features such as OIDC single sign-on, LUKS encryption, FIPS mode, STIG compliance and the API each add configuration, testing and documentation work. Pro also includes professional support, which changes who handles issues.	Decide the required features before the build, confirm the Pro terms and support scope in writing, and avoid enabling features that the security requirements do not call for.
Availability of a matching test grid	Without a test grid that mirrors production, detections, playbooks and upgrades must be validated on live monitoring, which raises risk and rework. A matching grid adds infrastructure cost but shortens validation cycles.	Confirm whether the client will provide a test grid with comparable node roles and versions, or whether a smaller test environment is acceptable for the scope agreed.

Project phases and outputs

The sequence moves from agreed detection requirements to tested, documented content that your analysts run in production without relying on the implementation team.

Confirm use cases and log sources
We interview the SOC lead and analysts to agree the detection use cases, the analyst questions each dashboard and playbook must answer, and an inventory of log sources with owners and access paths. The output is a signed requirements document and a log source inventory. The step closes when the client has approved both in writing.
Design the content and data model
We map each log source to the sensors, parsers and Elastic agent integrations that will collect it, and draft the content catalog covering Suricata, Sigma and YARA rules, suppressions and thresholds. We also set the retention model and specify dashboards and playbooks. Outputs are a log source map, the content catalog, the retention model and written dashboard and playbook specifications, approved by the client.
Build on a test grid
We build the custom content on a test grid that matches the production layout as closely as the client allows, and keep all rules, parsers and integration configuration in version control with reviewed changes. Each parser and integration is tested against sample events. The step is complete when the test grid runs the full content set and the test results are recorded in the repository.
Validate with replayed traffic
We send test traffic or replay recorded events through the test grid to confirm that detections fire, suppressions and thresholds behave as specified, and dashboards show the expected fields. Where useful, we run cyber range exercises to test analyst workflows. Analysts review the content and playbooks with us. The output is a validation report listing each use case, its test result and any open findings.
Deploy under change control
We deploy the validated content to production under a change record that names the components, the approvers, the timing window and the test evidence. A documented rollback procedure is rehearsed before the change and kept with the record. The step closes when production matches the approved version and the change record is signed off by the client's change board.
Hand over runbook and knowledge
We deliver a runbook covering content updates, rule tuning, retention changes, rollback and escalation, and run knowledge transfer sessions for the analysts and engineers who will own the platform. Handover is complete when the client's team has performed a supervised content change and the runbook has been accepted by the named owners.

What teams keep in-house and what they outsource

The table shows who usually owns each Security Onion customization component and the skills each part needs, with analysts keeping day-to-day changes while a partner usually handles the first design, parsers, integrations and a documented handover.

Component	Usually owned by	Skills each part needs
Log source onboarding	Partner for the first build, then the internal platform team	Linux administration, Elastic Fleet agents, log format analysis, parser design
Suricata content	Analysts tune rules, partner sets up the initial rule sources	Suricata rule syntax, network protocol knowledge, traffic analysis
Sigma content	Analysts write and tune rules, partner reviews the first set	Sigma rule logic, log schema knowledge, ElastAlert behavior
YARA content	Analysts with malware analysis input, partner sets up Strelka integration	YARA syntax, file format knowledge, malware triage
Dashboards	Partner designs the first set, analysts extend them	Elasticsearch query design, SOC workflow knowledge, visualization design
Retention and storage settings	Internal platform team, sized with the partner	Storage sizing, index lifecycle management, retention requirements from compliance
Playbooks	Partner builds the first set, SOC owns the runbooks	Incident response process, ticketing or SOAR integration, analyst workflow design
Content version control and change control	Internal team, with the partner setting up the process	Git workflows, peer review, change approval, audit evidence
Day-to-day analyst tuning	Analysts, kept in-house. The detection engineering page covers this workflow in depth.	Alert triage, false positive analysis, suppression and threshold tuning

What usually goes wrong

Most Security Onion customization problems appear during upgrades, capacity changes or outages, not on the day content is first built. The checks below help you catch them before they reach production.

Hand edits lost in upgrades

Custom changes made directly in Security Onion files or in Elastic objects such as dashboards and index templates are often unrecorded. A soup upgrade or a move between major versions can overwrite or break them. Keep every change in version-controlled files or exported object lists, and confirm each one survives on a matching test grid before production.

Dashboards tied to field names

Dashboards, saved searches and detection filters built on specific field names can stop matching when a later release renames or restructures those fields. The results then look empty instead of failing loudly. Inventory which fields each view depends on, and re-check those views after every upgrade.

Retention and volume outpace storage

Retention set on policy without checking the disk each search node needs can fill storage sooner than expected. New log sources can also raise event volume beyond what the grid was sized for. Before enabling a source or lengthening retention, estimate its daily volume per node and confirm the result against your hardware plan.

Playbooks with unowned credentials

Playbooks that call external APIs or depend on service credentials often have no named owner. When a key expires or a vendor changes an endpoint, the workflow fails quietly. Assign an owner to each integration, store credentials in a managed secrets location, and record a rotation schedule and a test step for each playbook.

Airgap content waits on media

In airgap environments, detection content and package fixes arrive through new ISO media, and the soup tool updates from that media. Rule updates and fixes can stall while the next media is prepared and transferred. Agree a media delivery process in advance, and confirm which rule and package updates your grid will receive between ISO releases.

Manager outage stops indexing

The architecture docs note that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Integrations that send events or depend on manager-side services inherit this dependency. Design them to queue or retry safely, and consider receiver nodes for pipeline redundancy and load balancing.

How the work changes by starting point

A new grid lets customization be designed in from the first build, so detection content, log sources and retention are settled before sensors go live.

Deployment type: Confirm the deployment type first, since node roles decide where custom rules and integrations land.
Rule ownership: Agree which Suricata, Sigma and YARA rules are custom, who owns them, and where they are tested first.
Cloud marketplace: For AWS, Azure or Google Cloud images, confirm the image version, networking and storage layout against current docs before building.
Log sources: Plan Elastic Fleet integrations for each source during the build, not after the first alerts arrive.
Retention: Set storage and retention early, since changing them later affects data already indexed.

What you need to provide

Customization goes faster when the client arrives with decisions already made. Before the design starts, provide a log source inventory that names each source, its owner and a few sample events, because Elastic Fleet integrations and Sigma field mappings depend on the actual event shape, not the vendor's documentation. Pair it with the analyst use cases and the specific questions each dashboard must answer. A dashboard built without those questions usually gets rebuilt after the first analyst review.

Provide the retention policy and any compliance drivers behind it in writing. Retention settings for Elasticsearch indices and packet capture storage are sized from how long data must stay searchable and how much it costs to keep, so the team should confirm which obligations apply and who signed off on them. Also provide access to a test grid that matches production in edition, OS and sensor placement as closely as practical. Without it, Suricata, Sigma and YARA tuning cannot be verified before it reaches the live grid.

Name an owner for each detection, dashboard and playbook, and confirm who approves changes. Provide a Git repository or equivalent for detection content, dashboards and playbook definitions so changes are reviewed and rolled back rather than edited in the console. For response integrations, supply service credentials and API access with least privilege, stored in your approved secrets system. Agree a change window and approval path for the production grid, since a rule change or a soup upgrade can affect alert volume and search node indexing.

Last, sign off in writing on which Security Onion edition the design assumes. Free and Pro differ in features that shape customization, including OIDC single sign-on, the Security Onion API and external notifications, so a design built on one edition may not work on the other. Confirm the target major version as well. Security Onion 3.0.0 supports only Oracle Linux 9, and the 2.4 and 2.3 lines have announced end-of-life dates, so confirm with your team and the vendor which version you will run before custom content is written against it.

Common questions about Security Onion customization

What drives the cost of Security Onion customization?

The scope you agree in writing sets most of the cost. A fixed-scope engagement is priced from the number of log sources, integrations, custom detections, parsers, dashboards and playbooks you need, plus the environments they must be built and tested in. Costs fall into one-time work (design, build, tuning, documentation and knowledge transfer) and recurring work (rule updates, upgrades and support retainers). Ask for a quote that lists each deliverable separately so you can see which items recur and which you can take in-house later.

How long does Security Onion customization take to complete?

Duration follows the written scope, not a standard timeline. The main variables are how many log sources and Elastic agent integrations must be onboarded, how many custom Suricata, Sigma and YARA detections need tuning, and whether parsers or playbooks are included. Each source adds validation work because its fields must be mapped and checked against real events. Ask the provider to show the milestones, the dependencies on your access and change windows, and what is excluded.

Can our own team customize Security Onion without outside help?

Yes for content tuning, harder for parsers and playbooks. Engineers with working knowledge of Suricata rules, Sigma rules, YARA and Elastic can usually tune detections, add suppressions and thresholds, and adjust dashboards in the Security Onion Detections interface. Custom parsers, ingest pipelines and SOAR playbooks need deeper knowledge of event schemas and failure handling, and mistakes there can drop events silently. Assess your team's skills honestly and consider a partner for the parts you cannot test well.

Does our custom content survive Security Onion upgrades?

It depends on how the content is stored and tested, so confirm against the upgrade documentation. Changes made through the console, edited files on the nodes, and custom parsers all behave differently during an upgrade. Keep rules, configuration and pipeline code under version control, record every change, and test the upgrade on a grid that matches production before running it live. Ask the provider to document which customizations are preserved, which need reapplying, and how rollback works.

Do we need Security Onion Pro for customization?

Only if you need a feature that is listed as Pro. Pro is a paid edition sold on 1 to 5 year terms and adds items such as OIDC single sign-on to the Console, the Security Onion API, external notifications, and professional support. Detection tuning, custom Sigma, Suricata and YARA content, and dashboards are available in the free edition. Confirm the current list of Pro entitlements on the vendor's Pro page before you budget, because editions change.

What do we need to supply before customization starts?

Access, data and decisions. Expect to provide administrative access to a test grid and the production grid, a list of log sources with their owners, sample events or packet captures for each source, and the detections or use cases your analysts need. You will also need to name an accountable owner for approvals, schedule change windows, and confirm where the work may run, including whether the environment is airgapped. Missing inputs are the most common reason a fixed-scope timeline slips.

How DeployOpen delivers Security Onion customization

DeployOpen scopes Security Onion customization in writing, builds the detections, log sources and dashboards inside infrastructure you control, and hands them over with documentation your analysts can maintain. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

We confirm your deployment type, whether Standalone or Distributed, and which Security Onion version and operating system your grid runs.
We list the Suricata, Sigma and YARA detections, log sources and Elastic agent integrations in the written scope before any build starts.
We agree retention settings, dashboard requirements and playbook needs with your analysts so the fixed scope reflects how they investigate.

How we build

We build custom detections in the Security Onion Detections interface, covering NIDS rules, Sigma rules and YARA rules, with suppressions and thresholds tested against your traffic.
We add and configure log sources and Elastic Fleet agent integrations on a matching test grid before changes reach production.
We create dashboards and investigation workflows, then check that alert volume and retention behave as agreed under realistic load for your environment.

How we hand over

We deliver a written record of every custom rule, log source, integration, dashboard and retention setting, with the reason each one exists.
We walk your analysts and administrators through how to tune detections, suppress noise and review changes, so the team can maintain them.
We document the update process, including how custom content is kept through soup upgrades and how airgap media is handled where needed.

How we support

Ongoing support, upgrades and rule maintenance are available as a retainer, scoped separately from the original fixed-scope build.
We retest custom detections and integrations when Security Onion releases new versions, before those upgrades reach your production grid.
Support scope is agreed in writing, and you should confirm with us how it compares with Security Onion Pro professional support for your needs.

Security Onion customization