Skip to main content

Are we Outrunning the Bear?

Or wasting our time trying?

Amrit's latest post has me thinking about what's been one of our brew pub round table topics lately.

There is an old joke about the hikers who cross paths with a grizzly bear. The first hiker immediately takes off his hiking boots and puts on his running shoes.

The second hiker: “why are you doing that - you can’t out run the bear”.

First hiker: “I don’t need to out run the bear, I only need to outrun you”.

In a sense, if hacking today is focused on profit rather than challenge or ego, as perhaps it once was, then the miscreants will likely follow the least cost or least resistance path to their goal (marketable data, marketable botnets). If that is true, our goal needs to be to outrun the other hikers, not the bear.

Fortunately there appears to be a limitless supply of slow hikers (clueless developers, sysadmins, security people and their leadership, or more likely - competent developers, sysadmins and security people led astray by clueless leadership).

We need to focus on out running them, not the bear.


  1. I think this reassembles the old saying: In the land of the blind, the one-eyed man is king.

    In other words, you don't have to have the whole package as long as you have more than your competition.

    - Unomi -

  2. I'm also reminded of the axiom that the amount of protection should be justified by what's being protected. Grandma's recipes don't need quantum encryption (if it works right).

    In terms of outrunning the other hikers, my only concern is that there are a LOT of bears out there, and some of them are mechanical. Or zombies.

    And if zombie robot bears doesn't scare you, then I don't know what would.

  3. One problem with the bear parable is that not all hikers are created alike. The bear may chase a fast but big and tasty hiker even if the scrawny unappetizing hiker is easier to catch. It doesn't do Microsoft much good to be faster than Joe's Bar & Auto Lube, because the targets aren't equally attractive.

    Another problem with the bear analogy is that my security depends partly on how well other people secure their systems. Botnets, phishing sites, and worms work partly because lots of other people have crummy security. To extend the analogy, the bear chasing us is a vampire bear: once it catches someone, it turns that person into another vampire bear. Being faster than the other hiker just means you'll soon have to outrun two vampire bears instead of one.

    In security, I think it's better if everyone is faster than the bear.

  4. I'd agree that it would be better if all the hikers were faster than the bear, but they are not, and probably never will be.

    I'm thinking of another analogy, this time with an addict and a $20 fix. The addict needs the money for a fix and plans a grocery store robbery to obtain the fix. On the way to the planned robbery, the addict sees $20 on the sidewalk. What will the addict do?

    The bear only runs fast enough to catch a suitable hiker, and then, upon having caught the hiker, is distracted by the catch sufficiently that the other hikers can trot along quite merrily, until of course the next bear comes along.

    With automated (zombie) attacks, there are many bears, true enough, but because the attacks are zombied, they are also predictable (after a few successful attacks).

    In the particular case of vampire bears, a successful defense against one will prove to be a successful defense against all vampire bears of the same species. So it really is a single threat.


Post a Comment

Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …