Chapter 17 — Control and feedback basics
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Feedback loops"]
N2["17.2 Tuning as control"]
N3["17.3 Oscillation"]
N4["17.4 Delay"]
N5["17.5 Positive feedback"]
N6["17.6 Measurement"]
N7["17.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Feedback loops"]
N2["17.2 Tuning as control"]
N3["17.3 Oscillation"]
N4["17.4 Delay"]
N5["17.5 Positive feedback"]
N6["17.6 Measurement"]
N7["17.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Feedback loops]
|
v
[17.2 Tuning as control]
|
v
[17.3 Oscillation]
|
v
[17.4 Delay]
|
v
[17.5 Positive feedback]
|
v
[17.6 Measurement]
|
v
[17.7 Case]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) explain feedback loops in security operations; (2) model tuning as a control system; (3) recognise oscillation and instability in alert thresholds; (4) design stable feedback with measurement.
17.1 Feedback loops
A feedback loop measures an output and adjusts an input to reach a target. A thermostat measures temperature and switches heating. In a SOC, analysts measure alert quality and adjust rules.
A loop has four parts: a target, a measurement, a comparison and an adjustment. If any part is missing, the loop does not work. Many SOCs have the adjustment, since engineers do tune rules, but lack a clear target or a reliable measurement, so tuning becomes a reaction to whichever complaint was loudest that week.
17.2 Tuning as control
Suppose the target is fewer than 20 false alerts per day from a rule. If the measured count is higher, the threshold rises; if real attacks are missed, it falls. This is a control loop with the engineer as controller.
The loop has two opposing pressures: false alerts push the threshold up, missed attacks push it down. A good controller balances both rather than reacting only to the more visible one. False alerts are seen every day by analysts, while misses may stay hidden, so engineers must deliberately look for misses or the threshold will drift upward over time.
17.3 Oscillation
If adjustments are too large or too fast, the system overshoots: the threshold jumps up, misses an attack, jumps down, floods analysts. Small, measured steps with time to observe effects avoid oscillation.
A thermostat that switched heating fully on and off at the slightest change would make a room swing between too hot and too cold. Rule tuning behaves the same way. Changing a threshold from five to six, then watching for a fortnight, gives clear evidence of the effect. Changing from five to fifteen and back within a week tells nobody anything.
17.4 Delay
Feedback in SOCs is slow: the effect of a change on missed attacks may not be known for weeks. Long delays make aggressive tuning dangerous.
A missed attack may surface only when a customer complains or when a later investigation finds earlier signs. If an engineer raises a threshold today, the cost of that change may not appear for a month. Faster signals, such as injected test events that should be caught, shorten the loop by showing immediately whether a change has opened a gap.
17.5 Positive feedback
Some loops amplify: an overloaded queue makes analysts close alerts faster with less care, which hides misses, which leads to more silent compromise. Recognising such loops lets managers break them.
The loop feeds itself: more silent compromises lead to more incidents later, which add more work, which increases the pressure to close alerts quickly. Breaking it might mean temporarily disabling low-value rules to give analysts time, or adding staff. Managers who track only queue length may see the queue shrink and believe things improved, while quality falls.
17.6 Measurement
Feedback is only as good as its measurement. Labelled samples of closed alerts and periodic safe test events provide signals about misses.
Labelled samples mean reviewing a random selection of closed alerts and checking whether the closing decision was right. That shows how often benign closures were actually wrong. Safe test events, injected without warning, show whether the full chain from sensor to analyst still works. Both give the loop data about misses, which ordinary alert counts cannot reveal. Both feed the monthly review.
17.7 Case
Amara's portal rule threshold starts at 5 failures per 10 minutes; Paolo asks her to plan its tuning loop.
Amara's plan names the target, at most a set number of false alerts per day with no missed test bursts; the measurements, daily counts and weekly injected bursts; the step size, one failure at a time; and the wait, two weeks between changes. Paolo approves it with one addition: any change and its result must be written in the rule's history. Amara starts the loop next Monday.
Worked example
Amara proposes: measure weekly false alerts and test-event detection; change the threshold by at most one step per fortnight; never raise it if any test event was missed. After four weeks the rule settles at 6 failures, with 8 false alerts per day and all test events caught.
Synthetic case. Thresholds and counts are invented.
Errors and limits
Treating tuning as control is a model; attackers adapt deliberately, unlike heat in a room.
Exercises
- EX049 — Oscillation cause. What causes threshold oscillation, and how is it avoided? Rubric: 3 = large/fast changes; small steps with observation time; 2 = partial; 1 = vague; 0 = none.
- EX050 — Harmful loop. Describe one positive feedback loop in a SOC. Rubric: 3 = overload → hasty closures → missed attacks → more compromise; 2 = partial; 1 = vague; 0 = none.
- EX051 — Tuning plan. State Amara's tuning rules and the outcome. Rubric: 3 = ≤ 1 step per fortnight; no raise if test missed; settled at 6, 8 false/day, all tests caught; 2 = partial; 1 = outcome only; 0 = none.
Synthesis
Treat tuning as a slow feedback loop: measure carefully, adjust gently and watch for amplifying loops.
Continue studying — chapter 17 of 50
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →