back
2 comments
Why don't you drive a different randomised route to and from work every day and keep a log of cars you keep recognising in the rear view mirror, to detect government/foreign intelligence spying on you?

Or: why doesn't your car have an FIA compliant roll cage, a fire extinguishing system and six point harnesses?

Same answer: for you (and 99.9% of us), the costs outweigh the benefits.

The cost was nearly free for the basic protections. High-assurance design or components applied in otherwise commercial. We call this medium assurance but it's quite effective in practice. Even high-assurance projects like LOCK program said A1-class requirements only added around 30-40% to the cost of otherwise solid, development process. That's not bad for software that should rarely fail, get hacked, or be unrecoverable. I'd pay $150 for Windows instead of $100 or so. :)

Meanwhile, methods like Cleanroom and Eiffel showed great reductions in defects and problems while around same cost and time to market due to reduced debugging. Sometimes faster or cheaper slightly. Sometimes slightly more cost or time. Not much of a difference and low technical debt meant it got cheaper to improve over time.

So, your argument might apply if we're talking keeping legacy software at full speed on cheapest hardware with zero modifications. That really puts high-assurance in a box. Yet, if you're talking dramatically improving assurance of isolation or recovery at the least, then you can do it for a significant, but not heavy, additional cost.

And remember much of those exorbitant costs came from straight-up inventing the stuff on the spot. Proven examples to draw from in the literature, including full designs, should drop that many fold. GEMSOS was $15 million over 2-5 years. seL4 was about $5 million over 2-4. A handful of academics put together Muen in SPARK pretty quickly so maybe a few hundred K to a million there. See how the costs drop as we do similar jobs with improved tools and prior examples?

That's hard to say. I need to re-research it and write another essay on it using info I've learned recently. Here's a few issues:

- High-assurance is a barely developed field due to neglect. This means each new problem is essentially a R&D problem then an engineering problem. That increases cost and risk while slowing things down a bit. Good news is there's examples of many kinds of things to work with out of both proprietary and CompSci (mainly) with almost nothing out of FOSS despite them being attracted to interesting, challenging problems. Weird but that's the spread.

- High-assurance applies rigorous techniques to systematically eliminate problems in requirements, design, code, deployment and maintenance. The extra care increases both upfront investment and time-to-market. The latter is often critical as whoever has more features at any given point gets more market share and profit. That high-assurance delays to get it right the first time is an unforgivable sin in capitalist market.

- A follow-up here, identified by a founder of INFOSEC (Schell), is that businesses make more money on broken software. They get market share by not charging too much plus adding features. So, that means they need to find minimal amount of features to add at minimal labor cost. They keep customers with lock-in, which neglects quality automatically. Common to charge for updates and fixes delivered regularly in a way that's good for financial reports. Schell reported that non-IT industry he met with was aware of the game early where they said IT industry knew about his and other methods for robust software, that they worked, and refused to apply them to continously charge for broken software. A true conspiracy that became the default as high-assurance was forgotten, everyone grew up with shit software, and everyone [wrongly] believes it's inevitable rather than intentional.

- Demand is a huge problem. Most people blame software makers... which admittedly conspire... yet users will rarely buy secure stuff or even higher quality stuff. Any HN reader knows how consumers do economics and most businesses do IT. If they don't give a shit, then the supply side shouldn't per capitalism. They want insecure OS's running with no safety checks in CPU supporting insecure peripherals/apps and nearly-backdoored wireless standards? Well, you better provide it or you make no money. FOSS has similar problem for popularity or uptake. There's a niche that does higher-security stuff, mostly in defense but not all. Yet, higher cost plus abysmally low volume = very high unit prices or OEM licenses. It's like a trap. Worst, another conspiracy Schell's industry people noticed early on was mainstream "security" vendors buy up high-assurance vendors, then eliminate or water down their offerings. Might be incidental or nefarious but it's a real effect.

- Walker's Computer Security Initiative, along with Schell's work, countered all of this to invent INFOSEC field, create standards, incentivize them, improve mainstream, and bring high-assurance market up. Bell, of Bell-LaPadula, describes in a paper that NSA killed it by competing with them directly w/ government solutions and reneging on all promises of longevity & pay. Post-Snowden, a dumb move or intentional sabotage? Still not sure but NSA is real obstacle. EAL6/7 products still considered munitions for export although maybe not enforced. Government keeps steady development of high assurance (Type 1 especially) for use by military and defense contractors but bans us from using it. They're steady obstacle, esp NSA and DOD but DARPA & NSF a helpful neutrals.

- Worst one is ignorance and apathy. You'll see me be harsh on security industry here for a reason: they don't know any of this shit or even what high-assurance is mostly. It's like CompSci, high-assurance, defense, mainstream INFOSEC, and common IT are all silo'd from each other with little knowledge going across. Tell INFOSEC or IT people about inexpensive methods for robust or secure software gets you ignored. They don't apply almost anything outside code review and testing despite empirical evidence backing each method in high-assurance. Not sure of the solution there but this really hurts us that almost nobody does high assurance. Especially FOSS given its free labor.

So, there's some of the obstacles to high-assurance security getting more adoption. Good news is there's steadily companies appearing to do it and academics dumping their work into companies or FOSS releases. Stuff to build on. Occasionally it happens like with Chrome being a variant of OP Web Browser w/ lower security for faster speed, Blackberry using QNX (medium assurance) for Playbook, OKL4 on mobile phones, Paxos in the distributed systems, Bernstein's NaCl getting more adoption, GenodeOS getting more desktop ready, and so on. Little outliers showing what's possible. Not much else, though, due to strong obstacles in every community even when high-assurance is easy or fairly cost-effective. Human nature I guess...