Scaling Threat Models by Playing Cards

let's start with a little game or maybe more like a thought exercise let's say that you've just been appointed as a head of security of some product uh maybe that's in the game for you maybe you have in the past or uh maybe you are uh one right now then i guess it will be easy for you uh but anyway uh you are responsible for security of the product so what would you do because i don't think i need to tell anyone here that securing things is not super easy so what would be your first steps what would be your first activities and i leave you uh with with this question for a little bit uh

because probably uh i need to introduce myself so i'll be talking about threat modeling and uh how we did it in uh my company and uh how we kind of scale it up uh with cards actually and i think you will understand uh what i mean later on uh my name is matteos i'm from poland and [Music] i've been working 19 for about 11 years uh started as software developer and around five years ago i started drifting into application security uh now i'm working as an application security engineer adocado technology you might have heard of ocado technology because we do have an office and engineering office here in barcelona um i mostly deal with uh java web

technologies because that's uh most of uh most of our products are uh written like that uh but sometimes a little bit of uh uh more unusual things i guess and so from my experience you don't really know what application security engineer does because it's it means something different in every company so my job in ocado is to help our developers to produce secure code and i'll come back to this uh later on and i actually i decided to create this talk uh with a motivation that can be summed up with uh a quote to somehow famous quote uh that in theory there's no difference between theory and the practice but in practice there is and so

the problem was that we started doing threat models in ocado and it turned out that there isn't a lot of like practical uh approaches me i mean uh there were there wasn't a lot of materials to go on uh to start and uh we've been doing quite a lot of trials and errors and uh i kind of felt that uh it would be nice to have more information on how to do this in real life if you are working in real company uh so yeah that's why i'm here uh and like a little uh thing i also wanted to mention uh uh so yeah embrace your newness i guess uh because i do not consider myself to

be some super expert on threat modeling this is not how you should do this this is how we did it and uh yeah i'm very open to discussions probably not right now because that would be hard but uh afterwards i'll be very happy to discuss uh if you think that my our ideas are good or not uh yeah just i'll be super happy to learn from your ex business experiences as well um right so short agenda is first of all i'll try to explain more or less why we think first modeling is important and why you should do this then uh there will be i'll describe our process and finally uh some lessons we have learned

so going back to the question from the beginning uh you are this head of security and the problem in my opinion that's obviously only one problem but the problem is that uh there is so many fun stuff you can do so maybe you are super fond about bug bounties uh and you want to start the program but uh like in the middle of it you think but kind of we kind of suck at devsecops and maybe we need some tools to be integrated into pipelines but you haven't even finished and you realize that actually we are not training developers uh so they don't actually know how to write secured code and so on and so on uh the

problem is uh if you are working like this then uh you are not very much different than kevin here running around trying to fix everything at once and i don't think that's super optimal way of introducing security so i'm not saying that any of those activities i mentioned before are bad they're great but i would suggest that you probably should start with doing a threat model and this is so you know so you have some kind of a methodical approach to uh introducing security uh and i kind of uh have this like in my head i'm trying to uh i have this visualization don't be a running headless chicken uh or kevin uh from the last gif because

uh and this is a uh like pretty important information do not google image search for headless chickens i wanted to have uh some kind of a nice cartoon uh picture in here uh but the results are very disturbing uh and they cannot be unseen so i used kevin uh back then and i recommend you to do not uh this is kind of still kind of a way i am thinking about this uh to apply some kind of you know order into your uh into your initiatives and so if you do that then you'll be able uh to answer three questions which in my opinion are very important first of them being why do you actually

want to be secure and if you think this is strange i'm an application security engineer and i'm asking this question uh i mean they are paying me to make everything secure so why would they ask this question well i think this is a very important question because i would say that you don't want to be a zealot security is a lot if you want to kind of have like a nice relationship with everyone around you in the company don't do this uh you shouldn't be like duh security is important because it's important because it's a security uh that's unfortunately arguments a lot of people are making uh in our community i am afraid uh and i'd

argue that that's not an ideal way and why is that that's because while security is important and i do know that i don't think it is the most important thing so if you have a product then the point of this product is to work to have functionalities so one of my uh like uh funny stories from the university time was when we had this java programming classes and uh a friend of mine started you know typing class blah blah and public static void main and then sat down um like thinking uh what to write down right next right and the teacher was uh coming uh behind his back he looked at his screen and he said well congratulations you

have zero bucks which is true but at the same time that wasn't really an interesting program it didn't do anything so it's kind of easy to have zero vulnerability vulnerabilities just don't write anything right but that's not the point uh you probably heard the joke about uh the only secure server is the one that is very deep uh on the seabed uh well this is generally funny but again this is not true even from the security point of view because uh if you go back to the basic what are the properties of secure systems there's confidentiality obviously there's integrity yes but there's also availability and uh guess which one of those uh server uh on the cbd is not

having what property is it not having and products are for users they need to function if you focus too much on the security and forget about users and by the way about developers who need to deliver this product then actually you might uh hurt security uh in the end because we all heard about like workarounds anything like the famous post-it notes with passwords on the on the screens just because uh you are requiring to change passwords every every 10 days or so um anyway let's say that uh you know why you want to be secure but the next question is what security actually means what is secure system uh which is kind of philosophical i know uh

but i'll show you to secure systems in next two slides these are real life systems uh they are secured obviously because they're locks and nobody says uh security more than logs right so this is the first one there's the door gate there's a lock and this is a secure system apparently because you can do this which is funny uh so i kind of googled another example of this so again you have log on the door and it works right [Music] so the point is there's another simple definition of security and if you forget about this you can do stupid stuff which will give you no security in the end but will make you uh spend a lot of time working on this

um i guess uh uh i mean uh you need to think about your context about data you're storing about your business model uh for example a lot of uh security people uh in my opinion focus too much on confidentiality of stuff and again uh i'd argue that for a lot of companies available availability as uh even more important i know that for my company this is the most important thing that we need to be available this is e-commerce if you are not available if people are not able to purchase thing on your website then you are losing a lot of money um all right uh and by the way yeah so uh the examples with the logs were kind of

obvious right very funny and and so on but it's much easier to miss similar things with software because with logs everyone kind of gets it even if you are not a trained security expert with software is it's much harder to spot some problems well finally you do know uh why you want to be secure you do know uh what things will make you secure uh or your product secure uh well that's easy note right just do the thing but have you talked to your product owners recently uh because their backlogs are pretty full uh i i think uh can you have you talk to your developers uh from your company because i'm yet to find a team

in ocado that will say that yeah actually we have nothing to do for next six months let's work on this security thing and the point is that there is a lot of uh work on development teams and you can do everything at once uh and you can spend like six years or even months working just on security because again security is not the most important thing you need to be delivering a business value at the same time and uh because uh because of uh of that you need to prioritize your work you need to work on issue on problems on uh or actually solutions that will give you the most bang for your bucks right uh with

low effort a lot of security added and yeah this all sounds pretty reasonable i guess but [Music] unfortunately again even though we knew that threat modeling is important we had some problems with running these initiatives uh initiative but and i think the uh important context for this is that in the caddo apsec engineers and any other security engineers are not responsible for security over product in ocado the whole responsibility of everything product related is on teams so it's going to be teams that will be working on threat modeling in the end so yeah that's that was kind of a point we were starting with and because of that our approach uh had to be at least somehow fun and engaging

i mean if people are bored then they will try to find every excuse they can to not do this uh again right so yeah um also simple because they can't like their development teams can spend next month or just like researching threat model options and learning maybe some tools used for threat modeling uh and so on we kind of wanted to have as simple as rules as possible uh use whiteboards and google sheets not anything more uh complicated uh for this and yeah that's it and finally uh at least our developers want to have some sense of accomplishment so uh if i make them sit for a prolonged amount of time uh and in the end they feel that they wasted

this time uh again they won't they won't don't want they will not want to repeat the process again and that's why we've chosen to go with so-called uh by us cornucopia approach actually there are two card games out there one is elevation of privilege by microsoft the other one is corncopia by owasp uh i'm using corncopia in this presentation but we actually in ocado used both of them they are very similar and it doesn't really matter which one uh which one you choose they are both very good uh so probably you can try uh both of them and these are like cards you can play a game with those cards and uh actually we are starting with even more

fun which is drawing uh this is our step zero it's not like the most important part but we do want to draw a system diagram uh it's again not required but it helps you to reason about the security of the system in the future so then you get this card guards you kind of play them and in effect you are collecting threats you are obtaining a list of threads which are applicable to the system but that's only half of the job uh because then you need to assess those threats and that means first of all quantify the risk associated to the threats so what's the impact what's the likelihood uh how serious is this problem this is very

important from the prioritization point of view because you need to have this in order to prioritize also assess if you are vulnerable because threats can be also material already materialized as vulnerabilities in your system but at the same time maybe uh it didn't happened yet the so the threat have haven't yet materialized uh but you want to be prepared in case it does in the first case uh you you want to probably fix the vulnerability uh in the latter case uh you will want to introduce some defense in depth controls uh to make sure that even if some vulnerability vulnerability will occur in later on or maybe even if you are attacked then you will be able to defend yourself

and then and this is pretty important as well you need to agree on actions so first of all uh can we accept the risk associated with this threat because not everything needs to be fixed and definitely not everything needs to be fixed right now so maybe we can accept the risk like for a year or something and companies do this all the time this is kind of underlying foundation of businesses to take some risks and it depends how much risk are you willing to take but yeah sometimes it's a it's it's a good thing to do but if a threat is pretty serious then how much work are you willing to do in order to

fix this uh because maybe there's some quick fix uh maybe uh you will need to spend a lot of mandates preparing a fix uh and maybe you don't have time for for for this right now well uh it depends on the project but uh you need to actually commit to do something uh and finally this is not a part of threat modeling but i thought it's pretty important to include this here as well so first modeling will be pointless unless you act in the end so if you've committed to some actions then do this and introduce those fixes put put some mitigations uh and things like this right and uh i'll try to show you how fret modeling more or less

could look like um so uh we'll be picking a card i mean cards are already picked uh i was cheating i know uh then i'll try to come up with some uh threats applicable to uh to the application we'll be reasoning about uh we are not going to do a risk calculation because it's kind of out of scope and possibly will propose some mitigations and and repeat uh we have like four cards i i think but first as i told you uh you need to draw so i drew a little diagram this is some system uh let's say some e-commerce system because you have customer and he wants to put down some orders in your e-commerce website there's a

retailer who wants to uh fulfill some orders and there's also an admin of of d-cloud because everything is in the cloud because it's 2019 i guess uh so yeah nothing really too complicated um and see ya let's uh let's say you were doing threat modeling and playing the first card so this is authentication four 4 is the rank of the card authentication is the suit and sebastian can easily identify user names or can enumerate them so obviously i will be simplifying things a lot uh i i won't be going very much in depth but uh you are talking with your development team so is this possible uh and you are kind of presenting them the idea of user

enumeration vulnerability when you know there's a different response when you use wrong username or password during login and they are saying they actually know about this and no the error response is the same so we are all right uh how about the password reset uh these are actually actual conversation i had um and they are saying that yeah we thought about this too uh so there's the same message if you do a password we said no matter if the account is present or not but i am digging deeper all right so what about registration it's like oh and yeah it turns out that you can do a user enumeration during registration as well so we would put down a thread

thread is account can be enumerated using registration functionality and then we need to come up with solutions with mitigations so one possible mitigation would be obviously to return the same same message no matter if the user exists or not um so yeah that could work but at the same time we're talking to business and because of reasons business doesn't like it so we need to accept this risk in the end uh so all right this is not bad i mean user enumeration is not a huge issue so i think it's worth accepting this isn't an ideal solution for me as a security guy but i can live with this so let's play another card and it's

session management jack and jeff can resend an identical repeat interaction for example http request and it's accepted not rejected so let's focus on those http requests so we are talking about reply attacks right and i inform developers that when we are talking about http then as long as you're using https reply attacks are not possible but if you are using a plain http then there is a possibility of reply attacks and guess what the green lines on the diagram are actually https and the red ones are http so obviously we already see that there are some places in our system that could be vulnerable to this and well the solution is simple let's just introduce https but and this is pretty

important what are the dotted lines on the diagram these are so called trust boundaries so the trans when you are inside transboundary you are trusting everything that's also within the same trust boundary right so for example we have http connection uh between our fronts and microservices and our backend microservice well this isn't ideal but since we are inside our trust boundary we decide that we don't want to introduce extra overhead of tls and we decide to uh accept this risk in this case on the other hand there is the http connection between admin and database and that's actually not ideal because admin is connecting from outside the cloud so probably from from some place like on the internet

so in this case the threat is much bigger and probably will want to introduce https in this place so let's say the dev team development team commits to fix this uh in a week because it's pretty serious at the same time we have back-end microservices uh talking uh via http and crossing trust boundaries with database so again this is not ideal this these are these components are not within the same trust boundaries but because it's in the cloud then the agreement is that we will fix that but not right now we'll introduce the fix uh in like two months or so so next one cryptography eight in can access stored business data for example passwords because it is not securely

encrypted or securely hashed and yeah we read out loud this card and developers are happy to inform me that they are using state-of-the-art sha-3 function which is obviously better than chatu so yeah i now need to explain to them that unfortunately even though shot 3 is like one version has this version number uh bigger uh this is not how you should store passwords and um i explained the concept of slow hashing why this is important i explained the concept of offline cracking um and we agree that this needs to be changed uh we don't want to accept this risk uh but the problem is um this is a lot of work and we know because with that we didn't use sha-3 we

used uh background background which is uh like a nice function but we kind of felt that we want to bump up the hardness factor and we wanted to migrate all the data uh into the like uh i knew like the same algorithm but new hardness factor and so on so we know this is a lot of work uh and uh because of that we can do this like overnight and we need to be very careful because it's password if we if we screw something up in the process then uh we'll block everyone from accessing our web page which is far worse than having those chat three in the database so we decide we'll fix this within the

year during a slow process with multiple checks iterations and so on and the last one i actually love this card because it's almost always a sure thing to have someone some threats to be listed so xavier can still circumvent the applications controls because code frameworks libraries and components contain malicious code or vulnerabilities so yeah if you ask your developers what version of of of strats are you using or was spring they usually don't really know i mean they might know the major version but not the minor in most cases so usually this is a problem but what are the solutions so they could like daily check for new versions of everything uh in their dependency three

three which is obviously kind of stupid because it's a very very tedious work or they could um [Music] like add like some kind of automated tool to the to their pipeline which stands for vulnerable vulnerable components and there are such tools and yeah we are using some in ocado because uh they're very interesting but not yet in all projects so the idea is that uh after threat modeling uh there is a single task created that one of the developers will check like the most important components but within a month or so we want to introduce this automated tool as well but again this is the last card i know not going very much in depth in most

cases there is more than one thread applicable to a card so for example in this case you could also talk about third party javascript uh used in your web page right because it's a malicious code in third party component and obviously the fix will be very much different because you probably want to use some something like sub resource integrity or perhaps content security policy both of this can help you with this the point is the this is another threat even though applicable to the same card and you also need to take care of this so the games goes on and on uh and this is kind of how we do this and what did we learn

in the process of doing this uh this is probably a kind of interesting so the first thing is that we really do like threat models and i'm not gonna say they're perfect and definitely the execution is not perfect but it gives you a lot of a lot of benefits and like the most obvious benefits benefit is the reason why you are doing threat models but we have found out that there uh there are another like bonus wins uh made possible by threat models so first of all documentation and system diagram if you have no documentation is already a good start and conversely i would argue that every good documentation should have fret model uh included uh

i mean we as a like the word are not yet for this to have this required yet but i think that eventually that should be a case and uh education so you might uh you might be running some programs on how to train people uh so they know what the vulnerabilities look like uh how to write secure code and so on uh but you know the training is like one two three days then they forget everything or not everything but at least some parts and this gives you an opportunity to kind of reiterate on on some problems so i regularly i'm forced to explain uh some vulnerabilities some problems uh on those cards and after this

obviously after threat modeling the side effect is that the dev teams is also a little bit smarter because they kind of learn a new vulnerability or a new kind of attack things like this and it really helps if you are using example from old threat models in your new threat models because you can say that yeah you actually do want to fix that because uh like team a and b also had this problem and it was nasty so you probably uh should fix that or if this is a planned feature you probably should not do this this way and so on and so on uh it's much better to give examples from inside your company

if the guys know that their friends made this mistake it's much easier for them to kind of accept that this is this is really a problem and visibility so i as an abstech struggle all the time to get the visibility in the company uh my role uh i wouldn't be possible if i uh if people wouldn't know that i exist so i kind of need to go all the time and remind people that i exist i am abstech engineer here hi uh and i'm here to help uh if they don't know that i am there they will not come to me with the problems they may have so fret models are a nice moment when

you kind of present yourself yeah also present yourself as a specialist so during the process they kind of see that i know what i'm doing and possibly they will trust me a little bit more but also uh because of the way how we do threat models because of the approach with which is not like you need to fix everything now but because of like more realistic approach uh they also are uh kind of inclined to um share their dirty secrets for example uh and to work with me not against me right and by the way i said about sharing dirty secret uh the visible visibility works also in another direction so uh if it wasn't for threat models i

wouldn't know about half the problems we had in company uh because you know there's this service everyone except two guys forgot about it it's been running forever uh it's not listed anywhere if it wasn't from threat model uh and like the quick oh actually i remembered that we have this service nobody really cares about anymore but it's still running like these are very these are how conversations sometimes look like and because of that i can do like oh wow so that could be a problem can i can you tell me more and gathering like knowing all the assets in the company is obviously very important uh it's not a way for modeling is not the way to gather all the assets

but it will help you to get some visibility of over what you have in a company back hunting it's not the problem like the common misconception is that during threat model you are kind of trying to identify vulnerabilities uh you don't uh you are looking for a threat for threats but in the process um you might i mean regularly i get these red lights in my head turning on because yeah that doesn't really look great what you are describing to me and then after in fret modeling i'll ask for an access to the application i'll do a little bit of ad hoc pen testing i guess or vulnerability hunting and usually i'm able to find

something interesting uh which i can uh show show to the team that yeah i was right the this isn't the best way to approach this um again not the point but also happened more than once and uh cornucopia and elevation of privilege give give you also uh a little bit of agility which is pretty important uh which will be pretty important in a minute uh so you have those cards but we actually stopped playing cards like we are not playing uh like having a game we are just using cards because they are very good uh um like the the threads described there are very interesting and are a great starting point but at the same time it

turns out that like teaching people how this game works what are the rules and so on was they were just wasting time so the feedback i continuously got was that it's not worth the effort and you are still using the cards but not playing a game also because these are cards then cards are very agile right there's a lot of cards in agile and you can for example choose to play a card every week or every sprint or every stand up maybe and over time you will play through the whole deck right so this is nice because that will be when you will finish red model yeah but as i said no everything is perfect so

there are three biggest problem i see with spread modeling in general and especially i mean not especially but in particular with chromecopia and elevation of privilege so first of them is time threat modeling takes a lot of time and actually uh that's kind of the outcome of very cool thing so every time i start threat modeling there is a lot of discussions being started uh so there's this card and there is this thread described so are we vulnerable no i don't think we are but you forgot about this service yeah but we have some mitigations in place so maybe this one and it goes on and on and on and that's kind of the point so you can't really uh like cut it

because you would be missing all the uh important bits but at the same time playing even one card takes a significant amount of time um so um yeah i still think this time is valuable so you kind of need to live with this uh as i said this agile approach uh could be something that will help so we are uh never playing like all the cards on the one sitting because it would take hours and i'm talking like uh not two hours but more like 20 hours probably and obviously you can't host sessions which are that long because and this is another problem decisions are pretty tiring uh like you wouldn't believe that i i think but uh

trying to come up with new threats all uh all like constantly uh is uh is tiring like really you are feeling tired uh exhausted actually after an hour or two so first of all uh again don't overdo this we usually host uh sessions which are uh like maximum two hours long uh and we are trying to cut them even shorter uh we prefer to have uh more shorter questions than one long one for example to have one day dedicated to fret modeling uh i i'm not saying this wouldn't work at all but uh but yeah it's probably better than uh to like kind of split this also like you know uh if you are kind of a company that can

get cookies into the room or pizza or house remodeling in the evening and even maybe some beer uh then that also helps to kind of refresh the group uh but don't overdo this actually we overdid it a little bit and uh like not with the beer fortunately but the point is you need to be focused and like pizza can distract people a lot for example and this is this is stupid this is really simple but uh i had this problem so many times that i need to kind of shred this out make sure there is a fresh air in the room because if there's not then after uh 30 minutes people will get sleepy they uh won't uh

what won't be engaging in the conversation as much and yeah that's not great and finally uh as i started this presentation i told you that the kind of a problem was that even for me and i was supposed to be an uh like specialist security specialist even for me uh getting all the information on how to do fret modeling how this could work in a company and so on uh was pretty it was pretty complicated i'm not gonna lie and if we are talking about developers who are not skilled security experts uh then it's even worse for them um and i unfortunately don't consider uh those projects uh to be so simple that you can just tell your

developers uh well do a threat modeling link use corncopia it will be good unfortunately that's not how it works uh we are hosting a lot of demo sessions uh and during this demo sessions we are going through the whole process but i am present uh in the group and i'm helping them i'm explaining how how this works and so on and so on uh and we are doing a lot of those like eventually the there there needs to be some point where i'm almost nonexistent uh on during those sessions i only get results or something but right now uh we are not there yet and yeah as a summary i guess do i recommend doing threat modeling

uh yes definitely uh i still think this is the one of the most important things you can do to make sure your product is secure it doesn't give you like immediate security but it can help you to plan everything further on and the processes we have are not perfect yet even corn copia even have elevation of privilege aren't perfect but it's still better to do something than do nothing right so don't try to be perfect and uh just start doing threat models and you will see uh if it works for you or not and i guess that's it uh i'm happy to answer simple questions uh if there are uh hard ones i like that we don't have time for this

uh so don't worry uh yeah but i i think like the point of this talk was to kind of make you think about this and i really don't expect that many questions but maybe more conversations later on and i'm very open to this uh i i don't have time for conversations right now so yeah questions are welcome anyway [Music] [Applause] [Music] no [Music] um i imagine before you started this as you said the team's agendas were already full uh how did you persuade people to take part in these sessions

i i don't think there's a simple answer uh for that uh i think it needs to be clear in an organization that you care about security so there needs to be like something like do you remember like bill gates trustworthy computing memo uh that went around microsoft uh so that was a good example of management very much supporting the idea that we want to produce secure software and i think that needs to be clear and then i i actually think that i was pretty helpful uh like i was pretty um effective with this because i had good relationship with uh with uh with my friends my colleagues and uh i i didn't talk about this but

we strongly believe in security engineers being enablers not blockers uh in our company so everyone knew that i'm not trying to kind of this w this won't be like another time there is this security guy who is saying no no no no no but it will be a conversation and we will uh and we'll have outcomes that will be interesting for everyone uh this is probably uh the second thing you can do uh to make sure that uh it works uh and finally i was from the beginning very open about the process about the reasoning so like the whole process starts with like simple 15-20 minutes presentation i'm giving to the team explaining why we

consider phase modeling to be very important and describing how we will do this later on and again i don't think there's a simple uh answer to this question but i think those three things are helping a lot hello just one question for curiosity so applications and systems continuously evolve right so how do you iterate on what currents uh the threat modeling exercises on your applications and systems when they change like on a monthly quarterly annual basis yeah that that's actually uh the bigger struggle we have and to be honest i don't really have answers yet i mean uh we do recognize this as being an issue uh i don't think i mean fresno link takes a lot of time

so you can't especially if you are doing like continuous delivery or something like this uh the you can't really threat model each iteration but you need to repeat the process every now and then i don't think it needs to be repeated very often but uh it needs to be repeated uh like every half a year or a year um and this is this is how we are trying to uh solve this but well till now to be honest it doesn't work that well um [Music] we are uh playing with the idea which i kind of uh hinted during the presentation to uh do this in a continuous way meaning uh instead of doing thread modeling now and then next

one in in a year uh let's like play one card uh every week or so and uh you are doing this uh like constantly uh they're like oh i i don't remember it's like six times uh 13 i think cards uh in current copia so it will take probably an a half or so uh to go through all of them but then you start from the beginning and you are constantly evaluating uh this isn't this isn't perfect i know but again uh this is a huge effort and we can justify uh taking a week work uh like like taking a whole week of work for a dev team uh every month or so so yeah

[Music]

and first of all thank you for making it understandable also for people who don't belong to the security indus industry like me for example i come from software testing which means i'm concerned also about security of course but i'm not an expert and i like the approach because as far as i understand if even though you can end up accepting a specific risk you perform risk analysis and risk management before in any case and and i like it because i've been noticing a warring trend recently um some project management managers uh tend to uh not to do risk analysis at all risk management they just assume risk i don't know if it's because they are not skilled at

these things or just because they know it takes some effort as you said so my question is have you been noticing this issue as well and if so how did you deal with it well to be honest uh like the risk analysis uh from the business point of view is a much wider topic than that just i.t security and i obviously focus only on it security and even not not uh like whole i.t security because i mostly uh take care of application security so uh i haven't noticed this trend in our company at least but i'm not sure if i would because i i kind of see uh as a small picture uh i think threat

models are great to deliver to your management later on so they can uh use this in the risk analysis uh but our uh like my point of focus is kind of now narrow you know uh like it doesn't uh so we are not considering things like you know like robberies or uh or fires or floats or some things like this uh which actually should be taken into account in uh in a company probably i mean like at least a company uh uh like ocado so yeah thanks and by the way uh i i hope i mean i'm trying to fix this but i tend to say developers uh and this is actually pretty bad because i always mean

development teams which at least in ocado consist of many people so for example we are engaging pos infrared models we are definitely engaging uh software engineering tests uh and actually we had even user experience guys is joining us and everyone uh who uh feels that his time won't be wasted during this is welcome to come and i'm usually trying to make this as open as possible this is this shouldn't be focused on developers only so i probably said developers along along my talk more than once and what i meant was like development team like actually just the team responsible for a product [Music]

um so one of the things that you mentioned was the um threat modeling gives you visibility of the issues yep which kind of make me uh think like you do on for example services that are already running in there i mean my question would be have you also done threat modeling on services that are just on inception like on the mindset of someone before doing so and if you see in kind of measurements instead of instead of if i've done thread modelling when i was designing my service i also reduce potential risk instead of just you know doing when something is already there i'm kind of having like the visibility of the festa already there

yeah that's a very good point uh and actually during my presentation to the teams uh i'm explaining that threat modeling is actually even better if you are doing this from the beginning because it's possible that you will avoid a lot of design flaws because you know vulnerabilities uh you fix them you forget about them that's cool but design flows oh that's that that's nasty and uh the problem is uh that unfortunately in ocado most of the stuff we already have there is not that much i mean there is a lot of new projects but unfortunately uh threat models we were running were mostly about projects which are already created but if you have a chance to do a threat

model before development starts uh in the like every early design phase uh that's even better because uh you can from the beginning indeed uh mitigate a lot of risks and just make sure this won't happen so yeah um i guess the simple answer is this is a great idea uh we would like to have this this way but unfortunately in real life we didn't had a lot of chances to to threat modern new systems

okay thank you