This post explains how to implement continuous threat hunting focused on inbound and outbound network communications to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requirement SI.L2-3.14.6, translating the control into concrete telemetry, tooling, and repeatable hunting practices suitable for small- and medium-sized organizations handling Controlled Unclassified Information (CUI).
What the control requires and key objectives
SI.L2-3.14.6 expects organizations to actively hunt for malicious activity in network traffic — not just rely on alerts — with an emphasis on detecting anomalous ingress/egress, command-and-control, and data exfiltration attempts. Key objectives are (1) continuous visibility of inbound and outbound flows, (2) proactive hypothesis-driven investigations, (3) documented hunts and artifacts for audit, and (4) rapid escalation and containment when suspicious activity is found.
Practical implementation steps (compliance-focused)
Inventory your telemetry sources
Start by cataloging the sources you'll use for hunts: perimeter firewall logs, web proxy logs, DNS query logs, email gateway logs, cloud VPC flow logs (AWS/VPC Flow, Azure NSG flow), NetFlow/sFlow/IPFIX from routers, NDR sensors (Zeek/Bro, Suricata), packet capture (PCAP) at key choke points, and host telemetry from EDR/XDR. Map each source to which type of behavior it can reveal (e.g., DNS -> DGA and tunneling; NetFlow -> unusual volume/external endpoints; EDR -> process-to-network correlations). For CMMC evidence, record the log sources and the log forwarding configuration in your System Security Plan (SSP).
Tooling and architecture choices
Small businesses can mix managed services and open-source tools to achieve continuous coverage: a SIEM (Splunk/Elastic/LogRhythm) or cloud-native logging (Elastic Cloud, Sumo Logic, Azure Sentinel) for aggregation; Zeek + Suricata or Security Onion for network detection and PCAP; and EDR (CrowdStrike, Microsoft Defender for Business) for host context. Technical specs: enable NetFlow v9 or IPFIX on perimeter routers, retain flow-level records for at least 90 days (extend if contractually required), keep PCAP ring buffers for 7–30 days indexed by timestamp, and ensure NTP time sync across devices for correlation. If budget is tight, use managed detection and response (MDR) with agreed SLAs that include custom hunts and evidence packaging for audits.
Hunting methodology and detection engineering
Adopt hypothesis-driven hunts mapped to MITRE ATT&CK tactics (e.g., Exfiltration, Command and Control). Example hypotheses: "A workstation that suddenly transfers >500MB to a single external IP over HTTPS outside business hours" or "Multiple hosts resolving a newly registered domain with low TTLs and then making repeated small GETs (possible DNS/data tunneling)". Build queries that aggregate per-host egress volume, count distinct external destinations, detect repeated short DNS TXT responses, and flag unusual TLS JA3/JA3S fingerprints. Example detection queries: an Elastic/KQL query to group egress bytes by src_ip and dst_ip and alert on outliers, or a Splunk query that looks for >3× baseline outbound connections to previously unseen /24 prefixes. Correlate network anomalies with EDR process metadata to reduce false positives.
Real-world small-business scenario
Scenario: a 120-person engineering firm with CUI uses cloud-hosted services and a single remote office. Practical approach: enable VPC Flow Logs in AWS and send to Elastic Cloud; activate DNS logging on the corporate DNS server and cloud DNS; deploy a Zeek sensor on the internet gateway VM to extract HTTP host headers, TLS SNI, JA3 fingerprints, and DNS behaviors; forward logs to a managed SIEM; run weekly hunts that check for top-talkers, new external endpoints, and spikes in DNS NXDOMAIN or TXT responses. If a suspicious host is found, use EDR to isolate the endpoint and pull a forensic snapshot. Document each hunt with hypothesis, query, evidence (screenshots, query outputs), actions taken, and lessons learned for the SSP and POA&M.
Technical example snippets
Small but actionable examples: a Suricata rule to alert on large DNS TXT responses that may be exfiltration: alert dns any any -> any any (msg:"Possible DNS TXT Exfiltration - large TXT response"; dns.query; dns.txt_len:>200; sid:1000001; rev:1;). An Elastic query to find unusual egress volume in the last 24 hours: index:flow* | bucket by src_ip | sum(bytes_out) | where sum_bytes_out > (avg_bytes_out * 5). Capture JA3 fingerprints in Zeek and create a table of JA3->dst_ip to spot rare TLS client fingerprints connecting to many external IPs. Tune thresholds over time to reduce noise.
Retention, evidence handling, and incident response
Retention and evidence rules matter for compliance: store flow logs for at least 90 days as a baseline; consider 1 year for systems processing CUI if contracts require it. Keep PCAP for the minimal forensic window (7–30 days) and move relevant PCAP to cold storage if an incident justifies it. Ensure logs are write-once/read-many (WORM) where possible, use secure log forwarding with TLS, and maintain chain-of-custody notes for any artifacts pulled during hunts. Integrate hunting outputs into incident response playbooks: if a hunt escalates to confirmed exfiltration, steps should include network isolation, forensic snapshot via EDR, notification to leadership, and updates to SSP and POA&M.
Compliance tips and best practices
Document hunts and map each activity to SI.L2-3.14.6 in your SSP: include hunting cadence (daily/weekly), personnel roles, tools, sources, and examples of hunt logs. Keep a living IOC/TTP repository (MISP or even a simple internal spreadsheet) and automate enrichment with threat intel (TAXII/STIX) to reduce manual work. Run quarterly tabletop exercises that include a simulated egress incident. If you use TLS inspection, balance privacy and legal considerations; document decisions and implement exclusions for personal traffic where required. Finally, treat hunting as a continuous improvement process: tune detection rules, close POA&M items, and preserve evidence for potential audit reviews.
Risks of not implementing continuous hunting
Without proactive and continuous threat hunting on inbound/outbound traffic, organizations increase the risk of undetected data exfiltration, persistent C2 infrastructure remaining in place, and delayed incident detection that magnifies damage. For CUI-holders, failure to implement this control can lead to audit findings, contract penalties, loss of DoD work, and reputational harm—plus longer containment and higher forensic costs after an incident.
In summary, meeting SI.L2-3.14.6 requires a blend of mapped telemetry, repeatable hunting methodology, pragmatic tooling choices, and documentation that feeds your SSP and POA&M. Start by inventorying telemetry, deploying affordable sensors or an MDR, and running hypothesis-driven hunts that correlate network flows with host context—document everything so hunters, auditors, and decision-makers can demonstrate continuous oversight over inbound and outbound communications.
