Resilience
Boeing trains pilots to survive failure by simulating it relentlessly. Most security programs only confirm that a fix was installed, never that it holds when someone attacks it.
A commercial pilot spends recurring hours every year in a simulator, and almost none of that time is spent flying a normal flight. Instructors fail an engine on takeoff. They ice the wings. They kill a hydraulic system at the worst possible altitude and watch what the crew does next. The point is not to confirm the plane can fly. The point is to confirm the crew can still land it when something it depends on stops working.
This is deliberate. Airlines do not test whether a backup system exists. They test whether the crew can operate under it, under time pressure, with alarms sounding and other systems degrading at the same moment. A redundant sensor nobody has trained against is not a safety feature. It is an assumption wearing a safety feature's uniform.
Recurrent training exists because a single pass is not proof. A pilot who handled an engine failure once, two years ago, in a calm simulator with no distractions, is not the same pilot who can handle it at night, in weather, with a warning light he has never personally seen fire. Aviation repeats the failure until the response is automatic, then repeats it again on a schedule, because skill against a rare event decays the moment you stop rehearsing it.
Security has its own version of this discipline, and it stops one step short of the part that matters. A vulnerability scan confirms a patch installed. A compliance report confirms an endpoint checked in. A dashboard turns green when a flaw no longer shows in the results. All of that is real work, and none of it is the same claim aviation makes about its own systems.
A patch report proves a control exists. It does not prove the control works under attack. Those are different claims, and the gap between them is where breaches live. An endpoint agent can be installed and misconfigured. A firewall rule can be deployed and never actually block the traffic it was written for. A detection rule can fire cleanly in a test environment and stay silent in production because the log source feeding it went quiet months ago and nobody noticed. Every one of those would pass an audit that only checks presence.
The MOVEit breach of 2023 is the clean example. A single flaw in a widely used file-transfer product was exploited at scale, and the organizations caught in it were not, as a group, careless. Many had patch programs, asset inventories, vendor risk processes, everything a checklist wants to see. What most had not done was test whether their actual exposure through that one product would survive a real exploitation attempt. The control existed on paper. Nobody had rehearsed the failure.
Aviation is not immune to this same gap, and its worst modern failure came from exactly this shortcut. The 737 MAX carried a new flight-control system designed to correct a handling change in the aircraft. The system existed. It had been engineered. It had been certified. What it had not been given was a realistic simulator scenario that put pilots face to face with it misbehaving, repeatedly, under the specific conditions that later occurred in the air. Crews encountered the failure for the first time with passengers on board. Two of those encounters ended in the loss of the aircraft.
The industry's response was not a better patch. It was to return to the discipline it had briefly skipped: put the failure in the simulator, force pilots through it until the response was instinct, and refuse to certify the aircraft's return to service without that rehearsal. The lesson generalizes past aviation. A system that exists but has never been tested against its own realistic failure mode is not a safer system. It is an untested one that has not failed yet.
The fix is not more scanning. It is treating "patched" and "protected" as separate, unverified claims until each has been tested against a real failure condition, the way an airline treats a redundant system as unproven until a crew has flown it broken.
Put your own controls through a live failure, on a schedule, not just after an incident.
Run a breach-and-attack simulation or a purple team exercise against the specific detection and response controls you rely on, not a generic penetration test that reports on everything except whether your team actually caught it. If your security operations center has never seen a live simulated exfiltration attempt, you do not know if it will catch a real one.
Ask what happens after the alert, not just whether the alert fires.
A detection rule that triggers correctly in a demo but never reaches an analyst, or reaches one who does not know the runbook, has the same practical value as no rule at all. Test the full chain: detection, escalation, decision, action, under time pressure, the way a simulator tests a full crew response and not just whether a warning light illuminates.
Rotate the failure scenario, the way a simulator schedule rotates.
An engine fire on takeoff, tested every session for a decade, stops teaching anything new. Vary the entry point. Vary the time of day. Vary which system fails first. A security program that always tests the same phishing scenario is training for the last attack, not the next one.
Report resilience, not deployment.
A board slide that says most endpoints are patched answers a different question than one that says here is what happened the last time we simulated a live intrusion, and here is what we changed because of it. Ask your team for the second slide. If it does not exist, that is the finding.
A checklist can only ever tell you what is installed. It cannot tell you what survives contact with an adversary who is not reading from your documentation. Aviation learned, at real cost, that the gap between a system that exists and a system tested under failure is exactly where disaster gets in. Security is still largely grading itself on the first claim and calling it the second.
The difference is not effort. Patch programs take real work, and nobody disputes that. The difference is what the work is allowed to prove. Until a control has been forced to fail in front of the people meant to catch it, all anyone actually knows is that it was installed.
Key point
A patch report proves a control exists. It does not prove the control works under attack. The gap between them is where breaches live.
On Monday
If your SOC has never seen a live simulated exfiltration attempt, you do not know whether it will catch a real one.
The takeaway
Until a control has been forced to fail in front of the people meant to catch it, all anyone actually knows is that it was installed.
