Chapter 17 — Control and feedback basics
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Loops"]
N2["17.2 Parts of the loop"]
N3["17.3 Lag and oscillation"]
N4["17.4 Feedback to producers"]
N5["17.5 Human in the loop"]
N6["Practice note — Set points from policy"]
N7["Synthesis"]
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 Loops"]
N2["17.2 Parts of the loop"]
N3["17.3 Lag and oscillation"]
N4["17.4 Feedback to producers"]
N5["17.5 Human in the loop"]
N6["Practice note — Set points from policy"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Loops]
|
v
[17.2 Parts of the loop]
|
v
[17.3 Lag and oscillation]
|
v
[17.4 Feedback to producers]
|
v
[17.5 Human in the loop]
|
v
[Practice note — Set points from policy]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) model the intelligence cycle as a feedback loop; (2) identify sensors, controllers and actuators in a CTI workflow; (3) recognise oscillation and lag; (4) design feedback from consumers to producers.
17.1 Loops
A thermostat measures temperature, compares it with a set point, and acts. Lantern measures false-positive rates of blocks, compares them with a target, and adjusts confidence thresholds. Without measurement the loop is open and drifts.
The measured quantity must be one the loop can actually change. Lantern cannot alter the quality of a partner's feed directly, but it can change how much weight that feed's indicators carry. Kofi chose the threshold as the adjustable value because moving it has a predictable effect on how many blocks reach the firewalls.
17.2 Parts of the loop
Sensor: SOC tickets marking blocks as false positives. Controller: the rule that raises or lowers the threshold. Actuator: the block list pushed to firewalls. Disturbance: a partner suddenly publishing low-quality indicators.
Naming the parts shows where errors enter. If analysts stop marking false positives because the ticket form is slow, the sensor goes quiet and the controller sees a falsely healthy system. Kofi made the marking a single click inside the alert view for that reason. The disturbance cannot be removed, but the loop can be designed to recover from it within days.
17.3 Lag and oscillation
If the threshold changes daily based on yesterday's complaints, it can overshoot: too strict one day, too loose the next. Damping — small steps, averaging over a week — stabilises the loop.
Kofi simulated both versions on a month of past tickets. Daily full-size adjustments swung the threshold up and down nearly every day, while weekly averages with steps capped at a small amount settled within two weeks. The slower loop reacts later to a real change, which is the price of stability. A sudden large problem is handled separately, by an analyst pausing the source.
17.4 Feedback to producers
NIST SP 800-150 encourages two-way sharing relationships. Telling partners which of their indicators caused false positives improves the whole community's loop, provided it respects TLP and agreements.
Kofi's feedback to a partner lists the indicator identifiers that caused trouble and what kind of trouble, such as a block on a legitimate supplier, without sending BEN's internal ticket text. Partners that receive such feedback have fixed recurring errors within weeks. Because the indicators came from the partner, sharing their identifiers back does not widen their audience.
17.5 Human in the loop
Automated control is fine for IT perimeter blocks with low impact; for OT segments, a human approves each change, which deliberately slows the loop where mistakes are costly.
Kofi measured the cost of that choice. Approved changes to substation firewalls took a median of several hours, against minutes for corporate segments. The operations manager accepted the delay because a wrong block in a substation could hide telemetry the control room needs. Fast paths exist for emergencies, but each needs a named approver who records the reason.
Practice note — Set points from policy
The target false-positive rate is not an engineering choice alone. Operations managers decide how much disruption is tolerable, and Lantern's controller uses that set point. Writing the set point into policy makes later adjustments a governed decision rather than a quiet code change.
Worked example
False-positive tickets jump from 3 to 25 after a partner adds a large unvetted list. Kofi's controller lowers the partner's weight by 10% per day, capped at 30% total, instead of disabling it outright, and sends the partner a summary of affected indicators.
Synthetic case. Ticket counts and weights are invented.
Errors and limits
Feedback signals can be biased: analysts report false positives more than missed detections. Measure both.
Exercises
- EX049 — Name the parts. Identify sensor, controller and actuator in Lantern's threshold loop. Rubric: 3 = FP tickets; threshold rule; pushed block list; 2 = two; 1 = one; 0 = none.
- EX050 — Damping choice. Why limit the weight change to 10% per day? Rubric: 3 = avoids oscillation/overreaction to noisy signal; 2 = caution vaguely; 1 = faster is better; 0 = none.
- EX051 — Biased signal. Why might relying only on false-positive tickets bias the loop? Rubric: 3 = misses false negatives; pushes toward permissiveness; 2 = partial; 1 = no bias; 0 = none.
Synthesis
Close the loop with measurement, damp it to avoid oscillation, share feedback upstream, and keep humans where errors are costly.
Continue studying — chapter 17 of 50
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →