From Darktrace to Security Onion

Darktrace sells a genuinely different proposition from the rest of network detection: unsupervised models that learn what normal looks like on your network and flag deviation, with no signatures to maintain. Teams leave for the reasons that follow from that model, appliance-plus-subscription pricing that scales with monitored bandwidth, a 2024 take-private that raised expectations about future repricing, and a persistent discomfort among security engineers about detections they cannot inspect, explain to an auditor, or reproduce. Security Onion is the open destination, and it is philosophically the opposite: everything it detects, it detects because someone wrote the logic down.

That inversion is the whole story of this migration, and it is worth being clear about the direction of the trade before starting.

What you gain and what you lose, stated plainly

You gain inspectability. Every Suricata signature, every Zeek script, every Elastic detection rule is readable, version-controllable, reviewable, and explainable. When an analyst asks why something fired, there is an answer. When an auditor asks what the control does, there is a document. When a detection is wrong, you can fix it yourself rather than raise a support case.

You lose the class of finding that comes from a model noticing something no one anticipated. That capability is real, and pretending an open ruleset covers it will damage your credibility internally. Anomaly detection over Zeek logs, statistical baselining of connection patterns, and Elastic’s machine-learning jobs recover part of the ground, but not all of it.

The honest framing for a business case is therefore: a substantial cost reduction and a large gain in transparency, against a real reduction in unsupervised-anomaly coverage, mitigated by explicit detection engineering that you now own. If nobody in the organisation will own detection engineering, do not start, because Security Onion without maintained content degrades quietly.

The mapping

• Darktrace probes → Security Onion forward nodes (sensors), fed from the same TAP or SPAN infrastructure.
• Darktrace master appliance → Security Onion manager and search nodes.
• Model breaches → Suricata alerts, Zeek notices, and Elastic detection rules.
• The Threat Visualizer → Kibana dashboards plus Security Onion’s alert and hunt interfaces.
• Device and connection history → Zeek conn.log and protocol logs, which are richer and more structured than most people expect.
• Antigena autonomous response → inline Suricata IPS, or SOAR automation calling firewall and NAC APIs.
• Cyber AI Analyst investigation summaries → your own triage workflow, backed by Security Onion’s case features.
• PCAP retrieval → Security Onion’s packet-capture component, subject to whatever retention you sized for.

Reuse the tapping infrastructure and run both on identical traffic

The single most useful property of this migration is that the physical layer is vendor-neutral. TAPs, SPAN ports, and packet brokers deliver a copy of traffic to whatever consumes it, so a packet broker can feed Darktrace and a Security Onion sensor simultaneously.

That enables the comparison this project needs. Deploy a sensor on a duplicated feed from a representative segment and run both systems on byte-identical traffic for months. Then compare, in both directions and with discipline:

• Model breaches Darktrace raised that Security Onion did not. Each is a detection you need to write, or a deliberate decision to accept the gap.
• Suricata or Zeek alerts Darktrace did not raise. Some are noise to tune, some are real coverage you did not previously have, because signature-based detection catches known-bad that a behavioural model may treat as unremarkable.

Keep a written log of both columns. That log, not a vendor comparison chart, is the evidence that authorises removing the appliance, and it is also the backlog for your detection-engineering work.

Storage is the decision that actually costs money

Darktrace’s appliance is sized by the vendor for your licensed bandwidth. With Security Onion, retention is your architecture and your capital expenditure.

The three data types have wildly different economics. Zeek logs are structured, compact, and the most useful thing you have for investigation months later, so keep them long. Suricata alerts are tiny. Full packet capture is enormous, and a busy link can produce terabytes a day.

The pattern that works is tiered and deliberate: long retention on Zeek logs across the whole monitored estate, short rolling-window packet capture (days, not months) sized to cover the gap between an incident happening and someone noticing, and full packet capture only on segments where it genuinely earns its disk, typically the DMZ, the crown-jewel segments, and anything under a specific regulatory obligation.

Decide this before you buy hardware, because retrofitting storage into an under-specified sensor is more expensive than sizing it correctly once.

Replacing autonomous response

If Antigena is actively containing activity in your environment today, that capability does not exist in Security Onion and needs an explicit replacement.

There are three practical routes and they are not mutually exclusive. Suricata can run inline as an IPS on chosen segments, which gives you real blocking but places a detection component in the traffic path and therefore in your availability model, so it belongs only on segments where you accept that. SOAR automation can react to detections by calling your firewall or NAC API to isolate a host, which is more flexible and slower. Or you can decide that autonomous response was never used in blocking mode anyway, which is more common than vendors like to admit, and drop the capability with a documented decision.

Whichever route, decide it during design. This is not a follow-up item.

Order of operations

1. Confirm someone will own detection engineering as a named, funded responsibility. If not, stop here.
2. Audit Darktrace model breaches over the last year: which were actioned, and what would have detected them explicitly.
3. Determine whether Antigena is actually enforcing, and design its replacement if so.
4. Size storage by tier (Zeek long, PCAP short and selective) before purchasing hardware.
5. Duplicate the TAP feed so both systems see identical traffic on a representative segment.
6. Deploy Security Onion, tune Suricata rulesets, and enable the Zeek scripts relevant to your protocols.
7. Run both for a full quarter, logging every detection discrepancy in both directions.
8. Write detections to close the gaps the log identified, and re-run the comparison.
9. Expand sensor coverage segment by segment, retiring Darktrace probes only on segments where the comparison is closed.
10. Decommission the appliance at the subscription boundary, not before the comparison concludes.

Clearing the bar before you cut over

Per segment: Security Onion is ingesting the full traffic feed with no drops under peak load, the detection-discrepancy log is closed or has documented accepted gaps, Zeek and Suricata content is version-controlled with a named owner, storage retention meets the documented obligation and has survived a peak week, response automation (if replacing Antigena) has been tested end to end, and analysts have investigated real activity using Zeek logs rather than the Darktrace interface.

The short version

Darktrace to Security Onion trades an unauditable model for detections you write, own, and can explain, at a fraction of the running cost and with a real reduction in unsupervised-anomaly coverage. The TAP infrastructure is reusable, which makes a long side-by-side comparison on identical traffic both possible and mandatory: that comparison log is the project. Size storage by tier before buying hardware, replace autonomous response deliberately if you actually use it, and do not start unless detection engineering has a named owner. The calculator above gives illustrative economics; the sensors, disks, and engineer are the real cost.