Security Onion detection engineering guide

Why Security Onion detection engineering takes longer than enabling rules

Enabling a rule in Security Onion takes minutes. Turning the detection output into a queue your analysts trust takes longer, and that gap is the subject of this section. This page covers building and tuning Suricata, Sigma and YARA detections in the Detections interface of the Security Onion Console. A team with a grid that already collects traffic and logs usually finds the alert queue either empty or so full of low-value hits that nobody reads it, and the work to fix that sits between those two states.

The main reason the work takes longer than expected is that the three rule types do not share one engine or one tuning workflow. NIDS rules load into Suricata and run against network traffic. Sigma rules load into ElastAlert and run against events that have already been indexed. YARA rules load into Strelka and run against files. A change that quiets a Suricata signature does nothing to a Sigma rule that fires on the same behavior, and a YARA rule that looks correct in review can still produce no hits because the file path never reaches Strelka. Plan separate test and review steps for each engine rather than assuming one change pattern covers all three.

Four problems tend to consume most of the effort. The first is noisy baseline traffic: scanners, backup jobs, update services and internal vulnerability tools produce alerts that are technically correct and operationally useless, and you need a baseline capture of normal activity before deciding what to suppress. The second is overlapping rules, where several rules from the same feed or from custom work fire on the same traffic and multiply the queue. The third is suppression that hides real activity. A suppression broad enough to silence a noisy rule can also silence the one host you most needed to see, so each suppression needs a stated scope, an owner and a review date. The fourth is ownership after go-live, which is covered below.

The Detections interface supports modify, suppress and threshold tuning for NIDS rules, and custom filters for Sigma rules. Confirm in the current Security Onion documentation whether and how YARA rule tuning is supported in the Detections interface before you promise it in a plan, and document what your team will do instead if the answer is limited. Assign a named person or small group to own tuning changes after go-live, with a change log that records the rule, the reason, the scope and the expected effect. Without that owner, suppressions accumulate, nobody remembers why they exist, and the queue drifts back to unusable within a few months of handover.

Which Security Onion components hold each detection type

Each detection type runs through a different engine, and the Detections interface in the Console is where analysts tune all of them. These cards show which component produces each alert, which tuning control applies, and which node role to confirm before changing rules.

Security Onion Console Detections interface

The Detections interface is the control point for rules across all three detection types. It manages NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka. The tuning controls differ by engine: modify, suppress and threshold for NIDS rules, and custom filters for Sigma. Check which controls apply to YARA rules in your version before you plan tuning work.

Suricata NIDS rules

Suricata inspects network traffic from sensors and raises an alert when traffic matches a signature. In the Detections interface, modify, suppress and threshold are the main levers for cutting noisy signatures. Scope suppressions to a known source or destination, and review thresholds after each change to confirm alert volume drops without losing true hits. Confirm which node role runs Suricata in your version, since the Distributed design separates sensor and search roles.

ElastAlert running Sigma rules

ElastAlert runs Sigma rules that are loaded from the Detections interface and evaluates them against log data already indexed in Elasticsearch. Sigma matches depend on log fields, so detection quality depends on which log sources reach the grid through Elastic Fleet agents. The tuning control for Sigma is the custom filter, which narrows matches to known benign activity. Confirm where ElastAlert runs in your Distributed grid before you change filters on production nodes.

Strelka running YARA rules

Strelka applies YARA rules to files that reach it from the grid, so YARA hits depend on file visibility as well as network traffic. Rules for this engine are managed in the Detections interface alongside the other two types. Before tuning, confirm which file types and sources reach Strelka in your deployment, because a rule that never receives its target files will look silent. Also confirm which node role runs Strelka and which suppression controls apply to YARA hits.

Elasticsearch alert storage and search

Elasticsearch stores the alerts that Suricata, ElastAlert and Strelka produce, and it is where analysts search, pivot and triage them in the Console. Alert volume and retention settings affect search performance and disk use on search nodes. The architecture docs note that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Confirm index and retention settings in your version before you size search nodes.

Suricata full packet capture for investigation

Suricata full packet capture keeps the traffic around a hit so analysts can examine what was transferred. In Security Onion 3.0, Suricata replaced Stenographer for this role, so teams moving from 2.4 need to plan for that change. Capture volume and retention drive disk use on sensor nodes and should be sized against link speed. Confirm the retention window, the node that holds the captured packets, and how an analyst pivots from an alert to its packets in your version.

Which tuning method to use for each kind of noise

This table compares six ways to handle a noisy Security Onion detection, from disabling a rule to writing a new local rule. Read each row for when the method fits and what it costs operationally, such as lost coverage or a suppression that hides real activity. The main takeaway is to pick the narrowest change that removes the noise and to record why it was made.

Method	When it fits	Operational cost
Disable a rule	The rule does not apply to your network or its signature is broken, and no other rule covers the same behavior	Coverage is lost for everything the rule matched. Record the reason and review it when rule sets update.
Modify a NIDS rule	A Suricata signature is correct but too broad, such as a missing variable or a HOME_NET value that is too loose	Changes persist only in your copy. Re-test after rule updates, since upstream changes may need the same edit.
Add a suppression	A known, benign source or destination repeatedly triggers a rule that is otherwise valuable	A suppression can hide a real attack from that source. Scope it to a specific IP or host and set an owner and review date.
Add a threshold	A rule fires on normal repetition, such as many connection attempts, but a burst is still worth seeing	Thresholds can miss slow activity below the limit. Test the count against a week of logs before enabling.
Add a Sigma custom filter	A Sigma rule in ElastAlert flags a known administrative tool or script on a defined set of hosts	Filters must be kept in step with Sigma rule changes. Narrow fields such as host and user reduce blind spots.
Write a new local rule	The existing rules miss the behavior you need, or you must replace a noisy generic rule with a specific one	Highest effort: you own the logic, testing and documentation. Validate detection and false positive rates before production use.

How to build and tune detections in sequence

This sequence moves a Security Onion grid from default rule sets to tuned Suricata, Sigma and YARA detections. Each change is made in the Detections interface, checked with a replay or test event, and recorded so analysts and auditors can trace why an alert fires or is suppressed.

Confirm deployment type and node roles
Record whether the grid is Import, Evaluation, Standalone or Distributed, and which nodes act as managers, sensors and search nodes. The architecture documentation recommends the Distributed design for production and notes that search nodes stop indexing when they cannot reach the manager, so confirm the grid is healthy before tuning. Your platform engineer confirms this in the console and the node inventory. The step is done when you have a written map of nodes, the sensors that see each traffic segment, and the node that holds Detections changes, so every later check runs against the correct sensor.
Baseline a clean period of traffic
Choose a window of normal business traffic and logs that is free of known incidents, scans and planned security tests. Use the Detections interface to capture which Suricata, Sigma and YARA rules are enabled and how many alerts each one produces in that window. Record the time range, the sensors covered and the console version. The check is that you can reproduce the same alert counts when you reopen the window, so every later before-and-after comparison has a fixed reference. Ask your security lead to approve the window before any tuning begins.
Review which rules fire on business traffic
Sort the enabled rules by alert count and match the top-firing NIDS, Sigma and YARA rules to the traffic or log source that triggers them. Classify each one as expected business behavior, a misconfiguration of the source, or possible threat activity, and assign an investigator to anything unclear. Make no suppressions or edits yet. The output is a triage list with one decision per rule. The step is done when every high-volume rule has a recorded reason, and the list is saved alongside the baseline.
Modify Suricata rules for known traffic
Edit enabled NIDS rules in the Detections interface only where the rule logic is correct but too broad, such as a match that should be limited to one destination or one field. Keep a copy of the original rule text so the change can be reverted. Replay a captured or test event that should still fire and one that should no longer fire. Then compare the alert count for the baseline window with the count after the change. Confirm in the vendor documentation what the console saves and how it reports modified rules.
Suppress and threshold NIDS alerts
Apply suppressions to specific sources or destinations where the behavior is known and accepted, and use thresholds to limit repeated alerts from the same pattern. Keep each scope as narrow as the business reason allows, so an unexpected source still alerts. The check is a replayed event from the suppressed source, which should be suppressed, and a replayed event from an unexpected source, which should still fire. Record the alert count before and after on the baseline window, the reason for each suppression and the person who approved it.
Add Sigma custom filters for ElastAlert
Sigma rules run through ElastAlert, so tune them with custom filters in the Detections interface instead of changing the upstream rule. Filter out a known benign field value, such as a scheduled backup account or an approved administration host, while keeping the base rule intact. Check the result with a log event that matches the filter, which should be filtered, and an unrelated event that matches the base rule, which should still alert. Record the alert count before and after the filter and note which log source the filter depends on.
Add YARA rules for Strelka file analysis
Add YARA rules that are loaded into Strelka only after the NIDS and Sigma tuning is stable, so file alerts are not mixed with traffic changes. Confirm the supported rule syntax and load behavior in the Security Onion documentation for your version. Test with benign sample files of the same type in a controlled lab, not live production files. The check is that a test file triggers the new rule, a comparable clean file does not, and the match count on the baseline file set is recorded before and after the change.
Run a local rule workflow with change records
Give every local rule a naming convention, a named owner and a change record that states the reason, the baseline window, the test event used and the before-and-after alert counts. Route changes through peer review, and where you run a matching test grid, prove each change there first. Rule updates delivered through soup or airgap media can change behavior, so re-run the replay checks after each update. The step is done when you can trace any alert from the console to its rule, owner and change record in one lookup.

What drives detection engineering effort and how to keep it down

This table lists the main drivers of detection engineering work in Security Onion, from rule set scope and traffic volume to change control and analyst review time. Each row explains how the driver raises effort and a practical way to keep it under control. Read it as a scoping checklist: the biggest savings usually come from a narrow first rule set and a matching test grid before anything reaches production.

Driver	How it raises effort	How to keep it down
Enabled rule sets	Every enabled Suricata, Sigma or YARA rule set adds alerts to triage and tuning, and each one needs an owner who knows what it is meant to catch.	Start with a narrow first rule set tied to your highest-value networks and log sources, then add sets only when an analyst owns them.
Traffic volume and sensor coverage	More sensors and higher link speeds produce more NIDS alerts and more noise to suppress, so tuning work grows with every tap or SPAN port added.	Confirm sensor placement and expected alert volume in a pilot before enabling broad rule sets, and tune the noisiest signatures first.
Distinct log sources feeding Sigma rules	Each log source has its own field names, parsing and gaps, so a Sigma rule that works on one source may need rework or be silent on another.	Limit the first Sigma rules to a short list of sources you already collect reliably, and document the fields each rule depends on.
Number of local custom rules	Custom Suricata, Sigma and YARA rules must be written, tested, documented and maintained after upgrades, and they accumulate quickly without a limit.	Restrict custom rules to named use cases with an owner and a stated purpose, and retire rules that no longer map to a use case.
Change control and approval steps	Every suppression, threshold or rule change may need a ticket, a review and a record, which adds time per change even when the technical work is small.	Group related tuning into batches, define which changes need approval, and keep a simple change log tied to each detection.
Analyst availability for review	Tuning depends on analysts who can judge whether an alert is benign, and their limited time often becomes the bottleneck for detection work.	Schedule fixed review windows, assign a named reviewer for each rule set, and agree on what the reviewer must check before sign-off.
Number of environments (lab, test grid, production)	Testing on a separate grid that matches production adds infrastructure, data handling and sync work, but skipping it shifts the cost to production noise.	Use a lab for rule authoring, a test grid with comparable sensors for tuning, and promote only tested changes to production.

How the detection workflow changes by deployment model

A standalone node runs the console, Elasticsearch, Suricata, Zeek and the detection rules on one machine. Tuning happens where traffic is captured and alerts are stored, so the loop from a suppression or threshold change to its effect on the alert queue is short. That speed helps early tuning, but it has limits that matter before production.

Single-node tuning: Modify Suricata NIDS rules and add suppressions and thresholds in the Detections interface, then review the effect in the same console you use for hunting.
Shared resources: Sigma rules run through ElastAlert and YARA rules through Strelka on the same host as capture and indexing, so a heavy YARA rule can compete with those services for CPU and disk.
Limits of same-host testing: A rule that looks quiet on a lab node may behave differently once it sees the full traffic volume of a production sensor.
Change records: Keep a written record of each suppression and threshold, so you can explain later why an alert was hidden.

Before moving a tuned rule set to production, confirm in your version how each rule type is updated, reloaded and backed up on a standalone node, and measure alert volume on traffic that resembles what the production sensors will see.

How to test that tuned detections fire and stay quiet

The point of verification is to show two things before a tuned detection goes into production: each rule still fires on the activity it targets, and each suppression or threshold removes only the noise it was written for. Treat every change in the Security Onion Console Detections interface as a testable hypothesis. For Suricata NIDS rules, replay known test traffic from a packet capture or a traffic generator through a sensor's monitored interface and confirm the expected signature alert appears in the Console. For Sigma rules running through ElastAlert, load a log event that matches the rule's conditions into the ingest path and confirm the alert is produced. For YARA rules in Strelka, submit a known test file, such as a benign file containing the rule's string pattern or the EICAR test file, and confirm the file is flagged. Keep these test inputs in version control so they can be rerun after every change or upgrade.

Suppressions and thresholds need a different check, because the goal is to remove alerts, not to prove that something fires. Build a negative test set that represents the noise you intend to remove, and a second set representing the activity that must still alert. Apply the suppression or threshold, replay both sets, and confirm the first set is silenced while the second set still produces alerts. Filters that are too broad will pass the first test and fail the second, so both directions matter. Also confirm that each alert still appears in the Console with the fields your analysts and any downstream workflow depend on, such as the rule identifier, source and destination addresses, timestamps, and the category or severity fields. A detection that fires but loses its key fields can break triage just as badly as one that stays silent. Silent failure is the risk most worth testing directly. A detection pipeline can stop without raising an obvious error: a Suricata process may stop on one sensor, a Strelka or ElastAlert component may fail to load a rule, or a search node may stop indexing if it cannot reach the manager. Include a deliberate failure test in your plan. Stop a non-production engine or simulate an unreachable component, then confirm that the Console, your monitoring, or a health check shows the gap within a time window you set in advance. Ask the vendor and your own team which health signals are exposed and who receives them. If you cannot confirm that a stopped engine is visible, treat that as a finding to resolve before relying on the detection. Every change needs a rollback plan written before it is applied. For each rule, suppression or threshold, record the previous version, the exact change, the owner, and the step that restores the prior state. Capture alert counts for the same replay set and the same time window before and after each change, along with the test results, and store them with the change record. Compare the counts against the expected direction set in your test design rather than against a number you assumed in advance. Confirm which settings are included in your backups and how they are restored in the grid, and rehearse the rollback on a matching test grid before you rely on it in production.

Access control and change control for detection content

Detections in Security Onion are code and configuration that decide what the team sees, so changes to them need the same control as any other production system. The cards below cover who can edit detections in the Console, how analyst tuning and rule authoring are separated, how custom rules are protected in version control, and how suppressions, review and captured packets are governed.

Console edit rights for detections

Decide which accounts can modify, suppress or threshold NIDS rules, and which can add or change Sigma and YARA rules, in the Detections interface. In the free edition, access relies on local console accounts, so the team must manage who holds each account and remove accounts when people leave. Confirm with your own configuration which accounts can reach the Detections section on each manager.

Role-based access through SSO

Role-based access tied to single sign-on is a Security Onion Pro capability, according to the supplied product facts, and the free edition uses local console accounts. If your design depends on mapping identity provider groups to analyst and author roles, confirm the Pro edition covers that mapping and plan for it before rollout. Without it, role separation is enforced through account management and process rather than identity groups.

Separating tuning from authoring

Analysts who tune alerts by adding suppressions or thresholds need different rights from engineers who write new Suricata, Sigma or YARA content. Tuning changes what an alert does for one environment, while authoring changes what the platform can detect at all. Document which actions each role may take, and check whether your Console roles allow that split before assigning them.

Version control for custom rules

Keep custom Sigma and YARA rules in a version control repository with protected branches, required reviews and an audit trail of who changed what and why. Treat the repository as the source of truth and confirm how changes move from the repository into the Console on your managers. Restrict write access to the repository separately from Console access so that one account cannot push a rule change unreviewed.

Suppression and threshold governance

A suppression can silently hide the activity a detection exists to find, so each one needs an owner, a stated reason, a scope and an expiry or review date. Periodically list every active suppression and threshold and ask whether it still matches the environment. Confirm how the Console records who created each suppression and whether that record can be exported for review.

Pre-production review of rules

Require a second person to review each new or changed rule before it reaches the production manager, and test it against captured traffic or sample logs first. Check the rule's expected alert volume, its fields and its severity, since a rule that floods analysts is a noise problem and a rule that never fires is a coverage gap. Record the review outcome in the same change record as the rule.

Protecting packets behind alerts

Alerts that reference Suricata full packet capture expose the underlying traffic, which may contain credentials, personal data or regulated content. Limit which roles can open packet data from an alert, log those access events, and set retention for captured packets separately from alert records. Confirm how packet access is authorized in your edition and how long captures are kept on sensors.

What to monitor, document and review after tuning goes live

Tuning is not finished when a rule stops firing on noise. The detections need an owner who reviews them on a schedule, watches how they behave, and keeps records that explain why each one exists. Without that routine, suppressions and thresholds added during tuning quietly outlive the conditions that justified them, and a blind spot can persist for months without anyone noticing. Review suppressions and thresholds on a fixed schedule. Every suppression and threshold created in the Security Onion Console Detections interface should carry a recorded reason, the rule it applies to, and a date for the next review. When the reason is a specific asset, such as a vulnerability scanner or a backup server, confirm the asset still exists and still behaves the way it did. A suppression that hides a whole rule across every sensor is the one to challenge first, because it removes visibility for everything that rule was meant to catch.

Monitor alert volume by rule and by sensor, not only as a total. A total can stay flat while one Suricata rule spikes on a single sensor after a network change, or while a Sigma rule goes quiet because its source logs stopped arriving. Build a simple baseline per rule and per sensor, then investigate sustained changes in either direction. A rule that drops to zero deserves the same attention as one that floods the queue, since silence can mean a broken log source or a filter that matches too much. Track rule updates from the official sources. Suricata NIDS rules, Sigma rules and YARA rules change upstream, and tuned rules may be affected by those changes. Record which rule sources and versions the grid uses, and check how the current rule update mechanism works in the Security Onion Detections documentation before planning a schedule. Rule and component updates for the grid itself are covered in the sibling upgrades topic, so this section focuses on how your team reviews the effect of those changes on your tuning.

Retest tuned rules after every Security Onion upgrade. Suppressions, thresholds and custom Sigma filters can behave differently once the underlying components change, and an upgrade is the most likely point for a silent regression. Keep a short set of test events for each critical custom rule, replay them on a test grid that matches production, and confirm the expected alerts and suppressions still hold before the change reaches production. Keep a register of custom rules. For each custom Suricata, Sigma and YARA rule, record the owner, the purpose, the data source it depends on, the tuning decisions made, and the test evidence that proves it works. Store the register where auditors and new analysts can read it. Ask the implementation partner, if you use one, to deliver the register as a handover item, and confirm who maintains it after the engagement ends.

Questions buyers ask before hiring detection engineering help

How much effort does detection tuning take and what drives it?

Effort depends on how noisy the environment is, how many detections are in scope and how many alerts need a decision. Tuning is iterative: review each alert, decide whether it is expected, benign or actionable, then adjust the rule with a suppression, a threshold, a custom filter or a modified rule.

Main drivers:

The number of enabled Suricata NIDS rules and how much traffic they match across sensors
How many log sources feed the Sigma rules and how well they are normalized
Whether YARA scanning covers file types that produce many hits
How quickly analysts can confirm what is legitimate in your network

Every change needs testing against representative activity before production. Ask any provider to split its quote into initial baseline tuning and recurring review, and to state which rule counts and sensors it assumes.

How long does a detection engineering engagement take?

Scope and environment set the timeline, and no fixed template applies. The main inputs are the number of sensors and log sources in play, how many detection areas span Suricata, Sigma and YARA, how many approvals a change requires and whether a test grid matching production already exists. Access to traffic samples and named analysts often sets the pace more than the engineering does.

Most engagements are fixed-scope, so deliverables, milestones and timelines are agreed in writing before work starts. Ask for a schedule that names its dependencies: access grants, change windows, analyst availability and any upgrade or migration running at the same time. If the test grid is still being built, the schedule should say so.

What does the work need from our team?

The work needs four things from your side. Named analysts who know escalation paths and can say whether an alert is expected. Traffic access to the sensors and to representative packet or log samples, including any segment that needs a tap or mirror change. Change approval from the owner of the grid, so rule changes follow your process. A test grid that mirrors the production Security Onion version and rule set, so changes can be replayed before rollout.

Also provide the current Detections list, known false-positive patterns and your naming and severity conventions. Confirm who may approve a suppression, because a suppression hides alerts from analysts.

Can our in-house team tune these detections without a partner?

Yes, many teams can, provided their analysts understand the traffic and the detection logic. The Security Onion Console Detections interface lets you modify, suppress and set thresholds for NIDS rules loaded into Suricata, and add custom filters for Sigma rules loaded into ElastAlert. YARA rules loaded into Strelka are also managed from the Detections interface.

Your team still needs a change process, a test environment and written tuning records. A partner usually helps when the team lacks capacity, when an upgrade runs at the same time, when custom rule logic must be written and validated, or when you want an independent review of suppressions. The official documentation explains the mechanics, but it cannot tell you which activity is malicious in your network.

Do we need Security Onion Pro for detection engineering?

No. 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, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. The Detections interface is not listed among those Pro features, so the tuning work described above does not depend on Pro.

Pro matters for detection work when your access model or support requirements call for it. If analysts must sign in through your identity provider, SSO may decide the question. Check the current Pro page before you decide, because editions and feature lists change.

What do we receive at the end of the engagement?

Handover should match the written scope. Ask for a record of every rule changed, added or suppressed, with the reason, the owner and the test evidence behind each decision. Typical items include a rule inventory across Suricata, Sigma and YARA, the tuning log, the test grid configuration, the change history, runbooks for the analysts who will maintain tuning and a review plan for future upgrades.

Confirm that custom rule source is delivered in a form your team can put under version control, and that the documentation describes the environment as built, not as originally planned. DeployOpen documents the work it performs and hands it over as agreed in the written scope.

Which alerts should we tune first to cut noise?

Start with the alerts that consume the most analyst time and have the lowest confirmed value. Review the Detections list by alert volume, then check which rules fire on expected activity such as vulnerability scanners, backups, software updates or known internal services.

A suppression fits a pattern that is understood and narrow. A threshold fits a valid rule that fires in bursts. Modify the rule only when its logic is wrong. Record each decision with the sample used, and replay the change on the test grid before production. Avoid broad suppressions that hide whole network segments, because they remove visibility you may need during an investigation.

Where do Sigma and YARA rules run inside Security Onion?

Suricata NIDS rules are loaded into Suricata, which inspects network traffic at the sensors. Sigma rules are loaded into ElastAlert, which evaluates events that the grid has indexed in Elasticsearch. YARA rules are loaded into Strelka, which analyzes files that reach the grid. Each engine sees a different slice of data, so a detection's coverage depends on which logs and files arrive.

Before you tune a Sigma rule, confirm that its log source is ingested and normalized. Before you tune a Suricata rule, confirm that the sensors carry the traffic you care about. Many apparent rule problems turn out to be sensor placement or ingestion gaps.

How DeployOpen scopes, builds and hands over detection engineering

DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and detection engineering follows the same approach. Work on Security Onion Suricata, Sigma and YARA content starts from a written scope, is built and tested in your environment, and ends with documentation and a handover your team can run.

How we scope

Engagements are fixed-scope, with the detection sources, rule types and deliverables agreed in writing before work starts.
We confirm which Suricata NIDS, Sigma and YARA detections are in scope and which log sources and sensors they depend on.
Scope names the Detections interface changes, suppressions and thresholds to be tuned, and the alert volumes you want to reduce.

How we build

Suricata rules are written or modified in the Detections interface, then reviewed against captured traffic on your sensors.
Sigma rules run through ElastAlert, so we test each rule's query, custom filters and expected alert fields on your search nodes.
YARA rules loaded into Strelka are tested against sample files you approve, with suppressions and thresholds recorded per rule.

How we hand over

Handover includes a rule inventory listing each Suricata, Sigma and YARA detection, its owner, source and tuning history.
Documentation explains how to add, modify, suppress and threshold rules, so analysts and engineers can maintain them after handover.
Test cases and before-and-after alert samples are delivered so your team can repeat the verification steps independently.

How we support

Ongoing support, rule updates and continuous testing are available as a retainer after the initial handover.
Retainer scope should state how new rules, tuning requests and Security Onion version changes are reviewed and deployed.
Ask us to confirm response expectations and change control in the written retainer before work begins.

Security Onion detection engineering with Suricata, Sigma and YARA