Rahul Raghavan: Threat Modeling Wins for Agile AppSec

[Music]

[Music] good afternoon everyone and i hope everyone can hear me well and see the screens as well my name is rahul i am the co-founder and chief evangelist at v45 we are an application security focused company um great to be here in besides calgary this is the second time that i'm here in a row i was there in 2020 as well uh i hope to have done this in person this year at least but i know how things are and i'm hoping to do this next year in person um at the leaves and fingers across from that standpoint um i know this is probably the second session that we're doing today on the same topic

around threat modeling i think i just saw another abstract by jalen who probably did this earlier in the day i didn't get a chance to go over that presentation but i'm hoping to kind of i'm hoping that this uh session here kind of adds on a little bit more perspective uh for viewers who've already seen that session um and there's something else that you can take away here in addition to what you even must have um talked about if there are any questions uh please feel free to kind of use the chat window and i'll probably get to it at the end of the session um a little bit about myself just because before we start off um

i have been in the domain of application security for the past seven odd years uh i helped co-found this company v-45 have been in cyber security over the last um 11 years or so um and largely some of the things that really keep me up at night or around are things around application security automation tooling threat modeling and really um driving programs from an abstract perspective especially with large customers in terms of not just the technology side of things but also the cultural um and the procedural aspect of things uh which often um seem to be a big issue with uh transformation projects um especially around devsecops so with that having said so we're going

to be talking about threat modeling in this session but if there's anybody else um in the virtual room who shares uh a keen interest uh in any of the things that you see up on the screen today uh happy to kind of connect and chat more of the um um out of the whole session here and and look forward to kind of connecting well as well uh with that let's get started with today's session over the next 45 minutes or so um we're going to be looking broadly around the following things we're going to be looking about um what threat model is uh in the in in in the current sense of the word um

and not really from a um from a from a logistical perspective but really in terms of what uh it means uh at a at a fundamental apsec perspective right we're going to be looking at a very different uh definition of threat modeling from that standpoint uh we'll also be looking at some failures and reasons as to why threat models usually fail as we know it um and more importantly we're going to be looking at two distinct schools of thought uh from a threat modeling perspective we're going to be looking at two very very different ways of performing threat modeling from an abstract perspective and also going to be looking at a very interesting point of conjunction from both these schools

of thought that we've worked on and especially which is which has proven quite interestingly successful in large scale implementations as well one of the ways to do that is an open source framework that uh we at the folks at v45 develop called the threat playbook it is out there and git for everybody to download and use we're going to be looking at that as well and finally we're going to be looking at how threat modeling uh in this new definition that we look at today seamlessly integrates uh with the security testing framework or the automated article insecurity framework that most of us are familiar with and what is really the interesting points of uh conjunction between threat modeling and

security says testing so to speak so we've got a couple of interesting things to uncover over the next 40 minutes or so so let's get started before we start off with threat modeling i think and this is this is uh this is a slide that i have um obviously changed with respect to the context of the presentation that i'm doing but most of my presentations always start off with this initial screen that really kind of gives you a perspective or a context of where appsec is today and obviously over the years that i've done presentations i keep changing this depending upon the kind of uh customers that i made and kind of and the kind of strides that

various customers have taken on uh but largely uh as we speak today in october 2021 a certain things are absolutely um you can't ignore some of these facts a a huge increase in tooling and test iterations a lot more testing a lot more automation that's done a lot more tools that have been gotten into the ecosystem so there's this whole bunch of tools and test titrations that have been thrown into the appsec pipeline um so definitely something that cannot be ignored and we're also seeing very interesting feedback loops that have been implemented from abstech automation standpoint so what i mean by that is not only have we been fairly successful in terms of shifting left as we probably say but

we've also been able to kind of shift right uh interestingly and what i mean by that is there's interesting feedback loop mechanisms that have been implemented where um metadata from production systems metadata from incidents that have happened in uh production systems have been used as intelligence back in the earlier stage of software development as well so you have a lot of insights that you can now glean from incidents that have occurred and have not been prevented but still you have that metadata giving you very very interesting data for you to build your initial threat models as well you're going to be looking at some of that as well a lot of as code execution models we

obviously started off at infrastructure score we then went into security testing this code and today we are at a point where we're also looking at threat modeling as code so there's been a lot of strides that have been done in the azure code execution model and threat playbook that you're going to see in a couple of minutes is one such example of how we've been able to kind of integrate threat modeling as a code and all of this have obviously kind of integrated with mainstream sdlc this is something that been saying in the application security world for the last decade but i think truly in many forms than not uh we've seen a lot of these

things integrate with mainstream sdlc i always say that the last decade the decade that ended with 2020 was the decade that gave apsec its prime time slot in product engineering we got the 10 pm slot uh or the 9 pm slot in product engineering so the and the way forward right now really isn't for us to be able to kind of scale that to the next level and with the increase in tooling with the increase in automation with the increase in testing iterations uh there's been a huge amount of data that's been resulted uh that's resulted not just in terms of traffic like indicators in vulnerabilities but also in terms of metadata uh that these tools generate so

it's not just the data that we see at the face of the vulnerabilities it's also if there's a lot of information in terms of the story that that vulnerability says in terms of how was it founded which stage was it found what is the class of this issue if there was a vulnerability that was found in a certain stage in the sdlc what kind of strategic initiatives could that product engineering take based on the kind of data they see a lot more of information that we're now seeing um through vulnerability statistics so some of these things have been interesting that have happened um as we see in african security today um when we get into threat modeling one

of the things that i always hear and i'm sure this is the same with many of you all here is really things that people say about threat modeling like there's a lot of casuals in the air that have been built on threat modeling oh you start doing threat modeling you can completely eliminate all kind of issues in security testing when you get there if you've not done threat modeling then you've not done anything in appsec threat modeling is really that utopian world that abstract engineers need to be in so on and so forth and there's been so much that's been said about threat modeling and to be honest some of them are factually right some of them have the

right motivation but then the issue is because of this overselling of threat modeling that's been done from really casuals in the air that have been built um by a lot of communities when people start implementing that at ground zero things are very very different and that's really why we see many of us have meet with failures in implementing threat modeling as we deemed fit um as in in the exact same and share in the exact form and shape that we've heard of threat modeling when we try to implement that at ground zero things are completely different they either fail um and they fail for multiple reasons so let's let's look at why threat models fail but before we

look at why threat models fail i think we need to ask ourselves the fundamental question of what really is threat modeling right if someone came up to me and said can you define threat modeling i would actually take a step back and say it really depends on what the motivations of threat modeling is and for that uh to for us to define threat modeling i'd like to kind of they always like to take the example of the blind men and the elephants and the fable that goes there were blind men who didn't know what they were touching and every part every person was touching one part of the elephant so some of them thought it was something else some of

them thought it was a snake some of them thought it was a heart or whatever it is and from their perspective that was right right because that's the view of the world that that person has and it's the exact same definition when it comes to threat modeling and there is nothing wrong or nothing right with it so threat modeling can actually be if you ask a person in architecture they would say that threat modeling helps them find issues in architecture and design if it's a security if it's a developer or a security tester they would say it a certain counter measures it could be used to simulate attack vectors it could be used to choose technology components

it could be used to ascertain the surface area of security testing in terms of coverage it could even be used to anticipate security incidents in the in the past but what's really interesting is all of this is true it's none of this all of this in today's world is possible through threat modeling so when we look at the definition of threat modeling i think one of the primary primary things that we need to ask ourselves is why do we need to do threat modeling and your definition of threat modeling and when i say you i mean you as a member in product engineering you could be a developer you could be a tester you could be an

architect you could be a devops engineer you could be a qa engineer or it could be a release engineer right so it really depends upon what your individual motivation to threat modeling is and that really is where the definition of threat modeling stems in just like there's an application security there's nothing that is one sides fits all and threaded modeling is also not a one-size-fits-all so one of the primary reasons why threat modeling fails is not understanding why we do threat model modeling right and as we've seen before and we're going to see in the next couple of slides is as well for one of the primary starting points of performing a threat model is to

really understand why you perform threat model right so uh if there was an if if you have a colleague or a friend who who's who's in another product company performing threat modeling and have got multiple and has got good results it does not mean that the same way that you perform threat modeling there would work in your organization because the motivation of threat modeling there would be very different it really depends on who's doing the threat modeling and why they're doing the threat modeling and as we've seen before you could do threat modeling you could perform a threat modeling activity for things such as finding flaws in architecture and design which is the probably the oldest reason

or the most common um reason that you would perform a threat modeling to something very very contemporary um to really figuring out what the impact analysis of a security testing is so the breadth and the horizon of why you would perform threat modeling in today's world is very very different so it's very important in terms of in terms of for us to understand what the motivation to perform the threat modeling is there is no one-size-fits-all and that's the that's the singular rule that that is present in appsec in my opinion nothing is one-size-fits-all in application security and threat modeling is not unique to that rule as well the second reason in terms of why threat

modeling usually fails is is an innately unnecessary over emphasis on how to do threat modeling the moment somebody says oh i want to do threat modeling the immediate follow-up question that comes to do is what methodology do you use are you going to be using stride are you going to be using dread are you going to be using the pasta framework what is it that you're going to use again there's no right or wrong answers the methodology that you use would once again stem from the motivation that you're going to be do that that you even perform the threat modeling right and one of the common reasons that most threat modeling fail is them coming is is the is the team

coming back to us and saying oh there's too much documentation uh there's too much of methodology information that i need to factor in various questions like what tool should i use and why you know what what what what what methodology should i be using and there's this unsaid rule that threat modeling needs to be complex so if there is somebody who does a back of the paper threat modeling they would often question themselves and saying am i doing the right thing it doesn't seem to be complex enough because there is this understanding that threat modeling needs to be complex and it needs to be documented in this hugely complex verbose form and i want to take

this time to say that none of that is necessary it can be as simple as just a back of the paper and i was just doing the threat modeling today i just i just i just i just had the paper fall off but i was doing a threat morning today morning with my team for a uh for an application pen test that we're doing and i'll actually show you it's as simple as just scribes in the paper that i've done this this is literally a threat model that i did today morning and all that it has is mind maps and and and sequence diagrams and and and three structures of just noting down what the impact state what

the what the surface area of the application is who the actors are what the input and the output vectors are and so on and so forth it's not even it's literally the back of some random paper here but the point of the matter is it really depends upon what you're going to be doing with that threat model right so let's not worry about documenting the threat model first let's just worry about what's the what what's the advantage of us doing threat modeling what's the what's the way of threat modeling that works for us and then we would document that right so it's very important that we do that so with that having said that i'm just

going to quickly check if you're okay on time you have a good on time um so having said that let's now get into um these two schools of threat modeling um in my world or in my kind of definition right it's not um it's not something that's it's this is not something that's there all over the world but everybody else is uh uh is is uh prescribing this but this is just purely my personal uh way of depicting this in my view there are two schools of threat modeling uh there is the story driven threat modeling which we'll get into in a bit and then there's a component driven threat modeling now the story driven threat modeling as the name

suggests is driven by stories of an application right there is an application the whole threat modeling stems from a what if scenario what if actor a was to perform this action an application x resulting in this impact y right so it's really based on a what if scenario what if this were to happen what if that were to happen so you ask questions of pessimism from a security perspective um trying to trying to kind of question the status quo of security of an application it's really based on the water scenario so that's the story driven model the competent dribble model is what people are mostly used to it's the way of us determining what the inherent weaknesses

of an application is based off the components that are built for the application so what are the kind of technologies what is the technology stack of the app what kind of programming language is it using what kind of database is using what kind of hosted environment are they using if it's a cloud-based application what kind of cloud services are they using so on and so forth so you kind of fig you kind of it's it's based on the fact that the overall threat of the application is the sum of all the individual threats of the components that are used to build that application so most of the uh most of the threat modeling that we've done in the recent

past is based on this school of thought the story given the cornerstone of a storytelling threat model are the abuse cases water abuse cases it's the way that you would abuse a use case every application has multiple use cases every use case has one or more abuse cases so the abuse cases are the cornerstone of the component of the story driven threat modeling school of thought whereas in the component driven school of thought they are known issues known issues of components if you're using a component x it could be a cloud service let's say you're in ec2 or you're using s3 or something like that s3 and ec2s have inherent vulnerability some of them have been fixed some of

them have not been fixed so it's all generated from that perspective of known issues of those vulnerabilities of those components therefore the story driven threat modeling is usually used in a post design and a dev it can be used even through development because you are really kind of subjecting it to a water scenario so even you could you could use the story driven model even at a stage where the application is just being prototyped it does not necessarily need to be used at a blueprint level but the component driven model is usually used in the pre-design or the design phase because you're kind of really questioning the status quo of the component so you want to be sure that

even before you start using the components to build that application you want to be sure that using the right components so therefore you use that much earlier in the face the by extension of which the story driven model is used by the security professionals and the developer personas of product engineering whereas this component reveal is used for the architects as well in addition to the security professionals and developers the focus of the story driven threat model is on depth obviously you're kind of questioning what if scenarios you're looking at business logic flaws you're looking at edge cases you're looking at multiple other things so the focus of this school of thought is on the depth

of the of of issues whereas that incompetent is usually more horizontal it's more on scale and it's more on breadth um examples of storyline thread modeling unfortunately you don't have a lot of tools that work on this so therefore you usually use you you usually subject your subject the application to manual methods or we've used threat playbook which is our way of kind of starting off that journey with this again like i said it's open source anybody can use it it's there on the it's there on git i'll send you the link as well uh so thread playbook was our way of kind of saying let's take that bit of storytelling threat modeling forward using some kind

of automation however on the component driven side you have multiple tools obviously this is a platform agnostic forum so i'm not going to be using the names of actual tools here but i'm just giving you hints here that most of the commercial tools that you've heard of and used are probably falling in this bucket of component driven threat modeling which is a great way to perform um to achieve scale so today for the rest of the presentation we're going to be largely looking on story-driven threat modeling but just to give you a hint of what complement driven threat modeling looks like it's typically it's a very simple four-step process you have a questionnaire or a wizard where you

would key in the details of the application in terms of text stack in terms of actors in terms of it's almost like preparing a bill of material of sorts you kind of feed in all details of the application including things like are there is it subjected to any kind of compliance mandate like a pci sock or a hipaa or a glba or what not and then you give all that wonderful information of the application to that system and the system really kind of spits out a neat little diagram or a vector diagram or a map diagram of the various components and the kind of interaction that happens with these components from a data flow perspective or a process flow

perspective and then it would also list down the sets of threats and counter measures of those independent or those individual components so like we said you have the ecosystem you have the components you have the components laid out there and then you have the individual threats and of encounter measures of those individual components and you would start working on them so this is really the broad way in which most of the competent level threat models kind of work on now in the story driven threat modeling which is quite interesting and that's what we would like to talk about today uh we're going to be looking at today uh in the next few slides is really the

story difference threat modeling and the anatomy of the storytelling threat modeling is something very interesting so it's always starts off with a use case like we discussed every application has one or more use cases uh which really is which what really is it's that it's what what is the functionality of that particular use case it's a simple functionality statement and that use case would have an abuse case which really is us trying to figure out what are the various things that can go wrong with that use case right what are the various things that you could abuse that use case right so that's the abuse case and then the abuse case would then drill down into an attack model

which is how can that abuse case come to life in the if if there are security engineers in the room this is really weaponizing the use case right so this is where we're kind of taking our analysis or our hypothesis of the abuse case into something more practical which is us trying to see how can this come to life so is the use case there's the abuse case and there's the attack model these are the fundamental building blocks of the story-driven threat modeling for example a use case uh let's say there's a there's an application and for the sake of uh conversation let's say there is a there is a uh there's a user story where there's a

search bar let's say it's an application where you could search for notes it's a note taking app so as a user you would wanna there's a search bar there and you can search for um your notes in that application so that is the user story uh the abuser story there could be two abuser stories that happen to that one of it is as an abuser i could search for notes that don't belong to me um which means that i could search for somebody else's users uh some another user's notes and therefore kind of steal potential information confidential information and whatnot or i could use the search functionality to kind of inject some kind of payload into

the system and therefore have some kind of persistent cross-site scripting attack or something like that where i could use it to steal a victim's credential or blah blah blah right something very simplistic i'm not obviously these are very simplistic examples but just for the sake of conversation right so there's a use case and there are two abuse cases now let's say if i want to exploit the first abuse case which is that of trying to disclose sensitive information i could do that in one or more ways let's say i could do this in three ways in one way i could do that one way i could do that is using man the middle attacks i could use that use i could do

that using injection attacks or i could do that using a url redirection scenario now demand in the middle the injection or the url reduction are ways in which my abuser story would come to life so therefore i would call them the attack models so this is an example of how one user story eventually translates to three attack models so this is just an example but you can it really has a oneness to end relationship a user story could have multiple abuse cases and each of those abuse cases could be exploited in multiple ways so it's almost like branching out a branch out scenario where there is an use case that branches out into multiple attack

scenarios so i wanted to do a demo of thread playbook because we don't have so much time today and i didn't want to you know really kind of take up a lot of time i've actually gone ahead and um this link here um that i would obviously the the the would share this presentation with you um and this would also be uploaded and recorded i'm assuming but this link here if you're interested is the github link where you could you would find all the details of threat playbook including uh videos of how you would use thread playbook and how does threat playbook uh fit into this model that we discussed it the entire thing of threat

playbook is really a threat modeling as a core framework it's built using python mongodb and a graphql interface um it's best suited for a story driven threat modeling like we discussed um and one of the things that you could do with threat playbook is really kind of integrate a threat with a vulnerability in terms of an actual vulnerability that comes from tools so there's interesting ways what we've done is that we've we've taken an application we've threat modeled it we've run tools on that same application like a zap or a burp or sas and seo tools which spits out a lot of vulnerabilities and then what we've done is we've actually taken the threats and

we've tried to map them with the actual vulnerabilities that these tools provide so what that does to you is that you now have a scenario where you have your threats like there are 50 threats and there are 100 vulnerabilities you can now say which threats resulted in which vulnerabilities right so for example if there are vulnerabilities that don't map to a threat that means that you need to improve your threat modeling process because now there is a vulnerability that you did not factor for so you need to go back and improve your threat modeling methodology now let's say there's a threat that don't doesn't link to a vulnerability that means you're in a good spot you've envisaged a threat

but then your application is still resistant to the threat because you've not found a vulnerability so that's a very interesting use case for us to be able to kind of link an actual vulnerability with a threat and in threat playbook it does that using cwe ids which really is what the tools kind of give you too now let's look at ways in which threat modeling as we've just discussed now and more more particularly the story driven threat modeling um uh model how does that kind of integrate with security testing as we know it right so that's what we then that's an interesting kind of a look that we've looked at in this section so you remember the anatomy that we

talked about earlier which essentially is the use case the abuse case and the attack model now we're going to add one more step to this tree and that step is that of test cases so we stopped with attack model which is how can an abuse case come to life a test case is really testing that right how plausible are they it's it's it's it's probably in a very unique way similar to the difference between a vulnerability assessment and a penetration test if you will a vulnerability assessment tells you what vulnerabilities are there a penetration test actually takes those vulnerabilities and tries to actually see if there is a salt to those vulnerabilities right so it's very similar in this place the

attack model tells you what are the various ways in which an abuse case can come to life but the test case will actually test that it will say okay you say there are 50 things that can go along let's see whether they're actually possible or not so again let's go back to the same example that we saw of the search application or the note taking application we had three threat models or attack scenarios that came out of it now each of those can be tested in these possible ways and and i'm not going to go over these test cases because these are pretty self-explanatory if there's a manual middle attack how would you check for a man of the metal attack like if

there's an injection attack that's possible what are the various security test cases that you would subject that index and attack too it's a very simple thing and the ways it means to this is very different depending upon the pen testing agency depending upon the processes that the pentester follows but in a sense what we're trying to do is we're actually trying to see each of these attacks coming to life and actually testing them so the security test cases really kind of um give you that um interlinking possible uh from from from a threat modeling standpoint and when you have these test cases each of these test cases that you see here when you have those test cases the

link to automation is quite simple right any test cases any test case can have three journeys possible the first way that you would a test case would fall into a bucket is if it's 100 tool based that test case can be completely executed by a diastolic or by a dash tool like a zap or a burp or an end map or an or whatever it is right or a w3 af so if if a test case can be purely executed by a tool i would call it a 100 automated test case on the contrary there are test cases that a tool cannot execute right it could be a business logic flaw it could be a logic bomb or

it could be an edge case which requires the trained eyes and the skills of a pen tester now if you have a test case like that you could still automate that and you would do that using automation frameworks like cucumber selenium robot and things like that so just like how you build uh functional test cases using these automation frameworks you would use the same means to build security test cases in a very similar form and then you have the hybrid test cases which means these are test cases where the tool takes you only so long only so further and then you would need a pen tester to carry them forward so it's a combination of the tool and the script

base so it's so things like parameterize dash scans which means you're running zap on a proxy mode uh using qa automation or functional automation scripts so that's an example of how you would uh use the hybrid testing methodology so irrespective of the kind of test case you can automate it you either automate it completely to a tool you would automate it using a combination of a tool and a script or it would be automated purely using a script now with this in mind you could actually kind of imagine the whole nine yards of how you could do this so what happens is that you would essentially there's a new feature that's developed and if it is

so so here's where you would use and especially in large scale enterprises you can't just use one of the two schools of model schools of thought or threat modeling and what we've done is when we work with large financial institutions we've seen that a combination of both of these schools of thought is what works best so you would use the component driven school of thought for you to achieve scale and you would use the abuser driven or the story driven threat modeling to achieve depth so every time there is a new feature that comes in you would first take that application the feature would be developed you take that feature development you run it through the

component develop the component um driven model so you run it through a commercially available check modeling platform and they would give you some kind of list of threats and counter measures based on the components so that's one flow right parallely you would also subject that version of the application to an abuser driven model as well right you would use the abuser driven school of thought and the score story division for you to find some threats on that model so essentially then what you do is you combine both these threads you combine the threats that the stock component driven model has given you along with the threats that the story driven model is giving you and then you have this

unique set of threats that are that is this is really you're really throwing the kitchen sink at it and getting this multitude of threats that you find from both these schools of thought and then you start um kind of working on them so and what this does is that it kind of solves two problems one you're not really depending on the story driven school of thought for you to scale because all said and done the story dividend model is not scalable it's not a scalable model it's not a model that you could use for applications that have 100 releases or 200 releases however you could use that model to find threat models to ensure that your threat modeling process

does encompass within itself very very specific threat models that threat more that that are not component related that are not related to the underlying tech stack but are related to external factors are related to how an actor interacts with that application so all those unique test cases or the unique threat models can be integrated using the story driven threat modeling at the same time the component driven threat modeling still gives you a platform for you to perform base level threat models and what i mean by baseline threat models are low hanging fruits uh the threats that are completely driven through um components uh so in in in the projects that we've run threat modeling for uh what we've done

is that we've used the we've usually worked with an external vendor of a threat modeling platform and we've tried to incorporate the story driven threat modeling with that platform so we've kind of made that platform almost work on steroids if you will because it does what it does well and now it's got this additional plug-in that we give it as well so if it's got 150 plug-ins that that the tool runs on we give it 25 more plugins and it now runs on 175 plugins which now gives you the best of both worlds so this is a very very interesting way for you to perform threat modeling and then once you have all of these threads you can

actually integrate that with your uh security testing framework um and how does threat modeling really fit into agile right and this is usually a um this is this is usually a diagram that i depict to show the devsecops transformation uh what you have on top are the eight building blocks of any security engineering of any product engineering process which is plan code build test release deploy operate and monitor and what you have on the bottom are the five stages of security engineering which is threat modeling sas dashed infrastructures code and then security monitoring and attack data detection right so these are the very specific uh eight and five uh building blocks of product engineering and security

engineering and what the color code really does is the color code kind of tells you how the secured engineering processes integrate itself with its respective product engineering processes for example correct modeling traditionally as we know it has always been in the plan phase right because we've always been looking at threat modeling as just a means for you to find architecture and design flaws because as we've seen today it goes much beyond that so considering that contemporary uh or continuing the whole traditional model threat modeling has always been implant but now with the thanks to threat modeling this code and other such initiatives you're now seeing that orange bleed into the the code phase as well similarly sas

starts off with code runs through build ends with a little bit of test and so on and so forth so the color code of the security engineering process below kind of gives you a idea in terms of how they fall into its respective product engineering process but what i want to point out to you more here in this slide is the possibilities in which threat modeling can cut across all these stages so threat modeling can be used in the threat modeling phase obviously to model stories right so that's the more that's the very fundamental use case of threat modeling you can use threat modeling as a way to derive and drive security test cases you've seen that as well so it

moves into it moves it moves more right as well what i'm trying to establish here is threat modeling is not just at the far left of the security engineering process there is a use case of threat modeling in every stage from left to right as well at the far left you have modeling stories then you have security test cases that can be driven through it you can now use threat modeling as a way to run security test automation and finally you can use threat modeling to actually build detection models as well remember the possibility that i told you about being able to link a vulnerability back to your original threat that is that feedback loop that's possible and

you could build detection models as well so threat modeling in terms of just possibilities and especially for the geeks who are interested in researching threat modeling out there it's just a case that i want to present to all of you all to say that threat modeling is definitely something that's possible for us to use not just as just a way for us to find design and architectural flaws but also as a way for us to kind of work on um towards other means in the software engineering process as well so in summary of this presentation what i want to leave you with is please know what works best for you like we said there is no one-size-fits-all

and threat modeling so therefore it's very unique to an individual stage that they have an individual product team stage in application security so there's something for everybody in threat modeling so therefore it's very important that the teams understand why they're doing threat modding so therefore you can adopt a strategy that works best for you it's it's important and it's recommended that there be a balance between depth and scale because just going one of these two ways will probably not cut it in the long run so it's important for us to kind of ideate a threat modeling process that balances the right balance between depth and scale in terms of finding issues it's important that we make threat

modeling more accessible and what i mean by that is it we have to make threat modeling more democratic it's not just it's it so what i mean by that it's not just a process that one team or one set of personas in product engineering use but we need to figure out ways and means in which various members of the product engineering community are able to contribute and use threat modeling to their benefit as well so how can developers use threat modeling what is what is a qa team have to benefit from threat modeling how can a devops team benefit from threat modeling so making threat modeling more accessible gives you that whole shared responsibility factor as well

especially to qa this is a separate presentation that i've done and you can check out our youtube you know the v45 youtube channel or my linkedin profile and you will see presentations that i've made that talk about how qa is a great uh way um i don't know today qa is used as both a noun and a verb but i'm assuming that if qa is still either irrespective of whether it's a noun or a word qa is a great way for you to integrate security testing um within the ecosystem so that modeling is also a great way for for qa to kind of contribute to the security testing model as well and threat modeling is ideally done in a sprint but i want

to kind of really not quote that because it's easier said than done it's important that before we go to a purse print model of threat modeling let's try and do threat modeling once a year if possible then we'll extend that to doing it twice a year four times a year nine times a year and then you could kind of get it more to a sprint model because what companies usually do is they they have this utopian dream of doing this only per sprint and if they're not able to do it for sprint they have a problem so let's set expectations accordingly it's ideal if you do it on a perspective basis but like i said it's an ideal it's not a

practical but it's always important that we do it as frequently as possible and therefore we adopt the ways in which you could do we could use that we could do that as frequently as possible in finally a good threat model is something that's incremental that allows you to be consistent and finally enables you to be to make it as collaborative as possible so with a good combination of incremental consistent and collaborative nature you can potentially make threat modeling a very very ideal piece within your software and product engineering process so with that i'd like to thank you for the time um by the organizers have given me in this year's um bcs as well i hope this was

useful this was um you know interesting and added more context to the earlier presentation as well so if there are any questions i would be available in the chat window generally or i have my credentials here and you could find me on linkedin as i don't have the linkedin id here but just google up my name on linkedin you would find me there i'm happy to kind of connect with any and all of you and have this conversation forward so with that said uh thank you again uh for giving me an opportunity to present here and i look forward to interacting with more people here thank you so much and have a good rest of