Open source network monitoring for CIS Control 13

What CIS Control 13 asks of open source network monitoring

If your enterprise is assessing CIS Controls v8.1 and has no network monitoring evidence yet, three safeguards define what you must build: Safeguards 13.1, 13.3 and 13.6 cover centralized security event alerting, network intrusion detection and network traffic flow logs. All three apply from Implementation Group 2 (IG2) upward, so an IG1 enterprise does not carry them as requirements, although the underlying practice is still useful. CIS Control 13 belongs to the Network asset class and the Detect security function, which means its evidence should come from sensors, flow records and alert pipelines that watch traffic crossing your network, not from endpoints.

CIS publishes the *CIS Controls Assessment Specification* for v8.1, which defines the inputs, operations, measures and metrics an assessor uses to verify each safeguard. It states what to measure, not how to build it, so the design choices are yours. Two points matter before you select tools. First, Safeguard 13.1 is scored as failing if there is no log correlation or log analytics tool, so an alerting pipeline is a hard requirement rather than an optional improvement. Second, CIS states that the Controls do not replace regulatory, compliance or authorization schemes. If HIPAA, the FTC Safeguards Rule or a sector regulator also applies, the same sensors may need to produce different evidence.

The rest of this page maps Suricata, Zeek and Security Onion to each safeguard, notes which parts of the stack are source-available rather than OSI-approved, and sets out the deployment and cost questions to resolve before a rollout. Confirm early which implementation group your organization falls under, which assessment scope your auditor will use, and whether the network you must monitor is connected to the internet. Those three answers decide most of the design.

How each CIS Control 13 safeguard maps to the platform configuration

This table compares what each in-scope safeguard asks for, how Suricata, Zeek and Security Onion can be configured to meet it, and where the implementation group applies. All three safeguards sit in IG2, so IG1 enterprises are outside their scope. Confirm final scope and evidence against the CIS Controls Assessment Specification measures for your environment.

Safeguard	What the function must do	How to configure Suricata, Zeek and Security Onion	Implementation group
13.1 Centralize security event alerting	Send security events from enterprise assets to one place so logs can be correlated and analyzed. A missing correlation or log analytics tool produces a failing score.	Forward Suricata alerts, Zeek logs and host events into the Security Onion manager or search nodes. Define correlation alerts for security-relevant patterns and confirm which sources are in scope.	IG2 and IG3, not IG1
13.3 Deploy network intrusion detection	Provide a network intrusion detection solution where appropriate, such as a NIDS or an equivalent cloud provider service.	Run Suricata sensors at the network boundaries and critical internal segments that you define. Load and tune NIDS rules through the Security Onion Detections interface and document coverage gaps.	IG2 and IG3, not IG1
13.6 Collect network traffic flow logs	Collect network traffic flow logs and or traffic from network devices so they can be reviewed and alerted on.	Configure sensor taps or span ports and Zeek connection and flow logs, and confirm which network devices export flow data into the platform. Set retention to match your review and alerting needs.	IG2 and IG3, not IG1
Asset class and security function	All three safeguards use the Network asset class and the Detect security function in CIS Controls v8.1.	Use this mapping to organize evidence by asset class and function in your control register. Keep sensor, alert and log records together for each safeguard.	Same for all three
Sensor placement	Assessors look for visibility where the defined network risk sits, with the placement rationale documented.	Choose placement qualitatively by trust boundary and critical segment. Record which zones are covered, which are not and why, and confirm the placement against the CAS measures.	Scope set by the enterprise
Rule tuning and alert handling	Alerts must be reviewed and noisy rules managed so the correlation output remains usable.	Use suppression and threshold tuning for NIDS rules and custom filters for Sigma rules. Keep records of changes and the reasons for them.	Scope set by the enterprise
Deployment constraints	Platform components must run on supported infrastructure and keep working when a component fails.	Security Onion supports only x86-64 and Oracle Linux 9 for version 3. Confirm hardware sizing, and note that search nodes stop indexing if the manager is unavailable.	Confirm with the vendor and your environment

Which open source platforms fit each safeguard

Safeguards 13.1, 13.3 and 13.6 call for intrusion detection, flow or traffic collection and centralized alerting, and no single open source tool covers all three on its own. The cards below cover the engines, the integrated stack and the correlation and adjacent tools that teams commonly combine, along with the license and edition choices that affect each one.

Suricata as the NIDS engine

Suricata is the detection engine most teams start with for Safeguard 13.3. It is developed by the Open Information Security Foundation and licensed under GPL-2.0. Version 8.0.7 was published on September 15, 2026. It runs as intrusion detection, intrusion prevention or pure network security monitoring, so the first decision is the mode, not the product. Check how rule sets are sourced and updated, how alerts are exported to your SIEM, and whether sensors on your link speeds keep up without packet loss. Those checks determine whether the engine satisfies the safeguard in practice.

Zeek for metadata and protocol logs

Zeek is a network analysis framework rather than a signature engine, so it supports Safeguard 13.6 by producing structured logs of connections, DNS, HTTP and file activity that can be reviewed and alerted on. It is distributed under a BSD-style license from the Regents of the University of California. Version 9.0.0 was published on August 21, 2026. Plan for scripting and log shipping work, and confirm which protocols your sensors must parse, since that list shapes both sensor load and retention.

Security Onion as the integrated stack

Security Onion bundles Suricata, Zeek, osquery and the Elastic stack into one console, sensor and search platform. It is licensed under the Elastic License 2.0, which is source-available and not an OSI-approved open source license, so have counsel confirm that the terms fit your internal use and any managed-service model. Version 3.3.0-20260911 was published on September 11, 2026. Oracle Linux 9 is the only supported OS for version 3. Pro adds OIDC single sign-on, FIPS mode and professional support on a paid term.

Wazuh for SIEM correlation under 13.1

Safeguard 13.1 asks for centralized alerting and correlation, which Security Onion covers through its Elastic stack but which some teams prefer to run as a dedicated SIEM. Wazuh is an open source XDR and SIEM platform licensed under GPL-2.0, and release v4.14.9 was published on October 15, 2026. The CIS assessment accepts a log analytics platform with security-relevant correlation rules, so the evidence to prepare is the rule set and its alert history. Confirm that Wazuh ingests your Suricata and Zeek output and that its agent footprint suits your network devices.

Shuffle and MISP as adjacent tools

These tools are optional and sit outside the three core safeguards. Shuffle is a SOAR platform licensed under AGPL-3.0, and version v2.3.0 was published on September 28, 2026. MISP is threat intelligence sharing under AGPL-3.0, and v2.5.50 was published on October 10, 2026. Use Shuffle for alert enrichment and triage steps, and MISP for indicators to feed detection rules. Both add operating burden, and AGPL-3.0 obligations apply if you modify and expose them over a network, so review them with your legal team before adding them.

How Security Onion Distributed deployment supports 13.1 and 13.6

For production, the Distributed deployment is the design to plan around. Security Onion's architecture documentation recommends a manager node, one or more sensor nodes and one or more search nodes. The sensors run Suricata and Zeek against mirrored traffic and produce the network evidence that Safeguard 13.6 asks for, while the search nodes hold the indexed events that Safeguard 13.1 needs for centralized correlation and alerting. Before you size anything, confirm with Security Onion how many sensors and search nodes your traffic volume and retention targets require, since those counts drive the rest of the bill of materials.

The manager is the dependency to plan for. The architecture docs state that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Receiver nodes add pipeline redundancy and load balancing, so ask your implementation partner whether receivers are part of the design and how alerting and evidence collection behave during a manager outage. Hardware minimums from the hardware documentation are 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor. These are floors, not sizing guidance. Security Onion supports only x86-64 processors, so confirm that your hardware standard meets that requirement before procurement.

Version choice comes next. Security Onion 3.0.0 was released on March 31, 2026 and supports only Oracle Linux 9. It also replaced Stenographer with Suricata for full packet capture. Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024. If your environment already runs 2.4 on Oracle Linux 9, the documented path is an upgrade to 3 after the packet capture change; other distributions need a fresh install. Ask your partner to document the operating system, the version pinned for each node type and the upgrade path, because that record becomes part of the evidence that your 13.1 and 13.6 monitoring is maintained.

How the setup changes for connected and air-gapped networks

Where sensors and the manager can reach outside networks, the rule sources and update path are set by your network policy. The main decisions for your team are which rule sources to trust, who approves changes, and how tuning is recorded so an assessor can follow it.

Rule sources: The Detections interface in the Security Onion Console manages NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka. Confirm which sources your deployment pulls from and who signs off on each one.
Tuning controls: NIDS rules can be modified, suppressed or threshold-tuned from the console, and Sigma rules can receive custom filters. Each change should carry a reason and an owner.
Update path: Confirm in the current documentation how packages and detection content are fetched, and which proxy and egress rules apply to the manager and sensor nodes.
Change records: Keep a log of every suppression and threshold change so the reason for a silenced alert can be shown during review.

Check the update mechanism and egress rules against the exact version you plan to deploy, because the connected path depends on your firewall and proxy policy.

What auditors ask to see as evidence for CIS Control 13

This table lists the evidence items an assessor is likely to request for Safeguards 13.1, 13.3 and 13.6 and the component that usually produces each one. Read it as a starting checklist, then confirm the exact measures against the CIS Controls Assessment Specification for each safeguard before you collect anything. The main takeaway is that the evidence is mostly configuration, logs and records kept over time, not a one-time tool install.

Evidence item	What it proves	Component that produces it
Sensor inventory and placement diagrams	Which network segments are monitored, where taps or spans sit, and which sensors feed which manager	Security Onion manager and sensor configuration, plus the network team's diagrams
NIDS rule set and version records	Which Suricata rules are loaded, where they came from, and when they were last updated	Security Onion Console Detections interface for NIDS rules
NIDS tuning and suppression records	Why rules were modified, suppressed or thresholded, and who approved each change	Security Onion Console Detections interface (modify, suppress and threshold settings) plus change tickets
Centralized alert logs	Security events from across in-scope network assets reach one place for correlation	Security Onion Console and Elasticsearch alert store fed by Suricata and Zeek
Correlation and alerting rule definitions	Which rules trigger alerts for security-relevant patterns, such as Sigma detections run through ElastAlert	Security Onion Detections interface for Sigma rules, plus any SIEM or log analytics correlation rules
Flow and traffic collection configuration	Zeek and Suricata are collecting network metadata or traffic from the monitored points	Zeek logs and Suricata EVE output settings, reviewed in the Security Onion deployment
Alert triage records	Alerts were reviewed, classified and escalated or closed, with a named analyst and a date	Case or ticketing records linked to Security Onion alerts (confirm the tool your team uses)
Sensor health and retention settings	Sensors are running, dropping no unexplained traffic, and keeping logs for the period your policy sets	Security Onion health views, sensor logs and storage configuration

Questions buyers ask before hiring help with CIS Control 13 monitoring

What drives the cost of CIS Control 13 network monitoring with open source tools?

The main cost drivers are the number of sensor sites, the tap or span hardware at each one, storage for metadata and any full packet capture, and the analyst time needed to tune rules and work alerts. Software for Suricata, Zeek and Security Onion carries no license fee under their open source terms, but Security Onion Pro is a paid edition sold on 1 to 5 year terms, so it is a recurring line item if you need its features. Ask any partner for a quote that separates one-time work (design, deployment, initial tuning) from recurring work (upgrades, rule maintenance, monitoring support), and that lists hardware, storage and licensing as their own lines. DeployOpen does not publish a price list; a quote follows from the written scope.

How long does a network monitoring rollout take?

The duration depends on the number of sites, how much network documentation exists, hardware lead times and how quickly change windows can be scheduled, so it should be confirmed in the written scope rather than assumed. Most engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. Ask the partner to break the timeline into design, sensor deployment, tuning and handover, and to state which steps depend on your change approvals or hardware delivery.

What does our team need to provide before a monitoring engagement starts?

Expect to provide current network diagrams, an inventory of segments and their purposes, the switch or firewall locations where a span or tap can be placed, and access to configure mirror ports. You will also need named change windows for sensor installs, a contact who can approve maintenance on production links, and analyst time to review alerts during tuning. Without these inputs, sensor placement and alert tuning take longer and are more likely to need rework. Ask the partner to list these dependencies in the scope document with an owner for each.

Can our own team run CIS Control 13 monitoring in house?

Yes, if you have people with solid Linux administration skills and network analysis experience. Security Onion's Distributed deployment, which is the recommended production design, uses a manager node, sensor nodes and search nodes, so you will need to operate those components, manage the rule sets for Suricata and Zeek, and keep the platform patched. Security Onion supports only x86-64 processors and, in version 3.x, only Oracle Linux 9, so confirm the platform matches your standards. Many teams split the work: they run the platform internally and buy design review, initial tuning or upgrade support from a partner.

Do we need CIS Controls Accreditation to implement Safeguard 13.1, 13.3 and 13.6?

No. CIS Controls Accreditation, run with CREST, accredits CIS SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services. It is a status for service providers, not a requirement for your organization. The CIS application fees are $1,500 for CREST members and $2,500 for non-members. DeployOpen does not issue certifications or attestations. It can prepare systems, controls and evidence for your own assessment, but an independent assessor or auditor makes the judgment. Ask any partner to explain what evidence they will produce and who will review it.

What does Implementation Group 2 mean for a smaller enterprise?

Safeguards 13.1, 13.3 and 13.6 are assigned to Implementation Group 2, so they apply to IG2 and IG3 enterprises but not to IG1. CIS describes IG1 as essential cyber hygiene for every enterprise, and IG2 as the group for organizations with more operational complexity that often hold sensitive information. A smaller enterprise that falls in IG1 is not required to meet these three safeguards under CIS, but it may still face regulatory expectations for monitoring. Confirm your implementation group with a written assessment before you scope the work, because a regulator or customer contract may require monitoring regardless of CIS grouping.

What breaks most often in a Suricata and Zeek deployment?

The most common problems are packet loss at peak traffic, sensors placed where they cannot see the traffic that matters, and alert floods that bury real detections. Sensor sizing should be checked against your link speeds before deployment, and tap or span placement should be verified with traffic captures. If the Security Onion manager goes down, search nodes stop indexing because they cannot reach Redis, so plan for manager availability and consider receiver nodes for pipeline redundancy. Ask the partner how they test for packet loss, how they document rule sources and suppressions, and how they handle the upgrade path, since Security Onion 2.4 reached end of life on October 1, 2026.

What open source tooling alone does not satisfy

Suricata, Zeek and Security Onion cover much of the detection work in CIS Control 13, but several safeguards and compliance obligations depend on things a sensor cannot provide. The cards below cover the correlation layer, flow logging, licensing, regulatory scope and documented ownership that a readiness review should confirm first.

Correlation layer for safeguard 13.1

Safeguard 13.1 asks for security event alerting to be centralized so logs can be correlated and analyzed. The CIS Controls Assessment Specification gives a failing score when an enterprise has no log correlation or log analytics tool. A sensor that raises alerts is not enough on its own. You need a SIEM or log analytics platform with security-relevant correlation rules, fed by sensor output and endpoint and identity logs. Confirm that the configured rules exist, are versioned and are reviewed.

Flow logs for safeguard 13.6

Safeguard 13.6 asks for network traffic flow logs or network traffic collected from network devices so they can be reviewed and alerted on. A NIDS such as Suricata generates alerts on matching signatures, but it does not by itself produce a complete record of who talked to whom. Zeek connection and protocol logs, or flow records from switches and firewalls, fill that gap. Confirm which sources feed the flow record, how long they are kept and whether they reach the central alerting platform.

Source-available licensing for Security Onion

The Security Onion repository is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved open source. Internal use is usually straightforward, but offering it as a managed service or redistributing it can fall outside the terms. Security Onion Pro is a separate paid edition on 1 to 5 year terms. Have counsel read the current license and the Pro terms against your intended use before you commit, and record the outcome in your procurement file.

CIS Controls do not satisfy regulation

CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. A deployment that meets safeguard 13.3 and 13.6 can still fall short of an obligation such as HIPAA audit controls or the FTC Safeguards Rule's monitoring and logging requirement. Map each regulatory obligation to specific sensor, log and retention evidence. Ask your assessor which requirements apply to your environment before you treat CIS alignment as sufficient.

Documented processes and ownership

The CIS Controls Assessment Specification defines what to measure for each safeguard, but CIS says it covers what to measure, not how. An assessor will still ask who reviews alerts, how tuning changes are approved, how sensor outages are reported and who owns rule updates. Write these procedures, assign named owners and keep records of reviews. Without them, a technically working sensor can produce no verifiable evidence.

How a CIS Control 13 monitoring rollout is sequenced

The sequence turns Safeguards 13.1, 13.3 and 13.6 from a list of requirements into a monitored network, tuned alerting and an evidence pack that an assessor can trace back to each Safeguard. Each step closes with a check that confirms it is complete before the next one starts.

Scope the assets and confirm the IG tier
The client's security lead and the DeployOpen team list the network segments in scope, the enterprise assets that generate or carry sensitive data, and the Implementation Group the enterprise is assessed against. Safeguards 13.1, 13.3 and 13.6 apply to IG2 and IG3 enterprises, so an IG1 organization should confirm with its assessor whether these Safeguards are in its scope before buying hardware. The step closes with a signed scope list that names each segment, its owner and the Safeguards it supports.
Design sensor placement and tap points
Engineers map where traffic can be observed, such as the internet edge, core links between zones and segments that hold sensitive systems, and choose between span ports and network taps at each point. They confirm link speeds, the number of NICs per sensor and whether any encrypted or proprietary traffic limits what Zeek and Suricata can parse. The step closes with a placement diagram and a sizing note for each sensor that the client's network team has reviewed and approved.
Deploy Security Onion Distributed in test, then production
The team builds a test deployment first, using the Distributed design the Security Onion documentation recommends for production, with a manager node, sensor nodes and search nodes. The test run checks sensor capture, log delivery to the search nodes and the effect of a manager outage, since search nodes stop indexing when they cannot reach the manager. Production follows only after the test passes, and the step closes with a deployment record that lists versions, node roles and the ISO or update path used.
Tune rules and build correlation alerts
Analysts load the Suricata NIDS rule sets through the Security Onion Detections interface, suppress known benign traffic and set thresholds for noisy rules, then build correlation alerts that combine Suricata, Zeek and host logs into security-relevant events. This addresses Safeguard 13.1, which requires that security events from enterprise assets be centralized and correlated. The step closes with a tuning log that records each change, the reason for it and the alert that now fires for each correlation use case.
Collect the evidence pack
The team assembles the records an assessor will ask for: the scope list, the placement diagram, sensor and flow log configuration, screenshots or exports showing traffic collection from network devices for Safeguard 13.6, alert samples with triage notes, and the tuning log. The client's control owner reviews the pack against the Safeguard descriptions in the CIS Controls Assessment Specification and confirms each item is current. DeployOpen prepares this evidence, while the independent assessor decides whether the Safeguards are met.

How DeployOpen scopes, deploys and documents CIS Control 13 monitoring

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For CIS Control 13 monitoring, that means agreeing in writing which safeguards, sensors and log sources are in scope before any sensor is installed.

How we scope

Confirm your Implementation Group and which Control 13 safeguards apply to your enterprise before design starts
Inventory tap and span points, link speeds and network segments that sensors must cover
Agree in writing which Suricata, Zeek and Security Onion components, log sources and alert paths are included

How we build

Deploy Security Onion sensors, manager and search nodes in your environment, sized from your traffic profile
Load and tune NIDS rules in Suricata and document each suppression and threshold change
Connect flow and alert data to your central log correlation tool and test that alerts reach the people who act on them

How we hand over

Deliver architecture diagrams, sensor inventory, rule and tuning records, and runbooks for upgrades and failover
Map each in-scope safeguard to the configuration, logs and screenshots an assessor would ask to see
Train your operators on the Detections interface and document the evidence collection routine you agreed

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer under a separate written agreement
Ask any partner, including DeployOpen, to confirm current Security Onion release and end-of-life dates before planning upgrades