Cloud Detection and Response

"We are not really seeing as many attacks in the cloud where people hack in. It's more likely that they simply log in."

In this episode of the mnemonic security podcast, we're exploring Cloud Detection & Response (CDR) together with Brian Contos; returning guest, fellow podcast host, author, and serial security entrepreneur. In his conversation with Robby, he shares from his new role as Field CISO for the Cloud Detection & Response platform Mitiga.

They discuss the Salesforce supply chain attack and the challenges of protecting interconnected cloud ecosystems, the evolution of Cloud Detection & Response so far, and what we should expect in the near future.

Transcript

Speaker 0:03

From our headquarters in Oslo, Norway, and on behalf of our host, Robby Peralta, welcome to the mnemonic security podcast.

Robby Peralta 0:15

When endpoints mattered most and malware was the problem, EDR was the answer. Then attacks evolved, and context mattered more, and that's how we got to XDR. Network traffic, authentication logs, the whole story. Then the cloud happened. Identity became the attack surface. SaaS became the infrastructure. And we responded by inventing a lot of new categories. Posture management, workload protection, titlement management, cloud access security brokers. Useful tools, mostly preventative. And they didn't help much when attackers started using legitimate access in real time. The Salesforce OAuth attacks were the wake-up call. Or compromising one trusted SaaS integration meant walking straight into customer environments. And suddenly incident response looked very different. No servers to image, no tenants to seize, just logs. Fragmented, throttled, and incomplete. A walk down memory lane, or an attempt to figure out whether CDR is real or just another marketing term. I'll let you decide. Brian Contos, welcome back to the podcast.

Brian Contos 1:42

Robby, it's a pleasure as always. And uh your new uh your new office digs are looking great.

Robby Peralta 1:48

Thank you. Thank you. Likewise. Do you miss the pillars? I feel like you had pillars in your old house.

Brian Contos 1:54

Yeah, you know, uh now I'm going pillarless. I never thought I I would, but uh no, yeah, I'm pretty happy. Pretty happy with the new location.

Robby Peralta 2:03

I saw on LinkedIn that you are now a field CISO for a company called Mitiga.

Brian Contos 2:08

Yep.

Robby Peralta 2:08

And as tradition goes, every time you start off in a new role, I know I have to have you back on because that means that you've found a new part of security that reserves more focus. And this time it's uh cloud detection and response or CDR.

Brian Contos 2:24

So tell us about that. I always try to do something a little bit different in the space. We've talked about a lot of things on your podcast over the years. And I always like to pause and reflect and talk to industry leaders and big thinkers and CISOs and see, you know, what's what's important to you right now? And it wasn't even a close call. Everyone was talking about cloud. I'm like, duh, right? With the whole idea, well, as we're moving to the cloud, well, we've moved. Everyone's there, every everyone's in the cloud. And there's this big transformation happening in security in terms of, well, how do we address cloud? But what makes the cloud powerful? What makes the cloud powerful is the fact that you've got all this interconnected tissue, right? You've got this SaaS application talks to that SaaS application, that SaaS application from a third party provider and fourth party and fifth party. And you've got your identity controls mapping across. I mean, you've got one or multiple, probably multiple cloud infrastructures. You you've got this hodgepodge, whatever it is, you've got this big sort of melting pot. And that's great. That adds you so much power, so much flexibility, so much scalability, time to market, et cetera, et cetera, et cetera. But what it also does is it means there's a lot of things within your environment that you don't have any control over. You don't have any visibility into. Heck, you might not even know that they're part of your chain because you're doing business with X and X is doing business with Y, you know that part, but you don't know Y is doing business with Z in order to add this capability that ultimately you get. So from just the fundamental perspective of I need this panoramic awareness, if you will, right? Into my infrastructure controls, my identity controls, and all of my gazillion SaaS applications, that becomes a huge, huge deal because no one's looking at that. And CDR said, hey, instead of just looking at SaaS, instead of just looking at AWS or Azure or GCP, whichever one it is, instead of just looking at identity controls, look at everything in its entirety. If you if somebody comes up to me and they say, Yeah, Brian, we're doing logging in the cloud AWS logs, I know right off the bat, they're not really sure what they're saying. Because within AWS, there's hundreds of different things that you can log. And each one of those things you can turn on different levels. So there's Cloud Trail, most people know about that. But there's VPC flow logs, there's Elastic Kubernetes, there are uh Route 53, which exists what Amazon calls DNS logs, port 53 DNS. There's S3 access logs, there's EC2, Lambda, containers, databases, then there's all your security controls on top for workloads like CrowdStrike, and the list goes on and on. You have so many different things that you can log. And in addition to the logs, you have the alerts from the CrowdStrike's and the other solutions like that. Just trying to get that all from AWS and get it tuned and get the proper amount of data, that's that can be really problematic for most organizations. For the fundamental truth, that most security people aren't cloud people and most cloud people aren't security people. There's a dichotomy between those groups. There's very few people that specialize in cloud security. And if they do, it's usually one area AWS or GCP or Azure or something like that. Very few work across all of the platforms, all the identity controls, and certainly not all of the SaaS applications. So CDR, to a very simplified point, is being able to look across all of those disparate sources, correlate all that information in real time, and then act upon it for rapid detection and response to uh potentially nefarious activity that's seen.

Robby Peralta 6:06

So AWS, Azure, Google, these are all things that you connect to just out of the box, sort of all the big infrastructure players, right?

Brian Contos 6:15

And then all the identity pieces, and then all the SaaS applications. Because if you think about, like, as you know, I sort of cut my teeth in the industry helping to build Arc site. We were one of the first sim players out there. And this whole notion that you'd have this thing, which was a database, and you're gonna pull in syslog and syslog next generation and checkpoint opsec and SNMP and SNMP version three, and all this information from firewalls and IDS and later IPS and VPN and routers and switches and endpoints, the list goes on and on and on and correlate that. Well, in the early days, people are like, Well, why the heck do we would we ever want to do that? And it's gonna be a lot of data, and they're right, it was a lot of data. In the cloud, it's so much more. There's so much more data. So if you have that old mindset of saying we're gonna take all that data and we're gonna take it out of the cloud and stick it someplace and analyze it, well, you're gonna make the sim vendors really happy because you're gonna be spending so much money on storage. Because we suggest three years of storage for forensic analysis. Also, you're gonna pay egress fees because all that data now leaving your cloud isn't free. So the way we approach it at MIDIGA, not here to pitch MIDIGA, but just CDRs in general, the way we approach it is we don't charge people based on storage. So we say turn on the fire hose. We want all the data because you really want all that data to be able to find the minutia of the malicious activities. Because honestly, in cloud, it's not so much people hacking in as it is people logging in. And because of that, a lot of traditional approaches to security don't really operate as efficiently and effectively because of that mindset. So we've sort of changed it around in our approach. So, anyways, that's a long way of saying there's a ton of volume, velocity, and variety in the cloud. And we built a solution in order to address that and embrace those differences as opposed to fighting them and saying, no, we're gonna egress all the data, we're gonna shove it into a sim and we're gonna analyze it that way. It just doesn't work. It just doesn't work at all.

Robby Peralta 8:16

Am I sort of oversimplifying to think that this is just the if you want to be doing security like SIEM, right? If you want to be doing that in a modern environment, you need to have something like this, or else your your SOC has to be going and making their own detection rules and all these different log sources like that. That is, is that even possible to be doing that by yourself?

Brian Contos 8:36

It's so hard to do it by yourself. Back to my initial statement about cloud people aren't necessarily security people and vice versa. There's a small, if you have a Venn diagram, there's a very small sliver where those folks overlap for some part of the cloud. But the truth of the matter is these people generally don't exist within your organization, or it's a very small percentage that do. So trying to build your own detections, is it possible? Of course it's possible. Is it probable? No, it's gonna be very, very limited. Just the reach, just the SaaS applications. I mean, yeah, we've got GitHub and GitLab and Salesforce and Workday and this and that. But once you get past the first 20, then you realize there's another 2,000 that marketing has or HR has or the engineering has that you've never even heard of these things, but they have sensitive data. They're connected to all your devices, and you're supposed to build detections on all that and and take this thread and this needle to connect all the identity and all that together. That's not gonna happen.

Robby Peralta 9:32

For a customer to go do individual detections on all those different SaaS apps. That just sounds all right. Yeah. Touched on that SaaS world for me.

Brian Contos 9:42

Yeah. Well, here's a good example. And there's a million of these, unfortunately. But uh everybody uses GitLab or GitHub. So nothing against those products. They're great products, and because they're used so heavily, people attack them, right? So we'll see somebody attack an instance of we'll we'll just say GitLab, whatever. And through that, maybe they get some secrets, maybe some API keys, maybe some tokens, maybe some passwords, who knows? But they get some secrets from that system. And through that, because of that, they're able to get through that organization's authentication solution. Maybe it's Okta or Ping, you know, but they get through that authentication system. Well, now they're in Slack. And maybe you don't have Slack Enterprise, you just have regular Slack in your organization because you're a bit of a smaller company. Well, guess what? Then you don't get logs. There's all these little isms. And then from there, maybe they move into Microsoft 365. So you got your whole office suite and all these productivity tools, which is great. Everybody uses something like that, a Google Workspace or Office 365. Well, let's just take Office 365, for example. By default, the amount of data that's stored for you, the log data for Office 365, is about a week of data. Okay. We suggest three years. They give you about seven days. So you get about a week of data. Now, technically, you can go back and get like 90 days of data, but they intentionally throttle it so it's slower if you do it because they don't want you doing it because it's a very big resource strain. So you actually have to use scripting to make calls against it. It's not as simple as just pulling it out of the API. So, what that means is it could take you more than a month to get a month of data out of it. So, realistically, in practice, not on paper, what that means is if somebody got in through GitHub, GitLab, whatever, they got some secrets, got in through your organization's authentication system. Now they're in Slack, and now from there they pivot to Office 365 or Microsoft 365, you only have seven days of data. So you don't even know necessarily how they got in. Your ability to sort of determine what happened and what, you know, what's going on, and how long have they been there, and what else have they done, what have they gleaned? It's almost impossible. And then from there, maybe they're getting into some S3 buckets and they're exfiltrating data. So everything's interconnected. So in the early days of Mitiga, Mitiga was actually an incident response company. Well, in the old days of doing forensics, what would you do? You'd get a server, you'd rip out the hard drive, you'd mirror the image, you'd do some analytics and stuff like that. You're not going to go up to Amazon or Microsoft and Google and say, give me all your hard drives so I can do forensic analysis. So what are you basing it on then? You're basing it on log data. So in the example I just gave you, Slack isn't giving you anything. And I'm picking on Slack only because it's popular. Slack's not the only tool SaaS application that doesn't give you logs unless you buy the enterprise account. There's a gazillion of them. Big things like Salesforce, for example, are in the same boat and there's others, but you don't have any logs there. And then you move into Microsoft. Oh, I only have seven days of log. So you call up a company to do incident response, and like, guys, either you don't have anything or you do have it, but it only goes back maybe a week, or if you're lucky, maybe 30 days or 90 days of data because you can't afford to put more than that in your SIM, which means it's almost impossible to do a very thorough level of forensic incident response. So the folks at Mitigas said, you know, this is a problem. Why don't we put a service together where we'll help organizations tune and optimize their cloud identity and SaaS solutions? So all the data is being collected, everything's being turned on at the right level. We talked about AWS before. I've got Elastic Kubernetes on and Route 53 and S3 logs, and I've got this, but there's different levels within each of those. So getting all that tuned. So when something does occur, you have the data to enable you to do the forensic analysis. And that was being offered as a service. And then that turned into a platform because we said, man, wouldn't it be great if we could just do this in real time for people? And or sometimes you get these logs every hour or maybe every few hours. So I'll say near real time, but it's near as near real time as you can get really in a cloud environment. So that's how the platform came to be, which I love because it started off with real incident responders migrating to a service, migrating to a platform and all those lessons learned and all that's baked into the solution.

Robby Peralta 14:07

When you say they're hopping from Slack to, you know, all these different systems, how are they doing that?

Brian Contos 14:12

A lot of the times this just happens to be through uh information they're able to glean from these other systems, whether it's tokens that they can grab, API information, whether it's actual credentials in these. Again, if they're coming in through, they've already bypassed your authentication mechanism and they're already able to get through whatever you're leveraging for that. They can just sort of enumerate, like we used to enumerate shares when we did pen testing back in the day to figure out what other systems do you have in place. I already have my credentials to get through here. If I can log into Slack, maybe I can use those same creds now to log into Microsoft 365. So the power of the cloud sort of weakens it as well. And, you know, security people know this. It's not that there's not an awareness of this. And we're to the point with cloud that we know that, yeah, AWS and GCP and Azure, they're going to do some level of security. But by and large, it's a partnership, but it's a partnership where 99% of it falls on you. The things that they're taking care of are very foundational. And that adds value for sure, but it's up to you. But again, it's closing that gap between cloud security and general security, which I run up against at every single organization I go into. And it's a lot of finger pointing. Well, who's responsible for this, right? And the thing it reminds me of my old days at Imperva when we sold web application firewalls. You're selling web application firewalls to security people that don't develop web applications or web application developers that don't do security, which means you have to have multiple meetings to get people in the same room and they don't even know each other. It's not quite that bad with cloud and security, but it's almost that bad. And we see it, and CISOs realize this, and you know, leadership understands all of our stuff's in the cloud. We need to have cloud security that's on par with what we used to do on-prem. And most cases, when it comes to detection and response, it simply isn't there.

Robby Peralta 16:05

Well, one thing that's uh helping you uh as a player in this market is the scattered lapses hunters of these AP Teens, right? I feel like a lot of the uh attacks that they're doing these days there are involving a lot of things that you just covered on. And I believe that that's the scattered lapses hunters. They're the ones that are doing a lot of stuff around Salesforce. Is that correct?

Brian Contos 16:25

Yeah, you're absolutely correct. People say, well, we want to go after this company. Do we go head on? Or do we kind of take a roundabout path? And that's exactly what happened with Salesforce. So for some of your listeners who may not be aware, Salesforce has been in the media a lot. But to be very clear, it's not because there's a bug in the Salesforce platform. Salesforce technically was not attacked. The breach came from a trusted third party. And we talked about that earlier, right? In the podcast we talked about third party and fourth party and fifth party risk. Well, they were this came from a trusted third party integration, which is what the cloud's all about. So, in some popular cases, some attackers, they they compromise the third-party SaaS apps for organizations like uh Sales Loft, they've got Drift, and also GainSight. Now, GainSight, I think, is still offline at the time of this recording. They basically got kicked off the Salesforce App Exchange. And again, for those that aren't familiar, that's the equivalent of being like taken off the Apple App Store. Like people can't download your app anymore. That's their business, yeah. That's their business. And for an enterprise, most let's be frank, most enterprises, well, let's say Fortune 2000 and smaller, but we'll say Fortune 2000, use Salesforce in some way, shape, or form, right? It's a very popular tool. It's it's very important to an organization, houses a lot of sensitive data. There's a lot of valuable information to run the business on operationally. Anyways, it's got a lot of the crown jewels. So this isn't to say Salesforce did anything wrong or even sales loss or gain sight, because these were pretty sophisticated attacks. But the way the attack worked was interesting. So these apps, gain sight, sales loss, I keep on mentioning them, but there's many others, right? These apps had legitimate OAuth access into the Salesforce instance, which means they were supposed to access Salesforce, they had to access Salesforce in order to provide the value that they're getting, which is now why gain sight not being part of Salesforce anymore is a critical issue because the whole reason people buy it is to give them further insight into Salesforce. So you can see how this is detrimental to their business. But back to the technical bits, once that OAuth token is stolen or abused in some way, well, now the attackers can act as if they had legitimate, fully authenticated access. Now, Robbie, you know in theory that when you give some type of access via OAuth token or whatever it might be, API keys, whatever, that you want to use lease privileges. That's theory. That's what it says in the textbook. The reality is it's never least privileges, it's full privileges and access to everything because it makes it easy and nobody changes it. Again, cloud not security, security people aren't cloud. So unfortunately, when these breaches occurred, it wasn't a least privilege access. They had access to much, much more. So that's that's one of the problems in design. Now it goes a little bit deeper than that, too, because these tokens grant API level access to Salesforce. We we kind of get that. Well, the attackers didn't need credentials or to go through their multi-factor authentication solution as end users. They simply used that valid token with the API call. So they have that token. They just used it. They didn't have to do all the security controls you had in place, all those preventive controls, they stopped working. So, what's that mean? I'm silent, I'm persistent, and I'm automated. That's a heck of a combination. So, in the case of Sales Loft, those attackers reportedly got compromised through a GitHub, which we talked about that earlier. Again, just because it's another big thing developers use, they use these repositories, a GitHub environment. And they stole the client records, um, they're stealing API credentials. And then they used that to escalate and pivot into the drift application that was provided by SalesLoft and their environment and extract those OAuth tokens so they could get access to all the customer accounts. Now, once they were inside, again, these these criminals, what they did was they were using a number of scripts and automations for these API calls, and they're often going through like Tor exit nodes as well. So they're using more traditional ways of hiding. But it was all about XFIL. And you go, okay, well, where are they going to XFIL at Salesforce? It's CRM data. That's valuable, that's important. But what else? No, no, no, no. Again, because they had access to everything because of the way that the OAuth was set up for ease, not for security. They reportedly, and I'll say reportedly, extracted high value items like AWS keys, snowflake tokens, passwords, internal support case data, other credentials that happened to be stored in Salesforce for whatever reason. So essentially it's like getting into your most sensitive data repositories back in the old days that you had on-prem. So it is a big, big deal. So that's that's what we're seeing with Salesforce right now. And it's we call it the Salesforce breaches, but technically it's not a Salesforce breach. It has to do with those organizations connected to it.

Robby Peralta 21:29

Although I will, we we can agree that this is not great for their reputation either. I guess.

Brian Contos 21:34

No, no, it's it's not. It's not and Salesforce does have some tools out there that they they supply in order to help. There's Salesforce Shield. Again, but that kind of goes back to that preventative control that we said. And I and I want to sound like the guy that said, Oh, prevention's completely dead, don't do it. I'm just trying to say that we're pivoting now to a resilience model. Because Robbie, if you think about security, like even maybe five years ago, but let's say even 10 years ago. Go. Prevention by and large is where you put most of your money. And then you had some money for detection, and then maybe a sliver of that for response. And that's kind of how it was. It was this uneven balance. But now we're seeing as it relates to resiliency, which is all about how the cloud operates, we're saying, okay, of course we're still going to have preventative controls, but we know that's not going to scale because we're connected to 50 million companies that we don't even know about, that we don't control their security. We better focus on detection and response and resiliency. So it shifted those budgets now. So we're seeing a much higher focus now on detection and response. Again, not that prevention's going away, but a higher focus and a larger budget in that area.

Robby Peralta 22:42

It's really funny. I've been in security like what, 10, 11 years now, and it's gone like prevent, no, detect and respond. Oh, prevent again. And now it's uh back into resilience. Yeah, the never-ending roller coaster. I was playing around with ChatGPT prior to our talk here, and it said that initial access, CDR is not, has nothing to do with initial access. Because I was reading, like, okay, you know, the uh exploitation of vulnerabilities or the fact that uh leaked credentials, all the ways that uh attackers get in. CDR is not meant for that. It's meant for everything that comes afterwards and data exfil. Is that correct? I think that's a point to drive home.

Brian Contos 23:21

I I I think there's a lot of truth to that because I I alluded to this earlier, but I'll say it again just to emphasize we're not seeing as many attacks within the cloud where people hack in. It's more likely they log in. But when they log in, they probably hacked in or got in for some other mechanism someplace somewhere else. It's just where in that chain of events did that occur. But you're absolutely right. We've seen cases where we're actually working with customers and we have threat hunting built into the platform as well. And we have identified issues and they resolved them. And then a couple of weeks later, they get a call from one of their SaaS providers that say, Hey, we had a breach. Um, we just wanted to let you know it happened and you might have been impacted. It's like, yeah, we are already quite aware of that. Thank you. Um and it's again, it's because we're focusing on the entirety, that sort of panoramic detection, if you will, across all those pieces. If you're just looking at one section, you're you're not really doing anything in cloud. And I hate to say that because I don't want people to say, oh, well, we've got, you know, these things turned on in AWS. If we're not doing everything, should we just turn it off? I don't, that's not the point I'm trying to say. The point I'm trying to say is to do cloud security right, yes, you have to look at infrastructure. More importantly, infrastructure configured properly, but you also have to look at identity and you also have to look at SaaS. And if you're not combining all three of those, how can you possibly try to make a determination? That's like you're going to a patiatrist and you're just having them look in your ears at the doctor. How's that going to help you? Right. So it's it's looking at the entirety. And the reason people haven't done it in the past is one, there really weren't great solutions to do it. There were sim solutions, which were a square peg and a round hole. Cost, the egress cost and the storage costs were just too prohibitive to try to enter this. And the last part is there weren't any outputs of this that actually made it useful. It just became this huge data store, but no advanced analytics to help me say, okay, here's 10 terabytes of data. Great. Now what do I do with this? Right. And have have things actually bubbled up into a nice visual that said, hey, here's the attack path. They got in through here, they did this, this, this, and this. They pivoted here. That is so powerful. And that again is resiliency. You stop the bleed before it gets bad. Like if I see something that smells a little bit malicious, I'm gonna block it. I'm gonna disable that account. I'm gonna quarantine it. These aren't disruptive things. You can, if you made a mistake, you can always turn them back on, re-enable. It's not like I'm gonna burn down my S3 bucket, right? But I want to do these things as quickly as possible. And if I made a mistake, I made a mistake and I'll go ahead and rectify it. But I rather do that than let something get by on my watch. Nobody ever did that for the past 30 years. Now they are. And the reason they are is because they have to, again, all about the resiliency level.

Robby Peralta 26:22

How much of the market do you think that CDR is relevant for?

Brian Contos 26:27

There must be companies that don't use like that much SaaS or there's a very small percentage of organizations that it's not relevant for anymore. I'd be hard pressed to think of any, let's say Fortune 5000. That's not entirely or the majority of their organizations in the cloud. Now that could be cloud infrastructure, that could be dependent on SaaS applications. They don't want to on-prem stuff. That's like having a PBX system in your closet. Why the heck would you want to do that? We've we've passed that point. So I think it's relevant for virtually everybody. And and the great part of it is from an attacker's perspective, is if I'm able to get into something, you know, we'll go back to the Salesforce attack, right? If I can get in through somebody that's connected to a lot of things, so it's spiderweb's out. Then now instead of being able to do ransomware attacks against one or two companies, maybe now I can do it against two or three hundred companies or two or three thousand companies. So it really expands that attack service. Again, that that's what's so peculiar about the cloud is everything that makes it powerful from an attacker perspective also makes it weak, right? And it sort of opens you up, which further underscores the need to have strong security controls and a space that, and the attackers know this, there's not a lot of people that are cloud security experts out there yet.

Robby Peralta 27:44

I would assume something that you might hear often from a client is yeah, but we have like an E5 license or we already have all these features and functions turned on in AWS. Like why do we need more? What would just be your quick response to that?

Brian Contos 27:56

Yeah, no, I think that's great and that you have those things turned on uh in AWS. But I would also argue that there's a lot more to your cloud infrastructure than just AWS. And you also want to validate that those things that you have turned on, there's no environmental drift. They're actually logging and doing what you want, how you want. And the other piece of that is a lot of those things are turned on for preventative capabilities. But if you're seeing sort of possibly nefarious activity going along, they're not really good at that level of detection. And they're not integrating your authentication. Maybe you're using AWS for authentication, maybe you're using all of that, but you still have other SaaS applications that are coming in. Again, it has to do with that panoramic visibility. Turn those things on, please, makes sense. But don't think that that's giving you the complete picture. It's not, it's giving you a slice, an important slice, but certainly not everything.

Robby Peralta 28:45

And also, I I would assume that your product has like some sort of threat and tell feed, so you know what these uh AP Teens are doing these days, and you're sort of looking for those patterns of behavior across the environments.

Brian Contos 28:57

Yeah, this stuff changes really, really rapidly. And it's so specific in the way they pivot from hey, they learned how to do this nefarious thing now, and now they've built five other attacks predicated on that, being part of that community and being able to have visibility into that's a very important.

Robby Peralta 29:13

Now uh I feel like I know everything about CDR and I'm I'm all in on it. Do you have any do you have any closing thoughts?

Brian Contos 29:19

I guess my closing thought is even CDR itself is evolving so quickly. Uh, now we're starting to talk about AIDR, which is AI detection and response, same thing. This whole notion of the three pillars. I've got AI infrastructure I've got to protect. I've got AI attacks, and I've got back and AI controls to address the first two. That's coming up in a big way. When we talk about security, we always we've always talked about CIA, confidentiality, integrity, and availability. But to be fair, we really meant confidentiality and availability. Integrity didn't get a lot of play. But now with all these AI infrastructures, if you hacked into some autonomous car system and you said, hey, anytime you see a red octagon stop sign, treat it like it's a green light, that's an integrity issue now. And now you're causing huge amounts of pain, huge issues, right? So now integrity has become so important and all these types of poisoning attacks that again, it all lives in the cloud, but it's leveraging AI infrastructure. So now it's how can I apply those same controls for detection and response for the cloud more focused on AI, that's becoming a big, big story. And I would start to say that that's kind of starting to even out. So our customer base is saying, hey, we want to talk about C DR, but we really want to talk about AIDR now. And the reason why is because our board, they don't know anything about security or AI. They just know we better be doing this AI thing, whatever that is, we want to do it. So they're being pushed and they're getting funding and they're getting resources to do it. And again, just like cloud people, security people aren't the same. We're seeing that in AI too. It's like, who takes responsibility for the AI security? What group manages that? Who collects the data? And luckily, tools like Mitigan and others were the ones saying, hey, to us, it's just another source of cloud data. We're gonna treat that just like anything else and correlate it, analyze it, do all the AI processing on it as well. So we're already there. So that's a big, phew, okay, we've gotten that part at least taken care of from a resilience perspective. So that's gonna be a big part of the future. So I think you're gonna start hearing more about AIDR probably next time we do a podcast like this in about a year from now.

Robby Peralta 31:28

Right. I heard uh quote, I think it was from the Google podcast that the the CISO is the HR manager for AI systems.

Brian Contos 31:38

That's that's a that's a great way of saying it. Something I also heard that uh AI has become uh the security Rorschach test. It can be whatever you want it to be or don't want it to be at any given time. Yeah.

Robby Peralta 31:50

Well, Mr. Contos, thank you for uh always joining the podcast every time you uh jump it into something cool. And uh we will make sure to uh follow your progress in Mitiga moving forward. Thank you so much for your time.

Brian Contos 32:02

Thanks, Robby. Thanks for everybody at mnemonic. Ciao.

Robby Peralta 32:06

Well, that's all for today, folks. Thank you for tuning in to the mnemonic security podcast. If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcast at mnemonic.no. Thank you for listening, and we'll see you next time.