Exploring AI and Cloud Security: Insights on Software Supply Chain and Workload Security – CISO Talk EP 42
Anton Chuvakin, security advisor at Office of the CISO at Google Cloud and former Gartner distinguished analyst, joins Mitch and JJ to discuss AI and its security implications, software supply chain security and moving and securing workloads in the cloud, including its similarities and differences from operating in traditional data centers.
Transcript
Well, hey everyone, you've joined us for another episode of CSO Talk. Got a very special guest, someone that, uh, JJ Jennifer and I have known for a little while. Before we get there, Jennifer welcomes, could we, uh, chatting again, CSO stuff?
Absolutely. Always fun to talk with you about it. I think we're gonna hit the AI topic pretty quickly here, but let's introduce our guest because I'm, I don't want to get jumped the gun.
We've got to introduce, uh, Anton Anton Shaba and is someone that we've known for, for a fairly long time. He is, uh, senior security staff at, uh, the offices of the CISO with Google. Welcome Anton.
Uh, sure. Thanks for having me on the show. It'll be fun.
Absolutely will be fun. Um, tell us a little bit about what senior security staff at the office of the c CISO is at Google. Just a a little bit of peek into the day and the life of.
So, uh, first thing is, uh, there's a minor correction to this. It's actually Google Cloud, not Oh, okay. Google as such.
Uh, okay. Because, uh, I work for, uh, Phil Venables, who is the seesaw of Google Cloud, and, uh, there exists an organization called Officer the Seesaw, which is kind of, um, has an interesting charter. A lot of what we deal with is kind of customer use of cloud and, uh, I can't say that we are, well, my title is kind of, uh, advisor or consultant, but ultimately our charter is to a large extent, help clients use Google Cloud and other cloud security.
So it's kind of a very broad mandate, and, uh, occasionally it veers into more strategic discussion, like transforming somebody's security, operat, security operations function of transforming their entire security to be in line with the modern times cloud use. And sometimes things get to be a little more tactical. Like I still deal with my good old sim and soc and the detection and response domains.
So in some strange regard, uh, those of you who know me from my Gartner days in some strange regard, my current job a little bit reminds me of my previous job with Gartner, because I do deal, I do advise clients, and I also do undertake some, um, you know, research and kind of, um, comprehension of various company X topics, including AI security, uh, for the benefit of the clients. So this is, uh, as fuzzy as it goes, but, uh, I do get to write papers. I share a couple, uh, later on, and I do get to talk to clients, and I do get to kind of understand how what we do in security applies to what they have in their environments.
Fantastic. Gigi, uh, why, why don't you take, kick things off here? Yeah.
Uh, well, you said we wanted to jump in with the AI topic, and I think this is one that's, uh, near and dear to everybody's heart. Not just CISOs, but I think us just as, uh, consumers and, and people moving about the world where now we have generative, um, AI and e everything is AI driven in even the things that aren't actually AI driven. So, um, and, and one thing I think is really interesting is, you know, we have these sort of niche use cases with different applications and maybe in the consumer world, but when we're looking at what we're doing for businesses and the enterprise, especially as it relates to cloud security, you know, I love understanding what's happening at scale or what's happening, um, so at scale, but also within the viewpoint of the organizations that are servicing those of us that are smaller scale using services.
And so I think, you know, a couple of the first questions that, um, that we have are whether regardless of the size of organization as it relates to ai, um, what do you, you know, I have a long list of things CISOs are asking, um, us and me Mm-hmm. For advisory services. But I'm kind of curious from your viewpoint, seeing it kind of up here, what do you think they should be thinking about or concerned about or planning for?
So this is, uh, this is kind of fascinating and I'm gonna, I'm gonna take it in many different directions. Uh, and first thing is, um, I wanna sort of gently push on the, what they should be asking, because ultimately they are asking some things, and it's almost like, does it matter what Anton thinks, what they should be asking? So for example, uh, if, if I, one of the stories that happened in, in my line of work is that we looked at some of the questions people are asking, and one of the top questions was about the intellectual property of something that is produced by GNI.
And my first reaction was, that is not a CSO question. Why are you pushing it to, why are you coming with that? But, but ultimately it does come from CSOs.
So we may, I may not think from first principles, whatever they are, uh, don't really have that many in cyber. I guess that they shouldn't be asking about this. You should be asking about how to secure the applications, how to secure the use of AI services.
But, but they are asking about that. And in that sense, it matters more what they're actually asking versus what they should be asking. Uh, for example, in some other, uh, situation, the question was about securing the data as it enters a certain AI enabled data processing pipeline.
And then the question came up of securing the data that comes in, and then also filtering the data that comes out. So to me, it's, the questions that comes up, uh, are probably more important than what I think they should be asking. Uh, one, one thing I I would say is that my personal obsession in this area was the differences in similarities between securing AI and securing some other complex data intensive enterprise system.
So, as a, as quite as a side note, um, I also run a podcast for, for us, and I've been kind of obsessed about asking this question of every guest who has anything to do with security and ai, I say, Hey, tell me which things from my normal security thing can apply and tell me which things are new. Because if you follow the media headlines, sometimes you, your impression would be that it's all new. But in reality, it's also very not true that it's all new.
A lot of stuff is very old, secure infrastructure using stuff, you know, identity and access management. I don't know, stuff like that. A lot of this is very much the same.
So to me, a useful question as CISO should ask, and some do ask that is securing ai, give me the, then give me the pie chart. This is old, this is new. How big is the new sliver?
What should I do there? How much of my old stuff really works? And that pie chart that I just imagined would be different for people simply using AI type services versus tuning in versus building, versus incorporating applications versus using the raw elements to build their own and train their own models.
So to me, the pie chart would change, but the fact that there is a pie chart and the pi, and, and the bigger part of the pie is the stuff you know how to do, you should still do AI or not. And the, let's call it a little, a smaller chunk of the pie chart will be, yeah, this stuff is new. If you have perfect knowledge of security up to last year, you won't know what to do here.
So to me, this is a useful framework. And of course there's a paper we wrote on this very thing, but, but ultimately that's a useful question. What's new, what's old, And what are the top two or three trends you're hearing from your guests and, and other people?
And what, what is that new sliver? So one thing that comes up kind of, maybe not all of the time, but often enough, is that people, organizations started figuring out this whole security supply chain and, and software supply chain and like securing open source software. By the way, this has nothing to do with AI at this point.
I'm, I'm gonna get get to the point. And, and it is kind of line of thinking about the supply chain and what goes into what sort of software you use when you use application X. Do they use libraries from Y and all that?
So a lot of this thinking becomes strangely relevant for ai. But in regards to data, like if you're training something on certain data sets, like where do they come from? Who held them in their hands, what did they do with it?
Um, who made them, who refined them, who filtered stuff? And this, uh, I am not a responsible AI expert. There's a whole other domain and a lot of very intelligent, very well paid people at Google who do that.
But some, some of this overlaps with responsible AI because certain changes to training data and to other type of data that affect what AI would do, have security outcomes, have safety outcomes, have other outcomes. So to me, this type of thinking that to program ai, you use data and you need to treat this data, please don't say data as code on treat it as as you would software, uh, in terms of supply chain security. So this to me is one bucket that I've talked about, thought about, had conversations about, and it's also somewhat misunderstood and unclear, but when we say this is training data and this training data would affect what AI system would do, treat it as you would code in other domains.
So this is one bucket, You're kinda root primitives. You sort, sort of mentioned before, if we have those, but you know, data protection that's not new where, where data lives and how we manage it, you know, and is that going into our models? Is it going into third party services just like it might be?
Is that going into our database or into a third party SaaS application? Mm-Hmm mm-Hmm. Not the same Exactly.
But the same principles right. Kind of apply and of course, correct. I think you brought up a really good point of are you consuming and using services or are you creating your own kinds of applications and models and training and which is, you know, a whole nother level of, uh, both knowledge and sophistication, but also you have control over that.
Correct. So you can secure it. I mean, you could do it insecurely just like you could do anything else in what we do.
Right. And the, the other side angle to this is that, um, in some cases, the, if you have the proverbial large complex enterprise software, you shouldn't really be scared about its output ultimately have, if you have ACRM system and you piled a bunch of very sensitive data, uh, into it, what would come out is probably the same data or some product of that. And you wouldn't, shouldn't be scared of the output.
I mean, scared is a little harsh perhaps, but the point is that output is gonna be mostly predictable for systems as generated ai, you should treat output as, eh, maybe not untrusted, but as not fully trusted. So, mm-Hmm. I'm not gonna output filter except for possibly data theft purposes of my traditional system, but I am going to output filter the system that has gen ai.
Right? That sounds sort of obvious, but it's certainly not for people who are assuming that, um, malicious data may come in and sensitive data may leave, but in this case, malicious data may leave and that you don't want that. So, so in that sense, that's probably minor, but, uh, it's interesting nonetheless, and I think it's also useful for people who are starting with this type of system.
Do you find most questions are coming from people that are trying to build AI t into their applications? Or is it more consuming AI type services and tying it into their Google applications or third party apps? It's a, it's a mixed bag.
It's, I I, I'm not even sure at this point. There's another little side angle to to your question is, uh, are they trying to use consumer grade services for business? Mm-Hmm.
And that to me is, uh, probably more applicable to kind of quote unquote the other guy, uh, namely OpenAI in this case where, uh, the whole world rushed in in November last year, right. To use, um, chat GPT and some other stuff for all sorts of fun things. And initially for fun things, and then later on for businessy things.
And I have some use cases, which I, I probably won't share, that to me should scare people because this is really not meant for this type of stuff, but people, I, I naturally gravitate into exactly these use cases. And my reaction was, but wait a second. This is very business sensitive data, tricky use case.
Why are you using a consumer grade service that should, you should think That's a little crazy, right? Mm-Hmm. But ultimately, um, oh, ultimately the, the result is not, um, that surprising perhaps that it's kind of the, uh, they use consumer grade things for business and then think nothing about that.
But then they, what happens with the data, what happens with governance? And they start asking those questions, but the questions may not have any answers because it was not meant for this use. Uh, I mean, it's, it's, I I don't wanna put my, uh, I think I have my nuclear hat back there, and I don't wanna put my vendor hat here, but at least, at least in case of Google, it's very clear if you use Bard, it's consumer grade.
If you use Vortex ai, it's business. And we try very hard to clearly steer people to the right things. Now, does it help every time?
No. People still say, oh, but we are gonna use BART for this. And it's like, wait a second, that's a consumer service.
That's not, no, look over here. And that to me is interesting how, because of this whole bring your own AI adoption route, we are observing Mm-hmm. These things would happen.
And, uh, I got into somewhat fun discussion on LinkedIn with somebody who said, well, it's a little bit like, bring your own SaaS application, bring your own cloud. When people whip up a credit card, pay for something, and then they have a business use case. But is it meant for that?
That's not always clear to people. It's not a new problem. We've been dealing with that, you know, business, uh, consumer product or something business, it comes up necessarily controls management, et cetera.
Mm-Hmm Mm-Hmm, exactly. And I think there's a, a big part of this is the user education. I think this is one of the things a lot of CISOs or whoever is responsible for wrangling this in the environment is, is trying to deal with, which is it, it's not a matter of, you know, maybe the office of the CISO or a department or a group related to it, trying to use AI and not knowing how and what to do.
I mean, there's definitely some of that, but it's how do you keep someone in HR or someone with access to your, your CRM or your sales records or someone with access to, even in the operational technology space, I've learned this is kind of a, a big deal where they're, they're trying to automate some analysis by feeding what, what's, what is in that space, very proprietary information related to like Modbus protocols into these consumer engines. And so I'm assuming, you know, short of redirecting, redirecting users, if you try to go to this, you know, consumer grades the site, we're gonna shoot you over to a little blurb that says, Hey, we use this tool, go talk to so-and-so about accessing it. Yes.
Are there, are there other things in place or strategies to deal with that? So I feel like a lot of this is still emerging. Uh, the, when people started using a wide range of SaaS services for business, probably like 10, maybe more than 10 years ago, uh, technologies like CASB, a few others appeared, which were meant to serve as kind of a filter for that.
And, uh, as a fan aside, the podcast we recorded today with somebody was about SaaS security. And somebody said, I think LLM would trigger a even wider, even broader software service ecosystem. And somebody will have to deal with all that, because if it's a AI powered notepad or AI powered image processing of some sort, they may, you may not be looking at dozens, you may be looking at hundreds.
And they would all have, uh, some form of gene AI or other AI inside. So to me, this is a kind of a fascinating slash scary, uh, area. And I, I feel like, uh, when people are launching those startups to secure all that, there is a point in that there, I mean, there is, uh, some startups do look like features, but ultimately there is a new world being born.
And that's very much very real. I feel like our concern, at least from my point of view, is I'm less concerned about somebody throwing a bunch of text and bullet points in and asking for a better marketing blurb for an event or an email, and more concerned with that proprietary data being fed into an engine that just like you said, with the supply chain and other applications, who, who has access to that? Who had their hands on it, at what point?
And then you have the whole kind of worrying about not just the, the garbage in, but now you might have kind of the garbage out happening, Right? And I think that, that this whole gems in and then somebody else looks at gems at your gems. Yeah.
That's probably like the other problem. And I think this is solvable. I, I, I'm not really an expert in how we solve some of this kind of IP related stuff.
Like I read the materials, but I don't have the depth on, on knowing this. I know that, for example, recording prompts versus not recording prompts, using prompts to retrain versus not using prompts to retrain is a big part of that. Like, ultimately, if we don't use, if you don't use any of the data to enrich the model, then it's, you're safe from that particular risk.
You may be not safe from other risks, whatever they are, but at least that risk is, is cleanly taken care of. So I'm gonna, Mitch, if you're cool with that, since we have Anton here, I have a lot of other questions around, uh, just moving to the cloud. And we have a lot of organizations now.
I think we've, we've hit this stride where we're past the early adopters and now we're into, most organizations are trying to move some or all of their operations into the cloud. Uh, and I know that's an area you've worked heavily in for some time now. So I'm curious about, um, your viewpoint of the trends in that space, uh, where the stumbling blocks are and where you think maybe the maturity curve is for a lot of organizations who are making that move.
Um, any thoughts on that? So yes, I, I first, uh, I'll probably share somewhat the embarrassing story first, uh, that's connected to this. We love Embarrassing stories.
And, and, and, and yes, later it became a more tame blog, which I'm happy to share. But ultimately, the initial initial embarrassing story was I had one too many conversations, um, from people who sort of mostly follow the on-premise blueprint in the cloud, which yes, they lift and shift it, they lift and shift security, they do firewalls and IDS and network packet capture and EDR and everything that they've built in their data centers in the last 30 years, they take with them to cloud, and then they replicate all that on the, it they had on premise in the cloud. And the initial reaction that I had was, it's not 2013, why are you doing it?
Like, why? Yeah, sure. In the early days of cloud, it was probably natural to use it as a colo because people didn't have anything better.
But like this whole universe of cloud native and microservices and containers and all the fun stuff, and I was kind of pretty close to shaming some security leader in one conversation when I said, it's 2003, why are you using the on-premise blueprint for cloud? Like, I was really kind of frustrated and kind of like, not, maybe not angry, but like, kind of like my reaction was like, that is stupid. And the person who was actually older than me, and hopefully, and, and as it, as it turned out in a minute wiser than me, looked at me and said, Anton, we are not using the on-premise blueprint for cloud because we think it's great because we think it's the right way we use it because that's the only one we know.
At which point I said, okay, yes, this is like one of those Buddhist stories. And then he got enlightened. And that was my moment of like, and then I got enlightened.
I stopped shaming people for not being cloud native enough in 2023 because, uh, in many cases, the organizations are following the blueprint that they grew up with since, I don't know, the seventies, eighties, nineties, pick a date. And their journey into the cloud is very much based on an on-premise blueprint. And it, it is not, they don't need shame in, they don't need motivation.
They need to know how to actually do it, how to actually transform to be maybe a little bit more cloud focused, cloud native, whatever the term we use, uh, and then grow from that rather than to just say, ha, haha, you are copying the M to it from a data center to cloud. That's stupid. Like, that's not the way to go ultimately saying this, because that's the only, for many organizations, it's the only route they know.
And so instead, I focused on figuring out how we can remap their mental models to cloud security. And, and the vlog I mentioned was how CISOs need to adapt their mental models for cloud security. And that was my revelation after that, that that discussion that ultimately we need to very gently explain, okay, you want to do ADMZ?
You, you, you've, you've lived with DMZs for many years. You know, there are firewalls, there's a public side, private side, um, you wanna replicate it in the cloud. Okay?
So in the cloud to achieve the same outcome, you would use this thing instead. And they'd be like, oh, okay, well, is it better? Yes, it's much better for this this reason.
It's also cheaper because of hardware. And they would say, okay, yeah, I get it. So DMZ is that thing.
Okay, yep, thank you. And then we say, okay, well what about this configuration assessment scanner? Yep, we have that.
That's called this thing in the cloud, and it does check your configurations for your applications, for your platform for this other stuff. Oh, okay, so we still need to do this. Yeah, that's called CSPM, whatever.
Uh, and it's just like what you had in the nineties with a configuration scanner from whatever vendor. And they say, okay, yep, that makes sense. And then they, this, this story needs to continue so that people with predominantly or exclusively pre-cloud mental models of security would grow into that type of, ah, that's what it means in the cloud.
So to me, this was like a big part. And there, there are absolutely companies who follow the on-premise blueprint to cloud in 2023, and no shaming them is not the way to go. It's this type of slow and somewhat detailed oriented education for both subject matter and also the kind of concepts and models of what cloud really means and what are the ways to achieve the same outcomes rather than just with the equivalent controls.
Equivalent controls ends up being a little bit off, because if I say, what's EDR in cloud land? Well, you can put EDR on the cloud on on the cloud instance. And then people say, whoa, wait a second, we don't have cloud instances.
We're gonna be microservices. Okay, so then EDR is a deeper visibility beyond logs from this system. Okay, so you probably should use this.
So, and that conversation may need to happen many times. It may need, it would be frustrating sometimes, but ultimately it almost has to happen. Makes sense.
And I think, so lemme ask this, I think there's obvious on-ramps to using cloud services like email and mm-hmm. Things like G Suite for businesses, and we've seen a lot of that on the, on the education side for mm-Hmm. Forever.
Um, what is the next couple of steps for an organization, like, based on what you've seen from an adoption standpoint, okay, we've gotten these few services in the cloud. Where do you feel like that next kind of big jump or hurdle is for them learning curve? Oh, so your, the scenario I have in mind is somebody who, um, maybe ran his own exchange since the nineties to 2022, and in 22 they switched to workspace or some other SaaS email and their days of managing their own email, they're gone.
So what, what should they do next? Like that's roughly what you're, you're asking. Yeah.
What do you see as that next adoption kind of milestone? I mean, it, it, it, it strongly depends on the company. A lot of people really started, not from email, but maybe from infrastructure.
They started saying, okay, these are my applications. Uh, I'm gonna refactor the app for the cloud, or maybe I'll migrate it to the cloud co copy lift and shift it to the cloud. And then slowly refactor that often what they want, but not what they do.
But, uh, I, I don't think there's any one adoption lineup. Like for, I, I've seen people move applications that deal with, you know, even sensitive data because they realize that cloud is perhaps more secure than their data center. But, uh, I think email is kind of the only easy, obvious, don't run your own exchange server.
That's crazy kind of bucket. Uh, uh, other things to me are more and more nuanced. At least that's my, uh, sort of unprepared mark to this.
Yeah. It just depends on the application. That makes sense.
Yeah. It's also seems, um, if you're on, in your certain point in your cost cycle, right? You are allocating dollars to more hardware, more this, it's like, okay, that's a na also a natural time.
It was for me, first time I had moved up to the cloud was, I'm not gonna budget for hardware refresh in two years. We're gonna do it this way, let's see if we can do it. And that was, you know, that's been a while.
You can, now we know you can do it, but it seems like that might also be, there's some financial incentives to say, can we save money? Can we do things differently? Can we economize, you know, or their capabilities we would have there in the cloud we don't have in our own data center today.
Right. And then people who would, uh, who would still be very, uh, attracted to replicating what they have on premise in the cloud. Again, the, the idea is to sort of point out that there would be things that I give them exactly the same outcomes, likely better, almost certainly cheaper, uh, compared to copying their entire stack.
Because at this point, cloud is depending upon how you count maybe 15, 17 years old, you know, depending upon the first date, you would consider the birth of public cloud, uh, people, there's already a lot of stuff known how to do things better. And some people would say, no, we still gonna go with the on-prem route. And you tell them, okay, if it's the first step, maybe that's okay, but here's where you would be kind of wasting time.
Or you'd be either protecting against threats that can never materialize, or you'd be investing in things that are very inefficient compared to a very efficient cloud native way. No judgment and no, no shaming, but kind of pointing out that some of these things are, will be suboptimal. And some of them are suboptimal from the effectiveness point of view.
Some of them are quite fine from the effectiveness point of view, but are very wasteful from economic point of view. So in that sense, if I can you copy every single packet of every single link from one cloud inside your cloud use? Yes.
You can copy every single packet from the, within your cloud, your east, west, within cloud effectively. I can copy it on disk, I can dump it on disk, I can save it, I can keep it for a year. Is it a good idea given that much of it's encrypted?
No. Uh, would you be able to understand what it all means? No.
Um, are there tools that would give you that at an enormous expense? Yes. So make your own decisions In this case, It sounds like one, the lesson you're, you're kind of sharing is, look, things are different, but you just need to map it.
What you know, is this is had done this way now and some things maybe are architecturally, structurally you might be quite different. A lot of things aren't that different, right? Yes.
Correct. Still basically a firewall, but it's done a little bit differently in the cloud. And, you know, you're not setting up the networking exactly the same and VPNs or VPCs or whatever kind of services that replace Mm-Hmm.
That, and they have other characteristics about it. So it's just that learning curve of mapping what, you know, and maybe finding out the new things, new ways of doing Things. Yes.
Yes. And that's why, um, the, the, the, we sort of have this on our podcast team, and me immediately jump on every guest who says something vaguely similar to cloud is just somebody else's computer. Uh, because we, this is the line we hate for the passion.
And, and I do too. We hate it with the passion because of the word, just because obviously cloud involves somebody else's computers. We're not gonna argue with that.
We have a lot of excellent computers in a lot of Google data centers. That's not the point. Uh, the point is that we're just, cloud is not just somebody else's computer, even though it involves somebody else's computers.
There's a lot of stuff that was built the cloud native way that just gives you results better and faster, but different. And that part is the one, the reason we hate this line so much. Yeah.
I'm the same way. I don't, to me that's an a line, and I'm not degrading anyone, but if someone says that probably means they're doing things the way they did it in the data center in the cloud. Yes.
Or they haven't yet seen the other way other things they can do in the cloud that you couldn't practically have done in your own data center because of the resources and service yet. So it's just a matter of learning those things. Yes.
In the world, in the world I come from with, with some of the network security stuff, this, this manifestation is, there's a very clear line. Um, and I'm not gonna name any company names, but I will say that for example, there's, there's one partner, uh, like one, one manufacturer that I've worked with for Mm-Hmm. For many years.
And, um, another company came up later and, and they had, you know, cloud native architectures, and the first company said, well, we have cloud native architectures. We run on microservices, we're using ai, we're doing this, and we're doing that. Mm-Hmm.
Um, and I, I, you know, still co-manage some environments in both of these and other vendor spaces, right? So I'm just gonna look at these two, this one. Um, the first one who's been in business for a long time and supposedly is running on microservices.
I still get notifications of massive outages, planned outages for up for updates. Mm-Hmm mm-Hmm. Of the entire sub, like whole sections of the system.
Just like, that's Like the opposite of Yeah, that's the opposite of I know the Idea. I know. But it, it's funny because it's like, there's this blurring of the lines, think about The analogy.
It's almost like you bought a gas car, but they say you have to buy a manu removal service, and you say, that's not a horse. You sold me a car. And they say, Nope, Manu removal service is mandatory.
And it's like, uh, what? Wait, wait, how? What?
Yep. So it, it's basically the equivalent of, of they have taken something that was on-prem that they had for, you know, many, many years and they lifted up into the cloud without retooling it for such, um, compared to the company that just came along later, built the entire architecture in a cloud native way. And there's, you know, you might, you might go in and maybe for a few seconds, there's a weird blip when they click a button in like one interface, uh, and, and a change log, and they push updates every, you know, um, every couple of weeks.
So it's like, it manifests in very tangible ways to us that are consuming those technologies. Yes. And we still have, yeah.
I mean, I, I, I, without naming the names, I do recall, um, a similar conversation with somebody actually in a sim land, in, in a security information management land when somebody build a cloud sim. But they had to do a lot of this type of, wait, wait, wait, we need to buy servers. And it's like, does Google Workspace or Office 365 or something tells you don't edit this doc, we need to buy the servers.
We need to buy the servers. Wait, wait, wait, we're gonna buy servers. Okay.
We're installing them. Like, that's not how cloud works. And if you, if your cloud service requires you to have advanced notice for buying servers, then it's really not a cloud service.
Yeah. So speaking of sim, because when, uh, when I first met you, Anton, I think you were, you were coming out of the PCI world and into a lot of, um, sim tooling that, you know, blossomed into other stuff. I think throughout your time, um, at Gartner, are you, are you working on anything like that in your current, do you advise on that with, with clients who are looking to do that type of data analysis?
And is that in the cloud? Is it, what are you, what are you doing in that space now? So I do deal with, um, I, I mean obviously Google, uh, owns Chronicle, Google Cloud owns Chronicle, and that's a pretty good, uh, software service sim very modern.
And, you know, I can say other good things without, but I won't, because again, I'm not trying to be a vendor here. Uh, so I do deal with how clients are evolving to use, uh, more modern tooling, evolving to use more maybe software service, uh, type tooling for, for si. I mean, even sim migration from on-premise to cloud is kind of a long journey because, uh, if I recall correctly, the first truly cloud native si or si like low collection platform was built roughly in 2013, 14.
That was Sumo Logic, right? No, that's, and that's told, that's a long time ago. And even today, we have people who kind of struggle with mostly on prey thinking for what they, what they, what they use the SIM for.
Uh, or you have people with kind of like a fake cloud sim, which is basically the, the vendor lift and shift their own SIM to a public cloud and then sells the result as a, as a cloud service, which affects how it operates, it affects what you can do with it and what you can do with it. But apart from that, apart from this text stack side, I also see a lot of people transforming their security operations centers. Not just sims, but like transforming the SecOps to a more modern model, maybe more engineering led model when they can scale better.
And a lot of, for a lot of this, we end up relying on some of the Google lessons of how, uh, Google did things, uh, good number of years ago and what it, what, what it came out to be. Now, an initial take that people had is when we shared how we do things, they say, well, great story, but we are not Google. So like, why does any of this apply to us?
And that was before I joined. And then after I joined, I kind of said, wait a second. We still have something good, but we need to, uh, we need to make it portable.
So what we now call autonomic security operations or as o um, is ultimately this portable version of some of our detection response lessons, which are usable by others. And autonomic by the way, does not mean without humans. It's kind of more like into autonomic nervous system and, and the adaptability and stuff, it's not about like fire the humans, but the point is that it's the lessons that are made portable, and they can be used by more people.
And that to me comes up a lot because, um, many, many organizations may modernize a tooling, but the processes for detection response is still very much, give me big screen, give me a SOC level one analyst, give me a level two, give me an escalation. Oh no, this all very expensive. I need to use an MSSP.
Like, like a lot of this is still in this bucket. And ultimately that's not the only choice. And there are other choices.
And we try to enlighten and educate and inform people with the as o model so that they know there are other ways to do it. And when people hear about some of the results and some of the scaling humans using automation that we achieved, they, they do realize that, wait a second, that's not the only way to go. So that's been occupying, uh, some part of my time, for sure.
Very good. Well, I wish we had about another hour and a half, two and a half days, I think actually would be better to sit down and talk, kinda like we used to do at those conferences. Maybe we'll be at those again soon, run into each other.
Um, Anton's been fantastic. We hope you'll come back and chat with us. Um, we're always interested in sort of what conversations we're all having, ensuring that amongst each other and with, with our customers, our, you know, our own infrastructure, et cetera.
It's been super helpful. So thank you for being with us. Where can people find out about your podcast?
Uh, well, it's, um, there's a bit of a story there. So our podcast is called Cloud Security Podcast by Google. And, um, and we had a lot of really cool naming ideas for a podcast.
We did not set out to name our podcast cloud security podcast, but I, I mean, I swear it is not what we wanted, but, um, you get an A for clarity though. It's true. Uh, yes.
But this is what the name, and this is what the name and team said, because ultimately they said all, all your cool quirky, funny names like weathering security and whatnot, you can take them out and keep them as souvenirs for your home use. But if it's our podcast, you're gonna get a cloud security podcast name, because what you want to do is a cloud security podcast. At which point we said, this is boring.
And they said, but it's very factual, at which point we surrendered. And that's why, that's how we ended up the, the proud owners of cloud security podcast by Google. Very creative name.
I think. Well, people would be able to figure out where to find it. Just Google it right There.
Is that, yes. Very good. So many thoughts there.
Who would've Thought, what a way to conclude the conversation. Just Google It. Yeah.
And Anton, I, I will find that blog with the, this you said the, the, the mental map for CSOs. Mental, mental, yes. For cloud.
So I will, um, yeah, the mental model. So I'm gonna find that too, and we'll link that as well here. Awesome.
That'd be super helpful. Well, great. Coming back again soon, Anton.
Jennifer, any part of burning thoughts before we wrap things up here? Ooh, you're good. I, I'll make one, one part thought is probably back to cloud use.
While AI and LLMs and all this exciting stuff is well exciting, um, I still see a lot of companies that deal for them, for whom the cloud is the new technology, not LLM. And, uh, to me, I, I am very happy to be involved with some of the stuff around security and ai, but I wanna never lose sight of the fact that for some companies, 2023 is when they first saw cloud. Yeah.
And we, they need help and they need to do things secure in a secure manner and a way that doesn't lead them to breaches in the next, in the coming years. The journey is all relative to where you are, right? Yes, exactly.
Exactly. Thanks everybody for joining us. Uh, we'll be back.
Another great episode of CISO Talk. We'll see you again soon.



