@wendynather@infosec.exchange I've never tried quite that. I have worked on securing what AT&T called "operational support systems" (OSS), the many computers that tend and feed the phone switches, plus the so-called "adjunct processors" that help the actual switches. Let me put it like this: it's a nightmare. None of these systems were built for today's environment, and they can't easily be upgraded. And if you tried to reimplement them, you'd definitely introduce far more bugs, including security bugs, than you removed. OSSes do things like associating a physical wire or fiber with a "trunk" to another switch. How many OSSes do you think AT&T has? Your guess is almost certainly too low. And adjunct processors? Suppose you dial an 800 (internationally a "free phone") number. That has to get translated to an actual phone number, and appropriate billing stuff handled. That is *not* done by the switch; rather, the switch does (in effect) an RPC call to the adjunct processor, which does the hard stuff (including the database lookup) and returns the answer to the switch. One last thought: back in the 1990s, I used to say that the Internet was becoming the data equivalent of the phone network. I no longer say "is becoming"—it is. Build your phone network lately, including what is known as "outside plant", i.e., the wires on poles or in conduits? Build your own high-capacity, production-ready switch? No, phone switching is not done today the way it was done when I joined AT&T in 1982, but apart from the fact that a lot of the complexity is inherent to the problem, you still have to interoperate with legacy gear, unless you're also building your own handsets, etc. (During a meeting in, I think, 1996, on how to do a completely "greenfield" design for a new phone switch, I completely blew a Bellhead's mind by suggesting that 800 numbers be implemented as a distributed database and cryptographically signed reverse-charge tokens…)