Name: Incident Response in the Cloud: The Modern CISO’s Plan
Uploaded: 2025-03-26T16:00:52.806Z
Duration: 30 min 24 s
Description: Incident Response in the Cloud: The Modern CISO’s Plan

Transcript for "Incident Response in the Cloud: The Modern CISO’s Plan": Hi, everybody. Thanks for joining this with this editions of the CSO webinar series. I'm really excited to have you all with us. My name is Adi from Wiz, and I'll be moderating today's session. We'll have about twenty five minute panel discussions here, and then we'll also leave enough time for q and a in the end. So please put your questions here in the chat throughout, and we'll get to them. With that, I'm excited to be joined, by, for a great panel and discussion so we could share and hear some personal experiences, perspectives, strategies, and have a question here. So rather than trying to summarize the many, many reasons why, you're a perfect speaker, Itai, I'd love to have you introduce yourself. Hi, everyone. My name is Itai. Thank you, Adi, for, brief intro. I'm, the CISO at Sixt, current company out of Germany. And, yeah, happy to speak to you guys today. Thank you so much, for joining us. We go a few years back, so always great to have an opportunity for discussion here together. David from Repsol is about to join us as well. So soon we'll be able to introduce him as well. I think he's having technical difficulties. So we'll be joining us in a minute. But for now, Itai, let's start with one question to to get the ball rolling. So, many organizations' incident response strategies were designed to mostly address non cloud threats. There has been a huge shift in the past years, but I'd love to hear from you what makes cloud threats different, and what has it impact on your IR program strategy so that you're indeed cloud ready? I think to begin with, how incidents or how even how to even start looks very different in the cloud. Right? It's it's less did you click that? And more is that supposed to do that thing? Right? The the the whole thing shifted, to a more technical oriented problem space. And this fundamental change, obviously, we will talk about it in the next thirty minutes quite a lot. But what we look for for this whole thing is, first of all, what do we call an incident? So is it different in the cloud than it was before? For me, the answer is yes. Right? The the the thresholds have changed to what we have to, take care of or or what we consider an incident to begin with. And then also, what are the what are the necessities that the person who's handling that the an incident or the the organization that is facing an incident, has to have, in order to successfully, go through them. And I think it's at its core, it it's not fundamentally different. And this is an incident, something that has that has happened. The organization is not gonna be happy, most likely at the end. But the way to get from where it started to how it ended is is very different, and the people you need to have involved to get to this in your best situation, to in your the best capacity to to the end of it, fastest, least damage, least impact, and so forth, that highly depends on the people involved, the technologies that you have, and most likely how prepared you are before this thing hits you. So Thank you for that. With that, are there certain challenges that you've experienced as part of the transition? While you said that there, you know, conceptually, there are some differences and some not. But if you look at certain challenges for that, how would you approach them? So I think one of the if I mentioned before, it's less about if you look at our security operation team today, they have to deal with cloud stuff, cloud incidents, cloud it's it's not necessarily an incident. Sometimes it's it's a it's a signal that shows you that something might wrong might be going on. When you deal with systems with with with, operations that are more human based, it's a lot more you go and ask, you figure it out. There's there's it's more tangible. It's more it's sometimes more it's easier to grasp. And when you look at signals that are showing, again, abnormal something that abnormal that's happening with the cloud, it's not always easy to figure out if it if it's even supposed to do that. Right? First of all, so many different technologies come in every day, so not everybody is aware of who's bringing in what. The business is moving very, very fast. Sixt has hundreds of engineers. We we're very cloud native. We have a lot of innovation happening every all the time. I I can barely keep up. And to expect that security teams can always figure out what's going on, which technologies are there, it's very hard. And then when those technologies interact with each other or at least some stuff are happening that you didn't know that they were there before because somebody implemented them this morning, it's very hard to know if it's if it's even meant to happen or not and then to figure out who is there to ask because it it's not a person. It's sometimes a a lambda. It's sometimes something else that you have to query. That was a very big challenge. First of all first and foremost, understanding the the landscape, which is constantly changing. And then I think that the what we try to do to to face this challenge is to not leave the the SecOps team, we call them SecOps, alone in this fight. So it's not them alone to figure out everything that's changing all the time and try to keep up with with this pace. It's finding a way to bring together, also the the teams that are implementing changes to find a way to correlate changes in the environment, events that the SecOps team are seeing with engineers. And we've done a lot of stuff, to to enable that. Right? We have something I personally really like. We call the security guild. We have over a hundred engineers from around the company just sitting around every couple of weeks and discussing changes. What could not what, like, road map stuff, but rather this thing could impact. So please be aware that this might affect you. And I think those discussions, just not not necessarily super structured, already put us several steps forward to, for the security team to actually be able to expect what is coming. And the other way around was also very important. So to be able to show the tech community here at six, but also business persons, product owners, and so forth, What are the things that are creating incidents or sending bad signals to the security team and to explain to them when they need to take a step forward and help this thing work together? So we try to bring not only security to this to the cloud or only or the cloud to the security, but we try to bring them to somewhere in the middle. And that's pretty, I would say, not an easy journey, but it's it's it's paying off. It's it's a very it's paying off, very well for us. That's interesting. So when you're talking about the shift, you're talking really the fact that it's not necessarily just technology. A lot of it is people in process. And as part of the people in process, you need to get the wider team on board and also sort of shift left to shift right if I'm sort of summarizing a few of the items that, you're talking about, which is really interesting to me. And, if we then take the other side of it, which is more the technology side, which we haven't addressed as much yet. How are you really using technology to improve your incident response specifically for the clouds? And are there similar to what you said about the the meetings and the processes you've had? What are the different wins that you've had already based on technology? I think we're trying first and foremost, and I'm sure we'll get to this in a minute, reduce complexity. So whatever we can do, again, we're talking about incident response. We're not I mean, this is a the core of this thing. Right? Something happens and then how do you deal with that? When stuff happens, you have to be able to very clearly so to create clarity and to very clearly define what is happening and who is doing what and and what is what what is it even that we're talking about. And we try to leverage technology for visibility, but not only. So it's also for the communication platforms. It's also for, even the the standard forms or or or or or process that we use so that everybody knows why the next step is what what's happening now and who's doing what in this whole thing. That helps teams focus on what their part is and not to try to figure out everything again and again, sort of trying to invent the wheel, every time something happens. So reducing complexity is a it's a very big thing, for us. And the second one is, I think, we're trying again, as I said before, to bring, the context, the the the whatever expertise it is that engineers might have on a certain system to the security team so that they can perform better and they they can support this incident investigation, the the whole, process, the containment, the remediation, and so forth better. But also to try and bring and this is a little bit more difficult, to bring this security operations mindset or the security mindset to the engineers who are it's impossible not to involve them in an incident now. So they have to be somehow involved. And instead of having this, please deliver me this log, please send me this thing and so forth that you might see in some cases, it's more try sorry. The thing, I'm trying to get now. Can you help me figure out the answer to that question? This is something that requires yeah. It's processing people, but it's but it's eventually technology helps really speed things up. Thank you for that. I appreciate. So if I sum up a few of the items that I've listened to, one, visibility is always, I think everybody's goal across the sort of cloud security strategy as a as a whole. But I've also heard democratization and how do you work across the teams through technology and prioritization on top of it as well. As if I connected also to what you said before about people and process, even if there's a knowledge gap, technology and the right prioritization could potentially mind for that gap. So really interesting perspective, Itai. I really appreciate it. And we had just had David join us. So, David, would you like to quickly introduce yourself, and then I'll shoot you a question as well? If you can hear me. But if not, let's go back to discussing. We're doing incident response during this webinar, which is an accomplishment, I think. So, maybe you can recruit me to incident response after. But, you know, we've known for quite some time, and, I think your background is extremely interesting. As you yourself come from an incident response background, going into a CSIRO role at Sixt, I'd love to get your perspective, especially for other leaders in this role that don't necessarily have that experience. What are your top recommendations for leaders and for us users today pulling from your experience as well as an incident responder? And how has that sort of brought a different mindset as well as you discussed the mindset a few minutes ago? Yeah. So, I was very lucky to take part of, and not as an employee. I would say not as a company that I thought is a CISO, obviously, but I was very lucky to, take the incident responder side of of looking into incidents and and real live, big, high impact incidents. And I think they all are very different, but at the core, at the essence, they're all there there are certain things that connect all of them. And I think the bottom line of an incident is how well did the organization get out of it. So how much impact did they suffer, how much money did they lose, or potentially how much they could have saved if they were faster or better. I think one of the core pieces that connects all of the incidents that I've done in the past years, is time. The faster an organization can get the role the the ball rolling, so to get to this state where people more or less know what they're supposed to do, people know the vision, the plan, the the where this thing is going, this this this factor, the time factor to to this point of time, significantly reduces the the the impact eventually and how quickly they can recover and and get back to operations or reduce the damage. And from at least from my perspective or my experience, where organization waste the most time to get to this point is where something happens, everybody's usually motivated to jump and help. Everybody tries to do everything. Everybody has an idea. Everybody has a concept. Everybody has something, and it's very hard to to to work together. It's very hard to to define who's doing what, and there are a lot of the times efforts that actually damage the the company's, efforts to to actually get out of the incident. And the best way to not have this this mess is practice. Obviously, you can plan. You can write conference pages. You can do a lot of stuff, but eventually, you have to practice. And the way that you practice, yeah, you could run some tabletops and those things are also important, obviously. But I think organizations sometimes forget that even the they they have a lot of opportunities to to learn. So what we do at Sixt, we take even things that I don't know. We you might not consider an incident. It's nothing happened. Nothing materialized. It it it was even just an alert that was even a false positive, but it was serious enough to involve several teams. And then we take that and we say, okay. Did everybody respond in time? Did everybody play their part? How long did it take us to actually get to this point where we are looking into the data that we got it, that we that it's aligned, who's doing what? And we're definitely not perfect, but every time we have this practice and we sometimes enforce it. We're forced to have this practice. We get much better. Only good things come out of it. And I I think, at least for us, what we see is it creates a lot of innovation in the incident response area where teams come even engineering teams come from their subset and say, hey. Let's add a monitoring here so the next time something has happened, I will also do that. And often, it's not even teams that were involved in the so called incident, but it's teams that heard that something might have happened, and they also wanna be ready for if if something happens for them. So these practices, when it's real, when something really happened, there there's something tangible to to hang on to. I think organizations should really leverage those and really use them to to learn, not to only show to the board that that CISOs like to do that. Right? We like to show to the board that there is a risk, that that we pay the money or or our budgets justify themselves. Fine. We need to do that as well. But we also need to take those to our teams and see that the operating model, that everything is tight. And we learn every day, and I'm sure, like, we can just get better and better every time. Let's double click on that, actually. I'd love to hear what metrics are you using. I've also had a recent interesting conversation with, CISO's at one of the Wiz CISO events, and we've talked about metrics as well as happy metrics. So metrics that are creating motivation and metrics that are just important to report on. I'd love to hear on both ends what are metrics that you continuously monitor and what are sort of happy metrics that you use to motivate the team, but sometimes also give reassurance, to the board. So I think your KPIs are is always tricky. Right? It depends highly on how do you define an incident, for example, because if you measure time to respond, then it all starts with what is an incident. And I think it's a it's a it's a double edged sword because the more maturity you have with what you call an incident or what you would now investigate or deep dive into, the worse your KPIs would look. Because if you include more and there there's more to grasp and the investigations become more and more deep, yeah, the metrics would go down. So it's the I think the KPIs themselves, like, what was my time to respond or to contain? Yeah. But what did you contain? How deep did you investigate and so on? It's it it's a good tool to make sure you're in the right direction and not moving in the wrong direction, but it's I don't think it's a great way to really practically measure improvement. And as I said before, what we try to do, we take we call them postmortems. Every time we have something that we spent more than some minutes on to to investigate and to contain, we take those and we try to learn from that. And then we take the one or two, not not 50, not 10, not five. We take one or two things that worked that could be better, and then we check-in the next postmortem or the next time that something has happened, did we get better? Is it is it look it doesn't have to look perfect, but it has to look better. And then we try to basically take those lessons from time to time and really very strictly, very vigorously make sure that they got better. And if they didn't, we again have to investigate why and why what what did we do that didn't make it, didn't improve it. And, eventually, yeah, I think KPIs are great. It's it's nice to report green stuff or not so nice to report red stuff, but, eventually, you really have to sit down with the the security teams, with the engineering teams, and ask look each one each other in the eye and say, did we do better this time than last time or we didn't? And I think that to me is to me as a CISO that that that eventually what really matters. Thank you for that. And if, you know, we're looking six to twelve months from now, what are sort of your big blocks of strategy that you're focusing on to help strengthen your security operations for the cloud or incident response program for the cloud? So, obviously, the amount of stuff we have the volume of stuff we have to deal with is get just getting bigger and bigger. Right? There's more signals. There's more incidents. There's more threats. There's every second weekend now, it feels like there's a new problem, arising somewhere. And what we are trying to focus on now, we I think we're we we reach a certain level of maturity in in our security, operations where now we're really focusing on making it more efficient. So, yeah, you have to make sure you prioritize well. You have to make sure, the quality of the investigations are good. But now our focus is also to make sure that it's efficient. Meaning, did we how many extra, actions did we do that we didn't really have to do to close an incident? Did we do it here? Does it is our playbook really fine tune to really what is necessary to close or keep it something open or not? Because, obviously, when you look at one in per one incident, it's not a big difference. But if you multiply it by the volume that is raising, then it becomes not scalable. So unless you really, again, vigorously tune those not not not not the detections, but the the the playbooks behind them, you're bound to fail because or you have infinite budget that you can continuously, scale your your operations. But nobody has that. So, the idea is basically to make sure we are really efficient on how we are handling incidents, who we're involving. It's a very good, question from my perspective because it's every false positive that you take that the teams take care of, it's eventually money we spend. Right? Because it's, again, it's not just the security operations team with their prioritization, but it's also now, in the cloud especially, engineering teams that at this time could deliver better products to our customers, or they could get their road map, further. And we have to make sure that when they're involved, when we basically create friction to the business, which is what what happens when we involve those teams, We do it for the right reasons. Interesting. I appreciate that. And, you know, we we spoke a little bit about technology. We talked about efficiency and consistently moving up and and investigating. We're also I'm sure you're also investigating vendors and, technology for that purpose, potentially in a similar way that you're consistently doing this, with your teams. But I'd love to hear how are you evaluating solutions for the spaces. It's quite new. And, what is bringing in a technology really also make the biggest impact for your program? So, yeah, you mentioned before, right, people technology, processes. And all of them can be changed, but some of them are easier to switch, I would say. And there is a hidden thing in this triangle, which is also relates to the company's DNA, which is is hard to put in this triangle, but it's there somewhere, maybe in the middle. And for me, it's you have to, yeah, you have to make sure that it aligns with the vision and with the with the processes and and and that the people like it and and can use it. But it's also it's basically like Wiz did. Right? It helped us or it shaped how we are doing stuff. It shaped our operating model. And what we are looking for is not necessarily technologies that would shape, reshape our operating model, but it it has to fit it has to fit with either the vision or, how we operate. And, obviously, there is the back end of it. Right? The the the technology we have you have to trust it. You have to make sure that it catches the right thing right things. But these things are, I mean, to be very honest, is are very hard to really, really measure. And they change all the time. It's very hard to keep track. So what we are trying to measure is, is it not just a better detection, detects this or detect or not detects this, but it's more how does it help me get to the point where where or the vision where we are seeing or the strategy that we are having for this topic. Right? In this case, if it's cloud security operations, then how does it help us bring security operations to the cloud, connect those two things, make sure that we are efficiently involving the right teams and not wasting time because, yeah, eventually, it's it's money that we we're losing if we don't. And this thing just has to really fit in the whole or as fit as good as possible within this whole, ecosystem. So this, to us, is the very, very, first line of how we choose a vendor in in all aspects, by the way. That's interesting. And you you sort of mentioned detection as well as response. And in a sense, these are two areas that are equally important and related, but sometimes there are different technologies that help you help you for either detection or response. But I'd be curious especially for those that are ramping up their program for cloud detection and response. Do you start with detection? Do you start with response? Is it simultaneous? How would you sort of think through this process as you're starting your move to the cloud? I think you do them in you don't do this linearly. So it's and I also think it's not super linear. Right? It's it's a it's a it's a cause and and and result kind of relation. Right? It's so you have to have something that helps you respond well. And there, it's a lot of also a lot of soft stuff. It's not just the technology itself, but it's everything we discussed so far. The detection is more technical. Right? You have to be able to scale it. You have to be able to build custom things that that help you get where you want. I'm not saying that those two things are not tied, but I and it's better if they are. Obviously, it's we love to have things consolidated. We love to have things in in one platform or in in one area where things are moving more smoothly. But I but I wouldn't necessarily tie them if it's I would not force to tie them if it's if it doesn't fit. So k. Would you prioritize a technology that tries to do both when if we refer back to our technology evaluation question? I would generally say yes. Again, if it's if it's in the if it's in this I would not prioritize something that I have to give up on very core things that are that are important for us just to have it in the same platform. But, obviously, if I compare apples to apples and one of them is integrated and one is not, I would obviously choose the one that has both. So yeah. Definitely. Amazing. And you talked quite a lot on efficiency, and ensuring that your team is efficient, the program is efficient, the vendor potentially is efficient. In that sense, how would you define efficiency if we had to really look through and, if you had to advise one of the attendees here, what is efficiency to you? How would you define it? Eventually I mean, why are we doing this whole thing? Right? We wanna prevent financial impact for the business or or or reputational impact, but eventually it comes down to money. Right? Imagine we are involving for every small incident five engineering teams. By design, we spend, I don't know, €5,000 per incident. So one of the the metrics as we look at is, did we really need to involve did we really need to involve more teams for that? Could we automate it? Could we get this information otherwise? Why did we need to involve them in the first place? If it's for to grab a log, why is it because we didn't have the access? So let's make sure we have the access and also preplan how we get it, next. So long answer to a short to to a short question. Eventually, it's how much money? How much what was the cost of of containing an incident? That that that that is it for us. How do you measure it? Yeah. It's complicated. I don't have a a silver bullet for that to answer actually do that. But I think we have a pretty good idea when it's getting better or when it it it it's getting worse. And I we're getting better, but, when we, yeah, when we overspend on something, I think we teams know it. Fair enough. And the last question from the audience before we wrap up, How engages your incident response team with cloud platform engineering teams? Are they seen as contributors to your security outcomes and enhancing your incident response, or enhancing your responses to incident events and response activities? Beautiful question. I think it really depends on the maturity and where we are today. Eventually, unless you are a % sure that an incident is contained within the cloud, which normally you cannot do within the the first, I don't know, several hours of of an incident if it's real. I don't see how you cannot not involve the the both teams. Right? The the the the cloud engineers, the the the engineers themselves, the the security operating teams, and so on. And that that's why when we build playbooks today, they are completely connected. So it's the playbook starts there's one conference page, but or whatever it is that where we documented it. And the incident start could start with the security operation teams and then transfer to a to a task to the cloud engineering team or vice versa. So there could be something it could be even a vulnerability, right, that popped up at WIS. It's a ticket somewhere in somebody's Jira. But if it's critical, if it's touching the crown jewel, if it's whatever, there's some criteria where it automatically goes to the security operating team because there are other actions that we have to take to make sure it is contained and nothing happened, is a precaution. So for us, it's it's it's not contributor or who's leading what. It's it's really integrated. We don't see a a difference. So we we're more mostly focusing on and where it happens, we we're mostly focusing on breaking those silos rather than defining who's doing what. For us, it works. Thank you, Itai. Some of the main takeaways I think that I've taken from the conversation with you is if you're looking for incident response in the cloud, you also have to shift left to shift right and not silo everything so that you have a security team that is able to work continuously from end to end, in the cloud specifically. And I found that really enlightening, as well as looking for any efficiency metrics and constantly checking even for the smallest alerts as you would call them so that you can always create best practices and to be able to sort of be preventative and preemptive based on anything small happening. So when something major happens, you're more ready and that, efficiency is also and productivity is, people and process focus and not necessarily just technology. So these are some of the takeaways I've taken. I'd love to hear any last words from you, Itai, as well. I first of all, thank you. It was a great thirty minute discussion. I think eventually it comes down to and I cannot stress it more. Right? After doing seeing so many incidents, out there, take the opportunities that you have to practice and really even if it's the smallest screw that is not tight, tighten it. Because when something happens, did this loose screw is where things are really gonna make the difference whether you successfully manage something or had a terrible worst case scenario outcome. And, yeah, whoever listens to us today, I I hope they take it with them because I think it can really, really change results of of an incident. Thank you, Itai. I really, really appreciate your time, and thank you everybody that joined us. Looking forward to the next session. Thanks so much. Everybody. Bye bye.