Always Be Debriefing

Always

Be

Debriefing

It’s not quite as cool as “Always Be Closing” from the cult classic sales movies, but the concept really is identical, just with a red team slant (which is the intended audience for this post). You maybe aren’t selling a product, but you are selling them an idea on how to improve their security (yes, “sell” … everybody is selling something, just some people are better at it than others).

The best penetration testers and red teamers I know do this, at least intrinsically if not overtly and consciously.

I’m a big fan of building your final deliverable, whether that’s a written report or a debrief slide deck, as you go about your testing. It saves time and ensures you have the evidence you need to support your findings as you go. Maybe you already do that, so let’s take it to the next level.

If you stop to think about your customer in the early stages of testing, and if you pause to do this enough, it forces you to think like your customer thinks. Think about the message you want to share to them. You could choose: “Hi, I wrote this impersonal 200 page penetration test report that shows your baby is ugly.” Or you could choose the message to be: “Hi, we found some problems, we realize this is not pleasant news and you’d rather be anywhere but here right now, but the good news is we really do want to help you fix them.” If you’re choosing the former, you can stop now and go back to reading Twitter.

Having this “always be debriefing” mindset directs your mind to think about how the problems you’re observing need to be presented. Not just with care and humility, but also with the most accurate and concise evidence. If you show up at the debrief and didn’t expect to be challenged on a key finding, your lack of compelling evidence will compromise the entire message of your work — even the findings for which you do have compelling evidence — so don’t do that. If you are a manager type, and didn’t do the hands-on keyboard tactical work from the security testing exercise, you should fully comprehend everything you are about to tell your customer and be ready to handle every challenge thrown your way, or you better bring along a life-line to the technical person who can answer the tough questions.

When testing, as you work, as soon as you see a problem, from the moment that shell returns home (and even beforehand in anticipation), visualize what that conference room debrief (or maybe it’s just a conference call) will look like, who will be there, what types of responses you may receive, and try to anticipate all of them. Exercise your empathy muscles. See things from their side of the conference room table. What will motivate your audience — your customer — to improve their security? Test those things NOW and specifically collect the supporting, conclusive evidence NOW, making sure you didn’t miss anything. Craft the debrief story as you go — don’t wait until the end when it’s too late to influence how and what and why you test. From the moment you begin planning your test, be thinking about how your choices at that moment will affect the debrief.

While you’re at it, handle all that evidence with extreme care — it is valuable after all, or else the security improvements you’re trying to sell aren’t all that necessary. If you mishandle it, your customer may notice during that debrief, which will further impact their willingness to receive your message.

Always. Be. Debriefing.