Which SIEM fits a team leaving or weighing Microsoft Sentinel
Sentinel fits cloud-first log analytics with Microsoft data sources, while Security Onion fits teams that need on-premises network monitoring and full packet capture. If your reader is facing the move to the Defender portal, or has a gap in network visibility that log data alone cannot close, the question is less about which product is better and more about where your data should live and who will operate the platform. Security Onion is a free Linux distribution that bundles Suricata, Zeek, the Elastic Stack and Suricata full packet capture, but its repository is licensed under the Elastic License 2.0, a source-available license rather than an OSI-approved open-source license. Legal and procurement teams should read that license before treating it as open source in policy documents.
Four factors should drive the decision. The first is data location: Sentinel runs in Azure, while Security Onion can be installed in your own data center, cloud accounts or an airgapped network, which the Security Onion airgap documentation covers. The second is network visibility: if you need Suricata alerts, Zeek metadata and packet capture from sensors on your links, Security Onion is built for that job, while Sentinel depends mostly on the log sources you connect. The third is staffing, since Security Onion's Distributed design needs a manager, sensors and search nodes that someone must patch, tune and back up. The fourth is whether Azure is the right home for the data at all. Ask your Microsoft account team what the Defender portal move changes for your retention and privacy terms, and confirm current Security Onion hardware and licensing details against the Security Onion Pro page before you size anything.
Scenarios where each option is the better fit
This table sets out the situations where Microsoft Sentinel or Security Onion is the stronger choice, with the condition that drives each answer. Read each row against your own telemetry sources, hosting constraints and support requirements, since most mixed environments end up using both tools for different jobs.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Azure-native SOC relying on Microsoft connectors | Microsoft Sentinel | Most sources are Microsoft Entra ID, Defender and Azure logs collected through built-in connectors with little custom parsing |
| Network team needing Suricata and Zeek visibility | Security Onion | Detection depends on network metadata, NIDS rules and protocol logs that Security Onion bundles and tunes in its Console |
| Air-gapped or disconnected sites | Security Onion | Sentinel runs in Azure, while Security Onion ships an ISO with packages and NIDS, YARA and Sigma rules for airgap updates |
| Packet capture must stay on your own hardware | Security Onion | Suricata full packet capture runs on sensor nodes you size and control, so capture data never leaves your network |
| Sites that must avoid cloud log storage | Security Onion | Logs, alerts and captured traffic are stored in your data centers, subject to your own retention and access design |
| Buyer who needs a vendor support contract | Microsoft Sentinel | Microsoft provides service support under its Azure agreements, while Security Onion Pro offers professional support on a paid tier |
| Team working with Linux-only skills and no Azure footprint | Security Onion | Operations depend on Linux administration of the Oracle Linux 9 base and Elastic-based search, rather than Azure administration |
| Mixed estate that needs both cloud and network detection | Both, in parallel | Sentinel covers cloud identity and SaaS signals while Security Onion covers east-west and north-south traffic, with correlation done in your own pipeline |
Where the data lives and who controls it
Sentinel keeps your logs in Azure workspaces that now fall under Defender XDR policies, while Security Onion runs inside your own data center or cloud account. The cards below cover where data sits, who sets retention and privacy rules, how sign-in works, and who owns the compliance evidence.
Sentinel data sits in Azure workspaces
Sentinel stores ingested logs in Log Analytics workspaces in the Azure region you choose, and the platform runs on Microsoft's infrastructure. Confirm which Azure region and workspace model your data would land in, and who in your organization holds the Azure subscription that owns it. Check whether your residency rules accept that region before you ingest regulated data.
Defender XDR policies replace Sentinel's
After March 31, 2027, Sentinel is available only in the Microsoft Defender portal. In that portal, Microsoft Defender XDR data privacy and retention policies apply instead of Sentinel's own settings. Ask your Microsoft account team to confirm which retention and privacy terms govern your tenant before you plan storage and residency.
Security Onion stays in your accounts
Security Onion runs on hardware you control, in your data center, air-gapped network, or in your own Azure, AWS or Google Cloud account through the marketplaces. Your team decides where sensors sit and where search nodes store indexed data. Confirm which of these deployment locations your sovereignty requirements allow before choosing a topology.
OIDC single sign-on is a Pro feature
Security Onion Pro adds OIDC single sign-on to the Security Onion Console, so sign-in can follow your identity provider. Without Pro, confirm with your identity team how Console access is controlled and audited on the edition you plan to run. Map who can view packet captures, since those often contain more sensitive content than logs.
Encryption and FIPS need Security Onion Pro
Security Onion Pro adds LUKS data-at-rest encryption, FIPS mode and OS STIG compliance. Teams that must show encryption and FIPS controls should price Pro into the decision and confirm the required mode with their assessor. Standard Security Onion does not provide these features, so plan compensating controls if Pro is not chosen.
Oracle Linux 9 is required for version 3
Security Onion 3.0.0 supports only Oracle Linux 9, and it replaced Stenographer with Suricata for full packet capture. Existing 2.4 installs on other distributions need a fresh install to reach 3. Check your OS standards and patch process against this single supported base before committing to a migration timeline.
Compliance evidence and ownership
Sentinel evidence lives in Microsoft-managed services and Defender reports, while Security Onion evidence, configuration and logs sit in systems your team administers. Confirm which logs, access records and change histories your auditor will request and where each one is produced. DeployOpen prepares controls and evidence for assessments, but independent auditors issue any audit report or certification.
What Security Onion adds that a log-only SIEM does not
The main difference is the network layer. Security Onion bundles Suricata for network intrusion detection and full packet capture, Zeek for protocol metadata such as connections, DNS, HTTP and TLS sessions, and Elastic Fleet agents for host logs. Since Security Onion 3.0.0, Suricata also handles full packet capture, replacing Stenographer, so a team moving from 2.4 on Oracle Linux 9 should plan that change into its upgrade. A log-only SIEM such as Sentinel sees what endpoints, cloud services and appliances choose to send. Security Onion sees the traffic itself, which matters when an attacker moves laterally without generating a useful log entry. Before you choose, list the detections your team relies on today and mark which of them depend on network visibility. If the answer is few or none, the extra components add operating work without much return.
The Security Onion Console is where the detection content is tuned. It manages NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka, with modify, suppress and threshold options for NIDS rules and custom filters for Sigma. This replaces part of the workflow your analysts currently run in Sentinel analytics rules, but it is a different model. Confirm with your analysts which rule types they write and whether Sigma rules can express your existing correlation logic, because Security Onion does not provide a KQL-style rule language. Plan for tuning time after go-live, since suppressions and thresholds are where most noisy alerts get fixed.
Security Onion does not replicate Sentinel's Microsoft data connectors. Microsoft Entra ID, Microsoft 365 and Defender sources need to be replaced by Elastic Fleet integrations, syslog or API collection, and this work is yours or your implementation partner's to scope. Teams without a network monitoring requirement may get less value from Security Onion than from a log-focused platform, and should compare it against a self-hosted option such as Wazuh before committing. Ask the vendor or your own engineers to confirm which of your current data sources have a supported Fleet integration and which need custom parsing.
Licensing and editions to check before you commit
Sentinel is billed through Azure and changes portal and policy owner in the Defender transition, while Security Onion is free to self-manage under a source-available license with a paid Pro tier. The cards below separate what you pay for, what the license permits and what to confirm with counsel before you commit.
Sentinel billing and the Defender move
Sentinel charges are billed through your Azure subscription, so ingestion, retention and commitment choices all appear on the Azure invoice. After March 31, 2027, Sentinel is available only in the Microsoft Defender portal, and Microsoft says the move carries no extra cost. Confirm with Microsoft which charges continue to apply after the move, and whether your Defender XDR data retention and privacy policies differ from your current Sentinel settings.
Elastic License 2.0 basics
The Security Onion repository is licensed under the Elastic License 2.0, which is source-available rather than an OSI-approved open-source license. Using the software yourself, inside your organization, is the usual case the license is written around. Do not assume you can rebrand it, redistribute it or treat it as a freely reusable component in other products without reading the license text.
Hosting Security Onion as a service
The Elastic License 2.0 restricts providing the software to third parties as a hosted or managed service, so an MSSP or internal platform team offering monitoring to other business units or customers may need a separate arrangement. Ask counsel whether your service model falls under the license terms, and whether Security Onion Pro terms change that answer.
Internal modification and rule changes
Modifying the Security Onion code, detection content or configuration for your own use is generally the kind of use the license permits, but any patch you plan to distribute outside the organization needs review. Your custom Suricata, Sigma and YARA rules are your own content, while changes to Security Onion source code may carry obligations under the license. Keep a record of what you changed and why.
Free self-managed edition
The free edition gives you the Security Onion distribution at no license fee, and your costs shift to the hardware, storage, staff time and support you provide. Standalone, Distributed and other deployment types all remain on the free track. Confirm which features you need from the free edition before comparing it with the paid tier.
Security Onion Pro terms
Security Onion Pro is a paid edition sold on 1 to 5 year terms, and it adds OIDC single sign-on, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, Manager of Managers and professional support. Ask for the price, term length, renewal terms and what happens to your deployment at the end of a term. Compare those costs with the Sentinel charges you would otherwise pay.
What each option costs to run, by component
Sentinel costs arrive as Azure consumption, so the bill follows the data you send and keep rather than a fixed server budget. The main recurring charges are log ingestion and analytics, retention beyond the included period, and any data lake or export usage. Microsoft's Defender portal transition is the other cost question: Microsoft states that moving to the Defender portal has no extra cost, and it must be completed before March 31, 2027, when the Azure portal stops supporting Sentinel.
- Ingestion and analytics charges: Recurring and metered by data volume. Check whether your tier is pay-as-you-go or a commitment tier, and which tables are billed at which rate.
- Retention: Recurring. Retention beyond the default period is charged separately, so long evidence retention grows the bill over time.
- Defender portal transition: One-time effort. Microsoft says the move has no extra cost, but rules, connectors and workbooks still need review, and Defender XDR retention and privacy policies replace Sentinel's own.
- Staff time: Recurring. Someone must tune analytics rules, manage connectors and review alerts, even though Microsoft runs the infrastructure.
Ask the vendor or your Azure account team for a written estimate based on your actual daily volume, table mix and retention settings, and confirm which charges sit under Azure billing versus Defender licensing.
Security Onion costs are mostly capital and operating expense for hardware or virtual machines you control. The published minimums give a starting point for sizing, but production designs usually need more capacity than the minimums, depending on traffic volume, retention and search load. The recommended production layout is Distributed, with a manager node, one or more sensor nodes and one or more search nodes.
- Manager node: One-time purchase or provisioning, then recurring power and hosting. The documented minimum is 4 cores and 16 GB RAM.
- Search nodes: One-time purchase, with the same 4 cores and 16 GB RAM minimum for each search node. Add nodes to scale indexing and queries.
- Sensor nodes: One-time purchase per network tap or span point. The documented minimum is 4 cores, 12 GB RAM and 2 NICs, with at least one monitoring interface placed where traffic is visible.
- Standalone alternative: A single node needs 4 cores, 24 GB RAM, 200 GB storage and 2 NICs at minimum, which suits evaluation rather than large production volumes.
- Hardware constraints: Security Onion supports only x86-64 processors, so ARM hardware is not an option.
The minimums are floors, so request a sizing exercise from your integrator or the Security Onion team that uses your traffic and retention targets, and confirm whether storage is local or network attached.
Storage and network interface costs are where Security Onion expenses diverge most from a cloud SIEM bill. Full packet capture and Suricata alert logs consume disk quickly, so retention length and traffic volume dominate the storage line. Network cards are a one-time hardware cost, but placement determines whether the sensors see the traffic you need.
- Storage capacity: One-time for disks and recurring for replacement and expansion. The documented minimum for a standalone node is 200 GB, but packet capture retention is the factor that most often drives size.
- Full packet capture: Since version 3.0.0 uses Suricata rather than Stenographer, confirm how capture retention and disk use change for your sensors before sizing.
- Network interface cards: One-time. Each sensor and standalone node needs 2 NICs at minimum, and taps or switch span ports may add cost.
- Backup and redundancy: Recurring. Plan for backup of configuration and data, and consider receiver nodes if you need pipeline redundancy.
- Air-gapped updates: The soup tool updates from newer ISO media, so your transfer process and media handling carry a small recurring effort.
Ask for storage and capture estimates tied to your sensor placement, traffic profile and retention target, not just the minimum disk size.
Staff time is the largest recurring cost for both platforms, and the split differs. Sentinel shifts infrastructure work to Microsoft but still requires analytics, connector and workbook ownership. Security Onion requires your team, or a partner, to install, patch, tune detections and operate the sensors, manager and search nodes. Security Onion Pro is an optional paid subscription with its own recurring cost.
- Installation and migration: One-time effort for deployment, sensor placement and rule tuning in the Detections interface.
- Operations: Recurring effort for upgrades, since 2.4 reaches end of life on October 1, 2026 and version 3 requires Oracle Linux 9.
- Security Onion Pro: Recurring subscription on 1 to 5 year terms. It adds OIDC single sign-on, LUKS encryption, FIPS mode, OS STIG compliance, the API and professional support.
- Partner support: Optional, one-time or recurring, depending on whether you buy fixed-scope deployment work or ongoing retainers.
- Training: One-time for analysts who must learn Suricata, Zeek and Elastic-based investigation workflows.
Ask whether Pro is required for your identity, encryption or compliance controls, and ask for the subscription term and what professional support covers in writing.
How much hardware and staff time a Security Onion deployment needs
Start with the deployment type, because it decides how many machines you buy and how much staff time you spend. Security Onion offers four deployment types: Import, Evaluation, Standalone and Distributed. Import and Evaluation suit lab work and offline analysis of captured data. Standalone runs everything on one node, which is workable for a small site but gives you no separation between sensing and searching. The Distributed design, with a manager node, one or more sensor nodes and one or more search nodes, is the recommended layout for production. Receiver nodes can be added for pipeline redundancy and load balancing. The architecture documentation also warns that if the manager goes down, search nodes stop indexing because they cannot reach Redis, so plan manager availability as a first-class risk.
The supplied minimums are a floor, not a sizing answer. A standalone node needs 4 cores, 24 GB RAM, 200 GB storage and 2 NICs. A manager or search node needs 4 cores and 16 GB RAM. A sensor needs 4 cores, 12 GB RAM and 2 NICs. Security Onion supports only x86-64 processors, so ARM hardware is out of scope. Real sizing depends on your traffic volume, how long you keep indexed data, and how deep you capture packets with Suricata. Each of those three drivers scales storage and compute independently. Ask for a sizing review against your measured peak throughput and your retention target before you order hardware, and confirm the current figures in the hardware requirements documentation for the release you intend to run.
The recurring work is operational. Upgrades run through the soup tool, which in airgapped sites updates from newer ISO media. Security Onion 2.3 reached end of life on April 6, 2024, and 2.4 reached end of life on October 1, 2026, so any 2.x estate needs a dated migration plan. Version 3.0.0 supports only Oracle Linux 9, and moving 2.4 installs on Oracle Linux 9 to 3 requires replacing Stenographer with Suricata for full packet capture. Other distributions need a fresh install. The heavier ongoing cost is detection tuning. The Detections interface manages NIDS rules, Sigma rules and YARA rules, and NIDS rules need modify, suppress and threshold tuning to keep noisy alerts from swamping analysts. Budget analyst time for that tuning, and confirm with the vendor who will own it, your staff or a services partner.
What a move from Sentinel to Security Onion involves
The sequence turns Sentinel's cloud analytics into a self-run network and log monitoring platform, with each step producing a checkable output before the next one begins. Sentinel data does not flow into Security Onion automatically, so the historical data and detection rewrite are the main effort.
Scope sources and the network monitoring need
List every Sentinel data source and decide which ones Security Onion must cover: network traffic seen by sensors, endpoint telemetry through Elastic Fleet agents, and firewall or identity logs sent by syslog. Identify the segments where a tap or span port can be placed and whether the site has internet access, since that affects the airgap path. Done when the team has a signed source inventory that separates network sensor data from log data.
Size manager, search and sensor nodes
Map the inventory to hardware using the Security Onion hardware requirements for standalone, manager, search and sensor nodes, and note that Security Onion supports only x86-64 processors. Confirm storage for retention with your own daily volume figures, because Sentinel billing does not translate directly into disk. Ask a quote to show the sizing assumptions and which nodes are one-time purchases and which recur. Done when a sizing sheet lists every node, its cores, memory, storage and NICs.
Choose the deployment type
Select Import, Evaluation, Standalone or Distributed. The architecture documentation recommends Distributed for production, with a manager, one or more sensors and one or more search nodes. Note that if the manager fails, search nodes stop indexing because they cannot reach Redis, so decide whether receiver nodes are needed for pipeline redundancy. Done when the topology diagram names each node role and its network path.
Build sensors, taps and log collection
Install sensor nodes on mirrored or tapped links, confirm that Suricata and Zeek see the expected traffic, and enable full packet capture with Suricata. Configure Elastic Fleet agents and syslog inputs for the log sources in the inventory. Confirm the key tuning on each sensor with test traffic and check that events reach the Security Onion Console. Done when every planned source shows recent events and the packet capture buffer behaves as sized.
Export or retain historical Sentinel data
Sentinel exports do not feed Security Onion automatically, so choose a path for history before cutover. Options include Log Analytics data export to storage that you then load with a script you write, or keeping Sentinel read access until the retention window closes. Confirm with your Microsoft contacts and your compliance owner what must be kept and in what format. Done when a retention plan lists each table, its export method, its destination and the owner who signed it off.
Rebuild analytics rules as Suricata, Sigma and YARA
Translate each Sentinel analytics rule into the matching Security Onion format: network rules as Suricata NIDS rules, log detections as Sigma rules loaded into ElastAlert, and file scanning as YARA rules loaded into Strelka. Manage them in the Detections interface and tune with modify, suppress and threshold settings. This is usually the largest share of the work, because KQL logic does not convert one for one and each rule needs a test against replayed events. Done when every retained rule has a tested equivalent, a documented gap, or a retirement decision.
Run both platforms in parallel
Keep Sentinel ingesting while Security Onion receives the same sources, and compare alerts for a period set by your risk owner. Track alert volume, false positives, missed events and analyst workflow differences, and record each gap found. Confirm that the on-call process, case handling and escalation paths work on the new console before any cutover decision. Done when the parallel run report shows agreed acceptance criteria and each open gap has an owner.
Cut over and retire Sentinel ingestion
Switch alert routing and analyst dashboards to Security Onion, disconnect or reduce the Sentinel data connectors, and confirm that the agreed sources still feed the new platform. Keep the Sentinel exports and the rule inventory under the retention plan. Plan backups and upgrade windows for the new platform, noting that Security Onion 3.0.0 supports only Oracle Linux 9 and that 2.4 reaches end of life on October 1, 2026. Done when a cutover record shows the routing change, the retained archives and the first post-cutover review.
Questions buyers ask before choosing Security Onion over Sentinel
What does migrating from Sentinel to Security Onion cost in effort, and who does the work?
The main cost is staff time, not licensing, because Security Onion is free to download and run. Your team or an implementation partner must size hardware, build a Distributed deployment, rebuild data sources, port detections and tune alerts. Recurring costs include the servers or cloud instances, storage, patching and the people who triage alerts. Ask any partner for a written scope listing each deliverable before work starts, and ask Security Onion Solutions which support tier you would need for production.
How long does a Sentinel to Security Onion move take, and what drives the timeline?
The timeline depends on how many log sources you onboard, how many analytics rules you rewrite, how much history you keep, and whether the network has internet access. Sensor placement for network monitoring and capacity planning also take time. Note that Sentinel moves to the Defender portal only after March 31, 2027, which may set your deadline. Confirm the schedule with your environment owners and the partner in the written scope rather than relying on a general estimate.
Can our team run Security Onion without outside help?
A team with Linux administration, Elastic Stack and network monitoring skills can deploy and operate Security Onion without outside help. The hard parts are the Distributed design, keeping the manager reachable, and tuning Suricata rules and Sigma detections so alerts stay useful. Security Onion documentation covers each deployment type and hardware requirement. Decide honestly whether you have the staff to run it on call, because a missing manager stops search nodes from indexing.
What does Security Onion Pro add, and when is it worth paying for?
Security Onion Pro is a paid edition sold on 1 to 5 year terms. It adds OIDC single sign-on to the Console, 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. It is most worth evaluating when you need those features or vendor support for production. Ask the vendor for current pricing and exactly which features are included in your term, since the price is not part of the supplied facts.
Does the Elastic License 2.0 limit how we can use Security Onion?
The repository is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved open source. Internal security monitoring in your own organization is the typical use, but the license restricts certain uses, such as offering the software to third parties as a managed service. Have your legal counsel read the LICENSE file on GitHub and confirm how it applies to your plans, especially if you resell monitoring or host it for subsidiaries or clients.
How does Oracle Linux 9 affect an upgrade from Security Onion 2.4?
Security Onion 3.0.0 supports only Oracle Linux 9. Installations of 2.4 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 rather than an in-place upgrade. Security Onion 2.4 reached end of life on October 1, 2026, so plan the change soon. Confirm the exact upgrade steps in the Security Onion end-of-life and 3.0.0 documentation before you schedule work.
What hardware and staffing do we need to keep Security Onion running?
Security Onion supports only x86-64 processors. A standalone node needs at least 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, while a manager or search node needs 4 cores and 16 GB RAM, and a sensor needs 4 cores, 12 GB RAM and 2 NICs. Production should use the Distributed design, which adds staff time for patching, rule tuning and alert review. Size your network traffic and retention with the vendor before buying hardware.
Primary sources for this comparison
Start with the Microsoft Learn material, because the Sentinel side of this comparison is changing. After March 31, 2027, Sentinel is available only in the Microsoft Defender portal. In that portal, Defender XDR data privacy and retention policies apply in place of Sentinel's own, and the Fusion analytics rule is replaced by Defender XDR correlation. Read the transition guide against your current workspace settings, and list which analytics rules, retention periods and data handling commitments will change. Those items are the ones most likely to shape a Security Onion decision.
Next, test Security Onion against your own hardware and network before comparing features. The architecture documentation describes the Distributed deployment, with a manager, sensor and search nodes, as the recommended production design, and notes that search nodes stop indexing if they cannot reach the manager. The hardware page lists minimum cores, memory, storage and NIC counts for each role, and the detections, airgap and end-of-life pages cover rule management, disconnected sites and release support. Confirm these requirements through your own sizing exercise, and check the end-of-life dates before you choose a release line.
Finally, review the Security Onion repository and its LICENSE file before seeking internal approval. The project is licensed under the Elastic License 2.0, which is source-available and not an OSI-approved open-source license. Legal and procurement teams should read those terms against how your organization plans to use, modify and offer the software internally. Security Onion Pro is a separate paid edition, so confirm which capabilities your design depends on before assuming they are in the free distribution. Record the license review as a decision item with a named owner.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Microsoft Sentinel vs Security Onion, we start with a written scope that fits your sensor placement, data volumes and detection goals, then build and test the platform with you.
How we scope
- Review which log sources, network segments and sites would feed a Security Onion deployment versus your current Sentinel connectors
- Confirm hardware, sensor placement and whether the platform runs on premises or in a marketplace cloud image
- Agree deliverables, timelines and Security Onion version choice in writing before any work starts
- Engagements are fixed-scope, and ongoing support is available as a retainer after handover
How we build
- Deploy a Distributed layout with manager, sensor and search nodes, or the topology the written scope specifies
- Port Sentinel analytics rules into Suricata NIDS rules, Sigma rules and Security Onion Console detections, with tuning and suppression
- Plan full packet capture retention and storage sizing against the hardware minimums published for each node type
- Test detections with replayed traffic and documented hunting queries before any alert reaches your operations team
How we hand over
- Document architecture, node roles, detection inventory and tuning decisions in a form your analysts can maintain
- Provide runbooks for upgrades, including the Security Onion end-of-life dates and the Oracle Linux 9 requirement for version 3
- Prepare evidence for your compliance assessment, while independent auditors and certification bodies issue any formal opinion
- Walk your security engineers through hunting, rule changes and airgap update procedures where your network requires them
How we support
- Offer retainers for upgrades, rule maintenance, backups and continuous security testing of the deployed platform
- Review license terms with your legal team, since Security Onion is source-available under the Elastic License 2.0
- Advise on Security Onion Pro features if your scope calls for single sign-on, encryption or FIPS mode
- Confirm current support commitments and any Security Onion Pro terms directly with the vendor before you sign
