Future of EDR: Is It Reason-able to Suggest XDR?

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks so much for joining us today. Your hosts here are myself, Tim Peacock, the product manager for threat detection here in Google Cloud, and Anton Chuvakin, a reformed analyst and member of the cloud security team here at Google. You can find and subscribe to this podcast wherever podcasts are sold and distributed, 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 morning, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, we've got a delightful episode today talking about EDR, XDR, and where that's going in the cloud, don't we?

Yes, and that's a very fun one because frankly, it's not just about like EDR as a technology, its evolution, but it's also about how people actually detect threats. We have a really good segment on how attackers are actually seeking to bypass EDR. This is fascinating, right?

It's not surprising that adversaries would do it, but it is really fun to hear from a practitioner exactly what they're up to these days.

True, true.

And frankly, I've seen enough security vendors, which in my mind are just vendors of software, and they kind of don't always realize they're against the adversary. I think the Cyber Reason team presented on this episode definitely realizes it, But you sometimes see vendors who sort of assume they sell alerting tools, but they don't necessarily assume that the attacker would try to hide, which to me is a little disturbing.

How would you not assume that? Of course an attacker's gonna try to hide. That's their whole MO.

True, true, but they think they sell software first and security software second.

Oh, God.

They don't think they provide security. Like, that to me is kind of at the center of my attention.

I hope you put those people in the bottom left of the quadrant then.

We ask them a lot of tough questions.

That's good. Well, perhaps with that, let's turn it over to our guest today.

And now it's time to welcome our guest, Sam Curry, Chief Security Officer at Cyber Reason and a visiting fellow at National Security Institute. That sounds really cool. Sam is on Twitter. Sam J. Curry is the Twitter handle. So the topic today is EDR, and we're going to have a secret topic that starts with an X a little bit later. EDR was invented back in 2013. Sounds like a whole era ago, and we are now in 2021. So what's your take on a modern EDR? What are the components, capabilities, perhaps what are the challenges?

Is this next-gen EDR? Is that what we're about to get here?

No. Don't do it. Don't next-gen it to me.

There's enough of that. NG this and NG that. You would know better than anyone, but when it first started, it was a very big collection of technologies. I think there were many different architectural ways to approach it and problems to be solved. And I'll get to your question, but in the middle phase, as the industry whittled down and as RFPs became more predictable, It really was endpoint telemetry that was being used to solve back office problems. It was supposed to deliver on some of the use cases we expected to get out of SIEM.

Mm-hmm.

So if you look at SIEM, it does a ton of stuff in an environment, but the stuff that is actually dedicated to finding bad guys in close to real time is what it was doing. It had a little bit of the EPP+, right? Endpoint Protection Platform, your classic antivirus and the suites around it. It was a little bit more than that, but really it was trying to get ahead of intelligent opponents in a race. Today, I would say there's still some diversity in how companies do this. And maybe the best way to think of it is, for those familiar with the MITRE ATT&CK framework, it is how do you stop the pathways and the chains that the attackers follow through an environment using endpoint telemetry primarily, and a little bit extra. But for me, the hallmark of really good EDR is not relying on things like signatures, and you're not looking for a moment in time where there's something bad. Instead, It's behavioral-based. It's the actions and activities in the environment, what the context is, and how they're causally related. So you can explore all the pathways and cut them off for bad guys.

Makes sense. But lack of reliance on signatures really puts you in the bucket away from antivirus, right, where it's mostly signature stuff, even though antivirus vendors would disagree. But do you think it has to be cloud-backed to be modern? Think about EDR 2021. Does it have to be cloud-backed, or can you do it on-prem?

I think done right, it has to have scale. It has to be delivered more or less as a service. Nobody wants to be in the business of managing these infrastructures. So does it have to be done that way? No, but I don't know of a good one that isn't. And some companies, including my own, we make an on-prem variant. If you're in an air-gapped network, you don't have many options. But I think companies have to at least be cloud-first in this regard. Yes, there are economies of scale and intel and pattern recognition, but when you get down to it, all the really good ones are cloud-based. When this first started as an industry, I remember thinking to myself, having been in it forever, how are we gonna get that much data into the cloud in close to real time and then come back and take action? And those problems have been solved.

Mm-hmm.

We spent the last 8 to 10 years doing it and now they're tractable problems. And I think most of the AV companies don't get that. Now, I think there's still space for signatures. It's just not used as a means of primary detection. By all means, use stuff low down in David Bianco's Pyramid of Pain, right? Use the hashes, use the domain names, use the easy to cultivate stuff. to color and help. But really what EDR should be doing is getting the stuff at the top of that pyramid of pain. It's the TTP descriptions that you want to get to. So I'll take signatures because they let me identify the thing that has been stopped. They let me maybe add color to the weighting and determining if something is likely good or likely bad, but it should work independently of that.

That makes a lot of sense. And the idea of getting away from signatures is certainly a hype-inducing feeling. Where do you think EDR has fallen short in its journey so far on living up to its hype?

I think it's been oversold. It is not a dessert topping or a floor wax, to borrow Saturday Night Live, an old sketch.

It's not the Chincho-Matic or the Bass-O-Matic.

Yeah, for the older generation that liked SNL. I think people put too much on it, and I think people are overselling the technologies behind it to some degree. I'm less interested in how some of this stuff is done and the hype than I am in the results. So stop bragging about your better math, stop bragging about your AI. I mean, yes, the toolkit's there. It's the old plateau of productivity that things start to get useful in. Unfortunately, a lot of tools are still using things like Mechanical Turks, and they're still really reliant on signatures in this space. And it's very difficult for purchasers to be able to tell the difference among these things, for practitioners to even in some cases. But what we've got to do is we've got to actually stop these attackers more effectively, sooner, more completely, with less false positives. It's all about efficiency. Obviously, there's false positive, false negative measures. There's also the mean time measures, mean time to resolution and such.

Mm-hmm.

But efficiency for me, if quality is the same or improving, how efficient can you get with the very precious carbon-based intelligence? Because there's intelligence in security. It's carbon-based. It's not silicon-based. So how do we deal with humans, avoid them getting bored, use them at what they're good at, use them without having to repeat the behaviors, and get them to be better spent resources really in the whole system?

That makes sense. And I think to me, this is kind of initial hype of ADR didn't mention prevention. So I guess I'm happy that you're not mentioning the preventative angle. But to me, it's kind of fun that The original vision didn't include prevention, but some people tried assuming that EDR would prevent threats. And of course that failed.

I still hear people bring up prevention as an EDR capability.

Well, we should never give up on prevention. It's silly to give up on it, but we shouldn't depend on it. One of my competitors, I won't name here, once said, I'm not in the garbage collection business. He said, right? Meaning I'm in the prevention business. We should never have to deal with detection. And that's a lovely thought, but, you know, we're dealing with the most incredible opponent ever, a human being. They will innovate, they will find ways around. There is no prevention that will ever 100% stop them, and not when they have mass and scale and innovation and motivation and tools. And just look at what's happening with things like ransomware and things like supply chain attacks right now. So the answer is prevent the preventable. By all means, get better at it, but don't depend on it. You've got to be detecting what gets past it because things will get past it.

So as a fun side question that sort of touches to this one, how focused, in your opinion, are the attackers on bypassing the EDR? Like, are people actually trying to avoid you in a similar way that they've been avoiding antivirus for 3 decades, maybe? Yeah.

Do we see the same evolution as we saw in anti-sandboxing tech where, you know, bad guys look to see if they're in a sandbox?

Absolutely. It's funny, I remember the first big manufacturer of sandboxes deciding to diversify, going into other areas. And I remember thinking, if they don't keep the innovation going, they're gonna be beaten. The attackers will be able to tell when they're running in a sandbox and change their behavior. And sure enough, that's what happened. You know, they try to stop processes, they try to stop services, they look for the telltales. One of the vendors out there, and of course I'm not gonna hammer anybody, has smart filtering. It's reducing the volume they have to ingest.

I know who you're talking to. You do, but I'm not gonna slam 'em This is a friendly podcast.

Yeah, yeah, it is a friendly podcast, but, but just look at that, right? It says the bad guys can know your methodology and they know how to generate noise in ways that, that then once they've hit the 50 or the 100 threshold beyond which things aren't forwarded, then they take action. And anti-tampering features become crucially important. It's not a question of if they are, and it's also a question of when and how often, right? Because this is the ultimate testing ground, survival of the fittest for the bad guys.

I remember having an argument with your founding team about userland and not kernel land in regards to tampering. This was like, I don't know, 2015 perhaps. And I still remember it fondly. I was arguing with them in our Boston office. And I was like, there is no way you can do it in userland. And they're like, no, there is. No, there isn't. And I think they ultimately won the argument. They did demonstrate to me that you can be tamper-proof yet not be in the kernel. It blew my mind a little bit. I'll admit that.

Yeah.

Okay, so this is a detour.

So first of all, we have gone to the kernel for things like prevention. So, you know, it does exist. But, you know, I think that meeting was, what, 8 years ago?

Easily can be 6, 7 years ago.

And I can say that at least 2/3 of the PIs or the sprints since then have included incremental improvements. How do you mutually check on processes, right? How do you send artificial traffic and when that absence is noticed, etc.? And in fact, you can use some deceptive techniques to send them after wrong things very easily. When the attack that went through SolarWinds came out, it began looking for processes of us and others because of the anti-tampering, essentially gonna suicide or self-immolate when we find them because we might get detected. Yeah, we got there, Anton, but it, it wasn't necessarily an easy journey. But one of the benefits of being in userland was just how little of a footprint it took up. We're not the traffic jams around the kernel, so that helped enormously. But you were right at the time, it was gonna take a little while and we've had 8 years to do it.

I want to pull us back to A, today, B, the future, and C, the cloud, since that's what we're ostensibly meant to talk about here.

All things I love.

All things we love. Future, clouds, it's all great. How is EDR working in the cloud? Do you see a need to evolve beyond, say, a world of IaaS? How's it going so far?

So, when you say in the cloud, do you mean from the cloud, instrumenting the cloud, or really dealing with the transformed enterprise?

We could talk about all those. I'm specifically curious about what are users experiencing if they try to use EDR to protect their cloud environments?

Well, so, so far the initial forays were— we may have heard companies say endpoints are endpoints and, you know, endpoint to everything we said in our case. So endpoints are extensible to things like containers quite easily. But really, this is where the X Anton alluded to comes in earlier. The transformed enterprise, we still have to get the actions and activities of whatever that is, whether it's in the IaaS and PaaS layers, whether it's from SaaS, whether it's in the identity plane, or maybe it's classic network. We need to extract what are the objects and what is the grammar of the things happening in an environment. For lack of a better word, I'm gonna use behaviors. This is not behavioral detection, as some people mistakenly think, and it's not human behavior exclusively. It's what are the equivalent to processes and services and daemons, and what are the connections? What's the grammar happening?

Mm-hmm.

And that's what XDR should be instrumenting. So EDR is to the classic enterprise that's moving to the cloud as XDR is to the transformed enterprise. You should be able to do the exact same thing, even if you have no traditional endpoints.

So you should be able to. Can you?

Yeah, you can. I'm not going to do a pitch for my company, but I'm going to say that there's a lot of different visions of XDR, just like we said in the beginning of EDR. I'm sorry, I keep pulling it back to the past on you, but going into the future, I think you're going to see the same whittling down. Ultimately, there's a, there's a battle going on for what is the next fill-in-the-blank for the central nervous system and ability to efficiently stop bad guys. We had SIEM 1.0, 2.0, 3.0.

I missed 3.0. Did we have 3.0 already?

I think we did. Believe it or not, I think 2.0 was right after the log fetish.

Right, right, right. Log fetish is forever though, so careful with that.

That's right. But SIEM 3.0 is kind of Palantir Splunk era, right? And going forward, and then SOAR gets introduced. I will never throw out my SIEM. I will never throw out my AV.

Never is a long time.

Let's say for foreseeable future. But I think XDR will do to SIEM what EDR did to EPP.

Let me get this sink in. So XDR would do to SIEM what EDR did to EPP?

Yep. That's a big claim.

Possibly a profound thought of the day. I'll go with that.

This is a big claim.

But it's a sane claim.

It's not crazy.

It's not a crazy claim.

I want to pick at this EDR in the cloud thing. How do you see agents evolving for cloud infrastructure?

Ooh, agents, such a dirty word.

It is.

And there's always something that's collecting.

But it's connected to EDR history. I don't think you can separate agents and EDR.

So how can you collect? There's really 3 ways, right? One is you can be present in whatever the computing object is in recording. 2 is you can be observing the object's behavior from the outside. It's analogous to what we do in vulnerabilities. The 3rd one is you can infer it from everything else talking to it. In other words, as you build out a graph, just like a social graph, you can infer presence and characteristics of objects you don't directly instrument. In other words, you don't have to instrument the whole enterprise to get it. There's a critical mass that you have to instrument after which you see effectively 100% of an enterprise. However, I suspect there will be a lot of agents, very lightweight ones, and some efficiencies in how to do that because you know what? A lot of virtualization, a lot of cloud environments have mechanisms for efficient scaling without just CPU hit on every instance.

So it's agents gonna survive then? Like they're gonna morph, they're gonna go in different places, but you're not basically predicting some kind of a shiny agentless future. saying agents would morph rather than die.

Yeah, I mean, I would love a miraculous system that can, in an oracular way, clairvoyance, know that something has happened without having to be there to record it. But even so-called agentless systems ultimately have a process somewhere, for instance, forwarding syslog. There's ultimately something there. There will always be something there, whether we call it an agent or—

Yeah, but let's be careful. This is not on a monitored system, but somewhere. Even in the good old days when I was at Gartner, people were really enamored with like VM stack introspection. We were reading materials on how VMware and possibly other Others would do stack introspection. Where is all this stuff? I read about it in like 2011.

Let's go through a few things. AI was supposed to be solved very quickly.

Ah, yeah, that's like saying fusion isn't here yet. Come on.

Ah, that's a low blow. Come on.

Even homomorphic encryption was supposed to be much more efficient than it is today, and so far it's highly impractical and requires a lot of custom engineering to make work.

Totally.

I think where we are with things like introspection is good ideas that will come. The question is How are we going to tackle the large body of work between here and there? It's not a PowerPoint for VMworld. There needs to be more than just a reference architecture. This stuff actually has to be built into a whole generation of technology, and it's not in the next one.

So, a note of pessimism around introspection and some comparisons to cold fusion for other things. Interesting.

I'm pessimistic about some of this. Yeah, absolutely.

Short-term pessimism, but long-term optimism. That's what I've heard. I didn't hear pessimism alone. I've heard Short-term pessimism, yes, but long-term optimism.

Right. I mean, I don't want to go too far off topic, but I'm also similarly worried how we still don't do things like hardware roots of trust and chains properly.

Well, we do.

Well, I'm sure you do. Well, I know you do.

Oh, we do. You don't.

Let's look at, I don't know, the IoT industry and the flood of devices coming in, right? It seems like we're right back to learning the lessons of every decade all over again. Now, that's not pessimism forever. It's just, I don't see it now. And I think that there's lots of ways that we can collect telemetry that describes behavior without having to go to a sensor, but ultimately something's got to be capturing it. Whether it's highly efficient and scalable thing built into the architecture of a virtual environment or a cloud environment, great. Or whether it's a native process or it's a third-party agent, there's always going to be something that's doing this recording in one of those 3 ways.

I think that is not an unreasonable position to take.

And I'm putting it out there, and anybody who wants to get angry can obviously write in the comments, and I'll revisit because I'm being categorical for fun. So yeah.

I like that, and I think that's a good kind of mini summary. That's agents running code, observation. You would still have certain laws of physics that you can't break. You would still have some code sitting somewhere running and observing, collecting telemetry, deriving telemetry, making telemetry. You can't like make it go away unless, you know, you go really deep into the backend and then take years to do that. So if we try to make it more practical, if you do leave, like put your vendor hat back on and like think about your technology living in the container-based, serverless, microservices, cloud functions, managed databases, how would value from today's EDR be realized if people are all modern IT stack?

Well, I think it's 6 of one, half a dozen of the other. To some degree, it is about vendors advancing their capabilities and interoperability, especially interoperability, but it's also about Advancing the notion of XDR independent of any vendors. I know you asked me to put my hat back on, but if we don't get the stacks thinking about the next version and how to be XDR ready, then it's still gonna continue to be heavy lifting. While I make an XDR product, my company makes one, and I think it's really amazing. I don't think any one vendor can be expected to solve the XDR problem for the industry and for all of us. There's going to have to be some new standards, and there's one I'm championing around indicators of behavior, as we discussed earlier today. I think there's going to have to be standards on how to describe actions and activities and to share that and to interoperate. There's a few vendors, and Google is one, that we have to take a leadership role and all work with. Me and the competitors I alluded to earlier all have to belly up to the table and say, we have suites and we're working on standards.

So I want to ask a potentially off-topic, potentially cliché question, but you're, you're an EDR vendor. I've got you here. How come companies are spending millions of dollars on your service and your competitor services, and they're spending as many dollars, if not more, paying the ransomware gangs? What's going on?

Ooh, ow. Okay. I love that question because—

Good. Told you he'd love it.

Really?

I do, actually. None of us come out and say we're ransomware-proof or supply chain-proof. Nobody is, right? But believe it or not, I don't have many customers at all that have to pay ransoms and do that thing. And I'm not just saying that. I've got pre-execution and post-execution, aside from antivirus prevention for ransomware, based some on deception techniques, some based on things like Shannon entropy between read and write. I freeze the ability to delete before something can actually write to disk. If it looks like it's doing bulk reads and encryption, encryptors look like encryptors, and there are ways to do that. Here's the trick. Most ransomware isn't ransomware, it's ransom ops. It's classic APT-style movement through a network that just happens to deliver a different payload called ransomware. So the trick is if you can cut them off in 3 to 5 steps, they don't get to put ransomware in place in a significant way. They might get a system or two. The other thing is supply chain attacks. We've now seen a convergence with Kaseya of supply chain and ransomware. This is like Hafnium, this is like SolarWinds, but now where the payload is likewise ransomware.

Mm-hmm.

EDR systems must be really supply chain stoppers. I don't care if you trust the process or not, when it starts to do something wrong, uh, let's take SolarWinds. Okay, Orion sideloads a DLL, it waits a couple weeks, then there's a DGA that phones out.

Mm-hmm.

The main generation algorithm. Then a file is pulled down and a file is launched, and then privileges changed. At what point in that chain do you not know this is bad? Because my system's designed to stop that. In fact, on December 13th, when it went public with SolarWinds, we added signatures to the system just so we could identify what we'd been stopping since April. So I'm not saying that anything is impervious to it. We have to innovate to stay ahead of the bad guys. But I'm not sitting in a situation, my phone's ringing off the hook going, we're paying ransoms, what's going on? We even put a warranty out there and we haven't had to fulfill it.

It's a very good argument.

There's a brief detour to follow on Tim's brief detour. Initially, when I heard of ransomware— by the way, I like your ransom ops argument— but when I heard of ransomware, I felt like ransomware— my initial take was ransomware is poor people's problem. If you have bad IT, bad security, bad hygiene, then you suffer. But then that's a wrong view. I admit to that.

That's right. So they come into an environment slow and stealthy, just like an APT. And using the old lingo, and they move over a course of weeks. In fact, they'll measure your backup cycles and go just longer than the backup cycle, and they'll put it in all your data centers on critical systems and simultaneously detonate at 11:59 PM on a Friday night. And then you've got 24 to 48 hours, if you're lucky, to pay the ransom. Ouch. So yes, like earlier, preventable, and I can prevent a lot of ransomware.

It's staggering.

But prevent its spread, and at most they get a system or two, as opposed to your entire operation shuts down. That would be brutal. That's what EDR should stop. And ultimately, if your EDR is not doing that, it's not an EDR. It's an EPP+ system that's just using a brand to sell more.

So XDR, I think both you and Tim kind of mentioned XDR very briefly, and I wanted to explore, like, what's your take on that? Like, for example, recently I've written something when I try to say that there are multiple conflicting visions of it. Some people think XDR is EDR+, others think it's SIEM 4.0. And so just give us your crisp, hopefully short view about how you define XDR.

I will give that to you, but I think partly your fault that we have 3 positions in this acronym, right? Input.

My fault?

And XDR?

No, it's Forrester's fault for EDR, but XDR is copying EDR, right? There's input, first position, analysis, middle position, responses, the third position, right? What's it really doing? It's saying we should be able to stop advanced attacks against the infrastructure faster, more completely. Now, I don't care, by the way, if that's done with a SIEM or any acronym or an EDR or whatever. EDR exists because that mission failed. I mean, really. Next Gen AV existed— to drag back out the NG acronym— because you needed to do more than signatures. But that's not the same as EDR. All 3 of these things have collided to some degree and they're present on an endpoint and vendors sell suites like mine. However, XDR is the transformed enterprise equivalent of that. And it's a fight. I think XDR is in the lead. I think if SIEM can learn the lesson that the antivirus giants didn't, if your SIEM 3.0 guys can, maybe they'll pick up some of those use cases. But right now it's more likely that XDR will fulfill the mission of stopping active human beings and their tools and go back and pick up the other use cases around log management and reporting and hygiene. XDR, put simply, is stopping active attackers and their operations as reliably and early as possible. That's its mission. If you ask what a SIEM is supposed to do, you get 12 things. That's what an XDR should do. And maybe XDR 2.0— we got to stop using this— but XDR 2.0, maybe that will pick up the SIEM use cases rather than the other way around. Hence my XDR is to SIEM as EDR was to EPP.

I think that's a nuanced and interesting answer. That's really good.

Perfect. This is actually useful. I love it.

And by the way, it's all going to get proved out in the world of people actually doing things, right? Everything is hypothetical until you see how RFPs change, EDR has seen a meteoric rise. I think honestly ate the lunch and breakfast of the big EPP brands. And now the question is, whose vision of XDR is going to get there? And if you see someone saying XDR is just the name I put to my reference architecture, fail.

For sure.

If they say, you know, oh, it's just the next version of SIEM by my SIEM, fail, right? But if they can fulfill that vision of actually stopping the stuff you were asking about, the ransomware and the supply chain attacks, And whatever comes next, then it's fulfilling the mission, and it can claim a right to describe XDR.

Sam, I hate to ask this question because this has been one of the most fun episodes we've recorded so far, and it's the question that means we're about to be done recording. But to close, we have 2 traditional questions. One, do you have a pro tip for people that want to be better at their use of EDR or their development of EDR? And then 2, to avoid leaving our listeners empty-handed. Do you have recommended reading or follow-up for our listeners?

I think the biggest opportunity right now is to solve the biggest problem in security, and that is lack of alignment between most security departments and their businesses.

Yeah.

That the language being discussed there is not right. So I once sat in an audience, I think it was CA World a long time ago, and someone said, hey, how do I work for a large hospital? How do I roll out NAC? Right? And it was like NAP and everything else. And, and I said, okay, why are you rolling it out? Before I answer that. And he said, well, because it's NAC. And I was like, ooh, this is embarrassing. There's 200 people here who just heard you saying you're buying an acronym because Microsoft or Cisco wants to refresh some equipment.

Yikes.

Right? So don't buy EDR because it's EDR. Make sure you understand your business drivers, that you have a language that they can understand, that you align to what the business cares about, and then really work your need for EDR/XDR into that, or it doesn't fit. And I'd be surprised if it doesn't. And now, as for books, I'm a huge reader. I love to read. I have to say right now, I would be reading Dune because the movie's coming out in October.

It is the most recent book I purchased.

Yeah. Have you read it before?

Oh, I've read it a dozen times. It's for my girlfriend.

I love that. Yeah, gotta spread the good word. But other books, I like to listen to nonfiction perhaps, as opposed to listen to fiction. And I like to read fiction on my Kindle. I listened most recently to The Bomber Mafia, which was awesome, by Malcolm Gladwell. Oh, I also listened to a book called Legion vs. Phalanx, for those of you who've ever wondered in the world of what-if whose military style from the ancient world would work best. But Dune's my recommendation for fiction. I'm going to stick to it. And if you've read it, reread it, because I can't wait to see what Denis Villeneuve does with it.

I can't wait to see Timothée Chalamet.

Yeah, exactly. Yeah, I think he'll be a great Paul Atreides.

With that, Sam, thank you so much for joining us today. This has been a tremendous pleasure. Everybody, Sam Curry, Chief Security Officer at Cyber Reason and a visiting fellow at the National Security Institute.

Thanks for having me.

And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can also follow us on Twitter, twitter.com/cloudsecpodcast. And of course, your hosts are also on Twitter, @anton_chuvakin and @timpeacock. Tweet at us, email us, argue with us. And if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast.

Security. Security.