Security Onion or Graylog: which fits your SOC's data
If your SOC needs to see what moves across the network, choose Security Onion. It bundles Suricata, Zeek, Strelka and full packet capture with Elasticsearch and Elastic Agent in one distribution, so east-west and north-south traffic is inspected and retained from the start. If your priority is collecting and searching logs from many systems (firewalls, identity providers, cloud services, servers and applications), Graylog is the more direct fit, because its job is centralizing, parsing and searching that data. The two overlap less than their names suggest. Security Onion can ingest logs too, and Graylog does not inspect packets, so the question is which data source your analysts will work from every day.
The decision turns on four factors: your data source mix, the license terms you can accept, your hardware budget and your in-house skills. Security Onion is licensed under the Elastic License 2.0, which is not OSI approved and forbids offering the software as a managed service, so a provider running it for your customers needs legal review. Graylog Open is licensed under the SSPL, which is also not OSI approved, and index archiving, correlation, reporting and prebuilt Illuminate content sit in the paid Graylog Enterprise or Graylog Security editions. Security Onion's documented minimum is 4 CPU cores, 24GB RAM and 200GB storage for a standalone install, with 32GB RAM or more suggested for even modest traffic monitoring. Confirm sizing for your sensor throughput and retention targets with both vendors before you compare totals.
Which platform fits which SOC scenario
This table maps common SOC scenarios to the platform that usually fits better, along with the condition that makes that choice hold. Read each row against your own telemetry sources, team size and hosting model, because the answer often flips when one of those conditions changes.
| Scenario | Better fit | Condition that makes it hold |
|---|---|---|
| Visibility into network traffic with Suricata, Zeek and full packet capture | Security Onion | You need network-layer detections and packet data as a primary input, and you can staff sensor nodes and storage for capture. |
| Centralized log search across servers, applications and cloud sources | Graylog | Your priority is ingesting and searching logs from many systems, and network sensing is secondary or handled by another tool. |
| Small team wanting one appliance-style install | Security Onion | You accept a bundled stack with published minimum hardware (4 CPU cores, 24GB RAM, 200GB storage for standalone) and want Suricata, Zeek and Elastic Agent preconfigured together. |
| Lean team needing a log platform without network sensors | Graylog | You only need log management and can run the server and search backend without deploying capture sensors across network segments. |
| Existing OpenSearch estate | Depends on the goal | If you want Security Analytics on OpenSearch, Graylog adds streams, pipelines and alerting on top, but archiving, correlation and reporting need paid Graylog editions. Confirm which layer your team already operates. |
| Budget for Graylog Open without paid editions | Security Onion or a paid Graylog edition | Graylog Open lacks index archiving, correlation, reporting and prebuilt Illuminate content, so plan for Enterprise or Security if those are required. Confirm current edition terms with Graylog. |
| Hosted or managed-service delivery to customers | Neither as licensed | Security Onion's Elastic License 2.0 forbids offering the software as a managed service, and Graylog Open is under SSPL. Get written license advice before building a service on either. |
| Strict open-source license requirements | Confirm with counsel | Both licenses are source-available rather than OSI approved (ELv2 for Security Onion, SSPL for Graylog Open), so an OSI-only policy rules out both. |
How Security Onion and Graylog are built and what that means for operations
Security Onion is one distribution that bundles sensors, detection, packet capture and search, so its operating model follows from how those parts are split across nodes. Graylog is a log platform that separates configuration from indexed data, so its operating model follows from the search backend you choose. The cards below set out what each design asks of upgrades, sensor placement and storage sizing.
Bundled network sensing stack
Security Onion packages Suricata, Zeek, Strelka, full packet capture, Elasticsearch and Elastic Agent in one distribution. Your team gets network detection and log search from one install, but it also inherits every component's version and tuning. Before you commit, confirm how each bundled component is updated, whether you can pin or replace one of them, and which parts your analysts would touch directly.
Manager, search and sensor nodes
The recommended distributed Security Onion deployment separates a manager node, search nodes and sensor nodes. Sensors sit where traffic is visible, such as span ports, taps or mirrored segments, and send data back to the rest of the grid. Placement is therefore a network design task. Ask your network team which segments can be mirrored, how many sensors that implies, and whether sensors can reach the manager across your segmentation.
Sizing packet capture and search storage
Security Onion lists bare minimum hardware of 4 CPU cores, 24GB RAM and 200GB storage for a standalone install, and suggests 32GB of RAM or more even when monitoring a small amount of traffic. Full packet capture and Elasticsearch indexes grow with traffic volume and retention, so the 200GB figure is a floor, not a plan. Model capture rate and retention with your own traffic before you size disks.
Graylog's split configuration store
Graylog stores configuration in MongoDB and indexes log data in a separate search backend. For Graylog 7.2, the documented MongoDB range is 7.x to 8.2.x and the search backend is either self-managed OpenSearch or Graylog Data Node, which Graylog recommends. Two stateful systems mean two sets of backups, two upgrade sequences and two sets of version constraints to track against the compatibility matrix.
Choosing the search backend
Graylog runs on self-managed OpenSearch from the 1.1.x to 3.7.x range, or on Graylog Data Node, which Graylog documents as its recommended backend. The choice affects who owns cluster operations, how you size shards and heap, and which upgrade path you follow. Confirm the backend and its support status for your target Graylog version before you size hardware, because the supported range is set by the compatibility matrix and changes between releases.
Upgrade cadence and version coupling
Security Onion moves as one distribution, so the sensor, manager and search components are upgraded together through its release notes. Graylog upgrades couple the server, MongoDB and the search backend, and each must stay inside its documented range. Plan a maintenance window for each platform, rehearse on a copy of production data, and confirm which component changes require a full stop.
What hardware and storage each platform asks for
Security Onion's published minimum for a standalone install is 4 CPU cores, 24GB RAM and 200GB storage, according to its hardware requirements. Those figures are a floor for a lab or a very light deployment. The same documentation suggests 32GB of RAM or more once you monitor even a small amount of network traffic, so a SOC that plans to watch production segments should budget above the minimum from the start. Storage in a Security Onion build is driven mainly by full packet capture and by the Elasticsearch-based log index that Suricata, Zeek and Strelka feed, so the disk you need depends on how long you keep packets and how much metadata each sensor produces, not on the install image.
Graylog sizing works differently because its cost sits in the search backend. Graylog 7.2 stores configuration in MongoDB and indexes log data in OpenSearch or Graylog Data Node, so your memory, disk and node count are set by daily ingest volume, retention period and replica settings. No Graylog hardware minimum is supplied for this comparison, so do not carry the Security Onion figures across. Ask your Graylog partner or sales contact for a sizing recommendation based on your measured events per second and average message size, then check the retention and shard layout in the Graylog index model documentation and the installation guide before you buy hardware.
Before you compare the two, measure your own inputs for a representative week: sustained and peak network throughput at each sensor, log events per second from your sources, and the retention your auditors and incident response runbooks require. Use those numbers in a written scope so vendors and DeployOpen can quote against the same storage model. Ask for the disk layout, the memory per node and the growth assumptions in writing, and confirm whether packet capture is included in the sizing or priced as a separate tier.
Capabilities side by side: network detection, log search and identity
This table compares where each platform's core capabilities sit, from network IDS and packet capture to log search, Sigma detection and single sign-on. Read it by asking which capability your SOC needs first, then check the edition column before assuming a feature is included. Security Onion fits a team watching network traffic, while Graylog fits a team centralizing logs, and the paid tiers on both sides change the answer.
| Capability | Security Onion | Graylog |
|---|---|---|
| Network IDS and packet capture | Bundles Suricata, Zeek and full packet capture in one distribution | Not a network IDS; ingests logs and events from other sources |
| Log search and storage | Uses Elasticsearch within the bundle; confirm supported log sources with the vendor | Indexes log data in OpenSearch 1.1.x to 3.7.x or Graylog Data Node, which Graylog recommends |
| Sigma-based detection | Confirm whether your Security Onion version exposes Sigma rule matching in your deployment | Sigma-based matching via OpenSearch Security Analytics only if you run that stack; confirm the fit with your team |
| Index archiving and correlation | Confirm within the Security Onion feature set for your edition | Index archiving, correlation and reporting sit in paid Graylog Enterprise or Graylog Security, not Graylog Open |
| Prebuilt detection content | Confirm the included detection content with the vendor | Illuminate prebuilt detection content is in paid Graylog Enterprise or Graylog Security |
| OIDC single sign-on | Included in the paid Security Onion Pro license | Confirm the SSO options for your Graylog edition with Graylog |
| FIPS and STIG hardening | Included in the paid Security Onion Pro license | Confirm hardening profiles and FIPS support with Graylog and your platform team |
| Reporting and API | Security Onion Pro adds reports and the Security Onion API | Reporting sits in paid Graylog Enterprise or Graylog Security |
How the licenses and paid editions differ
Security Onion moved from the GPL to the Elastic License 2.0 (ELv2) starting with Security Onion 2.4, announced on August 31, 2022. The change matters most when you plan to offer Security Onion to clients, because ELv2 is not approved by the Open Source Initiative and it forbids offering the software to third parties as a managed service. Running the software inside your own organization is the case the license is built around, so a single company operating its own SOC on its own infrastructure is on familiar ground. Read the Security Onion license documentation before you commit.
- Internal SOC use: Running Security Onion to monitor your own network is internal use. Confirm the exact terms with counsel before you deploy.
- Managed service offerings: A provider that runs Security Onion as a monitoring service for other companies needs a separate licensing arrangement, because ELv2 forbids that model.
- Implementation work: Deploying, configuring and supporting Security Onion inside a client's own infrastructure differs from hosting it for the client. Ask counsel how your engagement terms are structured.
- Modification and redistribution: Changing the code and passing builds to others carries conditions that differ from GPL terms, so check the license text before packaging a customized build.
- Scope of the change: The license change applies to the components named in the license documentation, so confirm which parts of your stack are covered.
Have your legal team confirm how the current ELv2 terms apply to your intended internal and client use.
Security Onion Pro is a paid license that adds OIDC single sign-on, FIPS and STIG hardening, notifications, the Security Onion API, Manager of Managers and reports, according to the Security Onion documentation. The open distribution already bundles Suricata, Zeek, Strelka, full packet capture and Elastic Agent, so Pro matters mainly when identity, hardening, reporting or multi-manager operations drive the decision. The supplied sources do not give Pro pricing, license term or renewal mechanics, so those belong in the written quote.
- Identity: OIDC single sign-on is the feature listed. Confirm with your identity provider team that OIDC is the protocol you need.
- Hardening: FIPS and STIG hardening are listed. Confirm which STIG benchmark applies to your hosts and what validation status your FIPS requirement demands.
- Operations: Notifications, the Security Onion API and reports change how alerts reach ticketing, case workflows and management reporting.
- Multi-manager operations: Manager of Managers matters when you run several Security Onion managers across sites or business units.
- Commercial terms: Ask for the license term, renewal conditions, support inclusions and any per-node or per-sensor scaling in the quote.
Ask the vendor which Pro features are included in the version you plan to deploy before you compare costs.
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0) since Graylog 4.0 in 2020, replacing the GPL v3 license it used before. The SSPL is not approved by the Open Source Initiative, and the Graylog LICENSE file is the place to check the exact text. Internal use is the simpler case. The SSPL adds obligations when you offer the software to others as a service, so a hosting or managed-logging business needs its own legal review before onboarding clients.
- Internal use: Centralizing your own logs with Graylog Open is internal use. Confirm that the SSPL terms fit your deployment and internal distribution pattern.
- Service offerings: The SSPL's service provisions can require broader source disclosure when the software is offered as a service. Get counsel review before offering Graylog to clients.
- Procurement policy: Many procurement and open source policies require OSI-approved licenses, and the SSPL will fail those checks regardless of the use case.
- Feature boundaries: Index archiving, correlation, reporting and prebuilt Illuminate detection content sit only in paid editions, so the Open license covers a narrower feature set.
- Search backend licensing: Graylog 7.2 indexes data in OpenSearch or Graylog Data Node. OpenSearch is Apache-2.0, but confirm the terms that apply to the backend you choose.
Have counsel and procurement review the SSPL terms against your internal and client-facing plans before you deploy.
Graylog Enterprise and Graylog Security are the paid editions. According to Graylog documentation, index archiving, correlation, reporting and prebuilt Illuminate detection content are in these editions and not in Graylog Open. For a SOC that depends on correlated detections and archived retention, the paid editions decide whether Graylog meets the requirement. The supplied sources do not list edition prices or the exact boundary between Enterprise and Security, so both belong in the written quote.
- Enterprise: Index archiving, correlation and reporting are the features the documentation places in this tier. Confirm the feature list for your target Graylog version.
- Security: Prebuilt Illuminate detection content is the feature the documentation places in this edition. Confirm whether Security includes the Enterprise features or is licensed separately.
- Cost components: The subscription, support, implementation effort and the search backend hardware are separate cost lines. Ask which of these the quote covers.
- Hosted offerings: Paid editions do not remove the SSPL terms for offering the software as a service. Confirm the licensing position for your intended client model with counsel.
- Upgrade path: Moving from Open to a paid edition changes the license and feature set. Ask whether configuration and content carry over unchanged for your target version.
Request a written feature matrix mapped to your detection, retention and reporting requirements before you buy.
How to pick between the two in a shortlist review
Start with the question that decides most shortlists: which telemetry must the platform handle first. If the SOC's main job is watching network traffic, with Suricata alerts, Zeek logs and full packet capture on sensors, Security Onion is built around that workflow out of the box. If the main job is centralizing application, server and firewall logs for search, correlation and alerting across many sources, Graylog is designed for that. Ask each vendor or your own engineers to list the top ten log sources by volume and the top ten detections the team must run on day one. Then ask whether packet capture is a hard requirement. Security Onion bundles full packet capture, and Graylog does not replace it, so a team that needs pcap for incident response should price sensor hardware into the comparison before anything else.
Next, map the license obligations to how the organization operates. Graylog Open is licensed under SSPL-1.0, and Security Onion components use Elastic-2.0, which forbids offering the software as a managed service. Legal and procurement should confirm whether a managed service provider, an internal shared service or a subsidiary will operate the platform, because that changes which license terms apply to the deployment. Also confirm which Graylog features the SOC expects, since index archiving, correlation, reporting and prebuilt Illuminate content sit in paid Graylog Enterprise or Graylog Security editions, and Security Onion Pro adds OIDC single sign-on, FIPS and STIG hardening and reporting. Ask both vendors for written confirmation of the current edition terms.
Finally, check whether the team already runs OpenSearch or Elasticsearch. Graylog 7.2 uses OpenSearch 1.1.x to 3.7.x or Graylog Data Node as its search backend, and Security Onion uses Elasticsearch. Operating two different search stacks doubles upgrade and skills work, so a team with an existing OpenSearch cluster may prefer a design that reuses it. The choice is also not always exclusive. Security Onion sensors can forward alerts or logs to a central log platform, and Graylog can ingest syslog or other feeds from network tooling, so some organizations run both. Decide early whether the SOC needs one console or whether separate consoles per function are acceptable, and write that decision into the shortlist scorecard.
What drives the running cost of each platform
This table compares the recurring cost and operating effort drivers for Security Onion and Graylog, including who is paid for what. Read each row as a question to put to your own quote, since no prices are stated here and the real figure depends on scope, hardware and edition.
| Cost driver | Security Onion | Graylog |
|---|---|---|
| Sensors and capture hardware | Sensor nodes run Suricata, Zeek and full packet capture, so capacity follows the traffic volume you tap. Bare minimum is 4 CPU cores, 24GB RAM and 200GB storage for a standalone install, and the documentation suggests 32GB of RAM or more even for small traffic volumes. | No sensor layer is required. Costs center on log ingest nodes and the search backend, so sizing follows daily log volume and retention rather than packet throughput. |
| Storage and search nodes | Storage grows with retained packet capture, Zeek logs and alerts in the Elasticsearch-based backend. A distributed design adds manager, search and sensor nodes, each a recurring infrastructure line. | Storage grows with indexed log retention. Graylog 7.2 stores configuration in MongoDB and indexes data in OpenSearch 1.1.x to 3.7.x or Graylog Data Node, so you pay for both the MongoDB and search tiers. |
| Licensed edition or Pro features | Security Onion Pro is a paid license that adds OIDC single sign-on, FIPS and STIG hardening, notifications, the Security Onion API, Manager of Managers and reports. Ask whether these features are needed at launch. | Index archiving, correlation, reporting and prebuilt Illuminate detection content sit in Graylog Enterprise or Graylog Security, not Graylog Open. Ask which of these you need before comparing totals. |
| Analyst and tuning skills | Ongoing effort goes into tuning Suricata rules, Zeek scripts and sensor placement. Ask the vendor or partner who owns rule tuning and alert triage, and whether that is inside the quote or a retainer. | Ongoing effort goes into stream routing, pipeline rules, alert conditions and index sets. Ask who maintains parsing rules as log sources change and whether that work is scoped as a recurring retainer. |
| Upgrades across release lines | Security Onion 3.0.0 was released on March 31, 2026, and 3.3.0 on September 11, 2026. Each upgrade touches the sensor, search and manager tiers, so ask for upgrade testing and a rollback plan in the scope. | Graylog 7.2.0 was released on October 12, 2026. Upgrades must match the supported MongoDB and OpenSearch or Data Node versions in the compatibility matrix, so budget for coordinated upgrades across tiers. |
| Support and retainers | Most engagements are fixed-scope, with ongoing support and upgrades available as retainers. Confirm response expectations and who on the team supports Suricata, Zeek and the Elastic-based stack. | Ongoing support, upgrades and continuous testing are available as retainers. Confirm whether support covers Graylog, the search backend and MongoDB, since each may have a different owner. |
Moving from one platform to the other
This sequence shows how a team moves monitoring from Security Onion to Graylog, or the reverse, by separating what carries over (raw logs and some stored data) from what must be rebuilt (detections, dashboards, alert logic and access models). The end state is one platform carrying the workload, with the old one retired only after parallel running confirms coverage.
Inventory sources and existing detection content
Start by listing every data source the current platform receives: Suricata and Zeek logs, full packet capture if retained, Strelka file analysis output, endpoint or syslog feeds, and any cloud audit streams. For each source, record the collection method, retention period, owner and the detections, dashboards and alerts that depend on it. Security Onion sensors and Graylog inputs handle traffic differently, so note which sources are network sensor output and which are log events. The step is done when the team has a single inventory that a SOC lead and a platform owner have both reviewed, with no source left unassigned.
Decide what transfers and what gets rebuilt
Sort the inventory into three groups: raw logs that can be re-sent to the new platform, stored index data that can be moved only where the target supports the same format, and content that must be rewritten. Raw logs are usually the easiest to carry over. Stored index data rarely moves cleanly between a Security Onion Elasticsearch stack and a Graylog search backend, so plan for it as historical reference rather than a live migration. Detections, dashboards, alert logic and role-based access models almost always need rebuilding. The step closes with a written decision for each item, approved by the SOC and compliance owners, and a list of questions to confirm with the vendor or in your own environment.
Rebuild sensor placement or input pipelines
On the Security Onion side, this means planning how Suricata, Zeek and packet capture sensors connect to the manager and search nodes, and whether traffic monitoring stays in place. On the Graylog side, it means defining inputs, extractors and any pipeline rules that parse the events that Security Onion would normalize. For network monitoring, confirm the sensor placement on each span port or tap is preserved, since a log-centric platform will not reproduce packet capture on its own. The step is complete when a test feed from each source reaches the new platform and the parsed fields match what the SOC expects.
Recreate detections, dashboards and alert logic
Translate each detection from the inventory into the target platform's format. Security Onion uses Suricata rules, Zeek scripts and Elastic-based alerting, while Graylog uses streams, pipelines and its alerting and correlation features, some of which sit in paid Graylog editions. Rebuild dashboards around the questions analysts ask, not around a copy of the old views. Test each rule against replayed or sample events and record the expected result. The step is done when every retained detection has a documented test and an owner, and any gaps are logged as accepted risks with a date for review.
Rebuild access models and single sign-on
Map the existing roles, groups and permissions to the new platform's model. Confirm which identity features you need, such as single sign-on through OpenID Connect or SAML, and check whether they are available in the edition you plan to run. Security Onion Pro lists OIDC single sign-on and FIPS and STIG hardening among its paid features, and Graylog's identity and role features depend on its edition, so confirm both against the current documentation. The step closes when a test account for each role can see only the data and actions it should, and the access review has been signed off.
Run both platforms in parallel
Keep the old and new platforms receiving the same sources for a period agreed in your change plan, comparing alert volume, detection hits and dashboard coverage. Look for differences in both directions: alerts that fire on one platform only, missing parsing fields, and sources that silently stop arriving. Record every discrepancy and its resolution. The parallel period is complete when the team has reviewed the comparison with the SOC, all differences are resolved or accepted, and the new platform has handled at least one incident or test scenario end to end. Duration depends on your environment and change control, so confirm it with your own governance process.
Retire the old platform and archive evidence
Once the new platform is confirmed, stop the old sensors and feeds in a controlled order, starting with inputs so no new data lands on the retired system. Export and archive configuration, detection content, retention settings and any stored data your compliance or legal requirements need. Check the license terms of the platform you are retiring, since Security Onion uses the Elastic License 2.0 and Graylog Open uses the SSPL, and make sure your use of either has ended cleanly. The step is done when the archive has been verified as readable, access to the retired system has been revoked, and the change record is closed.
Where Security Onion and Graylog projects usually run long
Security Onion projects usually run long at the sensor layer, because the work starts with traffic visibility. Before any alert is useful, the team has to confirm which segments carry the traffic they care about, where the sensors can see that traffic (span or tap placement, mirrored ports, cloud virtual network mirroring where it exists), and whether the packet capture design matches the retention the SOC actually needs. Suricata, Zeek and full packet capture all depend on that placement, so a sensor that sees only part of east-west traffic produces a SOC that looks busy but blind. Ask the implementation partner to produce a written sensor map and a capture retention plan before any hardware is ordered. Check the current hardware guidance in the Security Onion hardware documentation, which lists minimums and suggests more memory once even modest traffic is monitored.
Graylog projects usually run long at input, stream, pipeline and index design, and the delays are rarely technical in isolation. Teams often add sources faster than they define parsing, which pushes normalization into search-time work and makes later correlation fragile. Index sizing is the other common failure: retention, replica settings and daily volume must be modeled against the search backend, whether self-managed OpenSearch or Graylog Data Node, before production data arrives. Licensing reviews add weeks in regulated organizations, because index archiving, correlation and prebuilt Illuminate content sit in paid Graylog Enterprise or Graylog Security editions, and the SSPL terms need legal sign-off. Identity integration (single sign-on, role mapping for analysts and administrators) and rule tuning against real false positive rates are the final gates. Confirm each with the vendor and in writing before scope is agreed, because none of these durations can be estimated from this page.
Questions buyers ask before choosing or hiring help
How much operating effort does Security Onion need compared with Graylog?
Security Onion needs more ongoing attention because it runs a full sensor stack: Suricata, Zeek, Strelka, full packet capture and Elasticsearch in one distribution. Its recommended distributed layout separates manager, search and sensor nodes, and each sensor needs tuning against your traffic. Graylog centers on log ingestion, streams, pipelines and search, so its day-to-day work is mostly parsing and alert logic. Neither figure is fixed, so ask each vendor for its sizing guidance and count the node roles you plan to run. The Security Onion architecture documentation shows the layout to model.
Does a SOC watching network traffic need Security Onion or Graylog?
A team that needs network-level visibility, such as Suricata alerts, Zeek connection logs and retained packet captures, usually fits Security Onion better because those capabilities come in the box. A team whose main job is centralizing syslog, application and cloud logs across many sources usually fits Graylog better. Many SOCs run both, with Security Onion as a sensor source feeding a central log platform. Confirm which data sources drive your detections before deciding, since that choice usually settles the question.
Can an internal team run Security Onion without outside help?
A team with Linux administration, Elasticsearch experience and someone who can own detection tuning can run Security Onion alone, but the distribution has many moving parts. Hardware planning matters early. Security Onion's hardware documentation lists a bare minimum of 4 CPU cores, 24GB RAM and 200GB storage for a standalone install and suggests 32GB of RAM or more when monitoring even a small amount of traffic. Gaps usually appear in upgrades, sensor placement and tuning, so list those skills honestly before deciding whether to hire help.
Does the Elastic License 2.0 or SSPL block our internal use?
Internal use of Security Onion under the Elastic License 2.0 is generally not restricted, but ELv2 forbids offering the software as a managed service to third parties. Graylog Open uses SSPL-1.0, which is not OSI approved and carries its own network-service obligations. Read both license texts with your legal team, especially if you plan to resell monitoring or host it for subsidiaries. The Security Onion license documentation explains the Security Onion terms, and the Graylog LICENSE file in its repository covers the server.
What is the difference between Security Onion Pro and Graylog Enterprise costs?
Both are paid layers on top of an open core, so the recurring cost is the license plus the people who run the platform. Security Onion Pro adds OIDC single sign-on, FIPS and STIG hardening, notifications, the Security Onion API, Manager of Managers and reports. Graylog places index archiving, correlation, reporting and prebuilt Illuminate content in Enterprise or Security. Ask each vendor for current subscription pricing in writing, and ask which features your use case needs before comparing totals.
What does a switch between Security Onion and Graylog involve?
Switching means moving data sources, detection logic and retained history, which is usually more work than swapping software. Security Onion's data model centers on Elastic indices and Suricata or Zeek outputs, while Graylog uses its own streams, pipelines and index sets. Plan for rebuilding alert rules, re-onboarding log sources and deciding whether old packet captures or logs need to stay searchable. A written migration scope with a named owner for each source is the practical way to estimate the effort.
What should we put in a written scope for either platform?
Ask for the node layout, sizing assumptions, data source list, detection content to be built or tuned, identity integration, backup and retention approach, upgrade plan and handover documentation. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your environment, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the choice between Security Onion and Graylog is tested against your traffic, your log sources and your team's operating capacity. We begin with the monitoring job itself, then build and hand over only what that job needs.
How we scope
- We confirm whether the SOC needs network traffic analysis, centralized log management, or both before any platform is chosen.
- The written scope lists sensors, search nodes, log sources, retention targets and hardware assumptions for your environment.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen platform inside your cloud accounts, data centers or air-gapped network, following your change control.
- Integration covers your identity provider, log sources, alert routing and any licensing decisions for paid editions.
- We test detection content and ingestion against your own traffic and logs, and record the results in the handover documentation.
How we hand over
- You receive architecture, runbooks, configuration records and the evidence needed for internal or external compliance reviews.
- Operators are trained on daily triage, rule tuning, upgrades and backups for the platform you run.
- DeployOpen prepares controls and evidence for compliance assessments, while independent auditors issue any formal reports.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Before any upgrade, we confirm the license terms and component versions that apply to your deployment.
- Ask any provider to confirm the support hours, response commitments and upgrade cadence in the written quote.
