Irene Michlin -- We Are Not Making It Worse

0:01Chris RomeoHey folks, on this episode of the Application Security Podcast, Robert and I are joined by Irene Michlin, who talks to us about incremental threat modeling. Incremental threat modeling is how do you apply threat modeling in an agile or DevOps world where your developers are going 100 miles an hour and there's extreme feature velocity? How do you check the security and determine the threats and deal with those threats in a timely fashion? We hope you enjoy. The Application Security Podcast. Here we go. Hey, folks. Welcome to this episode of the Application Security Podcast. On this episode, we are joined by Irene Michlin, who's going to speak to us about threat modeling and how we approach threat modeling with things that go fast. So, hey, Irene, thank you for being with us today.

1:19Irene MichlinHi, Chris.

1:21Chris RomeoSo, one of the things that, Irene, we always do with our guests is we're We want to provide some perspective for our audience about how do people get into security, where do they come from. So, if you could, please share with us your security origin story, or how did you get into the world of application security?

1:42Irene MichlinSure. So, I started as a software developer. I've been a developer architect for many years. 2 of the companies were building a security product, but interestingly, it was not immediately translated into secure development practices. But then one of them started being, it's not enough to build a security product. You know, the product itself must be secure and our development must be secure and how we introduce security into everything we do, every aspect of the lifecycle. So by that time I was sort of a senior developer and I was also into process, how to do agile, scrum, lean, all these things. So I was right in the intersection of introducing security into lifecycle, at the same time maintaining our ability to deliver rapidly the releases that we were doing frequently before then. And that was a very interesting transition. And after that, I started to look around, maybe sort of expand from being a developer to doing this thing more permanently for different organizations. And I came into consulting and it seems like a very good spot for me to be in the intersection of agility and security because These are 2 things that I'm passionate about.

3:16Chris RomeoYeah, and it seems like this is a, you know, application security has been such a hot area for the last few years. And, you know, there's not a lot of people that are focusing on how we do application security at a high rate of speed. There's a lot of people that know how to, you know, how to do different facets of it, but I think this is an interesting kind of an area that you've kind of specialized in here as to, you know, how do you do application security when you're trying to develop and deliver software at an extremely high velocity?

3:52Irene MichlinSure. I think the security approach, all the security specialists come— if you work as a tester for many years, you usually work with organizations that take security seriously. And these organizations tend to be large organizations, maybe financial or other corporate people who are maybe under some external pressure compliance. So they maybe are not as agile as everyone else. And I think we are at the point where the maturity of software development is catching up with the maturity of security. So security people see agile lifecycles more and more and DevOps, something that maybe they didn't see 5 or even 3 years ago. So it's an interesting learning opportunity for everyone, for software people to learn about security and for security people to learn about faster lifecycles, not maybe what they're used to, to come every quarter and to test things before release and then they go and fix it.

5:01No.

5:02Irene Michlinthe typical old-school pentesting.

5:05Chris RomeoYeah. And the fact that you stated, hey, that you worked for this company that was building a security product. In my past experience, I had some opportunities to work with different groups that were building security products. And it was— I don't know if this has been your experience as well, but The people that build security products a lot of times tend to think that security product equals product security and that they already know, like, oh, no, we're a security product. We're good. Well, no, just because you're a security product doesn't mean you actually practice good product security in what you do. It just means you're a security product. Did you have that same experience in working with teams that were building, kind of, I'm putting air quotes around, security products? Yeah.

5:59Irene MichlinSometimes, but I must say that was a long time ago. And these organizations mature as well because if you come, if you sold a product to someone and this client of yours invited a red team and red team then writes a report saying all of the security products you had were just more attack surface for us. Hey, And you hear this feedback, suddenly you start taking the security of your security product way more seriously, right? And that's the way teams see whatever you've installed on your server. It's just more things for us to play with. So, they better be secure.

6:41Chris RomeoSo, we are big fans of threat modeling here. Our listeners will know, they've heard us talk about threat threat modeling a number of different times in the life of the Application Security Podcast. And so, what's been your experience then with threat modeling, Irene?

7:03Irene MichlinWell, I've started to do threat modeling when still working as a developer, and it's been incredibly useful. So, obviously, it does what it says on the tin. It finds threats that you maybe didn't think about. But it also does so much more when you do it as a whole team. If you involve QA, it helps them from these threats to build security-focused test cases, which are traditionally very hard to, to build, to come up with good security-focused stories. It also helps the team to sort of have this shared mental picture, to share the understanding, then you are forced to distill your architecture to, to a diagram and to tell the story. You know, if, if you go through software-centric threat modeling, one of the things is how to know you have a good diagram. Check that it tells the story of what your system does. For the team that does it for the first time, even that can be revolutionary. What is it, our product? What is our story? And can we all agree on, on, on what it does? So the team improves the knowledge sharing massively through threat modeling. As I said, you get test cases out of it. You, you validate requirements and it just a really good introduction to security. Developers didn't come across other security activities before. This one I think is one of the lowest entry barriers into lifecycle through threat modeling. But of course these are all additional benefits. The main benefit, it finds threats and you can mitigate them before you actually build the insecure product.

9:04And I was curious about— I know that I've seen some of your work where you talk about incremental threat modeling. One of the things I get sort of pushback, if you will, certainly from teams that are doing Agile or DevOps or something that's a really fast cycle is, oh, we don't have time for threat modeling.

9:21Irene MichlinSure.

9:22You know, we're already many, many sprints in, we're already almost done or halfway done. what's the value of threat modeling? And it sounds like that's been some of your experience as well. Could you talk to us about that?

9:34Irene MichlinYeah, absolutely. That's one of the 2 objections I hear. One of them is we are into sprint 10, we cannot just stop and threat model everything we built into the previous 9 sprints. So my advice is Do a threat model for just the new things that go into your next sprint. And it, it could be a bit challenging for a team to, to keep it timeboxed, to ignore all the threats that may be already lurking there, but are nothing to do with what we are building in the next sprint. But you can help to keep it focused if maybe whoever is helping this Agile team with the processes in general, maybe Scrum Master, to keep it focused saying, this is not changing in the subsequent sprint. Sure, maybe there are threats in this feature, but what we are building now will not make it worse. So that's one of the key phrases for me. It helps to keep it focused. Are we making it worse with what we are building? The goal of our threat modeling is just to concentrate on not introducing new threats, new security problems. So maybe we are in a hole security-wise and we don't even know how deep it is because we didn't model the system as a whole. But what we can do from this point, we can stop digging. And that's the focus of this incremental threat modeling. Stop digging. Make sure you're not making a hole any deeper than it already is.

11:24Chris RomeoSo then, how do you, Irene, how do you recommend that folks deal with the kind of security debt that they would have built up in those earlier sprints? How do they go back and over time and try to figure out, you know, and try to ensure there are no threats in what they did in the initial time.

11:45Irene MichlinRight. So, when software development in general talks about legacy software, I know the recommendation is, oh, don't try to introduce tests to everything. Just add tests to the things that are changing, and eventually you will cover all the important bits. So unfortunately with threat modeling, it's not like that in my opinion, because if the vulnerability is there in some feature, even if there is no code churn around this feature, even if it's not used much, still, if there is a vulnerability in it and attackers find it, they will be able to compromise the whole application through, through this vulnerability. So unfortunately the answer is not just Oh, do incremental forever and eventually you will cover everything that's important. No, you will have to tackle the debt on unmodeled things eventually. But what has been my experience through doing incremental for a while, you build up your skills. And when you come and tackle this technical debt, you are much more efficient and you can do it faster. Than if you just tried to face it on day one. Like I've read a book or I had a training and now I will start modeling my whole system. It'll be much more time-consuming than if you start incremental, you build up your skills, you maybe model some subsystems or components through this incremental, and then you come to model the whole system. You're not facing the blank page. And also, you have a better skill level. So, overall, I think it's a more efficient approach and cost-effective as well.

13:46Chris RomeoSo, when you go through the process, what is the kind of your basic process that you teach to new developers to get them into this incremental threat modeling mindset?

14:05Irene Michlinmindset? So I have some exercises. Normally I would present a simple architecture, I will explain it and the model for this architecture, and then we go, let's pretend we don't know the existing architecture, it's all just a big legacy blob, and let's talk about adding new feature and how we can model this new feature without knowing all the previous model and how we can focus just on the threats that are to do with the new data flows and the new additions to our system. And through this exercise, we learn to discover just enough of the existing stuff, just enough. And I have a couple of presentations where I like challenge people, get, get your phone out, start a timer. And we go through this realistic feature in 10 to 15 minutes. And I think even if you are in a very tight iteration, say week-long iterations, you have 1 hour, 1 hour and a half of your planning meeting. Yeah. How many features you will realistically do in, in this iteration, say 3 to 5 stories, features, whatever. So my experience is for at least half of them, you will look at them and you will say, it doesn't change our current model, whatever it is. We are not adding new data flows, we are not adding new components. Nothing to see here from the point of view of threat model. Moving on. And that took, what, 10 seconds to say it? There will be 1 or 2 features where you do have to go deeper and to apply STRIDE and look at all the new data flows that you're adding. And that should take about 10 minutes per feature. So I think it's realistic for development team that goes into Even a week-long iterations. Now, if people are working without any iterations, say if it's a lean process or something, they take a story and they just work on it and they deploy it as soon as possible. Even in this kind of environment, say they are doing extreme programming. That's the fastest you can go in, in development, right? So the pair of developers just grab the story. Works on it as fast as they can and tests it and deploys it. If you look at the Extreme Programming Guide, it says the pair should start with a conversation about the story. Well, you put this incremental threat modeling into your conversation. So your conversation takes 10 minutes longer than it would otherwise do, but you get so much benefit out of this 10, 15 minutes.

17:13Chris RomeoYeah.

17:14Irene MichlinI think it's quite a realistic goal for even the fastest development environment.

17:21Chris RomeoSo, the point of the timer then when you're teaching your developers how to threat model is to demonstrate to them that they can effectively do threat modeling in a very short period of time? Is that the idea?

17:38Irene MichlinYes. Yes, that's the idea. We take a realistic architecture, We take a realistic feature, then we say, okay, let's pretend we don't know the whole system. It's just a legacy blob. Let's discuss this feature and let's discover what are the data flows it adds, what, what are the components within this legacy system that it needs to communicate to, but don't go any deeper. If you come across things that you suspect are probably present in your existing application, just record them and move on. You don't do threat modeling of existing threats in this incremental process. You record them and move on.

18:28Chris RomeoSo, do you, how do you, when you're working with your developers, how are they, where are they recording their threats in this process where they go fast? Are they opening up you know, bug reports based on the threats that are found? Or how do you track these things and ensure they get fixed in a reasonable amount of time when you're trying to move fast?

18:51Irene MichlinWell, that's separate from the modeling, how you manage threat lifecycle. And it may not suit everyone, but I do recommend keep everything in one tracker, one source of work for the team because what you see sometimes people have a bug tracker, let's say Jira, right? It's not an endorsement, but let's say Jira and they take their stories and they take their bugs from it.

19:28Okay.

19:29Irene MichlinBut everything security related is hidden in some kind of Spreadsheet on security architect laptop. It's not a good place to be in because there is no visibility and this work is perceived as outside of our normal processes. It might be perceived as, oh, it's just something that slows us down, that eats into our velocity.

19:58Yeah.

20:00Irene MichlinI think security work has to be visible. So the easiest case is it's a security feature, right? We need a SQL login, or we need better access controls implemented. That's very easy. It's like any other agile story or agile feature. You work on it, it's on your board.

20:19Chris RomeoSo you're just creating a user story then. So in this first case, you're just creating a user story to say, hey, we identified some something in the threat modeling process that needs to be done?

20:27Irene MichlinNo, no, not always. That's what I mean. It's not suitable for every threat. So if it's something that can be expressed as a story, that's the easiest case. You just write a story. So it can be either security feature or an attacker-focused story. So you create a role of evil user and you tell your usual template of agile story from the point of view of an evil user. But unfortunately, not all threads are easily expressible as stories. Some of them, some of them are just not suitable to be a functional story and you need to find other ways of recording this work to keep it visible. So some options are make them part of acceptance criteria. Or make them part of definition of done. So say the team has this definition of done that says the code has to build, obviously it has to pass unit tests and to be covered at least 80%, or whatever is the team's definition of done. You can add things to it that will be security Specific things like, if I run it through our static analyzer, it doesn't come with any new errors, for example. And this is something that just cannot be expressed as a story and not something that can be expressed as a task, because sometimes you see these boards where the story is broken into tasks and everything is written as a separate task. Do a code review, run a static analyzer. What happens with these tasks when team is under time pressure? There will always be a pressure to cut, to cut these corners, to remove these tasks, to do them later, and this is, this is not good. But if they are part of the Definition of Done, then team controls them and they are not negotiable. Like, the story is not done until it went through all the security activities that, that we've decided on.

22:54So a kind of checklist essentially that you associate.

22:59Chris RomeoYeah.

22:59Okay.

22:59Irene MichlinSo what I'm saying, what can be a story, make it a story, put it in the same tracker as all of your other stories. What cannot be a story, add it to acceptance criteria or checklist or definition of done.

23:16Chris RomeoSo I'm a little bit confused as to what— in the acceptance criteria or the definition of done, you were talking about kind of static analysis and some of the other things. Do you recommend a specific threat modeling statement in that acceptance criteria that says for— or in definition of done that's going to say, for this feature to be done or complete, it must have all threats mitigated? Is there a catch-all there?

23:44Irene MichlinWell, that would be a very, very strong definition of done. And if team can stay on top of it, then fantastic. But I don't think it will always be the case. Not all mitigated, but at least all analyzed. And for each threat, you need to decide what you do with it, because some threats we can accept. We can say, yeah, it's a risk, but we've decided. We can live with this risk.

24:13Right. So managing risk along with, okay, determining priorities and so forth.

24:17Irene MichlinAs long as a conscious, informed decision has been made, there are options what to do with the threat.

24:24Chris RomeoSo are there any specific tools that you recommend your developers use to do threat modeling at a high rate of speed?

24:39Irene MichlinSometimes low-tech is the fastest. If you just— if you're just people in the room with a whiteboard, it might be fastest just to do your threat modeling with the whiteboard rather than try to get any specific tool. I do like Microsoft Threat Modeling Tool.

25:02Okay.

25:03Irene MichlinI think it's also quite a reasonable learning curve. I've seen people get some basic training, couple of exercises, and they can start using it because it's really similar to any other diagramming tool like Visio. So people already have the skills to start using it. The disadvantage of it is not so easy to export your diagrams to, to anywhere else really, but the threads themselves are exportable, so that's good, in the latest version at least. I don't think it can be used to store threats in it, because first of all too many false positives, And second of all, it will turn into a separate tracker just as bad as spreadsheet.

26:01Chris RomeoYep.

26:02Irene MichlinSo I guess the idea is you build your diagram in it, you discuss the diagram, either doing sort of stride in your head and capturing threads and putting them in the way we've discussed as stories or acceptance criteria or definition of done or whatever. And you can also look at auto-generated threads to see if something interesting was found. But that's another thing I found from experience. If you do these things at speed, then the auto-generated threads are just too much. You get more value from using the tool to build a good diagram and just quickly go through Stride, just with people in the room. Maybe someone can later look at auto-generated threads to see if we didn't miss anything spectacular, but I tend to use it more as a safety net.

27:06Chris RomeoYeah. So, you're kind of using Stride as your kind of foundational approach then, then that you're teaching your developers?

27:14Irene MichlinYeah.

27:16Chris RomeoHow has that been? So, I've had a storied history with STRIDE. And I say that because I started, you know, when I was working in a large technology company and rolling out threat modeling, we started using STRIDE as the backbone of what we were teaching. And then I went through a period of about a year and a half where I started to hate STRIDE because I thought it was too simple and I wasn't— I didn't see like I was getting— I wasn't getting deep enough results from what the developers were putting forward. And then after about a year and a half, I came back to Stride and then I, I saw the beauty and the simplicity again. So, um, that's kind of my love-hate relationship that I've had with, with using Stride as the kind of backbone of a program. Have you had any, um, have you had any, any concerns that Stride is too simple and it's not It's not complex enough to capture modern-day threats.

28:13Irene MichlinI don't think to say something is not complex enough is a disadvantage, but it's high level. Okay. If the people are very much technical, if it's all like, oh, which, which crypto we are using and what is the protocol and you know, what are the permissions on this file, then stride is at least one abstraction level above that. So you can have this initial challenge of asking everyone to go one abstraction level higher than that. Another disadvantage is it doesn't cover everything. So these 6 families of threads are very useful, But for example, things like privacy threats, you won't catch them with STRIDE.

29:06Chris RomeoMm-hmm.

29:07Irene MichlinAnd maybe some domain-specific threats, like you said, it's not good enough for modern times. So I don't know if you are a cloud provider, then maybe some things that STRIDE just won't find for you. So I guess you need to complement it with things like Attack libraries. But as a backbone, you said backbone, I really like it for application development. So maybe there are domains where you need lots more things, but for application development, it's a really good backbone. It's like 80/20. As you get more experience, you can complement it. Does 80/20 make sense to everyone? Yeah. Yeah. Okay.

29:59Chris RomeoYeah, that's, uh, that certainly makes sense. And, um, you know, I, I definitely— Stride doesn't have anything to do with privacy, like you said. And, and privacy is such an important area that everybody needs to focus in on now. So I think you're— I think you've got the right approach there in saying, you know, we're going to use Stride. Stride is— there is beauty in simplicity. Definitely. And, you know, we're going to use STRIDE, and then you're going to layer some domain-specific stuff on top of it and consider privacy. And, you know, in my experience, I've seen that in the beginning, you just— threat modeling is about momentum. And I would guess that incremental threat modeling is about momentum as well. You're going to get some terrible threat models in the beginning, but from my perspective, it's okay just the fact that people are threat modeling.

30:46Yeah.

30:46Chris RomeoAnd they're moving towards that, that new way of thinking about how we're going to make things secure. We're going to find the problems early in the process. And so, I'm okay with them not having perfect results in the beginning and not covering privacy and domain-specific stuff and just going through the stride because they're moving towards a more secure future where their experience will start to come out and they'll have even better results.

31:11Yeah.

31:12Chris Romeoin their 10th threat model than they did in their first threat model.

31:14Irene MichlinYes, that's a very good point. So if you start with something, it may not be perfect, but if it's useful and you're learning and you will make it better and more relevant as you go along.

31:29Chris RomeoWell, thank you, Irene, for taking the time to be with us today and share all about incremental threat modeling. I wrote about 10 pages of notes here as we've been talking. So, this is a topic that I was fascinated in, I wanted to learn about, and we figured we'd share it with our listeners as well. So, thank you for being here. We really appreciate you taking the time.

31:50Irene MichlinOkay. So, from 10 pages of notes, you can compress it to really one key sentence, how to make irrelevant threads go away when you're focusing on incremental. So, the magic phrase there, If we are not making it worse. If team comes up with some interesting scenarios and they're not relevant to what we are building in our next iteration, you go, if you are not making it worse, record it, move on.

32:16Chris RomeoYeah, I like that. I will take that away. We are not making it worse.

32:20That's great. Thank you.

32:22Irene MichlinOkay, guys. Thank you. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.