---
# System prepended metadata

title: Introduction to Network Security Monitoring
tags: [Learning BlueTeam2026]

---

# Introduction to Network Security Monitoring

## 1. Definition

**Network Security Monitoring (NSM)** is the continuous collection and analysis of network artifacts (packets, flows, and logs) to detect, investigate, and respond to security threats. NSM provides visibility into *who communicates with whom, when, by which protocol, and how much data is transferred*.

## 2. Three Primary Data Types

* **Packets (PCAP):** Full packet payloads used for deep forensics and traffic replay.
* **Flows:** Network metadata (5-tuple, byte counts, durations) suitable for large-scale threat hunting.
* **Logs / Metadata (DNS, HTTP, TLS):** Enable rapid pivoting based on indicators and support contextual enrichment.

## 3. Zeek

Zeek transforms raw packets into structured, analysis-ready logs, making it well suited for building detection pipelines and enrichment workflows. Three commonly used core logs include:

* **conn.log:** Who communicated with whom, when, over which protocol, and how many bytes were transferred.
* **dns.log:** DNS queries, useful for detecting DGA activity, DNS tunneling, and command-and-control (C2).
* **http.log:** Detailed HTTP request/response information, supporting detection of malware downloads, web shells, and data exfiltration.

In addition, Zeek supports analysis of more than 50 protocols, file extraction, custom scripting, and integration with threat intelligence sources.

## 4. Beaconing Attacks

* **Nature:** Malware or backdoors periodically send signals to a C2 server to receive commands or exfiltrate data.
* **Common Indicators:** Regular communication intervals, similar packet sizes, and unusual or suspicious destinations.
* **Detection:** Frequency and timing analysis using `conn.log` and `dns.log`, combined with heuristics or machine-learning techniques to reduce false positives.

## 5. Limitations of Network Evidence

* Network data does not reveal the **process** or **user** that initiated a connection (endpoint telemetry such as EDR is required).
* Encrypted payloads (TLS) significantly limit content inspection.
* Network evidence lacks sufficient context on its own and must be correlated with endpoint data, logs, and threat intelligence to reach reliable conclusions.

## 6. NSM Workflow

1. Capture
2. Parse (Zeek generates logs)
3. Enrich (threat intelligence)
4. Detect (rules / heuristics / ML)
5. Alert
6. Investigate (logs + PCAP)
7. Respond
8. Update detections

## Rule Improvements

### SOC-201: Potential Beaconing Activity Detected

* **Parent Process Check:** Trigger an alert immediately if `svchost.exe` is not spawned by `services.exe`.
* **Command-Line Check:** Trigger an alert if `svchost.exe` runs without the `-k` parameter (`-k netsvcs`).
* **Threat Intelligence Integration:** Automatically correlate destination IPs with blacklist and intelligence feeds as soon as a connection is observed.

### SOC-202: DNS TOR Proxies Detected

* **Matching Logic Fix:** Change from substring matching (contains `"onion"`) to suffix matching (ends with `".onion"`), ensuring the `.onion` domain appears strictly at the end.
* **Exclude Valid IP Resolutions:** The rule should ignore cases where the DNS query resolves to a valid public IP address (A record). Legitimate `.onion` domains do not resolve to public IPs via standard DNS servers.
