Threat Modeling for Developers

Jonathan Marcil

Summary

• Who’s this guy?
• Threat Modeling utopia
• Developer environment
• Lost of hopes and dreams
• Who are you?
• Organization size
• Win or fail game

Who am I?

• “AppSec person”
• Not Adam Shostack
• I sit next to developers
• In the time I have, Threat Modeling is one of many activities of Application Security

Threat Modeling Utopia

What happens if you give a lot of time to brainstorm, edit and reach friendly consensus to 15 people with diverse backgrounds?

👉You get a Manifesto and � a Catalog of Capabilities

What your organization can do for threat modeling

​

​

• Lego pieces to help build a threat modeling program
• Single page Web document
• https://www.threatmodelingmanifesto.org/capabilities/
• List capabilities with short description

​

​

​

Developer std environment

What happens when you subdue highly intelligent people into delivering software amidst chaos?

👉They get very resilient, � especially to diversions, � and focus on their goals

And now,�let’s bring both worlds together

38 Threat Modeling Capabilities

• Strategy
• Execution Governance
• Life Cycle Integration
• Resource Allocation
• Education
• Training Assignment
• Adaptive Learning
• Active Practice
• Execution Support
• Convention Alignment
• Continuing Education
• Creating Threat Models
• Experience Availability
• Fostering Participation
• Shared Responsibility
• Active Collaboration
• Portfolio Prioritization
• System and Threat Comprehension
• Pattern Cataloging
• Format Consistency
• Continuous Changes
• Change Control
• Threat Model Distribution
• Tool Assisted Process

​

• Acting on Threat Models
• Definition of Done
• Seamless Alignment
• Baseline Improvement
• Risk Management
• Communications
• Positive Reinforcement
• People-Skills Development
• Feedback Collection
• Constructive Conversations
• Listen To Diverse Viewpoints
• Measurement
• Value Assessment
• Status Tracking
• Quantified Risk Management
• Program Management
• Value-Driven Management
• Simple Changes
• Methodological Openness
• Metrics-Driven�Management
• Collaborative�Program Development

38 Threat Modeling Capabilities

😂

Can you recall 7 of them?

Take a deep breath of air,

perhaps a sip of water,�and carry on…

Who are you? What to do

• “AppSec person”
• Have capabilities fit in the big security picture
• Be the expert; perform a selection depending on organization size and current need
• Adam Shostack
• Say hi!
• Developer
• Focus, or have someone else, on threat modeling

Org size matters

• Size dictates the amount of different capabilities you can choose and how deep you can go in any

​

• But not that much!
• Teams would be always relatively the same size
• When engaging, the velocity and appetite of a team is what should be guiding your approach

Org size is about scale

• Scale is a double edged sword
• Gives you more opportunities to screw up and learn on a per session basis
• Gives larger amount of “clashback” and decisions and processes are harder to change

Let’s play WIN or FAIL!�

Vote with 👍 or 👎

​

​

Each example is tied to a Capability, but omits details. Refer to slide notes for the original Capabilities website text.

Strategy / Resource Allocation

The organization has mandated the security team to create a threat modeling program. Dedicated resources on the team have been given time to focus on the program and perform threat modeling.

Developers had to provide information required to create the model and to make changes from outcomes, yet the organization didn’t give them more time.��Make it part of the official tasks for developers, not just security!

Time squeeze ==☹️

• Developers are awesome at delivery, they will deliver “threat models” when asked
• But without additional time allocation, they will squeeze the tasks between other priorities, such as implementing features and fixing functional bugs
• This will impact the quality of threat models, and make developers push back on changes more for time constraints reasons

Education / Active Practice

The organization has invested in training and enrolled everyone, including the developers and security into a video based training that provides examples while introducing fundamentals.

​

Training was set with a due date to ensure completion.

Developers often don’t have time to reflect on theoretical applications and just apply them retroactively. Quickly, what was learned is lost.��Perform training alongside a real threat modeling session, by having a live hands-on training that uses the current developed system.

Direct context ==🙂

• Developers focus and context is the system they are currently working on
• Outside knowledge, like training, often uses examples that might not be even close to what developers are currently working on
• Direct context will improve memory retention of developers and reduce mental fatigue due to context switching.

Creating / System and Threat Comprehension

The organization has properly trained everyone on a threat modeling methodology, given them dedicated time to create threat models.

​

Developers are asked to produce an initial threat model that after is reviewed by security to add threats and mitigations.

People involved know about the system and have expertise to identify threats, which result into producing a quality model.

�But wait…

Creating / Active Collaboration

The organization has properly trained everyone on a threat modeling methodology, given them dedicated time to create threat models.

​

Developers are asked to produce an initial threat model that security reviews after to add threats and mitigations.

People don’t collaborate, thus reinforcing a culture of blame and pretend compliance.�

Have teams work together on the model in a non-adversarial manner instead of passing a document to each other.

But wait there’s more…

Communications / Constructive Conversations

The organization has properly trained everyone on a threat modeling methodology, given them dedicated time to create threat models.

​

Threat models are done with teams working together in a non-adversarial manner.

The peer-to-peer collaboration has evolved into productive dialogues to share knowledge and experiences.��Developers learn threats from security and security is better informed on what are the systems they have to secure.

Collab multiplier ==🙂

• Impact spreads from one capability to another
• Active Collaboration → Constructive Conversations → System and Threat Comprehension
• Chance to snowball and get to a point where the threat modeling program runs by itself
• Developers will be engaged organically, with a feeling of constructivity towards their goals and that will foster their participation

Acting / Seamless Alignment

Program Management / Value-Driven

The organization has positioned Threat Modeling where its outcomes can influence system designs.

​

That added value to the development process is demonstrated in the program at the organizational level.

Developers feel that the Threat Modeling Program is aligned with their main goals and take pride into creating better systems.

recognize the value added proposition

The key is to have developers by tying it to their goals.

Bonus slide

​

​

​

​

Izar is to blame if I go over time

Vulnerabilities are everywhere!

​

There’s a breach right now and there’s so many things that need to be fixed!

Don’t Threat Model. Help resolving the issues.

Observe and take notes… these will be priority threats for your organization.

Take time after recovery to incorporate lesson learned into threat modeling.

Thanks!

Slides and links on:

https://about.jonathanmarcil.ca →

​

Special thanks to:

Izar for the review

The Threat Modeling Group

ConFoo 2024

OWASP France

​

https://www.threatmodelingmanifesto.org/