EP258 Why Your Security Strategy Needs an Immune System, Not a Fortress with Royal Hansen

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here as ever are myself, Tim Peacock, the PM for, well, a bunch of stuff on Google SecOps, and of course, Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we have a super fun show today. We are talking about biology. We're talking about fighter pilots. What are we doing today?

We are talking about the future of security.

Oh, a small topic.

Okay, so for some people, it's a distant future. For others, maybe it's an immediate future, but it is definitely the future. And I feel like, at the risk of going for a spoiler, I feel like maybe we shifted from the compliance mentality to engineering mentality, but our guest thinks that it's time for another shift. But where we are shifting is really interesting, and I'm not gonna spoil that part.

That's very William Gibson of you to be like, this is the future for some people tomorrow and the future for other people. Much more in the future. I like that. I mean, I don't want to spoil anything for this episode, so maybe listeners, without any further ado, and sorry for the absence of a corgi today, I'm in the office recording studio, as you can see. Let's turn things over to today's guest. Today we're joined by Royal Hanson, VP of Engineering here at Google, former CISO of Alphabet. Royal, thank you so much for joining us today. You've argued in the past that we need to move away from this godlike designer model of security, and while that's like super upsetting to Anton, given his view of himself. I think what you advocate is that we would move towards an almost biological model for security. Could you explain that distinction and how that's especially relevant in a world of cloud and AI?

Yeah, I'm super excited for this, and thank you for having me because it is something I've been thinking a lot about, and I actually have been learning a lot. And I have a few examples I wanted to give, and hopefully, this could be the beginning of a dialogue as an industry. But, you know, first, Even though now it must feel even more like that with AI and cloud, and you can have agents and tools, the world is super dynamic, right? The idea that you have a deterministic view of every use case that your user or your vendors or your suppliers or your tech implements, it's sort of ridiculous, right? The idea that you could possibly do that. Yeah. So, I thought, okay, fine. We're no longer building bridges that are going to sit there for 100 years with roughly the same use patterns. What if we look to biology, which lives and breathes in exactly the way we just talked about? Every day your body or the ecosystem is different. It changes all the time. Species come and go. Cells are born and die. And I think, in a weird way, it's forcing us to confront the fact that, actually, at any big organization, we were already living in that world. We do not have, we never had, at least in sort of my career, perfect or deterministic visibility to all data, all services, at all times.

But I always assumed naively that engineering-led mindset and engineering will just build things the right way, build things securely, is progress compared to the previous wave of thinking where people thought about, like, checklists and compliance. So, it's interesting that when we talk about this, and we're going to touch other deep ideas here at this episode, when people moved from compliance auditor-led security to engineering-led security, It was supposed to be a big improvement. But you're hinting that while it was a big improvement, the next wave is coming, and we need to move beyond that. Is that fair? Or is it— am I pushing it too far?

No, no, it's such a good point. Because I actually, you know, I'm thinking back, you know, we're probably, you know, similar phases of this industry that we've lived through. When I started, it was much more engineering. I think it became more compliance because the world and every industry and every sector and that complexity we just talked about grew. And so you really couldn't engineer everything end-to-end like you could when I, you know, late '90s, you build a website, right? You could do that. You could engineer that. And little by little. So I think you make a good point. I think it became more compliance and checklist-heavy As a second phase. And now we're back to where, to your point, we need it to be engineering. Like, don't get me wrong. What I'm— well, by engineering, I mean technically sophisticated. You gotta have abstraction layers, you gotta have architectures, you gotta have design. But I don't think you can think of the entire system as one. You think of it as many interrelated or interactive subsystems. You know, so think about one example. Let's just get started with is that in an ecosystem, in a, you know, in a, in a ecologically, there are vultures and you always think, okay, what do these vultures do? Right. But the truth is the vulture, when it goes and eats the dead bodies that become loaded with bacteria, they're like massive cleaning engines.

Yep.

They don't care about the rest of the ecosystem. They don't think about it, know about it, worry about it, but they eat that dead stuff. What if, to the spirit of this, instead of thinking, okay, I gotta clean up my access for my team, right? Or, you know, my group management, or I've gotta clean up the memory that's being used. You think pre-systems that did memory management for you. And instead, we wrote vultures for the environment that all they did was fly around internally looking for unused data, unused privilege, unused group membership. And they were like, you know, think like almost like The Matrix, like those little workers doing their job. But that's all they did, right? This is the point. They don't actually solve the entire problem, but they play their role in a dynamic ecosystem. Does that make sense?

I really like that because I have so many conversations with security people where, you know, we'll propose a control or propose an intervention. They'll say that doesn't solve everything, so we shouldn't do it. But a vulture doesn't solve everything. They solve a particular problem of roadkill and decomposing bodies, and that's super valuable and we should do that. I really like that.

And I think it also combines the best from engineering side and the biology side where it's not a deterministic, we'll build it from absolutely the strongest concrete available on the planet and is going to last for 1,000 years, but also combines good design with biological elements, if it makes sense.

Exactly. That's exactly right. And it works at different layers, right? That's the other thing that I find very interesting is take the immune system. We talk about this in a lot of our own work and how the cloud functions this way. Sadly, because my youngest son has been quite sick with a sort of a chronic illness, I've learned a lot more about the immune system. This is some sort of autoimmune. And I didn't realize this, but the immune system when you're born, particularly the T and B cells, these are sort of the adaptive immune system, they go through this very sophisticated process of using antibodies or using sort of T and B cells to match up with all the parts of your body, every different kind of cell and protein. And then they almost throw those away so that you don't react to it in the future. And so that you know that when it sees a new, you know, body, so it generates an antibody because it's never seen it before. Because it knows what the body is, but not— it doesn't know it like in its head. It knows it because when you were born and in your first few years, it matched up with all of those self-types and then dropped them so that everything else it began to generate was defending you. And so, again, I think the spirit of that, think of a lot of our anomaly detection, which we— or think of our firewall rule, like, where we tried to enumerate everything. What if we had systems that knew just— and that's actually what AI does incredibly well. AI can tell you, that's normal. I see it all the time. I'm just not going to react to it anymore. And I start to only react to the anomalies. And then you think about the chess games like DeepMind, you can get finer and finer signals on these novel attacks.

Yep. And it also reminds us that people who are kind of the best of the best engineers or architects who are trying to build a system that's going to be strong and robust occasionally miss on the resilience aspect. And this is kind of where I want to go next in our conversation.

That's a great point.

Yeah.

I have not really spent that much time thinking about robust versus resilient, but our preliminary conversations made me think that it's sort of like a castle or a palace or some other building built out of the most strongest material may be robust, but the immune system is not robust. It's resilient. But also, telling people, telling security leaders, robust is not your friend, is hard for me. Like, it's hard for me to say, you have a chance to build the strongest possible building. Don't do that. Like, I'm like, ah, what do you mean? Like, how do you do that? How do you explain that resilient is better? How do you shift the focus from robustness to resilience?

You know where I learned this? So, at Goldman Sachs, I ran business continuity. And it was a wonderful experience to complement my security history because, to your point, that was the job. It wasn't a side effect. That was the job. And the company realized pretty early on that resilience was going to be a commercial asset and not just a thing you pulled off, to your point, when you need it, you know, when you— when this scenario occurred. And so, as I got to know more about the business continuity and disaster recovery fields, what I realized is you want options. And particularly when you come out of the financial services industry, you want as many options as you can, you know, reasonably buy. Because scenarios— you know this from the— what's the famous saying? No plan survives contact with the enemy. That's true of security as well. And so, what I wanna do is that, you know, the internet's a good example, right? The routes are almost infinite.

Mm-hmm.

But the same is true of access to data. Think about how much stuff we break because we over-instrument the privilege. What I need is the break glass that gets me through, even if it's in a deprecated state. So, as an example, in the BCP world, we wanted to say, do I have a team outside of New York City who can do this function if the island of Manhattan were eliminated? Maybe they can't do it perfectly, but they can do it in a deprecated state. So, I need the tech for that, right? I need remote access. I need the data access to be set up. Just forces you to think not And even our kill chain work sometimes falls into this. We assume we can imagine every adversary's kill chain. The truth is living off the land was a great example. People figured it out as they went. We need to do the same thing on our side. There's a bit of figuring it out as we go that needs to be true. And so, AI, again, I think AI is a really great asset here. It's going to come up with ideas that we never imagined. But only if you've built the capabilities, options, capabilities. So, it's not to your point that we're throwing away the architecture, but we're not— the architecture or the engineering is not holistic, it's modular. And so, to me, that's the real key. And I think, look, Kubernetes has done a good job with this. You know, the way we do some of the VPC work, we can't— I mean, like, you see it emerging. So, I don't think this is like— It's not like nobody's thinking this way, but they're not learning from the biological examples. So, for instance, blood-brain barrier, right? We talk about this all the time. What's the equivalent of that in a cloud or enterprise system? They say, I don't care whatever happens, toxins cannot cross this barrier, and I'm willing to live with an entirely different— administrative system for it, but I want that to be an invariant and true.

It seems almost as if we've moved into the world where that's going to be impossible to achieve with models and prompt interactions, where we've gone back to like the 1950s telephone network where the data plane and the control plane are exactly the same. So when you're looking at the AI world, how are we possibly going to achieve LLM interaction pattern for a blood-brain barrier or a data control plane separation even.

Yeah, I think this is where agents are actually more the future than the model, right? Like the foundational models will play their role, but to your point, the orchestration of agents, the MCP protocols by industry or function will begin to provide the kind of things you're describing. So think about financial systems. That would be one example where, what is it? Double-book accounting. I'm not an accountant, but you have this sort of—

Double-entry bookkeeping.

Yeah. Like, what's the equivalent there from an agentic perspective such that I know this agent cannot write to the secondary ledger, right? And so, I think, yes, you are right that the semantics and the code have blurred the line. But that, in a way, is an asset because now we can write controls in the semantics of the risk domain. finance, HR, healthcare, power, instead of writing it in the domain of software languages, which always required a translation layer through which attackers drove a bunch of buses, if we're honest.

I mean, this does make me kind of excited, but also a little nervous, to be honest, because This one is probably something that to me will easily set the easier said than done prize. This is just something that conceptually we all agree, but when I try to decompose it and try to see, is there any kind of biological primitives for these agents, like, I don't know, time-bound access or these impenetrable barriers? Basically, I don't know, zero trust for agents, or is this something that's radically new for the world of autonomous AI and autonomous actions? This to me is sort of like maybe a fun side of the house, fun side of the discussion.

It is. And like, back to where I started, I think, and this is true of biological history or analogy, evolution, whatever you want to use, we're already living in this world. It's not a decision we made, right? If you think about the complexities and the scale of a lot of our systems. We're already there. I'm just talking about beginning to use the lessons from another domain that has literally 4 billion years of experience to inform the abstractions we might use and the degree of confidence. Because there's the other thing about it, you don't need everything to be Think of your gut. It's a porous— like, it's interesting, your skin is porous in one way, your gut is porous in another way for different reasons. And they both provide immunological benefits, but they also have different functional requirements. And so, to me, again, it's not— we're already living there, like cloud, AI, agents, everything you've talked about.

Mm-hmm.

But my fear is that our industry will go try and draw up in sequential fashion every use case and then deterministically, to your earlier point, figure it out. Instead of saying, what are the primary capabilities in this ecosystem that I already rely on? And what do I need to do to make them more fit for purpose, for resilience, for scalability, for all these other things? So, I don't mean it to sound dismissive of engineering. I mean to say it's a new set of tools in the way we design things and even to talk to each other, right? To communicate.

I think it's dismissive to perfectionists, which I think we should dismiss the perfectionists. I feel like this is the—

They'll hate that.

Really? Yeah, that's fine. But it's dismissive of perfectionists. Yeah.

Yeah.

Because biology does not operate at 100 or 0% in anything.

Yep. But this would trigger the auditors.

Oh, go ahead, Anton.

I just want to trigger the auditors myself. Sorry.

I want to follow up on something you said there where, you know, life has had 4 billion years to figure this out. We've been dealing with LLMs for barely 4 years. And so how do we, how do we do this thing which takes billions of years in the span of not billions of years?

All the more reason to borrow from those quickly. And I think if you go talk to the DeepMind people, it's actually, I learned a lot of this from Demis and the team early on when I first met them. And I realized, you know, A, their primary goal was science at digital speed.

Yeah.

So every one of their use cases was actually a biological or sort of natural science use case. So when they did AlphaFold, There's a great talk from Demis at the Institute for Advanced Studies, if people want to go look it up, and maybe we could put it in there, where he talks about how the real trick with AI is to find these invariants or control, large control, and maybe that's like what he would say, like just constraints. And then let the thing run.

Hmm.

That's the trick in this is to say, I can't be deterministic. And I can't have a billion constraints. What are the constraints that developed the snail or the human mind or the ocean? And then in which, inside of those constraints, the blast radius was contained, things quickly failed or they succeeded and they evolved. So, to me, that's the idea is in all of it, like financial systems, in cloud systems, In healthcare systems, what are these macro constraints inside of which, to your point, we can let these agents and these AI models kind of make mistakes?

Yeah.

But give them the right reward functions and go and end death. When I didn't want— I would be ashamed not to talk about this. But one thing that we in engineering didn't ever have was death.

Yeah, there's no apoptosis here.

Exactly. So it's a super important part of the health of a body or an ecosystem.

Startups have that.

Startups do have that.

At a more macro level, you're right. But our technical systems, look at all that legacy. Like, think of our legacy systems as a diseased tissue or a diseased plant type that is ruining the ecosystem. That's true.

Yeah, you're not wrong.

So, I still want to go to the auditor triggering question. And I feel like Where we started is that the compliance mentality, paper checklist, big square boxes, big red pencil, checking the boxes, sort of from before the engineering world, at least to me, is from before, is still alive. And some of this biological deterministic, indeterministic, can't have zero, can't have 100, is probably immensely triggering to them. I mean, I'm not an auditor. I've made many, many auditor jokes over the years, probably too many. I am a little bit triggered by some of this stuff, but I bet the compliance people are unimaginably triggered by what we are describing here, that we would live in the world where things are a lot more probabilistic, and we're not sure of what will happen. And it's like the immune system, which means that you would either get cured quickly, or slowly, or not at all. How do we even open our mouths and talk to compliance-minded leaders, compliance-minded teams? How do we convince an auditor, maybe a board made of people of that sort, that it's okay.

So look, 3 things. First, why we're doing this.

You have them. Wait, wait, wait, you have an answer. I thought that we would stumble you, Rahil. I thought you'd be like, whoa, I don't know what to do. But you have 3 things.

Look at all these.

You even stumped him a little bit. He was just like, yeah, I got you.

Look at all these gray hairs, Anton. I did— this is not my first rodeo, right? So First, and this is why we're talking, and I love, you know, what you guys do, because the narrative is important. You can't take for granted what you've just talked about. And so we need examples, we need a narrative, but a narrative can be very powerful, actually more powerful. So my argument would be, as we build momentum with this narrative, actually people are going to come up with stuff that we didn't have any idea about, and they, and they will do it better. Second, I think it will be actually kind of liberating. You know how hard— I've lived in only big enterprises for the last 20 years. It is hard. The complexity, the denominators, the asset inventories, the vendor lists, like, it is hard. If this can be slightly liberating to say, hey, can we just acknowledge together that the complexity has gone beyond what a human and a checklist can solve? I actually think then the temperature can go down a second and we can say, okay, how are we going to do that? We're already living there. So there's a, there's a little bit of a release valve. And then third, I love this analogy, but it doesn't always play because not everybody knows what a cobbler is anymore. So shoemaker's children don't have shoes, right, in this little village. We're going to have to use agents to solve the problem you're talking about. So, if I'm an auditor, I'm building agents to do the things we're talking about. I'm going to embrace that non-deterministic but eventual consistency or limits that it will approach. Great. It's a tool. So, to me, narrative precedes it because no one's going to work on this unless they believe it. 2, relieve some of the pressure of the current job, which is almost impossible. And then 3, Get the shoemaker out there and start putting them on your team. Put on the auditor's shoes.

So I want to go back to the death thing, because we accept more or less that biological systems die. And I had this— this is going to sound pretty random, but in high school, I had a chaplain at my school who gave this amazing chapel. 20 years later, I remember him talking about how failure is good and how we should, as students, all experience failure. So, shout-out to you, Peter Emmerman. How do we help organizations get comfortable failing? Like, not everybody can listen to Peter at 9:00 AM on a Thursday. So, how do we achieve allowable failure? Because that's necessary in what you're describing, right?

I've got an answer for this too. So, there you go.

Good.

Well, I worked at Fidelity for a while, and Ned Johnson, who was the sort of, you know, ran the place and big fan of Japan and the kaizen continuous improvement.

Yeah.

But then there was a guy named— I have to get his name, but he wrote a book called Chasing the Rabbit, which was— we could put a link to it as well. But I think the answer is we measure the speed and rate of finding problems and fixing them. Like, that— I think we need to change some of our culture from here's the objective and here's when we met it to How fast did you find the problems and how fast did you fix them? And so, in a way, AI is perfect for this, right? Like, think of what we're doing with Big Sleep and where we're going with Mender. Big Sleep, we're gonna find these things faster and faster, and Mender is the automation to fix. So, we ought to be celebrating that cycle.

Yeah.

Instead of saying, what are these big systems we're gonna build and they'll be perfect? And if they have a problem, we'll all light our hair on fire and hope we come out the other side, right?

So, this is really about shifting our goaling from, like, how many airplanes do we build to how quickly did we make our OODA loops faster? Not just did we have an OODA loop, but are we making them faster over time?

Exactly. Celebrate it, measure it, talk about it.

I wanna stick— maybe I am old. I don't know. It's a weird way to start. Maybe. Maybe I'm old compared to Tim. Fine.

Okay.

So, before Tim goes to the closing question, I wanna to try to do the devil's advocate on behalf of those— I'm not going to say pesky— auditors or people who stick to firm answers to questions that are difficult to answer. So, if people observe the signs of this new world you're describing, observe successful companies move to this more biological approach, to less determinism, and they still insist on certainty, Like, is there one argument I would make? What if that person is my CEO, my CIO, my uber boss, whatever? Then is there one argument I can make to him or her that, hey, I get your desire for certainty, but this, like, what would this be?

The one example I use, because it comes from my history, I suspect we can find it in biology or others. But just because I lived so much time in financial services, I spent time in the card, in the credit card business for a little bit. And I learned that you can make your fraud rate too low.

Yes.

And I realized that people got beat up for the fraud rate being too low. And to your point, Anton, fraud is a big deal in financial services. We're not talking about like, like some sort of corner case. Credit card companies live and breathe. They exist because they get that rate right.

Yeah.

And too little is actually a sign that you're missing the market, you're not doing the right things. So, to me, that's just like— because I actually think we have a harder time, to your point, Anton, convincing people that correctness of code is actually an existential problem for a company. Plenty of companies without correct code that do perfectly well. I'm not suggesting we shouldn't have good code, but there are no banks who miss the range of their fraud rate. They go out of business to your death point. So, I'm sure there are other examples, but that's my sort of tried and true one.

I really like that because you can bring that back to the biology metaphors you were making earlier and say there's a correct rate for genetic mutation, which is non-zero. If you don't mutate, you will not evolve.

Nothing.

That's right. That's exactly right.

Yeah.

Okay, Royal, I can't say how much I've enjoyed this conversation. We've been all over the place, from cellular biology to evolutionary biology to fraud rates. And this is a blast. We could go on for hours, but I have to close the show. And so I have to ask our traditional closing questions. One, do you have a recommended tip to help people reimagine security and start on this journey? And then 2, aside from all the resources you've mentioned already, do you have recommended reading for people?

Yes. Oh gosh. Okay. So first—

Wait, I asked a stumper, Anton. See that? I asked the easy question. I didn't get an answer right away.

I just have to get the link to the book. There's a wonderful book to read.

Yeah.

And we can put it in the link. So, but first on the— I take very seriously Anton's questions about how are we gonna get people over the hump here. And the only way is by playing with experimenting, and being users.

Mm-hmm.

We are so busy doing our job. Nano Banana, you know, NotebookLM, like, figure out how to live your life using these tools. Not because I care whether you know what you look like in the '80s, but because you just have a much more intuitive understanding of the tools and how they can work. So I think one, and, and this, that world is inherently Biological in the way we just talked. So play, play, play, play. It's an incredibly important part of back to Timo's humans. Like play is actually an incredibly important part of a of any species existence. Stack and I will find the name of the book, but it's about life. It's it. We thought when we discovered the genome that this would be the software. of life. It turns out there are these massively complex omics, proteomics, you know, bacteria in the biome. Like, we learned that life is not software expressed in hardware.

Right.

It is in fact an endless combination of constraints, even the way RNA and DNA talk, you know, transcribe. is not done like a robot. It's done because the motion is contained every time you move from nucleotide to nucleotide. It's an incredible book. I'll put it in there.

I will too.

But it's both fascinating, and I think it has a lot of lessons for us.

Incredible. Royal, thank you so much for joining us today. This has been an absolute delight.

Thanks for having me. Let's pick, you know, next year one of these sub-areas, I think, because the other powerful thing is we need to work some of these analogies into more detail. I gave you a few, but I'd love to take a few more. And maybe even we get with the customer in a sector and we say, get in the healthcare or the biotech sector, and we go into it. These would be really neat. So—

That'd be a great idea. Let's do it. And now we are out of 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 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.