Improving Cyber Risk Management with Threat Modeling: Alyssa Hartford

okay hello everybody Welcome Back for those who stepped out to take a break um that was a great chat with Mr Gupta um and I think it's a great uh tie in to now hand it over to Alyssa Hartford who is an information security officer within the government of Alberta of Alberta Alyssa will be walking through improving cyber risk management with threat modeling from an introduction to her experiences within the government of Alberta to describing how it can relate to risk management practices so over to

Alyssa perfect thank you for the introduction so good morning everyone yes I'm going to be talking about how you can improve your risk management practices through threat modeling because ideally these things are done together and your threat modeling that you do beforehand should tie into risk management so I was given an introduction but my name is I'm an information security officer with the government of lamberta and I'm actually within their work experience program if you've heard Martin talk about it meaning that I've had experience in the risk management team and I've had experience in the application product security team which is the team that's been uh doing the threat models more often uh within our

teams so for today's presentation I have a couple goals that uh I want to accomplish and for you guys to take away the first I'm going to do is try to inform so whether you do know anything about threat modeling or you're still new to the topic maybe you'll learn something new second is I'm going to highlight the benefits of threat modeling and why we do it and the third is I want to encourage the adoption of threat modeling within your practices even if it's at a small scale and to do this I have this uh very small timeline uh being that I'm going to introduce uh threat modeling I'm going to go over an

example I'm going to tie it into risk management and then for the remaining time about 10 minutes I'm going to go over a Q&A so let's jump into that introduction to threat modeling before I go any further I'm going to go over the definitions that I pulled from oasp um it's a great resource for just getting into threat modeling but a threat model is a structured representation of a system uh through the lens of security so in other words it's a view of the system in terms of its security just like a data flow diagram is a view of a system through well how the data flows a threat model is a similar view but for

security you ever Googled or looked at threat modeling before you might see that uh it looks like a data flow diagram it's because it kind of uh is linked together but you're shifting that Focus onto security and then threat modeling being that verb is how we get to that threat model it's the process in which we analyze and prioritize and gather all that information that ends up being put into our threat model so the threat modeling is how we make those informed decisions on the security of the application so then moving on there based off of that definition I gave for a threat model what makes that model special and makes it a threat model

because as you can see here sorry I only have one laser pointer for one screen um but the blue elements are elements that you can take out of it and model on its own and potentially make a data flow diagram out of it or a different view of the system but once we add in those red risk elements we've changed the focus of the model from looking at maybe the data flow to looking at the security and that's what makes it unique and that's what makes it especially valuable when showing it because you're putting that focus on the model of the system to the security so I'm going to go over a brief highlevel overview of threat modeling um

in general the first box being why are threat models important to develop it's a great question and there's three kind of main reasons one is that it's a proactive tool you're proactively identifying threats and risks in the model because threat modeling is something that you do ideally before you've started coding at the beginning of your solution and your application development life cycle the second point is probably the most important point and that's being that it allows you to understand the threats and the risks in the solution but what it does is it allows you to change and modify the solution because once you've identified those risks you're able to then identify mitigations mitigations was one of those

red elements in that image I had shown and then you've evolved that solution and you can threat model again to make sure you haven't introduced anything but because you're applying these mitigations you're changing the system and the nice thing about threat modeling producing a model producing a report after it is that if you're going to change the solution you're probably going to have to get approval for it and you need to convince your stakeholders as to why you're either spending more money on changing the solution or why the design is even changing in the first place if you've modeled the solution with the threat model produce that list of risks produce that list of threats

and show it to your stakeholders you have a better case to explain why you need to spend x amount of more money or why you need to change the design you get a little bit more uh buyin from your stakeholders from the business decisions on the model and then the last one is a little hint into how we're going to tie it into risk management but because you're proactively looking at at those risks you can then take those risks and apply them into your risk assessment process because you've already identified a good amount of risks our second box is who benefits from creating the threat models these hopefully are decently obvious uh bullet points but it's h you're looking

at your risk so your cyber Security Professionals obviously benefit from helping also your developers in doing the threat model thus being able to provide input on maybe some of the threat a risk they've missed your developers and Architects are the key players in this because they understand the environment they understand what the environment is what the application environment is as well as potentially or hopefully what some of the controls or mitigation that you can add in so having them perform the threat model is a lot more valuable than someone coming in and not knowing what your environment is looking like and then the last two kind of go together as in saying well actually anyone can do a threat model

because it's it's quite simple it's it's a diagram and you're looking at those threats and there's tools to help you out with that but again with that time with those stakeholders being able to show the stakeholders where the risks are and why you need to make certain decisions about the solution is a lot of or is valuable for uh you and and for your teams and then the last box is when should the threat model be created so I put this box last but it should probably be the first box because it's a proactive tool it's something that you do ideally before you've even started any type of coding it's actually something you can do with just the concept of what the new

solution or the new application is going to be you know I just you know want to build an application from my head you know I can just model it out to then see where those threats are so as I go through the process and developing or not developing it but making out the plan I'm already eliminating po potential risks by having that model I've done beforehand so at this point I've given you know an overall concept of it and you might be wondering okay then how do we actually go about doing it or what tools can I use because we love tools um and my answer to that is I'm not going to give you a big list of tools because

tools don't do the threat modeling threat modeling again is is a process it's the analysis action so if you rely too much on tools they only get you if at all even halfway there in terms of threat modeling because you need to prioritize and analyze deeper and as for Frameworks it's somewhat similar to the same thing because threat modeling is a general concept there's a lot of different types of Frameworks that you can utilize you can use more than one together but again the Frameworks don't do the threat modeling they just help you do some of those steps so the two most popular Frameworks I'd say are probably stride and pasta I'd say stride probably beats

pasta in terms of popularity if you Google threat modeling the first probably 20 articles and videos will introduce stride to you uh stride stands for spoofing tampering repudiation information disclosure denal service and elevation of privilege basically when you go through the threat modeling exercise you classify each one of your threats and risks into one of these six categories which makes it quite comprehensive it can make it complicated but again because it's so well documented and used and has a lot of examples it makes it quite user friendly especially if you're first getting into it past it on the other hand I have on the board just to show the diversity in terms of threat modeling Frameworks

because it's I won't say the opposite but it's a completely different style of threat modeling framework because it's a process it's the process for attack simulation and threat analysis so instead of categorizing threats into one of those six categories it's a seven-stage process that you do from stage one all the way to Stage seven that's taking through you through a threat modeling process and pasta also focuses a little bit on um the attacker side but it's a different way to look at it and one is not better than the other it depends on your environment it depends on your organization culture and it depends on what you're threat modeling for I have tools on the title of this

slide so yes I will introduce some tools but again I'm not going to give you a giant list I'm going to give you I have five tools technically one is not a tool um but these tools again they don't do the threat modeling if you're familiar with it yes Microsoft threat modeling tool has an automated stride model that doesn't do the threat modeling for you you still have to take that automated set of risks uh analyze each one prioritize each one and then go into deeper and apply or Not Apply but even think of the mitigations for them threel I put on here again for that little diversity inclusion because thel is actually code based tool so you apply it into your

code and then it uh you've set a bunch of rules and it will automatically generate uh its list and reports Etc but it's a completely different style of applying a threat modeling tool o threat dry gon is a quite a cute tool that uh is easy user friendly to use and then the last two here aren't tools that are specific to threat modeling because again threat modeling isn't something that you need a tool to do you can use something like draw.io that's just a diagramming tool create the diagram and then using my last hidden tool that's not a tool people which is actually just communicating with your team communicating with cyber professionals And discussing that diagram that you've

drawn and where those threats and risk can be going through the actual process of threat modeling in the end with your team is almost more valuable than anything a tool can just spit out at you because you're critically thinking a little bit more on what those threats can be specific to your actual environment using that knowledge that you have within your organization to know where those weaknesses can lie so then let's get into oh it there let's get I that was a sneak peek let's get into the actual process so this is a five-stage process that we've been uh kind of applying within the Goa but not all threat modeling process has to follow these five stages pasta is

a process model it has seven stages and in the end you're answering like four general questions so as long as your process answers the four general questions you've gone through the threat modeling process so those four questions are what are we working on you need to know what you're going to threat model in order to threat model it right so this is you know bringing a team together looking at all the different um elements of the system that you're going to threat model again because ideally you're doing this before you've even started any kind of formal devel development for the system it's just the concept and the ideas that are being thrown out so what are the end points

the trust boundaries uh the assets Etc that you kind of gather and maybe model in this area the second question you're going to ask is what can go wrong this is basically the bulk of the threat modeling where you actually decompose a solution and then look at where those threats and weaknesses can lie maybe you prioritize them in this uh section of the process or maybe you just have them out as a list and then you move on to the third question that you're going to answer which is what are we going to do about it so this is looking at where those mitigations are applying those mitigations uh in this process here we deliver the model um for approval and

then we get it back maybe we've applied those mitigations but then this is where we start to iterate because threat modeling also isn't just waterfall step all the way down ideally it's also evolving with the application as you've inut in those changes so that you don't introduce a completely new Breaking vulnerability or threat within your system after trying to mitigate something else so you always kind of model it back to make sure that everything is uh all good and clean and then you can perform your updates so you put it into the one uh process category anyway and you're kind of done for the time being until you've added maybe a new change or the

requirements for the solution you're developing has changed and then you kind of repeat the the two processes again but you don't have to go from scratch you just go where you've left off and then the last question you ask is did we do a good enough job so this is your Lessons Learned this is a quite important piece of threat modeling that shouldn't be skipped uh because once you go through your Lessons Learned you'll start to see those Trends maybe things that are similar a similar system in a the same environment is going to have similar risks probably sometimes maybe arguably the same risks so when you go through this process and you're looking at those risks can take note of what

risks are reoccurring and maybe that's a deeper evaluation on do you have a weakness within your environment that you need to uh address you know at level zero instead of just keep applying surface level mitigations right so you're able to see a little bit more about your environment when you go through uh the lessons learned because you can see those Trends and so when you redo threat modeling again for maybe a new system you're also able to go well I know we have these threats these risks in these areas so we're just going to preemptively apply those mitigations and uh continue on with maybe a deeper threat modeling analysis on the system so I'm going to pause there on

the explanation and kind of dive into a little bit of example so this example I decided to do via screenshots because I use the Microsoft's threat modeling tool just to speed up the example process and it's quite cumbersome to demo live um but I'm going to kind of focus more on the process that I had kind of explained and how on a high level you can go through threat modeling um uh with a concept of an idea and then how we tie it into risk management so again let's say we have you know I get told an idea of a new system that's coming in right so I don't have this diagram yet instead I'm told

you know we want to create a new application and that application we want to store everything on a database and we want to make it easier for the people who are accessing it uh to just access it through their browser now so hearing this kind of story it's like okay let's just model it out in a high level data flow diagram which is what this kind of ends up being and then I look at it and go know even though it's simple it's not risk-free so let's look at what those risks could be for this system and then prioritize and with the team we'll go through and we analyze and then we'll hand it off to risk

management so that's what we do we put you know this model into the Microsoft threat modeling tool maybe use that tool maybe you don't but then it's going to spit out a very large list of risks that I don't know if you can read but honestly doesn't really matter so the tool autogenerated 26 risks that are all high priority so it's screaming at me that this is you know high-risk solution that I have created with my like three elements right but not all of these are going to be high priority I'd say less than half of them are even relevant to our environment because the tool doesn't know what my organization is like it doesn't know

what controls I already have in place it doesn't know the properties of the elements right so it's just going to spit up a list of very generic threats that it sees but this isn't completely useless in terms of what I want to do with it because this is a nice Baseline I can take this you know I can edit some of the things change that priority maybe say from not started to just like completed it's not relevant but then I can take this list with the team and we can start to go through and now prioritize which ones you know aren't relevant and which ones maybe we should look closer at uh in in terms of our team so then

that's what we do and then I didn't finish the list but I just kind of took and went you know let's say you know some of these are low priority so they're not even relevant to our system some of these let's say are median priority so if we have time to evaluate them maybe we will and some of these you know potentially could be harmful or maybe there's a risk there so it's something we want to look deeper into so that's what I do with the team team and we kind of get this output so at this point we haven't finished the threat modeling but we've done it enough to a point that we've gone at least some

sort of value on it we've prioritized risk that we want to look into further and uh evaluate what kind of mitigations we need to put in place or if we already have those mitigations for this list of risks at this point I can print out this list I can print out the diagram or not print it out but turn it into a nice documented PDF and provide it to the stakehold are provided to the team lead and kind of explain you know we have you know these potential threats so we're going to look at mitigations for it so then at this point I'm going to switch over to the risk management piece because my presentation is called

improving cyber risk management so I should probably talk about the risk management piece in it because there is a tie in it's not as sepis it as may seem and up until this point even though I haven't explicitly talked about risk management I've already introduced the ideas on how they're tied together so before I start I'm just going to briefly Define risk management and uh talk about it just to cover all the bases so risk management uh I briefly just put out the definition to be the ongoing process of identifying assessing managing monitoring and mitigating risks basically a key component of risk management is our trusty CIA Triad being the confidentiality integrity and availability of data so as long as we

can maintain these three pillars you know to a good enough extent we have a pretty secure or idea of what can be secure so when we evaluate risk management when we also evaluate our threat model we're also kind of looking at you know what is impacting our CIA Triad and trying to mitigate those and then on the left is our trusty risk equation being the product of likelihood and impact and this is kind of where threat modeling ties in the most so when we look at the likelihood the likelihood is what we know about the threats and risks compared to our environment so if I have a house that has all the doors and windows locked and you try to break

in you know maybe lower risk if I have a house that has all the doors and windows unlocked you know maybe a slightly higher risk and if I have a house that has all actually has no doors or Windows you know maybe I have higher risk the impact of someone breaking in for all those scenarios relatively remains unchanged but the risk exposure is higher because of the likelihood of someone entering the house when I have no doors versus when I have doors that are locked or have doors that are unlocked so that information from the likelihood stems from the threat model because when we threat model we look at the application specific to our environment

so basically by the time we get to our risk management activities we already have an idea of some of the security risks and then we already have an idea of the likelihood of those security risks occurring within our environment so then that ties back into risk management because once we get to these steps these activities so they don't all hop in at the beginning at the same time we're doing that threat modeling you know we're able to seamlessly transition over into our risk management activities so threat modeling is complimentary to risk management in short because it proactively supports those activities if you were in the uh panel discussion yesterday talking about uh the supply chain and Dev SEC Ops um

you know I'll quote a little bit that threat modeling is the ultimate shift left so threat modeling is part and one of the activities that you can use in Dev setups because again you're doing threat modeling before you've even developed you know a physical product so you've done that shift left on a looking for that security beforehand before you've even touched risk management right and keep your teams accountable you know in the DU way we've created our security Champion role right and that's maybe one strategy that you can also use when you're trying to incorporate Dev Ops or you know threat modeling in is having someone accountable you know to doing these kind of activ activities so that you can

incorporate them together U either with risk management or on their own so then a little bit of a success story on how you know we found value in actually using threat modeling and tied it into risk management and putting them two and two together so the first is that it's been able to support our risk assessment process right we have a list of risks either before or during that risk assessment process you know makes the risk assessment allows to focus on maybe other risks operational risk or Financial Risk depending on the application or the solution the second point of value is that we've been able to proactively identify risks um I think I've mentioned this one quite a bit but

we're able to look at those risks before we've even started to assess in terms of risk management the third is that identification of a wider variety of risks so when we've been doing threat modeling because you're able to take in your development team which have different Specialties and different knowledge in different areas right you're able to look at the risks in a different way than let's say if I just did my head you know tried to do threat modeling for a system and I don't have like very specific knowledge on I don't know encryption or something like that you know having a team come together and do the threat modeling together you're able to gather that specialized

Knowledge from different members and I identify different risks and potentially their areas of expertise that you would have missed if you tried to do this alone or put this activity or risk management in general on someone who doesn't know everything about the solution that's been trying to that's trying to be developed and then the fourth one is that improved understanding of the system right so with uh this uh togetherness because we have that diagram that has all those risks because it has you know stems from a data fard diagram as well we're able to get a better understanding overall of what that system looks like and what that system is possibly doing so that again

we can kind of pinpoint some areas and you know question maybe the reason why something is being developed in a certain way uh based on that diagram that we have created at the beginning at that concept stage so then tying it back into our example because like I said we weren't quite done I'm going to take that same screenshot and just for this example I kind of pulled for half random uh risk from this list to say that you know these are actually super high priority in my organization um and I need to evaluate these and apply these earlier into risk management and add them into our risk register so then I take those and I move

away from the tool and then I move towards something that works within our organization and I put into ouris risk register format so here I've taken the same risks the same titles but now I've evaluated their likelihood I've evaluated their impact the exposure is automatically calculated from that I've decided if I'm going to reduce or accept you know I guess technically these would all be reduces with the mitigation in place but you can accept and say this is the mitigation we have against these risks and then I have also evaluated that mitigation and said that we're going to do this or we've already done this and this is where the threat modeling kind of takes a pause and then

gets transferred over to risk management to then manage the risks in their own processes and then we can move forward with the application or sdlc process or a Dev setups process so then the last couple slides I have here is you know again bringing it back into like is there value in this because at the J way it's not like we're extremely specialized in doing threat modeling it's still relatively new but because it's still relatively new I'm able to talk about the ups and downs in using it uh and a little bit more relatable in our in our experiences so we have good and bad um you know nothing is ever perfect and especially with

threat modeling with there being lots of different tools different Frameworks uh there's it it's not all going to work for everyone and it does take a while to figure out what is going to work for for you so on the good side um that word again practive identification of risks obviously has been great we're able to look at them and then apply them into our risk assessment process but then the real good one that we've sound is that the visual model part of the threat model has been able to give us a different perspective and also see different areas we may have missed so especially in our risk assessment process if if we're not um

doing that process with you know a visual model of the system we may be missing some key components that they want to apply into their solution or application but if it's modeled out in a thread model we can poke at it and ask questions why are you doing it this way that's not very secure and then they can change it um but if they're not doing that or if the cyber security s we not getting that visual model we can't ask those questions UPF front in instead maybe we discover those questions through a bunch of different meetings and someone slips up and says that we're doing it this way whereas here we can visually see it and then make any

changes we need to do um on the tooling so on the positive side you know a lot of tooling is free a lot of tooling isn't free a lot of tooling specializes for different things Frameworks too uh specializes for a bunch of uh different types of organizations if you wanted to do like private privacy threat modeling for a system that deals with more uh sensitive matters or needs to address privacy regulations know this Frameworks and tools for that and a lot of them are free a lot of them are specialized for threat modeling there's also tools or a sets of tools that may not be threat modeling specific but have like a threat modeling module um but in general it's

it's been good using some of the free tools because again the tooling doesn't do the threat modeling so by not focusing too much on what tool we've been needing to use and more in that group process of communicating and going through the steps of threat modeling has been quite valuable um and then uh I guess my last point on the good side is that the model has been able to evolve with the mitigations right the model doesn't disappear after we've done the threat modeling where we keep it you know if things change we then revisit it and that has also been a lot of help because it's not something that disappears very uh easily in that sense

and then on the lesso side so my main point of focus is that first point so you do need technical knowledge to do threat modeling because if you don't have the technical knowledge of the environment of the controls that you have in your uh organization um or anything about the technical aspect of the system that's your threat modeling you're not going to produce a model of of value so you can't just bring in one random consultant to do threat modeling for your idea of a system because again fet modeling stems ideally before the code so at this point you don't have anything to show for you just have an idea so you need someone with the technical knowledge of what

that idea is actually trying to uh provide and produce to be able to do that threat modeling so it's difficult to just have your cyber security folks do threat modeling you need the developers actually building it because they know what they are going to build and then again with the content overlap so for us because it's relatively new and we do our risk assessments relatively early in the process we find that sometimes there's that content overlap with what we're trying uh to provide in terms of risks we've been able to kind of mitigate that by saying you know the threat modeling produces different types of risks that go on a risk assess but still it's a very similar concept

sometimes depending on how mature your risk management processes are and that complex Solutions may require more models or may require a different type of tool if you have a very very large system it's quite difficult to model that in a tool like the Microsoft threat modeling tool because I only only have a limited space for what I can model for um and then it's going to produce a thousand risks uh in its automated uh stride model um but there are tools that out there that you know are meant for complex Solutions but again it's something that you have to evaluate and is dependent on the system it's dependent on the organization uh and Etc so there is some thought that has to go

into you know what tool that you're going to use to help you with it and so with that I'm going to close off the presentation I had those three goals right to inform hopefully learned something new about threat modeling or maybe reinforced your bias I either one the second is I wanted to highlight the benefit of threat modeling so hopefully uh you've understand some of the value that's in there and then the last one hopefully to at least some of you that are maybe developers or have or work within those teams to encourage you to try to do some of that early stage threat modeling when you've just had the green light approval you know to build a

new uh application or a new solution to try to do that threat modeling stop right at the beginning and then if there was anything to take out of this presentation it was these three points one first is system design when you do threat modeling if you do it correctly you're able to apply those mitigations and evolve the system to be more secure right off the bat second is that PR proactiveness piece threat modeling is a proactive activity for you to do again it's supposed to be done at the beginning and that proactive identification of risk is going to be of high value and the third is that communication piece threat modeling is something that you do together with your

team it's something uh that has a lot of value in the process and in the communication you have throughout and not just using a tool and generating a list of risks so with that for the last 10 or so minutes I'll open the floor to any questions

hi there um great presentation uh I saw one of your slides references to Dev SEC Ops we talked about um software development have you seen or do you see value in threat modeling being applied to uh more of a say out of the-box solution so you say you're you're deploying several different out of thebox software elements or Hardware Solutions products and you're putting it all together and you're just peace mealing you're creating a solution out of things that already exist have you seen threat modeling being used for those types of deployments yeah definitely so uh within my role and what I've seen I haven't seen it done uh exactly like personally however uh that is something that can be

of high value and and definitely something that that should be done with threat modeling um basically again because uh even if you just have the concept of it or what not uh the threat modeling does have value in looking at it right so even if it's not something that's done in its concept stage and it's something that already exists it still has value it doesn't lose value just because you already have something right so it's going through those motions you know maybe at that stage it's not called threat modeling but really if you're going through those motions it it is

modeling so I've had a problem with uh using things like the CIA triangle and the the product of of likelihood and uh impact of seemingly oversimplifying things to the point where where they lose meaning case in point uh bunch of my Aviation research was likelihood of things happening really very very very low impact plane into ground you know that kind of impact um but by the math it's well that's a really low prior we shouldn't you know worry about that as somebody who flies a lot I'm kind of like maybe you should spend a little more time to make sure that is less likely than that uh there seems to be a lot of times

where where things a overs simple ified and and you've lost meaning to it where it's it's a number oh it's a one out of 10 well that one is 400 people um how do you bring some of that back in as to to adjust those priority levels yeah that's a good question so uh one of the things that I had talked about in the presentation was having uh those people that have that knowledge within your organization within the environment also do part of that prioritization right so even if the likelihood is quite low but the impact is quite High um you know to the numbers it may mean this but if you have that team that's evaluating

it and you know quite critically this actually should be higher priority you know in the end they still have the authority to uh put that fourth as a higher priority item within the threat model and again because a threat model is something that you've done beforehand ideally when you evaluate that this could be quite a high risk or vulnerability you've you've preemptively put in mitigation or thought of mitigation before you've even started developing it so ideally what happens in threat modeling is that you're not introducing those risks that you have identified into the solution um because then you didn't accomplish that last step of threat modeling which is did we do a good enough job right so if it is

something that is a high impact ideally you're still not ignoring it it's up to the business in the end to decide where they want to accept that risk that's put in place and you know once they do that um it's not not that it's final say but you know that's in their end their decision but if you've identified it and you're able to mitigate it beforehand you've done your job in threat modeling and you don't then ignore what you've done in the coding phase and then reintroduce that r

yeah for an ex for an existing system you know at that point the the threat modeling and it's almost a different conversation because an existing system you know maybe it's called threat modeling but maybe you're doing more threat hunting um if the system already exists because it's already exists so the threat modeling concept which is doing it before the system exists would have changed to threat hunting looking for uh threats that have been introduced there thereafter hi I have a question I'm curious to know what are your thoughts on um because I've heard about dread dread modeling as well um I know it focuses more on um risk assessment for impact likelihood uh versus stride which

seems like it focuses more on attact VOR and and so I'm curious what are your thoughts pros and cons and and and what do you think in general yeah yeah so um if you take a look at the screen I did take a list of some pretty common threat modeling Frameworks um I've never personally used dread so I can't speak on my personal uh opinion on it but one of the like differences in use cases that I that I have here um you know dread is using for I have here scoring and prioritizing uh the threats against numerical values of each category whereas stride is like best suited for categorizing um you know uh based on

kind of more of that structured uh system so it it really again depends on what the system is what your organizational culture is and what is best going to suit the uh application that you're trying to threat model again and that's a step that you have to do at that first stage of the process where you're looking at what are we going to model against part of those steps and stages is looking at what framework is best going to suit the actual application uh that we are you know have that idea to build right so uh like I had mentioned in the presentation too like if the application is more privacy focused then maybe neither dread or

stride is best and maybe you do lynon which is more privacy focus in terms of its model so it it does really depend but that's part of the process is to evaluate which one is actually going to be of value and if you can't decide maybe you do both it doesn't hurt to do

both thank you so just I'm curious about how do you integrate or factor in third-party vendors or uh external dependencies into your tread model yeah so that's also a good question so when it comes to uh third-party vendors it may amp it up a little bit in terms of complexity um but if it's a vendor that you already have you know potentially uh going back on looking on systems that you already have in place and maybe kind of modeling based on that can help you out if it's a vendor that you've never uh hired on before one of the key things to think about too is um you know how early into that process you've done that

threat modeling so maybe you threat model more on how that's going to integrate on your environment side and then once you've decided on what vendor to use then you threat model again with that uh vendor's information that that you have um it's a unique question because I haven't personally dealt with that kind of situation um well I sort of have but there's enough uh information out there on the vendor's page on you know where they gather that information or where it's going to come from but then I look more at the link onto how it's going to impact the system on our side and where those uh threats are going to be um because I you know you I can't solve the

issue on the vendor side but I can think of how the wrists are going to affect us on our side thank you okay