Compare commits


2 Commits

3 changed files with 114 additions and 2 deletions

View File

@ -26,7 +26,9 @@ pipeline:
# if the newswire has changed, publish the new one.
- |
cmp oldnewswire.txt public/newswire.txt || \
curl -s -H "Authorization: Bearer $MASTODON_SECRET" -F "status=$(cat public/newswire.txt)" \
curl -s -H "Authorization: Bearer $MASTODON_SECRET" \
-F "status=$(cat public/newswire.txt)" \
-F "content_type=text/markdown" \

View File

@ -0,0 +1,108 @@
title: Most breaches actually begin in corp
date: 2023-12-07
Readers of my blog will note that while I believe Rust is an excellent
tool for developers to leverage when building software, that there is
a disconnect between the developers leveraging Rust features to improve
their software and many of the advocates who talk about the language,
which I believe is counterproductive when it comes to Rust advocacy.
For example, I see [takes like these][linkedin] frequently, which generally
advocate that if *only* we adopted memory safe languages, we would solve
all security problems in computing forever:
> If it's estimated that writing in a memory safe language prevented
> 750 vulnerabilities (in just one codebase!) and IBM calculated [1]
> the average cost of a data breach is $4.45 million, that's over
> $3.3 *billion* saved by moving to memory safety.
Don't get me wrong: it sure would be nice to change to a memory safe
language and save $3.3 billion in losses, but in reality it's far
more complicated than that.
Every year, Verizon's security group releases a [Data Breaches
Investigation Report][dbir]. These reports are *fascinating*
to read, and I highly recommend giving them a read if you're
interested about the past year's notable data breaches and
how they actually happened.
What we learn from these reports is that, in general:
* Over 70% of data breaches actually involve a human element
instead of a software vulnerability, for example a phishing
attack or a misconfiguration of a service.
* Almost 50% of data breaches actually involve compromised
credentials, such as leaked OAuth tokens which did not
* Roughly 15% of data breaches have phishing as their root cause.
* Only 5% of data breaches actually come from exploitation of
a software vulnerability.
Don't get me wrong -- software vulnerabilities are bad and should be
fixed in an expedient manner, however, to circle back to the prior
example I quoted, if we are considering data breaches to have a price
tag of $4.45 million, and we are talking about 750 security incidents
in practice, then in reality only 38 of these incidents would have
the potential to have memory safety as their root cause, which is a
much smaller price tag of $169.1 million that could be attributed to
memory safety.
The point is not that we shouldn't refactor, or even rewrite software,
to improve its memory safety. But we should be honest about why we are
doing it. While memory safety *is* important, the real benefit in
doing this refactoring work is to improve the *clarity* of the underlying
software's technical design: technical constraints can be enforced using
Rust's trait system, for example -- a form of behavioral modeling.
By leveraging features such as traits to enforce behavioral correctness
of the code you are writing, you wind up having a much better
vulnerability posture *overall*, not just in the area of memory safety.
This is the reason why refactoring software to use code written in Rust
and other modern languages with these features is advantageous.
This is a far more interesting story than the talking points about
memory safety I hear. At this point, with features such as `FORTIFY`
and Address Sanitization, it is possible to address memory safety
defects without having to go to such lengths to refactor pre-existing
Features like ASan do not even have to carry significant runtime
performance penalties. To illustrate my point, Justine Tunney proposed
building a modified version of Alpine with ASan enabled in 2021 using
a production-tuned variant of [her ASan runtime included in her
Cosmopolitan libc project][cosmo-asan]. It was estimated that enabling
ASan in conjunction with this variant of her ASan runtime would only
result in a 3 to 5% performance reduction over code that did not have
ASan enabled. Adopting this work would have immediately derisked the
use of memory unsafe code in all packages as they would be built with
ASan by default.
And, of course, even with the borrow checker, and traits, and type
enforcement, and the other code verification features provided by the
Rust compiler, you still have `unsafe{}` blocks, and the Rust compiler
provides support for ASan as a mitigation for these blocks. So you
*still* really need ASan even in a memory safe world, because even when
you build such a thing with perfect memory safe abstractions over a
memory unsafe world, you really are still building on top of a memory
unsafe world.
The point here isn't that these abstractions are meaningless. They do
provide significant harm reduction when working with otherwise memory
unsafe interfaces, but even the most perfect abstraction is still, by
its very nature of being an abstraction, leaky. Instead, we should
recognize *why* Rust improves memory safety, and how the techniques
which improve memory safety can also be used to enforce elements of
the underlying software's design at compile time. This is a much
better story than the handwaving I usually see about memory safety
from advocates.

View File

@ -1,5 +1,7 @@
{{- range first 1 (where .Site.RegularPages "Section" "blog") -}}
{{ .Title }}
{{ .Title }}:
> {{ .Summary }}
{{ .Permalink }}
{{- end -}}