A Product-Led Approach To Threat Modeling

In the world of threat modeling, perspectives vary widely. While most approaches focus on an engineering-centric methodology, Michal Svoboda brings a different perspective. A veteran security architect, security product designer, and security teacher, he advocates for aligning threat modeling closely with product management.

The Interplay of Threat Modeling and Product Management

According to Michal, who has 25 years of experience in the security industry, there's a natural synergy between threat modeling and product management. The latter often uses a lean methodology to determine what needs to be built. Michal posits that threat modeling can readily mix into this framework.

Take the example of an e-shop. While conventional product management may focus on features related to merchandising, it's crucial to consider security features. Michal recommends starting with the CIA Triad—Confidentiality, Integrity, and Availability—as a simple yet effective way to address customer security needs.

The Role of Product Managers

In Michal's approach, product managers or owners play a pivotal role in threat modeling. They are responsible for balancing both functional and security needs. This approach allows for making trade-offs, a normal part of any decision-making process, which should also apply to security considerations. Organizations can better integrate security into their products by putting security decisions through the same decision-making pipeline responsible for serving the end user needs.

Expertise and Limitations

Product managers may lack specific security expertise, but this gap can be filled by "security personas" or security advocates who can supply the requisite security knowledge. This multidisciplinary approach ensures that security considerations are not an afterthought but integrated into the core product development strategy.

Problem Space and Solution Space

Michal employs the terminology of 'problem space' and 'solution space,' which are borrowed from lean product management. The problem space in this context pertains to the user's needs. In cybersecurity, this is primarily concerned with vulnerabilities and threats that an application or system may encounter. For instance, in the example of an e-Shop, the problem space could be identifying the authentication requirements. Do users need to log in? What kinds of threats, such as spoofing, should be mitigated?

However, the problem space is elusive; it can't be measured directly. Teams usually employ a 'throwing spaghetti at the wall' approach, testing different solutions to see what effectively addresses the problem. This trial-and-error strategy is crucial for navigating the intricate labyrinth of cybersecurity concerns.

Conversely, the solution space is about designing mitigations for the risks identified in the problem space. For example, is a simple login password sufficient, or is two-factor authentication necessary? Sometimes, constraints like time, cost, and regulatory burden shape these decisions. The example provided elucidates how a login feature could be implemented using a social media account, thereby reducing development time and cost at the expense of limiting user access. But, it may limit non-Facebook users from logging in – a trade-off the product team must decide to make.

Chris aptly emphasizes the significance of using product management terminology. Cybersecurity professionals can bridge the gap between different departments by employing language that product management already understands. Effective communication is indispensable when it comes to security.

Responsibility: The Cornerstone of This Approach

Michal delineates two approaches product managers can take: "I am responsible," which implies ownership of security end-to-end, and "Others are responsible," where parts are delegated to other team members. Whichever approach is chosen, Michal stresses the importance of owning the responsibility for security.

The key takeaway revolves around responsibility. The product manager must assume complete responsibility for the security features or delegate it to someone who will. Either approach works as long as everyone agrees on the total responsibility one way or another.

In practical terms, this would involve a traditional threat modeling session where stakeholders meet, possibly aided by a data flow diagram or a Rapid Risk Assessment methodology, to identify and prioritize threats. A foundational methodology like STRIDE can serve as a baseline but suggests maintaining a "cookbook" of different technological approaches for efficient problem-solving.

Practical Workflow

A typical threat modeling session in this paradigm could involve the following steps:

1. Rapid Risk Assessment: Quick questions to identify the most important risks.

2. Data Flow Diagrams: Visual representation to understand business problems.

3. Threat Library: Utilizing foundational methodologies like STRIDE as a starting point.

4. Engagement with Multiple Stakeholders: Involve not just product people but also architects and technical leaders.

Michal Svoboda’s insights spotlight the often-overlooked relationship between threat modeling and product management. By incorporating product management methodologies and responsibilities into the threat modeling process, we have an opportunity to make our software not just feature-rich but also secure by design. This isn't just a refreshing take; it could be a cornerstone for a new generation of security-conscious products.

This post is based on an episode of The Threat Modeling Podcast. Listen to the full episode here: Product-Led Threat Modeling