There are a couple of metaphors that tend to guide my thinking about the practice of security: ratchets and levers.
A ratchet is a kind of one-way gear, with angled teeth and a pawl that allows motion in one direction only. In the physical world we use ratchets to help lift or move heavy loads. Using a ratchet, we can overcome the massive inertia of a heavy object by breaking the movement down into small, easy, irreversible steps.
I think about ratchets when when I’m trying to improve some sub-optimal system. Organizations and systems have their own kinds of inertia, so sometimes it can be difficult or impossible to improve all in one go. So, I try to think: how can I break this improvement down into a series of ratchet-like steps? The key is that each step should be:
- Small, so that it can be accomplished quickly. Success builds on itself, so I prefer small steps with a high chance of success to big risky ones.
- Easy, so that there’s little or no organizational inertia to overcome.
- Irreversible, so that we can’t backslide between steps, and so that we can take breaks between steps.
A lever is the simplest sort of physical machine: just a bar and a pivot point. Levers amplify force: a small amount of force applied to the long end of the lever is multiplied at the short end. Using a lever lets us multiply our force, many times.
I think about leverage when I’m trying to prioritize security work. There always seems to be a massive backlog of potential security work, so how do we decide what’s most important? For me, the answer becomes clear when I try to focus on the work with the most leverage.
Some kinds of work provide more leverage – by which I mean: they multiply the force put in. For example, consider a few different approaches to authentication security:
- I could review pull requests dealing with authentication. In doing so, my leverage is minimal: my hour of work doesn’t really save any other work organizationally, and I’ll need to review similar pull requests again in the future.
- I could write a guide to reviewing pull authentication correctly. In doing so, I increase my impact: now, anyone who reads that guide is more likely to implement authentication correctly (reducing future review time), and anyone who reads that guide is a potential review-er of future requests (increasingly the PR-review “force”).
- I could write a library to make correct authentication Just Work™. This has the most impact: once this work has been done the one time, the problem is solved for good; only very minimal future work is required.
Each option requires more up-front work than previous one, but each also pays increasing dividends. So, to decide between them, I can think about the leverage each provides – which has the best ratio between up-front work and future-saved-work? By choosing the option with the best leverage, I can be fairly sure I’m using my time most effectively.