CLOUD INFRASTRUCTURE
Start with the base rate
Undersea cables break constantly. The global fault rate runs to well over a hundred incidents a year, and the overwhelming majority are mundane: fishing gear, anchors dragged in shallow water, seabed movement, and equipment reaching the end of its service life. Repair ships are dispatched, traffic reroutes, and most users never notice.
Any monitoring program that treats each fault as a potential attack will produce a flood of alerts, exhaust the team reading them, and be quietly ignored within a quarter. The useful question is never whether a cable failed. It is whether this failure looks like the ones that came before it.
What is actually observable
A provider operating on top of leased capacity does not see the cable. What is visible is the behaviour of paths crossing it, and that turns out to be sufficient for the questions worth asking.
- Latency structure. Every path has a characteristic distribution. A reroute onto a longer physical path shifts the floor of that distribution, and the floor is far harder to disguise than the average.
- Route churn. Announcements withdrawn and replaced across a short window describe reconvergence. The shape of the reconvergence says something about whether one segment failed or several did.
- Correlation across paths. Independent systems degrading simultaneously is the signal worth waking someone for. Independent failures are independent. Correlated ones have a common cause, and common causes are worth naming.
- Sequencing. Faults arriving in a pattern that is convenient for a specific traffic outcome deserve attention that a single fault does not.
The tell is correlation, not any single event
The distinction that matters operationally is between one thing breaking and several related things breaking in a way that concentrates traffic somewhere specific. The first is a Tuesday. The second is a question for a threat analyst, because forcing traffic onto a chosen path is the precondition for anything an adversary might want to do next.
This is why our telemetry correlates path behaviour across facilities rather than monitoring each region in isolation. A regional view of a single degraded path produces a ticket. A fleet view of three degraded paths that share a landing station produces an investigation.
What telemetry cannot tell you
Honesty about the limits matters more than the capability list.
Telemetry cannot establish intent. It cannot distinguish a deliberately dragged anchor from a careless one, and it cannot attribute. It observes that traffic which previously took one path now takes another, and that the change was or was not consistent with the failure pattern of accidental faults. Everything beyond that requires information that does not arrive over a network interface.
It also cannot prevent the physical event. No amount of monitoring keeps a cable intact.
The control that makes it academic
Which brings the discussion to where it always ends. The reason a rerouted path is tolerable is that everything crossing it is encrypted in transit, terminating inside an enclave, with keys held in hardware that never leaves our custody. An adversary who successfully forces traffic onto a path they observe collects ciphertext.
That is the actual defence. Route monitoring tells us when the topology changed and whether the change deserves scrutiny. Encryption is what makes the answer survivable either way. A program that invests heavily in the first while treating the second as optional has the priority inverted.
Practical guidance
- Baseline your paths before you need to. A latency distribution is only useful against history.
- Alert on correlation across independent paths, not on single-path degradation.
- Know which of your paths share a landing station. Diversity on a map is not diversity in the water.
- Encrypt every path by default, and hold the keys somewhere the transit provider cannot reach.