Engine-Out Landing Plans

“I have difficulty sometimes talking to people who don’t race sailboats”
- Bruno Gianelli

Sometimes when I am working on security incident response, I remember that I have an advantage: I am an instrument-rated airplane pilot.

I fly small planes. While any pilot flies - from the most boot VFR student to the Houston-to-Tokyo 777 captain - they’re maintaining a continuous instrument scan (ensuring the dials all agree), and regularly looking outside the airplane. For traffic. For weather.

And every few minutes or so, for emergency places to land.

Multiple times every flight hour, a good pilot thinks, “What happens if I lose my engine(s) now?” And then tries to answer the question in practical terms.

Sometimes this is easy - ‘That hayfield over there’ or ‘Oh look, there’s an airport,’ or even, ‘Ah, good old I-10.’

And sometimes, the answer is, “Well, I guess I’m fucked for a while.”

The point is, you know.

You’re actually “situationally aware”.

Nothing focuses the mind like planning for what happens when you start to fall out of the sky like a brick.

When I talk about rigorous security incident response planning, I don’t mean, “Do you have an IR policy?” or “Do you have an IR Plan?” but rather, “how did you make these things?”

Were these created by the IT or eng group, or by a multi-disciplinary committee? It really needs to be the latter. You need people in your organization (not mine) working on the things that they will care about when the defecation hits the ventilation.

Have you ever tested your plans, your procedures, your runbooks? And by testing I mean in several ways. Tabletops. Simulations. Whiteboarding. And actually working small incidents to test your larger plans (never let an incident go to waste).

So have you? Like, really drilled into your plans and procedures? How often? When’s the last time you did? What did you learn? What did you update?

All these questions are key to ask and even more critical to be able to answer. Answering them - even when the answer is, “I don’t know.” - gives you situational awareness.

“No,” you’ll say to yourself," I don’t have a plan yet for ___________."

And in saying that, you can kick off a project to make that plan. Preferably, you know, before the plan for ___________ becomes today’s reality as opposed to a vague, fuzzy, imagined future.

I’ve been in security incidents in which the runbooks told people how to kick off an action, but didn’t specify what to do when conditions change for the worse. And also, I might add, I’ve seen them neglect to say what to do when conditions change for the better - so don’t forget to have a section in your runbook and plans and rehearsals where you all get together and declare the conditions and criteria that must be met to allow you to actually declare the incident resolved and return to business as usual.

Putting your IR plans through the paces means thinking regularly about incident handling, and finding the areas where you’re weak. These are often around changing conditions of your business, your IT fabric, your engineering practices…