2.2 Core Workflows and Decision Points

2.2 Core Workflows and Decision Points

A security operations center (SOC) runs a repeatable pipeline: collect telemetry, normalize and correlate it, detect, triage, and escalate. CySA+ tests each handoff in that pipeline, so learn the inputs, the controlling tool, and the output of each stage.

The monitoring pipeline

Log sources you must read on sight

Windows security auditing event IDs are frequent PBQ fodder. Commit these to memory:

• 4624 – successful logon; the Logon Type field matters (Type 3 = network, Type 10 = RemoteInteractive/RDP).
• 4625 – failed logon; a burst of 4625 across many accounts = password spraying.
• 4648 – logon using explicit credentials (lateral movement / runas indicator).
• 4672 – special privileges assigned at logon (admin/SYSTEM session).
• 4688 – new process created (command-line auditing reveals living-off-the-land abuse).

On Linux, watch /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) for sshd authentication failures and sudo escalations, and /var/log/syslog for daemon activity. NetFlow/IPFIX records summarize conversations (source/destination IP, ports, byte and packet counts) without payload, which is ideal for spotting beaconing and exfiltration volume at scale; full packet capture (PCAP) adds payload for deep inspection but is storage-expensive, so most SOCs keep flow data long-term and capture packets selectively.

Detection methods you must distinguish

The exam separates two detection philosophies. Signature-based detection (traditional IDS/IPS rules, antivirus, YARA) matches known-bad patterns: it is precise and low-noise but blind to novel attacks. Behavioral/anomaly-based detection compares activity to a learned baseline and flags deviations: it can catch zero-day and fileless activity but produces more false positives until tuned. Heuristic detection sits between, scoring suspicious characteristics.

Most mature SOCs layer all three, and CySA+ expects you to pick the method that fits the threat described — signatures for known malware, behavioral analytics for living-off-the-land abuse.

Correlation beats single alerts

A single failed login is noise. The same source IP producing 4625 across 50 accounts in two minutes, then one 4624, then a 4672 is a credible compromise. CySA+ rewards the answer that correlates events into a chain rather than reacting to one line. This is why SIEM correlation rules and a tuned baseline are emphasized: without a baseline, you cannot define "anomalous," and untuned rules drown analysts in false positives (alert fatigue).

SOAR: automation and orchestration

Security Orchestration, Automation, and Response (SOAR) platforms execute playbooks that perform the deterministic steps of triage: enrich an IP against threat intel, pull the EDR process tree, disable an account, or open a ticket. The exam-correct framing is that SOAR augments analysts by automating repetitive tasks and orchestrating tools, freeing humans for judgment-heavy investigation. It does not replace analysts, eliminate firewalls, or by itself generate threat intelligence.

A practical correlation tool the exam references is the SIEM use case, a saved rule that joins data sources to detect a specific scenario — for example, "VPN login from country A followed within an hour by a login from country B" flags impossible travel. Building and tuning these rules is core SOC work: too loose and analysts drown in false positives; too tight and real attacks slip through. The metric that captures this balance is the true-positive vs. false-positive rate, and reducing false positives is the single biggest lever against analyst alert fatigue.

Common decision-point traps

Watch for stems that tempt you to act before you have evidence. Containing a host on one suspicious DNS lookup may destroy volatile memory you needed; conversely, "keep monitoring" is wrong when you already have confirmed C2. The defensible answer matches the confidence the evidence supports: enrich and correlate when uncertain, contain when confirmed.

Remember the order of volatility when a stem implies evidence collection: capture the most fleeting data first — CPU registers and cache, then RAM and running network connections, then disk and logs, then archival media and backups. An analyst who powers off or reimages a host on a hunch loses the memory-resident artifacts that fileless malware lives in. The exam-correct sequence almost always preserves volatile evidence before any destructive containment, and it documents each step so the action holds up in an investigation.

When two actions seem reasonable, prefer the one that gathers confirming evidence while keeping the cleanest, most defensible audit trail.

Standardizing and automating processes

Objective 1.5 of Domain 1.0 covers standardizing and automating SOC work, and the exam tests why it matters, not just the buzzwords. Standardization through documented playbooks and runbooks ensures every analyst handles the same alert the same defensible way; it makes onboarding faster and makes outcomes auditable. Automation through scripting and SOAR removes human latency and error from repetitive steps — enrichment, ticket creation, blocklist updates, and account disablement.

Two terms to keep straight: orchestration is coordinating actions across many tools (firewall, EDR, ticketing), while automation is executing an individual task without a human. The exam-correct view is that automation handles volume and speed so analysts can spend judgment on the ambiguous cases that scripts cannot resolve. A related concept is single pane of glass — consolidating tool outputs into one console — which reduces context-switching and the missed correlations that cause incidents to slip through. Automating a bad process only scales the mistake, so standardize first, then automate.