Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 The SOC as a system"]
N2["16.2 Interfaces"]
N3["16.3 Requirements flow"]
N4["16.4 Trade-offs"]
N5["16.5 Lifecycle"]
N6["16.6 Verification"]
N7["16.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 The SOC as a system"]
N2["16.2 Interfaces"]
N3["16.3 Requirements flow"]
N4["16.4 Trade-offs"]
N5["16.5 Lifecycle"]
N6["16.6 Verification"]
N7["16.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 The SOC as a system]
|
v
[16.2 Interfaces]
|
v
[16.3 Requirements flow]
|
v
[16.4 Trade-offs]
|
v
[16.5 Lifecycle]
|
v
[16.6 Verification]
|
v
[16.7 Case]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) view the SOC as a system of people, process and technology; (2) define interfaces and requirements across components; (3) manage trade-offs with explicit criteria; (4) plan lifecycle from concept to retirement.
16.1 The SOC as a system
A SOC combines people (analysts, engineers), processes (triage, escalation) and technology (sensors, SIEM, case management). Zimmerman (2014) argued that many SOCs over-invest in tools and under-invest in people and process; systems thinking keeps them in balance.
A new SIEM bought without analysts trained to use it, or without a triage process to receive its alerts, adds cost but little protection. Systems thinking asks how a change in one part affects the others: a new detection adds alerts, which adds analyst workload, which may need a process change. Amara learns to ask that chain of questions before proposing any tool.
16.2 Interfaces
Each component exchanges something: sensors send events to the SIEM, the SIEM sends alerts to the case system, analysts send escalations to incident responders. Each interface needs a defined format, timing and owner.
Most failures between teams happen at interfaces nobody owns. If the SIEM changes its alert format and nobody tells the case system's administrator, alerts may arrive with missing fields, or not at all. Writing down format, timing and owner for each interface turns an assumption into an agreement that can be checked, and gives someone the duty to notice when it breaks.
16.3 Requirements flow
Top-level needs ("detect account takeover within 15 minutes") break down into component requirements: portal logs delivered within 2 minutes, rule latency under 5 minutes, analyst acknowledgement within 8 minutes.
The parts add up: two minutes for delivery, five for the rule and eight for acknowledgement give exactly fifteen, which leaves no slack. If log delivery slips to four minutes, the whole target fails even though the rule and the analysts are on time. Paolo suggests tightening component budgets so the total leaves a margin, and monitoring each one separately.
16.4 Trade-offs
More data improves visibility but costs storage and analyst attention. Systems engineers state criteria (detection time, cost, analyst load) and compare options against them.
Stating criteria before comparing options stops people from picking the option they already liked and then finding reasons. Weights make priorities explicit: if detection time matters most, a costlier option that halves it may win. Amara builds a small table for adding depot network sensors, scoring each option on the agreed criteria with the evidence behind each score.
16.5 Lifecycle
Components are planned, built, operated, maintained and retired. Retiring an old sensor needs a replacement first, or coverage silently disappears.
Retirement is the phase most often neglected. A sensor switched off during a hardware refresh can leave a gap that nobody notices until an incident needs its data. Planning retirement means checking which rules depend on the component, confirming the replacement produces equivalent data, and running both in parallel for a short period before switching the old one off. Owners sign off each retirement.
16.6 Verification
Each requirement has a test: a timed synthetic event checks that the 15-minute target is met end to end.
The synthetic event is injected at the portal, as if from a real login burst, and timestamps are recorded at each stage: log arrival, rule firing, alert creation and analyst acknowledgement. Comparing the stage times with the component budgets shows exactly where delay occurs. The test runs regularly, not once, because performance drifts as volumes and staffing change. Missed targets open a ticket.
16.7 Case
Amara draws Lindqvist's SOC as a block diagram and labels each interface with format, latency and owner.
Drawing the diagram reveals two interfaces with no named owner: the feed from the load balancer and the link between the case system and the on-call paging service. It also shows that the portal logs pass through an intermediate collector that nobody had listed. Each gap becomes a task, and the diagram is stored with the SOC's architecture documents. Paolo reviews it with her.
Failure modes of the system
System-level failures often sit at interfaces: a format change upstream silently breaks parsing downstream. Amara adds a parsing-error alert at each interface.
Worked example
Her timed test injects a harmless synthetic portal login burst at 14:00:00. The SIEM receives it at 14:01:40, the rule fires at 14:05:10, and an analyst acknowledges at 14:11:30 — 11.5 minutes end to end, inside the 15-minute requirement. The slowest step is analyst acknowledgement.
Synthetic case. The SOC design and test are invented.
Errors and limits
End-to-end tests at quiet times may understate delays during busy periods; repeat them under load.
Exercises
- EX046 — Balance. What imbalance did Zimmerman (2014) warn about? Rubric: 3 = over-investing in tools vs people and process; 2 = partial; 1 = vague; 0 = none.
- EX047 — Requirement breakdown. Break "detect within 15 minutes" into component requirements. Rubric: 3 = log delivery, rule latency, acknowledgement with times; 2 = two; 1 = one; 0 = none.
- EX048 — Timed test. What did the end-to-end test show? Rubric: 3 = 11.5 min total; inside target; acknowledgement slowest; 2 = partial; 1 = wrong; 0 = none.
Synthesis
Systems engineering connects SOC people, process and technology through defined interfaces, requirements and tests.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →