Our Influences: Dan Geer

Back in the early 2000s, before podcasts were a thing, I drove around in a new, but very basic Kia Spectra, with manual crank-up windows and no power door locks. It got me where I needed to go. Something like this:

As Spartan as it was, it had a key feature that I absolutely loved: an auxiliary port to plug in the headphone jack of my Apple iPod Nano, that looked just like this one, about 1 inch by 1 inch square, light blue, with all solid state memory (which was amazing at that time):

For the modern reader, please keep in mind that podcasts were years away at this point in history. But being the nerd that I was, I had managed to find the .mp3 files for several cybersecurity conference talks, and I loaded them onto my iPod Nano and rotated through them every week on my commute to and from work. I had a handful of Dan Geer’s talks, which were some of my favorites. Through this humble channel, Dan’s thinking began to radically shape mine.

I should note, that if you’ve ever listened to Dan talk, you probably pressed pause, rewound a bit, and then pressed play a second time (or third, or fourth) in order to fully grasp what he said. He has a lot of signal in the words he chooses, but his eloquence is on another level. I’ve heard that Dan’s father was a Southern Baptist preacher, which combined with Dan’s extensive time at both Harvard and MIT (where he invented Kerberos that virtually every organization on the planet has used at some point), makes for a very interesting delivery that is only accentuated by the lamb-chop sideburns.

Dan’s famous for many things. The creation of Kerberos, of course, the X Window System, and also his letter about monocultures in cybersecurity that got him fired from the early security powerhouse company: @stake. He even opened the first information security consulting firm on Wall Street. But if there’s one thing he should be remembered for, it’s his influence on our industry to shift away from preventing security failures to making recovery from security failures cheap, fast, and easy. Twenty years ago, as I write this, the security industry was myopic towards prevention of security problems. Firewalls, strong authentication, patching, hardening configurations … but there was virtually zero emphasis on detecting security failures and quickly recovering from them.

In one talk (that is long gone from my iPod Nano, which is also long gone, and I unfortunately cannot dig it up exactly, but you’ll see Dan has rhymed and repeated this over the years since), Dan Geer compared these two phenomenons to “knobs” for cybersecurity. You can dial both in to achieve a strong posture and security program. In his academic way, he stated them as:

1. Mean Time Between Failures heading to infinity
2. Mean Time To Repair or Recover heading to zero

For those of us who don’t like reading academic papers written in LaTex, what Dan means is:

1. Prevention (i.e. that if the amount of time between security problems is nearly infinite, then you’ve done a great job preventing failures)
2. Response (i.e. that if you can quickly recover from a security failure to the point that the failure becomes meaningless, then you’ve done a great job recovering)

Not ironically, you see this captured in NIST and other frameworks, too: Prevent, Detect, Respond. My previous posts on Left and Right of Boom are a timeline representation of this same concept that I learned from Dan Geer.

#Mean Time Between Failures

“MTBF” as it is often initialized in other engineering disciplines is typically the obsession of the immature security professional, who has not yet realized just how frequently computer security systems can be breached. It makes sense that we would hope we can eliminate every possibility of a bad guy wreacking our systems and confidential data. But the seasoned professional has a plan to address that failure.

#Mean Time To Repair

“MTTR” as Dan initializes it, and sometimes interchanges it with Mean Time To Recover (also MTTR), and our industry has adopted the MTTR to represent Mean Time To Respond, which is similar, but slightly different (and often not universally agreed upon by people within the security industry–topic for another day).

#Algorithms for Offense & Defense

When Dan was asked the question: “Over time, does automation help defense or offense more?” Dan’s answer sounds like a more eloquent version of something you could read right here on this blog:

If the answer over time is offense, then cybersecurity becomes more like nuclear deterrence, including that there are few precision weapons and that enforceable treaties are essential to our survival. If the answer is defense, then we should turn to algorithms to do what we cannot otherwise do, that is, to protect us from other algorithms.

In my red teaming days, which were over years before that quote was published, I was already influenced by Dan in this direction, hence my post explaining how I encouraged my red team to think in algorithms, which ultimately led to us building some very novel and highly automated private C2 and attack frameworks.

And from the launch of Wirespeed, we have focused on the idea that algorithms are crucial to response especially given the speed of adversaries and the choice between a well-understood algorithm and blackbox LLM approach.

#Choosing Prevention or Response as Primary Focus

When Dan was asked the question: “Do we steer by Mean Time Between Failure (MTBF) or Mean Time To Repair (MTTR) in Cybersecurity?” Dan answered:

Choosing Mean Time Between Failure (MTBF) as the core driver of cybersecurity assumes that vulnerabilities are sparse, not dense. If they are sparse, then the treasure spent finding them is well-spent so long as we are not deploying new vulnerabilities faster than we are eliminating old ones. If they are dense, then any treasure spent finding them is more than wasted; it is disinformation.

[Translation from Geer eloquence: It’s a waste of money to primarily focus on Preventing security problems, unless you are confident that there aren’t that many.]

Suppose we cannot answer whether vulnerabilities are sparse or dense. In that case, a Mean Time To Repair (MTTR) of zero (instant recovery) is more consistent with planning for maximal damage scenarios. The lesson under these circumstances is that the paramount security engineering design goal becomes no silent failure – not no failure but no silent failure – one cannot mitigate what one does not recognize is happening.

And that right there, is why Wirespeed exists. Because we have no confidence that security vulnerabilities (especially if we consider human behavior to be a vulnerability) are decreasing in number, therefore it’s paramount to be able to make the breach meaningless for the attacker, by detecting, responding, containing, and meeting the fullest definition of “repair” as quickly as possible.

And we can do it in seconds.

---

Want to know more about Wirespeed? Follow us on LinkedIn / X or join our mailing list.