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.
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.
[00:00:00] Chris Romeo: There are many ways to perform threat modeling. Almost as many ways as there are fish in the sea. The way of threat modeling is influenced by the participants and the unique challenges that they face.
[00:00:22] Michal has a different way of thinking about threat modeling. His way's different than the engineering first way and his is a focus that you must understand. I'll let him explain.
[00:00:35] michal: My name is Michal Svoboda, I do work in the security industry for about 25 years now. Currently I do work as a security architect. I also work designing security products. I also teach security. I think there is a connection between the thread modeling and the regular product development approach.
[00:01:02] /
[00:01:02] Chris Romeo: This description of a connection between threat modeling and product development caught my attention. What is the role of product management in threat modeling?
[00:01:11] michal: They have some point of reference, maybe a product owner or product manager. The discipline of. product management, or specifically the lean product management is all about figuring out what is that thing we need to build. The threat modeling by itself, I just see it as a sort of mix in, into that methodology. You just take a different vantage point because every product would have features that pertain to its functionality. What's, take an simple example. Maybe we are doing an, e shop. There will be features pertaining to the merchandise we want to sell. At the same time we can say the customer needs that. E-shop to be secure in some way? We know that in security there's this triad approach, confidentiality, availability, integrity. So we can start right there just asking about from the customer's perspective, what is the need on those three items? Maybe they need that to be available much more than it needs to be confidential or, temporary resistant. Yeah. That would be fair guess for an E-shop because the company loses money every time they're not selling online. Yeah. And that is already our first thread model, and that allows the product manager, the product owner, or the whole team to understand What they need to build and why, and that, that type of security feature is then just another thing that has a persona. And that goes into the, story mapping or whatever the team is using to build.
[00:03:01] \
[00:03:01] Chris Romeo: We have the beginnings of a threat modeling methodology, and it's a simple methodology that I'm not ashamed to say I've never considered on its own. The CIA Triad provides a splendid jumping off point for thinking high level about threats to an application. It lays the foundation for what we're trying to protect and make sense for product managers who may be less technical than the developers that are building the software.
[00:03:28] We need to define better the roles and responsibilities of this product manager. Here's Mihail again.
[00:03:35] michal: By saying the product manager or product owner, I simply mean the person who takes the responsibility of deciding what is the. Best way, how to serve the user's needs. It can be one person, it can be multiple persons, so it can be a product team. or Besides just taking responsibility on these functional aspects for the eShop, for example, they also need to own the security needs, and that puts these things on the same table with the same decision making process as the the rest of running the business basically.
[00:04:13] So it allows the product manager or the this activity to make trade offs.
[00:04:22] Chris Romeo: This is an important point. Security should go through the same decision making process as anything else within the business. Often security is seen as something different, and this methodology is pressing it into the same decision structure that exists for any other business driver.
[00:04:39] But what about technical limitations that the product manager may have? How do they surround themselves with security expertise? Here's Mihail again.
[00:04:49] michal: They may be more versed in their field of business rather than the security expertise they may take. Additional persons like that would be embodied in the security persona. In, for example, in Cisco that is called the security advocate, but in generally it's person who is an expert in these matters and they can supply, for example, the information about the risk that is, Pertaining to the business. And for that matter, they can use the thread modeling techniques such as we know the stride and others just to figure out what are the needs of the user regarding security of the product they're building.
[00:05:36] Chris Romeo: As we continue to flesh out the product management approach to threat modeling, we hit two key terms, problem, space, and solution space.
[00:05:47] michal: The problem space and solution space are terms from lean product management. Problem space pertains to the needs of the user. we really cannot measure the problem space directly. Instead, we try different solutions and see whether or not they apply to the problem at hand. This is called the throwing spaghetti at the wall approach. You basically throw them until they stick and then you know they're cooked.
[00:06:15] Chris Romeo: Side note, if Mihail ever invites you over for dinner, you better hope he's not cooking spaghetti. My fear is that it may have hit the wall before it hits your plate, but I digress.
[00:06:28] michal: Taking as an example, our e-Shop there will probably be a need to be locked in user like. Username, password, or any other type of authentication. Let's suppose there is this need. So this is your problem space.
[00:06:45] The problem space is how do I authenticate a user in the terms of the stripe methodology? That would be a spoofing threat. Somebody else may do, Shopping on, on behalf of somebody else, so then the solution space can be different. And this is what we call the designing the mitigations for that risk in threat modeling.
[00:07:10] Yeah. And this is where really design work goes. So maybe there could be a solution of the, classic login and password. Maybe even two fa approach. This would probably satisfy the need of the persona, but maybe the product manager would really like to get this out as soon as possible.
[00:07:33] And this types of features are quite costly, and they have quite a lot of regulatory burden as well, like storing passwords, storing personal information. So maybe they can decide for a different approach. They put a login with Facebook button on the eShop for the first iteration because they're not even sure if somebody would buy what they're selling, right?
[00:07:57] So in this way, The product manager or the person who is responsible for a product can ask the persona, will this satisfy your needs? And he will say, yes. This serves as an authentication point at the expense that people who do not have Facebook will not be able to log in. And that's a trade off that the product team can make.
[00:08:22] Yeah, they will have a limited user base, but much cheaper feature.
[00:08:27] Chris Romeo: With problem and solution space, we're using product management terms instead of classic threat modeling terms. This is the best possible solution because we're using language product management already understands and uses in their day-to-day. Smart threat modeling builders use the language of the teams they are trying to influence.
[00:08:48] Now we need to explore what the process looks like when we include product management.
[00:08:53] michal: The prerequisite is that Person needs to take the responsibility for the security. You could have two different approaches that the product manager takes. One is what I would call the I am responsible, like I own this end to end. And if there's a security feature I need to consider it.
[00:09:15] If there's a security problem, it's my problem. And if I don't understand, I get some advice, but at the end it's me. The other is others are responsible. I only own the parts I am comfortable with owning, and then I delegate some other parts to other people and they call the shots. But then Whatever they come up with, I don't really influence. So for the approach we are describing, it is required that all the parties agree on the total responsibility one way or another.
[00:09:55] Chris Romeo: Responsibility for security is a key takeaway. The product manager must be in the habit of saying it's my problem and not it's someone else's problem.
[00:10:06] michal: This would be your normal thread modeling session. You would meet up either in person or virtually you would maybe ask for or help the team even come up with this data flow diagram. Understand what the business problem is, what are trying to do. You could have. A couple of these, five, 10 minutes questions like we see in the rapid risk assessment methodology. You would just ask what do you think is your biggest your crown jewels and where are they on the diagram? And what would happen if, you know this happens and so on. So that helps you frame the overall risk maybe. Guide you a little bit on the threats. Yeah. And then it depends on what information you have so far. So you may begin doing some detailed thread models. I do this trite methodology although we don't tend to try it from scratch if you would call it like that. So we have a. Pre brainstormed set of threads that we apply because the projects I work with are quite repetitive with the basic needs, I would say.
[00:11:26] You could call it a library, but it what really is, 10, 20 lines in notebook or something.
[00:11:34] Chris Romeo: Multiple better practices on display here. Rapid risk assessment to quickly assess probability of an issue for the most important things and stride as a foundational methodology to build upon into your own simple threat library.
[00:11:50] are crucial in any threat modeling process. Here's me, Hal.
[00:11:56] michal: Going back to our analogy with the problem, space and solution space. So the list of the threats is really a list of problems. There are no solutions yet. And on the call, you may have people, like not just the product person, but also maybe an architect. Technical leader or anything.
[00:12:17] And again, it's important that this person owns the technical implementation, even including the security measures. Yeah. So they need to work with the product team or the product manager or whoever. So you would ask, okay, so you told me that this piece of data is your, biggest crown jewel. And according to our threat library, if you call it that way, information disclosure may be a problem. So how do we prevent data going from here to the outside, for example? And so what measures are in place technically to, to help that? And that's the solution space and the result could be this is fine.
[00:13:00] You, you have thought of that. Maybe you haven't thought of that. Maybe the way you're proposing is too expensive. Yeah, I can even say that cuz I love to, even when thread modeling, I love to make things more efficient and less costly. And this is the discussion and this is how we go for the next hours.
[00:13:22] Chris Romeo: Moving forward with more better practices. Here are what Mihael calls cookbooks.
[00:13:28] michal: We have what I would call cookbooks for different technological approaches. So if you are building on this type of technology, there would be a reference to how some other people already solved the problem. It may or may not be applicable to your product but generally it's quite similar. When that doesn't fit, we can go one level back and say can we talk about the generic mitigation? Is it applicable here? If not, we have to brainstorm some other things. So this already some hint at the solution space that might work just to save some time.
[00:14:11] Chris Romeo: Mihael has a great thought that ended our conversation.
[00:14:16] michal: I think think the more important part is that you don't be in annoyance with the thread modeling. And that's that's why we worked at thinking about ways how to make it more engaging and less annoying. When you touch something that they're responsible for, then that's when they're engaged. Now that's why I talked about the responsibility. This is how I think it can work pretty much very harmoniously.
[00:14:43] Chris Romeo: The highlights of product led threat modeling include using language familiar to product people, applying the C I A Triad as a high level approach, focusing on imparting responsibility within the product manager for security rapid risk assessments to quickly assess probability of an issue for the most important things, stride as a foundational methodology and simple threat libraries with cookbooks to back up the technical details. Reach out to the product managers in your life. Introduce them to threat modeling. Help them take on the responsibility for security within their products.