Risk it for the Biscuit: Crunching the Numbers on Cyber Threats

Good afternoon and welcome to Bides Las Vegas's Common Ground Track. This talk is risk it for a biscuit. Crunching the numbers on cyber threats given by Sha. A few announcements before we begin. We'd like to thank our sponsors, especially our diamond sponsors Adobe and Ikeo and our gold sponsors Profit and Run Zero. It's their support along with our other sponsors, donors, and volunteers that make this event possible. These talks are being streamed live. And as a courtesy to our speakers and audience, we ask that you check to make sure your cell phones are set to silence. If you have a question, uh, use that microphone over there. It's ready to go so YouTube can hear you. As a

reminder, the Bides LV photo policy prohibits taking pictures without the explicit permission of everyone in frame. These talks are all being recorded and will be available on YouTube in the future. With that, let's get started. Please welcome Sean.

All right. Thank you everyone for coming out. How's it sound? Can everyone hear me? >> Nah. All right. Is that better? Can everyone hear me? All right. Maybe I will just do the microphone instead then. Um, >> my beard would mute it. >> It's all right. We can do just the microphone. All right. So, not clipping it to my beard is not the worst idea I've ever heard. Um, but thank you all for coming. I know this is not what you probably imagined the talk would be if you looked at the schedule yesterday. Um, but I am happy to be here, happy to pres presenting here in Las Vegas for Besides Las Vegas. So, this talk is all about risking it

for the biscuit. Um, I go by Sean. I also go by AdWare. That is my hacker handle. It's another story. Ask me after the talk if you want to hear more about it. Um I am currently a senior security engineer with SoundCloud and I am also one of the organizers of a little meetup called BBSE. We are a thousand uh plus organization based in Chicago. We have six meetups in Chicago. There is a BBSE every Thursday of the month. is an incredible community and I'm mentioning this because I want to advocate to all of you that you should find your local community that you should build your local community and that you should be a

part of your local community because it is an incredible incredible opportunity that we have to be and to be build friendships and to just build cyber security as a whole. So this talk is really just basically what I think is wrong with how a lot of people tend to measure risk. So to start off with how do we measure cyber security or not how do we measure it what is the point of cyber security? What is the point of what we do? It's to reduce risk. It's not to completely eliminate it because that's probably never going to happen, right? We continually review, we reduce, and we tackle it. Um but when we reduce it, what is an acceptable level of risk?

It's not for us to define as much as we would love to. It's for the business to define. Only business owners can accept risk. So they can say how much they can tolerate and you can recommend against it. But at the end of the day, it is their risk that they are accepting. And so it is important that we keep that in mind so that we can further advocate to frame it in a way that they realize how risky it is to them and to continue to help us improve it. So when I talk about risks, when you think of risks, what's the first thing that tends to come to mind, right? Are you thinking about social media? Are you

thinking about memes you've seen? Are you thinking about headlines in zero days? But how often are those actually the causes of your problems? Right? Where do most incidents start? So statistically 68% of breaches are non-malicious human factors, right? They are people writing their passwords on sticky notes. There are people going along with fishing PS and different things like that. people that don't have any ille towards your company just not doing the proper thing. And then if we look at that 68% of breaches, how many of them could have been stopped with multiffactor authentication? 98% of those. But we we talk about multiffactor all the time. And a lot of these attacks that could have been stopped with it

that you've probably heard of are some of the biggest that have happened in the past few years. Midnight Blizzard completely owned Microsoft. And while there is a lot to go into with that story with how indepth Microsoft was breached with that incident, all of it could have been stopped if that one account had multiffactor. Obviously, there was a ton of issues they were doing improperly, but it probably wouldn't have actually become an instant if it had multiffactor. MGM Gaming, that massive hack that happened not far down the street. I'm staying at one of their properties. That attack happened because someone social engineered a multiffactor reset by calling up the help desk. Sure, they had multiffactor enabled, but they

didn't have secure policy around how to handle the resetting of it. And if you let anyone reset your multiffactor, do you have multiffactor? Um, ticket master. Ticket master was breached because they had a snowflake account with all their data and the parent account for that snowflake had no multiffactor enforced. It was a service account that they used to sign up for that was the chief account of it. It had no multiffactor. And so you might be thinking, is this a talk about MFA? No. I just think it's really really simple. It's something we've been talking about for years, but it's it's the year of our lord, our our zorg, uh 2025, and we're still talking

about it, right? So, why? I think it's just constantly overlooked despite it being really simple. And a lot of it tends to be from user pressure, from users saying, "Oh, I don't want to. It's inconvenient." But you have to explain the risk. You have to build relationships and help them understand why it is so important. All right. So let's reverse a bit away from the MFA and talk about what we're actually going to talk about. So to understand what kind of risks are present at your organization, you need a couple key ingredients. You need your threat models. You need risk maps for those threat models. You need a list of risk mitigations. And then you also need

to understand how those risks can impact your business in actual terms of your business. Not just, oh, it'll take down that server. Okay. What does that mean for the business you work at just because it takes down a server that could be basicallyformational, it could be inconvenient, or it could grind your business to a halt. So, first off, if you want to build a threat model, you need some more ingredients, right? You need a complete inventory, all the SAS that people aren't telling you about because you can't secure it if you don't know about it. You need all of your data flow diagrams, and you need to understand how your business operates and generates revenue.

So build a map of your tech stack. Understand what you have. All of your SAS, all of your pass, all of that new data center that they decided to build in this other country because it was really cheap, but they didn't tell you about it because they know you wouldn't be unhappy. Not a real world example. Just thought it'd be funny. Um, probably happened, right? We all know it's probably happened. Um, as you build that, you also need to understand a map of how data flows across all of your infrastructure, what it interconnects with, and why does it interconnect, right? If you build out your topology and you have this beautiful map, but you don't understand

why it connects here, what it's doing, why it connects there, what it's doing, then if you look at it and say, "Oh, this is kind of insecure. Why would they do that?" Well, if you go through and you answer those questions, you might figure out, oh, they did that because they did that 20 years ago and yeah, that's actually something we should tackle because that's 20 years old and we've just been ignoring it because it's part of our infrastructure. This is um not mine. I stole off the internet, but I think it is a really golden example of the maximum amount of information that should be on your topology. Yes, you will eventually need more

information, but you shouldn't put it on the same topology map. You should build another topology map that's more specific because if it gets any more information on it than this, people's eyes are going to start to glaze over and they're going to ignore what you have or just be unable to read it, right? Just information overload really. So if you need to get more specific, if you need build more, remember to notate it, build that additional diagram, but don't put too much of it in one place. So multiple diagrams for multiple levels and also for multiple audiences because you don't want the same diagram for your data team that you're going to use for your executives, right? Because your

executives are going to just see this jargon. You want something really high level for them that they're going to be able to absorb and take information away from. Ensure that you're labeling your trust boundaries as well as the data flow directions because data sometimes it flows both ways, sometimes it flows one way, sometimes it flows 99% just outwards, but there's that one instant, that one thing you connect to that it then flows into your organization with. Right? And then as you're going through that, you're going to naturally start to ask questions because you can't build these topologies alone. You can't build these without the help of your other teams. So you're going to ask these

questions of them to help build these topologies. And every question you ask is also probably going to end up kind of being about vulnerabilities, how they're mitigating it. You're just kind of naturally going to start to threat model and figure out what kind of threats you're facing because that's just kind of how humans operate. As we build these things, we naturally tend to be curious and ask questions. Remember to document all the questions that you ask. That is this slide is the most important slide. If you ask it, if you think it, write it down and document it so that you know about it later. Um, so let's talk about threats. What is a threat? Threats aren't

are often misunderstood. I think the threat is the actual event. It is when the thing occurs. It isn't the vulnerability that you have. That's not a threat. It is someone utilizing the vulnerability. That is the threat you are facing. So in order to build out your threat models, you have basically just four questions you need to ask time and time again. What are you building? What did you build? What will you build? What can go wrong with it? and how will you prevent or respond to it if it goes wrong? And then the final question, did you do a good job? And then you ask that again. And then you ask that again. And then you ask that again. And then you

get to be a little bit paranoid and you start thinking in James Bond terms, okay, maybe then you should go get a cup of coffee, go for a walk. Um because once you think the paranoia is setting in, it probably is. Um, I think especially for us in this industry, we t we start to we go through the basics and then we start to get a little bit advanced back down. After you get there, walk away, come back to it, and start with the low-level questions again. And then eventually just accept that you might have done a good enough job. So, if I ask you what risks you have, what jumps to your mind? Are you do you

start thinking about versions, open exploits, zero days that you're still vulnerable to? Those aren't risks. Those are vulnerabilities because a risk only exists when you have both a threat and a vulnerability. So if you have a vulnerable version of SSH on a machine, but you've disabled SSH on that machine, it's not a risk, it's a vulnerability. Because if you disabled it, then you don't have both the threat and the vulnerability. So good job. You're already mitigating risks if you're doing that. So to understand impact I think is also a key part of this talk. Basically how will it affect the business? Why are we employed? We are employed to stop businesses from losing money, right? Um,

so if you understand how your staff do their job, if you understand how your business generates revenue, and if you understand what the impact is of these different events occurring, then you can build a rough understanding of how much money you're going to lose if this event occurs. Because if we can say, I need money to fix this. Otherwise, there's a chance that we are going to lose $500,000. That's a lot better than just saying this is really really bad and all of these things will happen and an executive will look at you like okay but I don't know what that means. It sounds bad. It has big words in it but I don't care about big words unless they have a

dollar sign at the start. So calculating likelihood I will not talk about calculating likelihood. If you want to learn more about it you can look up Monte Carlo simulations. You can take statistics courses. You can read how to measure absolutely anything in cyber security. But I am not a mathematician. This is a 20inut talk. So I am not going to talk further about the topic. So you have all those things, you have all those ingredients. All right. So you mitigate them. You make those fixes and again you document. You document who owns the vulnerability. You document what is the mitigation that you are applying to it. You document why you are mitigating it in that manner and then

you document when will you visit this again because if you're mitigating it not eliminating it then you need to know if you need to revisit it say okay is there a better way to do this in 6 months something like that. So risk acceptance um if you are unable to accept your risks if you think this is not great but some executive is breathing down your neck saying okay we have to do this we can't take this system offline the business will lose so much money then you have to say okay but these are how we can mitigate it and if you think it's efficient okay that's fine you might not need a risk acceptance if you do not think it's

efficient you should tell your executive why in specific terms write out a lengthy document explaining to them this is the potential impact to the business. These are the mitigations we can do. These are the time it will take to do the mitigations. This is why I think it is necessary and will impact the business. And then you give it to an executive to sign. You don't give it to a director. You don't give it to probably a VP. You can give it to someone who has the capability to take on risk and ownership for the business. So mitigation is essentially how much you decrease the likelihood or the cost of an instant from occurring. Risks can often be mitigated without

being able to be eliminated. You right, you can remove a threat, you can remove the vulnerability, that's awesome. But if you can't do either, you can still micro segment. You can still put guard rails and safety things in place to make it less likely to be exploited or to reduce the potential impact to your business. This is my risk tracker. I title it. I have a description that needs to be specific enough so that when I have time in six months from now, I'll be able to look at it and understand what I was talking about when I wrote it. Then you need the impact. How will this affect the business? Not what server will go offline, but how does it affect

the business? You need the team that owns it and the contact information for that team. And then you need to notate how you're mitigating it. And then you'll notice that acceptance is still in red because if you have a risk that you are accepting, it still exists. So it shouldn't be green if it still exists. And then I like to just have that PDF URL just all all the documents, all the tickets, every bit of information that is about that ticket, I like to just fill up all of them, link them into the spreadsheet so I can find them without too much hassle later on. So at the end of the day, there's always going to be more risks to resolve and

more security to improve. So a lot of this talk is about don't get lost. Stay on track. If you get a new zero day, a new issue, evaluate it. See the impact that it will have to your business and say if I if I have other things that are more impactful, more likely put it on your thing. Don't ignore it, but put it below what you're currently working on. Because if you constantly get distracted by the latest zero day, you're going to end up building better locks while leaving your safe completely open. So, here are some really great OASP resources. I recommend everyone check it out, but there's also plenty of other resources about that. And I think that

is just about our time for the talk. Um, but we might have one minute if anyone had any questions on it. Oh, and if you could use the microphone. >> Thank you. Very very great talk today. Thank you. >> Um I have a question on risk acceptance. So can you give me an example when it so for example if you're working on something where um say the CRA right the cyber resiliency act and you have a bunch of things to ask your other teams where you need a lot of funding and they say no this is not a business need well I'm just taking a hypothetical example right say they say no it is not how did you

approach on actually having a written consent on accepting the risk and say if it didn't work out and it actually fell fell fell off did how did the repercussions of that work out worked out in your company? So if if it is a legal requirement that we have something um then I just go up the levels of executive and if the executives continue to push back I go to the lawyers because the lawyers um speak executive a lot more fluently than myself and I am extremely privileged to be in an EU based company where if I get the lawyers involved and they start using words like GDPR then people actually might take action. Yeah, I think I took a horribly

easy example. Um, for example, inventory control that you had in the first one, threat modeling, right? Where you have to have you want to ask all your product teams to have the inventory in place. You could have it as an SDL control, but the teams are just not doing it because it's not a priority. >> So, I was just given the stop sign. Um, but you can ask me after the talk. >> Okay. Thank you. Thank you.