Security Onion vs Malcolm: which to choose

Security Onion vs Malcolm: which fits your SOC or OT network?

Security Onion suits a SOC that wants hunting and alerting on an Elastic stack, with Suricata, Zeek and full packet capture in one distribution. Malcolm suits a team that needs deep ICS protocol parsing and Arkime session analysis under the Apache License 2.0. Choose on the network you monitor first, then on the license terms you accept, because the two stacks differ on both. A corporate IT network with a SOC analyst team points toward Security Onion. A plant or utility network with Modbus, DNP3, S7comm or other industrial protocols points toward Malcolm.

Four factors decide the choice. The first is the monitored network: Malcolm's documented ICS parsing covers protocols such as BACnet, DNP3, Modbus, PROFINET and S7comm, and you should confirm that your specific devices and firmware are covered before committing. The second is the license you accept. The Elastic License 2.0 that governs Security Onion forbids offering the software as a managed service, which matters if you plan to run it for other organizations. The third is whether you want a paid tier. Security Onion Pro adds OIDC single sign-on, FIPS and STIG hardening and the API, while Malcolm's stack is open source end to end, so ask your own compliance lead which of those controls you must evidence.

The fourth factor is who operates the platform. Security Onion's distributed design of manager, search and sensor nodes is built for a standing team, and Malcolm's container deployment is documented for long-term use on a Linux server or short-term response on a laptop. Ask your integrator to scope the hardware, the sensor placement across both networks and the tuning effort in writing before work starts, because those costs recur long after installation. If you run both IT and OT monitoring, the Security Onion architecture documentation is the natural next read to compare the node layout against your segmentation.

Which monitoring scenario fits Security Onion and which fits Malcolm

This table maps common monitoring scenarios to the platform that fits better and explains the condition behind each choice. Read each row as a starting point, then confirm the license, hardware and protocol requirements against your own environment before deciding.

Scenario	Better fit	Reason and condition
Corporate SOC watching IT networks	Security Onion	It bundles Suricata, Zeek, full packet capture, Elasticsearch and Elastic Agent in one distribution with a Console for detections. This fits when the team wants one product for alerting and hunting, and it accepts running under Elastic License 2.0 terms.
OT or ICS network with Modbus, DNP3 or S7comm traffic	Malcolm	Malcolm's documentation lists ICS and OT protocols parsed by Zeek, including Modbus, DNP3, S7comm, EtherNet/IP and PROFINET. Confirm that the specific PLC and protocol variants in your plant appear in that list before relying on it.
Incident response on a laptop	Malcolm	Malcolm can run on a laptop for short-term incident response, and installation ISOs are published. Security Onion's standalone minimum of 4 cores, 24 GB RAM and 200 GB storage makes it a heavier fit for a portable kit.
Long-term monitoring on a dedicated Linux server	Either, depending on license terms	Both run as self-hosted Linux stacks for long-term use. Choose Security Onion if you accept ELv2 and want its integrated console, or Malcolm if you need Apache-2.0 terms and Arkime session search.
Team that wants a paid support tier	Security Onion	Security Onion Pro is a paid edition on 1 to 5 year terms with professional support, OIDC SSO, FIPS and STIG hardening. Confirm the support terms and per-node licensing in the Pro offering before budgeting.
Team that must avoid ELv2 terms	Malcolm	Malcolm is Apache-2.0, while Security Onion's repository is under the Elastic License 2.0, which is source-available rather than OSI approved. Have legal review the ELv2 restriction on offering the software as a managed service if you plan to host it for others.
Team that needs dashboards with session-level network search	Malcolm	Malcolm uses Arkime to find and identify network sessions alongside OpenSearch Dashboards with prebuilt dashboards. Security Onion centers on Suricata and Zeek alerts and hunting within its Console.
Team that needs Kubernetes-based deployment	Confirm before choosing	Malcolm documents Kubernetes deployment with standard manifests, but describes it as new and somewhat experimental. Security Onion's documented production design is a distributed manager, search and sensor layout, so confirm which fits your platform team.

How each suite is built and what that means for operations

Security Onion and Malcolm both start from Zeek and Suricata, but they package the rest of the stack very differently. The layout you pick decides how you patch, scale and recover the platform, and several of those behaviors need confirmation in a lab before you commit.

Security Onion distributed layout

Security Onion's recommended production design separates a manager node from one or more search nodes and sensor nodes, with optional receiver nodes that add pipeline redundancy and load balancing. Each role is a separate machine you patch, size and recover. Scaling usually means adding sensors for more capture or search nodes for more indexing, which adds hardware and configuration work at each step. Check how your chosen node roles map to your traffic volume and retention targets before sizing the cluster.

Redis dependency on the manager

In a distributed Security Onion deployment, search nodes stop indexing if they cannot reach Redis on the manager. A manager outage therefore halts log ingestion into search, even when sensors keep capturing traffic. Plan a maintenance window for manager patching and an alerting path that tells you when search nodes fall behind. Ask the vendor how much traffic buffers at the sensors during an outage and whether receiver nodes change that behavior in your topology.

Oracle Linux 9 only in version 3.0.0

Security Onion 3.0.0 supports only Oracle Linux 9, so your host operating system choice is fixed by the release, not by your standard build. Teams that run other distributions cannot upgrade in place and need a fresh install, according to the end-of-life guidance. Confirm that your OS image, hardening baseline and patch cadence match Oracle Linux 9 before you plan the rollout, and test the 2.4 to 3.x path in a lab first if you have a running 2.4 deployment.

Malcolm container stack

Malcolm runs as a set of containers managed by setup and run-time scripts. The project describes it as suited to long-term use on a Linux server in a SOC, and also to short-term incident response on a laptop, with installation ISOs published. Patching usually means pulling new images and rerunning the scripts, so your change process must cover the container host and the application together. Confirm the upgrade steps and any data migration path for your Malcolm version with the maintainers before going live.

OpenSearch Dashboards and Arkime layers

Malcolm pairs OpenSearch Dashboards, which carries dozens of prebuilt dashboards, with Arkime, which finds and identifies network sessions. Analysts move between the two views, so a slow or unavailable index affects both the visualization and the session search. Storage and index sizing must account for full packet capture as well as Zeek logs and Suricata alerts. Ask for the expected index and capture storage per day of retention, and test session search speed against realistic traffic in a lab.

Kubernetes deployment still experimental

Malcolm documents Kubernetes deployment with standard manifests, including an Amazon EKS guide, but the project calls it a new and still somewhat experimental feature. Choosing it means accepting a less-proven path in exchange for cluster-native scaling and recovery. Ask the maintainers which features are supported on Kubernetes, how packet capture storage is handled, and what support exists for upgrades. Use a non-production cluster to rehearse failover before you depend on it.

Hedgehog Linux sensor option

Malcolm documents Hedgehog Linux as its network sensor appliance, which gives you a purpose-built capture box rather than a general server build. This narrows the patching surface on the sensor side, but it adds an appliance lifecycle you must track separately from the Malcolm host. For OT networks, confirm with the vendor how the appliance is updated inside a segmented network, how it is hardened, and whether it fits your site's change windows.

Security Onion vs Malcolm feature by feature

This table compares Security Onion and Malcolm on license, detection content, packet capture, session analysis, ICS parsing, asset inventory, threat intelligence, authentication, search backend, deployment targets and paid tiers. Read each row against your own network: where a cell says to confirm, the supplied facts do not settle that point for that platform.

Capability	Security Onion	Malcolm
License	Elastic License 2.0, source-available and not OSI approved, which forbids offering the software as a managed service	Apache License 2.0, an OSI-approved permissive license
Detection content	Console Detections manage NIDS rules for Suricata, Sigma rules for ElastAlert and YARA rules for Strelka, with modify, suppress and threshold tuning	Zeek logs and Suricata alerts are normalized and correlated; confirm the detection rule sources and tuning workflow you need in the current documentation
Packet capture	Suricata full packet capture, which replaced Stenographer in Security Onion 3.0.0	Processes uploaded full packet capture files and live traffic from lightweight forwarders
Session analysis	Console workflows built on Zeek and Suricata metadata; confirm session search depth against your analyst process	Arkime finds and identifies network sessions, alongside OpenSearch Dashboards with prebuilt dashboards
ICS and OT protocol parsing	Confirm which ICS protocols its Zeek and Suricata configuration parses in your version before relying on it	Zeek parses BACnet, DNP3, Modbus, PROFINET, S7comm, IEC 60870-5-104 and other ICS and OT protocols, with a smaller subset parsed by Arkime
Asset inventory	Confirm whether a native asset inventory or external CMDB integration meets your requirement	NetBox is documented for asset inventory
Threat intelligence sources	Confirm the threat intelligence feeds and Zeek Intelligence Framework integration available in your edition	MISP and STIX/TAXII are documented as Zeek Intelligence Framework sources
Authentication options	Console sign-in is included; OIDC single sign-on is a Pro feature, and Pro also adds LUKS encryption and FIPS mode	Keycloak or LDAP authentication is documented; confirm the exact setup for your identity provider
Search backend	Elasticsearch, under Elastic License 2.0	OpenSearch with OpenSearch Dashboards, under Apache-2.0
Deployment targets	Standalone or distributed deployment on x86-64 with manager, search and sensor nodes; supports airgap installs from ISO media	Containers on a Linux server, a laptop for short incident response, and Kubernetes manifests that the documentation calls still somewhat experimental
Paid tier	Security Onion Pro, a paid license on 1 to 5 year terms that adds OIDC SSO, LUKS, FIPS, STIG compliance, the API and professional support	No paid edition is documented in the supplied facts; confirm any commercial support path with the project

What the licenses allow and what the paid edition adds

Security Onion's repository is licensed under the Elastic License 2.0 (ELv2), which the project describes as source-available rather than OSI-approved open source. Security Onion components moved from the GPL to ELv2 starting with Security Onion 2.4, announced on August 31, 2022. The license lets you inspect, run and modify the software for your own use, but it forbids offering the software as a managed service to third parties.

Source-available: The code is visible and usable, but ELv2 is not an OSI-approved license, so it does not meet the open source definition some procurement policies require.
Managed service restriction: You cannot sell access to a hosted Security Onion instance to outside customers under ELv2.
Free edition: The distribution is free to run within the terms of the license.
Pro terms: Security Onion Pro is a paid edition sold on 1 to 5 year terms, priced per node.
Pro features: Pro adds OIDC single sign-on, 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.

Confirm the current Pro price, node count rules and support terms directly with Security Onion Solutions, and have counsel review ELv2 against your intended use.

What drives the running cost of each suite

Neither suite has a license fee for its free edition, so the running cost sits in hardware, storage, people and upgrade work. The cards below separate what you pay once from what recurs, and list what to request in a quote before comparing totals.

Hardware for each role

Security Onion publishes minimums of 4 cores, 24 GB RAM and 200 GB storage for a standalone node, and advises 32 GB of RAM or more even for a small amount of monitored traffic. Its manager and search nodes need 4 cores and 16 GB RAM, and sensors need 4 cores and 12 GB RAM, so a distributed layout multiplies the machine count. Malcolm's hardware floor is not in the supplied sources, so confirm Malcolm sizing with the project before comparing purchase or cloud lines. Ask any vendor or integrator for hardware per role, not one total.

Storage for packet capture and logs

Full packet capture and indexed logs are usually the largest recurring cost, and they grow with traffic and retention rather than with the software. Security Onion 3.0.0 moved full packet capture to Suricata, so capture sizing now follows that pipeline. Malcolm ingests PCAP files, Zeek logs and Suricata alerts, and its indexes live in OpenSearch. Ask for the retention window, the traffic rate assumed for sizing, and whether capture is kept in full or only as metadata.

Staff skills in Elastic, OpenSearch and Zeek

Security Onion is built on Elasticsearch, Suricata and Zeek, while Malcolm is built on OpenSearch, Arkime and Zeek, so the skills you need differ by suite. Staff time is a recurring cost that rarely appears on a vendor quote, and it rises if you must tune detections, write Sigma content or troubleshoot an ICS protocol parser. Ask who will operate each suite, what training they already have, and whether an integrator will handle tuning in the first year.

Pro subscription fees and renewal

Security Onion Pro is a paid edition sold on 1 to 5 year terms, and it adds OIDC single sign-on, FIPS and STIG hardening, the Security Onion API and Manager of Managers. Pro fees recur at each renewal and may be charged per node, so a distributed design raises the count. Malcolm is Apache-2.0 and has no paid edition in the supplied sources, so its recurring cost is labor and infrastructure. Ask for the term length, the node count the quote covers, and the renewal price cap.

Upgrade and release cadence

Both projects ship often, and each upgrade costs testing time. Security Onion 3.3.0 was published on September 11, 2026, and Security Onion 2.4 reached end of life on October 1, 2026, so older deployments carry a migration project. Malcolm v26.09.0 was published on September 30, 2026. Budget for a test environment, an upgrade window and rollback planning every release cycle, and ask who performs upgrades and how long they are supported.

Outside services and integration

Implementation, tuning, hardening, backup design and compliance evidence are often bought from outside the team, and these fees are usually one-time, while retainers recur. Malcolm integrates with NetBox, Keycloak or LDAP, and MISP, which add setup work. For Security Onion, airgap installs need an update path through new ISO media. Ask for fixed-scope deliverables, what is excluded, the support hours covered, and who pays for hardware changes that a scope discovery reveals.

Moving between Security Onion and Malcolm: what transfers and in what order

This sequence shows a team how to inventory what it runs today, separate what carries across from what must be rebuilt, run both stacks side by side, and retire the old one without losing evidence or coverage.

Inventory sensors, log sources and detections
The team lists every sensor, the network segments each one watches, every log source feeding the platform, and every detection in use, whether a Suricata NIDS rule, a Sigma rule, a YARA rule or a Zeek script. The owner of each item is named. Done means the inventory is signed off by the SOC lead and the OT or network owner, and each item is tagged as portable, partly portable or rebuild. Confirm with each vendor which export formats the current platform supports before assuming any content can be pulled out.
Confirm what transfers and what needs rebuilding
Sort the inventory into three groups. Zeek and Suricata configuration concepts carry across because both suites rely on the same engines, but the exact file layout and tuning will differ. Raw packet capture and log archives can be kept as evidence, provided the destination can read the format. Sigma and YARA rules are the most portable detection inputs, though field mappings still need checking. Dashboards, Security Onion Console detection tuning, Malcolm dashboards, Arkime session views, identity integration and retention settings must be rebuilt on the new side. Done means a written transfer register exists and each entry has a named owner.
Build the target stack beside the source
The team deploys the target platform in its own environment, with sensors placed on the same segments as the current platform so that both see the same traffic. Identity integration is configured early, because Security Onion Pro's OIDC single sign-on and Malcolm's Keycloak or LDAP authentication differ and affect who can reach the console. Hardware is sized against each vendor's documented minimums, and the team confirms whether its Security Onion edition or Malcolm deployment type fits its scale. Done means both stacks ingest live traffic and the team can log in with the intended roles.
Migrate detections and rebuild dashboards
Portable Sigma and YARA content is imported and tested against replayed PCAP or recent logs on the target. Each rule is checked for alert volume, field mapping and suppression needs, since tuning done in one console does not transfer automatically. Dashboards and analyst views are rebuilt in the target's visualization layer, and retention settings are set to match the agreed evidence policy. Done means each migrated detection has a test result recorded, and every rebuilt dashboard has been reviewed by the analysts who use it.
Run both platforms in parallel
For a defined overlap period agreed in advance, both platforms receive the same traffic and logs. Analysts triage alerts from both, and the team records where each platform detects, misses or over-alerts. Discrepancies are reviewed against the transfer register. The overlap period length is a decision for the team and its governance, not a figure supplied here. Done means every high-priority detection has been seen to fire on the target, and no gap is left unexplained.
Cut over and confirm coverage
The team moves production monitoring to the target stack in a planned change window. Sensor feeds are switched, alert routing is repointed to the on-call channel, and the old platform is set to read-only for investigations. Analysts confirm they can run their standard investigation paths on the new platform. Done means the cut-over checklist is complete, the change record is closed, and the old platform has stopped receiving production traffic.
Retire the old stack with evidence preserved
Before decommissioning, the team exports or archives what must be kept, including PCAP, logs, alert history and configuration, in formats it has confirmed the new platform or the records team can read. Access is removed, network taps and credentials are revoked, and hosts are wiped or reassigned according to policy. Done means an archive manifest exists, the retention owner has signed it, and the old platform is no longer reachable from the network.

Where Security Onion and Malcolm projects usually run long

The longest Security Onion projects usually stall on sizing and node layout, not on installation. The architecture documentation recommends a Distributed deployment for production, with a manager node, sensor nodes and search nodes, and notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Decide the node count, receiver placement and sensor locations before hardware is ordered. The hardware documentation lists minimums of 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, and suggests 32 GB of RAM or more even for a small amount of monitored traffic, so confirm the traffic volume with your network team first. For version 3.0.0, the operating system is a hard gate: it supports only Oracle Linux 9. Security Onion 2.4 reached end of life on October 1, 2026. Installations on Oracle Linux 9 can upgrade to 3 after full packet capture moves from Stenographer to Suricata, while other distributions need a fresh install, so an existing 2.4 estate may need a rebuild plan rather than an in-place upgrade. In air-gapped sites, plan the ISO transfer and the soup update cycle from newer media as a recurring task, not a one-time setup.

Malcolm's effort sits mostly in the data path and identity layer. Each sensor placement needs a decision about where full packet capture files are collected, whether they are uploaded through the browser or forwarded live from lightweight forwarders, and who owns the forwarder configuration on each segment. Expect time for validating that the Zeek logs and Suricata alerts actually arrive and are normalized. If you monitor OT networks, the protocol documentation lists the ICS parsers Zeek provides, including Modbus, DNP3, S7comm and PROFINET, but a smaller subset is also parsed by Arkime. Test each protocol your plant actually uses against captured traffic rather than assuming coverage, and record which ones are missing. Authentication through Keycloak or LDAP, and the NetBox asset inventory, each need a named owner and a test account before the dashboards are handed over. Kubernetes deployment is documented with standard manifests and an Amazon EKS guide, but Malcolm calls it a new and still somewhat experimental feature, so treat it as a validation item, not a default target.

Both projects tend to slip at the same points: unclear sensor coverage, undocumented network segments, identity integration left until the end, and detection tuning treated as optional. For Security Onion, tuning NIDS rules, Sigma rules and YARA rules in the Console takes analyst time after go-live, and suppression and threshold changes need a review step. For Malcolm, the dashboards and protocol validation depend on the asset inventory being accurate. A fixed-scope written statement of work should pin down the node layout and sizing basis, the target operating system and any upgrade path from 2.4, the airgap update procedure, the list of sensor segments and protocols in scope, the identity provider and authentication method, the Kubernetes or Docker target, the detection tuning hours, and who signs off each acceptance test. Ask the vendor or your own environment to confirm any capability you cannot verify, rather than assuming it from the documentation summary.

Can our team run Security Onion or Malcolm without outside help?

Can our team run Security Onion without outside help?

Yes, if the team already runs Linux servers, Elasticsearch-style search clusters and network sensors, and has at least one person who can own upgrades. Security Onion is a single distribution that bundles Suricata, Zeek, Strelka, full packet capture and Elasticsearch, so most of the skill load sits in operating that stack rather than assembling it. Security Onion 3.0.0 supports only Oracle Linux 9, and the recommended production layout is distributed, with a manager, search nodes and sensors. Confirm internally whether you have staff who can run that layout, tune detections in the Console, and plan upgrades. The Security Onion architecture documentation is the right first read for that assessment.

Can our team run Malcolm without outside help?

Often yes, provided the team is comfortable with containers and Linux administration. Malcolm runs as a set of containers managed by setup and run-time scripts, and it is intended for long-term use on a Linux server in a SOC as well as short-term incident response. Its Kubernetes deployment is documented but described as still somewhat experimental, so a team choosing that path should plan for more engineering. Skills that matter include container operations, Zeek and Suricata log handling, OpenSearch administration, and authentication setup with Keycloak or LDAP. Confirm which deployment model you intend before deciding on in-house staffing.

How long does a Security Onion or Malcolm implementation take?

No supplied fact gives a timeline for either platform, so treat any figure you hear from a vendor or partner as unverified until it is tied to a written scope. The drivers are the number of sensors and network segments, whether you run standalone or distributed, how many log sources you onboard, how much detection tuning you need, and whether authentication and change control must be integrated. Ask any provider to break the schedule into hardware readiness, installation, tuning, validation and handover, and to state what the client must provide at each step.

What does the implementation need from our network and staff?

Expect to supply network access, sensor placement approval, hardware, and staff time from security operations, network engineering and, for OT, the asset owner. Security Onion requires minimum hardware including 4 CPU cores and 24 GB RAM for a standalone node, plus 2 NICs, and its documentation suggests 32 GB of RAM or more for even a small amount of monitored traffic. Sensors need span or tap access that the network team must approve, and changes to production networks usually need a change window. Confirm each of these requirements in writing before the engagement starts, because they set the schedule more than the software does.

Does Security Onion Pro or a Malcolm support option remove the need for a partner?

Security Onion Pro removes some operational load but does not replace an implementation partner or your own staff. The Pro edition, sold on 1 to 5 year terms, adds OIDC single sign-on, LUKS encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers and professional support. Malcolm is Apache-2.0 software with no paid edition in the supplied facts, so any support you buy is a separate contract with a third party. Confirm with each vendor what support covers, response expectations, and whether it includes installation, tuning or upgrades.

Can we monitor an OT network with Malcolm without disrupting live control traffic?

Malcolm can parse many ICS and OT protocols from Zeek, including Modbus, DNP3, S7comm, PROFINET and OPC UA Binary, but whether it can be deployed without affecting live control traffic depends on your sensor design and the asset owner's rules. Passive capture through a tap or span port is the usual pattern, yet you must confirm the sensor placement, the hardware, and any protocol-level impact with the sensor vendor and the asset owner before connecting anything. Plan a maintenance window for initial deployment and agree in writing who can approve changes to the monitored segment.

What does a fixed-scope DeployOpen engagement cover?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. For a Security Onion or Malcolm project, that typically means defining sensors and data sources, deployment design, detection and dashboard work, identity integration, hardening and handover documentation. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so ask for a scoped quote that lists each deliverable and what the client must supply.

How DeployOpen helps teams choose, implement or migrate

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For Security Onion vs Malcolm, we start by working out whether your team needs a SOC-focused sensor and search stack or an OT-oriented protocol analysis suite, then build and hand over only the option that fits.

How we scope

Written scope that names the sensor placement, network segments and traffic volumes to be monitored
Confirmation of which ICS and OT protocols the environment actually carries before any parser work starts
Agreed deliverables, timelines and responsibilities for each side, set out before work begins as a fixed-scope engagement

How we build

Deployment of the chosen platform in your own cloud account, data center or air-gapped network, using the topology agreed in scope
Integration of identity, asset inventory and threat intelligence sources your team already relies on, such as your directory and existing feeds
Security testing of the deployed stack, including review of access controls, data retention settings and exposed interfaces

How we hand over

Runbooks covering installation, upgrades, rule tuning and capacity checks, written for the analysts and engineers who will operate the platform
Compliance-oriented evidence packs that document controls and configurations, prepared for your own auditors who issue any formal reports
Knowledge transfer sessions with your SOC and OT staff so the platform is operable without DeployOpen on site

How we support

Ongoing support, upgrades and continuous testing available as a retainer once the platform is live
Planned upgrade reviews that check release notes and license terms for the chosen platform before each change
A clear support boundary written into the engagement so your team knows which changes are handled and how they are requested

Security Onion vs Malcolm