Zeek Notice Log is the alert-style output stream produced by Zeek when it detects a policy event or notable activity on a network. It records security-relevant observations such as scans, suspicious protocols, or policy violations, and is typically used alongside other Zeek logs for monitoring and incident triage.
What the Zeek Notice Log captures
The Zeek Notice Log is the alerting layer of Zeek’s telemetry, turning notable network events into a structured stream that analysts can triage quickly. It is less about raw traffic volume than about policy-relevant observations that deserve attention.
Because the log is event-driven, it helps distinguish ordinary protocol visibility from conditions that merit investigation, such as scans, protocol anomalies, or policy violations. That makes it useful as a high-signal starting point rather than a complete incident record.
How it fits into network monitoring and triage
The Notice Log normally sits alongside Zeek’s protocol and flow logs, where those other records provide context for what happened before, during, and after a notable event. In practice, teams use it to bridge detection logic and human review, especially when an alert needs corroboration from Zeek Network Monitoring Guide content or broader sensor data.
That role makes it useful in network detection and response workflows, where the first question is often not “did anything happen?” but “is this event meaningful enough to escalate?” Zeek’s notice framework helps answer that by converting scripted policy logic into observable records.
What the notices usually mean
Notices are best understood as structured signals about suspicious or policy-relevant network behaviour, not as proof of compromise on their own. A notice may indicate benign but unusual activity, a configuration issue, or an adversary technique that needs further validation through surrounding logs and packet evidence.
Common examples include port scans, unexpected protocol use, failed policy checks, or activity that resembles command-and-control or tunnelling patterns. When combined with flow and protocol metadata, those notices can support network hunting and incident scoping with much less noise than raw packet review alone.
Why analysts rely on it during investigation
The practical value of the Notice Log is speed and prioritisation. It helps analysts focus on events Zeek has already judged worth recording, which can shorten triage time and provide a repeatable paper trail for why a network event was elevated.
It is also useful for correlating with other telemetry sources, including full packet capture and external detection platforms. The strongest investigations usually treat a notice as a lead, then validate intent, scope, and impact across related logs rather than assuming the notice itself tells the whole story.
Risk and Threat Considerations
Because the Notice Log is designed to surface unusual or policy-significant behaviour, its main risk is not false alarms alone, but missed or misunderstood signals. If notice generation is poorly tuned, too sparse, or not reviewed in context, scanning, beaconing, protocol abuse, or other hostile activity can blend into routine traffic.
Failure mechanism: Weak notice rules, noisy environments, or incomplete log correlation can hide adversary activity behind either alert fatigue or under-collection, leaving analysts with an incomplete view of network behaviour.
Impact: Detection gaps can delay incident response, reduce confidence in triage, and allow reconnaissance or lateral activity to continue longer than it should.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1595 — Active Scanning | Zeek notices often surface scanning and recon activity on networks. |
| T1071 — Application Layer Protocol | Zeek notices can flag suspicious protocol use and command-and-control over application protocols. | |
| T1048 — Exfiltration Over Alternative Protocol | Notice logs can surface unusual alternative-protocol activity that may support exfiltration detection. | |
| Recommendation — Map scan notices to T1595 and validate whether the source is probing exposed services. Correlate protocol notices with T1071 sub-techniques and hunt for anomalous C2 patterns. Investigate protocol notices for T1048 patterns and confirm whether traffic is carrying unauthorized data out. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | The Notice Log is a monitoring signal used to detect suspicious network events. |
| DE.AE-02 — Anomalous Activity Is Detected and Analyzed | Notices are the kind of anomalous network observations this control expects organizations to analyze. | |
| Recommendation — Use DE.CM-01 to review notice coverage for unauthorized or unusual network activity. Use DE.AE-02 to triage notable events and determine whether the anomaly is benign or hostile. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Zeek notices are part of network monitoring and alert triage workflows. |
| Recommendation — Apply CIS-13 to centralize notice review and correlate alerts with other network telemetry. | ||
Practitioner Guidance
What to watch for: Treat the Notice Log as a signal stream that needs context, not a standalone verdict. The most useful operational habit is to pair notices with protocol logs, flow records, and packet evidence so each alert can be validated or dismissed with evidence.
Governance implication: Teams should own notice logic, review thresholds, and escalation paths explicitly, because a notice that is never tuned or routinely checked becomes a reporting artifact rather than a detection control. Linking the log to a broader monitoring strategy, such as NDR Guide and Network Forensics Guide practices, keeps it operationally useful.