Fireproof Your Castle with Risk-First GRC

Okay, people are ready. So, please uh welcome our last speakers uh Lindseay Akash. Give him another round of applause. Uh a reminder if you have any questions and uh please leave them at besides.org/q&a and if you have time at the end uh we'll address them. Thank you. Cool. All right. Hi, I'm Lindsay. This is Akos. Um, we're going to be talking about fireproofing your castle with risk first GRC today. Um, and yeah, thank you for hanging out till 4:30 and wrapping up the day with a talk about risk because you know that is what everyone wants to talk about right before you know you go to happy hour. So, okay, let's get into it. Um, bit of disclaimer

to start. We will be talking a little bit about, you know, the work we're doing at Roblox. Uh, but I just want to say these are our personal opinions for the most part. the data we're going to be talking about is is fake. It is not meant to represent the risk posture or control posture at Roblox. And you know, these are just our opinions. So, I just want to put that out there. Okay. Uh, a little about me. I've been in the risk space about 15 years. I am the senior engineering manager over the security GRC uh leading the you know GRC team. Uh, I started my career in a more quantitative uh field. I was a statistician and then

through kind of a windy path made my way into tech and cyber security. So also if anyone you know wants to chat about how to get into tech or into cyber happy to chat with people about that. Um started in government then in banking now tech. Um very proud of my CPA so I like to share people. Yes I'm an accountant. Um but anyway uh Akash. Hey everyone my name is Akash. I uh work with Lindsay on the GRC team and I help lead and manage the risk program. Uh I have about 12 years of experience. I I've pingponged between the fintech industry into the software industry and back into ping pong pingpong pingponged back into uh the uh the uh the social

media business. So yeah, glad to be here and thanks again for being here until 4:30. All right, excellent. So I think we need to like level set a bit about risk uh risk versus GRC and when we think about that um it's helpful to understand that our GRC program is part of the security organization meaning we are not uh part of legal part of compliance and that really helps us take that risk first lens because honestly you know your legal or your compliance or they have a different lens they have a different perspective they have different objectives ives that they have to care about. So I'm not trying to malign compliance by any means. I love

compliance. I used to work in banking. But by being part of the security org, we get to approach our problems with a risk first lens. So this is our org chart. Um I report to the SISO and uh we the GRC or are peers with the other traditional pillars you would have in an infosc. And again, that just really supports this risk first view. A little bit about what we're doing here uh in our GRC program. I want to emphasize that we're covering off on a large portfolio of work. We're a small scrappy team, but we like to do a lot and we like to be creative about it. So we're trying to balance the need to just

do those kind of foundational GRC activities like good governance that you need to have a solid foundation, but we're also looking for opportunities to innovate and be more effective ultimately adding value for the organization. So right now for us um we are embracing vibe coding in GRC and building our own tools and and we're pretty excited about that. But ultimately what we want to do is just shape Roblox's information security strategy with that risk first view and Akos is going to talk about risk. You know what's the most difficult thing for a GRC person honestly in any company that you work for is talking risk and convincing people of what a risk is. So to begin with, let me put

these words in front of you quickly for a couple of seconds do a mind map of which of these are risks. Count until five. 1 2 3 4 5 Okay, surprise. None of these are risks. These are components of risks that we have in front of us. And that's the challenge. And that's the challenge of a GRC team with a risk first approach. We have uh control differentiencies. We have assets. We have threats and methods. But none of these are real risks. So to begin with, let's level set and let's define what a risk is. In a general definition, risk is the probability of something adverse happening in your environment that you're trying to protect. Risk needs and should always

have three main components. And that's how our GRC team operates. We need to know what a threat is. We need it. It's generally usually people or a set of processes that is going to have an adverse uh impact on an asset. Now these assets need to have value to the company or the value you're trying to protect them. What's the point of not having uh or what's the point of protecting something that's not going to have an adverse effect on your organization? And it needs to be impact. It it uh the risk needs to have an impact. There is no point if if if a threat actor cannot exploit something that would impact an asset and have an

adverse effect on the company's operations, what am I trying to protect? Nothing, right? So, we're not going to call it a risk. Um, and of course, risk is the potential. So, we need to know it's a probability. It's not something that has occurred. And that's the very important distinction that we all need to make sure that we understand. It's something that's probable. It's in the future. it's not occurred. If it has occurred, it's something else. It's probably a finding and we operate on findings in a different tone. So the companies that we work with for us they are are castles. We are trying to protect them. We're going to have a walls that represent controls. We

probably even have a mode that to protect our organization for all sense of protections. And we get attacked from all different sides. we don't always get attacked by the threat actors from the straight door or the obvious path. Uh so that's the threat landscape. It's it's ever evolving. It's not the same like even if you talk about it today and then you talk about it tomorrow probably the the rate at which the environment is changing the technology environment is changing the threat environment is going to be different. But how we understand risk is really important and that's where we come in with the approach of risk first. Before we get into risk first, let's talk about a traditional approach. So

when you hear about GRC, the first thing probably and again this is I I love compliance. That's why where my career began. Uh where the first thing that comes to your mind when you hear GRC is compliance, right? It's it's like okay, it's a compliance demon. It's going to help you be compliant and it's important and we're going to speak about it a little bit more later. uh but it's it's it's the uh it's the approach that really matters like how do you approach GRC in a compliance-driven approach your focus is on internal policies and requirements you you begin with policies and requirements which target a particular framework let's say an ISO fetram or a sock 2 or PCI something

that's going to help your uh business grow as part of helping the sales all come up together uh based on the requirements. Then you do a gap assessment and th the gap assessment helps you find def uh deficiency controls and those deficiency and controls becomes your risk. But ask yourself is that the complete picture for your organization? Is meeting compliance requirement the absolute requirement for your organization? And spoiler no that is not the absolute uh goal of your organization. So when we think about risk first security GRC um it is pretty literal. So we took that same chart and now we have the big yellow box far to the left there and that's your risk

identification assessment. And what that means is we put our policies, we put our control requirements, uh you know legal obligations. We put that to the side and we look at our business. I mean what do we do here? How do we make money? What assets do we care about? What are the critical business processes that help us achieve our objectives? And then we bring our experts into the room and say, well, what can go wrong? How can this break down? How can this be threatened or compromised? And that's how we surface the actual risks to the company. So we define these top risks. Then we start thinking about, okay, well, what are my policy requirements and what

legal obligations do I have? So it's not like we don't think about compliance. We just don't think about it first. And then we do our gap assessment while we take a chance to look at our control environment, right? And then we get our gaps and instead of calling those gaps our actual risks, we call them issues and we map those issues against the risks we identified in the first place. But the point is we are pulling back and thinking overall picture what are the risks to the business what are our gaps in our control suite and that's driving our risk management strategy from there and a cost some tips right so summarizing we in order to make

good use of GRC we need to ensure what we need to understand what's a threat what's an um asset what's the method the pro uh the threat actor is trying to exploit or use to exploit the asset and cause an impact or cause an imp uh uh adverse effect to the company. Uh we use security as a perspective uh to meet compliance but it's not the end goal and security controls will help us meet compliance if we do it the right way. We set the targets as security and we meet compliance. And okay, when we're talking about risk, there is always a a discussion around what's an inherent risk, what's residential risk. Lindsay and I have our thoughts. We can have a

discussion later. Uh what we what we like to consider risk is the current state which involves controls. Again, heated topic. We can always talk about it later, but it's uh don't worry about inherent risks at the moment. Always think of risks at as the current state. Okay. So now that we've defined risk and we've talked about the need to use your risk first to define and drive your security strategy, you ask yourself, well, how do we understand it? And um I'm just going to warn you, this is probably the most controversial part of the talk. So we have two main tools here. We have qualitative and we have quantitative and people have opinions. And so let's get into it.

Okay, let me first start with qualitative. I will first I will say like you guys heard my intro. I'm a statistitian. I'm a quantitative person. I love qualitative risk assessment. I think when it's done well, when it's done systematically, when you consult your experts and you you have a method that you true back to, it is very powerful. It can answer a lot of questions for you. And just because it's qualitative, it doesn't mean that there's no numbers involved. you often assign quantitative ranges to those categories that you're using to um describe the likelihood or impact of a risk. Qualitative risk analysis is really an effective method to take a look at your risks and triage them or

stack rank them against each other. It helps you understand your risk landscape really well. And kind of following on this um you know tips from the castle idea, I'm just going to say a lot of you will use ordinal values with your qualitative risk. That means use a scale 1 2 3 4 five. Um please don't average those numbers or perform any kind of arithmetic on those numbers. They are just meant to describe where your risk might fit on a scale. totally okay to report your outcomes using frequencies or counts, proportions or percentages, but please don't take averages. Again, we can talk about it. It's outside the scope of this talk, but that's my little

um you know PSA. Okay, cyber risk quantification. Now, this has emerged in recent years. there's a lot of hype around it and you can see the hype because there's a lot of tools on the marketplace to help you implement cyber risk quantification uh in your organization and this really came from a call for leaders that wanted more precise risk estimation. Um which is kind of an interesting idea since risk when we're dealing with risk we're talking about uncertain events. So the amount of precision that you can ever really get there um it's subject to debate. But what you're doing with CRQ is you're describing the probable frequency and cost should an event occur during a specific period of time. I

really want to emphasize here CRQ is an estimation methodology. It is not a prediction methodology. It is not going to tell you exactly when something is h have is going to happen or how much it will cost. Um and we're going to get into the difference between estimates and predictions in a minute. Um I truly believe anyone can do cyber risk risk quantification because it really just involves gathering a few data points and running a Monte Carlo simulation. But anyone who tells you it's easy, I don't think is really telling you the full story. To do it well, it actually does. It takes a lot of rigor. It takes a lot of work. So it's easy to get an output

from a model, but the quality of your results is going to vary. Um, so just a moment to go off on a bit of a side quest here. This idea of estimation versus precision. So in CRQ, the underlying methodology is the Monte Carlos simulation, which is a statistical method that allows us to handle a lot of unknown values for the independent variables going into the equation. Um, and that's why it is more in this estimated realm. In prediction, a lot of you may be f familiar with a regression analysis. It's that kind of fit a line style of math. You're using actual data that you've collected from known observations to predict something, predict a value

within kind of your known scope of values. They're different. I don't want to get into that here, but I think it's important when you're presenting the results of CRQ to manage expectations with leadership. They will want predictions about risk. We don't make predictions about risk. We make estimates about risk and we describe risk and we say okay here make your make your informed decision about security strategy. Okay. Now doing CRQ best model out there factor analysis of information risk the fair model. This can look overwhelming but when you break it down really it's just risk decomposed into two main pieces. We've got your loss event frequency which is just the probability of the thing happening and

then the loss magnitude. Again that's just impact or severity. You don't need all these other data points to run the model. Um but you know the more data you have the better obviously but what do you get when you run a CRQ? uh I think the most helpful uh graphical result and the way to interpret the information you get is in this histogram style where say you run 50,000 Monte Carlo simulations and um you get frequency on the vertical axis and then the dollar loss with increasing dollars uh you know more to the right and in most cases with cyber events as we know most of the time nothing happens. Uh the world of cyber is

infrequently occurring high impact events. And so what we see with the results of our Monte Carlo, that big blue bar, that's no loss. And then we see um with less frequency going out um the more costly the event becomes. So when you're talking to leadership, it's important to try to get a sense of where they are worried. Are they worried about that little red bar, that thing that's probably never gonna happen but could destroy the company? Um, it's helpful to understand what they are worried about because it'll help you choose the control strategy that makes right right sense for your organization. Okay. So now I've just talked about both methods. So I have you know this this idea I have two tools.

Let's use them together in a hybrid fashion with a typical risk problem. So, I am in my organization and I have this top security risk list. They're all red because they all seem bad. What do I do? Well, this is where qualitative is very helpful. I'm going to use qualitative to do an initial triage. I'm going to get my experts together. I'm going to give them the methodology I want to use. They're all going to be uh working off the same sheet of paper. We're going to talk about it and then in a systematized standard way we're going to rate our risks. And by doing that we can see these four risks now are emerging into

an ordered list. We have a critical risk, two high risk and a medium risk. So let's dig into this critical risk, this deletion of critical assets. This is now where I might want to use my CRQ to help drive my strategy. Now again uh this is all made up. It's just meant to demonstrate how this might work in your organization. So you have this topline risk deletion of business critical assets. In order to use cyber risk quantification, you have to anchor the risk within a scenario. And thinking back to what Akos was telling us about these three elements of your risk, this is how you build the scenario. So I need to know who is doing it. A malicious

insider. What are they doing? They're misusing their authorized credentials. And what is the asset that is going to be compromised? The critical data asset. We're going to delete it. And what's the bad thing? Well, significant financial loss and operational impacts. So, because I've scoped the scenario, I can make more precise estimates about what I think the likelihood of this thing happening. an insider has a very different likelihood of success than an external actor if you can follow. Um, and then how much how bad is it when it does happen. So at a base level, you only need six data points to run a Monte Carlos simulation. So on the likelihood side, you need to know your minimum,

maximum, and most likely values for what you think the probability of this thing happening is going to be. And on the impact side, same three values, minimum, maximum, most likely. And the Monte Carlo will run the simulation for you using a distribution between those values and just keep bumping up those against each other to get you a range. Um, so you can leverage data sources within your org. But, um, I'm going to tell you something. Even when you're doing cyber risk quantification, you do make some subjective judgments in there. So people that you know want to think that CRQ is like a purely quantitative methodology, they might be kind of fudging it a little bit. There's still

some judgment involved. Okay. So I ran my Monte Carlo and then the result looks a lot like that graph I showed you before. Most of the time nothing happens, but 46% of the time we do have a cyber event and when that event occurs probably between three and $9 million of loss. Now I present this to leadership. That's powerful, but let's get even more helpful. Let's think about our controls. And this is where I think that CRQ really has the power to make a difference. So, I have a bunch of controls. What controls do I choose? Well, I'm going to go real simple. Do something around access management. That's going to reduce the likelihood of

the risk. Or I'll choose a different control. Um, go after the impact side, build out my stock. And again, I've got some estimates here about the likelihood reduction here and the impact reduction. So I run my model again and as predicted or I'm sorry, as estimated, the control has or this scenario now has a 25% chance of occurrence. On the second one, the impact reducing side, I went from I think was 3 million to 9 million to 1.2 million to 4.2 million. So again, the outcomes that we expected, we're seeing. I have some numbers, but that doesn't mean I have an answer. And I think this is the most important thing we need to remember as risk

professionals. Our results don't point, pardon me, point to a clear path. We are just providing decision makers with one piece of data to consider, but there's lots of other pieces that they have to factor in. What is their risk tolerance? Will this control bother my engineers? Is it going to make it harder to do business? And honestly, is the cost of this even worth it to me? We'll revisit these ideas in a few minutes. All this is to say, I would highly recommend you use a hybrid approach in your organization. Focus on those big existential risks and use qualitative for that. After you understand the landscape, start asking more targeted questions and then use CRQ

for that. Bring them together. Um, again, especially in the CRQ results, be aware of this false precision. Your statistical model is going to spit out a bunch of numbers. You have to understand what those numbers are and how to present them to leadership and make meaning out of them. Um, never fall in love with the method. Choose the right tool for the question you're trying to answer. Honestly, for about 90% of the risk questions I get, qualitative is just fine. And now we're going to talk a little bit about compliance. See, we told you we love compliance, but we didn't speak about compliance, did we? Yeah, that's because uh compliance is going away. That's breaking news. Uh you guys are probably

thinking, he does not know what he's talking about, and you probably would be right if I believed in it. Compliance is not going anywhere. Compliance is something that helps the business run. Uh we can't create trust without showing a paper trail. Right? So if if I say I'm secure, are you going to just trust me or are you going to be more trustworthy if I give you a piece of paper which says that it's attested by a third party who is independent? They don't have any business with our organization. And that's when you're like, okay, the these pro people are probably saying the right thing. So that's where principlebased compliance is something that we like to

preach. it's it's not re meeting compliance but still meeting compliance. So the way I like to think about it is uh a security environment is like a maze where uh we have walls which are compliance um which are which are representing compliance and the exit on the other side is what our goal is or that's where we need to be. you can actually achieve it when you go through the maze, you achieve compliance. You the way you probably do and the way if if you want to do the right thing is if you if you meet the the the need to meet security, you do the right thing, you use risks to understand what the risk the

organization is exposed to. You understand what the threats are rather than focusing on meeting compliance. I want to meet a sock two is probably not going to make you secure. What's probably going to make you secure is I want to implement controls that protect me from threats. And you know what? On the way to getting there to being secure, you meet 80% to 90% of these compliance requirements. And that's the approach that would get you to security because we want to change the narrative from from a question which says are you compliant to are you secure?

So revisiting this idea of decision support. So again our leaders probably are wrestling with this idea of are we compliant? Are we managing our risk? And these us as risk security professionals, it's our job to understand that we're providing information that's just one bit of context for their overall decision. But ultimately our goal is to understand that they have information beyond what we have. But we need to be a partner with them and helping and be an enabler. Like how can we as risk people get to yes, get to where the business wants to go. And so it's a balancing act all the time. We're not a blocker. We help them understand the risk and make

measured principlebased decisions um that ultimately are going to serve the organization and and us. And that's it. Thank you.

When it Okay. When it comes to GRC, in your opinion, what is the most important of the three? What should we lead the security programs with GRC? Um, I think it obviously we're a little biased. We believe risk to be the most important. Um, but it depends on your organization. I think there's very valid cases. Um, I come from government. I've worked at bank. I can think of hospitals where maybe compliance actually is the most important thing that they need to prioritize. So, you know, classic auditor answer, it depends. But just think about what your organization's needs are and choose a strategy for there. But if you are a compliance-driven organization, I would encourage you to do the work to think

about risk first because what we often see is people are implementing a control strategy and not really understanding what risk the controls are actually mitigating and I think you need to understand the relationship between your controls and risk to really be effective as a GRC. You want to take the next question? How should GRC teams leverage or work with other infosc pillars to create risk scenarios? So there are various methods that of course we use uh and uh there are experts in the various pillars that help us get to those scenarios. Some of those for example let's let's look at a threat scenario right so you go to a infosc team they know the details they

are into the nitty-g gritties of what control how it is implemented and what threats they have. So they have the data points. So you work with them to first make them understand that we're going to get to a risk and help with their help identify the three data points that we were interested in. What threats are we seeing in an environment? What controls we have in place to protect the assets and if those controls are not accurate, what would be the impact? So that's how we approach the scenario of creating risk uh like coming to a risk scenario that's more accurate to the current state of the organization. Okay, I'm gonna I'm gonna take two

questions here. So, someone asked, how do you estimate minimum maximum likelihood for a scenario? So, again, you're thinking about two different pieces there like the threat actor doing the thing that you've described in the scenario is getting at the likelihood and then the impact is related to you know financial damages. Um there's ways to go about this. You gather data from within your organization, your security systems. You can go externally. There's a lot of data out there. Ultimately, it's a conversation. You yourmemes know the history of your org. They have access to data. Um, I guess what I'm trying to say is it's conversation driven. Even though it's cyber risk quantification, you need to talk about it. You need to figure out

where to get the good data and what the data mean. Um, the other question is how would you apply CRQ to a third party risk management program? Another spicy take I have is I think that uh some of these different program distinctions are quite arbitrary. Risk is risk. CRQ works, you know, it's it's for cyber risk specifically, but that model, the idea of decomposing risk into likelihood um and impact works with any style of risk. Um I've done a risk assessment of my cat destroying my couch. it it really doesn't matter. It it's just you just need to have the data behind the risk you're trying to estimate. So CRQ applies to third party risk management.

We just we have to scope the scenario. We have to define what we're worried about and then we estimate the risk from there. I think we're at yeah at the end of the session. So thank you. Please give a round of applause our last speakers and to