This post gives small-business IT and security teams a practical, tool-focused blueprint for implementing the communication monitoring and control expectations of FAR 52.204-21 and CMMC 2.0 Level 1 (SC.L1-B.1.X) within the context of the Compliance Framework: inventory your communications, detect suspicious traffic, restrict unauthorized flows, and retain evidence of controls and alerts.
High-level architecture and open-source tool choices
For Compliance Framework practice SC.L1-B.1.X you should aim for a simple, resilient architecture: network sensors to observe traffic (Zeek and Suricata), an edge firewall for enforcement (pfSense or OPNsense), host-based monitoring for endpoints (Wazuh or OSQuery), and a central log/alert store (Elastic Stack, Grafana Loki + Promtail, or SecurityOnion as an integrated appliance). For small businesses (10–50 users) a recommended stack is: pfSense at the internet edge, a mirrored/tapped port with Suricata (IDS/IPS) and Zeek (network telemetry), Wazuh agents on endpoints, and Filebeat/Logstash feeding Elasticsearch + Kibana for search and alerting. SecurityOnion is a good prebuilt option when you want quicker deployment of these components.
Step-by-step implementation plan
Start with these steps mapped to the Compliance Framework practice: 1) Inventory communications endpoints and services (email, VPN, SaaS apps, dev hosts). 2) Define permitted flows (which hosts can reach what destinations on which ports). 3) Deploy passive sensors (Zeek + Suricata) on a network TAP or SPAN and forward logs to a central collector. 4) Enforce at the edge with pfSense rules and inline Suricata if you need blocking. 5) Install Wazuh agents on endpoints for process/network events. 6) Tune signatures and alerts for false positives, and document tuning decisions as compliance evidence. Each step should produce artefacts (flow lists, firewall rule-set exports, sensor logs, tuning notes) for audits under FAR/CMMC.
Practical deployment notes: place Zeek on a mirrored port to generate detailed DNS/HTTP/SSL metadata, use Suricata in IDS mode initially to measure hit-rate before switching to IPS (inline) mode, and configure Filebeat on sensors to ship logs over TLS to Elasticsearch. Example Suricata alert-to-block lifecycle: run Suricata IDS, observe a rule that reliably identifies exfiltration patterns, then enable that rule inline on a test schedule during low-impact windows. Use pfSense firewall aliases for grouping DoD endpoints and restrict outbound traffic to only allowed destinations and ports (e.g., SSH to approved management jumpboxes only).
Include concrete config snippets in your runbook. Example Suricata rule to alert on large DNS response sizes which can indicate DNS tunneling:
alert dns any any -> any any (msg:"Large DNS response - possible tunnel"; dns.query; byte_test:4,>,5120,0; sid:1000001; rev:1;)Example nftables rule to drop outgoing traffic to a blacklisted IP list (replace
nft add table inet filter; nft add set inet filter blacklist { type ipv4_addr\; flags interval\; } ; nft add rule inet filter output ip daddr @blacklist drop And an example Zeek policy snippet to log suspicious HTTP POST sizes: @load policy/frameworks/notice; event http_request(c: connection, method: string, original_URI: string, unescaped_URI: string, version: string) &{ if ( c$http$body_len > 1MB ) { NOTICE([$note=Notice::SUSPICIOUS, $msg="Large HTTP POST", $conn=c]); } }</p>
Host-based visibility and control are as important as network: deploy Wazuh (fork of OSSEC) to collect syslog, Windows Security Event logs, and Linux auditd events. Use OSQuery or Fleet to run scheduled queries for unusual outbound processes (e.g., unknown process spawning curl/wget/tcp connections). For small shops, a lightweight approach is: deploy Wazuh agents, configure central rules to alert on new external connections by non-admin processes, and set up a weekly OSQuery query that lists all processes with network sockets open. Example OSQuery SQL:
SELECT p.name, l.address, l.port FROM processes p JOIN listening_ports l ON p.pid = l.pid WHERE l.address NOT LIKE '10.%' AND p.name NOT IN ('sshd','nginx','systemd');
Alerting, playbooks, and evidence capture: centralize alerts in Kibana/Grafana and connect to a simple incident playbook (TheHive + Cortex or email/Slack notifications). For compliance, record the alert, the investigative steps, the conclusion, and any rule changes in a ticket system. Build minimal automated containment options: for example, a script that uses the pfSense API to add a temporary deny rule for an IP flagged for data exfiltration, or a Wazuh active response script that kills a malicious process and quarantines the host. Retain logs for the retention period your Compliance Framework requires—FAR/CMMC commonly expects evidence for an audit window (document your retention policy and storage encryption settings).
Risks of not implementing SC.L1-B.1.X controls: lack of monitoring and controls increases the likelihood of sensitive unclassified Controlled Unclassified Information (CUI) being exfiltrated, unnoticed lateral movement by attackers, and failure in an audit. For a small DoD contractor, this can lead to contract termination, removal from future bids, fines, and reputational damage. From a technical viewpoint, absence of network and host telemetry means incidents are detected much later, increasing time-to-contain and cost of response.
Summary: implement a minimal, auditable stack using open-source building blocks—pfSense for enforcement, Zeek + Suricata for network visibility, Wazuh/OSQuery for host telemetry, and Elasticsearch/Grafana for aggregation. Start with inventory and policy, deploy sensors in passive mode, tune rules and false positives, then add enforcement with documented change control. Keep playbooks and evidence retention aligned to the Compliance Framework requirements so your controls meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.X while remaining operationally manageable for a small business.
