Network Defense, Part 6: Security Monitoring Data, Logs and Alerts

The last part of the Network Defense course was the closest yet to actual SOC work: which protocols and technologies make monitoring harder, what kinds of security data exist, where logs come from, and how alerts are generated and evaluated. This section made it clear what I’ll be doing day to day as an analyst.

Monitoring common protocols

Attackers abuse the same everyday protocols that networks depend on, so analysts need to know what normal and abnormal look like for each one.

• Syslog and NTP: syslog carries log messages, usually over UDP 514 without encryption, so logs can be intercepted or faked. NTP keeps clocks in sync. Attackers may try to change the time on systems to mess up the order of events in logs, and NTP servers can be abused for amplification attacks.
• DNS: used by almost every connection, and allowed through almost every firewall. Attackers use it for DNS tunneling (hiding data in queries), to reach command servers using domain generation algorithms, and for exfiltration.
• HTTP and HTTPS: HTTP is plain text, so it can be inspected. Attackers use it for things like malicious iFrames and redirects. HTTPS is encrypted, which protects users but also hides malicious traffic from security tools unless it’s decrypted.
• Email protocols: SMTP (port 25) sends mail, and POP3 (110) and IMAP (143) fetch it. Email is the top way malware arrives, and it can also be used to send stolen data out.
• ICMP: used for ping and error messages, but also for scanning (ping sweeps), DoS, and even ICMP tunneling, hiding data inside ICMP packets.

Security technologies that affect monitoring

Some technologies are good for security in one way but make monitoring harder in another.

• ACLs block traffic, but they can give a false sense of safety. Attackers can get around simple ACLs, for example with spoofed addresses or by using allowed ports.
• Mitigating ICMP abuse: blocking unneeded ICMP at the edge stops scans and tunnels, but needs care so normal functions still work.
• NAT and PAT: NAT translates private addresses to public ones, and PAT lets many devices share one public IP using different ports. This hides internal addresses, which is good, but it also means logs at the edge only show one public IP. To find which internal machine did something, you need the NAT translation logs too.
• Encryption, encapsulation and tunneling: VPNs and encrypted traffic hide the content of packets. Analysts can see that two hosts talked, but not what they said. Attackers also use tunnels to sneak traffic past controls.
• Peer-to-peer networking and Tor: P2P apps share files directly between users, which can spread malware and leak data. Tor routes traffic through several encrypted relays to hide where it came from and where it’s going. Tor traffic from inside a company network is usually a red flag.
• Load balancing: spreads traffic across several servers behind one address. It’s great for availability, but it can make it harder to tell which actual server handled a suspicious request.

Types of security data

The course described four main types of data analysts work with:

• Alert data: messages generated by IDS/IPS and other tools when traffic matches a rule. For example, a Snort alert for a known exploit.
• Session and transaction data: records of conversations between hosts: source and destination IPs and ports, protocol, start and end times, and bytes sent. Zeek’s connection logs and NetFlow are examples. It shows who talked to whom without the full content.
• Full packet captures: every packet, including its contents. This is the most detailed data, and lets you see exactly what was sent, but it takes a lot of storage.
• Statistical data: summaries of normal network behavior, like average traffic levels, top talkers and protocol mix. Used to build a baseline so unusual activity stands out.

End device logs

Host logs

Host logs come from the endpoints themselves. On Windows, that’s the Event Logs, especially the Security log with events like logons, failed logons and new processes. Host-based tools like HIDS and EDR add more detail.

Syslog

Syslog is the standard way network devices and Linux systems send logs. Each message carries:

• Facility: which part of the system created the message. Examples: 0 is the kernel, 1 is user processes, 4 is security/authentication, and 16–23 (local0–local7) are free for custom use, like network devices.
• Severity: how serious it is, from 0 (emergency) to 7 (debug).
• Priority: a single number combining both, calculated as facility × 8 + severity.

For example, a message with priority 34 means facility 4 (authentication) and severity 2 (critical), because 4 × 8 + 2 = 34. In the raw message it appears at the start as <34>.

Server logs

Servers keep their own logs. A web server’s access log records each request: the client IP, time, the page requested, the response code and size. For example:

203.0.113.45 - - [06/Nov/2026:14:22:10 +0500] "GET /login.php?id=1' OR '1'='1 HTTP/1.1" 200 512

That request clearly contains an SQL injection attempt. DNS server logs, mail server logs and authentication logs are other important server logs.

SIEM and log collection

A SIEM (Security Information and Event Management) collects logs from all these sources into one place. Its main jobs are:

• aggregation: gathering logs from many systems
• normalization: putting them into a common format so they can be compared
• correlation: connecting related events across different sources, like a failed VPN login followed by a successful one from a different country
• alerting and reporting: raising alerts and producing reports, including for compliance

Without a SIEM, an analyst would have to log into dozens of systems to piece together one incident.

Network logs

The course listed the main sources of network data:

• tcpdump and libpcap: tcpdump is a command-line packet capture tool, and libpcap is the library it uses to capture packets. Wireshark and many other tools use libpcap too.

  sudo tcpdump -i eth0 port 53 -w dns.pcap
  

  This captures DNS traffic on eth0 and saves it to a file for analysis.

• NetFlow: flow records showing who talked to whom, when and how much, without the content.
• Application Visibility and Control (AVC): a Cisco feature that identifies which applications are being used on the network (even on non-standard ports) and lets you control them.
• Content filter logs: from email and web security appliances (like Cisco ESA and WSA), showing blocked spam, malware and websites.
• Logs from Cisco devices: routers, switches and firewalls send syslog messages in the format %FACILITY-SEVERITY-MNEMONIC: description, for example %SEC-6-IPACCESSLOGP for an ACL hit.
• Proxy logs: web proxies record every website users visit, which is very useful for spotting malicious sites and data leaks.
• Next-generation firewall logs: NGFWs log connections, application use, intrusion events and malware detections.

The course also had a Packet Tracer activity on logging from multiple sources, sending syslog from several devices to one server and seeing how combining them gives a fuller picture.

Sources of alerts: Security Onion

Security Onion is a free Linux distribution built for network security monitoring. It bundles many tools together.

Its architecture has three parts:

• sensors that capture traffic and generate data and alerts
• a server that collects and stores everything
• analyst tools used to review and investigate

The tools in my notes:

• CapME: a web tool for viewing the transcript of a captured session (used in older versions of Security Onion)
• Snort: a rule-based network IDS that generates alerts
• Zeek (formerly Bro): records detailed logs of network activity like connections, DNS, HTTP and files
• OSSEC: a host-based IDS that watches logs, files and system changes on endpoints
• Wazuh: a newer host-based IDS and security platform that grew out of OSSEC
• Suricata: another network IDS, similar to Snort but able to use multiple CPU cores, so it handles more traffic

Analysis tools and alert generation

Analysts review this data with tools like Kibana dashboards (part of the Elastic Stack), and pivot to packet captures in Wireshark when they need full detail.

Alerts are generated from several places:

• NIDS (network IDS) like Snort and Suricata, matching traffic against rules
• HIDS like OSSEC and Wazuh, watching endpoints
• asset management and monitoring, noticing new or unexpected devices on the network
• HTTPS, DNS and TCP transaction records from Zeek, which can trigger alerts when something unusual appears
• syslog messages from devices, like repeated failed logins

Snort rule structure

A Snort rule has two parts: the header and the options.

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"Possible SSH brute force"; flags:S; threshold:type both, track by_src, count 5, seconds 60; sid:1000001; rev:1;)

The header (everything before the brackets):

• alert: the action (others include log, pass and drop)
• tcp: the protocol
• $EXTERNAL_NET any: source addresses and port (outside the network, any port)
• ->: the direction
• $HOME_NET 22: destination addresses and port (inside the network, SSH)

The options (inside the brackets):

• msg: the text shown in the alert
• flags:S: only match SYN packets (new connection attempts)
• threshold: only alert if the same source does this 5 times in 60 seconds
• sid: a unique ID for the rule (custom rules usually start at 1000000)
• rev: the rule’s version number

Other common options include content, which looks for specific text in the packet, and classtype, which categorizes the alert.

Alert evaluation

Why alerts need evaluating

Security tools produce a huge number of alerts, and many aren’t real attacks. If analysts treated every alert as real, they’d be overwhelmed. If they ignored them, they’d miss real attacks. Each alert has to be checked and classified.

Evaluating alerts

Every alert falls into one of four outcomes:

• True positive: an alert fired, and it really was an attack. The right result.
• False positive: an alert fired, but it was normal activity. Wastes time, and too many cause “alert fatigue.”
• True negative: no alert, and nothing bad happened. The right result.
• False negative: no alert, but an attack really happened. The most dangerous outcome, because nobody knows.

Tuning rules is about reducing false positives without creating false negatives.

Deterministic vs probabilistic analysis

• Deterministic analysis works when every step of an attack is known and follows fixed rules. For example, a known exploit always uses a specific port and a specific payload, so you can say with certainty whether it happened.
• Probabilistic analysis is used when things are less certain, like when an application uses random ports or the attack doesn’t follow a fixed pattern. The analyst uses statistics and judgment to estimate how likely it is that something malicious happened.

Real analysis usually mixes both: deterministic for clear signatures, probabilistic for everything else.

Why this matters for a SOC engineer

This whole section is the SOC’s daily work. Writing and tuning Snort or Suricata rules, getting syslog and Zeek data into a SIEM, understanding how NAT hides the real source of traffic, and sorting alerts into true and false positives are things I’ll actually be doing. Security Onion, Wazuh and Suricata are all free, so I can set them up in my home lab to practice.

Wrapping up Network Defense

That finishes Cisco’s Network Defense course. Over these posts it covered asset management, defense in depth and hardening, access control and AAA, ACLs, firewalls and ZPF, cloud security, cryptography, and finally security monitoring and alerts. Next is Cyber Threat Management, the last course in the Junior Cybersecurity Analyst path.

Questions I should be able to answer

• How can DNS, ICMP and HTTPS be abused by attackers?
• How do NAT, encryption and Tor make monitoring harder?
• What are the four types of security data?
• How is a syslog priority calculated? What does <34> mean?
• What are the main jobs of a SIEM?
• What do Snort, Zeek, OSSEC, Wazuh and Suricata each do?
• What are the parts of a Snort rule?
• True positive, false positive, true negative, false negative: which is the most dangerous, and why?
• Deterministic vs probabilistic analysis?