BSidesSF 2026 - The Risky Business of Risk Illiteracy (Sean Juroviesky)

We're getting started with our next uh speaker. Please uh welcome to the stage Sean. Give him a round of applause. And he's going to teach you of how to handle the risky business of risk illiteracy. Sean, please go ahead. >> Thank you. All right. Sounds like the microphone's working. All right. So, let's get this started. Um, so yeah, my name is Sean and this talk is all about risky business. Um, it's great to be here in San Francisco. This is um, not just my first time presenting at Besides SF. This is the first time I've actually been back to San Francisco since I was 10 years old on vacation. Um, so it's really cool to just see all the sites

that I remember as like a really small kid. So this talk is all about what is wrong with how a lot of places are measuring their risk. How a lot of companies I've joined and seen what they're doing and how they're measuring it and where I think a lot of that tends to go wrong. So we have to start with what is the actual point of security, right? Why do we do what we do? Why are we okay with all these sleepless nights nights, all these nightmares, being paged at 4 in the morning and realizing someone vibe coded something and put their keys, you know, publicly on GitHub, all those fun things. Why do we tolerate that? Well,

the point of what we do basically is to reduce risk to an acceptable level. But what is an acceptable level? Unfortunately, it's not a level that we can define ourselves. The acceptable level of risk for business is defined by the business itself. It's defined by the executives who have an actual stake in the business. The people that you know would go to jail if they lie to the FBI. That those are the people that can define what is a risk to the business. And most often they see risk in terms of money, right? Risk is a cost to them. So what risks do people often prioritize to the top? Often they'll see headlines. They'll see new CVSs 10.0's. They'll see

brand names. Oh, Crowd Strike got crowd struck. That kind of thing. They'll see cool zero days. But at the end of the day, how exploitable are those things that you're actually seeing? And where do most incidents that we experience start? 68% of experiences of breaches are non-malicious human factors, right? That means there's lack of multiffactor authentication. That means someone's getting fished. These aren't zero days. These are just human factors that cause the vast majority of breaches that places experience. And overall of that 68% of incidents, 98% of them could have been stopped if the account that got exploited had multiffactor authentication enabled. And these are attacks that you've probably heard of. Um, Midnight Blizzard, striking Microsoft, uh, MGM

Gaming when they were ransomware. All these attacks are just multiffactor um authentication not being present, not being enforced and it causes so many issues. But this is not a talk about multiffactor authentication. I just think it's a great topic to kick it off with, kick off the um frame of mind for this talk because it's simple. It's easy to implement, but because it's constantly overlooked, because there's constant exceptions because of this executive saying this or this person doesn't want to have their phone on them all the time. For whatever reasons, it's constantly accepted that there's an exception to it. and it's also constantly exploited. So this talk is all about ensuring that you can see the actual forest through

the trees, ensuring that you can take a step back and review your entire risk picture instead of just focusing on the individual risks that you're experiencing. So let's rewind a little bit and get back to risk. So before we can talk about risk itself, we have to talk about what makes up risk. We have to talk about your threat models, your risk maps, how you're mitigating things, and then how those risks um look throughout your environment. So the ingredients for a threat model are fairly straightforward. There is a complete inventory, and you can laugh if you want because you're never actually going to get that. it's as complete as an inventory as you possibly can. Um, you need your data

flow diagrams and then you need to understand how your business operates. How does your business drive revenue? How does your business how do staff and the different departments of your business go about their day-to-day? Because in order to understand business impact, that's really key. So, you have to map up your tech stack. You have to map how data flows across your tech stack between different departments. What departments are sharing resources or have one-off exceptions to things and then what systems are interconnecting and why they're interconnecting. Often times there is, you know, more data flowing than is necessary. there is, you know, you're capturing a certain amount of data and you need all of it for that

reason. But then you also send all of that data to the secondary use case when it doesn't need that much data and it's really important to understand the whole of the business logic of why it is flowing across the business like that and where can you adjust it. Maybe that configuration was required at the time but it's been 5 years and now you have to review the amount of data that you're sending because you can now refine it a little bit. you better data controls on whatever platform is being interfaced with. Um, this I thought was a fairly decent data flow diagram. Um, it is fairly difficult to get a good quality data flow diagram offline. Often times

they're archaic or they're overflowing with way too much information. And if there is so much information on a page that your eyes start glazing over and your audience falls asleep, you really really need to peel back that data flow diagram and start having a much much simpler uh layout. And if you do need all that information, you can layer your data flow diagrams. You don't need one flow that has every single piece of information on it. you can have a high level overview and then have different data flow diagrams that can layer down into those other more complex services. That way you can have an understandable and digestible picture of what your what your tech stack looks like and

everything that's happening within it. And then really importantly again why it's happening within it. You're going to want to label your trust boundaries, do all those usual things, all those uh directional informations. Um and then throughout this throughout your building of a data flow diagram, inherently as security people, we tend to start saying, "Hey, that sounds a bit insecure or that seems a little bit vulnerable." Those are just natural questions that we are going to have with the teams that we're building these diagrams with. So as they're coming to you, as they're building these data flow diagrams, you're naturally already going to start threat modeling. It's kind of just inherent to the way security people

think. And throughout that process, as you're getting answers to those questions that just automatically pop to your mind, you need to ensure that you are documenting it. It is so so critical because you might learn it then. You might remember it for a couple weeks, but in six months when you go back to this, you're probably going to forget it. You're going to forget why you asked that question. You're going to forget the context around it. You're going to forget what prompted it. These are all items that you need to note. Otherwise, if you don't remember the context of why you asked that information and took that narrow note that you took, you probably won't realize why it's relevant until

maybe it's a little bit too late. So, what is a threat? Threats are the actual events themselves. They are the action, you know, the the verb of the risk. They are when the thing happens. So it's when a potential event exploits a vulnerability and then that can cause you know the damage to the business. And these events aren't just you know intentional events. Um these are often unintentional events. You publishing your um your keys onto a public GitHub repo is an unintentional event. There's all these actions that you can take that can cause risk to a business. You accidentally sending a bad push and deleting a database is an unintentional event, but it's also a risk and a threat

or I should say it's a threat. Uh not the risk unless you know there's a lack of controls which would create the vulnerability and then it's a risk. So throughout your threat modeling, it's fairly simple on surface level, right? It's what did you build? What can go wrong with what you built? um how will you prevent or respond to that? And then of course, did you do a good enough job? Um and you all might recognize these four questions from Adam Showstack. Um I've seen him around quite a few times today. Um which really cool uh to see someone like that just floating around a conference. Um yeah, us security people, we often trip up with that last question

because we tend to hyperfocus. We tend to focus a lot on did I do a good enough job and we catastrophize and it's really really important to ensure you aren't James Bonding the scenario. If you're in the NSA, okay, maybe then you need to go through all of that. Will someone halo dive from a helicopter with a laser and cut a hole into the roof of the data center? But if you're not in a national security role, you probably don't need to go that level of in-depth. You need to ensure that when you're asking, did I do a good enough job? You're thinking in the context of what is likely to happen to the business. How is the business

likely to be attacked? And then at the end of the day, you have all those threats. Where do you start to have risks? Right? Do you have a risk if you have a open exploit? If you have something else like that? Risks only exist when there is both a threat and a vulnerability. because without either of those it is not possible for that event to occur. You should still you know track the threats that are relevant to you but unless you also have an accompanying vulnerability it is not going to be exploitable. So when you're prioritizing how you're mitigating things you really really need to ensure that you're accounting for the likelihood and the exploitability of events happening to

your business. Because if something's not in use and you've disabled the feature and that feature is the only vulnerable thing, well then you know you mitigated it because you disabled the feature. So business impact is really really key especially when you're presenting risks to executives. Um so to understand how it impacts your business, you also really need to get a good understanding of how your business goes about its business. How does it generate revenue? How do staff operate? what is their daily work like if there is an outage in say Google Workspace what happens to this team if your CRM has an outage what happens to that team being you don't need you know the most in-depth

understanding but you need to understand enough so that you can figure out what is the impact to the business and how much money is your business going to lose if that thing actually occurs because being able to translate this into a monetary term can really really help with funding that you're requesting from executives or can really really help convince them to not accept the risk and to agree that yeah we do actually need to mitigate that we do need that many amount of engineering hours to fix this within a time frame. Using monetary terms are often some things that a lot of us technical folk are not all that comfortable with. But when you're speaking to executives they

can have a much much larger impact than just talking about ransomwares. Because at the end of the day, your average CEO doesn't care if you get ransomware. They care that you're losing a million dollars a day. So, calculating likelihood, I am not going to even attempt to speak to that. Um, there are multi-day courses on that. There are quite a few good books on it. Um, you can look up Monte Carlo simulations. You can read how to measure anything in cyber security. Um, but at the end of the day, this is a 30 minute block and I don't have enough time to cover that with more than one slide. Um, and then you also have to at the end of

the day mitigate what you find. Um, you have to add the multiffactor. You have to implement password wallets, update the vulnerabilities, ensure that you're actually rotating keys, and extremely importantly, you have to document. You need your who. You need you know your what, your why and your when. Who owns the vulnerability? What is the mitigation that you are implementing? Why is the risk being mitigated? And then when are we going to revisit this? Because if you do not fully fully close out a risk, you always need to ensure that you are revisiting it. Let's see how this looks. I've never seen this on uh such a large screen. It's actually readable. That's neat. Why are the slides moving?

Oh, I think I stepped on the cord. All right. Uh, so when you document everything, when you put it into your charts and you say, "Okay, executives, this is, you know, what we have. we have, you know, a description that is actually specific enough for you to understand what your risk was in the first place. Um, because these are things that you might not be looking at every day. And then you have to ensure that you are going all the way out to my left, your right, as far as you can so that you have one source of truth for all of your documentation, all of your relevant tickets, all of your relevant conversations, all of your risk

acceptances. Even if you make a folder for it and you're great about putting everything in the folder, you might lose the folder. So, if you have that document that is the source of truth for all your risks with all of the documentation in there, it is such a life hack. It saved my life so many times, right? Once you document everything, once you create a plan for how to mitigate it or why you really need to mitigate it and an executive tells you, you know, no, we're not going to mitigate it. When they tell you that no, you have to ensure that you get that on paper that you are presenting to them an exhaustive threat model of what events

can occur to the business when that goes wrong. And defining that not just in technical terms, but in the clear business impact from an executive standpoint. What would the executive see when this event happens? Right? Ransomware again they don't care about. They care about you know customers cannot purchase things. So all that revenue we get every day cannot happen. That is a lot more impactful to them. And then you also need to present alternative solutions. The thing you might want to do might you know resolve it the most but might also be costly. It might be take a lot of time to implement. So there's all sorts of other things that you can utilize that are

middle grounds and say okay we can temporarily do these solutions instead and then presenting all these options isn't just you know um for for our interest it's um well it is for our interest it's not just for fun it's in our own interest we need to cover our rears and ensure that we are doing enough due diligence to ensure that we are CIA and not going to be at risk of anything mitigation um mitigation is not just you know direct mitigations but there are secondary and tertiary effects to how you mitigate things and a mitigation doesn't necessarily mean you're completely resolving a risk right you are just reducing the likelihood that a risk can actually happen um and a lot of

the time people think oh we mitigated it and we applied this we patched this And okay, we reduce the likelihood of it, but if there is still a likelihood to it, then we really really need to ensure that it is still a risk that is present and that we are still revisiting every so often to ensure can we mitigate it better? Is it now more vulnerable because of changes to your infrastructure? These are all things that are really really important to note because if you mitigate something by putting it behind a W a couple years later your infrastructure might look a lot different and maybe it's no longer as protected as it was in that moment.

So mitigation is all about you know removing either the threat or uh the vulnerability and there's all sorts of different ways to do it. user training can reduce the likelihood of something happening um but you know it doesn't reduce it to zero so you're attempting to mitigate it um and it's not always possible to you know decrease it by likelihood. So there's also things that you can do to make it less impactful. Micro segmentation and different strategies like that that can have, you know, it's still exploitable. It's still possible that's going to happen, but then they can't pivot and do all these other really bad things. And then really at the end of the day,

there's always going to be so many more risks. We are experiencing more than one CVE a minute being released out into the open world. There are so so many CVEes. If you are just prioritizing things based on just raw CVSS without looking at the exploitability, the impact and the likelihood of that event actually occurring to your business, you are going to start drowning and just feel completely overwhelmed by the amount of vulnerabilities out there. Which is why it's really really important that you stay focused on what is relevant to you. What is relevant in your day-to-day, not what's relevant to the headlines, not what's relevant to your friend's business that's in a completely different market segment, has a

completely different tech stack. It's always really important to ensure you're viewing what you're doing because otherwise at the end of the day, you'll spend all of your time building better locks while your safe is left completely wide open. So, my name is again Sean. Some people call me Adwware because I often talk about um how marketing may just be quite malicious. Um especially with all of these different services Meta and others have. Um I am currently a senior security engineer at SoundCloud. Um I've worked in quite a few different market segments though. Um and I'm also one of the organizers of a city set called BBSE. We are actually one of the oldest city sects. Um we're in the Chicagoland

area. We have seven meetups a month in the greater Chicago area. Um, some of them having up to 150 people every single month. I really really recommend that you get invol involved in your local city, that you get involved in your local bides, that you volunteer with the community when you can because being a part of this community has really really changed my career and I just really really want to give a shout out to all of the bides in the world and just the cyber security community in general. Questions?

Thank you so much Sean for a great uh presentation. I think we have some already questions from uh from the audience but for those who have any please scan the QR code for Slido and also uh you can go if you don't want to scan QR codes besides uh sf.org/q&A. So, one of the questions uh that was asked for for us gigs without excessive business speak is our best bet to find an alive friendly middle manager to help with verbiage of our CEO's buyin. Yeah, that's probably going to be the most impact you can have is having an ally that gets that has a peer relationship with an executive who can act as that point to help translate your

risks into business impact. Um, so if you know you're the analyst that discovered a risk and you need to explain it and get it mitigated, finding that strategic ally in the business can make a huge impact. And then you can also offload things like finding the cost to the business onto that person which makes it a lot easier on you. >> And there is another question uh how do you convince executives to accept that bridges are inevitable or not possible >> that what is inevitable >> that I think it's maybe your question if you can rephrase that. >> How do you convince executives to accept that breaches are inevitable not impossible? There's a typo. >> There is no such thing as 100%.

>> That's a great question. I think I would have to say it's important to stick to um things that they're familiar with, right? They know that you're going to have better quarters and you're going to have worse quarters. And there is a likelihood to everything. there is a likelihood that um you know their business is banned in the country they're operating in or that uh the internet is banned in the country that they're operating in. They're aware of a lot of uh those business things. They're aware that you know there's a likelihood that taxes are increased by a certain amount. Um they're know that there's a likelihood that a key vendor of theirs will become too costly for business.

There's a likelihood that you're going to get breached too. And in all honesty, it's an it's an inevitability, which is why it's also so important to ensure you're, you know, reducing as much possible impact as possible through mitigation. >> Uh, another question, uh, for something like ransomware, if executives ignore classic fear, uncertainty, and doubt arguments, how do you cultivate buying successfully? I think explaining explaining it in likelihoods, finding um key players in your own industry that have experienced those types of events and those types of losses can really make it a lot more present to your executives. Um especially, you know, you can go look at your executives LinkedIn and see where they've worked. One of

those places probably experienced a breach and they may even have been there then. So being able to get them to flash back to those memories I found to be quite effective. >> Um let me check. Yeah, I have a question. Since you were talking about measuring exploitability uh associated to a specific business uh risks, did you see already maybe mathematical models that could work for companies at scale or adapted to their business? uh do you build it entirely from scratch uh on your own? >> I would love to work at a in a type of industry that was large enough to have um some modules like that, but I think at the end of the day, wherever you're at,

you're going to be building a little bit of it from scratch. Um there's a lot of open source work that you can take into account and um build on top of. Um, but at the end of the day, there's always going to be uh requirements that you do your own study, you do your own um uh research and figure out why it's directly impactful to your market segment. >> I think we're good with the question. So, thank you so much again, Sean, for your presentation and please give around the class. Thank you.