As any long-time readers know, I constantly abuse my past experiences and hobbies to try and make my current work sound WAY more interesting than it probably is. Or maybe it’s just an ego thing, I don’t want to think too hard about it. But, on occasion, lessons from my parallel lives actually inspire some original work.

As a paramedic and a pilot I have had to memorize many dozens of mnemonics, and I’ve forgotten many more. Mnemonics are proven to be highly effective memory devices even in the midst of intense stress, like flying a plane or working a 9-1-1 call. For example, I learned “SAMPLE” for taking a patient’s history probably 30 years ago and I still use it today because in the insanity that is some calls it can be easy to lose track and forget a fundamental. This I always remember to ask about Signs and Symptoms, Allergies, Medications, Prior medical history, Last oral intake, and Event (why did they call us today?). Having issues ventilating an intubated patient? Use DOPE. Accidentally put your airplane into a spin? Use PARE (Power, Aileron, Rudder, Elevator).

The more you drill these the better they work. I memorized RAKETS for my private pilot checkride but I definitely need to look that one up (it’s used to figure out if you can still fly a plane with a broken part).

We don’t really use these in infosec, and I think it’s time to change that. Thus I present to you RECIPE PICKS for cloud incident response. This one hit me yesterday on an internal dev review call in one window while finishing my paramedic recertification in an open browser tab. For 4 years now here is how I’ve taught what to look for first in a cloud incident:

Analysis slide

I have the students leave that one up when we start the scenarios and live fire exercises. But standing in the shower I came up with a much better way to remember what to do. NOTE: the order doesn’t matter, as with SAMPLE it’s to make sure you don’t miss anything (the format breaks a little at the end due to this sites rendering, sorry):

              Resource (current config/state)
              Events (api call(s) on that resource)
              Changes (diff plus associated API calls)
              Identity (who made the triggering change or API call)
              Permissions (of the identity; informs the blast radius)
              Entitlements (of the resource: e.g. it’s IAM role or managed identity)

              Public (is it public?)
              IP (all API calls from that IP address)
             Caller (all other API calls from the calling identity)
trac(look for indications of a pivot; e.g. role chaining)
forenSics (on a resource, or digging into resource logs)

These steps shouldn’t be done in order, except the last two probably need to be the last two (especially the forensics). This is all based on the process I’ve figured out over the years and I estimate you can probably close 90% of incidents relatively quickly by pulling this data.

I’m definitely going to start trying to build more of these into my trainings, and I’ll do some more blog posts in the coming weeks on how to use RECIPE PICKS. I’d also be remiss if I didn’t link over to a work blog post on how our platform does most of this automatically on every incident.

Let me know what you think and if I missed anything. Just email since I have comments turned off due to all the ridiculous spam.