Panel – Practical Tips for Cloud Incident Response

Hi, good morning. Welcome to this session. We're going to be talking about Cloud incident response.

My name is chancy Wang. I'm the founder and general partner of rain capital. I also sit on a Fortune 500 public board and looking at digital transformation initiatives.

I'm very happy to be running the session today talking about an issue that is very interesting and near and dear to my heart. I've been looking at the issue of cloud into the response for several years now and very happy to have my friends and also experts in this area join me today and I'll start with intros read and then offer and then David so we take it away. High Chancey hi everybody.

My name is Reed Kaur and I am coming with 20 years of experience in it and information security in Fortune 100 to 500 companies prior to my current role as a chief information security officer at one of the largest high-red institutes in Oregon, and I have seen the move from on-prem to the cloud and the challenges which we are dealing with so, this is a perfect topic to discuss one. Thank you read over coming from Tel Aviv. Here chancing always great to be in a panel with you.

So my name is offer more. I'm the CTO and co-founder of mitiga a company focused on cloudir Technologies and initiatives. I've been in the security space for over 25 years A lot of it in appsec which relates closely to Cloud these days.

So I've seen pretty much everything in a lot of incidents. So happy to talk about it. and David Well, it's great to join everybody with the over and reaches, you know, been interacting over the past, you know a couple of years here.

And so I'm the senior vice president and CSO for Oracle SAS cloud and most interestingly I think the past 10 years, right? We think about instant responses that I was over the head of msrc and back of the Microsoft, you know days then in the Google Cloud security, you know organization and now here in the Oracle SAS, so I think the very exciting and interesting topic to to go over today. Yes, and I feel like we've been talking about Cloud forever.

I remember back in the Forester days for me in 2010. We were talking about weather Cloud would be here to stay and fast forward what 12 years of course cloud is here to stay and it has become mainstream. I think folks don't ask the question anymore about should we go to the cloud the question is how do we go to the cloud?

And how do we manage things in the cloud? So that's certainly a big change, but now that we have Many of our Assets in the cloud and applications in the cloud the question is how do we make it more effective? And how do we really control?

Everything that is happening in the cloud without owning assets, right? So that's the big question and so today certainly there's a wife worth of topic. About Cloud security.

But today we're going to focus on into the response and the reason incident responses. Interesting is I've heard of many practitioners including some of you who told me that boy when I moved my infrastructure to the cloud into the response is different. So when I have my sin on premises, I do I run a queries and it can finish in like two minutes and and when I run it on cloud trail, it took hours sometimes would be days to do anything and the data formats different the the way I do analysis is different.

So it's a whole new world if you will so I'm gonna start with read you are see so of a high-end institution and I would assume that you guys don't own a lot of your infrastructure, right? You probably Cloud heavy and and tell us a little bit about you know, what you do in the cloud. And also how you think about Cloud IR at a high level.

Yeah. So our journey to the clouds, you know, two and a half years ago when I This role just two days into my job. We got hit with Kobe and you know Portland Community College that is where I work right now and they were heavily on Prem shop and to do that lift and shift because prior to coming here.

I was at Nike where we had a five-year program to do that lift and Chef to migrate everything to the cloud and over here. We had to do it within five weeks and we did not even have the right resources as we are already dealing with the talent Gap in security. Just imagine the talent Gap in Security in Cloud security.

So it has been such a challenge for us. So we migrated over there and you know, some of the team started saying that hey we are just doing this testing and QA and that was the learning for us where you know you is you know in love there is no concept of QA versus Dev versus Broad. Need to secure all of these environments equally.

So that was the biggest challenge which we dealt with where we had to send everybody for training right off the bats. So right now we are making sure that we are fully trained before we do that full lift and shift over there. So I would say that, you know, we have a few things.

We are not fully in Cloud. We are not Cloud heavy yet, but we are trying to be there. So we are using a lot of SAS products a lot of platform as a service as well.

But we are also thinking about how we can you use infrastructure as a court because when we talk about code up in the cloud There can be a lot of vulnerabilities in there and we don't have that many resources at an education system level. So we are trying to see how we can partner with vendors in that space. Right, and I know that Portland Community College is actually a huge institution.

You've got many many students. So I would imagine there the environment is probably fairly diverse and you've got different applications you have to contend with so and doing this lifting a shift and left into into the cloud is not no small fee. So I'm gonna go to David you have been in Cloud environments for a long time right you you worked at probably the largest cloud providers in the world in Your Capacity today and and in the past so putting on your technologist hat on not just for your SAS Cloud others, but putting on the industry had.

Seen in terms of practices different in practices when people have moved their infrastructure to the cloud in terms of the way. They view IR in terms of a process procedures and in Technologies just high level. Yeah.

I actually think one of the more interesting elements here is it's a lack of maybe understanding or thinking about it right is that when a customer has, you know, it's their data center. It's their you know, I would say their Club but their data center their operations, they have access and can touch everything and then when they move to the cloud whether it's infrastructure as a service or SAS as a service it understanding of that what are their responsibilities what controls are in place what logs are available to them and often we know it is a difference, but I think I think one of the challenges in the industry is that we really don't have a great guidelines of what everyone should expect what everyone should look for in what everyone should do in managing? Environments from an IR perspective and I think this is sometimes when they need some help right in that because sometimes they're very mature themselves and sometimes it's a new experience and as they do that transition.

This is sometimes with a gaps occur. That's not necessarily always easily provided naturally from a cloud provider. Right and and IR is all about data, right?

So you need data to extracting formation and using the information to make decisions. And I know several come companies have built their IR process fairly processes fairly mature processes for on-prem infrastructure, but when they move to the cloud these processes no longer work or at least they need to be adapted. So hence and that's one challenge secondly hiring people who know how cloud data works and how Cloud info structure works is no fairly difficult today so over you are you've been in security for a long time not necessarily in Cloud security, but now you are really spending and day and night thinking about how security and how infrastructure how incident months tell us Why incidents response in the cloud is an interesting challenge for you?

So I think I think you know some people like to see Cloud as you know, just just another bigger data center, but it's really a whole paradigm shift and so incidents incident response in the cloud just first of all interesting because incidents in the cloud are different, right and of course, we still see in the cloud compromise of ec2 machines. It's just like a compromise on a server but we see a lot of other attacks that you would never see in on-prem environment, right this interconnectivity of cloud infrastructure the fact there's you know, no perimeter or identities the new perimeter depending how you want to look at it. So first of all, the incidents are different and we also see a lot more sass which is really application Level attacks that in the past even though I've spent most of my career and apps like we didn't see as many incidents when we did they were happy, but we didn't see as many because each application is different but now is sass, you know, there's an application that serves thousands or tens of thousands of organizations.

So on one hand, the incidents are different and and the people who are used to dealing with they are and a really good at it the on-prem, irr. They're really good at Host type of incidents, right? There's gonna be some fishing now, we're get entry to a host get to active directory, you know, 90% of the on-prem stuff is around that cloud is very different.

And then as you've already mentioned in and David's already mentioned. The infrastructure is different. Right?

So the logs are different you need to understand what you're doing. It's a whole new challenge and then on top of everything, there's so much stuff that's not accessible or just tools that are not there yet. So if I go today to an on-prem incident where the customer had no sin.

And no logs. I can still get a lot of data from the machines. Right?

We own the machines customer owns the machine and I can extract data in the cloud. I'm totally dependent on what the cloud provider gives me and what they store for me and by default most providers will keep 90 days sometimes up to 180. It's older than that and you didn't do anything up front.

You're blind if zero capabilities. but you have you have Trouble, right? In in many environments you can do that.

However, as we discussed preparing for this this panel, it's actually not easy for folks to know what events to log so tell us a little bit about, you know, maybe given the example of why knowing how to configure those logs that super important. Yeah, so this is a great point. Right?

So we go to customers whenever we talk to customers. Do you collect Cloud trip? The answer is almost always.

Yes. So then but Cloud crew is just an infrastructure for wild collection, right? It's not actual logs.

And then you start diving into this. So one customer doesn't collect the management blogs, which is really what you need for big chunk of forensics investigation and then another wouldn't collect RDS blogs. They're not turn on by default.

If you start a new AWS account ideas logs are turn on my default. Um, and then some customer will be probably telling me their collecting VPC long right probably because they're big and expensive but the default scheme of VPC logs is not designed for security. It's designed for performance network monitoring a lot of good stuff that has nothing to do is with security forensics.

And so all of this, I mean even those who collect the data don't necessarily collect it, right? But on top of that if they collected in cloud trail and they don't extract it. And the retention is limited.

You can't control the retention. There's another great example with with Office 365. So Office 365 is really good logs and it has an API for you to extract.

So if you extract them regularly, you're good. If you don't the retention is 90 days, but anything older than seven days is no longer accessible through the API only through this Powershell that's throttled and limited and was larger customers. It would take longer than 10 minutes to extract 10 minutes worth of logs.

And that's why I think it is very important for us to figure out what are we logging? Like, you know, we need to configure our logs to make sure that we are logging the right thing. Right?

So when we talk about indicators of misconfigurations or indicators of attacks or indicators of compromise are like, you know, what kind of logs will help us drive these different parameters. I think that is the key Point here. I'm just sorry, go ahead.

It's just one more thing. I think I think there's a difference between what we're used to log from the Sim days, which is mostly around security alerts versus forensics data and I'll give it again an example from from Office 365 right that that security alerts will give me things like I use your logged in or or Warnings from from email content filtering, but you won't give me enough data to completely investigate all the emails that a certain user got this I can get from something called the mail flow logs, but nobody would collect them as a security tool by default and again in the old days when the machines are ours, we would extract that forensics from files from mailboxes from things like that. But that's not available in the cloud in that way.

Yeah, I can resist you jumping in now. I think this is where we're all getting excited because I think we've hit on a point here that I think as is a over you've kind of highlighted and you you build upon is there's many elements in exactly of the cloud in the various layers. There's different logs and players and for different purposes.

Right and I think they're awareness of the customer knowing what logs are accessible to them. And what logs should they be pulling down are they fully aware of that? Do they need help with that?

Because it's part of you know, the shared responsibility. So I think that them understanding the various elements of this and where they want to, you know, pull and collect and retain these because if you think of an investigation, it's not just what's in the scene it me all of the elements and end is like what you may have you may have the host logs. But what about the application logs?

What about your identity provider? Right? Do you have those logs because your daddy provider may not be the same as in your Cloud application and I think this is A very important point that very few people understand I think as they did the initial lift and shift into the cloud.

So to build on what you just said David I Am says that you know, we've been In This Cloud Journey for and maybe good part of 20 years now. Um, I'm surprised of that large crowd providers. Don't just publish Play Books, right?

So if you are this profile of customers here the things you should log and maybe there are a few knobs you can you can turn here and there but largely you just take it and go I'm such things exist. No, But I think this builds up the question of and I love to hear from from everyone else is well is that we're all multi-cloud multi-application, right? And how do you have a Playbook, you know as an individual vendor for a multi-cloud scenario and I think that may be one of the challenges is that you may be and your application may be from cloud a but your Denny prouder provider is Cloud B, right and who builds a who builds playbooks across all of the cloud providers when they're working together?

Yeah, and do your point David? I think the taxonomy is completely different in these environments, right? So, how do we make it consistent?

Like, you know, how do we unify that so that somebody who is working in IR they can work in all these different environments if they are working in ec2 instance in AWS. They understand what to look for in Google cloud and what to look for it as you I think that you know, something unified is you know up for us here. Yeah, it's harder right?

So I'm sorry for just like now you need someone who understands how to pull logs from this Cloud that cloud Hunter put them together analyze it. I mean just to hire folks. Understanding One Cloud is hard enough.

That's even harder right? So, um, sorry. Oh, sorry.

I'm sure you say that customer environments a lot. Right? Yeah.

Most of our customers are multi-cloud and we're actually as part of what we're building work. We're trying to build this. Let's call it obfuscation layer of the different clouds, but it's it's not just the taxonomy of of logs, right that is different.

It's the art cloud architecture itself, you know gcp and AWS may be closer. Azure is very different in a lot of it's Core Concepts. So it makes it quite difficult to just, you know, take the same logic and run it on different on different clouds.

And I think that's that's part of the challenge. I also think you know going back to what you asked on the cloud vendors even for for a single and of course David, you're right with multicolas more complicated, but I think we see a challenge of getting this information from cloud vendors. And I'm not sure if it's partly because it doesn't communicate well with the message they're trying to convey about Cloud security and telling people they have to turn on a lot of logs as best practice means it's more expensive and it may not be the message they want to say but also these Cloud vendors are running so fast, they create new features and new capabilities that even their own best practices security, you know, the people who write best practices security for them aren't able to keep up.

We see new Services coming from AWS and the security recommendations for them coming six months later, right? So yeah, that's interesting. I mean Cloud, you know David to your point earlier you said cloud is a share responsibility model sure it is but you know things moving so fast and what else our first said.

Um, how do we make sure the customers have the capability to hold up there and of the share responsibility when there's no good guidance, there's no you know available and you talent to make it work and it's it's a big pile of a complexity really and so, how do you I mean read? How do you even know think about solving this problem? Yeah, so one thing is, you know earlier when you talked about that.

This is a shared responsibility model. What I think is that at the end of the day it is still that organization's rest, right like because already dies in there and it is our risk. So one thing which we have done.

Is that okay? How do we play with maybe we can create a hybrid model that like, you know our teams while the while we are making sure that we have the right resources, but we do need this help. So, you know, we are thinking about partnering with the vendor who understands all these different environments who can get all that data who knows how to perform Intelligence on and analyze the data.

So we are partnering with a third party vendor to do this for us, but on top of that I would also That we have to also think about because you know breaches are going to happen, right? So at that time when we are dealing with a breach we do want to make sure even if we have in-house incident response capability in Cloud, we do want to have incident response retainer so that because at that time we do need an independent vendor to come in we want to make sure that all that process is already up and ready to go and we are not scrambling it that time from you know, contract perspective that or contractors, you know, getting up and ready from procurement point of view. We should already be ready to go.

Yeah, that's it. That's a good point. I mean that's a so the process point of view but that's really important.

Right? So, um for those of us who on the practitioner side, I have half of my foot in a practitioner's camp. We always want to make sure we have things ready to go and that's part of a cloud incident Readiness if you will, right?

So if you don't have a vendor already selected, when was you hit by incident and trying to do the contract process forget it right and also things like how do you even select the right right help at that point? So I would like to add one thing to do that. I know so think about solar winds or log 4G right?

It's not just you who are who is dealing with that problem. There are so many different organizations who are dealing with that same problem at the same time. So you want to make sure that you have Leave bought with these teams so that you can get that help right off the bat.

Want to add on that read? I think the contractual side is extremely important. Of course, like you said you need the SLA and you need the contract in place.

I think also the technical Readiness is important. When when you're in a mess just even the basic things like getting people access to the system having the team know how to interact with the data assuming you have it getting heavy having the right date. Of course, all of these things are the difference between being able to respond to it into it within hours or a day to days and weeks and months.

And and we see that right when when I are companies are called in just based on a contract but there was no real Readiness done. It takes three four days just to get started just to get through the technical hurdles. So so getting this in place is gonna make a huge difference in your next incident and yeah, just go.

Sorry. Go ahead. And is that you?

And to your points over I think sometimes leaders think that okay, if I have zero dollar retainer, I am good to go. But that's not true. You know, you need to have that proper preparedness in you know, you want to make sure that it's a partnership you want to make sure that that I are retainer has all the information they are monitoring your data.

They have full visibility to it so that they can jump right on it when you have a reach kind of situation because if you are waiting for two or four days for them to get ready at that time by then it is too late. Yeah, absolutely. So which is you know, one of the things I really like what over and his colleagues are doing a mediga.

I remember a few years ago. I was talking to a ciso and he was asking me he said who's doing Cloud IR? And I was like, oh, so I hadn't thought about that.

Particular set back then and I was like, well, I see your point that traditional I are may not work in the cloud, but I don't know anyone who's focused on the car, ir and he was saying, you know, this is coming. Somebody has to be specialized in Cloud IR because they were running IR, um, no by their own teams and and he was saying it's so different in the cloud versus and that was several years ago, and that was my first so the Came into contact with this concept. and it was again all the points that we've discussed and then he said look, it's I was trying to build a forensics data Lake.

And they've got you know, they're the internal sin and then they've got their cloud data and and he was like, okay. I'm I'm gonna try to pull cloud data into the Sim so built the centralized data lake so I can do forensics later if I need it. and He asked his Sim vendor how much will cost to to pour that cloud data and yet one from somewhere to from like 70k a year he paid for his Sim to 380k a year.

And he's like, whoa, you know, wait. Wait, hold on a second. I'm not sure I want to build this data lake.

So question about what you log what data to pull and where to put them the data are all questions of people don't really know. So this is this is a building on the point of technical Readiness, right? How do we achieve the technical Readiness of out configuring our Cloud infrastructure so that if incidents happen they do happen that things are ready to go.

I have the funder in place. I have the data in place and then they can hit the ground running. What are the top one to three things you have to do to prepare your infrastructure for readiness.

I want to start just before your question was one one comment on on Sim and data Lake I think part of the challenge you you've described which we've seen when we came. This space is that Sims are really not designed to be a forensic data Lake. They're designed to be an aggregation of alerts and and logs that are used for alerting not for forensics and and they're great at it.

They have a very highly indexed data structure that allows very quick queries very interactive into work with the data, but because of that when you try to pull a lot more data, which is what you need for forensics is it's becoming difficult. And so it brings me to your to your question. The first thing is to realize that you're probably not going to be able to use your sim.

As your data Lake but you need to build a different data Lake for forensics data. And and yes, sometimes you're gonna have to to stream some of this data in parallel because you still want the alerts going to your sim, but more of that your data like I just met with with a company that spends over a million dollar a year on their Sim because they're streaming so much data into their Enter the data Lake and and that's a very big cost and so building a data Lake either on your own or right by using a vendor that can help you with that is is the first step and then the second step as we mentioned is mapping. The main resources that you have and collecting their data and I think one thing we see a lot of people Miss is is reference to SAS.

So everybody will collect, you know, cloudtrail logs and maybe VPC flow logs and all their AWS stuff. But then you start looking into things like Salesforce and slack and in these have a lot of sensitive data in them and people don't collect or even if they collect they have no idea what to do with the laws. What's their structure what's in them?

And we've seen that in the OCTA breach. The optim reach came directly eventually wasn't too bad. But people were trying to figure out how do I know if I was breach and people wanted I don't even know where my Optical logs are alone what their structure is so getting that in place is super critical.

This is a perfect point to to ask David. So since you are deeply in the SAS security World these days when we've been talking a lot about infrastructure as security infrastructure as service log collection and security. So coming to SAS.

Now we use ass. all the time slag l365 all these applications are very critical to our business Core Business utility. Yeah, we we don't treat it.

Maybe we're not treating it exactly the same as as other infrastructure. Tell us a little bit about how your how you coach your customers thinking about sass incident response and incident data collection. Think two points.

I'm gonna go back to one an element as I think we've been talking about is but you say you choose a given cloud provider and you have is service has services and SAS Services. Well, each of those actually for instant response and logging they're actually all different even though it may be the same cloud provider right that each assass has one process versus is an expectations for support. It's response.

And I think that's an element in coming back as sometimes you need to be proactive and understanding do you have the capability because your level of support and incident response could coming from the cloud provider could be different and is likely different between all those three, you know in itself. So another element I think is King asking a responding to your question in element is you need to understand is what is the incident response process for, you know, a given SAS provider because they're also probably very different even within the provider for isss or between SAS providers is is it through a email system? Is it through a support system?

Is there a different tool and understanding that and I think many are many customers don't understand. What is that process even though maybe published they don't understand it. They don't know how to use it.

And when something does occur then they get confused they get frustrated. They may not be able to respond quickly because they're not aware and having practice using that process. And so I think that's one of the key point for the industry that I think we're all trying to to help with in most customers need help because they can't necessarily do it themselves.

The one person who may have access to that process to perform an incident or ever request. Assistance maybe on vacation and they're the only person so how are they going to respond to that? No pun intended.

Nope, High intended. Yes and reach anything bad here. Yeah, I just Found thing is that sometimes I feel that these resources who are working on over these vendors.

So for example Microsoft, right initially when I took this role when we were trying to deploy MFA we were working with this vendor where there were some integration challenges and they have all this open documentation and our teams were trying to digest that documentation. And you know, I really think that we should buy that level of service from these different vendors to make sure that we have proper help from them during these different challenges that we deal with not just incident response. But also when we are building or infrastructure as well, so that is another thing.

I think this is very important for the leaders because you know, we had to actually buy and extra service from one of the vendors we are working with so Ultra, you know, even if you know, we don't have the full knowledge, we do the partnership with this vendor so that we can build it together. They can provide us the right resources. Right, I think.

You know, it's not it's it's not tenable for every company to build up all the expertise for managing Cloud incidents and Cloud security. Right? So, you know, certainly you are in high-end and it's not your core business and many companies that I know their Core Business is not Security even though you need to have Some core talents, but some of the the tasks initiatives are probably best left for experts that who can do this really well and which is you know, part of what that shared responsibility model is about.

for him I think that as Leaders we want to make sure that we provide the right tools to our teams to be successful. So we need to ask for that help from or executive leadership to do that these Partnerships with these third-party Windows who are experts in this space, you know, if we are lacking that experience then you know, we can partner with a third party vendor to do that. And and I want to I want to end up just one thing and that that the breadth of capabilities and knowledge that's needed is just immense you go to a larger organization.

They will have all three or more main Cloud providers and over a hundred SAS vendors. And each of them has a different process of different at risk a different type of logs and and so on and and to make things even worse a lot of the staff vendors would charge extra to give you things that I I consider as basic like security laws. Because that's part of their pricing model.

And so you may not always have even the ability to to deal with that incident unless you partner upfront and make sure that that you have yeah, I'm so certainly there's you know, we talked about technology challenges is there's business model challenges and and there's cost that is a lot of folks don't actually understand forensics in the cloud. What they implication of cost is I've seen some interesting new startups that the kind of hitting that area which I thought was quite a different view on things because if you don't peel the onion to see what the core cost is you might be surprised at your your, you know, Cloud Bill to be honest and then you get you get this internal fight. I've seen people saying oh, this is not it spend the security spend and who's gonna pay for the bill, right?

I want to know what thing in the cloud that was interesting to me coming from my background. I worked quite a few years and Davis involved to in the sort of a container Operational world where our resources are very ephemeral, right? So you've got a containers may be running for a few hours and they come and they go they may be running very critical applications, but they don't stick around that long and how do you deal with a femoral resources where maybe later you would need to look back on some of the aspect of the event to detect incidents and and respond to incidents and what are some of the the do's and don'ts for the for those resources?

So I think the main challenge was was this is balancing. You know having as much forensics as you'd want which basically keeping a snapshot of every part or every instance before it goes away which which of course is unreasonable. There's just getting enough forensics data.

And so at the core that there are two things that that are really important one is to get it at least the minimal viable forensic data out of each machine before it disappeared or resource before it disappears, right so drive away your sislog or or any other law outside of your kubernetes before he dies, but also log the interactions and that you can get from the infrastructure from from the kubernetes infrastructure the interactions between the different containers and pods and clusters and by combining the two you can get a pretty good understanding without having all those snapshots. And by the way, this is true not just for for containers, of course. Okay, there's big we see more and more customers that even you know spin out and kill out easy to machines on a daily basis as as part of modern cicd.

Garmented infrastructure is code. And so again the same if you spin a new ec2 machine every day in the race the old one you have to make sure that you have access to at least some forensic data. Yeah, we are actually five minutes away from our time limit and and I want to maybe just switch gear to ask each of the panelists to have a so one last word.

You want our audience to take away in terms of cloud incident response. I'll start with you David. I would say it's about it's about planning.

It's about proactive. It's about you know, understanding and building that plan in advance before you need it. Don't be reactive and and going in and how you figure out how you're going to solve it after the fact but assume that something will occur in the future and how you plan it with your Cloud providers and with your partners and in other companies, you know, like mitiga and to be ready for that.

Yeah, I think that the again hitting on this point that I realized a few years ago that cloud incident response is really about incident Readiness and and read. Yeah, I agree. And I really liked when David said that you know being making sure that we are planning and we are being proactive.

I really think that when we talk about proactiveness we want to make sure that our employees are fully trained and we if we don't have the right set of employees we should not be shy away from asking from help and then like, you know Outsourcing that particular portion of incident response to a third party who is highly skilled in that area one. Another thing I would like to say is that we also need to start thinking about you know, how are we making sure that what we are implementing in the cloud we want to make sure that we have the proper Frameworks. So for example, might or attack they came up with the cloud framework recently.

We want to make sure that we are using those Frameworks to build a proper secured infrast. actual Right. That's that's a great point Thank you.

Thank you for mentioning that oh fur you have the last word. I really like what you guys your team is doing at mediga. And I think it it builds a lot in terms of cloud incident response expertise for the industry.

So, um take away last word. Yeah. Thank you.

I think I think building on top of what you and Reacher said I think on top of the technical Readiness the forensics which we all understand is crucial. This skills Gap is just enormous and as the cloud is continuously evolving. I think it's it's going to be impossible for most of the organizations to have all the knowledge internally.

So, you know finding the right partner building the right Technologies doing the Readiness and and relying on support when incidents occur is all you know, all we're gonna see in this space in the next few years. Yeah, so I think we're gonna see more reaches at the scale of objective and and hopefully not solar winds, but we'll see, but thank you so much for joining me this morning, and I really thoroughly enjoy the conversation. Hopefully we can do more in the future.

So, thank you. Thanks.