As facilitator of a threat modeling session, how do you stop it becoming a security lecture?
answer
- your product is the room's output
- ask questions rather than deliver answers
- tangents get parked, with a name
- count findings at the halfway mark
- interrupt your own lecture first
basics
~20 sFacilitate by asking, not telling. The facilitator's job is keeping the team producing threats: pose questions about the design, park teaching and fix debates in a parking lot, watch the clock, and check part-way through that findings are accumulating.
solid answer
~50 sThe facilitator produces throughput, not content. Practically that means asking questions of the room rather than answering them yourself, giving the quiet implementer air time, and refusing to let one item consume the session. Two habits do most of the work. First, a parking lot: any tangent - background theory, a fix debate, an argument about a library - goes on a visible list with a name against it and the room moves on. Second, a mid-point check: at the halfway mark, look at how many findings are captured. A session on a brokerage order-routing rewrite where the security engineer has spent forty of sixty minutes narrating authentication history has produced nothing, and the only fix is to interrupt it - your own tangent included. Teaching is a side effect of the team working through their own design, not a slot on the agenda.
go deeper
Be ready to say that the facilitator asks questions and writes things down rather than presenting, and that a session where one person talks most of the time has probably gone wrong.
Explain the mechanics: directing questions by name, the parking lot, deferring fix design, and checking findings against elapsed time part-way through. Be able to describe the symptoms of a session drifting into a lecture.
Demonstrate having run one. Describe an intervention you made mid-session, including interrupting yourself, and how you decided to end early rather than fill time when the room could not produce findings.
Own the question of who facilitates at scale, how you train facilitators who are not security engineers, and how you keep the practice from degrading into a meeting that teams attend because the process requires it.
## The role: throughput, not expertise A facilitator's product is a session that generates findings from the people in the room. That is a different job from being the most knowledgeable person present, and the two conflict more often than people expect - the better your own security knowledge, the stronger the pull to answer your own questions. ## The security-lecture failure mode Picture a sixty-minute session on a brokerage order-routing rewrite. The asset at stake is money: orders that could be replayed, re-priced, mis-routed or suppressed. The security engineer opens with context, the context becomes a history of authentication protocols, someone asks a clarifying question, and the answer is another ten minutes. At the fifty-minute mark the engineers have learned some things and the shared document is empty. The session did not fail because the material was wrong; it failed because the room's knowledge was never extracted, and the room is where the knowledge about this order-routing design lives. The mode has recognisable early symptoms: - One voice is speaking most of the time, and it is the facilitator's. - Statements outnumber questions. - Nothing has been written down for several minutes. - Participants have shifted into audience posture: no laptops open, no interruptions, polite nodding. ## Techniques that keep a session productive **Ask, do not tell.** Convert every piece of knowledge you were about to deliver into a question aimed at someone specific: what happens to this request if the caller replays it; who can reach this queue directly; what does this service do when the downstream one returns an error. A question you know the answer to still counts - the point is that the answer comes from the room and gets captured as theirs. **Name the person.** Open questions to a group land on the most confident speaker. Directing questions by name pulls in the implementer or operator whose knowledge you invited them for. **Run a parking lot.** Keep a visible list. Anything that is not a threat against this design goes on it: background theory, a design argument, an implementation debate, a fix that needs a spike, a question that needs someone who is not present. Each parked item gets a name against it so parking is not the same as dropping. This is what lets you cut a tangent without cutting the person off socially - you are moving their item, not rejecting it. **Defer the fix debate.** The fastest way to burn a session is to design a mitigation live. Fix discussion is unbounded and engineers enjoy it. Capture the threat, capture a one-line candidate direction if one is obvious, and move on. **Watch the clock deliberately.** Announce the shape at the start, keep an eye on elapsed time per area of the design, and say out loud when you are moving on. A mid-point check - roughly how many findings are captured against how much time is left - is the single most useful facilitator instrument, because it converts a vague feeling that the session is dragging into a decision to change how you are running it. **Interrupt yourself first.** If you are the one lecturing, the fix is to stop mid-sentence and put your own point in the parking lot. Facilitators who only ever discipline others lose the room's permission to be disciplined. ## Teaching still happens - as a side effect None of this means the team learns nothing. People learn a great deal from being asked, in front of their own architecture, what an attacker could do with a request they wrote. That learning is durable precisely because it was applied to their system rather than delivered as background. If a genuine knowledge gap is blocking the room - nobody understands what an authorisation boundary is - the right move is a short, bounded explanation, stated as such, and a note to schedule proper training separately. ## Two related traps **The facilitator who also owns the design.** Running the session on your own architecture makes it very hard to stay neutral, because you will defend choices instead of eliciting attacks on them. Where possible, split the roles. **The session that becomes a status meeting.** Delivery updates, staffing, and dependency chasing crowd in because the same people are in the room. Same remedy: name it, park it, continue. ## What interviewers are listening for That you can describe the facilitator's job in terms of what the room produces; that you have concrete mechanisms - questions by name, parking lot, deferred fixes, a mid-point findings check - rather than an intention to keep things on track; and that you apply the discipline to yourself first.
- Halfway through a sixty-minute session you have three findings captured. What do you change?Say it out loud and change the mode. Stop whatever narration is happening, pick one concrete part of the design, and go around the room by name asking what could go wrong with this specific flow. Park every fix debate immediately. If the shortfall is caused by a missing decision or absent person, end early and rebook rather than filling the remaining time with discussion nobody will act on.
- A senior engineer keeps steering the session into a debate about which library to use. How do you handle it?Acknowledge it is a real decision, write it in the parking lot with their name against it, and return to the threat you were on. Doing it visibly matters: the room sees the item is preserved, not dismissed. If it recurs, restate the session's output at the top of the board - threats with owners - so the boundary is the agenda's, not yours personally.
- Should the person who designed the system facilitate the session about it?Prefer not. The designer's instinct is to explain and defend choices, which is the opposite of eliciting attacks on them, and the room reads pushback as criticism of a colleague present. Have the designer participate as the design-intent expert and let someone else run the clock and the questions. If the team is too small to split the roles, name the conflict at the start.
A facilitator is closer to a referee than a coach: the game is played by the people on the pitch, and your value is keeping it moving and on the clock, not scoring the goals yourself.
saying these in an interview costs you the question
- Opens the session with a security background presentation
- Answers own questions instead of asking the room
- Lets the room design mitigations in detail live
- Treats a quiet room as agreement
- Judges the session by discussion quality, not captured findings
- Never checks the clock until the session is over