Security Analogies are usually Wrong

I have long believed that if someone makes an argument and uses an analogy, then the argument is often weak. But that’s just me!

This is why I usually roll my eyes when I hear statements like, “If [bridges|cars|airplanes] were built like software then…” because comparing physical items and software is just wrong. They are not the same thing, you cannot compare them.

That being said, I thought I would offer a counter-analogy.


If cars operated in an environment like the Internet, they would…

  • Be driven by people with little regard safe automobile operation.

  • Have their windshields shot out every 60 secs.

  • Once you have bullet-proof glass, the bad guys place nails at freeway off-ramps next to signs like, “free coffee this way”

    • and someone is always trying to steal your keys

    • and pull out your sparkplugs

    • and siphon your gas

  • Talking of gas, you fill up at a Shell station, only to realize the gas really isn’t gas, it’s vegetable oil and sand

  • Oh, that gas station isn’t a Shell station, it certainly looked like one, but they took your credit card details anyway

  • As this all goes on, you can’t see the adversary

  • And the adversaries are sharing new weapons with each other

And you thought you were going to work this morning!

Comments (30)

  1. My favorite analogy I bring up when engineers complain about the stability of software by saying that bridges rarely fall down whereas software fails on a constant basis:

    Engineers are never asked to build a car then 2 months later told it has to be able to travel under water and 2 months after that that it has to be able to go into space and also be ready the next week.

  2. Juanex says:

    Bad nerd joke, try to code better because

    jokes are not your best area.

  3. Adam says:

    Don’t forget, as you enter the station they install a remote control under your hood.  It doesn’t work very well, and often causes you to crash, but since they attack a lot of cars, they don’t care a lot.

  4. Vasu says:

    Very nice and very true!. Being a security guy, I have to say its sad that I didn’t make that counter analogy. I guess that’s why you work at MS 🙂

  5. nutzo says:


    don’t want to sound to stuborn, but:

    – you cannot run your own gas-station without certain certificates, even if you manage to fake these certificates, you will surely get cought sooner or later (if you mix sand with gas) -> analogy: on the Internet it is way too easy to counterfeit "secure" web pages.

    – automobiles are made dead-sure, it is not an  an option that you get BSOD during your ride with 100 mph, i.e. quality assurance/testing is way better/standardized compared to software engineering.

    – when buying spare parts (applications/plugins, whatever) for your car, you have two options, original (dead sure quality, for a bigger price) or produced by someone else (cheaper, quality MIGHT not be that good as the original, but still works). The choice is yours and either you choose, you still get a working car after replacement. Analogy: buy a software, you know absolutely sh*t about its quality. none. zero. doesn’t even matter if it’s from the "original" or a 3rd party supplier, it still can work badly.

    Quality assurance? Laugh my heads off.

    So pardon me Mike, but the analogy is better

    than you would think.


    a senior sw engineer

  6. I thought I would share Michael Howard’s recent blog on "Security Analogies are Wrong".  I agree…

  7. From a presentation by a security contractor on campus:

    1 bottle of beer on the wall, 1 bottle of…

  8. Bad security analogies are like cherry pits in chocolate.

    (The meaning of that bad analogy is left as an exercise for the reader – please don’t exercise here though.)

    Nutzo already went off-topic and took the analogy way too far (missing the entire point of Mike’s post), but somehow I am compelled to follow:  "Dead sure"?  Are you kidding?  Do you remember what American automobiles were like until they began to absorb Japanese lessons about quality?  They were crap, and they were dangerous.  And this was after almost a century of the industry’s existence.

    Also, "you cannot run your own gas station" is clearly false – hence the huge profitability in phishing.

  9. nutzo says:


    "Do you remember what American automobiles

    were like until they began to absorb Japanese

    lessons about quality? They were crap, and they were dangerous."

    So the industry all together improved.

    Do you see any improvement since the sixties?

    The only change I see is that are easier to use (even dummies can code now) -> analogy : again you don’t even need any license to proove that you are capable of develop/code (compared to automobiles, where I am quite sure that you cannot ‘release’ your own developed car without certain burocracy in your way).

    About quality change? Sorry to tell, but no major difference I see. Still no exact/proper/bulletproof standard (at least that I know of) around that makes you sure that starting from a set of requirements you end up with working (all the time, in all situations) sw (i.e. that is delivered to the customer).

    "Also, "you cannot run your own gas station" is clearly false – hence the huge profitability in phishing. "

    Well at least in the country where I live you cannot run your own gas-station without the proper certificates/papers/contracts with suppliers, etc. (thus you cannot "fake" a gas-station in our country -> thus you cannot have sand+gas filled into your tank).

  10. dave says:

    Security and robustness are easy.

    Except that no-one is willing to set the development schedule to accomodate the security/robustness requirements.

    Except that no-one is willing to set the pricing to accomodate the security/robustness requirements.

    Except that no-one is willing to deny feature requests to accomodate the security/robustness requirements.

  11. nobody says:

    When the environment (O/S) that software operates in is basically flawed and insecure, how can the software be anything else ? People use analogies so often because they’re limited in their ability to communicate thoughts with words, and hope to rely on preconceptions to make their point.

    We’re lucky when the masses can spell simple words correctly, much less express thoughts and concepts.

  12. Curphey says:

    If Cars Were Built Like Applications….

    70% of all cars would be built without following the original designs and blueprints. The other 30% would not have designs.

    Car design would assume that safety is a function of road design and that all drivers were considerate, sober and expert drivers.

    Cars would have no airbags, mirrors, seat belts, doors, roll-bars, side-impact bars, or locks, because no-one had asked for them. But they would all have at least six cup holders.

    Not all the components would be bolted together securely and many of them would not be built to tolerate even the slightest abuse.

    Safety tests would assume frontal impact only.  Cars would not be roll tested, or tested for stability in emergency maneuvers, brake effectiveness, side impact and resistance to theft.

    Many safety features originally included might be removed before the car was completed, because they might adversely impact performance.

    70% of all cars would be subject to monthly recalls to add major components left out of the initial production.  The other 30% wouldn’t be recalled, because no-one would sue anyway.

    The after-market for safety devices would include such useful products as training wheels, screen doors, elastic seatbelts and devices that would restrict the car’s top speed to 3mph, if found to be unsafe (which would be always).

    Useful safety could be found, but could only be custom retro-fitted, would take six months to fit and would cost more than the car itself.

    A DOT inspection would consist of counting the wheels and making recommendations on wheel quantity.

    Your only warning indicator would be large quantities of smoke and flame in the cab.

    You could only get insurance from one provider, it would be extremely expensive, require a duplicate DOT inspection, and you might still never be able to claim against the policy.

  13. Jeremy says:

    I don’t get the people who "haven’t seen a change", or claim that "70% of all cars would be subject to monthly recalls" where cars are software.  Maybe I’ve just been lucky, but I have not had any real software issues in years.  Have these people forgotten the blue screen days of Win 98 and NT 4?  How about the regularly scheduled reboot?

    OK, OK, I’ve downloaded a few free trials of software that were just junk, but all in all every application I now run on a regular basis is stable and does what it said it would do.

    As for security, of course I’ve paid for the "add-on" security of a firewall, virus protection and spyware removal.  I can usually spot a fishing email before I open it, and have never clicked on a link in one (except out of curiosity to see how well they remade the original site).  So, the everyday user should be a lot safer driving a mouse than a car.  If they do something stupid in either one they’ll probably end up paying with pain.

    I do understand that securing, for example a website, would be more difficult to do, but not impossible.  Besides isn’t a website more like an airplane? 😉

  14. pen says:

    Counterfactual conditionals are always true. That is, an implication (such as "if x then y") where the antecedent (in this case "x") is false will always be true.

    Uninteresting, perhaps, but true nonetheless.

    So if this is an example:

    If cars operated in an environment like the Internet, they would be driven by people with little regard safe automobile operation.

    Then, because cars are not operated in an environment like the Internet, the statement must be true.

    Instead of "Security Analogies are usually Wrong", I’m afraid security analogies are always true. Uninteresting, but true.

    And cars are frequently driven by people with little regard for safe automobile operation. But the truth value of the consequent is not relevant when the antecedent is false.

  15. Helium says:

    Are analogies wrong, or is it a common failing the of the person who expresses them to  poorly clarify the similarities to the less familiar subject? Almost all complex human communication is based on metaphore. All metaphore is flawed.

    "The fog entered the city like a cat."

    Did it scratch up the furniture and vomit on the carpet, or was it silent and creeping into the cribs of children to steal their breath?

    "This is not a pipe"

  16. Good points – what I don’t like is when people use analogies as the fundamental point of their argument. To me it means they have a crappy argument!

    Ceci n’est pas une pipe 🙂

  17. Gary G says:

    But nutzo, you are still missing the point.  No matter how dead-sure autos are built and tested, they only work properly when the roads also work properly and the gas stations also work properly.  If you drive in Iraq and there are roadside bombs every few miles, suddenly your well-designed car is a death trap.  Likewise, it’s hard for me to write and test software properly when bad (but smart) people are actively trying to make me fail.

  18. JB says:

    Most analogies are inherently flawed.  It’s sort of an apples and oranges situation.  While you can attempt to compare and contrast, the dissimilarities between the 2 disparate subjects can often cloud the message.  Such as Helium’s cat analogy; very well put.

  19. Web Resources

    [.NET Framework] GotDotNet CodeGallery

    Share, find, download and discuss evolving…

  20. In his entry "Security Analogies are Usually Wrong, Michael Howard does a bit of delving into the "software security by analogy" poing of view: I usually roll my eyes when I hear statements like, “If [bridges|cars|airplanes] were built

  21. After reading Alik Levin’s Security Language That Everyone Understands and Michael Howard’s Security