The AIV Model: Defining What a Threat Actually Is
Ask ten people what a threat is and you get ten answers. Without a shared definition, controls from offensive and defensive teams cannot align. Forget-Besnard and Bouchard solved this with the AIV model: Actor, Impact, Vector. The actor is a person type with a defined access level and sophistication. The impact is that actor’s end goal, kept to a short list modeled on MITRE ATT&CK. The vector splits into exploit (the attack steps) and surface (what is exploited). That structure lets teams compare one threat to another.
Scaling Through Decentralized Champions
Three threat modelers cannot review every project at a 58,000-person organization. The answer was decentralization: train others to do threat modeling and embed them across teams. To prepare, they published a threat modeling guide and made the core team reachable for questions. To extend further, they identified use cases where threat modeling added clear value and chose collaborators with both the technical depth and the authority to act on findings. Small team, big org, allies required.
Building a Threat Catalog to Reuse Intelligence
Each completed threat model feeds a central database rather than disappearing into a slide deck. The team built a threat catalog: every modeled threat, categorized by AIV components, and queryable. Champions submit threats; the core team manages quality and visualization. Power BI dashboards let risk officers filter by surface or actor, review historical data, and spot patterns. An exploited threat outweighs a hypothetical one. That weighting drives action plans instead of unranked CVE backlogs.
Lead Architects Catch Design Bugs Before Production
The first champion group Desjardins tried was developers. Training worked, but developers lacked the authority to change security requirements. Lead architects turned out to be the right group. They reviewed all projects going to production, had the depth to assess threats, and could block insecure designs. Training ran as 6 to 8 two-hour sessions, recorded so new hires could onboard without the core team repeating everything. After one year, architects ran threat modeling autonomously. Yearly updates now adjust content based on patterns in the threat catalog.
Threat-Framed Scoping for Penetration Testing
Vulnerability reports were the second target. Risk owners received dense reports, assessed risk poorly, and made action plans disconnected from the findings. The fix: frame everything through the AIV model before handing findings to owners. Instead of listing vulnerabilities, communicate the threat directly. All 30 ethical hackers at Desjardins trained in one day to translate exploit chains into AIV-structured threats. Scopes changed: instead of “test this IP range,” the brief became “can you exfiltrate data from this asset?” Executive summaries now list exploited threats, not vulnerability counts.
Detection Engineering Starts with a Threat
Detection teams were requesting detection on everything, with no explanation of why. The new process: start every detection request with a threat. Offensive security and lead architects, already trained in AIV, write the threat. Detection engineers then determine whether detection already exists, whether it is needed, and where in the attack chain to place it. The result was fewer duplicate rules and better coverage. Detection engineers worked from their own strength and offensive teams from theirs. Building the shared process took about three months before it entered continuous operation.
Q&A
What did rollout cost in time and budget? Training lead architects required 6 to 8 two-hour sessions with annual updates of about 4 hours, and architects reported the methodology also improved their day-to-day design work. ▶ Watch (36:16)
Did architects or detection engineers push back? They avoided pushback by selecting only willing early adopters, and people who initially refused came back months later asking to join after seeing results with other teams. ▶ Watch (37:28)
What tooling supports the process? The foundation is a methodology guide rather than a specific tool; they are evaluating AI assistants but consider process the more important investment. ▶ Watch (39:14)
How do you measure program success? They track which teams contribute threats and how much core-team support those teams still require, treating support volume as a proxy for training quality. ▶ Watch (40:02)
Notable Quotes
not your intelligence that’s very key Léandre Forget-Besnard · ▶ Watch (23:01)
so it was on a checklist Léandre Forget-Besnard · ▶ Watch (29:59)
Key Takeaways
- The AIV model (Actor, Impact, Vector) gives every security team a common definition of what a threat is.
- Lead architects with cross-project authority make better threat modeling champions than developers who cannot change security requirements.
- Centralizing modeled threats as a queryable catalog turns single-use exercises into persistent organizational security intelligence.
About the Speaker(s)
Léandre Forget-Besnard is a security engineer and team lead at Desjardins specializing in offensive security, including pentesting and red teaming. Over six years, he integrated threat modeling into offensive practices to strengthen security assessments.
Laurent Bouchard is an Offensive Security Threat Modeler at Desjardins. His focus is understanding how and why computer systems work the way they do, applied to threat modeling over the past several years.