After spending 48 hours with some of the world’s most skilled programmers (Hackers Conference), it was possible to make some generalizations about what’s on their minds. About half of the time blocks included a session on security, consistent with Zurich’s prediction that, by 2019, the cost of securing the Internet will exceed the value of the Internet (previous post).

What would it take to have real assurance that the systems we bring into our businesses and personal lives won’t be turned against us? Some of the participants suggested that we will need to start by simplifying the hardware. It would be better to sacrifice some processor performance to obtain a processor simple enough to understand. “Start with the 8051 and build out from there,” was one theme. Looking at the PDP-10 manual on saildart.org, one expert commented “The errata sheet for a modern processor is probably longer.” [The PDP-10 was a powerful mainframe of the 1960s.]

After that we would need much simpler operating systems that (1) were small enough to understand, and (2) provided true isolation among programs and protection against malicious code. Perhaps something like MULTICS. Participants agreed that Google’s Chrome OS was probably the best current desktop option from a security standpoint.

A Distributed Denial of Service (DDOS) attack to the tune of 400 Gbits/second was described as “trivial” and the result is that “nobody can be up if someone wants them down.” Are standalone Internet publishing businesses that depend on advertising overvalued as a result? The revenue stream can dwindle as readers install ad-blockers or turn their attention to Facebook. The revenue stream can be cut off any time by a DDOS attack.

Where there are challenges, of course, there is opportunity. Some folks noted that insurance companies writing computer security policies were taking wild guesses at the risk and that it should be possible for a company staffed with security/software experts to make money simultaneously insuring and analyzing/securing.

Nick P

The problem is indeed the combination of hardware, software architectures, and languages along with how they fight reliability and security at every turn. I did a write-up here along with links to lists of everything better in past or present:

So, there’s no excuse as far as “what to try?” There’s so many worked examples being ignored, even with C/Linux/BSD compatibility, that it’s not even funny. Mainstream IT security just don’t know or understand true INFOSEC. They’ve slowly pieced together important parts on hardware level at conferences like Black Hat over past years. However, much of it has been known, published, not learned, and not applied even when people that know publish it. So, there’s a huge knowledge transfer problem in the industry.

Nonetheless, the requirements are looking pretty clear. The mainstream solution will need compatibility with C, UNIX, and (other legacy stuff here). It will need to protect fundamental structures such as stacks, pointers, buffers, and so on. It needs hardware enforcement of leak prevention w/ memory isolation or crypto. It probably needs to be done at compiler and OS level with few modifications. The methods must be able to protect all software, including firmware and drivers. Good example is CHERI processor. Similar tech, scaled down, must be applied to microcontrollers so device software can be protected. All together, using academically and industrially proven techniques for the above with mainstream hardware will *dramatically* improve our baseline far as code injection and leaks.

Simultaneously, we need to keep doing clean slate re-designs that start fresh to eliminate the bad and facilitate the good as much as possible. SAFE crash-safe.org) is a good example of this. CPU’s accelerating Haskell, Ocaml, Go, Rust, Ada, etc are another example where they can be used for appliances or cloud-style workloads with regular processor doing management/virtualization/networking. Many options.

Will they apply proven techniques [finally]? Don’t know. I’m not betting on it outside a niche. However, we need to at least keep getting the message across to hopefully get results. Hope engineers in Zurich discover some of the stuff I linked to although some specifics have been superceeded by even better stuff now. Stuff that’s also being ignored… (sighs)