Threat Modeling Wins for Agile AppSec by Rahul Raghavan

um great to be here uh as besides dublin thanks for having me so a little bit about myself um i'm the co-founder and the chief specialist at b45 uh we're an application security company and pretty much um helping product teams kind of implement a lot of abstract uh solutions and helping them scale and things like that um today however we're gonna be talking about one of the things that keep me up at night which is that of stress modeling but um really my interests are largely from a perspective from a different spectrum from a difficult standpoint um very happy security fantastic 2.0 and things like that so um happy to kind of chat and network with

anybody else who has similar interests uh once the program is done okay um over the next 45 minutes or so uh the core of today's presentation i've been kind of looking at another presentation so probably for those who are expecting a very deep down technology a technical presentation this might be a slight deviation because this is more exploratory from that perspective because of the fact that threat modeling as a domain itself um is is quite fluid so this is one of those presentations that i've intended to kind of keep a little bit more uh you know fluid if you will and essentially you're going to be kind of presenting uh some schools of thought of why threat modeling uh

possibly fails in um really large scale aspects in terms of security programs that have a lot of uh uh i traded processes and also kind of looking at uh two uh potential possibilities of trying to kind of see uh what potential opportunities exist within the threat modeling space for us to kind of have the capabilities to scale it at the speed of product engineering um so that's really uh the crux of the presentation um and and and we're going to probably end the presentation with a small demo of a thread playbook which is our open source uh security uh tech modeling that's called a fabric that we put out there on git and we're going to kind of show you in

terms of how we fly [Music] so let's start off with um a really uh the state of application security today right so we're largely looking at um an increase in a tool adoption be fast dashed sda so whatever it is right so you're kind of seeing a large uh adaptation of two way in which obviously needs or is intended for uh higher uh test titrations uh and thanks to the holden seconds model we're also seeing a lot of feedback loops not just shifting left as probably speaking but also seeing a lot of shift right in terms of adoption of automation and feedback loops at a hrd monitoring phase as well and you're also seeing a

lot of as a code execution model it started off with securities code invented infrastructure scope and today what we're going to be talking about is threat modeling this code because code as a fundamental piece of element is something that's really kind of um being the catalyst if you will in terms of uh the whole application security automation space or in the that's the top space you're gonna kind of see today in terms of how the azure code model fits in within the threat marketing space and obviously um there's a lot of impetus today in terms of metrics and metadata and and and one of the things that i personally like to follow is in terms of

metadata or vulnerabilities because today uh not only are we kind of attracting vulnerabilities from a high medium low severity perspective we're also trying to understand in terms of what the potential story uh behind a vulnerability is because obviously every vulnerability has a story and if you start to look at really metadata that vulnerabilities give out beyond just the traffic light indicators there's a lot of interesting uh kind of things that could come up there but that's for another day uh but uh really to kind of look at threat modeling and this is this is the same that i really love and something that i put together you know if threat modeling if if applicant security was a website uh

threat modeling would be the page with the highest bound rate because that's simply because of the fact that there's a lot of things said about threat modeling in terms of channels in the air they're saying that you know you could fix a significant amount of issues even before they're recorded or in terms of saying that uh you know pet modeling um you know without faith modding up against hrd nothing so you know there's a lot of a lot of things that said about modeling and this is over the last four or five years before that sort of um uh noise uh in the apathy security world as foster smalling is concerned in terms of things that

chesmar we can achieve and and how is it going to help i think it's a query programs but really at ground zero uh this is not necessarily happening because one of the things that i've personally seen in the last decade of working with apple security teams is the fact that that necessarily doesn't really translate to real world implementation of that modeling and more so in terms of implementation of trade modeling especially in organizations where we see product deployments and applications iterations at scales we're talking about people deploying uh every a minute or every hour and how do you kind of see the same concepts of this model really kind of fit in those kind of uh

infrastructures so one of the things that we'd like to talk about in terms of why do threat models fail but before that i think it's quite essential for us to really understand um what's a definition of threat modeling is and i think that's really the fundamental building block of looking at responding scale and one of the things that i really like to kind of compare threat modeling is really uh with the blind man and the elephant right because you have multiple viewpoints in terms of what threat modeling is back to the old problem for fuel threat modeling could be getting issues in design and architecture for certain others in the in the developer space it could be about

certainly what the countermeasures retreats are um for us in the security domain it could be an efficient reverse to simulate attack vectors it could be a way for us to choose technology components better testing coverage anticipate security incidents and things like that but really the definition of threat modeling is really coming from a perspective of what is your motivation to print model right it doesn't really matter in terms of what the definition is because i think that's where we're getting really caught up and product teams today are really getting caught up in terms of really finding the sweet spot of what the definition of technology is as opposed to really understanding what your motivational technology is

and as you've seen before uh one of the things that the whole shift left model uh is kind of bringing into up against the charity is the fact that as as much we're talking about or breaking the silos between teams they're also seeing that the silos there's also a shared sense of responsibility in terms of potential activities like threat modeling that spread across the cardboard engineering flight cycle so obviously trademark plumbing is not something that was only done with architecture teams to make a monitoring something like that security teams with devops teams to start with developer teams so each of them have their own motivations in terms of what they're planning to achieve or express model so i think the primary

objective uh before we start looking at the look at that model is really what the motivations are and one of the one of the primary reasons in terms of why that models fail is really not is really understanding or not understanding why we do test modeling right and like we see in the previous uh slide there there are multiple reasons why you could do threat modeling the fundamental reasons why people started doing such modeling was really to kind of look at potential issues at an architectural or at a blueprint level even before you started writing your first line of code which is great which is still valid but today it's gone much beyond that there are multiple reasons or multiple

use cases of potentially uh performing threat modeling one of the things that we're going to see today is in terms of the [Music] because usually threat model is something that's usually done from a component or a defender's perspective but we're also going to see in terms of how stretch modeling can be used uh from an attack uh from an attack perspective what we'd like to call uh uh driven test marketing so that's one view of the world in terms of why you would do click market and like you've seen earlier there are other views of the world as well you could do it from an architecture perspective you could do it from just just try and understand what the test

coverage of your security testing is so there are multiple reasons um in terms of why um you would need to do threat modeling so before we start talking about test modeling before teams is really go ahead and start implementing threat modeling i think that needs to be a very fundamental understanding of why is it that that model is being done not just by that organization but also in terms of why do we need to do clip modeling from that team's perspective as well so obviously just like with anything in application security there is no one-size-fits-all and that's the beauty of absolute right uh and that's also the beauty about abstract modeling uh there is no

one-size-fits-all from a from a smalling motivation perspective so one of the second reasons why a threat model in my opinion we've seen fails is really because of an over emphasis of how good brutality should i you should i use a pasta uh framework do i need to do venus do i use octave do i use a stride uh you know it which really start getting uh bogged up down in terms of what methodologies to be used uh or we start talking about what two squared is can use an open source tool and i use a commercial tool in terms of even before we start understanding how to frequently be talking about uh tools and things like that and

the biggest and documentation uh is really one of the biggest reasons uh for our failures of threat model because uh you've already made it this huge uh mountain if you will of that that needs to be caused or climbed uh before you can then start getting to the other side of realizing the benefits of checkpointing right and and and for others it's also a matter of self-doubt uh is it complex enough right i think uh the image that's been built around this modeling is that it needs to be complex right and i was like at least what is being said and said and done so so once you feel once you take you've done a test modeling you start

so is this good enough is this something that's complex enough uh from an expectation of what a tech model is right so one of the one of the things that i like to say is document what you do and not the other way around right so let's see what works from this morning perspective and then let's look at formalizing that so uh talking about schools of threat modeling uh this is purely from my perspective uh i see that there are really kind of two major schools of thought you have the story-driven trick modeling and then you have the competency module and let's look at what each of these things mean from a storyteller you're always asking the question of

what if and this is what is the attack student threat modeling the abuser case demonstrate modeling and so on so but you have multiple names for it but you're going to call it the storytelling for this presentation right so in a story-driven threat modeling scenario most of your threat models start off from a water scenario what if this were to happen to your application [Music] from a component of infect modeling it's more inside out you're essentially kind of really breaking down the architecture and you're kind of seeing in terms of what are all the various components in my application and what are the inherent threats and vulnerabilities that those components might have so it's more an inside out

perspective whereas the attack table is more and outside at that point the fundamental building block of the storage and threat model are abuse cases um suggest you have use cases for application uh have one or more abuse cases right so abuse cases are one of the more important uh almost like the keystones of uh of the threat modeling uh uh for storytelling threat model uh competent events modeling you're always kind of looking at known issues right it's always those known issues those publicly disclosed vulnerabilities uh uh uh which has been loaded up and you know for a fact that a particular component has these kind of issues like for example you're going to take an apache

server if you're going to take a uh you know a protect a particular library that's been used uh uh extensively you know what those known issues are so that's what a competitive technology is largely going to be used for a stoichiometric model is used to force design and giving development in most cases as opposed to the traditional component of threat modeling which is usually used pre-designed and that's the world view that you know often because like we said one of the motivations of threat modeling was first to kind of look at what the issues are from an architecture perspective so therefore from a content different set module perspective we are largely looking at threat models that are used as a

pre-design or a design perspective who uses storytelling technology security professionals and developers and automation engineers and we see why automation engineers connect and use uh storytelling but the competent technology is also used by architects because obviously uh you know you're kind of looking at a really kind of treadmill at the blueprint level so you have that additional persona of an architect uh coming again from the stronghold model the crux of the storytelling threat modeling is on depth and and and i want to draw a little bit of parallel in terms of pen testing here as well so look at an application especially in terms of applications that have complexities in terms of workflows they're trying to draw a balance in

terms of finding out deep-rooted security vulnerabilities that could actually be found by manual exploits and whatnot but you're also looking at an angle of scale which is in terms of how well is your coverage so that's the same school of thought when you get into threat modeling because our story is even threatening focuses on depth because remember it asks you the question what if what if this were to happen what if you know there was an attack a vector that did or weaponized a particular boundary would be displayed but in terms of the competent on scale because you're trying to ensure that you have as many components asserted for the potential security issues or known security issues

so uh there's a fundamental difference between soil even and complementary which is that of depth versus scale and we'll see in the next couple of slides in terms of how you could kind of bring both of these together uh from a sorry different smalling perspective to use there but then that's one of the reasons you want to talk about the open source trek playbook platform between them and a lot of them use a lot of manual uh kind of uh uh methodologies to do a story differentiate modeling uh but you have a lot of commercial variants from a conference inside modeling and because we don't want to be talking about any specific brands here we're just going to kind of leave you

with you know what those could be and uh happy to chat about it later uh but you do have a lot of commercial platforms in the components of the technology space um but not so much modern perspective right so that's really a compare and contrast if you will between the stoichiometrism and the competency smart so let's look at how what a complementary technology is usually kind of look like and and for people who use technology platforms especially in larger enterprises i think this is something that you would probably uh relate to easier because this is what most commercial trip market platforms do you usually start with a questionnaire that kind of talks to you about

what the technology stack is uh then that's where you kind of load up things like what programming language is your application developed on what are the various components that you have who's your cloud provider and so on and so forth and what domain does your application work is it in the financial sector is it in the healthcare is it retail and things like that so that the the the associated signatures are kind of loaded on from the background and you have uh you have like a correlation between potential threat potential impact of that application to your business and the vulnerability that it could be subjected to and then you have a lot of compliance and now you subjected to pci

are you in under hipaa are you under stock and so on and so forth so you you flush that question and then it kind of gives you like a map or a diagram where it tells you here's your process flow here's your data flow this is how your users kind of potentially interact with your application and things like that and this is where you'll probably be able to move around those bits and pieces uh to make it more customized and then once you've done that you have a potential list of threads and associated vulnerabilities and this is where we go back in terms of these platforms being able to work on known issues so based on the based on

uh the components that you've loaded on in the initial questionnaire you automatically have a list of threads and associated vulnerabilities and countermeasures for those known components and this is where you're also looking at scale because remember let's assume that your application uses you know for lack of a better number 250 per capita application you load up all your 250 components and then you already have a fundamental podium on which you're starting off your threat modeling exercise because you have those two group d components and if those are pretty known components you're going to have 250 uh competences uh threats and vulnerabilities so you're already starting off with a place and then once you've done that

you get to the countermeasure in terms of each of those threats and potential vulnerabilities then you have uh your remediation strategies and your validation strategies for each of those vulnerabilities right so this is really like a very bird's-eye view of what a genetic workflow from a component driven threshold kind of looks like so let's now look at what is this modeling which is something that we usually work on because uh uh you know we predominantly started off uh from from from a testing perspective from an applicative chariot perspective uh so therefore our technology that we do with d45 is largely story driven uh and one of one of the most easiest way for us to do throughout even

threat modeling is when we give an application to pentest for example we start off with something as simple as a scribe on a piece of paper that says okay this is the application this is the kind of workflow that the application has so let me just draw a quick attack trick right so so that's how we started off between check modeling but then over the last three or four years we've been able to kind of formalize that into something very interesting that kind of feeds into the security animation systems as well so we'll talk about that so from a storyline technology perspective you're not immediately this you have a use case every application has multiple it's just kind of breakdown a

use case which definitely talks about what the functionality of the application is into an abusive case or an abuse case which means what can all what could go wrong with that application so every use case would have multiple abuse cases and each of the use cases have something called an attack model which essentially says how can that abuse case come to life which in the security engineering world would potentially mean something like how can you weaponize that particular vulnerability so the the anatomy of of of the stoichiometric model is a use case drilling down into one or more abuse cases and then into more than one attack models let's look at an example here right uh

let's assume there's a there's an application where the user story says this as a user i want to be able to search for my nodes using the search functionality let's assume there's a search functionality in that application and this is just going ahead and searching for your notes just use case for the hdb as an abuser i would like to search for notes that do not belong to me which means you're kind of looking at uh elevation of privileges they're kind of looking at bridge of confidentiality and things like that so that could be one use abuse case the other abuse case could be as in a as an abuser i would like to share

notes that would steal the victims uh account details you're talking about more integrity based attacks there as well so just a just a very very uh novice kind of abuser case just for us to get an understanding of how this works so how do you escape those use cases in this example trickle down to two abuse cases now for the first abuse case you could potentially have three attack models so how would you potentially weaponize the first abuser case you could do that using manual middle attacks you could do that using injection attacks command os equalize if it's possible and then you probably do something like the ur redirection and you would kind of take that user

somewhere else and then you know be able to kind of steal those credentials and things like that right so let's assume you have three of those uh attack uh models so what you see here is that one user story now has potentially three potential attack vectors now this is really how a story differences model kind of drips down and this is a great way a segue for us to kind of really look at um a playbook now those who are interested that's the github link there for the third playbook platform this was something that we open source almost three or four years ago um and a lot of people have done different things with it uh what i'm going to show you

today is a very simple demo that my colleague and i put together i think in a very raw format because we just took a couple of hours and just put this together but there's really more fluid in terms of what the possibilities are of it so let's kind of look at i still hope you're able to see uh so paul and adam can you just give me a quick thumbs up in case you'll be able to see the browser here because i'm sharing two windows thank you okay so this is the uh let me just okay so this is the uh thread modeling uh checkplaybook interface and what you see here is that you essentially and like i said

you could download this from the git and you could kind of uh do what you want with it so what we've done here is that we've just loaded up something called an expenser project and if you look at the expensive project it would i just for the for sake of the demo here i have one user story that breaks my thread scenarios and vulnerabilities i'll take you through that for example if you look at the user story i've created one user story called create upload expense right so this is a this is an expensive project essentially means imagine this is a platform where employees would essentially upload their expenses uh and for them to kind of get

reimbursed uh from the accounting or the financial department right so imagine it's that kind of an application here so one of the user stories here is for you to be able to kind of create your experience user is as a user i'm able to create and upload expenses and project limits that have been incurred by me for processing and payment analytics right so any just any descriptions here not really the point um so if you look at that user story we've kind of created three abuser stories and the way we've been able to create this primarily they want to talk to you is by yaml files so thread playbook uh in the backend really is

uh really our facebook files which is really the uh fabric that drives them and for automation engineers if you're interested uh we use a lot of robot framework uh so what we've done is we've been able to kind of develop a lot of robot frameworks for popularly used open source tools like that we have it for wiper as well because that we've got npm on it we've got a lot of these things i can send you the link in terms of being able to download those robot scripts so what you have here is you have this yaml file in which you would be able to kind of create a user a use case here if you see the use cases

to create upload expense and then you give a description here and then you could have multiple use cases here for example one of these case could be manipulated expense information give a description here and then you could essentially say how you will recognize that so one you you could do that with equal injection so if you give something called the repo here so what you've done is that playbook also has a repository in the background in terms of our instance here and we've connected that to a database base which has all the cwe ids that are associated with a particular vulnerability for example if i just say a reference as sql injection and security three which means

it's a high serious vulnerability automatically the repo would pull in the cwe ids of sql injection and their associated vulnerabilities so similarly you can actually go ahead and create as many abuser cases as you would want so one of the questions that we get asked a lot is hey do i need to create these abuser stories every time i have a particular use case so the answer to that is yes and no you would have to create it once but one of the things they always counter that is you could do something very simple because you are already documenting your user stories today as part of agile apps like uh uh documenting user stories in jera

or a confidence is already a thing so all know all that you need to do is have your user cases kind of documented at the same time and once you have your user bases documented once the people who do been testing uh you know this is that a lot of these security cases a lot of these abuser cases are reusable so what you're doing is you're creating these smaller abusers cases uh uh components that you can essentially kind of mix and match to any application at any given point in time to create these abusive cases once you'll be then able to move them around into multiple applications as well so this is how you would actually go

ahead and create uh your yaml spec in terms of use cases to abuse your cases and the key here is really kind of being able to give that reference here in terms of how you would weaponize that vulnerability so let's go back into the into the ui here so we have this use case and we have these three aggregate cases now if you click on the abuser case here you'll be able to expand on what that particular user case is like we saw in the previous example but if you actually go drill down here here's where it tells you how you plan to weaponize this particular case you could do this using sql transaction you could using compromise manage your

password compromise manage your arts tokens and now you drill down one level below in terms of the various ways in which you could uh even various ways of weaponization right for example you could see if there's a sequel injection possibility using an automated vulnerability scan you could check this using a manual exploit uh you could run an exploit script which we'll talk about a little later you could run an sca scan or you could do a static another so these are the various ways in which you could potentially uh find that particular sequence section uh bypass limit so if you just click on this rms vulnerability scanning so here we've talked about what are the various tools

that you could potentially run that tool you'll actually see that the test case has been executed so i'm just going to go back here to the dashboard real quick and then i'm going to show you in terms of so if you look expensive project here you'll see the number of scans that you've done so for this particular project what i've done is i've run a zap scan i've run an npm audit scan and i've also done a manual assessment here so when you look at the scan results from the node.js scan for example you would see that the node.js found four vulnerabilities out of which one of them was sql injection right you found the cw 89 right so

similarly you would find that found a sql injection as well so you can essentially what you could do with thread playbook is you would uh so it's the thread model that comes from the left to right perspective just logically speaking and then you have the scanners that run on the application and they give you uh vulnerabilities uh that they find and now what you're able to essentially do is you're able to kind of map your threat models to your vulnerabilities so you can now say how many of your threat models have actually found a world kind of were realized by actually scanners finding them which means that if you found a threat model now you know for a fact that that

threat model was eventually uh it was kind of the same vulnerability was formed by scanner so there's that mapping between the thresh model to a scan and on the on the on on the other side of it is what are all the vulnerabilities and vulnerabilities that you never thought existed which means that now you found a vulnerability and there's no associated trick model to it it tells you that your threat modelling can be done better right so that's just to uh one of the byproducts if you will of using something like that playbook like i said uh go on to the git live there's a lot of videos there's a lot of materials that you put out there in terms of

various ways and you could use modeling and it's completely open source so you could kind of just use it the way you would want to use uh let me just quickly go back to the presentation um and it's largely used um using uh frameworks like uh the mongodb uh a graphql and python um and it is largely used from a story story-driven set modeling perspective and we said it's a great way for us to kind of map threats to vulnerabilities as well if you kind of look back to the original use case abuse case attack model perspective what we've been able to do now with red playbook is actually drill down into test cases so which now tells you how plausible are

they right so you start off with you this case the attack model and now you have the test case level as well so if you what i'm trying to get here is now stress modeling can be used as a way to effectively generate security test cases as well so if you look at it here you start to use the come back um to a security test case potentially means just look at the man in the middle attack for example you now have three security test cases for the middle attack you have three more for injection attacks so going back to our previous example one of the byproducts of stress modeling is for you to potentially be able to

generate effective security cases now let's talk about how automation comes in here so now that we have test cases there are various ways in which you can automate these databases right so if you look at a test case there are three things that are possible a test case is either completely experienced by a rule which means that that word nmap genetics whatever it is that particular test case can be completely executed by a dash faster than c2 that's a tool uh driven trip a test case on the other side you have completely manual vulnerabilities vulnerabilities that could never be found by a tool either because they have very deep subject capations or they could be hidden behind

authentication mechanisms that scanners may not be able to go in so you can potentially do a parameterized dash scan using proxy but let's assume that there are vulnerabilities that are completely manual so those you can actually use scripts um you can actually use the same automation fabrics robot etc for us to build security exploits tips so just like you have functional testers build security regression uh build functional regression scripts using selenium robot and things like that you could now use the same automation frameworks to build security exploit scripts so if you find a manual vulnerability all that you need to do is write an automation script that mimics the things it took uh to actually find that vulnerability

so that's a completely manual driven uh security test case and then you have the hybrid with the same name it's a combination of tool and script for example there are test cases where the tool takes you to a certain level and then you so you could you could mimic that using the platform uh using the tool as well uh the framework as well you could first run your tool results you can assert a particular value that comes out of the tool and then you could have your selenium script for example pick up from where the tool left off and then carry out that entire sequence of steps so that's the hybrid kind of a model so

once you have your test cases in place you can figure out which of those test cases is catered to by which of these three kinds of uh building blocks this is the tool related test case is it a script or a completely manual test case or is it something that's between the two which is more of a hybrid mod and this is really the whole nine yards if you will from a uh from an automation perspective this is where i'd like to go back into how threat modeling kind of fits in within the potential product development right so let's say there's a new feature development that's coming in you first ask yourself the question has

technology being done on that product yes or no if it said yes you're existing you go back to your existing thread libraries and then you pick up those threat libraries run those test status on it and say if all of this case is enough or have that has that component kind of grown beyond that earlier version if that's a component if those set of cases are enough you essentially kind of just map those strip models and then you drive down to your test cases because you already have those strict monitors now in case if those threat modeling in case it is a component for which strip mining has not been done earlier on this is where it gets

interesting because here going back to our original slide we want to be able to maintain a balance between depth and scale that we've done is in case if it's a fresh thread model especially in larger enterprises where you have the problem of achieving depth landscape we first run the threat model through the copper intervention so you use one of your commercial tools that gives you a fundamental analysis of what the various components are then you have your you have all of your security all of your thread cases coming from a component given perspective then you would run the abuser case stress model on that same component so the component driven technology now gives use k

and then the abuse is driven that model now gives you depth and now you take this combined thread model uh which is that of depth and scale and then you loop that back into your test cases so now what you're able to do is that every iteration you have the aspect of scale model combine that with efficiencies of depth and then you root that through the same automation pipeline which is that of either hybrid tool are completely manual right and in this way what you could do is that you could maintain that whole uh it's one way i'm not saying it's the only way but this is one way for us to potentially kind of

keep up with the speed uh of um of of product deployments because every time there's a new product department coming if you have so one of the things that we do is in some organizations they even have a small jita plugin or a confluence plugin that does not allow you to commit a user story until you write the association of uh user stories right so while while architects or business cases analysts are actually writing the user stories you have almost like a mandatory form field that makes you uh that prompts you to write so cases from that level and start tricking them downwards as well so that's one way to do it how does threat modeling fit in back to

the agile uh uh or the whole best cost model uh this is one view of the world that i love um what you see on the top are the traditional building blocks of product development plant code will test release deploy operate monitor and what you have at the bottom are the building blocks of security engineering which i can see stress modeling fast marking and electrical detection and what i love about this is that the color code here keeps changing as and when you keep moving forward a couple of years ago the color code was very different so now if you look at thread modeling that modeling is something that not just fits in within the plan

phase of the protein string lifecycle it's now moved into code as well fast for example which was now which was always largely in code has now moved from code to building and testing that's because of our animation problems have moved from test into release as well and so on and so forth so threat modeling uh so i i one of the things that i love is that threat modeling today has its place in multiple spaces as well for example just used to model stories at an initial as a plan and a court phase for example uh you could use threat modeling to write security test cases which means that you are kind of using thread

modeling or the output reflect modeling into the code and build space a little bit because the fact that threat modeling also helps you trickle down into security test case automation you're now seeing the threat modeling's benefits are now being trickled down into the test deploy as well and finally uh we if you're able to kind of map the potential the vulnerabilities the scanners find and then if you're able to kind of map that back to your thread models you effectively what you've done is that you've built that you know one of the benefits of threat modeling in the uh security monitoring uh space as well because now you're kind of using the threats that you

uh that you modeled way up in front and now you're looking at vulnerabilities that have come now and then you're kind of mapping both of them to say how many of my threads were actually validated by my scanners and how many new standard please that my scanner something that my thread model uh architects were able to uh kind of comprehend back then so you're constantly kind of improving your threat models based on what the scanners are finding and then you're validating your threat models based on the vulnerabilities that the scanners are fine so this is one way in which you could kind of ensure that model uh one benefit of threat model kind of trickling down into multiple personas of

product engineering uh i think i have five more minutes i'm almost at the end of my presentation here so in summary one of the things that i like to say is when you talk about threat modeling especially in agile applicant security know what works best for you because it's not just a one-size-fits-all figure out what are you trying to achieve from a technology perspective are you trying to achieve efficiencies of efficiencies of depth are you trying to ensure that there is some level of threat model that every persona and private engineers can achieve so really kind of figure out what is it that you would want to achieve using test modeling and always understand there is a

potential balance between death and skill then you have to do that because people have gone down the route of using just commercial platforms have figured out that there is no depth because commercial platforms or confidence modeling need will not always be best because they have no way to a certain uh threats that are more christmas largest driven such that are more exploratory test driven uh uh and things like that right and people have gone down that route of only doing threat models based on that have often come back and realized that especially in larger organizations especially in product teams where you have multiple iterations of the product going so there's always a balance between threat modelling for

depth and with molecular scale and it's very essential for us to really find that manual balance between the two the other thing is about making threat modeling more accessible uh we're talking about uh devsecops2. we're talking about breaking silos we're talking about breaking barriers for technical and cultural uh so therefore it's only essential that we see that threat modeling is made more accessible and and and we're big suckers for core here at v45 we love doing things in the as a code model think of getting more accessible especially if the developer community uh without any product engineering community is trying to expose threat modeling in a codified manner as possible right so developers love code so make set

modeling as a code something that they can kind of imbibe uh you probably have a lot of non-co professionals within product engineering and that's where you use if you look at robot chamber for example they're almost developed in natural language you can actually write abusive cases in simple uh almost conversational english and they can essentially be translated into uh you know what what you do with bdd for example right you can actually translate that into effective uh test cases as well so in one way or the other if you're gonna make this money more accessible across properties that would be great especially to do it because it already has the where we call to use

automation engines and automation fabrics for their gatekeeper functionalities to ensure that validations on an application are done so there's a very real possibility for us to equip qa for them to use security regressions as well and that's a great way for us to ensure that you have the same gatekeeper making you know checks and balances of non-functional and functional requirements and frequencies modeling is not always equal to sprint so it it if it's possible but don't make that mistake of saying that you want to be able to spread you would present it all right so we can please get started somewhere and finally uh the wings of effect modeling is has to be it needs to be

incremental it needs to be consistent and it has to be collaborative because that's really uh what will kind of give you that that that uh depth scale and value in terms of being is able to realize something with threat margin because we've seen enough offset money largely failing because you're kind of using one of the two other schools in fact uh so with that i will end my talk here uh thank you once again for giving me an opportunity and if are you happy hey sorry one question there quickly um i think we have time for have you seen models and their creation management integrated within existing tool sets today and any examples yeah i mean we've seen these models and

one of the examples here is writing this so we've seen thread playbook test cases using fabrics like that playbook integrate with a commercial tool um a commercial threat modeling platform and both of them have integrated very well into automation uh framework so uh maybe uh what i can do is i can point i can point you to the github link where we actually have one example uh where you just kind of have these modules linked directly into a tool chip so i can i can probably hunt that down into the key sorry with that on you shame thank you very much for that emma we're up on time unfortunately so and that was a great

talk and thanks for your time