◇ OpenCyber Academy
Bachelor's · Chapter 21 · English

Chapter 21 — Security operations and blue team: system models

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 21 — Security operations and blue team: system models

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 The SOC as a system"]
  N2["21.2 Tracing an alert"]
  N3["21.3 Delays"]
  N4["21.4 Roles"]
  N5["21.5 Interfaces"]
  N6["21.6 Using the model"]
  N7["21.7 Feedback loops"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 The SOC as a system"]
  N2["21.2 Tracing an alert"]
  N3["21.3 Delays"]
  N4["21.4 Roles"]
  N5["21.5 Interfaces"]
  N6["21.6 Using the model"]
  N7["21.7 Feedback loops"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
    |
    v
[21.1 The SOC as a system]
    |
    v
[21.2 Tracing an alert]
    |
    v
[21.3 Delays]
    |
    v
[21.4 Roles]
    |
    v
[21.5 Interfaces]
    |
    v
[21.6 Using the model]
    |
    v
[21.7 Feedback loops]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) model the SOC as a set of connected components and roles; (2) trace an alert from source to closure; (3) identify where delays and errors arise; (4) use models to plan improvements.

21.1 The SOC as a system

Riverton's SOC links log sources, a SIEM, detection rules, a case-management system, analysts and responders in IT. An alert is a message that passes through this chain; every link can delay or distort it.

Thinking of the SOC this way shifts attention from individual mistakes to the design of the chain. A late alert may not be any analyst's fault; it may come from a log source that arrives slowly, a job that runs once a day or a queue that nobody watches overnight. Each link can be measured and improved.

21.2 Tracing an alert

For the s2047 flag: the mail service logged outbound messages; logs arrived in the SIEM within 10 minutes; the z-score job ran at 07:00; the alert entered the case queue; a student analyst picked it up at 08:05; the service desk reset the password at 08:41.

Each step leaves a timestamp in a different system, so the trace was built from the mail service, the SIEM, the case system and the service desk's ticket. Putting them on one timeline showed for the first time how long each step took, which the next part of this chapter uses to find where time was lost.

21.3 Delays

The largest delay was the gap between activity (from 02:30) and the batch job (07:00). The second was queue time before an analyst picked up the alert, because the morning shift starts at 08:00.

Neither delay came from slow analysis: once the alert was picked up, the password was reset within about forty minutes. Improving analysts' speed would have saved little; changing when the job runs and who watches the queue overnight would save hours. The model makes that difference visible, which is its main purpose.

21.4 Roles

Student analysts triage; Dr. Kim's two staff engineers maintain tools and handle escalations; the service desk performs resets; the data protection officer handles personal data exposure.

Each role holds a different power. Student analysts can examine logs but cannot reset passwords; the service desk can reset but does not investigate. This separation protects against misuse but adds hand-offs, and the phishing case shows that hand-offs are where time is lost if the next person is not expecting the request. Clear roles reduce that risk.

21.5 Interfaces

Each hand-off — SIEM to case system, analyst to service desk — has a format and an expected time. Missing expectations cause waits.

After the campaign, Riverton defined the analyst-to-service-desk hand-off: a ticket with the account, the evidence reference and the action requested, with a target of thirty minutes during working hours. Before that, requests arrived by phone or chat with varying detail, and the service desk sometimes had to call back to ask what was needed. The new format removed those calls and made each request traceable in the ticket system.

21.6 Using the model

Lucas annotates the model with measured times from the campaign to show where improvements would matter most.

With times attached, the model turns opinions into comparisons. Faster triage had been suggested, but measured triage time was small; the batch gap was large. Lucas's annotations let Dr. Kim choose the changes that would save the most time for the effort, which is the decision described in the worked example below. The same annotated model is reused after each later incident, so the effect of the changes can be measured against the campaign's original times.

21.7 Feedback loops

Analyst closure reasons feed back to engineers, who tune rules; without this loop, the same noise repeats.

At Riverton, analysts close each alert with a reason such as benign travel, shared address or confirmed compromise. Engineers review the reasons monthly. When many spray alerts closed as library computers, the engineers added the library's addresses to the shared-address list, and those false alerts stopped appearing in the queue. Without the closure reasons, the engineers would not have known which addresses to add. The loop works only if analysts choose reasons carefully rather than picking the first option.

Worked example

Lucas's annotated model shows 4.5 hours lost to batch timing and 1 hour to queueing. He proposes running the outbound-mail check every 15 minutes and paging the on-call engineer overnight for scores above 50. Dr. Kim approves the first and limits the second to a trial.

Synthetic case. Times and roles are invented.

Errors and limits

Models simplify; real alerts sometimes skip or repeat stages.

Exercises

Synthesis

Modelling the SOC as a system shows where time is lost and which changes matter most.

Continue studying — chapter 21 of 40

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →