Chapter 20 — Security operations and blue team: engineering context
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Mission first"]
N2["20.2 SOC services"]
N3["20.3 Constraints"]
N4["20.4 Stakeholders"]
N5["20.5 Engineering problems ahead"]
N6["20.6 Maturity"]
N7["20.7 Measures of success"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Mission first"]
N2["20.2 SOC services"]
N3["20.3 Constraints"]
N4["20.4 Stakeholders"]
N5["20.5 Engineering problems ahead"]
N6["20.6 Maturity"]
N7["20.7 Measures of success"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Mission first]
|
v
[20.2 SOC services]
|
v
[20.3 Constraints]
|
v
[20.4 Stakeholders]
|
v
[20.5 Engineering problems ahead]
|
v
[20.6 Maturity]
|
v
[20.7 Measures of success]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) describe the SOC's mission and services in engineering terms; (2) relate SOC functions to the organisation's risk; (3) identify stakeholders and constraints; (4) frame SOC engineering problems for the rest of the course.
20.1 Mission first
Knerler, Parker and Zimmerman (2022) open with "know what you are protecting and why". Lindqvist protects customer data, delivery operations and payment flows. Engineering choices follow from that mission, not from tool features.
Starting with tools leads to collecting whatever the tool supports. Starting with the mission leads to asking what harm would matter most: stolen customer data, stopped deliveries or diverted payments. Those answers decide which systems need the best coverage and which alerts deserve a page at night, so engineering effort follows business impact.
20.2 SOC services
Lindqvist's SOC provides monitoring and triage, incident response coordination, detection engineering, vulnerability intake and threat intelligence consumption. Each service has customers inside the company and measurable outputs.
Treating each as a service clarifies who it serves and how to measure it. Monitoring serves the whole company and is measured by detection and response times; detection engineering serves the analysts and is measured by rule quality; vulnerability intake serves IT teams and is measured by how quickly reports reach owners. Unclear services tend to drift into unplanned work.
20.3 Constraints
Budget, staff numbers, regulation and legacy systems constrain design. The depot scanners run old software that cannot host agents, so network monitoring must cover them.
Constraints are design inputs, not excuses. Old scanner software that cannot run an agent rules out endpoint telemetry, so the design shifts to observing scanner traffic on the depot network. Budget may limit sensors to the busiest depots first. Regulation may require keeping certain logs for set periods. Each constraint is written down so later readers understand the design.
20.4 Stakeholders
The CISO sets priorities; IT operations own systems; legal and privacy staff set limits; business units feel the impact of response actions. SOC engineers must work with all of them.
IT operations may resist a sensor that could slow their systems; legal staff may limit what content can be collected; business units may object to an account lock during peak delivery hours. Engineers who involve them early hear these concerns while design is still flexible. Amara keeps a stakeholder list with what each group cares about most.
20.5 Engineering problems ahead
The course follows four problems at Lindqvist: detecting account takeover on the portal; monitoring depot networks without agents; keeping the SIEM within capacity; and proving the SOC works through verification.
Each problem draws on different skills: account takeover on identity data and statistics, depot monitoring on networks and architecture, SIEM capacity on data systems and maths, and verification on testing and measurement. Following the same company through all four lets the course show how decisions in one area, such as storage tiering, constrain options in another.
20.6 Maturity
The SOC-CMM (van Os, 2016) assesses business, people, process, technology and services. Lindqvist's self-assessment shows strong technology but weak process documentation, guiding priorities.
A maturity model gives a structured way to see strengths and weaknesses across a whole SOC. Strong technology with weak process documentation means tools work but outcomes depend on which analyst is on shift. The self-assessment suggests writing playbooks before buying more tools, and it gives a baseline to repeat later and show progress. The assessment is repeated each year by the same method.
20.7 Measures of success
Success is not "no incidents" but faster detection, better decisions and less harm.
A quiet year may mean nothing happened, or that nothing was detected; the two look the same in an incident count. Better measures include time from first evidence to detection, time to containment, and how often response decisions were later judged correct. Lindqvist's SOC reports these monthly, alongside honest notes on any missed detection. Each measure has a stated target, and trends over several months matter more than any single month's figure, which can swing with one large incident.
Funding the SOC
The SOC's budget competes with other IT work. Engineers who can show how a change reduces risk or analyst time win support more easily than those who ask for tools.
Worked example
Amara writes a one-page context brief: mission, services, constraints, stakeholders and the four engineering problems. Paolo adds one constraint she missed — the SOC has only two analysts on night shift — which shapes every alerting decision.
Synthetic case. Lindqvist's SOC and its assessment are invented.
Errors and limits
Context changes with the business; revisit the brief when the company changes.
Exercises
- EX058 — Mission link. How does the mission guide engineering choices? Rubric: 3 = what is protected drives priorities, not tool features; 2 = partial; 1 = vague; 0 = none.
- EX059 — Depot constraint. Why must depot scanners be monitored from the network? Rubric: 3 = old software cannot host agents; 2 = partial; 1 = no reason; 0 = none.
- EX060 — Night shift. Why does the two-analyst night shift matter? Rubric: 3 = limits alert volume they can handle; shapes alerting; 2 = partial; 1 = irrelevant; 0 = none.
Synthesis
SOC engineering starts from mission, services, constraints and stakeholders; the rest of the course solves problems within them.
Continue studying — chapter 20 of 50
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →