BSidesROC 2025 - Risky Business - Sean Juroviesky

all right cool all right everyone we are going to get started that seems like it's kind of picking up my voice sort of cool well I'm also naturally loud and obnoxious so you're gonna hear me regardless well we're gonna get started with the first talk of track two given by Sha joveski and I'm gonna read his bi over btim here because I don't have this memorized Sean is a dedicated security and risk management expert with extensive experience navigating complex environments he Sean excels at developing a comprehensive understanding of intricate systems and crafting strategic strategic road maps to revitalize Security Programs by identifying high-risk areas and optimizing the use of existing resources Shawn removes barriers between teams to

enhance communication and coordination driving effective security outcomes beyond their professional Pursuits sha finds joy in backpacking through the mountains with their adventurous Australian shepherd and twins embracing the serenity of Nature and the thrill of exploration and i' pass it over to

Sean man that sounds like it was written by AI my name is Sean and this talk is the risky business of risk illiteracy some people call me adwar because I'll be speaking about the evils of marketing and adwar in general over at Cipher con IM walkie so if you'll come out there please come see my talk about all that is evil with marketing I'm currently a senior security engineer with SoundCloud and I've past experience in healthcare marketing nonprofit and the entertainment sectors um I'm also one of the organizers of a community called BBC we are one of the largest um cyber security networking communities probably in the US but absolutely within Chicago we're a little over a thousand

people and we meet every single Thursday of the month in one of the Chicago suburbs we also have chapters now in Las Vegas and gallway Ireland and um as I was introduced I also do love to go camping I've done lots of camping over in the Appalachians here the cat skills when I was growing up and in the Green Mountains as well so this talk is all about what I think is wrong with risk measurement now to get to what I think is wrong with it we have to first figure out what is the point of security why do we do what we do well at the end of the day because it's pretty hard to completely eliminate

risk we focus on reducing it to what we consider an acceptable level but what is an acceptable level it's a little bit hard to judge but from a business perspective from the people that are paying us money to do our jobs typically they think of it as as risk they don't like losing money because of ransomware attacks and other things like that so when I talk about risks what tends to jump to mind usually it's things like headlines it's memes you're seeing on social media or a really super cool zero day that was just dropped things like deep seek things like Sim swapping there were some headlines about signal that were very overblown and then phy2 defeats but that

phy2 defeat is exceptionally hard to reproduce you need several hundred, in laboratory equipment and you need to steal someone's PH2 key and spend eight hours tinkering with it and you have to have the knowledge to do all that and not mess it up you also have to irreparably destroy their phy2 key so you can't give it back to them so they're eventually going to figure out hey something's wrong so unless you're a state actor or something like that that's probably not going to happen so a few years ago grammarly was in the news maybe like a year after it came out and Executives were like huh this sounds like it might steal my IP this sounds pretty bad so an executive

of mine comes up to me and says hey you need to take care of this right now you need to drop everything and you need to get rid of grammarly throughout organization because I'm sure someone's probably using it well we were in the middle of an incident we were actively losing money we had an active outage we were mitigating but he said no you need to drop that and you need to fix this and I said well I guess I'd like to keep my job so I did that but I don't think that was appropriate risk prioritization so it's really important to think about where most incidents actually begin 68% of incidents involve a non malicious human factor and you

might ask yourself what is that for the most part it's things like social engineering it could be things like storing passwords in Google Drive and then saving that Google Drive document as public on the web as you know one does um it can be all sorts of things like that but studies show that of those 68% of instance 98% could have been stopped just by enforcing multiactor from the application that was compromised and multiactor is very often a factor of things you've probably heard of like the midnight blizzard compromise of Microsoft that was incredible how in-depth they were able to compromise Microsoft and how long they went without Microsoft realizing it all of that was there were a number of really

horrible things Microsoft did that enabled them to do that but at the end of the day MFA would have stopped that it would have stopped that chain of events from occurring there was also the MGM gaming hack a few years ago where all their casinos all their hotels were basically offline taking reservations with pen and paper that was because someone called up their help desk and social engineered the MFA reset for a systems administrator Ticket Master I'm sure everyone in this room's prob probably received an email saying yeah your everything was compromised you might want to look into that from Ticket Master all of that was because their parent account in Snowflake that they used extremely heavily for their

databasing had no multiactor so why do I keep talking about MFA is it because this talk is about it no it's because it is really simple to implement but time and time again it is a really massive factor in instance so I have a few ideas about why I think that is one it's boring it doesn't grab headlines it's not attention getting in order to figure out that MFA was the cause of many of those incidents you would have had to go search all the way to the bottom of the news articles where there was maybe a blurb about it and then the other factor is it's inconvenient it's something that I'm sure all of us get frustrated with

occasionally and we're Advocates of it it it's annoying to go find which of your 30 top apps that you have to put in it's inconvenient and I'm sure all of us have experience with it our banks mandate we do it our schools mandate we do it our workplaces mandate we do it Microsoft is maybe mandating that you do it according to them so what is this talk actually about this talk isn't about risk modeling per se though there is a little blurb about that but that would be really really hard to teach you in an hour this talk is focusing on ensuring you're viewing the forest through the trees ensuring you're not getting lost in the

weeds and ensuring you're tackling your risks appropriately so to get back to risk it's really important to figure out what risks you're facing and in order to figure that out you need a few things you need threat models you need risk Maps you need a list of how you are mitigating all of your risks and you also need to understand what the potential impact is of those risks if this event occurs what will happen to the organization there are a few ingredients that you can use to build your threat models so first you need a complete inventory of what you have because you can't secure it if you don't know what you have it's fairly

simple or at least you'd think it would be fairly simple then you need some data flow diagrams because you need to understand how information is being passed from one level to the next to the next throughout the whole topology and then it's really important to understand what risks your business specifically is facing every industry every company has unique threats and unique opportunities that might occur and before you can actually build your threat model you need to know and have a really firm understanding of what it is that you're securing because there is probably a lot more of it than you actually realize PE people went out they used a company card they bought a SAS app and

never told you they connected that SAS app to CRM for marketing purposes and they never told you they went out and signed up for this free service and that free service and they Google oo to it and share data with that service and now you don't even know that they have access to view everyone at your company's calendar so you have to build that understanding of what it is you have you have to lay all of that out on onto a topology how does it connect where can data flow across it and why can it connect it's really important to understand the why because if it can connect but there's no reason for it to

it really shouldn't be able to so this is a chart that I absolutely stole but I really liked it because whoever Drew this is a lot more talented in draw.io than myself I love how it talks about all the different entry points and exit points because Google ads over there in the top left is one entry and exit point then at the other end there's Shopify there's external apis you're connected to it goes in depth about all the different entry points which there tend to be a lot more than you actually realize so you need to build a lot of data flow diagrams because topologies are really complex and your eyes are just going to

glaze over if you actually put everything onto one topology so you need to build out an understanding of at the highest level this is what's occurring for the most part and then you need to build little samples of if we dive into this this service is actually 30 different microservices they connect to these 12 apis they share these datas and this across all these different ways and they do them with this and then these you have to also label all of your different trust boundaries what can access where what can access both what can where does data flow stop where does it continue and as you go throughout this you're going to be thinking to

yourself hm is this a threat I feel like this is a little bit risky and you're probably building this with people from different teams so you're going to say hey can they actually exploit this in this way and they're going to say no the permissions for that account are limited to just read or whatever that's threat modeling you just thought of a threat you just found out you mitigated it and there's no vulnerability you should write that down probably because in 6 months you're probably going to have that same question again in a year you're going to forget it or you might just be praised as an absolute Hero by whoever replaces you because you

actually documented it so this is a really basic data flow diagram which includes trust boundaries it's really important to label all of these to take notes on each trust boundary and what does this trust boundary mean which accounts can pass through it which accounts can pass through multiple trust boundaries all of that good things but it's also important to understand that trust boundaries aren't firm it is really fairly easy to defeat an llm and typically it goes right through that trust boundary where that prompt and response is then fooled into being interpreted by a series of commands by that llm that happens all the time it is fairly easy to replicate and there does not honestly seem to be a

decent solution in eliminating it at this moment so like I was saying before you're probably working with other teams as you build this topology and it's really important to involve them because they understand their own Tech Stacks a lot better than you probably actually want to understand them because if you know all of this then maybe you should be getting their salary as well so they're going to help you build it they're going to help you diagram it and as you make assumptions that are incorrect cor they're going to help you correct it and they're going to help strengthen what it is that you're actually writing and throughout your threat modeling process you're going to

continuously involve them because they know how they've mitigated these things or they realize that oh that's a good point we didn't mitigate that so it's really important to just continuously involve them and continuously build relationships with them because if you build stronger relationships with them maybe before they build something they'll ask you to threat model it first because it's much easier to mitigate threats before you build it and maybe you might even have some fun along the way and we'll talk about it later in this presentation so as I said before as I'm going to say time and time again you really want to document everything that you're figuring out everything that you're finding and you want to be able

to understand it that's not documentation that's just acee I just like the picture but you also need to understand what it is that you're documenting because if it is source code and you're not having a firm understanding of what's in the source code what is the source code doing when you leave and come back to this project in 6 months next quarter whatever you're probably going to forget some minute details so you need to understand everything that you're writing and you will thank yourself so many times later on so in order a threat model you need to know what a threat is threats are events they are occurrences a lot of times people mix them up with

vulnerabilities but the threat is the actual what can happen what can an attacker do what can happen here or what can a staff member do unintentionally because unintentional events are threats they are things we need to mitigate backing up your database in order to ensure that some Dev can't just delete your production database that you've never backed up that is a threat so that's something that you have to threat model it's something you have to mitigate and you don't just want to scrape the surface because if you've acquired a company and they've offboard most of the services that they're doing but they still have this one thing that one thing they'll offboard in three weeks three weeks can take

years it can take a really really long time and they'll keep telling you no no no you don't have to work through this you don't have to mitigate those vulnerabilities we're going to be off that lightning quick but how often does that actually happen or you've come into a new company or you've been at a company for years and you figure out we acquired this company 15 years ago and they're actually doing this one service still on their old infrastructure that they forgot about that's automatically paid for out of a different account it's an FTP yes there's no s it's an FTP and it's also hosting some people share wear for some reason and you find this and you say what in the

[Music] world so throughout this process we've been threat modeling as you build a topology you naturally tend to start threat modeling we as Security Professionals tend to start saying hm this looks like a bad idea should we be doing this and so at the end of the day threat modeling is what did you build or what will you build what can go wrong with it and then how have you prevented it from going wrong or how will you prevent it from going wrong once it does go wrong and then at the end of the day you have to ask yourself did I do a good job of that I feel like a lot of us in security

never feel like we can actually say yes to that question so while it's important to go through it a few times well it's important to reconsider it to ask others to bounce their opinions off of it to say hey do you feel like I'm missing anything in this threat model it's always great to get outside feedback to get another set of eyes on it but also it's really important to understand sometimes you just need to step away for a week for a day and come at it with fresh eyes and maybe you'll find something new so if you end up building this topology if you end up doing all this then you end up with a threat

model so what do you do with that threat model when you have it and is that threat model a list of risks so if I ask you what do you think a risk is what tends to jump to mind do you think about zero days you've yet to mitigate do you think of operating systems which are still out of date which you really really should update but are those actually risks sometimes you might have a CVSs 9.9 but it's not actually a risk to your organization because a risk only exists if there's both both a threat and vulnerability so if SSH has some kind of vulnerability on the system you're using but you've disabled it across your

organization you've disabled it and turned it off and all those good things then there's no risk you've mitigated that by disabling it in order for that risk to be exploited that system would already have to be compromised so you mitigated it and congratulations you've just closed out a risk as you find your risks as you uncover them it's really important to consider the actual impact of the risks and how risky the risks are it's fairly difficult to gauge how risky risks are that's sort of the point of this talk so I'd like to break it down into three factors what is the impact to the business if this risk is exploited How likely is it how feasible is it that

this risk will actually come into play and how well can we mitigate this risk understanding impact is really difficult and it actually really requires that you understand how your business generates Revenue it requires that you understand how staff go about their day because if these systems go down what happens how many services go down are you still able to sell things to people are you still able to fulfill orders but you can't upgrade your subscription to a higher level what sort of impact does this have on the actual Revenue generation for your business and when an attacker does this when an attacker compromises these systems takes them down whatever it is they do what can they do with the access that they

achieve are they able to spend client money because they stole credit cards or because you spend um you purchase ads for your clients and have access to their money are they able to take down client content can they take down content that they don't like can they upload content that you don't like can they download protected data that you are legally obligated to protect and then can access to that one system that's been compromised break access somewhere else if they get someone's credentials for terraform are they able to remove and alter the permissions that databases have and then suddenly they just lock you out of all of your databases and then you also have to understand how

much money will your business lose if this happens if you say that oh all the all the music streaming for instance still works but people aren't able to purchase an upgrade to their current plan well how long will that take to mitigate and then what is the likelihood of not the likelihood what uh how long will it take for you to actually resolve this issue so you do some math on that saying you know we lost 10 customers during this one minute period that we had this outage okay so that's 10 customers times $10 a month that's $100 and then that's $100 times 12 months because on average most people are fairly unlikely to make a purchase

again within the next 12 months if they weren't able to make the purchase right then and then I'm talking a lot about money especially in this section it may not be our biggest interest in protecting companies it may not be what motivates us the most we want to find the cool vulnerabilities we want to be those hacker catchers we want to do whatever it is that we want to do but it's why companies pay us money it's why they hire us even if you're working for a nonprofit if that nonprofit loses too much money then that nonprofit probably won't survive so unfortunately it's really impactful across Ross all of what we do and at the end of the day if

you're able to talk in these terms to Executives who don't care about security but they do care about money it's a lot easier to justify headcount it's a lot easier to justify purchasing additional tools if you can talk about the potential losses that they will face if they don't do this next up there's calculating likelihood calculating likelihood is exceedingly difficult it is something that you learn in statistics courses it is not something that I can teach you in the 3 minutes I've allocated to this section um what I can tell you is that there are things like Monte Carlo simulations you can use to get rough estimates there are statistics courses probably at this University that you can

take you can read a book called how to measure anything in cyber security it's a very good book it gives you probably like a 101 understanding of it some rough math some formulations you can do to actually say to your Executives these are the likelihoods these events will occur so if you end up have but it's also something that you can just gauge from data that you already have if your logs show attackers exploit a zero day an average of 14 days after that zero day is released then you know you really really should mitigate that vulnerability within 14 days though that is absolutely exceedingly unlikely 90% of the time zero days don't get exploited for years most organizations

don't see them actually being tried against their org for years unless it's something like all those foret vulnerabilities that were released time and time and time and time again for the past like is it 3 years now come on guys hope no one works for foret here um yeah unless it's something like that and you might ask yourself what's the difference between there well it's really exceedingly easy to utilize those Ford net um those foret exploits and because it's so easy to use it's low hanging fruit it's something that attackers are going to try first so it's really important to understand when you're calculating likelihood probably the largest factor at play is how achievable is it for the

attackers how exploitable is it for the attackers how will they be able to do this how easy will it be for them and at the end of the day after you figured all this out you have to actually mitigate what you found and as you add MFA as you do all these mitigations as you run all these updates it's really also important again to document it you need to remember why you mitigated it the way you did how you mitigated it and all these important things that you are likely to forget once the next thing catches fire and you might ask yourself well did I mitigate it well enough I decided that because Executives said we couldn't turn

off this one feature because it's critical and because the vendor is yet to release a patch we have put it behind a WAFF and that mitigates most of the risk for us and so as you document it it's really important to understand who what why and when who owns the vulnerability who will actually be the person that mitigates it once you can mitigate it or who you have to talk to time and time again to get them to mitigate it um what is the mitigation how are you mitigating it you have to understand why are you mitigating it the way you are are you eliminating it if you're not then you need to understand what are the

potential impacts that remain and what uh and why you're doing it the way you are did an executive tell you no we can't do anything to this because we're turning that off in 2 weeks so we just have to accept it and then you also have to ask yourself when are we going to talk about this mitigation and this vulnerability and this risk again it is exceedingly important that you don't just say okay we'll close that out we'll talk about that next year or if it has another vulnerability you need to plan to actually have a firm date a meeting on the calendar with all the stakeholders and say okay we are going to talk about this again in 2 months you

said you're going to turn off this feature in 2 weeks okay I'm going to talk to you in 15 days about why that feature is still on and about how we're going to actually mitigate it then there's risk acceptance if someone tells you that you cannot fully mitigate something because they don't feel like it you have to understand that only the actual risk owners can accept risk we as security individuals cannot accept risk directors cannot accept risk most VPS cannot accept risk typically it's going to be someone like a ciso a CTO a CEO someone who actually has a stake in the business someone that the owner or board or whatever of the business can actually

put blame on they're the only people that can accept risk because they're the ones that actually have a stake in this business and if you're see CTO says I don't know about this I think we should do it the way uh we should do it this way but we shouldn't do it that way but he refuses to sign a document saying I as the CTO accept this risk then you have to go to his boss and you have to say you have to accept it because I'm not going to sign this piece of paper someone with a stake in the business needs to sign when you present these risks for them to accept you have to create an

exhaustive you have to ensure that you're covering your rear you've to present an exhaustive threat model of what is the potential impact of this risk what can actually go wrong with it and you have to list out all of the alternative solutions that you think is better and why you think they are better and again this is to cover your rear and ensure that they are saying okay maybe at the end of the day we can compromise and go to this slightly better mitigation or they'll just fly out tell you no and you've covered your rear and they can still fire you if they feel like it and they can still blame you but at least they'll feel a

little bit embarrassed about that because you got them on paper to say I told you so so what is mitigation mitigation is reducing the likelihood um or the impact of a potential risk because often times it is really hard to eliminate the absolute possibility that something will happen right we can James Bond it as much as we want we can have Insider threats who've been at the the business for 10 years and oh they can still exploit this because they can revert it they can exploit it some other way okay yeah that's still a likelihood I guess but we can reduce [Music] that so risks are eliminated by removing either a vulnerability or a threat if

neither of those are possible then it's not risk and that's often times not possible so what we can do is we can add some protections we can make it less likely or less impactful less likely we can send fishing videos catchy fun Clips to staff and maybe they'll remember this and hm this looks like that video I just watched should I still click this link should I put my credentials into this text box that has no CSS that just looks horrible I think I will at least they considered it right you can send oasp training games to make mandatory training for your developers slightly less miserable um there's all sorts of things that you can do that might

actually have an impact on likelihood or you can do technical things to reduce likelihood like put it behind a WAFF do some other configuration and then that might require it be a multi-step process so this can't be exploited unless this gets exploited okay that's adding a barrier that's making it both less likely and possibly less uh less of an impact but if you're just putting a barrier in front of it it's probably not reducing the impact unless you're also putting walls around it so you can do things like micro segmentation so if one service gets compromised then it can't pivot it can't move it can't impact your business further and as you go through this as

you add all these different mitigations reducing impact and likelihood you then want to recalculate hm how much much of a how much did we reduce the impact did this go from a $10 million compromise to a $500,000 compromise cool that is great to put on my CV that is great to put when I request a promotion and also at the end of the day unfortunately it's likely to have a lot larger of an impact than some super cool Tech thing that you put on your request to be promoted right so I apologize for the horrible tiny text but this is how I like to lay out my risk tracking risk what do I title it description what

is the actual risk that we found was the potential impact of the risk we found who is the team that is going to be repairing it who is the actual owner of the risk the the stakeholder who has the ability to sign off on this risk if we mitigate it the way we did and then how are we planning to mitigate it or how have we mitigated it next up there is the date that you are next going to review this risk probably the most important section of your risk tracker when will we talk about this again when can I harass you to ensure that hey no you accepted it for 3 weeks those three weeks are up we

need to talk about this again and then has it been accepted and what is the vague risk level then extremely importantly did they sign and accept that risk you want to link a PDF or docy sign link or whatever right into there to demonstrate okay this is my cya right there so it's really important to get people to accept that they are responsible for risks it is really hard to get people to accept that sometimes because one team that built this feature was split into two teams most of those people aren't there anymore how do you decide which of those two teams will actually take ownership of this and actually be the team that mitigates

it and it's really often difficult sometimes you even have to go to the CEO and say pick one of these two people it is now theirs because I'm not going to spend all of my time and all my Engineers time engineering our product to fix vulnerabilities that's not our job our job is to find them and help you do that but I don't have 30 developers I can't fix this feature I can't do this that's just not practical and then always always always Excel sheets keep going to the right like forever so link all of your documents link all of your threat models for each of your risks link all the relevant tickets that you've received news articles if you

want links to CVSs databases all that good stuff just ensure you have one central place that you can find your documentation it's really hard to find a j ticket sometimes so you want a central place where you can go and say okay cool that is where that link is Jirus search is

broken so as you continue to track your risks as I've as I've said tons of times throughout this talk open risks should always always have a follow-up date um and before you actually close out and say that a risk has been mitigated it's been eliminated you should ensure that it actually has because sometimes vendors will release a patch for something and it won't work or it'll be really easy to fuzz and then still exploit it so it's really important to ensure that you actually have mitigated this risk you haven't just done what the vendor says is appropriate then as I said before there I put a risk level on there risk levels are really really hard to judge

especially I don't like to have all of the different levels on my risk tracker because that just makes your eyes scroll past it and it removes more important information that you could be looking at so I like to kind of just vaguely combine likelihood and impact that I've represented um more conclusively elsewhere as just like a vague how important this how important is this to me and then there's even more about tracking please don't ever ever ever delete anything you put on your risk tracker there's a ton of reasons why this is both to cover your rear because if you said you eliminated it then in your risk tracker you've documented how you've done that so you

can say okay no we did put an effort it's just that the vendor lied to us or no it's a new vulnerability that was released I know it's similar but no we did actually complete this plus it helps set precedence if some executive wants to accept a risk and just ignore a problem you can say but like 6 months ago we had a really similar vulnerability and you refused to do it and we got that fixed in 3 weeks they might feel a little bit embarrassed about that and might say you know what you're right we were planning on dumping that feature in 6 months but it's fairly likely that project will run long so I

guess we can prioritize this right now plus it might be potentially mandated because of GRC because of different requirements if something's been eliminated it still should be tracked and then it's really good um for your annual review for your resume you should probably put these somewhere else that you can access if not confidential information of course but somewhere that if you get fired you want to put on your resume and say these are the impacts I had there you should probably track that somewhere personally but if you forget to do so or if you forgot that document exists for 6 months and you've added a couple things here it is a great place to go back and refresh yourself on maybe

I can make my resum a little bit better with these points so earlier in the talk I said you might have some fun with these different teams that you're working across because service owners know their Stacks way better than you yourself know it is really important to build relationships with them and maybe you can sit down with them and do a little bit of Dungeons and Dragons or hacking and Dragons or whatever you want to call it so it it's important to encourage them to get hackery they can sit down they can risk model your own topology and you can just roll dice to make it random your medication didn't work okay how are you responding to this now and

this helps you threat model and build real threats for your business but it could also just teach them really important skills so they don't have to constantly ask you all these different question questions or before they even come to you if someone comes to them with an idea or they come up with a brilliant solution they might say no wait actually uh that didn't work in Dungeons and Dragons you can make up completely fake scenarios with random topology just to teach them good skills just to get them better into the practice of it and you can even have some fun they can pone different teams if you've got a positive vibe maybe you can even put

people against each other but always keep things really positive you don't want to start a fight because some guy found some really bad mitigate vulnerability that another team didn't mitigate it's important to do these semi-regularly because it both helps you find mitigations and vulnerabilities that you have but it also helps strengthen the skills and you can even mix things up you can make frontend Dev sock analysts you can make backend devs friend and devs you can take a lawyer and throw them in somewhere you can make someone be a lawyer and see how they can craft a really good PR release but at the end of the day there's going to be more risks there's

going to be more vulnerabilities our job keeps going and going and going so it is extremely important probably the most important point in here is to stay focused on what you have if a new zero day comes out fine figure out relevancy impact likelihood those good things but don't just fix it right then prioritize it properly because if you don't actually close out the risks that you have if you just keep focusing on the newest latest greatest vulnerability you're going to spend all of your time building the best safe without actually closing the door here are some really great resources from oasp um they have tons and tons of information there's fantastic information all over about

actually threat modeling um in more specific detail than I was able to get into here um but I would like to thank you all for your time thank you all for coming to my talk and ask if you have any

questions yep um you talked about reducing potential cost of a risk 20 million to obviously is an example but most of the time don't we end up evaluating this more qualitatively than quantitatively so how do you make that from qualitative that is extremely difficult that is making that leap is the topic of not a talk but like a 3-day course um I can say for the most part you can figure out what the impact is to your business if a risk happens how much money will your business lose during an outage that's now quantitative that lost money is the potential impact and if you can reduce it from all of our music going down so

pissed customers will just start unsubscribing the second we're up again two people can't upgrade their subscription that is a massive reduction instead of losing tons and tons of customers you're just not gaining new customers two-part question um so on the spreadsheet that you were showing that for the really small tax that attra for the person who owns it if that risk is going to be accept by do you put that person like the CEO's name whever there do you like replace the technical person who would understand the mitigation with the person who's actually just saying yeah we're not going to do this is that what you would do and part two is why um why do you

feel that a VP or a senior VP would have enough stake in the game to be able to accept that risk yeah so it definitely um so that's why I had both a team section and an owner section because the owner is going to be the executive um because that might be a chief marketing officer maybe they can accept the risk um often times Executive Vice Presidents can accept risk but it really depends on the company it depends on the size of it and it depends on a what a VP can do um if if a VP doesn't have like an actual Financial stake in the business are they able to say we should ignore this how

comfortable do they feel with with that and how comfortable do you feel with that because if this VP answers to an EVP who answers to a some other VP that doesn't seem like someone that's going to actually be able to accept the risk you probably have to go to a higher tier to have them accept that yeah and just to follow up so I think like some of the difficulties that I've seen is you've got BPS who are they've been tasked with growing the business and making more money and so they're just saying you know to H everything just we have to take these risks we can't afford to not do it right MH okay thanks yeah that's

why I mean it depends how comfortable you feel in the company you can you can tell someone's boss hey you have 5 minutes I feel like he's accepting this but he's not fully considering something you know do it in a polite manner to try to not get fired but it depends how comfortable you feel with doing that it depends on your Dynamics it depends how often do you socialize with the people that that person answers

to to add on to what you were saying I think it really varies when it comes to the ownership so risks can have very farreach consequences so oh this is an end of life L that end of life OS is going to lock you certain forest level which over time is going to lock into certain types of encrytion that you can use going to to the whole organization not just that specific area that that risk is in so now that's risk for the entire organization and that's when you need to go up to that high level because only they can accept that because I'm only responsible for this small little slice but this impacts the entire company

that's really bad yep you on the my right uh Curious uh what you would think uh the appropriate like obviously the Excel sheet is endless in either direction um at what point do you think that a company needs to consider investing in like TRC software rather than using just an Excel spreadsheet for tracking everything at the point that you can get the money to purchase it um when you're evaluating risk and sort of prioritizing different uh different threats and vulnerabilities do you ever incorporate like uncertainty into your estimations like there's a certain threat but it's uncert like there's certain aspects of it that are uncertain what the impact might be or How likely it is to actually become a threat that

you need to worry about that's something incorporate into your estim it is it's not really possible to calculate uncertainty or at least maybe it is and I don't have enough of a background in statistics but um what I can say is I tend to if I can't calculate it for my own company I tend to look at the industry as a whole what are people in the healthcare industry doing about this risk how often are those companies being exploited if there's a 100 companies in the healthcare industry every five years one of them gets popped maybe I can use uh from a similar risk maybe I can use that to kind of guesstimate our own

uncertainties I've understood the emphasis you put on documentation but by any this is just me being buy do you have any templates or any reference documents apart from the that we can use as um I do not I think all of mine are proprietary company-owned ones but um I do think there are some really really fantastic ones available online for that um there is um a book that I think is called threat modeling designing for security um that book is fantastic and it also includes a bunch of online resources that you could

reference no problem thank you all for your time