2.3.1. SIEM, SOAR, and EDR
💡 First Principle: SIEM, SOAR, and EDR form a detection-response stack — SIEM provides the centralized view, SOAR automates the triage and response, and EDR provides endpoint depth that network-level tools can't see.
SIEM (Security Information and Event Management) centralizes log collection and correlation from across the environment. Core functions:
| SIEM Function | What It Does | Why It Matters |
|---|---|---|
| Log aggregation | Collects logs from all sources into one place | Enables cross-source correlation |
| Normalization | Converts different log formats into a common schema | Allows correlation across unlike systems |
| Correlation rules | Matches patterns across events from multiple sources | Surfaces multi-step attacks invisible in single logs |
| Alerting | Generates actionable notifications when rules fire | Directs analyst attention |
| Retention | Stores logs for investigation and compliance | Forensic investigation, regulatory requirements |
| Dashboard/reporting | Visualizes security posture | Management reporting, trend analysis |
Common SIEMs: Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM. The CySA+ exam is vendor-neutral but expects understanding of SIEM functions.
SOAR (Security Orchestration, Automation, and Response) extends the SIEM by automating the response workflow. When a SIEM alert fires, SOAR can automatically: enrich the alert (query threat intel for the IP; look up the user in HR systems), execute containment actions (block the IP at the firewall, disable the user account), and ticket the incident. Human analysts review completed playbook runs rather than manually executing each step.
Key distinction: SOAR automates defined, repeatable responses. Novel attacks or complex investigations still require human analyst judgment.
EDR (Endpoint Detection and Response) provides deep visibility into endpoint activity — process creation, network connections, file modifications, registry changes, memory access — and the ability to respond (isolate the endpoint, kill a process, pull a forensic image). EDR is the evolution of antivirus: instead of only blocking known-bad signatures, it records everything and enables behavioral detection.
XDR (Extended Detection and Response) extends EDR to correlate signals across endpoints, network, cloud, and identity — essentially a more integrated version of the SIEM+EDR combination.
Putting them to work:
- Triage with intel. EDR per-process network telemetry matched against threat-intelligence IoC feeds (IPs, domains, hashes) is the fastest way to learn whether an endpoint is talking to known-bad infrastructure; a vulnerability scanner does not observe traffic and a full PCAP is slower to collect and read.
- Context sets urgency. An alert's priority depends on what it touches (privileged or service accounts, crown-jewel data) more than on time of day or raw count, so enrich alerts with account privilege and asset criticality: failed logins against a backup service account that can read everything outrank the same pattern against an ordinary user.
- Tune before you automate. When most alerts are false positives, analyze them rule by rule and tune or suppress known-safe patterns (raise a threshold, allowlist a trusted application) before expanding SOAR, because automating noise only scales it. Disabling noisy rules wholesale, auto-closing by severity, or hiring to match the volume all leave the cause in place. A detection tool with a high false-positive rate usually has its sensitivity set too high or lacks allowlisting for trusted applications; outdated signatures cause misses (false negatives), not false alarms.
- Logging gaps. A system that cannot forward logs or run an agent (SCADA/OT, legacy) is not excluded from monitoring; the compensating control is passive network monitoring on its segment (a TAP or SPAN port feeding Zeek or an OT-aware sensor) into the SIEM, which never touches the fragile devices.
⚠️ Exam Trap: SOAR does not eliminate the need for analysts — it eliminates the need for analysts to perform repetitive, well-defined tasks. The exam will present scenarios where SOAR is appropriate (block known-bad IP, disable compromised account) vs. where human judgment is required (investigate novel malware, decide on incident severity). Know the difference.
Packet Analysis Tools
| Tool | What it is | Typical analyst use |
|---|---|---|
| Wireshark | Graphical protocol analyzer | Open a capture, apply display filters, follow a TCP stream |
| tcpdump | Command-line packet capture | Capture on a headless server or sensor; -w writes raw packets to a pcap, -r reads one back |
| Snort | Rule-based IDS/IPS | Alert on (or, inline, block) traffic that matches a written signature |
| Suricata | Rule-based IDS/IPS and network security monitoring engine | Signature alerts plus protocol metadata logged as EVE JSON |
| Zeek | Network security monitor | Turns traffic into structured logs (conn.log, dns.log, http.log, ssl.log) for hunting and forensics |
Snort and Suricata answer "did this traffic match something known to be bad?" Zeek answers "what actually happened on the wire?", and its conn.log uid field links every record belonging to one connection across the other logs.
Reading a Snort rule header. alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"Inbound SMB from internet"; sid:1000001;) reads left to right as action (alert), protocol (tcp), source address and port, direction operator, destination address and port, then options in parentheses. -> means the left side is the source and the right side the destination; <> matches either direction. msg is printed with the alert and sid identifies the rule. alert generates an event but lets the traffic pass; stopping it needs drop or block on a sensor running inline.
⚠️ Exam Trap: An IDS rule with the alert action never stops traffic, however serious its message sounds. Blocking requires an inline deployment and a blocking action.
The difference between the two is placement, not detection method. An IDS watches a copy of the traffic (SPAN port or TAP, out of band) and alerts; an IPS sits inline, so it can drop or reset malicious sessions in real time, at the cost of added latency and the risk of blocking legitimate traffic. Either can use signature or anomaly detection, on premises or in the cloud.
Reflection Question: A SOAR playbook automatically blocks outbound connections to IPs flagged in a threat intelligence feed. An attacker pivots to using a compromised legitimate CDN as a proxy for C2. Why does the SOAR automation fail to block this traffic, and what kind of detection would be needed instead?
