Security Onion or Elastic Security: which fits your team
Choose Security Onion when you want a prebuilt network security monitoring stack on one distribution: Suricata for network detection, Zeek for protocol metadata, Strelka for file analysis and full packet capture, with Elasticsearch and Elastic Fleet already wired together during setup. Choose Elastic Security when you already run Elasticsearch or intend to build a broader data platform on it, and you need SIEM detections and endpoint protection on a stack your own team will extend. Licensing does not separate them. Security Onion components and Elastic's default distribution are both licensed under the Elastic License 2.0, so the question is what you build, what you must pay for, and who operates it.
Three questions decide the fit. First, how much network visibility do you need? If you must see east-west traffic, run NIDS rules and keep packet captures for investigations, Security Onion gives you that on day one, and its minimum hardware (4 cores, 24 GB RAM and 200 GB of storage for a standalone node) is documented before you buy. Second, which Elastic features must you pay for? Security Onion's documentation notes that Elastic Defend has free and paid features and that only the free ones are enabled by default, and controlling which Fleet Server endpoints agents connect to requires custom firewall rules or a paid Elastic license. Confirm the current Elastic subscription terms for endpoint prevention, host isolation and single sign-on with Elastic before you commit. Third, who will operate it? Security Onion is an opinionated appliance-style distribution, while Elastic Security is a set of components you assemble and maintain.
Before you choose, run a short proof of concept on representative traffic and map your required detections, identity integration and retention to each platform's licensed features. Ask Elastic in writing which subscription tier covers each control you listed. Ask Security Onion Solutions which Pro features you need, such as OIDC single sign-on or FIPS mode, and whether they apply to your deployment. A scoped implementation partner can document both paths against the same requirements, but the decision should rest on your own traffic and staffing.
Which platform fits which team scenario
This table compares Security Onion and Elastic Security across six team scenarios, naming the better fit and the condition under which the other platform wins. Read each row against your own sensor placement, existing estate and staffing, then confirm the licensing and feature points noted in the cells before you commit.
| Scenario | Better fit | Reason and when the other platform wins |
|---|---|---|
| Network-first SOC | Security Onion | It bundles Suricata, Zeek, full packet capture and a NIDS rule workflow in one distribution, so network telemetry is available without assembling those parts yourself. Elastic Security wins if your primary need is endpoint and SIEM correlation across many non-network sources. |
| Existing Elastic estate | Elastic Security | If you already run Elasticsearch and Kibana with Elastic Agent and Fleet, adding detections and cases to that estate avoids a second stack. Security Onion wins if you want its prebuilt Suricata, Zeek and Sigma workflow and accept that it manages its own Elastic deployment. |
| Endpoint-heavy environment | Elastic Security | Elastic Defend's endpoint prevention, host isolation and response features are central to Elastic Security. Confirm which of these you need, since Security Onion enables only the free Elastic Defend features by default and malware prevention and host isolation sit in the paid Enterprise tier. |
| Air-gapped site | Security Onion | Security Onion documents full installs without internet access, with its ISO carrying packages and NIDS, YARA and Sigma rules, and updates applied from newer ISO media. Elastic Security can run self-managed in isolated networks, but you must plan rule and package delivery yourself and confirm that process with Elastic. |
| Small team without dedicated engineers | Security Onion | A standalone deployment is a single managed distribution, which reduces the number of components your staff must integrate and upgrade. Elastic Security wins if you already have engineers who run Elasticsearch well and prefer to build a smaller, purpose-selected stack. |
| Multi-site Elastic programme | Elastic Security | Multi-site programmes that need centrally managed Fleet policies, Elastic Cloud or enterprise subscription features benefit from the Elastic stack's own tooling. Security Onion suits sites that each run a distributed deployment, but confirm whether Fleet endpoint control across sites meets your requirement, since controlling Fleet server endpoints needs custom firewall rules or a paid Elastic license. |
How each platform is built and what that means for operations
Security Onion and Elastic Security both sit on Elasticsearch and Elastic Agent, but they differ in how much is bundled, how nodes are laid out, and which components you run yourself. The cards below cover the parts that shape day-to-day operations, along with the checks to make before committing.
Security Onion bundles the sensor stack
Security Onion ships Suricata, Zeek, Strelka, full packet capture, Elasticsearch and Elastic Agent in one distribution. The network sensing, detection content and log pipeline arrive together, so the team inherits one install, one upgrade path and one support boundary. The trade-off is that you run the whole stack, including components you may not use. Confirm which sensors you need before you size the deployment.
Node roles in a distributed layout
The recommended production layout separates a manager node from sensor nodes and search nodes, and receiver nodes can add pipeline redundancy and load balancing. Each role has its own hardware minimum, so the bill of materials grows with the layout. Ask your team to map which node carries which traffic and where log volume will peak before you choose the number of search nodes.
The manager's Redis dependency
If the manager goes down, search nodes stop indexing because they cannot reach Redis. Manager availability therefore decides ingest availability for the whole grid, not only for the console. Plan backup, restore and failover for the manager first, and test how long a manager outage can last before your log retention or detection obligations are affected.
Elastic Agent and Fleet as the control plane
Elastic Security runs on Elasticsearch and Kibana, and Elastic Agent is the single agent that collects logs, metrics and security data, managed centrally through Fleet. You build the cluster, policies and integrations yourself, which gives flexibility over index design and retention. Check that your team can own Fleet policy, agent version alignment and Elasticsearch cluster health on its own.
Elastic Defend as an add-on
Elastic Defend is the endpoint detection and response component of Elastic Security, and its free and paid features differ. Security Onion enables only the free features by default, and controlling which Fleet Server endpoints agents connect to requires custom firewall rules or a paid Elastic license. Confirm which Defend capabilities your endpoint program needs, and price the paid tier against those needs, before you plan the agent rollout.
Agent and stack version alignment
Security Onion advises using an Elastic Agent version that matches the Elastic stack version it runs, because agents newer than the stack may cause errors. In a self-built Elastic deployment, your team controls both versions, so it must plan agent and stack upgrades together. Ask each platform's team how they test upgrades across the grid and what rollback path they document.
What each license covers and what is paid for
Security Onion's own components and the Elastic components it bundles are licensed under the Elastic License 2.0 (ELv2), and the installer asks the operator to accept that license during setup. ELv2 is source-available and is not OSI approved, so you can read the code and run it inside your own environment, but the license forbids offering the software as a managed service. The free distribution carries no license fee of its own, so your spending goes to hardware, the staff who operate the platform and any paid support or Pro license you add.
- Covered by ELv2: the Security Onion components and the bundled Elastic components, as described on the license page.
- Free distribution: you can download, install and run the free edition without a Security Onion license fee.
- Managed service limit: a third party cannot sell hosted Security Onion to customers under these terms, so confirm how any outsourced operator is licensed.
- Recurring spend: hardware refreshes, storage growth and staff time recur every year, while the free license does not.
- Elastic Defend: the free Defend features are enabled by default, and paid features require an Elastic license.
Ask Security Onion Solutions to confirm in writing how ELv2 applies to your planned hosting model before you design around it.
Security Onion Pro is a paid edition sold on 1 to 5 year terms. It adds operator features for teams that must meet identity, encryption and hardening requirements or run several deployments, and it includes professional support. Pro does not change the underlying open distribution, so the platform you evaluate for free stays the same platform you would license.
- Identity and encryption: OIDC single sign-on for the Security Onion Console, LUKS data-at-rest encryption and FIPS mode.
- Hardening: OS STIG compliance, which matters when your baseline requires STIG-aligned hosts. Confirm the benchmark version with the vendor.
- Integration: the Security Onion API, an MCP server and external notifications.
- Scale and assistance: Manager of Managers for coordinating multiple deployments, the Onion AI assistant and professional support.
- Term commitment: a 1 to 5 year term turns the license into a recurring line item that you must budget for and renew.
Request the Pro terms, the support scope and the expiry behavior in writing, since these determine the contract length you should accept.
Elasticsearch and Kibana, the stack under Elastic Security, are distributed under ELv2 by default, and the source code is also offered under SSPL 1.0 and AGPLv3. Elastic added the AGPLv3 option in 2024, before the 8.16 release. The source license governs how you may use the code, while paid Elastic Security features are controlled by subscription tier, so the two questions need separate answers.
- Default license: most users take the ELv2 terms without making a separate choice.
- Alternative source licenses: SSPL 1.0 and AGPLv3 are available for the source code, which matters if your legal team has a policy on one of them.
- Free tier: the Free and open (Basic) tier is available for self-managed deployments.
- Enterprise features: endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise.
- Platinum retired: the detection engine, machine learning anomaly detection and case management were listed under Platinum, which Elastic no longer sells to new customers.
Map each feature you need to a current tier on the subscription page, and confirm the detection engine tier before you assume it is free.
For self-managed deployments, new buyers of paid security features choose between Basic and Enterprise or move to Elastic Cloud. Basic gives you the stack and its free security capabilities, while Enterprise adds the endpoint prevention, host isolation and single sign-on features that regulated teams often ask about first. Elastic Cloud changes who operates the infrastructure, which changes the cost structure without removing the subscription question.
- Basic: free and open, suited to teams that need the stack and free features and can accept the gaps listed under Enterprise.
- Enterprise: a paid subscription for self-managed deployments, quoted by Elastic.
- Elastic Cloud: hosted by Elastic, so your recurring cost shifts from hardware and platform staff hours toward the service fee.
- Defend features: Security Onion enables only the free Elastic Defend features by default, so paid features need deliberate enablement under a valid Elastic license.
- Fleet control: Security Onion manages Fleet output and download settings itself, and restricting which Fleet Server endpoints agents reach requires custom firewall rules or a paid Elastic license.
Ask Elastic for a written tier comparison for your deployment model, and ask which Fleet and Defend capabilities your license enables.
Capability comparison from supplied facts
This table sets Security Onion against Elastic Security on the points that usually decide a shortlist: license, network monitoring, endpoint coverage, detection content, single sign-on, air-gap support, hardware and release line. Read the Elastic column as the capability of the platform in general, then check the tier you would actually buy, because several Elastic features depend on a paid subscription.
| Capability | Security Onion | Elastic Security |
|---|---|---|
| License | Elastic License 2.0 for Security Onion and Elastic components; not OSI approved and bars offering it as a managed service | Elasticsearch and Kibana default to Elastic License 2.0, with SSPL 1.0 and AGPLv3 also offered for source; paid features sit in subscriptions |
| Network monitoring | Suricata, Zeek and full packet capture (Suricata replaced Stenographer in 3.0.0) ship in the distribution | Not bundled as a sensor stack; network data is brought in through Elastic Agent and integrations, so confirm sensor coverage with Elastic |
| Endpoint protection | Elastic Agent on every grid node; Elastic Defend free features enabled by default, paid features not active by default | Elastic Defend provides endpoint detection and response; malware and ransomware prevention and host isolation are listed under Enterprise |
| Detection content | Console manages NIDS rules for Suricata, Sigma rules for ElastAlert and YARA rules for Strelka, with tuning and suppression | Prebuilt rules from elastic/detection-rules delivered to the detection engine; custom rules and alert suppression; confirm Sigma import needs with Elastic |
| Single sign-on | OIDC single sign-on requires Security Onion Pro | SAML or OpenID Connect single sign-on is listed under Enterprise; confirm availability for your tier |
| Air-gap support | Full install without internet; ISO carries packages and NIDS, YARA and Sigma rules, updated with soup from newer media | Self-managed deployment is possible; confirm offline update and rule delivery steps for your environment |
| Hardware minimums | Standalone: 4 cores, 24 GB RAM, 200 GB storage, 2 NICs; manager or search node 16 GB RAM; sensor 12 GB RAM (x86-64 only) | Sized by the chosen Elastic deployment; no fixed minimum in the supplied facts, so request sizing from Elastic |
| Release line and current version | Security Onion 3.3.0 (hotfix 20260911) on Oracle Linux 9; 2.4 reached end of life October 1, 2026 | Elastic 9.5.5 and 9.4.8 released October 6, 2026; 8.19.23 still maintained |
Moving between the two without rebuilding everything
This sequence shows which parts of a Security Onion or Elastic Security deployment carry across, which must be rebuilt, and how to confirm each stage before the next one starts. Most of the effort falls on rule mapping and agent rebuilds, because dashboards and tuning depend on each platform's own data model. Treat the steps as a plan to confirm against your own sources, versions and licenses.
Inventory data sources and detections
The SOC lead and platform owner list every log source, sensor and network feed on the current platform, then export each enabled detection with its status, tuning, suppression and threshold settings. On Security Onion, this covers Suricata NIDS rules, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka, all managed in the Detections interface. On Elastic Security, include prebuilt rules you have customized and every exception you have added. The step is complete when the inventory has one row per source and one row per detection, and each row names an owner and a target platform.
Confirm versions, editions and licensing
The platform owner checks the current release lines before building anything. Security Onion 2.4 reached end of life on October 1, 2026, and 2.4 installs on Oracle Linux 9 can upgrade to 3 only after full packet capture moves from Stenographer to Suricata. Other distributions on 2.4 need a fresh install, so plan for a fresh build instead of an in-place upgrade. On the Elastic side, endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under the Enterprise subscription, and Platinum is no longer sold to new customers. The check is a written list of editions, versions and the Elastic Agent version that matches the target stack.
Map Sigma, NIDS and YARA content
The detection engineer sorts each inventoried rule into one of three groups: rules that carry over as written, rules that need conversion, and rules with no equivalent on the target. Sigma is designed as a shared format, so those rules are usually the easiest to carry, but conversion to the target's query language and field names still needs review and testing. Suricata rules and Strelka YARA rules stay useful only where the matching sensor or file scanning component is kept in the design. Index mappings rarely carry over unchanged, so treat any reindex as a tested project with its own validation. The output is a mapping table with a recorded test result for each rule, and no rule reaches production without that record.
Rebuild agents and Fleet policies
The platform engineer rebuilds the collection layer on the target. Security Onion pre-configures Fleet during setup, installs Elastic Agent on every grid node and enrolls it in the so-grid-nodes policy, and manages Fleet output and download settings itself. Controlling which Fleet Server endpoints agents connect to requires custom firewall rules or a paid Elastic license. On Elastic Security, the team builds its own Fleet policies and decides which Elastic Defend features to enable, since Security Onion enables only the free features by default. Keep agent versions aligned with the stack, because a newer agent can cause errors. The check is that every host enrolls, reports in and shows the expected integrations in Fleet.
Rebuild dashboards, tuning and suppressions
Analysts rebuild dashboards, saved searches and case workflows on the target, because these objects are tied to each platform's data model and do not move cleanly between them. Thresholds, suppressions and custom filters are re-entered and retested against the target's field names and recent baselines. Security Onion offers modify, suppress and threshold tuning for NIDS rules and custom filters for Sigma, while Elastic Security uses its own rule customization and alert suppression. The check is a side-by-side review of the same test period on both platforms, confirming that alert volume and top detections after tuning match what the SOC expects.
Run both platforms in parallel
Keep the source platform receiving the same traffic while the target runs the mapped rules. Compare alert volume, severity and results from the test cases recorded during mapping, and investigate every gap in both directions: missed detections on the target and new noise that the source never produced. Record each finding with an owner and a decision. The length of the parallel run is not fixed by this plan, so agree written exit criteria with the SOC before starting and confirm them against your own environment. The run is complete when every critical detection fires on the target in the agreed test set and noise sits within the level the SOC accepted.
Cut over alerting and response
The platform owner switches alerting, on-call routing and analyst workflows to the target. Each downstream integration that consumes alerts, such as ticketing and notifications, is repointed and tested on the target before the old route is removed. The source platform stays running in read-only mode for lookups during the transition. The check is that a sample of production alerts flows end to end to the ticketing system, and that an analyst can open, investigate and close them in the target's case workflow without relying on the source platform.
Retire the source platform
Before shutting down any node, archive what compliance or incident response may need from the old platform: retained logs, alert history, rule exports and configuration backups. Confirm retention obligations with your legal and compliance owners, since they determine what must be kept and for how long. Then decommission sensors, agents and search nodes in a planned order, removing firewall rules and Fleet enrollments as each one goes. The check is a signed-off archive inventory, a restore test on at least one archived item and an updated asset register that no longer lists the retired platform.
What drives running cost for each platform
Running cost on Security Onion is mostly hardware, staff time and the decision about paid features, while on Elastic Security it is mostly licensing and Elasticsearch operations. Security Onion's published minimums are 4 cores, 24 GB RAM and 200 GB storage for a standalone node, with 4 cores and 16 GB RAM for a manager or search node and 4 cores, 12 GB RAM and 2 NICs for a sensor, and the hardware documentation suggests 32 GB of RAM or more once even a small amount of traffic is monitored. Storage grows with retention and packet capture volume, so the recurring cost is disk and the hardware refresh that follows. On the Elastic side, the stack is the same Elasticsearch and Kibana, so the same disk, memory and cluster costs apply, plus any Elastic subscription you choose. Ask each vendor or partner to quote hardware by node role, retention days and expected ingest, not a single box size.
Licensing is the cost line most often misread. Security Onion components are under ELv2, and Security Onion Pro is a paid per-node license on 1 to 5 year terms that adds OIDC SSO, FIPS and STIG hardening and the Security Onion API. On Elastic, features like host isolation, malware and ransomware prevention and SAML or OpenID Connect SSO sit under the Enterprise subscription, and Platinum is no longer sold to new customers. Check which features your use case depends on before you compare totals, and ask for the subscription tier, term and renewal terms in writing. Also confirm whether Security Onion's Fleet endpoint control, which the documentation says requires custom firewall rules or a paid Elastic license, is part of your design.
Skills and migration are recurring and one-time costs that quotes often omit. Running either platform well requires Linux administration, Elasticsearch tuning, index lifecycle management and detection engineering, and Security Onion's architecture notes that search nodes stop indexing if the manager is down, so on-call coverage matters. Plan for a parallel run in which both stacks ingest the same sources, and for Security Onion 2.4 to 3.x upgrades that may require a fresh install on distributions other than Oracle Linux 9. Ask any implementation partner to separate fixed-scope build work from retainers for upgrades, testing and support, and to state who pays for the parallel run and for detection content maintenance.
Questions buyers ask before choosing or hiring help
Which is cheaper to run, Security Onion or Elastic Security?
Neither is free to run at production scale, and the answer depends on what you count. Security Onion's software is free under the Elastic License 2.0, and its paid Security Onion Pro edition is optional, so recurring cost is mostly hardware, staff time and any outside help. Elastic Security's free Basic tier carries no license fee, but detections, machine learning and endpoint prevention features sit in paid Enterprise subscriptions, and Platinum is no longer sold to new customers. The main drivers are how many sensors and search nodes you need, how much data you retain, how many analysts tune detections, and which paid features your use case requires. Ask any vendor or partner for a written quote that lists hardware, licenses, support and recurring tasks separately.
Can a small team operate Security Onion on its own?
A small team can run a standalone Security Onion node, but a production deployment asks more of its staff. Security Onion's architecture documentation recommends a distributed design with a manager node, search nodes and sensor nodes, and notes that search nodes stop indexing if the manager goes down. Your team also has to handle sensor placement, detection tuning in the Console, upgrades and the choice of Elastic Agent versions that match the stack. Security Onion is a full distribution, so the work is closer to operating an appliance than assembling components. Ask whether your analysts have time for a weekly tuning cycle, and whether you want outside operators for upgrades and incident support.
Do the free Elastic Security features cover what my SOC needs?
The free Basic tier covers basic log ingestion and search, but many detection and response capabilities need a paid subscription. Elastic's subscriptions page places the detection engine's full set, machine learning anomaly detection and case management under Platinum, while endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise. Security Onion's documentation notes that Elastic Defend has free and paid features and that only the free ones are enabled by default. Map your required detections, response actions and identity controls against the current subscription page before deciding, and confirm the exact feature split with Elastic.
Can we move from Security Onion to Elastic Security later?
Yes, but expect a rebuild rather than a switch. Both products run on Elasticsearch and Kibana, which makes data and detection content easier to carry across than in a product with a proprietary store. Still, Security Onion bundles its own Console, ElastAlert and Strelka rule workflows, Suricata and Zeek sensor layouts, and Fleet policies such as so-grid-nodes, so you would need to rebuild those in Elastic's model. Detection content from the public elastic/detection-rules repository is licensed under ELv2 and can inform the rebuild. Before committing, document your sensors, rules, tuning files and retention settings, and ask any implementation partner for a migration scope in writing.
What skills do my staff need for either platform?
Both platforms need Linux administration, Elasticsearch and Kibana familiarity, and detection engineering skills for tuning rules and reducing false positives. Security Onion adds network security monitoring knowledge, because Suricata, Zeek and full packet capture produce the data your analysts read, and sensor placement affects what you see. Elastic Security adds more emphasis on index lifecycle, Fleet policy design and the subscription feature set. Staff without any of these skills should plan for training or outside help before the first production day. Ask a partner which skills their scope assumes your team already has.
How long does a typical rollout take?
Duration depends on scope, so confirm it during scoping rather than relying on a general estimate. The main variables are the deployment type (import, evaluation, standalone or distributed), the number of sensor and search nodes, the number of log sources to onboard, the amount of detection tuning you want at go-live, and whether the network is air-gapped. Hardware lead times and change approval windows often matter as much as the software work. Ask for a written timeline with milestones, the acceptance tests for each stage, and the assumptions it depends on, such as who provides hardware and access.
Do I need Security Onion Pro for production use?
Not necessarily. The free Security Onion distribution runs production deployments, but Security Onion Pro adds features that some regulated environments require. Its documented additions include OIDC single sign-on for the Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers and professional support. Pro is sold per node on 1 to 5 year terms, so you should confirm what happens to your deployment when a license expires before buying. If your identity, encryption or hardening requirements map to those features, price Pro against the effort of building the same controls yourself.
Are air-gapped installs supported on each platform?
Security Onion supports full installs on networks without internet access. Its ISO carries packages along with NIDS, YARA and Sigma rules, and the soup update tool can apply updates from newer ISO media in airgap mode. For Elastic Security, air-gapped support depends on how you deploy Elastic Stack and which packages, rule updates and agent artifacts you can mirror internally, so confirm the exact procedure with Elastic and your own environment. Whichever platform you choose, plan how you will bring in rule updates, threat content and software patches, and test that process before go-live.
Decision risks to check before you commit
Each risk below changes cost, support or exit options for a Security Onion or Elastic Security deployment, and most are settled by written answers from the vendor rather than by testing. Check them with Security Onion Solutions, Elastic, your legal team and your own infrastructure team before you choose.
Platinum tier is closed to new buyers
Elastic lists the detection engine, machine learning anomaly detection and case management under Platinum, and that tier is no longer sold to new customers. A self-managed buyer who wants these features must choose Enterprise, or move to Elastic Cloud. Ask Elastic which tier includes each feature you need, and get the Enterprise price in writing before you size the project. Illustrative: a team that costed Platinum features in an older quote will need a new quote.
ELv2 limits on managed services
Both Security Onion and Elastic Security components are licensed under the Elastic License 2.0, which is source-available and not OSI approved. ELv2 forbids offering the software as a managed service, so a provider running it for other organizations needs a license review. Ask your counsel whether your planned hosting or managed model falls inside that restriction, and confirm the same for any Elastic components you add.
Security Onion version lifecycle
Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024. Security Onion 3.0.0 supports only Oracle Linux 9, so a 2.4 install on another distribution needs a fresh install rather than an in-place upgrade. Confirm the operating system you must run, the upgrade path for your current version, and the support window in writing before you commit.
Hardware sizing underestimated
Security Onion lists 4 cores, 24 GB RAM and 200 GB storage as bare minimum for a standalone node, and suggests 32 GB of RAM or more even for small traffic volumes. Production designs use separate manager, search and sensor nodes, and the search nodes need disk sized for your retention. Ask for a sizing review against your traffic and retention targets, and confirm the sensor NIC count before ordering hardware.
Elastic Defend feature gating
Security Onion enables only the free features of Elastic Defend by default, and Elastic lists malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise. A team that expects endpoint prevention on day one may find it is not in the default configuration. Map each endpoint control you need to a tier, and confirm with Elastic which features your license activates.
Single Fleet control plane dependence
Security Onion manages Fleet output and download settings itself, and controlling which Fleet Server endpoints agents connect to requires custom firewall rules or a paid Elastic license. Its architecture notes that search nodes stop indexing if the manager goes down, so the manager is a single point of failure unless you plan for it. Ask your architects how agent enrollment, policy changes and recovery behave during a manager outage, and test that path before go-live.
How DeployOpen helps you choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Security Onion versus Elastic Security decision, that means we can help you test both options against your own network, log sources and retention needs before you commit. We do not favor either platform. A fair evaluation starts with the question of whether you want the bundled sensor stack and its Elastic License 2.0 distribution, or whether you want to build detections and sensors directly on Elasticsearch and Kibana.
If you choose Security Onion, the decisions that most affect cost are the deployment type, the number of search and sensor nodes, and whether you need the Pro-only features such as OIDC single sign-on or FIPS mode. If you choose Elastic Security, the decisions to settle early are which features your team needs from the free Basic tier, whether Enterprise subscription features are required, and whether self-managed or Elastic Cloud fits your hosting rules. Confirm current edition terms directly with Elastic and Security Onion Solutions, since their licensing pages change. We can document the answers in the written scope.
Most of our engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A migration between the two platforms is a separate scope that covers rule and detection conversion, agent and sensor changes, and historical data handling. We also offer retainers for ongoing support, upgrades and continuous testing. We do not publish a price list, so ask for a quote that follows from your written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any attestation or certification.
