CMMC Level 2 network monitoring with open source tools

Which CMMC Level 2 practices does network monitoring satisfy?

A defense contractor that handles CUI and wants a network monitoring stack to count toward CMMC Level 2 should plan around two practices: SI.L2-3.14.6 (monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks) and SI.L2-3.14.7 (identify unauthorized use of organizational systems). Both are the CMMC Level 2 versions of NIST SP 800-171 Rev. 2 requirements in the System and Information Integrity family. They are worth 5 and 3 points respectively under the scoring methodology in 32 CFR 170.24, and because each is worth more than 1 point, neither can sit on a POA&M. Both must be MET. Assessors judge them against the assessment objectives in NIST SP 800-171A (June 2018): three objectives for 3.14.6 covering the system, its inbound traffic and its outbound traffic, and two for 3.14.7 covering the definition of authorized use and the identification of unauthorized use.

The evidence side matters as much as the sensors. SP 800-171A points assessors toward a continuous monitoring strategy, documentation of monitoring tools and techniques, the locations where monitoring devices are deployed, audit records, and tests of the intrusion detection and monitoring capability itself. Before you select components such as Suricata, Zeek or Security Onion, write down which network boundaries and internal segments each sensor covers, and confirm that your rules for authorized use are written and current. A requirement is MET only when evidence is in final form, not in draft, so an unfinished monitoring strategy will fail the check even if the sensors are running.

Program status in 2026 changes the timing but not the requirements. On 13 July 2026 the Department of War suspended CMMC Phase II, which would have required Level 2 C3PAO certification for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in force, and the DoW CIO's About CMMC page describes Level 2 as self-assessment only during the pause. The eCFR text of 32 CFR 170.3(e) still carries the original phase schedule, so confirm the current phase with your contracting officer before relying on either version. NIST withdrew SP 800-171 Rev. 2 when Rev. 3 was published, but CMMC still incorporates Rev. 2, and the Department of War has said it will enforce Rev. 2 in the interim. Build to Rev. 2 numbering, and ask your assessor or C3PAO which revision they will use for your evidence.

How SI.L2-3.14.6 and SI.L2-3.14.7 map to sensors, rules and alert workflow

This table maps the two CMMC Level 2 monitoring requirements to what the function must do, how Suricata, Zeek and Security Onion sensors should be placed and configured, and what must be written down. Read each row as one assessment objective group, and note that both requirements are worth more than one point, so each must be fully MET rather than placed on a POA&M. The main takeaway is that an assessor will test the sensor placement and the documented workflow as much as the alerts themselves.

Requirement and points	What the function must do	Sensor and rule configuration	What must be documented
SI.L2-3.14.6, monitor system (5 points)	Show that organizational systems are monitored to detect attacks and indicators of potential attacks, with the monitoring tied to defined systems in the CUI boundary.	Deploy Security Onion in distributed form with sensors covering the CUI enclave, using Suricata for signature detection and Zeek for protocol metadata. Confirm sensor coverage against an asset list of CUI systems.	Continuous monitoring strategy, monitoring tools and techniques documentation, and a list of sensor locations matched to the system boundary diagram.
SI.L2-3.14.6, monitor inbound traffic (5 points)	Detect attacks and indicators of attack arriving from outside the boundary, such as through internet edge, VPN, remote access and partner links.	Place Suricata or Zeek sensors on the perimeter side of firewalls and at each internet or partner ingress point. Load current NIDS rule sets and tune suppressions with recorded reasons.	Sensor placement diagram with tap or span points, rule source and update record, and test results showing that inbound alerts were generated and triaged.
SI.L2-3.14.6, monitor outbound traffic (5 points)	Detect indicators of compromise and data movement leaving the boundary, including command and control, unexpected DNS and exfiltration patterns.	Position sensors at egress points and on segment boundaries that reach external networks. Use Zeek logs for DNS, HTTP, SSL and connection records, and Suricata rules for known command and control indicators.	Egress monitoring procedure, list of monitored egress paths, and sample alerts or log queries showing outbound detections were reviewed.
SI.L2-3.14.7, define authorized use (3 points)	Define what authorized use of CUI systems looks like so that unauthorized use can be recognized against a baseline.	Use Zeek and Security Onion asset and protocol visibility to baseline normal services, administrative protocols and user-facing applications per segment. Feed the baseline into Sigma rules and detection filters in the Security Onion Console.	Written definition of authorized use, approved protocols and services per segment, and the approval record for any change to that baseline.
SI.L2-3.14.7, identify unauthorized use (3 points)	Identify use that falls outside the defined authorized baseline, such as unapproved remote services, new hosts, or administrative sessions from unexpected sources.	Create Sigma and NIDS rules for unauthorized protocols and new external destinations, and set threshold or suppress tuning with documented reasons. Route alerts from Security Onion to the ticketing and SOC workflow.	Alert triage records showing who reviewed each unauthorized use alert, the disposition, and the escalation path, along with rule change history.
Alert workflow and sensor health	Keep sensors running and alerts moving through triage so that monitoring evidence is complete and current.	Monitor sensor health and pipeline status, since search nodes stop indexing if the manager is unreachable. Plan redundancy for receiver nodes where alert loss would break the evidence trail.	Sensor health monitoring records, outage and recovery logs, and documentation of the retention period for alert and packet data.
Scope and boundary coverage	Confirm that every system in scope for CUI is covered by a monitoring point, and that the boundary itself is accurately described.	Map sensor interfaces to network segments and document any encrypted or unmonitored paths. Check that sensors are supported on x86-64 hardware that meets the published minimums for the chosen node role.	Network diagram with sensor locations, asset inventory cross-reference, and an exceptions register for any path that cannot be observed.
Assessment-ready evidence	Present final-form evidence that an assessor can test against the NIST SP 800-171A objectives.	Run and record tests of the detection and monitoring capability, such as controlled test traffic that should produce alerts. Keep these tests repeatable across assessment cycles.	Final versions of the monitoring strategy, test plans and results, and triage records. Drafts do not count toward a MET determination.

Which open source platforms fit a CMMC monitoring design

Distributed is the deployment type Security Onion recommends for production. It separates a manager node from one or more sensor nodes and one or more search nodes, so sensors can sit at the CUI boundary and at internal segment edges while analysts query a central console. This layout maps well to the monitoring locations an assessor will ask about under SI.L2-3.14.6 and SI.L2-3.14.7, because the sensor inventory and placement become a documented artifact.

Node roles: Manager, sensor and search nodes each have published minimum hardware, and the sensors need at least 2 NICs.
Platform support: Security Onion supports only x86-64 processors, and 3.x runs on Oracle Linux 9 only.
Manager dependency: If the manager goes down, search nodes stop indexing because they cannot reach Redis, so plan manager availability.
License: The repository is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved. Have counsel confirm it fits your use.
Version currency: Security Onion 2.4 reached end of life on October 1, 2026, so new builds should start on 3.x.

Confirm with the vendor which edition, support terms and upgrade path your enclave requires before you commit the design.

How detection rules and tuning produce defensible evidence

An assessor reviewing SI.L2-3.14.6 and SI.L2-3.14.7 will not accept a sensor that merely runs. The evidence has to show which rules were active, who changed them and why, what authorized use looks like, and how alerts were handled. The cards below cover the parts of a Security Onion deployment that produce that record.

Rule sources and update path

Security Onion Detections manages the NIDS rules loaded into Suricata, the Sigma rules loaded into ElastAlert and the YARA rules loaded into Strelka. Record which rule sources are enabled, who approved them and how often they are pulled. An assessor testing the monitoring capability will ask whether detection content is current, so keep a dated inventory of each rule set and its version. Confirm with your team which sources are permitted under your own policy before enabling them.

Suppression and threshold changes as records

Tuning is where monitoring quietly becomes blind. Every suppression, threshold change or modified NIDS rule should be a tracked change with a stated reason, an owner and a review date. Keep the before and after state so a reviewer can see that a noisy signature was adjusted, not disabled to hide activity. Tuning that cannot be explained in a change record is the first thing an assessor will question.

Baselining authorized use

SI.L2-3.14.7 requires you to define authorized use before you can identify unauthorized use. Document the expected protocols, hosts, external destinations and administrative paths for each enclave, then use Zeek logs and Suricata alerts to compare observed traffic against that baseline. Keep the baseline document under version control and review it on a set schedule, since an assessor will look for both the definition and the evidence that deviations were examined against it.

Airgap rule updates through soup

Enclaves without internet access cannot pull rules directly, so updates must cross the gap on approved media. Security Onion's airgap mode carries NIDS, YARA and Sigma rules in the ISO, and the soup tool applies updates from newer ISO media. Record each media transfer, its hash or provenance and the date it was applied. Confirm with the vendor how rule content is versioned between ISO releases before you write the procedure.

Retaining alert triage records

An alert that was seen but never triaged is a finding waiting to happen. Define the triage states your SOC uses, such as new, investigating, benign, escalated or closed, and retain the analyst's decision with timestamps for each alert. Keep these records with the rule and tuning history so one alert can be traced from the signature that fired to the disposition. Confirm your retention period against contract and internal policy, since the CMMC rule does not set one for these records.

What an assessor looks for in monitoring evidence

This table maps the evidence an assessor typically asks for under SI.L2-3.14.6 and SI.L2-3.14.7 to what each item proves and the component that produces it. Read it as a checklist: each row should exist, be current, and be in final form before the assessment, because a requirement is met only when all applicable objectives are satisfied with final evidence.

Evidence item	What it proves	Producing component	What must be in final form
Continuous monitoring strategy	The organization planned monitoring of inbound and outbound traffic and defined what counts as an attack indicator	Organization policy, reviewed alongside the Security Onion deployment design	Approved, dated and versioned document naming owners, monitored boundaries and review cadence
System monitoring tools and techniques documentation	Which sensors, rule engines and analysis tools are in use and how they are configured	Security Onion Console, Suricata, Zeek and the deployment architecture records	Current configuration baseline reflecting the deployed version, not a pre-upgrade draft
Sensor placement and network diagrams	Monitoring devices sit where inbound and outbound traffic crosses the boundary and internal zones	Network diagrams and sensor inventory maintained with the deployment	Diagrams matching the live network, with tap or span points and sensor locations labeled
Suricata and Zeek logs and alert records	Traffic was observed and alerts about attacks or indicators were generated and handled	Suricata alerts, Zeek logs and the Security Onion Console event records	Retained records covering the assessment period, with triage outcomes attached to alerts
Tests of IDS capability	The intrusion detection and monitoring capability detects what it is supposed to detect	Test traffic or known-signature exercises run against the sensors, recorded by the team	Dated test plan, results and remediation of any missed detections, signed off by the owner
Authorized use definitions	Authorized use of the system is defined, which is the baseline for identifying unauthorized use	Acceptable use policy and access role definitions, referenced in monitoring procedures	Approved policy that matches the roles configured in identity and monitoring systems
Unauthorized use investigations	Unauthorized use was identified, investigated and resolved against the defined authorized use	Security Onion alerts, case records and any linked EDR or identity logs	Closed case files with scope, timeline, findings and corrective action recorded
Rule change records	Detection rules were kept current and changes were reviewed and approved	Security Onion Detections interface change history and rule source records	Change tickets or approvals for each NIDS, Sigma or YARA rule change, with dates and reviewer

What a monitoring program must prove beyond installing sensors

A deployed sensor does not satisfy SI.L2-3.14.6 or SI.L2-3.14.7 on its own. Under NIST SP 800-171A, the assessor tests each objective separately: for 3.14.6, monitoring the system, its inbound traffic and its outbound traffic to detect attacks and indicators of potential attacks; for 3.14.7, defining authorized use and identifying unauthorized use. A requirement is MET only when every applicable objective is satisfied with evidence in final form, not drafts. Both requirements are worth more than 1 point under the CMMC Scoring Methodology, so neither can be placed on a POA&M. A Suricata or Zeek deployment without a documented monitoring scope, written authorized-use definitions, tests of the detection capability and records of review will leave the program unable to show that it met the objectives, even if the sensors are running.

The evidence an assessor looks for is mostly documentation and records. Expect to produce the continuous monitoring strategy, the documentation of system monitoring tools and techniques, and the locations where monitoring devices are deployed, along with audit records showing that alerts were generated, triaged and closed. For Security Onion, that means the sensor placement and the rule sets loaded into Suricata and Zeek, with a record of how the Detections interface was used to tune and suppress them. Tests of the intrusion detection capability should be scheduled and their results kept. Confirm with your assessor and your C3PAO how they expect these records to be packaged, and confirm that your monitoring scope matches the boundary defined for your CUI environment.

The distinction between a self-assessment and a certification assessment matters for timing, not for content. A Level 2 self-assessment is conducted against the NIST SP 800-171A objectives and results are posted to SPRS, while a Level 2 certification assessment is performed by a C3PAO authorized or accredited by The Cyber AB. On 13 July 2026 the Department of War suspended CMMC Phase II, which had included the Level 2 C3PAO certification requirement, and started a 60-day review. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Plan the monitoring program against the same 3.14.6 and 3.14.7 objectives either way, and check the current status on the DoW CIO About CMMC page before scheduling any third-party assessment.

What monitoring tooling alone does not satisfy

A sensor that sees every packet still fails SI.L2-3.14.6 and SI.L2-3.14.7 if nobody defined authorized use, reviewed the alerts or documented the boundary. Assessors score the people, procedures and records around the tooling as closely as the tooling itself, so the cards below cover the gaps that most often surface during evidence review.

Defined authorized use and baselines

SI.L2-3.14.7 has two assessment objectives: defining authorized use of the system, and identifying unauthorized use. Monitoring cannot identify unauthorized use until someone has written down what authorized use looks like, by user role, host and protocol. Check that the policy exists in final form, names the systems it covers, and is tied to baselines your Suricata and Zeek logs can actually be compared against.

Staffed review and triage process

Alerts from Security Onion only matter if a named role reviews them on a defined schedule and records the disposition. Ask whether coverage is 24-hour staffed, on-call, or business hours only, and who owns tuning when a rule floods the queue. Assessors will ask to see triage records for a sample period, so the process has to produce them as a routine output rather than an ad hoc effort.

CUI system scope and boundary

Sensors can only monitor traffic that crosses a point you placed them on. Document which systems process, store or transmit CUI, where the boundary sits, and which segments carry inbound and outbound communications across it. The location of each monitoring device is itself assessment evidence under SP 800-171A, so a diagram that matches the deployed taps and span ports is a precondition for a credible assessment.

Encryption and access for stored packet capture

Full packet capture can contain CUI, credentials and session content, so the capture store becomes a CUI-adjacent system with its own access and protection requirements. Ask how capture files are encrypted at rest, who can query them, how that access is logged, and how retention is enforced. Security Onion Pro lists LUKS data-at-rest encryption as a paid feature, so confirm whether your design depends on it or on your own disk encryption.

Licensing and support for ELv2 and Pro

Security Onion is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved, so legal review should confirm that your intended use, hosting and redistribution fit its terms. Security Onion Pro is sold on 1 to 5 year terms and adds OIDC single sign-on, FIPS mode and OS STIG compliance. Decide early whether the community edition meets your control set, and get the support path in writing before the assessment.

People and written procedures assessors interview

Assessors interview the people who run monitoring, not only the administrators who installed it. Staff should explain how they recognize an indicator of attack, what they do with an alert, and how unauthorized use gets escalated. Written procedures must be final, dated and consistent with what staff describe. Train at least two people per shift so the interview answers do not depend on one engineer.

How much work does CMMC monitoring take, and what do we need to provide?

What drives the cost of network monitoring for CMMC Level 2?

The main drivers are how many sensors you need, how fast the links they watch run, how much packet capture and metadata you keep, and how much analyst time goes into tuning alerts. Sensors and their hardware are a one-time purchase per site, while storage growth, rule updates, staff time and any support contract recur. Security Onion publishes minimum hardware for standalone, manager, search and sensor nodes, so sensor count and capacity planning follow directly from your boundary and traffic. Ask a partner for a quote that lists sensor hardware, storage sizing with retention assumptions, tuning hours, and whether Security Onion Pro is included. Security Onion Pro is a paid edition sold on 1 to 5 year terms, and you should confirm its current price with its vendor.

Where does CMMC monitoring stand after the Phase II suspension?

On 13 July 2026 the Department of War suspended CMMC Phase II and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so monitoring requirements in SI.L2-3.14.6 and SI.L2-3.14.7 still apply to contracts that carry them. Because the official schedule is in flux, confirm with your contracting officer and the DoW CIO's CMMC pages which assessment type applies to you and when. Plan the monitoring work against the controls, since they do not change with the schedule.

Can a small security team run Security Onion monitoring alone?

A small team can run it, but the work is mostly tuning and daily review rather than installation. Security Onion's Distributed design, with a manager, sensors and search nodes, is the recommended production layout, and it adds components that need patching, backups and capacity checks. Expect ongoing work on rule sets, suppression of noisy alerts, and documenting who reviews alerts and how often. If your team has no Linux or Suricata experience, consider a partner for the first build and knowledge transfer, then decide whether a retainer for upgrades and continuous support fits your staffing. DeployOpen offers ongoing support as retainers.

What should we give a partner before scoping a CMMC monitoring project?

Prepare the inputs a partner needs to size and place sensors correctly:

Current network diagrams, including IT segments, enclaves and any links to cloud or remote sites
A CUI scope statement that names the systems that store, process or transmit CUI
A boundary list of in-scope and out-of-scope systems, with owners
Link speeds, switch and firewall models, and where mirror ports or taps are possible
Existing logging, SIEM and ticketing tools, and who will review alerts
Your retention needs for metadata and any packet capture, and whether sensors must run without internet access

A partner can use these to write a fixed scope with deliverables before work starts.

Does Level 2 CMMC always require a C3PAO assessment?

Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and Level 2 self-assessments are also possible under the rule. Which path applies depends on the contract and on the current implementation status, which is paused and under review. The CMMC rule specifies that requirements are MET only when assessment objectives are satisfied with final evidence, so the same monitoring evidence supports either path. Check the DoW CIO's About CMMC page and your contract language to confirm which assessment you will need.

Does DeployOpen issue CMMC certifications or attestations?

No. DeployOpen plans, implements, hardens and documents monitoring systems and prepares the controls and evidence for a compliance assessment, but it does not issue certifications, attestations or audit reports. Those come from an independent assessor, such as a C3PAO for Level 2 certification. DeployOpen's work is fixed-scope, with scope and deliverables agreed in writing before work starts, and a quote follows from that written scope rather than a published price list.

What ongoing effort should we budget after the monitoring stack goes live?

Budget for recurring work in four areas: software updates for the platform, rule and detection tuning, storage growth from retained metadata and packet capture, and periodic evidence collection for assessments. Security Onion's end-of-life dates mean a version upgrade is a planned project, so confirm the support window of the release you deploy. Ask any partner to state which of these are covered by a retainer and which are billed as separate work. Analyst time is usually the largest recurring cost, so agree on alert review cadence and escalation paths before handover.

How a monitoring deployment moves from scoping to assessor-ready evidence

The sequence runs from defining the CUI boundary to a set of final-form records that show SI.L2-3.14.6 and SI.L2-3.14.7 are operating, not just installed. Each step produces an artifact that the next step depends on, so gaps surface before an assessment rather than during it.

Scope the CUI boundary and assets
The organization, with its CMMC advisor or implementation partner, first lists which systems store, process or transmit CUI and which enclaves connect to them. It then maps the network paths, cloud accounts and remote access routes that cross the boundary. The step is done when the boundary diagram and asset inventory are approved by the system owner, because every later sensor decision traces back to them. Ask the partner to show how the boundary changes when a new subcontractor or cloud service enters the scope.
Select tap and span points
Engineers choose where sensors see inbound and outbound traffic at the CUI boundary and at critical internal points, using switch span ports, network taps or both. They document each chosen point, the traffic it covers and any blind spots, such as east-west flows that never cross the boundary. The output is a placement register that an assessor can compare against the locations where monitoring devices are deployed. Confirm that the placement covers both inbound and outbound directions, since SI.L2-3.14.6 names both.
Size sensors and search nodes
Using the Security Onion hardware minimums for standalone, manager, search and sensor nodes as a floor, the team sizes each node against measured traffic, link speed and the retention period the organization sets. Security Onion supports only x86-64 processors, so hardware selection is checked against that limit first. The step closes with a sizing worksheet signed off by the engineer and the security lead. Ask the partner to show how they test for packet loss at peak load before the sizing is accepted.
Deploy and tune detection rules
The team installs the Distributed deployment with manager, sensor and search nodes, connects the sensors to the chosen taps, and loads Suricata NIDS rules along with Sigma and YARA content. They then tune rules, suppressing known benign traffic and setting thresholds, with each change recorded with a reason. The step is complete when sensors report to the console, alerts reach the analysts, and the rule change log shows who approved each change. Confirm how air-gapped rule updates are handled if the enclave has no internet access.
Write the monitoring strategy and procedures
The organization writes a continuous monitoring strategy that names the monitored boundaries, the tools and techniques used, the alert review process and the people responsible for each task. Procedures cover how analysts identify unauthorized use, including the definition of authorized use for the system, which SP 800-171A treats as its own assessment objective for SI.L2-3.14.7. The step is done when the documents are approved and version-controlled. Assessors read these documents against the running system, so inconsistencies between the written process and the console are common findings to avoid.
Run and record detection tests
Testers generate controlled attack and indicator traffic across the monitored boundary and confirm that Suricata alerts appear in the console and reach the responsible analyst. They also test whether unauthorized use is identified, for example by checking that logins from outside defined authorized patterns are flagged. Each test records the date, the scenario, the expected result, the actual result and the analyst action. The step is done when the records show detection working as the strategy describes, and gaps are either fixed or formally documented.
Assemble final-form evidence for the assessor
The team collects the boundary diagram, placement register, sizing worksheet, rule change log, strategy, procedures, test records and audit records into one evidence set, with each document in final form rather than as a draft. A cross-reference maps each evidence item to the SI.L2-3.14.6 and SI.L2-3.14.7 objectives it supports. The step is complete when an internal reviewer can trace each objective to evidence without asking the engineers. Requirements are MET only when all applicable objectives have evidence in final form, so the reviewer checks dates and approvals before the package goes to the assessor.

How DeployOpen scopes, deploys and documents CMMC monitoring

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source monitoring inside the client's own infrastructure, including enclaves that handle CUI. For CMMC Level 2 work, the engagement is built around the evidence an assessor will later ask to see, from sensor placement records to alert handling history.

How we scope

Engagements are fixed-scope, with the monitored boundary, sensor locations and in-scope systems agreed in writing before work starts.
The written scope names which assessment objectives for SI.L2-3.14.6 and SI.L2-3.14.7 the deliverables are meant to support.
Scope records the authorized-use definition and the inbound and outbound traffic paths that the monitoring must cover.

How we build

Sensors such as Suricata and Zeek are deployed in the agreed locations, with rule sources, tuning and alert routing configured and tested.
Monitoring coverage is tested against the agreed scope, including detection tests of intrusion detection and system monitoring capability.
Air-gapped or segmented enclaves are configured with update and rule-transfer procedures that the client can repeat.

How we hand over

Deliverables include the monitoring strategy, tool documentation, sensor deployment locations and audit record configuration.
Runbooks cover alert triage, unauthorized-use investigation and escalation, so the client's staff can operate the stack after handover.
Evidence is delivered in final form, since assessors accept only final evidence, not drafts. DeployOpen prepares evidence but does not issue assessment results.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover platform upgrades, such as Security Onion version changes, with the change record kept for later assessment.
Periodic detection testing can confirm that monitoring still catches the attack scenarios documented in the original scope.

Network security monitoring for CMMC level 2