The Threat Modeling Podcast Chris Romeo

Nandita Rao Narla introduces the basics of privacy in software. She discusses privacy threats, privacy threat modeling, and privacy by design. Suppose you write or handle software that touches user information. In that case, you need to understand privacy, how to assess and mitigate privacy concerns, and know when to implement privacy concerns into a design. This episode of the Threat Modeling Podcast is the perfect primer to raise awareness of the critical role privacy concerns should play in your next project.

Helpful Links:
Daniel J. Solove's "A Taxonomy of Privacy":  https://scholarship.law.gwu.edu/cgi/viewcontent.cgi?article=2074&context=faculty_publications

Akira Brand joins Chris to talk about her journey into threat modeling, her early experiences, some lessons learned, and how she knew her threat model was successful. Akira's experiences emphasize the importance of collaboration, understanding the application, and using tools and diagrams to aid the process.

Akira is a visual thinker and draws parallels between surgical checklists and the STRIDE model. Akira emphasizes the importance of a comprehensive approach, likening the STRIDE model to a surgeon's checklist that ensures all potential threats are addressed.

In her initial foray into threat modeling, she identified a significant security risk due to excessive permissions in an application. To understand and address this, she delved deep into the application's architecture, relying on data flow diagrams and a hands-on approach rather than a purely theoretical one.

Akira's story underscores the power of collaboration. Her challenges were overcome by the combined efforts of teams from engineering, data analytics, and security. She believes that the true measure of success in threat modeling is when diverse teams come together to create holistic security solutions.

Dr. Michael Loadenthal specializes in threat modeling beyond the conventional realm of technology. Companies today face multifaceted challenges, including political, legal, and technical threats. Solutions to these problems can also be varied. A comprehensive threat model should consider many dimensions, such as political, legal, ethical, and social. Whether advising activist groups or high-profile individuals, Dr. Loadenthal emphasizes a comprehensive understanding of the threat landscape and the development of context-specific solutions.

Dr. Loadenthal's unique approach to threat modeling is rooted in his early involvement in social movements and activism. He noticed that groups often faced many non-technical threats, such as legal, social, and political challenges. This realization led him to develop "intersectional threat modeling," which considers a broader spectrum of threats beyond just the technical.

Based on his diverse training and experience, Dr. Loadenthal emphasizes the importance of a multidisciplinary approach. He collaborates with a diverse team of specialists, including advisors and the clients themselves, to address complex challenges. Threat modeling works best with a team, and he discusses ways this works for him.

One of the tools in Dr. Loadenthal's multidisciplinary toolbox is the mind map. A mind map can show relationships between threats and lead to integrated solutions that address multiple problems together. A tool he likes to use from outside the tech industry is the harm reduction framework, a concept borrowed from public health. This approach acknowledges the inherent risks in various activities or systems but seeks to minimize the potential harm. Dr. Loadenthal explains how he applies the harm reduction framework to threat modeling. He shares practical examples of companies, non-profits, and high-profile individuals who all benefit from the broader perspective of his intersectional threat modeling.

The AppSec community agrees that threat modeling is essential, but many struggle to implement it effectively. Using insight from the LinkedIn community, Chris lays out a comprehensive Threat Modeling strategy to guide AppSec teams to success in this critical discipline.

Before starting, consider the organization's culture, tech debt, and current risk posture. Threat modeling will not be successful in an organization that doesn't prioritize security!

Tie threat modeling to the success of the business. See it as an enabler for the company, and define its success metrics clearly.

Integrate threat modeling into the development process in an agile and incremental manner. It's not about where you start but where you end up. It's essential to begin with critical applications and expand the scope over time.

Keep the Threat Model Up to Date. Threat modeling is a continuous process that adapts to new threats and system changes.

Make threat modeling holistic and straightforward. Start after the high-level design phase, and revisit the model continuously throughout a product's lifecycle.

Concentrate on domain-specific problems, which threat modeling is good at identifying. However, when identifying domain-agnostic issues, use automated approaches.

Special Thanks to the following individuals who provided feedback for this episode: Iswarya Subramanian Balachandar, Kuldeep Kumar, Abdoulkader (Abdo) Dirieh, Rob van der Veer, and Tony Turner.

Engineering-led, developer-focused, or software-centric threat modeling: they all have software in common. Composing software into functions through the user story's lens is important. Farshad Abasi shares his journey from being a software engineer to forming a global AppSec team at HSBC Bank. Farshad expresses the importance of asset-based threat modeling and the need to keep things simple. He emphasizes the importance of focusing on the user story and considering the "comma, but" scenario to understand potential threats. He also suggests using pull request templates in source control to ask standard threat modeling requirements-specific questions.
Farshad recommends doing architectural threat modeling at the beginning of the development process and revisiting it periodically, perhaps quarterly or annually. He also highlights the importance of being part of the DevSecOps process to review user stories regularly. 

The key points are asset-based threat modeling, following the data, focusing on the user story, balancing high-level architecture threat modeling at the right time, and adopting pull request templates as reminders for threat modeling. 

Provide a solid process that makes sense to developers, as they don't mind threat modeling when presented in this way.

What is the connection between threat modeling and product development? How can you apply lean product management and focus on understanding the user's needs while still threat modeling? Prepare to explore product-led threat modeling.
The conversation delves into the importance of taking responsibility for security and using the language of the teams being influenced. Michal shares his process for conducting a threat modeling session, including using rapid risk assessment and STRIDE methodologies, building a threat library, and utilizing cookbooks for different technological approaches.

Throughout the episode, Chris and Michal provide valuable insights and best practices for incorporating threat modeling into product development, emphasizing the importance of collaboration and communication between product managers, architects, and technical leaders. Listeners will come away with a deeper understanding of how to approach threat modeling that aligns with the user's needs and the product's goals.

Key takeaways:
1. Threat modeling can be integrated into the product management approach to understand better the needs of the user and design mitigations for security risks
2. The problem space and solution space are terms from lean product management that can be applied to threat modeling
3. Responsibility for security should be taken by the product manager or owner
4. Rapid risk assessment and STRIDE methodology can be used to identify and prioritize threats
5. Cookbooks for different technological approaches can be used as references for solving security problems
6. Smart threat modeling builders use the language of the teams they are trying to influence
7. The product manager must be in the habit of saying it's my problem, not someone else's.