EP262 Freedom, Responsibility, and the Federated Guardrails: A New Model for Modern Security

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here as ever, myself, Tim Peacock, the senior PM for a bunch of stuff in Google SecOps, and of course, Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. If you enjoy our content and want it delivered to you piping hot every Monday, please please do hit that subscribe button on your podcasting app of choice. You can find the show, follow us, and argue with the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page, and of course, at our website, cloud.withgoogle.com/cloudsecurity/podcast. Finally, you can find us at youtube.com/@cloudsecpodcast. Anton, what are we talking about today?

So we are taking a very much needed break from detection response And AI. Well, AI would make an appearance, of course, because, hey, look at the date. It's 2026.

It's 2026. We can't not.

We can't not AI. But it is a topic that bothers a lot of people, including listeners, including their bosses, including many clients of cloud. Namely, how do you organize security for the modern era, for the cloud age, for the AI age?

Not easy.

For the AI-native employees and customers, A lot of this is calling for a lot of changes. And as we know, in our beloved domain of cyber, there's a lot of resistance to change.

So much resistance to change.

Yes. And some people complain about how your knowledge would be obsolete if you take a break for a year. And other people say, no, come on, 1996 is still here. I can do the policy thing and I can do the—

Why do you think our field is more resistant to change than others? Do you think it's because so much of our decisions are fear-based, and fear-based decisions revert to more conservative patterns of thought. And I say conservative with a small c.

I am actually not sure that our field is more resistant to change. As you recall, I made references to IT inertia as being the most powerful force in the universe.

Yes.

It may be that we are no less resistant to change than our IT brothers and sisters.

Oh, are we not special? We're just IT?

In the sense of liking the old ways. Security is probably more akin to operations than, like, developers who seem to be more mobile. This gets very philosophical very quickly, I think.

And very philosophical off the track of today's episode.

And there's that.

And so I think what Waffles is trying to tell me here is, Tim, you and Anton should turn things over to today's guest. Today we're joined by Alex Schulman, the CISO at Kraken Technologies. Alex, thank you for joining us.

Thanks for having me.

We want to talk about centralized security and how it's not serving us that well anymore. You work at a company that's super cloud-native, utility-quality AI. And so, can you talk about how, for your company, the changes of cloud, SaaS, and AI have made the traditional centralized security model just not sustainable?

Yes. And indeed, traditional centralized security, where there is one team that approves every move for everyone, is now simply impossible and insufficient. There are 2 reasons for this. First, cloud and AI development just happens faster than before, and controlling each and every step for everyone becomes impossible. Second, new threats are emerging all the time, and they're exploited faster than before. As a result, security teams cannot be this bottleneck. They cannot be approving everything. And also, security cannot be offloaded to one centralized team. But security needs to be done by everyone and all the time. And this is why we call this model security with distributed ownership. The security team is providing the tools, the metrics, the guidance, the support, and everything that is needed to empower the teams. But we need everyone to be the security champion for their domain. And I believe that that's the model that we need to adopt to provide this sustainable security support for cloud and AI.

But, I mean, this makes sense. And I think Tim, me, many people working for modern companies, tech companies, would be nodding and saying, yep, yep, that makes sense. But it's very clear to us, kind of to put our cloud hats on, that some of the clients, some of the large companies kind of persist, not only that centralization is still right, But it's literally the only way. They don't have anything. Like, I had a debate yesterday on Twitter with somebody about shadow AI policy, and this topic would come up, I'm sure, in our show. And they said, no, if 90% of users are breaking the policy, they're still wrong. It's not the policy. Policy is right. Ban consumer-grade AI at the company. And if you violate the policy, even if 95% of the users do it, they're in the wrong. I think people do say that, and people mean it. So, if I may ask, how do you talk at parties, talk with such people? How do you say, hi, I'm from this company, we do this, and they look at you with big eyes and say, no? Like—

Yes, our goal as security leaders is to optimize the security management for the specific company and the specific culture.

Mm-hmm.

There is no one-size-fits-all. This is why each and every company needs to find the best approach to manage this. For some companies, the centralized approach may be the best one, because if this is what they've been doing for many years, most probably, their developers are not thinking about security, and they got used to this model where security is offloaded to the centralized team. And then, it is not that easy to change this culture and build something else. In our case, since the company was established, the fundamental principles that are being used to operate are freedom and responsibility and get things done. So, these are just part of our culture and part of the values. And they support this model of distributed security ownership, because it was never managed in a different way before. Mm-hmm.

Yep.

And since the beginning of the company, engineers were the security champions of the environments. So, as we are growing our security organization, we're focusing on how to support this, how to give everyone this guidance and the support that they need to do the right thing. But we're working with our culture, and we're empowering everyone in what we have. So, that's why I think what you're saying, this may be the right thing for one company, But for us, we need this distributed security, distributed security ownership, and just building upon what we have and supporting everyone on this journey.

You know, Anton, that security person you were arguing with on Twitter, they remind me many episodes ago. Do you remember when we had the episode about shovels versus backhoes? That person sounds like they were trying to dig a ditch with their fingernails and told you that you were silly for using a hydraulically powered backhoe.

No, I feel it was more of a top-down. They see top-down centralized as the law of physics, not even the law of the land, not the legal law.

But there are no laws of physics in security.

You know that, I know that, but people who wrote policies since the 1990s assume that it's the only truth. And I feel like we may trigger them. Yeah, policy, policy.

Yeah.

Okay, so let's go to the next.

Yeah, man. Sorry, I'm just so hung up on that. But Alex, you said something really interesting in there. You said freedom and responsibility. And this is like, I don't know, to shift metaphors away from digging holes, this is like the, I don't know, libertarian security argument. So, could you expand on what that means and help people understand maybe out of the highly regulated top-down to this libertarian freedom and responsibility world?

So, first of all, freedom and responsibility doesn't mean that people are not doing security. It just means that it is their responsibility.

Hmm.

And let me maybe give you an example, also kind of my lessons learned, because I also, I'm in my previous roles, I worked for Citibank, EY. I'm well familiar with the centralized approach. I can see the value of the centralized approach. It is just, we have different technologies now and we need to adjust it to modern environments. But let me illustrate the power of this distributed security ownership. when I just joined Kraken as NEC. So, I started with prioritizing the risks, and then I brought together all the key leaders and stakeholders to meet in person in one room and discuss all these findings and to strategize and prioritize, because this is what I'm expected to do as part of my role, and I will continue doing this. But at the same time, we had amazing individuals outside of the security organization They were not aware of these discussions. They didn't review my spreadsheets. They just saw some of these issues, and they stepped in, and they addressed some of them. They did this not because I asked them to do so. We never discussed this with them. They just took the freedom to do what they felt is the right thing to do.

Hmm.

And indeed, it was the right thing to do. And even more, they took the responsibility, and they resolved some additional issues that they also thought that they can resolve. And this will strengthen our controls. And this shows the power of this distributed security model. Because when everyone is thinking about security, and when people feel responsible and accountable, they're just spending more time on these topics.

Mm-hmm.

They can do more, they can do this better. And this is the true power of this distributed model because instead of having 10 security champions, we have thousands of security champions. But I believe that in this new world where we have threats coming our way all the time, we have no choice. Otherwise, we're just outnumbered. Because if you look at nation-state, they have very powerful teams. Oh, yeah.

Oh, yeah.

Obviously, companies are just outnumbered if they will be limited to these centralized security teams. This is why we need everyone to be thinking about security all the time. We need to give them the tools, we need to support them. But both because kind of cyber defense now is a critical topic for everyone, and because cyber awareness is so critical, and because engineers know their systems better.

Mm-hmm.

Any centralized attempt to tell engineers what to do will be limiting. Because those who are building these systems, they just know them much better than those who are reviewing them. And that's the true power of this distributed model. It cannot come instead of this centralized compliance, risk management, strategy management, prioritization, cyber defense. But we need to have both. We need to empower everyone to do the right thing, and we need to give them the tools, the technologies, the metrics, And also, this ability to constantly see these things. And we need also to have this security strategy prioritization, certain initiatives that we think are critical. And we need to combine this approach of kind of the CISO team promoting certain things and distributed security ownership with everyone thinking about this all the time.

I think I strongly buy the argument that, In the modern distributed world, a distributed model makes a lot more sense. And I think I've actually reasoned my way into being a little more sympathetic for the 1990s policy people when I think about what computing used to look like with mainframes and thin terminals connected to them. So maybe I'm having a moment of empathy, listeners, for the policy brain out there, but I do still think they need to get with the programme.

And these models were okay back then.

Yeah.

Let's give everyone this credit, that when IT was centralized and centrally managed for everyone, this was the right model. And in certain aspects, it is still the right model. And for some organizations, it is the right model. But for other organizations, we may benefit from this power of engineers thinking about this, because let's give them the credit. They're smart. They are.

That's why they're engineers.

Yes.

I mean, I think this is also generational. I feel like we've talked— the conversation that Alex and I had at the conference did mention the whole Gen Z security. And I feel like a lot of this is just really odd because I'm obviously not in Gen Z, but to me, that sounds like common sense that you have to decentralize. But people show up and say, what do you mean? Security team decides on the policy and then enforces it. That's the only way. It's just one of those tricky subjects where it feels like it's seen as common sense by both sides, but the positions are opposite. To me, that means there's some kind of transformation/revolution/crash is coming, because if people continue to assume that centralized is the way, bad things would happen, bad things of some sort would happen to them trying. But okay, let me stop rambling, and I want to kind of ask more of a deeper question about Centralized versus what you define as security with distributed ownership. We sometimes hear centralized versus federated, but is security with distributed ownership the same as federated, or is this a new and different thing?

Can you please better define federated?

Ah, okay, excellent, most excellent.

That is a great response to Anton.

That is a really good subject, and I almost froze for a second because I realized that it's kind I mean, so federated sometimes is used as kind of a placeholder for decentralized, meaning it's defined as not centralized. But in other cases, I feel like federated implies multiple places of control. So, like federation of islands. So, it's either decentralized or islandized. or where there are islands of control but no central authority. Is that better or worse? Did I make it better or worse?

Let's maybe discuss what are the metrics that the security teams need to see. Because I think first, we should be set policy, for example, compliance. We do need to have this cross-organization view on compliance, risk management, And policy, obviously, should be the same policy for the entire organization. Obviously, we need everyone to read these policies, and we need them to implement this by themselves.

Mm-hmm.

Then, also, risk management, because organizations need to know what are their bigger risks. Lower risks, like small misconfigurations, I think that in the future, maybe, we can decentralize this as well. But this high-level view on policy compliance, risk management, and then the 911 number, because people may be able to handle certain issues or certain misconfigurations. But if there is indeed something that is happening, we need to bring professionals, first in-house professionals, then additional support is needed. So, exactly like in the medical field, if I'm just coughing and I'm not in danger, I don't need to go to a doctor, but if my health is at risk, I need to call 911. It's the same. So, I think these are the things that still require a lot of investment from the security teams.

Mm-hmm.

But then, also giving everyone this guidance on what is the right thing to do. This is also something that the security team should be promoting because, freedom and responsibility, but people may not know what's the right thing to do. So, how are we giving everyone this guidance and the support to know what is the right thing to do? We need to give everyone this visibility. This is what is happening in your environments. This is how we are categorizing these things. Now, as part of your quality management of your product, You need to address all of these things. You may have certain freedom to select the priorities, especially, let's say, for medium-risk items, but it is the role of the security team to help everyone with these metrics.

You might, listeners, think, gosh, this sounds a lot like the SRE philosophy of, we're going to build tools for observability and work with teams to achieve reliability outcomes. This sounds pretty similar, honestly, and I like that about this.

It is small in a way. Yes, I agree with you.

Yeah.

I think that we call it a hybrid. I feel like in some of our materials, Google materials, we call this approach hybrid because it has certain very clear centralized elements. And I'm sure in this show, we'll get to what is centralized. You gave the 911 example. Like, if it's an IR team or policy writing, they're absolutely centralized. We are not saying Hey guys, you have a little team of 3 people, just write your own policy. Yeah, it's okay. You'd be fine. Like, nobody's doing that. So there's no responsive, personal, distributed libertarian approach to some of that. So, but I think enough of that. Let's talk about AI because, hey, it's 2026.

So you mentioned being AI native. How does AI change this hybrid model? And does Does AI maybe augur for a return to centralization, or does it augur instead for even more freedom and responsibility? Which way does it push us?

Yeah. So, let's maybe start with cloud because I feel that AI is almost an extension of cloud. Let's learn from our cloud journey, and now let's apply it to AI and potentially do it better. And there are certain similarities between the two. So, let's start with cloud-native development. And I think cloud-native development changed how people think about infrastructure. For those who are kind of just developing in the cloud, they're just additional API calls. They're not doing the separation between infrastructure and application. It is all one kind of application, and they're managing all of this together. AI is also going to bring an additional change of speed of development. I think how AI-native development practices are still shaping right now, but we know that software will be developed faster.

Yeah.

So, in a way, certain things will be much, much easier for developers. But I think this is where we have this opportunity to make quality and security central components of AI-native development, because other things are just much easier. So, let's give more guidance on what's the meaning of quality and security for cloud and AI, and help everyone to pay more attention to these topics. And I think this is where we should invest more, both as an industry and as security leaders, building better metrics. Let me give you maybe one additional example from cloud that most probably all of you are familiar with, but we can learn a lot from it. When it comes to cloud misconfigurations, these are not—

Everybody's favorite topic on our show.

Yes. Oh, yes.

But I think they're showing how we need to change our thinking, because some of the cloud misconfigurations, let's say exposed buckets, are more critical than certain vulnerabilities. because they may lead to immediate exposure that we need to immediately resolve. So, we need to start handling these misconfigurations and vulnerabilities together as one thing, helping everyone to prioritize because, for example, most of the legacy policies, they're only addressing vulnerabilities. They're not addressing misconfigurations. And then, We need to give this better guidance to our developers what to resolve. Because if we have all this together, cloud misconfigurations and vulnerabilities, what should our developers be jumping to resolve first?

Hmm.

So, we need to put this as part of the same ranking methodology and give everyone this guidance. Okay, critical should be resolved within this period of time, high within this period of time. without breaking this to different types of vulnerabilities versus misconfigurations. It's not a competition. It's about just improving, constantly improving the environments. But this is where we need to do more, both as an industry agreeing, okay, these are our new metrics. We're putting all these together, and then giving everyone these tools to constantly see these things, because they're also changing. So, kind of this more clear guidance is needed, both on cloud, and then now with AI, we also need to give better guidance on all of the AI violations. I think this space is still evolving, but we need to put all of this as part of the same picture that is easy to understand and manage.

Yeah.

So, Anton's gonna ask, I think, our last question, which actually is my favorite, but he gets to ask it today. Lucky you, Anton. But it's a very, like, Motorcycle Diaries question, I think, is actually where this is going to go. So, Anton, can you ask the Motorcycle Diaries question?

I think you should just ask it because I'm okay. I would survive without asking one more question. So just go ahead. This is too much fun.

I get to ask it? Okay.

Yeah, just go and ask it.

So one of the things that we talked about in the prep for this episode, listeners, is the idea of security as quality. And so, the idea here is maybe that a security-unaware developer is actually just a bad developer, or that they lack quality. And so, how do you— it sounds like your org started this way, but what advice would you give to another org, perhaps, to help shift their mentality into security awareness is quality, or writing secure code is quality code?

Yes, great question. And first of all, this is not one and done. This topic requires and will require continuous efforts from everyone, both the security teams and engineers.

Hmm.

But I think there are 3 components to this. One, we need security to be part of engineering standards and best practices. So, these are not just policies written in legal language, but practical standards and templates for developers to adopt. Then, we need to give everyone this continuous, real-time visibility and metrics. These should be accessible, easy to use, and they should be combining all the data points that we discussed on cloud misconfigurations, AI violations, vulnerabilities. All of this is part of one system that is easy to use, and it is accessible for developers. It is not a security product that is used just by the security team. It's for everyone. And then, we need this culture of distributed security ownership. where engineers are empowered to manage all of these things that they may be seeing through these systems in real time. We need them to act fast. We need to trust them, but we need to give them the tools, the guidance, and this continuous support, because it's not just one metric or one policy sentence that will solve it all. It is about being with them, Helping them and constantly adjusting our tools and capabilities and analytics, everything that's involved. And our tools are also evolving. So that's also the role of the security team, to constantly improve the security tooling and the dashboards and the analytics that they're providing for everyone to better address this topic. Yeah, it's not an easy answer.

Yeah, not easy.

Hard work for everyone. As long as we'll have software systems.

So, I want to switch gears before we close with the final question. Is there a short way to answer what stays central no matter what? I mean, you already figured out IR, quote unquote, 9/11 service in this case, and of course, policy writing. But is there a short list of things that is in any model must be central or doom is imminent?

Yeah, as we discussed, so, these are the risk management, the compliance, security engineering, cyber defense, I would define this as things that require specialized expertise in addition to engineering, right? So, for example, engineers can own the security for the corresponding areas, but we cannot expect them to be on top of threat intelligence or new compliance developments. So, Areas that will require these additional skills will continue being part of the kind of this security team that may be compliance, privacy, risk management, and cyber defense. So, I think we will need these specialized skills and specialized team members, but their role is to support all the rest because without this involvement of all the rest, without them being the security champions and mini cyber defenders, and understanding the environments and thinking about these topics, it will be very difficult to manage things, especially because our threat landscape is constantly evolving. And we want people to be curious. We want them to be learning about this, and we want to support them in the best way we can.

So, I hate to do it, and I'm glad that Anton managed to sneak in one more question, but I have to ask our traditional closing questions. One, do you have a tip to help people imbue their engineering teams with more responsibility and freedom? And then 2, do you have recommended reading? And that recommended reading could be almost anything from Mary Oliver to Mary Shelley, just not Anton's blog.

Thanks. These are tough questions. Actually, I can't answer both in one sentence. I think, first reading, just read all the time because you don't just catching up on cyber news. It's just, I would say maybe just reading something every day is helpful, whether it's Anton's blog or something else.

Yes.

Be curious, learn, and read. So maybe let me close with this. I would recommend both sides to do more of the following. For the security teams, read more about engineering, understand what engineering teams are doing, be curious about the architectures, that your product teams are building. And for the product and engineering teams, read more about cyber, understand what may be impacting your products, and be curious about these areas as well. So just, you know, learn something new about the area of your peers every day. And I think that's how we can jointly build better and more secure systems.

I think, Alex, that is great advice. Thank you so much for joining us today.

Thank you. Thanks for having me.

And now we are at time. Thank you very much for listening and, of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast by Google.