On 8/3/24 19:05, Bill Bogstad wrote:
What you are basically saying is that we need to write software that
has essentially 0 bugs.
I'm saying we need to at least try.
The measure of success isn't that there are 0 bugs, it is that that we
are reducing the numbers of bugs. And at least eliminating the ones we
know about!
It isn't just "write software" but make decisions in designing larger
systems that make them inherently secure.
If the ops people discover the firewall has been off for a time, is that
an occasion to turn it back on, or to panic? If it is the latter, then
the firewall was a crutch and an excuse to build insecure stuff.
Enter the modern CSO. If s/he discovers the firewalls were off for a
week, that is an all out emergency. Because they are NOT just an extra
protection. Quick, turn them on, and start sifting through the damage.
Calm things down, so the CSO can get back to deciding among commercial
products that help keep track of what assets a company has, because it
is all so chaotic that there is no way of knowing from having *built* it.
I like a quite I recently ran across from Peter Gutmann:
Rule #1: Complexity of the enemy of security.
But these days "best practices" is to build such godawful complicated
systems that his rule must be perplexing to most people.
-kb
_______________________________________________
Discuss mailing list
Discuss@driftwood.blu.org
https://driftwood.blu.org/mailman/listinfo/discuss
