Beyond the Spreadsheet: Mastering Cybersecurity Risk Management with Joseph Haske

TLDR;

• Communication is the key aspect of running a successful security risk program. In order to do it well, understand your landscape, understand stakeholders and their goals.
• When choosing Qualitative vs Quantitative risk management approach, the framework you can use is use Qualitative for decision making framework and Quantitative for in-depth scoring.
• Prioritization plays a major role in risk management programs. Understand your asks and prioritization of other teams in the organization before engaging.

Transcript

Host: Hi, everyone. This is Purusottam, and thanks for tuning into the ScaleToZero podcast. Today's episode is with Joseph Haske. Joseph works as a risk manager at PipeDrive in the security department. He has a master's in actuarial and financial engineering from University of Tartu. His previous experience gives him unique perspective on problems faced by security industry today.

Thank you so much, Joseph, for coming to the podcast and I'm looking forward to a fun conversation.

Joseph: Yeah, I'm also really looking forward to a good conversation. I hope I have some interesting insights for your audience.

Host: Absolutely. But before we get started into the security aspect, I know that we were chatting about it right before the recording. You have a unique background. So do you want to talk about how did you start into security? What made you jump into security while coming from a different background altogether?

Joseph: Yeah, so it's an interesting story. I was looking for data science jobs. I had just got finished my master's degree and PipeDrive is located in Estonia, or at least that's where the big place is in Tallinn. We have, I think something like 550 or 600 employees in Tallinn. And yeah, I applied as a data scientist to the information security department, which is much more related to my degree than I think where I ended up.

And the CISO at the time was the hiring manager. said, you know, I think he said, you know, I'm putting together this team and I think he would be a good fit, but I want you to be in risk management instead, which is a little bit tied to the actuarial topic, but that's how I ended up becoming a risk manager at Pipedrive in the security department.

Host: Interesting. One of the questions that I ask all of our guests, and based on different roles, get different answers. What does a day in your life look like?

Joseph: My day looks like a lot of conversations. I have quite a few meetings, usually at least 10 hours a week worth of meetings, trying to engage with people who get their, their opinions, their insights. I'm also part of the AI use case review board. So I'm handling use case reviews from the security perspective, which means even more talking to people. I spend a lot of it asynchronously working also on documentation, writing up risk reports, doing documentation related to different processes, procedures, trying to write down the knowledge that I have so that way it's there and somebody else can follow it. And then there's the piece of trying to make sure that the thing that I wrote down makes sense. So getting feedback on that.

Host: Okay, so looks like a lot of things you're trying to do on a day to day basis.

Today's focus is primarily around risk management approaches, quantitative, qualitative, what are the strengths, weaknesses, and what are the common pitfalls and things like that, and why it maybe doesn't work, what has to be done so that it can get better. So let's dive in.

So given you like non-tech beginning of the career with background in actuarial, financial engineering, also you are a US Navy veteran, it must bring a unique set of discipline and experience and outlook to the field of security. Have you found this to be an advantage, like helping you to communicate about the risk in a more compelling way to let's say non-security stakeholders. If so, then can you give an example?

Joseph: Yeah, I, thought quite a bit about this and the Navy is the thing that really helped me the most because I try on financial engineering. This is more about getting complex information, thinking about it and understanding it. But the Navy was about communication. How do I communicate in a way that people are going to understand? I remember one example, I had to wake somebody up in the middle of the night and explain to them why we needed a part for a machine that was broken.

And if you're waking somebody up that's tired, you have to explain it to them so you can get their approval. They have to explain it to somebody else to get approval who they're also waking up. You need to be really clear about the communication. And I remember it was so rigid, the rules, that we couldn't even say words like increase or decrease because they sounded too similar. We have to say this is going up, this is going down. So it was to that level of detail that our communication was regulated.

Then, I mean, know you asked for one, but I have a couple of examples. Then the next thing was this, we had to have knowledge of the whole submarine. So when I qualified submarines. And so instead of just worrying about security, I'm also trying to learn about sales, about marketing, about privacy, about legal, so that when I communicate to those stakeholders, I have a better understanding of where their priorities are and what kind of language do they speak? What things are they interested in?

And through this, I'm able, I feel like to communicate better with them, which of course requires this continuous learning attitude that everybody talks about. You want to be continually engaging with material.

Host: Yeah. Yeah, I love that we started with communication. So I was recently watching a podcast of Facebook's CTO. one of the things that he and he spent a little bit of time on this. One of the things that he was highlighting was the communication is the job like.

And I believe it strongly that in security, is one of the key skills you need to have because you will be interacting with a lot of folks who are for whom security is not the priority or they don't understand that language. You have to simplify it for them. So yeah, communication is definitely one of the key aspects. And I love that we started with that.

And another question on this, how has your background influenced your perspective on methodologies when it comes to risk management? Do you see any benefit or anything that you can draw from your background?

Joseph: Yeah, I think it's this, actuarial background where we try to think about a model and we see if it works. We then break it. I'm actually stealing from, took a micro economics course and I'm taking material from his lectures, but basically in these mathematical sciences, what we try to do is we try to create a model and we see how it's not working. And then we try to fix it from there. And so there's a quote from, I believe it was a statistician, George Box, it's, all models are wrong, some of them are useful.

So when we look at risk management, we have to look at, okay, we know that the model is wrong. So we need to know where it's wrong and how that affects the outcome so that we can interpret the score correctly.

Host: So I think in software engineering also there is a somewhat parallel, not exactly same, like we do test-driven development where we start with tests, you write tests, and then you validate that those tests are failing. Then you write your program and make sure they pass. That's one way of sort of validating that you have a mental model and you are thinking in the right direction.

So I'm just trying to draw parallels between them, but I can see how you are sort of correlating between the models in statistics to security, how we should use that from a risk management planning perspective.

So for today, as we said, we'll be focusing on quantitative and qualitative risk analysis. So there is a lot of literature around it. And there are experts on both sides. Some say that you have to quantify everything. Some say that, have to look at quantification is one aspect. Some of the security aspects you cannot quantify. You have to look at it from a qualitative aspect.

So beyond the basic definitions, what are some of the nuanced scenarios when one approach is better than other? What have you seen when it comes to cybersecurity, like risk management?

Joseph: Yeah, I see when you want something that's easy that people can grab onto and really what you're the core of what you're looking for is a decision making framework. This is where qualitative really shines because essentially what you're doing is you're rating the risk based on who you think should make the decision.

And pretty much all of the quantitative authors that I've read have said that expert, expert like intuition is better than qualitative risk management. But the way I look at qualitative is a little bit different where you're not necessarily measuring the risk, but you're putting the organization around this decision-making framework. You're standardizing this. So everybody is talking about the decisions in the same way. Okay.

The CEO definitely needs to make a decision on this. We have why he needs to make the decision on this because the impact and likelihood give this risk score. The I can make a decision on this because it doesn't have a speak of an impact. It's not as likely. And so I think if you look at it from that perspective, you can make a qualitative approach work. And this is a good scenario for it.

Now shifting gears to quantitative, you want to use this when you really want to dig in. So you want to understand something more. You want to understand the dynamics of how it's working. You want to look in, build a model, figure out if the extra spend worth it. And you don't have that necessarily expert intuition. They're not sure.

Host: Okay. Mm-hmm. So qualitative view, look at it both from a decision-making framework for the organization, you have a standard approach, quantitative when you want to dig deeper. So more like a T model where you use quantitative to dig deeper into things.

So now when it comes to these two options, what are the strengths or weaknesses that you have that in these frameworks that organizations need to be aware?

Let's say you want to follow a qualitative approach, then what should you be aware of before you say that, this is the approach that we want to take for decision making.

Joseph: I think the biggest strength of it is that it's easy. People can understand it. They can look at it. They don't get intimidated by the math behind it. And this allows them to actually use it. Now they do have to be aware that the big weakness is that you're not really measuring risk. You're more measuring the feeling around the topic. And so

A lot of the quantitative literature is where you can find the weaknesses, but it talks about how these matrices can't be consistent. So if you use the scale of one to five, five, so impact of one likelihood of five does not mean the same thing as the other way around, even though they would both be scored as a five.

So this is one of the biggest weaknesses to make sure that you understand that there are inconsistencies and it's not the end all be all. It's more about the decision.

Host: Okay, one question that comes to my mind is, let's say, how would you educate your team so that they follow that approach?

Is it more around training?

Is it doing like brown bag sessions?

How would you train your team so that they follow the approach that you have laid out in front of them?

Joseph: I think it's about reminding people from time to time. Like if I give them a training, then maybe they'll remember it. But it's more for me about providing consistent reminders of, you know, this is the decision level we're looking at. isn't, I don't come out and say this isn't the risk, but I try to focus on - hey, who do we need the decision from? And by framing it like that, I can enforce this thought process without forcing it on people. They can come to it naturally like, I think actually this is a CFO decision. And then when I'm doing the risk analysis, I can go into that with that in mind. When we're talking about the risk, I can use that to frame it. And I don't have to necessarily explicitly train people to think like that.

Host: Okay, so you put together, let's say, the playbook so that folks know for different decision making what approach to take. You have also written about like quantitative risk assessments and the dream of doing like being quantitative risk management approach. And you have also cited like a FAIR approach, like F-A-I-R approach, like based on your understanding, experience and research.

What are the fundamental differences in the underlying philosophies and data requirements between a purely qualitative and a quantitative approach like FAIR?

Joseph: So from a data perspective, I can say that it's not that different. Pretty much all of the quantitative authors agree that, yes, you can calibrate people. And I was really myself very not so ready to trust that. But then I did a calibration course where I saw my ability to estimate get better as I went through the course.

Now, quantitative allows you to dig in a little bit deeper with more data. And so you can use more of the data that you have. Now you still have to create a good model. can't just blindly go in and make something, but you can use a little bit more of that data.

When it comes to philosophy, if I can shift gears here, then the qualitative philosophy, is that it's easy and that it should work with the business, not be this big mathematical overhead that you these top specialists to come in, a bunch of mathematicians to come in and figure out how to do this and calculate this.

And when we talk about quantitative, their focus is always on, we want to get an accurate answer. Now, how accurate can you be? That might be a range of one to ten million dollars of potential loss, but they're saying that this is the level of accuracy that you can get, then we can get there by a quantitative method. and we can have a little bit more certainty in that answer.

Host: So for an organization, let's say a growing startup and they want to build risk management program in their organization, would you recommend they start with more of a qualitative approach and then as they grow, they should look at quantitative approach? What would you recommend in that scenario?

Joseph: I think it's a lot easier to lay down a qualitative framework. so getting started with that, you can start working that risk conversation muscle. Now it is really easy to get stuck there. It can be hard to, okay, we have something that really works. We have our decisions documented. We're getting risks mitigated. It can be really hard to bring the organization up to the quantitative level.

And maybe the appetite isn't there in the organization. But what people can even do is end up creating this quasi method where, oh, now we want a little bit more information. We can start including the number of incidents related to this, the cost of the instance, because usually this is a little bit easier to calculate than just an ambiguous risk, they can start to bring in the number of vulnerabilities they have. And now you're already starting to get into this quantitative plan and you're in more of a hybrid environment, which keeps that ease of use, but allows you to dig a little bit deeper when you feel like you have the confidence to do it or the data to do it.

Host: Mm-hmm. One follow-up question to that is, like you mentioned about hybrid approach. So I want to understand, if an organization focuses heavily on qualitative approach or focuses heavily on the quantitative approach, do they lose out the benefits of the other approach? Is hybrid approach the solution that everyone should follow?

Joseph: I think if the organization has the resources for quantitative, that's the place to be. I think if you are only using qualitative, you're missing out on a lot of information.

Host: Mm-hmm. OK, that's fair. Can you give an example of what does a maybe a few approach? Yeah, maybe one example of a qualitative approach versus a quantitative and maybe a hybrid approach that we that an organization can take.

Joseph: So a purely qualitative approach is usually, I think this is medium risk for this and this reason. Maybe the organization has impact and likelihood, very vaguely written down. So it might be something like this has a high likelihood of happening. And this is very qualitative. It's based on what my perception of high risk is, what my perception of medium impact is.

And I saw very early on in risk management that this varies quite widely. And I even had to, I was thinking like, wow, know, $10,000, that's a lot, but for an international organization, risking that isn't so much.

Yeah, it was quite the adjustment, but it showed me just how different people's worldviews can be.

And then… Yeah, I think I forgot the rest of the question.

Host: So that is a qualitative example. On the quantitative side, if you have an example that you can share.

Joseph: Yeah. So on the quantitative side, then this is where you're going in and you're either making a model yourself or you're using something like the FAIR model. And what it does is it gives you. the actual you calculate what do you expect to lose monetarily? Or maybe you can also use other units like hours spent or computational resources, and then you calculate how likely that is, and you end up with a probability distribution. $100,000 or more loss is likely in 5% of scenarios.

Host: That is very mathematical. I mean, I see your point why you were saying that if you have the resources, you should definitely spend, like you should definitely focus on the quantitative. But there is a lot of math and statistics that you need to rely on to come to some of these quantitative scores in a way.

One of the things that you have emphasized in your proposal is that there should be a peer review of the risk coding. by stakeholders in different business areas. Why do you think it's required? Or why do you think it should be done?

Joseph: Yeah, I think it comes back to this point that I brought up not so long ago is that people have very different views of what high risk is. So if you can take your set of assumptions and tell people, this is why I think this is high risk and others agree with that, then you have some assurance that the assumptions that you've made are correct and that your conclusion is correct.

And so even if they have some different view of what high risk is, then you have convinced them almost that your view of high risk is correct. And I think I've only had one case where they've been like, no, you're very wrong. We have discussions sometimes, but yeah.

So it's really good. And when they did say, no, you're very wrong, it turns out, yes, I was very wrong. And if I had gone to the executives with that kind of an assessment, then they would have just thrown me out and said, try again.

Host: Yeah, OK, I see your point. And it also brings collaboration and brings other leaders together so that you also get their buy-in, right? Not only they sort of agree, you discuss and agree on a scoring approach or the decision-making approach, but you are also in alignment with other teams as well.

One side question to that is, what are some challenges do you see with implementing such a process, especially when it's a large organization? Like, let's say you need to work with 10 leaders and everyone is busy, right, nowadays. So does it impact on your deliverable timelines? Does it impact, like, do you take some shortcuts in those scenarios? Like, what are some of the challenges you have seen of implementing such a process in a large organization? And if you want to touch on how can organizations tackle them as well.

Joseph: Yeah, I haven't actually run into this because I've only implemented it in one place and we all agreed that it was good idea. We're also all impartial. We're the legal privacy and security team that are reviewing these. Now, what I could see in a large organization is that the people that view them and peer review them aren't working so closely together.

And so you end up with this situation where maybe the people are further from the business area that they're reviewing it for. So they have no idea. And so they can't conduct an effective review.

Or the other potential problem I see is too many chefs in the kitchen. get too many stakeholders in a large organization being part of this risk steering committee, which is the body that we use to peer review the risk.

And let's say you get somebody from sales, somebody from marketing, somebody from engineering in that group. Well, they have their own departmental agendas that they need to push. They have their way of looking at things. And so I could see a situation where you end up getting deadlocked.

And so in that case, I think you have to be deliberate about who peer reviews it. has to be somebody that's close enough to the assessment that they still can provide an effective review, but they also have to be impartial. So maybe if it's an engineering risk, it needs to go to the IT department where they can still understand some of the technical things, but they don't have a vested interest in what the end score is.

Host: Yeah, makes sense. So how do you solve some of these challenges?

Joseph: Which challenges?

Host: Like working with different departments and them bringing in, like as you mentioned, right? Like they might have their own interest to be put forward or if they do not have enough context, some of these challenges, like how should organizations tackle them, any recommendations you have.

Joseph: I think you have to keep in mind how much you're asking of them. So just because you've identified three high risks in one area of the organization doesn't mean that they're going to be able to go through all of those at one time. So you have to be intentional about how you introduce them and how you talk about the priorities to them. Because they also have their own initiatives that aren't security related going on. So keeping an eye on how much cumulative ask you have from the department helps. And then also being clear when something isn't high priority. So, hey, I have this risk for you. This really isn't a priority for us right now.

We know that you have all of these things that you're working on and you acknowledge that they do have work to do. And you're trying to work with them, not just force some new security measures on them.

Host: Yeah, I think there is an age-old debate about prioritization, right? And the friction between security and engineering when it comes to what's a priority, what's not a priority for both the teams. So yeah, I'm glad that you called out like prioritization is like working on your prioritization and also helping the engineering understand that what is a...

And it's a P1 which has to be addressed this week or it says what can wait for a couple of weeks. Makes sense.

One of the questions that we received around like risk management programs from one of our common friends, Mauricio, is what is the biggest misconception related to risk that might hamper any efforts when starting a security risk management program?

Joseph: I think one of the biggest ones is if you already have a risk management framework somewhere in the organization, that security risk is so different that you can't build on that. For example, when I came into the organization, privacy was doing some risk management already.

And so, we did have to build from the ground up essentially because they weren't doing a whole lot. wasn't nearly as formal as what we have today, but we were able to build on that. so it's about this understanding that a risk management framework, it does work.

Like it will work for any type of risk. You don't have to say, you know, we have an operational risk framework. Then over here we have the engineering risk framework. Then over here we have security. The risk framework works. So don't try to over complicate it.

And that was one of the principles that I tried to follow is what are the simplest pieces that I can put into place that will give us the foundation that we can start. And that's how you get around this misconception.

Host: Okay, makes sense. So we have been talking about the risk management, how does it work, what are the challenges, different approaches and things like that. I'd like to get your take on the future of risk management.

What are some of the significant shifts or advancements you anticipate in the field of cybersecurity risk management coming in?

Joseph: I think that the biggest shift that's coming is the standards moving to requiring quantitative. And particularly, you see stronger and stronger regulations in the EU with the EU AI Act, GDPR before that, you see that stronger and stronger regulation, regulatory environment. And I think that's going to hit cyber security risk. If you look at the history of any other type of risk, whether it's credit risk, life insurance risk. I don't know if that's how you call that risk, but you the, risk behind life insurance, the risk behind auto insurance, all of these has hit a quantitative requirement. And this is the standard. I think cybersecurity risk just isn't old enough yet to hit that. But I think that day is coming when everything is known enough that the shift can happen.

Host: So if that is the case, I totally get your point because at some point there has to be a standardization, right? So how should security leaders prepare for these shifts? Like how should they, what should they plan for? Let's assume that some of this will start from next year. Then how can security leaders prepare for some of these?

Joseph: I think it starts by using quantitative when you can. It could be something as simple as, like I mentioned earlier, putting the number of incidents in the risk report. That's a quantitative measure of how often does this happen. And if you start incorporating these metrics now, then you'll already have them. They may not be in the format that you need for a quantitative assessment, but you'll have them.

And your quality of your assessments will go up to the assessments that are the highest in quality for me are the ones where I include real numbers. And those are the ones that the people pay attention to the most as well. It's like, Hey, we had an incident and it costs this much money. And it's pretty likely that we're to have this type of incident again is much more compelling than. Yeah. I think this is high risk.

Host: Because now you have data to back it up, right? That you can say that it costed us, let's say we had to pay a million dollars for a ransomware attack or something like that. You can clearly show the impact of it. So OK, makes sense. Anything else you want to add to that?

Joseph: No, I think that's what I had to say about that.

Host: OK, so one last question that I have is that we are living in the age of AI, right? Like with the advancements in generative AI, now not only we are using for generating, let's say, more code or generating more doing security evaluations. We are using it for security and you are using it to secure as well. So, and I have attended recently a couple of events like RSA, AWS Summit and everyone is focusing on leveraging AI security or AI for security.

How do you approach the sort of the challenges of assessing or managing this associated with some of these emerging technologies like AI or now there is a lot of chatter around quantum computing? How do you do that?

Joseph: So it actually ties back to this misconception that I mentioned earlier that every risk type is radically different. Now the time horizon might be different that you're looking at, but the underlying framework still works. It's the knowledge that you have to have about the technology. So we're looking at AI risk right now, which means that I have to dig into, well, what are the laws surrounding this? How does this interact with GDPR in the EU? What are the new security vulnerabilities that can come about because of AI?

So it's more about learning about the new technology and staying up to date with that. So, you know, what questions to ask. It's very similar. For example, if I were to switch from cybersecurity risk to legal risk or to operations risk, it's a different set of questions that you have to be ready to ask.

Now luckily with AI security risk and security, there is a large overlap among the questions. You just have to be familiar enough with the technology that you can ask the questions in the right way.

Host: OK, OK, makes sense. One last question is, like we touched on this earlier, right? Like for your decision-making framework or your scores, we collaborate with other teams so that we have alignment, and that helps us move faster as well.

How do you build such a culture in an organization so that risk management, the overall program is not seen as just a security team's function, but everyone has a role to play? How do we drive that culture?

Joseph: Yeah. Well, we luckily managed that. We went from a security and privacy risk management program to an enterprise risk management program. And it's about getting buy-in. The first part is being willing to explain, explain, explain. Because if you explain something to somebody once, as we've discussed, they have all of these other things to worry about.

So if the, I don't know, the CEO, he's got things to think about. And you say, hey, this is the risk management program. And you say it once, the next time you come to him about it, he's not going to remember necessarily how we do it in our organization. But if you're continually talking to people about explaining how it works, then you're providing this constant. It's almost like a micro training. and, and this is the first big pillar.

The second big pillar is to do it really well. If you can write up a risk report that's really compelling and you get this decision-making down where it's recorded, organized, then what I've seen is that other people also want this because we're all fighting for the same resources.

So what they want is a way to present their information in a what could go wrong type of document. And what does this mean for the organization? And so if you build it really well, then people will want that. They'll ask, then the explain, explain, explain, stops being you reaching out to people and being like, hey, we have risk management. And them coming to you and asking, how can we get involved?

Host: Yeah, I love how you sort of connected this to the answer to the first question, which is around communication. So at the end of the day, how you communicate with other leaders, other team members, so that you have alignment and they also see the value of the security risk management programs, so that they not only are informed, but they are also contributing to it in an effective manner.

So yeah, love that. And that's a great way to end the security questions as well.

Learning Recommendations

But before I let you go, I have one last question, which is, do you have any reading recommendation for our audience? Like it could be a blog, it could be a book, or a podcast, anything like that.

Joseph: Yeah, I gave this question some thought because I knew it was coming and I decided to keep it topical. So there's the FAIR book. You can look it up. What it's actually called is Measuring and Managing Information Risk, a FAIR Approach and it's by Jack Grund and Jack Jones. This is the most comprehensive and I think fair between, not to use a pun intentionally, but it's the most fair between qualitative and quantitative. It doesn't feel so aggressive and one is better than the other. think it provides a really well-structured, this is how to do a risk assessment. This is how to stand up a risk management program. I was actually going to bring it, but I forgot it's in the office. I keep it there because I find it to be such a useful reference.

Host: Okay, awesome. Yeah, thank you for sharing the recommendation. So what we'll do is when we publish this episode, we'll add it to the show notes so that our audience can go in and they can also learn from, learn the fair approach from the book.

So yeah, that brings us to the end of the episode.

Thank you so much, Joseph, for joining and sharing your learning, your experience. And I'm pretty sure our audience will get value out of this discussion.

Joseph: Thanks for having me. It's been a lot of fun.

Host: Yeah, absolutely. And to our audience, thank you so much for watching. See you in the next episode!