Improve Your Security By Talking About Gardening
I am convinced that banging on and on about warfare is hurting our ability to make pragmatic, cultural changes that protect our software and our organisations.
It’s dangerous to just accept metaphors as a way of describing the world. In many cases, that act of description changes the way you see the world — it is performative. I’m not even talking about using inclusive language, although that’s important too, I’m just talking about whether or not a particular metaphor encourages people to think about the right things at the right time.
Early on in my tech career, much of the things I learned about security were described to me in terms of warfare. I attended developer talks with Sun Tzu quotes, learned what a DMZ is for, and heard the value of threat modelling is described as “knowing your enemy”.
I think gardening is a better metaphor. Not only is it more accessible (let’s face it, the IT consultant with a camo laptop case knows next to nothing about how to conduct warfare), but it emphasises a few things that I think are missing from the military analogy.
Obviously this isn’t true for every context, maybe in your context warfare (or something totally different) works better — but I think it works better for many of the organisations I’ve found myself in, including government teams working on regular citizen-facing services.
The rest of this post is a hodge podge list of ways in which it is a more useful metaphor than warfare, accompanied by some photographs I like.
It emphasises the nice things you want to build.
When you are gardening, you might need to go “on the offensive” now and then. For example, weeding, or putting down slug repellant.
But it’s really clear why you want to do that. You put down slug repellant because you want nice cabbages, you pull up the weeds before they grow tall to give the geraniums a chance to grow.
At no point does it become an all out existential conflict against slugs or dandelions. States become involved in long, moral, tit for tat conflicts against each other that sometimes lead to war.
The notion of a “total war” on slugs would be absurd in a gardening setting. Would you salt the flowerbeds and concrete over the lawn to stop the slugs? Obviously not. Because stopping the slugs doesn’t ever become a top level moral priority, protecting the veg patch is.
In the same way, your security should be obsessively focussing on the nice things you want to build and maintain. You lock down access so that people feel safe giving you their data, you rate limit the API so that your human users can have a smoother experience.
The enemy is unknown.
Gardeners might not even know who the enemy is. You see something has been nibbling at the leaves — is it a caterpillar? Is it a slug? You can ask other gardeners or read books to see if the pattern looks familiar to them. Sometimes it will be, sometimes it won’t.
There is no geneva convention requiring the aphids to wear a uniform, and you can’t even track down who manufactured and sold the weapons.
This is even a problem in actual cyber warfare. Sean Lawson criticises the use of military analogies in state-on-state cyber attacks, at one point drawing attention to what he calls “a crisis of cause and effect”.
The attacker is anonymous. You can’t credibly threaten them, you will struggle to reason too much about their individual motives. You can reason in broad terms to try and figure out how much trouble they will go to to get at your database, but that’s about it. In the same way, you might reason that slugs love eating basil, so you might need some extra slug proof defences around the basil, but it would be pointless to try and second guess the strategies and behaviour of individual slugs.
The enemy is impersonal.
This isn’t always true — but many of the things you are defending against really have nothing to do with you at all. Nobody cares that it is your database, they just care that you left it exposed with a default password.
Many of the threats you want to reason about are purely transactional, or maybe even random. The script kiddie as an archetype is well known. They really don’t care whether they’re targeting a bank, a government, or the webpage for the local running club: They just care that it’s deployed on a version of wordpress that they know an exploit for. They might have scanned the web at random to find your website, and you just got unlucky to be an early hit.
If a gardener started by trying to think about which animals might be personally motivated to ruin their flowerbed, that would be pointless. The insects don’t know or care that it is your flowerbed, they just care that its made of flowers and they were able to easily crawl to it.
The enemy is you.
Gardeners break their own gardens all the time. Over-watering, under-watering, accidentally stepping on a plant, using a pot that’s too small, getting the leaves wet before a scorching hot day, etc.
Software teams do this too. We migrate the wrong database, lose access to an important account, introduce a defect, forget to test a feature with a screen reader, etc.
It is absolutely not the case that everyone within the garden (or team) can be trusted. As a matter of historical truth, I have done far more damage to my users and their goals than any cyber attacker has!
Gardeners and software teams need to learn to live with that (the garden won’t always look pristine, and that’s ok), introduce antifragility to recover from it (plant multiple types of thing in the veg patch), introduce checks and balances to remind themselves to do the right thing (check the weather and write up a watering schedule).
Sometimes, the enemy isn’t an enemy at all.
I’ve already pointed out that animals aren’t out to get you, but it’s more than that — their entire status as a threat or a welcome presence depends on how you build your garden.
Bees are good for your garden, but it will be incredibly annoying if they are always flying through the kitchen window. You can solve this by planting lots of bee friendly flowers a little distance away from the kitchen window.
Foxes might trample the flowers, but if you make the flowers a little bit harder to get to, and make other parts of the garden more attractive for them to spend time in at night, then they might become completely benign visitors.
The problem isn’t the presence of the animals at all, it’s just the environment they’re in. In the same way, your actual users might cause a nuisance if you build things wrong.
Have you got a long running transaction that makes your users refresh the page a bunch of times in frustration and increase server load? It’s not their fault, it’s just about how you designed the website.
Experimentation is a good idea.
Experimentation obviously exists in a military setting, but that’s fairly dark and it would be hard to describe it as unambigously a good thing. The consequences of decisions in warfare are, more often than not, tragic.
In a gardening setting, and in the majority of application security settings, you’ve got to try things out to know if they work. I’ve been in sitatuations where we’ve seen a particular type of attack, so we study it and try out a new way to identify it, wait for it to happen again then add another layer, and so on.
We would never have got it right if we just guessed at what we needed up front. Our context was a little bit unique, so different things had different effects to any previous context we had been in.
Gardeners also do this. You start out with a basic approach that lots of people seem to recommend, then see what happens. If it doesn’t work, you start to think about some of the other variables. Maybe your soil has a particularly high clay content; maybe the elevation leaves the plant exposed to the wind.
You keep researching, you ask questions of other enthusiasts, and you try something new. You might even plant multiple plants in slightly different conditions to see what works best.
Little and often usually makes things work better.
This article by Jim Gumbley was transformative for my ability to make pragmatic change to the behaviour of teams around cyber security. Jim makes a compelling case for starting simple and expanding your threat model over time.
I’ve seen so many teams get lost trying to reason about all threats across their whole product, but when we starting talking about the threats to a particular flow, they generated a huge amount of useful data that allowed us to proactively invest in security much earlier than we otherwise could.
This is also what gardeners do. A bit of weeding one day, a bit of pruning the next, tidying up the tool shed now and then. Gardens are living, organic, complex systems (just like teams), and as such your investment in them needs to be continuous.
Additionally, monumental changes can actually be a bad thing. If you rip out all of the plants and soil from your garden to start again with something new, you will lose some of the nutrients built up over centuries, you’ll lose the organic serendipity that formed (the tree grew in that patch 40 years ago because the light suited it so well). If you rip up your software and your processes overnight and replace it with a cookie-cutter solution, you end up with a complexity that people don’t understand, and a set of processes that were not formed according to the needs and preferences of the actual humans that are expected to carry them out.
Final caveats
- Your context may very. Obviously. Pick a metaphor that works for you and what you are doing.
- I’m not actually a gardener! I do, however, love reading and listening to gardening content. Gardeners employ a mixture of old wisdom, new ideas, experimentation and enthusiasm to build nice things in a way I find to be completely infectious.
