Chapter 17 — Control and feedback basics
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Feedback in operations"]
N2["17.2 Designing alerts"]
N3["17.3 Avoiding fatigue and oscillation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Feedback in operations"]
N2["17.2 Designing alerts"]
N3["17.3 Avoiding fatigue and oscillation"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Feedback in operations]
|
v
[17.2 Designing alerts]
|
v
[17.3 Avoiding fatigue and oscillation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) apply feedback loops to security operations; (2) design alerts on cryptographic health signals; (3) avoid oscillation and alert fatigue.
17.1 Feedback in operations
Control engineering studies systems that measure output and adjust input. Aiyana applies the idea to cryptographic operations: measure signals such as tag verification failures, certificate days to expiry and key ages, compare them with targets, and act. Without feedback, problems are noticed only when customers complain. A feedback loop for Ridgeway might measure the hourly rate of verification failures per collector and alert if it rises sharply, which could indicate a faulty meter batch or an attempted forgery. Aiyana treats each signal as a sensor and each runbook as the controller that closes the loop.
17.2 Designing alerts
Aiyana chooses thresholds from baseline data. Normal verification failures, from radio noise and clock drift, run at about 0.1 percent; she alerts above 1 percent sustained for fifteen minutes. Certificates alert at thirty days before expiry and escalate at seven. Key ages alert at the end of their cryptoperiod. Each alert has an owner and a runbook stating the first checks. She also adds alerts for the absence of expected signals, such as no renewal attempt in the past week, because silent failures cause many outages.
17.3 Avoiding fatigue and oscillation
Too many alerts train people to ignore them, and automated reactions that are too aggressive can oscillate, for instance repeatedly revoking and re-provisioning keys for a meter with a flaky radio. Aiyana adds hysteresis: an alert clears only when the rate falls well below the trigger. Automated actions are limited to safe steps, such as flagging a meter for inspection, while revocation requires a human decision. She reviews alert volumes monthly and removes alerts that never led to action, keeping the signal meaningful.
Worked example
Aiyana designs alerts on verification-failure rates, certificate expiry and key age, with baselines, hysteresis and human approval for revocation.
Synthetic case. The baselines are invented.
Errors and limits
Thresholds set without baselines create noise. Automated revocation without hysteresis can disrupt service.
Exercises
- EX049 — Health signals. Name three cryptographic health signals Aiyana measures. Rubric: 3 = verification failures, certificate days to expiry, key ages;; 2 = two;; 1 = one;; 0 = none.
- EX050 — Missing signal alert. Why alert on the absence of renewal attempts? Rubric: 3 = silent failures such as broken renewal clients cause outages;; 2 = silence;; 1 = not needed;; 0 = none.
- EX051 — Hysteresis use. What does hysteresis prevent here? Rubric: 3 = oscillating alerts or repeated revoke/re-provision for flaky meters;; 2 = flapping;; 1 = vague;; 0 = none.
Synthesis
Feedback loops with baselined thresholds, hysteresis and human gates keep cryptographic systems healthy without drowning operators in noise.
Continue studying — chapter 17 of 50
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →