Which open-source network traffic analysis suite fits your team
If your team needs network security monitoring with packet capture and wants to run it in your own infrastructure, the choice comes down to how much you want bundled and how much you want to assemble yourself. Security Onion is the option to shortlist if you want one distribution that already combines Suricata, Zeek, Strelka, full packet capture and Elasticsearch with an Elastic Agent. Its license is the Elastic License 2.0, which is source-available rather than OSI approved and forbids offering the software as a managed service, so have legal confirm that terms fit your model before you commit. Security Onion 3.0.0 runs only on Oracle Linux 9, so confirm your platform standard early, and plan for a distributed manager, search and sensor layout if the deployment is for production.
Malcolm fits a team that wants a container suite under the Apache License 2.0, built around Arkime for session search and OpenSearch Dashboards for visualization, and that needs OT protocol coverage. Its Zeek parsing covers protocols such as Modbus, DNP3, BACnet and S7comm, which matters if your monitored networks include industrial or building systems. Malcolm runs on a Linux server for long-term SOC use or on a laptop for short incident response, and it documents Kubernetes deployment, which the project describes as still somewhat experimental. Confirm the Kubernetes path against your own cluster standards before you rely on it.
Standalone Arkime suits a team that already runs an IDS such as Suricata or Zeek and needs full packet capture and search on top of it. Arkime is Apache-2.0 licensed, keeps PCAP on the sensors in standard format readable by tools such as Wireshark, and stores session metadata in OpenSearch or Elasticsearch. Retention is governed by sensor disk and cluster size, so size both before you choose it. The project itself says Arkime is meant to work alongside an IDS rather than replace one, so you will assemble the alerting, dashboards and identity integration yourself. Ask your team how much of that integration effort it can carry.
Which network traffic analysis suite to choose by scenario
This table maps common network monitoring situations to the suite that fits each one best, with the condition that makes the choice hold. Read each row against your own sensor placement, protocol mix, team skills and connectivity before shortlisting.
| Scenario | Best fit | Why |
|---|---|---|
| SOC wants one distribution with IDS, Zeek, full packet capture and Elasticsearch | Security Onion, if you accept the Elastic License 2.0 and a single Oracle Linux 9 platform | It bundles Suricata, Zeek, Strelka, full packet capture, Elasticsearch and Elastic Agent in one distribution, and Distributed is the recommended production design. |
| ICS or OT team needs parsed Modbus, DNP3 or similar protocols | Malcolm, if Zeek protocol parsing is the core requirement | Its documentation lists Zeek parsers for Modbus, DNP3, BACnet, EtherNet/IP, PROFINET, S7comm and other ICS protocols, and it integrates NetBox for asset inventory. |
| Team already runs OpenSearch and only needs packet search | Standalone Arkime, writing session metadata into your existing OpenSearch cluster | Arkime is Apache-2.0, stores PCAP on sensors and sends session metadata to OpenSearch or Elasticsearch, so it does not require a full distribution. |
| Incident responder wants a laptop deployment | Malcolm, for short-term analysis of uploaded PCAP on a laptop | Malcolm runs as containers with setup and run-time scripts and is designed for both long-term SOC use and short-term incident response on a laptop. |
| Team must run on Kubernetes | Malcolm, after confirming the manifests fit your cluster and accepting experimental status | Malcolm documents Kubernetes deployment with standard manifests, including an Amazon EKS guide, but calls this feature new and still somewhat experimental. |
| Air-gapped site with no internet access | Security Onion, using the ISO and airgap update path | Its ISO carries packages and NIDS, YARA and Sigma rules, and the soup tool updates from newer ISO media in airgap mode. Confirm rule update cadence with your own process. |
| Packet retention matters more than alert pipelines | Standalone Arkime, sized to sensor disk and cluster capacity | Arkime keeps packets on sensors, so PCAP retention depends on local disk while metadata depends on the OpenSearch or Elasticsearch cluster. |
Security Onion, Malcolm and Arkime in brief
Security Onion, Malcolm and Arkime all capture and analyze network traffic, but they differ in scope, license and what the operator must build around them. The cards below set out what each one is for, what it leaves out and the checks to run before choosing one for a SOC or incident response team.
Security Onion as a bundled stack
Security Onion is a free Linux distribution from Security Onion Solutions that bundles Suricata, Zeek, Strelka, full packet capture, Elasticsearch and Elastic Agent in one install. Its repository is licensed under the Elastic License 2.0, which is source-available and not OSI approved, and the license forbids offering the software as a managed service. The latest tagged release is 3.3.0, published September 11, 2026. Check the license terms with counsel if you plan to resell monitoring, and confirm the supported operating system before you plan a deployment, since version 3.0.0 supports only Oracle Linux 9.
Malcolm as a containerized analysis suite
Malcolm is an Apache-2.0 suite maintained in the cisagov GitHub organization. It takes full packet capture files, Zeek logs and Suricata alerts, uploaded through a browser or forwarded from lightweight sensors, and presents them through OpenSearch Dashboards with Arkime for session lookup. It runs as containers managed by setup and run-time scripts, and it documents ICS and OT protocol parsing through Zeek. Its Kubernetes deployment is described by the project as new and still somewhat experimental, so test that path before relying on it in production.
Arkime as packet capture and search
Arkime is an Apache-2.0 system for large-scale full packet capture, indexing and search, originally created at AOL. Capture sensors write PCAP to local disk and send session metadata to OpenSearch or Elasticsearch, so packet retention depends on sensor disk space and metadata retention depends on cluster size. Arkime is not an intrusion detection system and is designed to work alongside one such as Suricata or Zeek. Expect to supply the alerting and detection layer yourself if you deploy it alone.
Capabilities across the three network traffic analysis options
This table compares Security Onion, Malcolm and standalone Arkime on the capabilities that decide fit: licensing, bundled sensors, packet capture, protocol coverage, deployment targets, airgap installs, enrichment sources and authentication. Read each row as a question to confirm against your own requirements, because Arkime is a capture and search component while the other two are full stacks.
| Capability | Security Onion | Malcolm | Arkime (standalone) |
|---|---|---|---|
| License and OSI status | Elastic License 2.0, source-available and not OSI approved | Apache License 2.0 | Apache-2.0 |
| Bundled IDS and Zeek | Suricata and Zeek bundled in one distribution | Zeek logs and Suricata alerts processed; Arkime included | Not bundled; designed to work alongside an IDS rather than replace one |
| Full packet capture method | Suricata full packet capture (replaced Stenographer in 3.0.0) | Uploaded PCAP files or live feeds from lightweight forwarders, with Arkime for sessions | Multithreaded capture writing PCAP to local sensor disk |
| OT and ICS protocol parsing | Confirm with the vendor | Zeek parses BACnet, DNP3, Modbus, S7comm, PROFINET and others; a smaller subset also in Arkime | Confirm with the vendor for OT parsers; a smaller subset is parsed by Arkime |
| Kubernetes deployment | Confirm with the vendor | Standard manifests and an Amazon EKS guide; described as new and somewhat experimental | Confirm with the vendor |
| ISO or airgap install | Full installs without internet access; ISO carries packages and NIDS, YARA and Sigma rules | Installation ISOs published; container scripts for Linux servers | Confirm with the vendor |
| Asset inventory and threat intelligence | Detections interface for NIDS, Sigma and YARA rules; confirm other enrichment sources | NetBox for assets; MISP and STIX/TAXII as Zeek Intelligence Framework sources; YARA and CyberChef | Optional wiseService for threat intelligence on session metadata; Cont3xt for context |
| Authentication options | Pro adds OIDC single sign-on; confirm base options | Keycloak or LDAP authentication | Confirm with the vendor |
| Paid tier | Security Onion Pro on 1 to 5 year terms, adding OIDC SSO, FIPS, STIG, API and professional support | Not identified in supplied facts; confirm with the vendor | Not identified in supplied facts; confirm paid support with the vendor |
How packet capture storage changes the sizing decision
Packet capture storage decides the sizing question before you pick hardware. Arkime keeps packets on the capture sensors, so PCAP retention is limited by sensor disk space, while metadata retention depends on how large the OpenSearch or Elasticsearch cluster is. The two grow on different budgets, so plan them separately. Arkime writes PCAP in a standard format that Wireshark can read, which means your analysts and your evidence handling are not locked to the Arkime viewer. Confirm with your own team how long PCAP must be kept and who can export it, because that retention window, not the session count, usually sets the disk footprint.
Security Onion handles full packet capture differently. Its bundled Suricata capture replaced Stenographer in Security Onion 3.0.0, and the sensor nodes in its distributed design hold the capture while search nodes hold the indexed data. Malcolm takes a different path again: it processes PCAP files that analysts upload through a browser, or traffic forwarded live from lightweight forwarders, so storage is driven by what you choose to upload and forward. Ask each vendor where packets land, how long they stay there, and what happens when a sensor's disk fills, because the answers change the failure mode you need to monitor.
Security Onion publishes minimum hardware of 4 CPU cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone install, and its hardware documentation suggests 32 GB of RAM or more even when monitoring a small amount of traffic. Treat those figures as floors. Traffic volume, retention period and sensor count drive the real disk and memory needs, and a single busy sensor can outgrow a small standalone build quickly. Before you size anything, measure your peak throughput, decide how many days of packets and metadata you must retain, and confirm current requirements with each vendor against your own environment.
Licensing and paid editions for each option
Security Onion's repository is licensed under the Elastic License 2.0 (ELv2), a source-available license rather than an OSI-approved open-source license. The license is not OSI open source, and the ELv2 forbids offering the software to others as a managed service. Internal use by your own security team, on your own infrastructure, is the common case it permits, but a managed security provider that runs Security Onion for client organizations needs legal review before it starts.
- Internal use: Running the free distribution inside your own environment is the pattern the license is written around. Confirm the exact terms with your counsel.
- Managed service restriction: Offering Security Onion as a hosted or managed service to third parties is the activity ELv2 forbids. Providers should not assume the free edition covers that model.
- Security Onion Pro: A paid license on 1 to 5 year terms 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.
- Recurring cost: Pro is a subscription, so the term length and renewal affect total cost. Ask for the price, term options and renewal terms in writing.
Before you commit, confirm with the vendor which Pro features your identity provider, compliance baseline and support model require.
Malcolm is licensed under the Apache License 2.0, a permissive OSI-approved license. Its repository sits in the cisagov GitHub organization, and the copyright notice names Battelle Energy Alliance, LLC, with the project contact at malcolm@inl.gov. The Apache-2.0 terms allow internal use, modification and redistribution, subject to the license conditions and notices.
- License type: Apache-2.0 is an OSI-approved license, so it does not carry the managed-service restriction that ELv2 imposes.
- Copyright holder: The notice names Battelle Energy Alliance, LLC. Keep that attribution when you redistribute or modify the code.
- Paid tier: The supplied facts do not describe a paid Malcolm edition. Confirm with the project maintainers whether any commercial support or paid option exists before you budget for one.
- Recurring cost: Software licensing is not a recurring cost here. Your costs come from hosting, staff time and any support contract you choose to buy elsewhere.
Ask the maintainers to confirm the current license file and whether any commercial terms apply to your deployment.
Arkime is licensed under Apache-2.0, an OSI-approved license. The project is an open source system for large-scale full packet capture, indexing and search, and its optional applications are separate components you may choose to deploy. Those components include Cont3xt for contextual intelligence, esProxy between capture and the database, Parliament as a front door to multiple clusters and wiseService for adding threat intelligence to session metadata.
- License type: Apache-2.0 allows internal and commercial use without the managed-service restriction that applies to Security Onion.
- Optional applications: Cont3xt, esProxy, Parliament and wiseService are optional. Deploy only the ones your workflow needs, and confirm the license terms of each component in its own repository.
- Integration cost: Adding wiseService or Cont3xt adds configuration and threat-intelligence sources to maintain, which is an effort cost rather than a license cost.
- Paid tier: The supplied facts do not describe a paid Arkime edition. Confirm with the maintainers whether a commercial support option exists.
If you plan to offer packet analysis as a service, confirm with counsel how Apache-2.0 applies to your use, and confirm the license of any optional application you add.
OT protocol coverage, Kubernetes and ISO deployment
Protocol coverage only helps OT monitoring if the sensors can see the traffic. Malcolm's protocol documentation lists ICS and OT protocols that Zeek parses, including BACnet, DNP3, Modbus, PROFINET, S7comm and Synchrophasor, plus a smaller subset that Arkime also parses. Before you count those protocols as covered, confirm three things in your own network: that the capture point sits on a span or tap that carries the OT segment, that the traffic reaches Malcolm as PCAP or as forwarded Zeek logs, and that your plant engineers agree the parsed fields are enough for the detections you need. A protocol listed in the documentation but absent from your capture points gives you no visibility at all.
Malcolm documents deployment on Kubernetes using standard manifests, with an Amazon EKS guide in the Malcolm Kubernetes documentation. The project describes Kubernetes deployment as a new and still somewhat experimental feature, so treat it as a pilot path unless your team has tested it against your own storage and ingest volumes. Arkime's Kubernetes status is not covered by the facts available for this comparison, so confirm it directly with the project before you plan a cluster-based Arkime deployment. Ask your platform team whether they can run the stateful OpenSearch and capture components with the persistent storage and node placement your sensors need.
Security Onion takes a different path. It publishes ISO installs, and its airgap documentation describes full installs on networks without internet access, where the ISO carries packages and NIDS, YARA and Sigma rules. Updates in airgap mode run through the soup tool from newer ISO media, so you need a process to bring verified media across your boundary on a regular schedule. Security Onion supports only x86-64 processors, so confirm that your sensor and manager hardware, including any appliances in your OT zone, meets that requirement before you commit to it.
How to choose and pilot a network traffic analysis suite
This sequence turns the three-way choice between Security Onion, Malcolm and standalone Arkime into a documented pilot decision, with sizing, license and OT coverage checked against your own segments before any production build.
Define monitored segments and traffic volume
Your network team lists the segments you need to watch, such as the internet edge, data center east-west links and any OT zone, and records the sustained and peak traffic on each. This list decides everything after it, because Arkime's capture model keeps packets on sensors while Security Onion and Malcolm each assume a specific sensor layout. Done means every segment has a named owner, a traffic estimate from measured data rather than guesswork, and a note on whether packets must be retained or metadata is enough.
Decide between an all-in-one stack and a paired sensor
Your security architect decides whether you need intrusion detection, Zeek logs and full packet capture delivered by one product, or whether you already run a sensor such as Suricata or Zeek and only need packet search added. Security Onion bundles Suricata, Zeek, Strelka and full packet capture in one distribution, Malcolm combines Zeek logs, Suricata alerts and Arkime sessions in a container set, and standalone Arkime works alongside an existing IDS rather than replacing one. Done means a written choice with the reason, such as keeping an existing signature engine or consolidating operations on one team.
Check license against how you will use the stack
Your legal and compliance leads review the license for each candidate against how the platform will run and who will receive its output. Security Onion's Elastic License 2.0 forbids offering the software as a managed service, which matters if you plan to run monitoring for subsidiaries or outside clients. Malcolm and Arkime are Apache-2.0, and the Security Onion Pro terms are a separate paid license. Done means a signed-off note covering hosting model, third-party access and whether paid features such as OIDC single sign-on or FIPS hardening are needed before rollout.
Confirm OT protocol needs against the parsed list
Your OT or industrial security lead compares the protocols on your plants or substations with the list Malcolm documents as parsed by Zeek, which includes Modbus, DNP3, S7comm, PROFINET, EtherNet/IP, OPC UA Binary and IEC 60870-5-104 among others. Some protocols are parsed by Arkime only as a smaller subset, so confirm those separately. Done means each OT protocol on your network is marked as parsed by Zeek, parsed by Arkime, or not covered, and any gaps are logged as items to test with real traffic in the pilot.
Size sensors and search nodes from measured traffic
Your platform engineer maps the published minimum hardware for each candidate against the segment volumes from step one. Security Onion lists a standalone minimum of 4 cores, 24 GB RAM and 200 GB storage and recommends more RAM for even modest monitoring, with a sensor minimum of 4 cores, 12 GB RAM and 2 NICs, and it supports only x86-64. Arkime keeps PCAP on sensor disks, so retention is set by local storage while metadata depends on the search cluster. Done means a sizing sheet per candidate that separates minimum from recommended hardware and shows which disks and cluster nodes carry the load.
Run a pilot on one segment with set retention
Your security operations team deploys the shortlisted candidate on one representative segment with a retention period fixed in advance, then records disk growth per day, the number of alerts raised and the hours spent tuning rules and suppressions. For Security Onion, the Detections interface handles tuning of Suricata NIDS rules and Sigma filters, so log that effort separately. Done means a pilot report with measured disk growth against the planned retention, an alert tuning log, a list of OT or protocol gaps found, and a go or no-go decision recorded for the next candidate or production build.
What buyers and practitioners ask before choosing a traffic analysis suite
What drives the cost of running Security Onion, Malcolm or Arkime?
Hardware, storage and staff time drive most of the cost, and the software licenses are the smallest part. Security Onion's free edition is licensed under ELv2, and its paid Security Onion Pro license runs on 1 to 5 year terms and adds OIDC single sign-on, FIPS mode, OS STIG compliance, the API and Manager of Managers. Security Onion's documented standalone minimum is 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, and it suggests 32 GB RAM or more even for small traffic volumes. Arkime keeps packets on sensors, so PCAP retention scales with sensor disk, while metadata retention scales with the OpenSearch or Elasticsearch cluster. Staff time recurs for upgrades, tuning and monitoring. Ask for a quote that lists hardware, storage sizing, whether Security Onion Pro is included, and who carries each recurring task.
Can our team run these tools without outside help?
A team with Linux operations experience and some search platform knowledge can run any of the three, but the workload is continuous, not a one-time install. Security Onion Pro includes professional support, and Malcolm and Arkime are community-maintained open-source projects, so support depends on your own staff or a contracted provider. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own infrastructure under a fixed scope agreed in writing, and ongoing support and upgrades are available as retainers. Decide early which tasks stay in-house, such as detection tuning and on-call alert triage, and which go to a provider, then put that split in the written scope.
How long does a pilot of a network traffic analysis suite take?
No fixed duration applies to every environment, so treat any timeline as something to agree in writing before work starts. The pilot length depends on how many network segments need sensors, the traffic volume at each tap or SPAN point, hardware lead times, how the output connects to your existing SIEM, and how long security staff take to tune detections. Regulated environments also add change approvals and, for OT networks, a safety review with plant owners. Ask any provider for a scope that names the segments in the pilot, the acceptance criteria, the hardware assumptions and the points where your team must sign off.
What skills does a team need to run Security Onion, Malcolm or Arkime?
Plan for four skill areas, and check each against the people you can assign:
- Linux administration for installs, package updates, disk management and networking on sensor and manager nodes.
- Container skills for Malcolm, which runs as a set of containers managed with setup and run-time scripts.
- Elasticsearch or OpenSearch knowledge for index lifecycle, storage sizing and cluster health, since Security Onion and Arkime both depend on them.
- Detection tuning, including Suricata NIDS rule modification, suppression and thresholds, and Sigma rule filters in the Security Onion Console.
If one area has no owner, the tool will still install, but alerts will age without triage. Map these skills before choosing a platform.
Can Security Onion be offered as a managed service under the Elastic License 2.0?
The Security Onion license documentation states that ELv2 forbids offering the software as a managed service, so a provider cannot sell hosted Security Onion to customers on that basis. Whether a particular arrangement counts as a managed service is a legal question, so put it to your counsel before you sign anything. DeployOpen implements these platforms inside the client's own cloud accounts, data centers or air-gapped networks, and the client operates the resulting system. Read the Security Onion license documentation and confirm your model with counsel before procurement.
Can Malcolm monitor OT networks, and what sensors does it need?
Malcolm can process OT traffic, because its Zeek component parses several ICS and OT protocols, including BACnet, DNP3, EtherNet/IP, Modbus, PROFINET, S7comm and Synchrophasor. Arkime parses a smaller subset of these protocols, so confirm which ones your devices use. Malcolm accepts full packet capture files uploaded through a browser or traffic forwarded live from lightweight forwarders, and Hedgehog Linux is the network sensor appliance its documentation covers. Before deployment, confirm protocol coverage against your device inventory, decide on passive tap or SPAN placement, and get written sign-off from OT owners, because any sensor on a control network needs a careful change plan. Review the Malcolm protocol documentation for the full list.
How do we upgrade Security Onion safely?
Start by checking your end-of-life status, because 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.x supports only Oracle Linux 9. A 2.4 installation on Oracle Linux 9 can upgrade to 3 after you move full packet capture from Stenographer to Suricata. Installations on other distributions need a fresh install instead. Before any change, inventory your operating system, back up configuration and data you need, rehearse the upgrade on a lab copy, and confirm sensor and search node compatibility. Use the Security Onion EOL documentation to confirm your path.
How DeployOpen scopes and delivers a network monitoring selection and implementation
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For network traffic analysis, we start from the sensor placement, retention and licensing questions this comparison raises, then deliver a written, fixed-scope engagement that covers the platform you choose.
How we scope
- We confirm which network segments, OT zones and sensor locations the stack must cover before choosing between suites.
- The written scope lists the platform, deployment model, storage sizing inputs and integrations agreed with your team.
- Hardware and licensing questions, including the edition needed for SSO and hardening, are answered in writing before work starts.
How we build
- We install and configure the chosen suite in your environment, including sensors, manager and search nodes where the design calls for them.
- Integrations with your identity provider, ticketing, threat intelligence and existing SIEM or log pipelines are built and tested.
- Security testing of the deployed stack is scoped separately so that findings are reviewed before the platform goes live.
How we hand over
- Deliverables include architecture notes, configuration records, runbooks for updates and air-gapped media handling, and sizing assumptions.
- Operators are walked through alert handling, rule tuning and capture retention so that your team can run the system after handover.
- Compliance evidence, where it is needed, is prepared for your independent auditor, since DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the initial engagement.
- Upgrade work follows the vendor release line you select, with the maintenance window and rollback steps agreed in advance.
- To request a quote, send your sensor count, traffic profile, retention targets and any OT protocol requirements so the scope can be written.
