SOC Analysis & Monitoring

CyBOK Knowledge Area 8.2–8.3 · Level N2 (all Cyber Security students, both studios) · depth: know, use & apply

How you can use this topic (learning outcomes)

This topic supports the following learning outcomes, with example products you could deliver in your project:

Analysing & Advising — an analysis of which data sources your project application should log, and an advice note on how you would spot a specific attack in them.
Designing & Realising — a basic monitoring setup for your project (for example capturing and inspecting traffic, or running a detection rule) that demonstrably fires on a test attack.
Managing & Collaborating — a triage agreement for your team: which alerts matter, who investigates, and how you avoid drowning in false positives.

This topic builds directly on the SOIM overview (topic 8); make sure the MAPE-K loop and the SOC/SIEM vocabulary are clear before you start here.

What is this and why should you care?

Inside the MAPE-K loop, this topic is the first two steps: Monitor (collecting the traces) and Analyse (turning those traces into alerts). If SOIM is the security team, this is the camera network plus the guard who actually reads the feeds. It is where most of a SOC's day-to-day work happens, and where the hardest practical problem lives: there is far more benign activity than malicious activity, so finding the real attack is like finding a whisper in a stadium.

Monitoring: what do you watch?

Monitoring is the deliberate collection of activity traces so you can see what is happening in a system. The point is that an attack leaves traces somewhere, and you need to know which source holds them. The main data sources:

Network traffic is the raw data flowing over the network — who talks to whom, how much, over which protocols. Full-packet capture (the pcap standard, the format Wireshark reads) gives the most detail but costs enormous storage, so sensors often inspect it on the fly. Network aggregates (such as Netflow) record summary counters instead of full packets — far cheaper, good for spotting large-scale events like DDoS, but often sampled, which means stealthy low-volume attacks can slip through. Application and web logs record what servers and applications did (the Common Log Format of web servers, for instance). System and kernel logs record what the operating system did (audit trails). A recurring practical wrinkle: modern traffic is encrypted with TLS, which hides payloads from your sensors, so part of the job is deciding how to keep visibility without breaking privacy.

A distinction that matters throughout: an event is a raw trace (a login, a packet); an alert is a synthesised signal a sensor produces when it recognises a pattern worth attention. Monitoring produces events; analysis turns some of them into alerts.

Analysis: how do you recognise an attack?

There are two fundamentally different detection philosophies, and the tension between them is the heart of this topic.

Misuse detection (signature-based) looks for known-bad patterns — "signatures" of documented attacks, often tied to CVE identifiers. Tools like Snort and Suricata work this way. It gives a clear diagnosis (when it fires, you know exactly what it is) but it is blind to anything new and needs constant signature updates. Anomaly detection (behaviour-based) first learns what "normal" looks like, then flags deviations. It is your best chance against novel, "zero-day" attacks, but it produces far more false alarms and needs heavy tuning to be useful. Machine learning shows up here as a classification tool for anomaly detection — useful, but not magic, and itself a target (attackers craft input to slip past models).

Why tuning is not optional: because benign events outnumber attacks by a huge margin, even a very accurate sensor produces a flood of false positives. This is the base-rate fallacy (formalised by Axelsson), and it is the mathematical reason a SOC that does not tune its sensors ends up buried in noise and misses the real incident. A SOC is therefore a socio-technical system: technology (sensors, SIEM), processes (playbooks) and people (analysts) together — no one part works alone.

Starting points

Read — CyBOK KA 8, sections 2–3 (Monitor & Analyse) — the authoritative treatment of data sources and detection algorithms.
Do — Wireshark — capture and inspect real network traffic; the fastest way to understand what "network monitoring" actually means.
Do — Snort (signature-based) and Zeek (behaviour/specification-based) — compare the two detection philosophies hands-on.
Map — MITRE ATT&CK — map what you detect to real adversary tactics, so an alert becomes intent, not just a rule firing.
Study material in the knowledgebase — [TODO — !!!! Hier knowledgebase links neerzetten !!!] (Domain II → 8 SOIM → monitoring & analysis: data-source comparison, misuse vs anomaly, the base-rate fallacy worked through.)

Points of attention (check your own work)

Event vs alert — For any alert you act on, can you point to the raw events that produced it?
Right source for the threat — Have you chosen the data source that would actually contain the attack you care about (network vs host vs application)?
Performance cost — Does your monitoring choice (full pcap storage, Netflow sampling) fit the system without breaking it, and are you aware of its blind spots?
Base-rate check — Have you tuned out irrelevant noise so your alerts are mostly real, rather than contributing to alert fatigue?
People and process — Is it clear who reads the alerts and what they do next? Technology alone is not a SOC.

Going deeper (advanced)

Adversarial machine learning — how attackers craft input (evasion) to make anomaly models classify malicious traffic as normal.
Keeping visibility under encryption — the trade-offs of inspecting TLS traffic (proxies, session termination) versus respecting privacy, and where that line sits legally.
The integration burden — why sensors speak different languages (CEF, LEEF, IDMEF) and why building and maintaining the "connectors" into a SIEM is a large part of real SOC work. (This leads into the SIEM topic, 8.4.)

Sources and attribution

Debar, H. (2021). Security Operations & Incident Management. CyBOK Knowledge Area v1.0.2.