4 ms·

The base mindset around software development, particularly at the lowest levels, needs to change to put security as the #1 priority. Far too many vulnerabilitie

by titzer 5y ago

The base mindset around software development, particularly at the lowest levels, needs to change to put security as the #1 priority. Far too many vulnerabilities are due to use of unsafe languages and features. While there are holes at all layers that lead to these types of attacks, as a runtime systems and language/compiler person, it's clear to me that unsafe languages should be abandoned, even if it costs a handful of percent of performance. The societal costs are just too great.

thegagne 5y ago
Not just software development, much more of the responsibility lays at the sysadmin/network/firewall layer, and even more at the management layer. Networks need to move to zero trust models, sure, but companies need to evaluate the risks of all the systems and processes that they rely on. The problem is it’s too easy to accept the risks or downplay them, while the work to get them addressed is costly.
dijit 5y ago
Lots to unpack here, and I'm a huge fan of memory safe languages, but honestly it's quite misguided to assume that security can ever be number 1; Security isn't boolean, and the closer to "security = 1" you get the more non-functional the system. It's always going to be a tradeoff between doing useful things and being secure. I would agree that we need to shift the bar closer to 1, but absolute security is impossible without the world closing down. w.r.t unsafe languages: it's not even possible to instrument and operate hardware in a "safe" way, even rust which is rather low level needs to be wrapped in unsafe in order to interact with hardware. I believe we need to be better at: Detection, mitigation, response -- all things traditionally sysadmins dealt with. But our industry assumes that sysadmins need not apply.
- titzer 5y ago
  It's still the case that two thirds of critical CVEs are due to memory safety errors. That ratio has held constant for several decades. Those CVEs aren't in hardware drivers, but in mundane things like JPEG decoders and mail processing programs. That is directly due to them being implemented in unsafe languages. > Security isn't boolean, and the closer to "security = 1" you get the more non-functional the system. Security isn't one-dimensional. Security can be phrased in functional requirements like "does not allow remote code execution attacks", which is of course a boolean requirement. You can slice that finer and finer such as "does not allow remote execution attacks through X, Y, or Z mechanisms" and start adding other, higher-level requirements such as "does not leak user data through APIs", etc. Security isn't boolean, but it is absolutely chock-full of boolean requirements one can pose. > I believe we need to be better at: Detection, mitigation, response -- all things traditionally sysadmins dealt with. I don't disagree with that, but this is the last-line-of-defense, the-horse-has-left-the-barn stage, which is basically admitting defeat because of how absolutely riddled with vulnerabilities existing software is.
- ratww 5y ago
  > w.r.t unsafe languages: it's not even possible to instrument and operate hardware in a "safe" way, even rust which is rather low level needs to be wrapped in unsafe in order to interact with hardware. Like you just said: security doesn't have to be boolean. Using more secure languages doesn't mean we have to completely banish every occurrence of unsafe in Rust. It just means we should avoid languages that force even business logic to be written using pointer arithmetic.
the8472 5y ago
I don't consider "remote IT management" (outsourcing) software to sit at the lowest levels. They're commercial solutions developed solely for commercial purposes. This isn't some ancient, underfunded open source library, this is people getting what they're actually paying for.

by titzer 5y ago

thegagne 5y ago

Not just software development, much more of the responsibility lays at the sysadmin/network/firewall layer, and even more at the management layer. Networks need to move to zero trust models, sure, but companies need to evaluate the risks of all the systems and processes that they rely on. The problem is it’s too easy to accept the risks or downplay them, while the work to get them addressed is costly.

dijit 5y ago

Lots to unpack here, and I'm a huge fan of memory safe languages, but honestly it's quite misguided to assume that security can ever be number 1; Security isn't boolean, and the closer to "security = 1" you get the more non-functional the system. It's always going to be a tradeoff between doing useful things and being secure. I would agree that we need to shift the bar closer to 1, but absolute security is impossible without the world closing down. w.r.t unsafe languages: it's not even possible to instrument and operate hardware in a "safe" way, even rust which is rather low level needs to be wrapped in unsafe in order to interact with hardware. I believe we need to be better at: Detection, mitigation, response -- all things traditionally sysadmins dealt with. But our industry assumes that sysadmins need not apply.

titzer 5y ago
It's still the case that two thirds of critical CVEs are due to memory safety errors. That ratio has held constant for several decades. Those CVEs aren't in hardware drivers, but in mundane things like JPEG decoders and mail processing programs. That is directly due to them being implemented in unsafe languages. > Security isn't boolean, and the closer to "security = 1" you get the more non-functional the system. Security isn't one-dimensional. Security can be phrased in functional requirements like "does not allow remote code execution attacks", which is of course a boolean requirement. You can slice that finer and finer such as "does not allow remote execution attacks through X, Y, or Z mechanisms" and start adding other, higher-level requirements such as "does not leak user data through APIs", etc. Security isn't boolean, but it is absolutely chock-full of boolean requirements one can pose. > I believe we need to be better at: Detection, mitigation, response -- all things traditionally sysadmins dealt with. I don't disagree with that, but this is the last-line-of-defense, the-horse-has-left-the-barn stage, which is basically admitting defeat because of how absolutely riddled with vulnerabilities existing software is.
ratww 5y ago
> w.r.t unsafe languages: it's not even possible to instrument and operate hardware in a "safe" way, even rust which is rather low level needs to be wrapped in unsafe in order to interact with hardware. Like you just said: security doesn't have to be boolean. Using more secure languages doesn't mean we have to completely banish every occurrence of unsafe in Rust. It just means we should avoid languages that force even business logic to be written using pointer arithmetic.

the8472 5y ago

I don't consider "remote IT management" (outsourcing) software to sit at the lowest levels. They're commercial solutions developed solely for commercial purposes. This isn't some ancient, underfunded open source library, this is people getting what they're actually paying for.