If they secure the hardware, that was known true as of early 1990's in VAX VMM. The only thing they couldn't eradicate was the timing channels in CPU's (esp cac

If they secure the hardware, that was known true as of early 1990's in VAX VMM. The only thing they couldn't eradicate was the timing channels in CPU's (esp caches) and system. They could just minimize bandwidth per TCSEC certification requirements. Stopping leaks had negative impacts on performance, though. They found plenty in the Intel processors later calling for making them leak-proof. Physical partitioning with optical connections is still best. Add TEMPEST shielding and power filtering if on high end. https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A-retrospective-on-the-VAX-VMM-security-kernel.pdf http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A... https://ieeexplore.ieee.org/document/213271 https://ieeexplore.ieee.org/document/213271 https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653... Industry and hackers just ignored this stuff for different reasons. The TCSEC certification, despite its problems, cause those along with all kinds of vulnerabilities by forcing systematic design and evaluation with methods proven to get the job done. NSA pentesters shredded most commercial products during evaluation. Today's still do for lots of F/OSS, too. The B3/A1, or high-assurance, systems took 2-5 years of pentesting with hardly any issues found. Details were published in conferences and products marketed. Aside from formal verification, only apathy explains security-focused folks totally ignoring all that outside CompSci which often cites it. What's causing the problem Jessie Frazel speculates about is merely that people running companies are incentivized to not give a damn in all kinds of ways. That includes adding insecure features to drive sales (mgmt bonus), cutting or ignoring security along with other costs (mgmt bonus), and no liability for damage that happens (externalities). The solution is, like TCSEC or DO-178C, carefully-designed regulations that force them to use known-good methods to knock out preventable problems. If they don't, the fines are higher than the cost of preventing them. That and/or liability in court for anything they could afford to use. Obviously, we might make provisions for smaller businesses that had less money for consultations. A lot of what we see in the marketplace, though, is avoidable with almost no effort. Free guides experts keep up to date on the basics might constitute the minimum with liability going up based on what resources they had available to do more. Reusable solutions and solution providers would show up to make it easier like they did for both TCSEC and DO-178C (still do for it). There's also existing offerings that are more secure-by-default which can be extended. On native side, you have stuff like OpenBSD, lwan web server, and TrustDNS in Rust. Even PHP has Airship CMS to help people throw web apps together with fewer problems. These companies will come around when they're forced to come around with the threat CEO's, project managers, and others will loose their money and/or position for not having security. Before that, they'll try to bribe, argue in court, bullshit, and so on. There will be some fight to get there. Lots of improvements such as no telnet on routers can come with almost no money spent. We might make progress by just reminding decision makers during those battles how inexpensive certain improvements really are vs the regulatory and legal actions.