Chapter 21 — Security operations and blue team: requirements
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Sources of requirements"]
N2["21.2 Functional requirements"]
N3["21.3 Non-functional requirements"]
N4["21.4 Measurable wording"]
N5["21.5 Traceability"]
N6["21.6 Prioritisation"]
N7["21.7 Change control"]
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 Sources of requirements"]
N2["21.2 Functional requirements"]
N3["21.3 Non-functional requirements"]
N4["21.4 Measurable wording"]
N5["21.5 Traceability"]
N6["21.6 Prioritisation"]
N7["21.7 Change control"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Sources of requirements]
|
v
[21.2 Functional requirements]
|
v
[21.3 Non-functional requirements]
|
v
[21.4 Measurable wording]
|
v
[21.5 Traceability]
|
v
[21.6 Prioritisation]
|
v
[21.7 Change control]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) elicit SOC requirements from stakeholders and threats; (2) write measurable functional and non-functional requirements; (3) trace requirements to threats and tests; (4) prioritise requirements under constraints.
21.1 Sources of requirements
Requirements come from the mission, threats, regulations, incidents and analysts' pain. The portal incident produced the requirement "detect likely account takeover on the customer portal within 15 minutes".
Each source pulls in a different direction. Threats suggest what attackers will try; regulations set minimums such as retention; incidents expose gaps that actually hurt; analysts' pain reveals where work is wasted on noisy rules or missing context. Collecting from all of them avoids a requirement set that reflects only the loudest voice, and the source of each is recorded beside it.
21.2 Functional requirements
These say what the system does: ingest load-balancer logs; correlate failures and successes per network; raise an alert with the customer ID, source network and subsequent actions.
Each statement is phrased as something the system must do, so a tester can check it directly: feed in load-balancer logs and see whether they are ingested; create a failure burst followed by a success and see whether the correlation fires; open the alert and see whether it carries the three named fields. Vague verbs like 'support' or 'handle' are avoided.
21.3 Non-functional requirements
These say how well: latency under 5 minutes from event to alert; availability of 99.5% for the pipeline; no more than 10 false alerts per day to the night shift; data retained 90 days hot.
These qualities are often where systems disappoint, because they are easy to forget during design. A rule that is logically perfect but alerts twenty minutes late misses the target. A 99.5% availability target allows about 44 hours of pipeline downtime per year, which Amara compares with the maintenance windows already planned, to check that the figure is realistic.
21.4 Measurable wording
"Fast" and "accurate" cannot be tested. Each requirement states a number, a condition and a measurement method.
For example, 'fast' becomes '95% of alerts created within 5 minutes of the triggering event, measured from event time to alert time over a calendar month'. The method matters as much as the number: measuring from ingestion time rather than event time would hide delays in log delivery and make the pipeline look better than it is. Amara rewrites every requirement in this form and asks Paolo to try writing a test for each; any he cannot test goes back for rewording.
21.5 Traceability
A table links each requirement to its source (threat, regulation, incident), the design element that meets it and the test that verifies it. ATT&CK technique IDs give a common reference for threat sources.
The table works in both directions. Reading forward from a threat shows whether anything addresses it; reading backward from a test shows why it exists. A changed regulation is traced the same way, from its row to the requirements and tests that cite it. Using technique IDs means the security team and outside reports can refer to the same threat without ambiguity.
21.6 Prioritisation
With limited staff, Amara and Paolo rank requirements as must, should or could, guided by risk and cost.
A must is something without which the system fails its purpose, such as detecting account takeover; a should adds real value but can wait, such as enriching alerts with customer tier; a could is nice to have. Ranking openly lets managers see what will not be delivered this quarter, rather than discovering it later when time runs out. Musts are funded first; coulds wait for spare capacity.
21.7 Change control
Requirements change; each change is recorded with reason and approval, and affected tests are updated.
Without it, requirements shift quietly through conversations, and tests end up checking something no one agreed to. Recording the reason keeps changes honest: lowering the false-alert limit because analysts complained is different from lowering it because the night shift was reduced. Updating tests alongside keeps verification aligned with what the system is now expected to do. Paolo approves each change, and the requirement keeps its history so earlier test results can still be interpreted against the version in force then.
Acceptance criteria
Each requirement has acceptance criteria agreed before building: what result in which test counts as passed. Agreeing them early prevents arguments later about whether the work is done, and gives analysts a clear promise about what the new detection will deliver.
Worked example
Amara's requirement R-07 reads: "The pipeline shall raise a possible-takeover alert within 15 minutes of a successful portal login that follows at least 6 failures for distinct users from the same /24 in 10 minutes; verified monthly by a timed synthetic event." Paolo approves it as a must.
Synthetic case. Requirements are invented.
Errors and limits
Too many requirements become unmanageable; focus on those tied to real risks.
Exercises
- EX061 — Functional versus non-functional. Give one functional and one non-functional requirement from the case. Rubric: 3 = e.g. correlate failures/successes; latency under 5 minutes; 2 = one; 1 = confused; 0 = none.
- EX062 — Measurable wording. Rewrite "alerts must be fast" as a measurable requirement. Rubric: 3 = number, condition, measurement; 2 = partial; 1 = unchanged; 0 = none.
- EX063 — Traceability table. What columns does the traceability table have? Rubric: 3 = requirement, source, design element, test; 2 = three; 1 = one; 0 = none.
Synthesis
Measurable, traceable, prioritised requirements turn incidents and threats into engineering work.
Continue studying — chapter 21 of 50
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →