Is Retro = Threat Modeling a Team?
When I had released the ⛈️☂️(⛈️☂️) Threat Modeling of Threat Modeling #meta, I had a fascinating insight:
I met a friend for lunch. My friend was so annoyed that the team had a retro in the afternoon. Apparently, retro was just the same fruitless talk again and again - and no improvement.
I asked: “Does your team suffer from admiration for the problem?”. Importing this meta threat modeling concept and applying it to retro connected the dots: Is retro = threat modeling a team? In it’s essence, we are looking at our team, it’s mission, past and upcoming tasks, capabilities and limitations. Then we elicit threats and see how we can mitigate them.
Wisdom from the ⛈️☂️(⛈️☂️) Threat Modeling of Threat Modeling #meta that makes retros suck less
Back at the computer, I could right away filter the ⛈️☂️(⛈️☂️) Threat Modeling of Threat Modeling #meta for threats that might as well apply to retro and turn it ineffective, inefficient and frustrating.
Surprisingly, the threats and mitigations really fitted retros as well. Even the detail texts worked. Only sometimes, I needed minor adjustments in the words.
Here’s the list. See ⛈️☂️(⛈️☂️) Threat Modeling of Threat Modeling #meta for the detail texts and the suggested mitigations:
- 🧩 Develop software without
threat modelingretro (May serve as motivation) [0.1]- ⛈️ [0.1.1] Blindness
- ⛈️ [0.1.2] Insecurity / Accidental Security
- ⛈️ [0.1.3] Actual Damage
- ⛈️ [0.1.4] Late
Threat Modelingretro
- 🧩 Design
Threat Modelingretro process (how) [0.3]- ⛈️ [0.3.1] No process available
- ⛈️ [0.3.2] Perfect process trap
- 🧩 Scope and represent the system [1.3]
- ⛈️ [1.3.1] Too abstract scope
- ⛈️ [1.3.2] Too detailed scope
- 🧩 Discover threats [2.1]
- ⛈️ [2.1.1] Blind spot
- ⛈️ [2.1.2] Blind area
- ⛈️ [2.1.3] Hard threat discovery
- ⛈️ [2.1.4] Stuck in threat discovery / “admiration for the problem”
- ⛈️ [2.1.5] Never-ending threat discovery
- ⛈️ [2.1.6] Irrelevant threats
- ⛈️ [2.1.7] Loss of big picture
- ⛈️ [2.1.8] Lack of focus
- ⛈️ [2.1.9] Long excursions
- ⛈️ [2.1.10] Rewind
- ⛈️ [2.1.12] Hiding the unpleasant
- 🧩 Assess risk / Decide which threats need mitigations
[3.1]
- ⛈️ [3.1.1] No risk assessment
- ⛈️ [3.1.2] Arbitrary risk assessment
- ⛈️ [3.1.4] Single underestimated risk
- ⛈️ [3.1.5] All-acceptable bias
- ⛈️ [3.1.6] Single overestimated risk
- ⛈️ [3.1.7] All-critical bias
- ⛈️ [3.1.10] Never-ending risk assessment
- 🧩 Plan mitigations [3.2]
- ⛈️ [3.2.1] Unfeasible / high effort mitigations
- ⛈️ [3.2.2] Mitigation overkill
- ⛈️ [3.2.3] Mitigation underkill
- ⛈️ [3.2.6] Hard mitigation planning
- ⛈️ [3.2.7] Small toolkit / “If all you have is a hammer, everything looks like a nail”
- ⛈️ [3.2.8] Too much confidence in a particular mitigation
- ⛈️ [3.2.9] Too little confidence in a particular mitigation
- ⛈️ [3.2.10b] Lack of harm reduction
- ⛈️ [3.2.11] Vague mitigation confusion
- ⛈️ [3.2.12] Mixing essentials with ideas
- 🧩 Implement mitigations [3.3]
- ⛈️ [3.3.1] Split brain tracking
- ⛈️ [3.3.2]
SecurityRetro theater/ “Labersicherheit”
- ⛈️ [3.3.3] Undone mitigation
- ⛈️ [3.3.4] Undone mitigation unnoticed
- ⛈️ [3.3.5] Mitigation rotting
- ⛈️ [3.3.5b] Meaningless MUSTFIX markers (MMM)
- ⛈️ [3.3.6] Mitigation closed
- ⛈️ [3.3.9] Mitigation implementation error
- ⛈️ [3.3.10] Broken mitigation
- 🧩 Do collaborative knowledge work in teams with mixed
skill level [X.1]
- ⛈️ [X.1.1] Challenging traits in inter knowledge worker communication
What did go wrong? Or: What can go wrong?
One difference that I found is that threat modeling asks “What can go wrong?”, whereas retros ask “What did go wrong?”. If exaggerated, this yields a new threat: ⛈️ Living in the past. Teams may operate retros like incident response. And, yes, “Retro-spective” means “looking back”. I suggest they should threat model the future of their team and it’s mission.
Now what?
Here’s some directions where to go next:
- Are your team’s retros a success - effective, efficient, satisfying? If not, maybe wisdom from above
might help. You can meta threat model your retros.
- With the connection in mind, how does retro solve problem scoping, threat elicitation, threat
ranking, mitigation planning and execution? What can we learn from that for our threat modeling
programs? And vice versa?
- Some vendors have strong retro culture and weak or no threat modeling. Can threat modeling somehow be “piggybacked” via retro?