​

​

​

OWASP SAMM User Day Lisbon 2024

Hosted by Jonathan Marcil

Wednesday, June 26th

THREAT MODELING DISCUSSION

What is Threat Modeling?

• Business function: Design
• Security Practice: Threat Assessment
• Stream B: Threat Modeling

​

Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations

Threat Modeling Philosophical Supplement

Have you ever asked yourself if the core values and principles reflected in your activities are aligned with that has been observed elsewhere to get good results?

​

​

​

​

​

​

https://www.threatmodelingmanifesto.org/

Objectives of this session

• Think about how a single security practice impacts others
• How’s one practice could be the center proxy to many others for the end users of your security program
• Share and learn from others based on real examples
• Both successes and failures are valuable for learning
• See how different maturity levels implement threat modelings, and infer what works best for a given lever

Threat Modeling relationship

to the rest of OWASP SAMM

quick overview

Threat Modeling outputs

Threat Modeling adjacent dynamics

Threat Modeling ingest / leverage

What are your examples of relationships between security practices?

What approach clearly provided value and success for your security posture?

Next:

Jonathan’s examples bank

Threat Modeling Informs Risk Profile

• At first you create a risk profile in order to prioritize what you should threat model first

​

• While performing threat modeling, you notice that for one system, collected information was incorrect

​

• After doing many systems, you notice that your risk profile formula doesn’t reflect the situation of the system

Threat Modeling <> Security Requirements

• Security requirements are written and available somewhere but not consulted

​

• Threat modeling becomes an enforcement step for requirements, as you can map a threat, design flaw or mitigation to a given security requirement; synergy!

​

• Findings during threat modeling could help refine existing requirements or create new ones

Threat Modeling <> Verification

• Threat Modeling findings are implemented as a test case to ensure completion and prevent future mistakes

​

• Threat Modeling artifacts are being reused, not for their usual outputs, but as a security oriented view to guide pentesting that facilitated a deeper understanding of the system context

Threat Modeling Dataflows == Data Elements

• Threat Modeling is performed at a good time to prepare, populate and validate your data catalog by having a common touchpoint

​

• Dataflow diagrams enables visualisation of data element moving between systems
• Threat Model can collect and show data storage details intention before operations
• Enforce data protection policy at the design phase

Threat Modeling <> Architecture Assessment

• Simply do them at the same time!
• Architecture Mitigation QC L2: You systematically review each threat identified in the Threat Assessment
• Back and forth process costs more

• Most organizations doesn’t have a difference between an architecture reference and one implementation of a given system
• The architecture is often the infrastructure as code + the software code

Thanks!

Slides and links on:

https://about.jonathanmarcil.ca →

​

​

Special thanks to:

Seba

Threat Modeling Manifesto Group