He&#x27;s still not getting it or fully recommending it any more than most have. The funny thing is that I recently read a 150 page interview with one of founders of INFOSEC, Dr Schell, that showed his employer was the same way: ignored &quot;COMPUSEC&quot; as useless in favor of &quot;COMSEC&quot; solutions to all security problems. Schell, Karger, and Anderson&#x27;s tiger teams smashed every mainframe and crypto using system put in front of them due to hardware and software bugs. They bypassed it.<p>Like Schell and Karger said for <i>30 years</i>, what we need is to start deploying high-assurance security practices, protocols, systems, methods... everything that&#x27;s proven to get the job done in various ways. We need them deployed pervasively. More private protocols and encryption by default, too, but who gives a shit if it runs on systems so insecure it doesn&#x27;t need backdoors?<p>Let&#x27;s go back to 1960&#x27;s moving toward the 70&#x27;s and 80&#x27;s on hardware stuff. Burroughs stuff was tagged so everything in memory was code or data, pointers protected, arrays bounds-checked, arguments checked on function calls, and OS tried to isolate apps from each other. Some LISP machines had GC&#x27;s for memory management. System&#x2F;38 had capability-security &amp; built-in database. Solo had safe concurrency at OS level. One had read-only firmware you couldn&#x27;t change without physically moving it with a nucleus that handle protected functions that OS&#x27;s built on. Two implemented a secure, Ada runtime that enforced the language&#x27;s safety properties. SAFE (crash-safe.org), Cambridge&#x27;s CHERI, and Sandia&#x27;s SSP&#x2F;Score processors follow these traditions.<p>Now let&#x27;s look at how Schell et al said to do assurance. Precise, math&#x2F;flowcharts&#x2F;whatever description of functional and security requirements to avoid ambiguities &amp; resulting vulnerabilities. Similar for design with attention to simplicity. Implementation in safest language you can with simpler subset and style easy to analyze. Every module proven to match a requirement&#x2F;spec so no subversion (well, a start on it...). Strict modularity, layering, and interface checks all over the place. Success <i>and failure</i> states modeled then shown to follow a precise, security policy. If you can&#x27;t state it precisely, then you can&#x27;t secure it because you don&#x27;t know what security means for you. Code review, tests of each function, formal proofs if possible, static analysis if possible, <i>covert channel analysis</i> of info flows, configuration management that <i>assumes malicious developers</i>, source to object code verification, trusted distribution of HW&#x2F;SW to customers, onsite verification&#x2F;generation from source, and configuration guidance. All of this independently verified by at least one set of professionals that know what they&#x27;re doing.<p>That was security in 1970&#x27;s-1980&#x27;s. Far from red tape some here claim, <i>every method above</i> was proven by researchers, field users, and pentesters to catch serious problems. The only dispute was what caught most and where to spend most money. Even those questions had decent answers. Well, plus specific design and modeling decisions but INFOSEC was in infancy &amp; that was evolving. I&#x27;m talking assurance activities: getting it done right whatever it is.  Fast forward today to find that all the problems Schell, Karger, etc predicted have happened and consistently in systems that don&#x27;t use those methods whereas systems that do avoid many more problems.<p>So, here&#x27;s the solution: raise assurance of our systems across the board using methods that go back to <i>1961</i>. That&#x27;s right, Burroughs engineers were doing a better job on security before that was even a thing just trying to improve reliability. This is 2016. We have better specs, better languages, better static analysis, easier formal tools, automated test generation, tons of sample code, fast dev machines... you name it. There&#x27;s no excuse, outside willful ignorance or apathy, for security-focused developers (esp in FOSS) to not use everything at their disposal that&#x27;s <i>proven to work</i> at reducing risk. Even less excuse for the stuff they make to <i>still</i> be less secure than tech from the friggin 60&#x27;s and 70&#x27;s.<p>Shout out to the exceptions that are trying to do it right. Groups like GenodeOS, Dresden, NICTA&#x2F;OKL4, Carlisle&#x27;s IRONSIDES DNS, Bernstein&#x27;s stuff, Galois, JX OS, ETH, INRIA, Secure64, Sentinel HYDRA (minus bodacion crap lol), Combex, and even NativeClient since they knocked off OP browser. Enough stuff like this and NSA will be begging us to ban INFOSEC books and shit since their info will dry up haha.