Global AppSec Dublin: Introducing Threat Modelling To Established Teams

### Overview In this talk from Global AppSec Dublin, Sarah Jane Madden, Chief Information Security Officer for the Sensing Technology Group at Fortive, shares real-world experiences and lessons learned rolling out threat modeling across mature, established development teams. Rather than presenting theoretical frameworks or tooling demos, the presentation explores the human, organizational, and cultural hurdles encountered when embedding threat modeling into long-standing engineering workflows across hundreds of developers.

### Key Topics - **Selling Threat Modeling to Leadership and Product Managers**: Madden explains that framing threat modeling purely as an academic "best practice" failed to gain real traction with engineering and product leadership. To establish a compelling business case, she analyzed Jira historical tickets to find past defects and interruptions that threat modeling would have prevented, winning buy-in from product managers who control roadmaps and sprint priorities. - **The Goldilocks Problem in Team Selection**: Attempting a company-wide rollout to 300+ developers simultaneously led to bottlenecks, divergent custom standards, intranet wars, and no actionable output. Similarly, attempting to mimic an acquired team that had practiced threat modeling from greenfield inception failed because their methods did not translate to legacy codebases. The ideal pilot group proved to be busy, fast-moving teams maintaining mature products: they lacked time for theoretical debate and focused strictly on pragmatic, actionable mitigations. - **Navigating Remote Work and Stale Processes**: The onset of COVID-19 disrupted in-person collaboration. In one instance, a team's sessions yielded zero findings because an isolated engineer created diagrams, proposed threats, and suggested mitigations asynchronously, turning sessions into rubber-stamping exercises. Security reintroduced facilitated working sessions centered around the core threat modeling questions to revitalize the practice. - **Iterative Cadence and Scoping**: Threat modeling large, legacy systems all at once causes fatigue and failure. Successful adoption relies on limiting scope—focusing only on current features or changes ("little and often") rather than trying to boil the ocean.

### Technical Details - **Timeboxing**: Both entire sessions (e.g., 90 minutes at the start of a feature or 30 minutes weekly) and individual activities (brainstorming threats vs. solutioning) must be strictly timeboxed. This prevents speculative rabbit holes (such as "missiles from Mars") and stops teams from prematurely writing complete implementations during modeling. - **System Coupling and Architecture**: For loosely coupled microservices, small feature teams suffice. For tightly coupled monolithic or legacy architectures, broader cross-functional representation is required to evaluate boundary points and integrations. Similarly, platform and cloud operations engineers should be included when infrastructure directly serves application features. - **Diagramming Guardrails**: While teams may produce diagrams before or during sessions depending on preference, having a visual model (even a simple diagram) is required to ground discussions. - **Output Metrics**: Tracking raw ticket volume can incentivize perverse behaviors (e.g., filing low-value or absurd threats). However, monitoring output drops—such as a sustained cliff to zero findings—serves as a primary indicator of process stagnation requiring a facilitation reboot.

### Takeaways - **Unintended Side Benefits**: Beyond discovering vulnerabilities, threat modeling produces up-to-date system architecture documentation, forces engineers to validate how legacy components actually communicate, and dissolves organizational silos. - **Meet Teams Where They Are**: Tooling (whether Miro boards or specialized software) and meeting cadences should adapt to team maturity, architecture, and geographic dispersion. - **Maintain Product Management Partnerships**: Strong relationships with product managers ensure threat modeling is protected in sprint planning and treated as a collaborative product health activity rather than a security box-ticking chore.