5.1Security event monitoring and escalation

Incident handling begins, before any dramatic response, with the machinery of noticing. Finding "this is not normal" among a flood of logs and traffic and, when needed, handing it up—this first checkpoint is monitoring and escalation. This section covers the difference in roles between SIEM (collecting logs in one place and correlating them) and SOAR (automating the response after detection), the targets of network data monitoring such as packet capture and various logs, and how to identify a suspicious event and when to escalate—learned not by rote but through the lens of "what does this sign on this screen mean."

5.1.1The differing roles of SIEM and SOAR

• SIEM (Security Information and Event Management) is a platform that aggregates logs from many sources—servers, devices, applications—into one place and correlates them to produce awareness (detection). Its essence is relating and surfacing anomalies invisible in a single log (for example, a burst of failed logins immediately followed by a success) and raising alerts.
• SOAR (Security Orchestration, Automation and Response) is machinery that automates and orchestrates the response after detection. Following a playbook, it chains steps like "isolate the host," "open a ticket," and "notify the owner" automatically, reducing manual effort and speeding the first response. Remember the split: SIEM notices, SOAR acts.
• The two are not rivals but work together. Typically SIEM detects "something suspicious" by correlation, and SOAR receives that alert and runs a routine response. At the introductory level, what matters is holding the role wording precisely: "log aggregation and correlation = SIEM / response automation and orchestration = SOAR."

5.1.2Monitoring data, spotting suspicious events, and escalating

• The targets of network data monitoring are broad: packet capture (recording the communication itself), firewall and proxy logs, authentication logs, DNS logs, endpoint logs, and more. At the CCST introductory stage it is enough to identify "what data sources exist and what each reveals", without going as deep as CyberOps-level detailed analysis.
• Identifying a suspicious event means finding a deviation from the baseline (the normal picture). Examples: an administrator login in the middle of the night, a burst of failed logins in a short time, large transfers to a country you never talk to, or an unknown process running. More than a single event, suspicion arises when the combination of time, count, and counterpart is "not normal."
• Escalation means handing an event you cannot fully judge with your own authority or procedures up to a higher or more specialized owner. Good cues: "the impact may spread," "sensitive data is involved," "the response needs authority or expertise," or "it exceeds what the runbook anticipates." The correct behavior for a beginner is to raise it promptly rather than sitting on it while unsure.

Suppose you are on monitoring duty and a single alert appears on the SIEM screen: "for one employee account, 12 consecutive failed logins from an overseas IP at 22:10, immediately followed by a successful login from the same overseas IP." What matters here is understanding why this became one alert. The failed-login records and the success record are originally separate entries, but because SIEM aggregated logs from multiple sources and correlated a time-linked relationship (a burst of failures -> a success), they became a single piece of "this is suspicious" awareness. Staring at one log alone, you might have missed it. Next, consider what you should do. This sign is a suspicious event—a clear deviation from the baseline for an employee who normally logs in only from within the country, now succeeding at midnight from an overseas IP after repeated failures. A password may have been broken by brute force, and leaving it could let the damage spread. If the organization has SOAR, a playbook can automatically run first-response steps like "suspend the account," "cut the session," and "open an incident ticket," stopping the spread before a human decides. But whether SOAR responded automatically or the environment has no automation at all, the thing you yourself must judge is whether to escalate. It may be an account that handles sensitive information, and pinning down the blast radius may need investigation beyond your authority—if you feel that, hand it promptly to the incident response team rather than holding it until you are certain. The lesson: from a single alert on the screen you can read the three-way division of roles—SIEM builds the awareness, SOAR drives the response, and the human judges "should this be raised."

5.1.3Section summary

• SIEM aggregates and correlates many logs to detect (notice); SOAR automates and orchestrates the response after detection (act)—do not swap the roles
• The targets of network data monitoring are packet capture and various logs; a suspicious event is found as a deviation from the baseline
• The correct beginner behavior is not to sit on an event you cannot fully judge but to escalate it promptly to a higher owner