EP39 From False Positives to Karl Popper: Rationalizing Cloud Threat Detection

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the product manager for threat detection here at 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 you get your podcasts. As well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered piping hot every Monday afternoon Pacific time, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Our episode today is shockingly, I think, the most philosophically wide-ranging episode we've had so far. And it's about the very practical and tactical world of detection engineering. So how did we end up with this chaotic stew of an episode?

It's because we are looking at detection at a very micro level in this episode. I think that's my impression because we are talking about the details, but a philosophy of details. We are not doing the high-level BS like, oh, you have to detect threats.

No kidding.

But in this episode, we're going to go philosophical on a micro level, which is really— should I say profound?

Is it too much? No, I think it's kind of a profound episode. We spend a lot of time dealing with known unknowns, unknown unknowns, thinking probabilistically versus possibilistically, which I'm not even sure I knew that was a word before.

It probably wasn't, but it's a very useful word in the context of this episode. So to me, this is for people who really want to— I don't just get to detection excellence. It's for people who want to be true masters. I don't know, that's too much.

Thoughtful masters.

It's for people who want to become thoughtful masters of detection. Oh my God, that's really cool.

Yeah, that is really cool. So perhaps with that, let's turn it over to our guest today.

Welcome Jared Atkinson to our podcast. It's going to be a fun topic because detection episodes tend to fare really well. And of course, Jared is a bit of a celebrity here.

Oh geez. Oh, I don't know if that's a proper introduction, but I'll take it.

If you have a cool title, feel free to mention it.

Yeah, sure. I'm the technical director for our adversary detection services at SpectreOps. And so adversary detection is just kind of our defensively focused service offerings.

Adversary, right? That's good because I hate people who only detect malware and ignore adversaries. Oh boy.

Yep.

There is that rabbit hole. I wanted to start on the topic that's been giving me some pain lately, and it's a topic of good detections, bad detections, great detections. I had a fight with somebody here internally who was kind of telling me that hash-based or IP-based detections can be bad because I was kind of brought up on the Bianco pyramid, I guess.

Sure.

And I tend to naively think that the fragmented— sorry, fragile detections with IPs are bad, but like high levels are good. Is it really true? How do you tell good from bad?

That's a good question. So I think the idea of the Pyramid of Pain or David Bianco's pyramid is just generally that not all detections are created equally based on, like, what you use to actually perform the detection. There are certain things that make it harder for the bad guy or the adversary or attacker to adjust their tradecraft. Conceptually, a hash would be very easy to change because all you have to do is change one byte, as to where if you are able to remove an entire technique from their arsenal, then that Forces them to change quite a bit more. Now, whether or not that is indicative of bad, good, or great detections, the way that I look at that is like, can we falsify the idea that high on the pyramid is good and low on the pyramid is inherently bad? I think we could do that by simply saying, is it important to have a detection that would detect the like default hash of Mimikatz? And I think the answer is obviously yes. You'd be silly not to detect the default version of Mimikatz, right? However, if all you do is detect based on hashes, then you have some issues with marginal return for each additional detection, right? So I think the answer is, is that low on the pyramid is not inherently bad. However, only focusing low on the pyramid is bad. Then that kind of leads me to this idea of what makes a great detection. There's a few things that I kind of think about. One is the goal should be clearly stated. I've had folks that have said, why do I need this process to develop a detection? I'm just going to look for bad. I think that's a bad starting point. So you need a clearly stated goal. I think there's this idea of no matter how we approach detection, we're going to make assumptions because we don't have perfect information. Explicitly defining what those assumptions are. There's this principle called better wrong than vague, which is—

Wait, wait, better wrong than vague, right?

What does that mean?

The principle would be it's better to make an incorrect assumption than to make a vague assumption or a non-stated assumption because the idea is that assumptions Assumptions can be falsified. So explicit or like wrong, well-stated assumptions can be falsified, but non-stated assumptions can't be falsified. For instance, I'm looking to detect malicious service creation. One starting point that a lot of people will look at on Windows is a 7045 event log.

Mm-hmm.

And so an assumption that you might be making is that a 7045 event log is going to be created every time a service is created. And that would be an assumption that you're making. A lot of times people make that assumption implicitly rather than explicitly. The problem becomes when you actually dig into how a 7045 event is created, it's created as part of like the RPC process. And then the question is, is can I create a service without using RPC? And if I can, then I could create a service without triggering that event. And that assumption is now proven wrong. That has a cascading effect of how my detection is going to work.

I really like that. I had this crew coach in high school, and that's going to sound like I'm going off in left field or the left side of the lake. But he would always tell us, if you're going to make a mistake, make a big one so that he could correct it. It's the same thing with assumptions that you're getting at. If you're going to make an assumption, make it obvious.

Visible. Yes. I think visible assumptions. Yeah. So to me, this is if I'm going off an assumption that this would do X, I better state it. And then if I go wrong, people can correct it. But if I assume that every attacker would always show up in network traffic, That's a common one, right? Every attacker would show up in network traffic, right? Because, well, how else can they get there? I don't know. They show up at the door and plug a USB stick. I don't know.

Yeah, for sure.

It's a naive example.

I like that.

I think it is factual to say that when we're facing uncertainty, which is what detection is, right? So like we don't know all the information about what's happening. When you're facing uncertainty, you must make assumptions. That's factual. We are really bad as an industry, from my observation anyway, at explicitly stating what those assumptions are. That is something that we would be much better off if we clearly stated our assumptions. It's like cryptography. It's better that it's open so that everybody can criticize it, and then you make it better over time iteratively. If you state your assumptions upfront, then your peers, whether that's internally within your organization or like more broadly within the industry, can criticize that, and you would grow over time, is the general idea.

So I'm going to assume explicitly that in this world, there are good rules and bad rules, or good detections and bad detections. Feel free to tell me that that's a bad assumption, but I'm curious, with that assumption, how do we know which are which? And is there a quality framework out there? Is this always going to be super context-specific, or can this generalize?

Like I said, one of the important things is to have a clearly stated goal. I think with detection, there's like a macro perspective, which is, How do you create numerous detections to create a robust overall approach? And then there's like a micro perspective.

Detection in depth, right?

Yeah, correct.

This cool term that we sort of occasionally use, right?

I actually really like the concept of detection in depth because I think we're very familiar with defense in depth, right? And detection in depth is a very similar concept. The idea of detection in depth allows you to be very specific in what your goal is. So you don't have to like overstretch the goal of a single detection because you could always complement that detection with something else. Whenever you start to find that the actual detection rule itself does not align with the detection goal from a micro perspective, I would say that's when it becomes bad.

Wait, example. So that means you say you detect X, but you really detect one particular case of X?

Correct.

Or is that— would that be— would that count? Especially I'm thinking of MITRE ATT&CK when people say, oh, we detect persistence. And I'm like, dude, You detect one persistence technique with that. Yeah.

We detect Mimikatz would be a good example of it. And it's like Mimikatz has numerous capabilities within it. Not to mention, what is detecting Mimikatz? Is it detecting the tool or is it detecting the actual capability, right? Because for instance, just one of those capabilities is credential dumping, but there's also Kerberoasting, there's golden ticket attacks. It could even find the mines in Minesweeper for you if that's what you're into, right? By saying we detect Mimikatz, Are you detecting only the tool or are you detecting a capability that it performs or are you detecting every capability that it performs? I would say that there's some aspect of like, do you have a clearly stated goal which tells me what I should assume about that? And then like, what are the assumptions that you're making about that as well to kind of get an idea of that?

So good detection has a goal.

I would say that's the starting point.

I think it's more like matches the stated goal, right? Is it fair?

Yeah, the things that I would say a great detection involves, and this is probably not exhaustive, is a clearly stated goal, explicit assumptions, documented response process. And to be clear, I don't expect you to identify a list of you're going to do all these things, but maybe when this alert fires, I expect that you might look at A, B, and C as a starting point. How many times have we run into an alert where it fires and you look at the title of it and you have no idea what it was intended for or what you're supposed to do with it?

Mm-hmm.

Ideally, there's some Marginal value to creating that detection in the first place. Like I said, with the pyramid of pain, if you focus all on hash-based detections, you're gonna have diminishing returns at some point, right? So like the first one is going to be the hash of Mimikatz, and that's probably fairly valuable.

Mm-hmm.

And then at some point you've exhausted all the known tools that you could come up with, and now you have diminishing returns, right? As opposed to creating something higher in the pyramid that's going to have a much larger impact on the multiplicative factors of different attack techniques. So I'd say that that's probably my general idea for what makes a detection valuable or good or great.

Some of it feels site-specific, though. So back to the part of the question about, is this a general answer? Like, Tim is creating a tool, and the tool is the same for every Google Cloud customer, to pick an example. And good detections are good for everybody, sort of. But there are also examples where detections are clearly good for one client and bad for another. Where do we have a slider for context-dependent versus general? Like, if a detection doesn't achieve its goal, it's bad. That part's clear. But beyond that, how do we balance the site-specific versus general? Is it too philosophical for the audience? I don't know. It's fun for me.

I think it's a good question.

I think it's an important idea, right? And I think that goes back to like, what is your goal? I'm a consultant, right? And so the way that I look at everything is how can I apply what I'm saying as broadly as possible. There is a level of abstraction involved in kind of like what makes a great detection. Having a clearly stated goal is applicable across every use case, I think. However, I think it is important to align your goal, and maybe this is the more macro perspective, is how do I make sure that my overall detection posture— so I have numerous detections that form some detection posture— how do I make sure that those are aligned to the risk of the organization or Something along those lines.

That makes sense to me. So to me, this means that maybe there won't be a simple checklist like check 1, check 2, check 3. If you pass, it's a good detection. There won't be a general thing like that, but you can at least have principles for good detections rather than the checkbox. That's probably a useful outcome for the audience. So the topic of this, at least in the industry discussions, very often comes to a more specific angle, namely about false positives. And people almost naively equate bad detections, high false positives, good detections, low false positives. And that's like they start expressing a very one-dimensional thinking, like good detection, low false positives. And to me, it leads people astray. And sometimes I used to kind of blow their minds a little bit by saying, hey, I've met people who have detections with 90% false alarms and they love them. And people are like, what do you mean, Anton? You're wrong. And they say, well, they produce 10 detections a month. 9 are false. 1 saves their bacon. No other technique detects it. And so they accept the 90% false positives given low volume. But what are other useful nuances to think of? Because I feel like we are really not healthy mentally about false positives in this industry.

This is something that I think about so much. Like I mentioned earlier, we're dealing with imperfect information and uncertainty inherently. You're going to have false positives and you're going to have false negatives. And so the first important thing is to realize that there's 2 types of error. There's false positives, which is where you alarm on something that shouldn't have been alarmed on, right? That's the innocent person that is found guilty in a trial, for instance. Or you have false negatives, which is where you don't alarm on something that should have been alarmed on. That's the guilty person that got off. We have a tendency to be focused on false positives. There's this kind of fallacy, which is the problem of silent evidence, right? And so the idea is, is that False positives by their nature are conspicuous, right? So a false positive is going to create an alert, and we associate alerts with work, and we have a limited amount of capacity to do work. Then we say, okay, well, we have too many false positives. We're not able to do the things that we want to do, and so we need to reduce those false positives. Meanwhile, there's false negatives that are occurring, but we don't alert on false negatives by their nature. We're not aware of those. false negatives. And as a result, we kind of ignore them. So our solution to a high false, like a bad detection or a poorly calibrated detection, is to always reduce false positives. I don't know that this is like mathematically true, but there's almost like an inverse relationship between false positives and false negatives, which is as I reduce false positives, right? So it's too noisy, I reduce false positives, I'm increasing the likelihood of false negatives.

And there are vendors who would argue with that, but actually you're right. It can be proven statistically, but you encounter vendors who would almost like argue against gravity. It's not even arguing against climate change, that has more nuance, but it's more like they argue against gravity. They're like, no, dude, our tool though, it has no false positives and it totally catches all the attacks. And I'm like, that's impossible.

You can't prove that.

You can't.

Earlier when we were talking about the pyramid of pain, I was like, let's try to falsify the idea that high is good and low is bad. Karl Popper is famous for this idea of falsification, which is where In science, you make a conjecture based on the evidence that you have, and that conjecture is supported by evidence, but it's not necessarily true. One of the problems with false negatives is in order to prove that you detect every attack, you would have to have perfect information about every attack that ever happened and ever will happen. And you don't have that. That's just a fact. The way the scientific method works based on Popper's kind of process is that you don't prove conjectures because in order to prove something, you'd have to have all the information. But you can falsify conjectures. And so the idea would be you just have to prove once that they don't detect everything, and then now you've falsified their statement, which is we catch all the attacks. That's just the idea that I always bring to the problem, is like, we should be thinking possibilistically, which is like, what's something that could happen? Whether or not we've observed it or not, that doesn't matter because we haven't observed everything that could or has happened in the past. Thus, like, when we're making decisions, we shouldn't work from probability because probability is inherently limited because we don't have— Mm-hmm. Perfect data. If we think possibilistically, then we ultimately have that 7045 event log example that I gave, which is we're assuming right now that a 7045 is going to identify every service that's ever created. But is it possible for a service to be created without a 7045? When you ask that question, you may not know the answer to that, but you could think about whether it's possible. And now you can try to prove what that possibility is. It can actually happen. And that's where red teaming really fits into the whole process is. Identify something that might be possible and then try to prove that that possibility can occur, and that would falsify some conjecture that you've made earlier or some assumption.

That's a very philosophical answer to these kinds of questions. I don't think any guests have brought up Karl Popper. I don't think anybody's brought up falsifiability to this extent.

But people live with that without being aware that it's kind of happening. So, I mean, I think Jared has an excellent point that These are the laws that drive our domain. And people's kind of unawareness of them doesn't save them from their impacts. You know, you can argue against gravity, but you're still going to be falling down, not up, right? Or sideways.

Yeah, that is true.

You're still going to have your coastal real estate get very wet thanks to climate change. I want to pick at this false positive thing a little bit more though. What can organizations do practically and I love Karl Popper, but I don't think he's going to help my SOC analyst have fewer sleep-interrupted nights. So what can organizations do practically to deal with being blinded by false positives?

There is an aspect that false positives are kind of a hedge on false negatives. You can't quantify false negatives, and so you have to kind of hedge on them to some degree. The threshold by which you alert on something is arbitrary, and that may be controversial to some people, but The idea that you can tune a detection means that the detection is an arbitrary concept because it's not going to be perfect. Really what we're doing, whether we're doing it explicit or implicitly, is we have some constrained amount of resources. Let's just call those like analysis hours. Maybe not all analysts are as efficient as each other, but we'll just kind of abstract it to analyst hours. One of the main key focuses is, can we improve the efficiency of our analyst units or analyst hours.

Mm-hmm.

One way would be to hire more analysts so you have more analyst hours, but that seems to be not the ideal solution for most people. And so the idea would be, can we make those analyst hours that we have more efficient so that we can deal with more false positives, right? Or more alerts in general. Anton has a really great blog post about this that he called On Threat Detection Uncertainty, and he kind of proposed 3 different strategies, and I'm sure they're not comprehensive, but One is improve alert triage, which is kind of like the idea of, can we make this process more efficient than what we're doing now, right? So you could always become more efficient, which then means you could handle more alerts, which then means you could increase your false positive threshold. Use multi-stage detection, which is don't let the detection rule be the end-all be-all, right? So like, I think of detection and response as a series of context building and filtering, right?

Mm-hmm.

It basically allows you to apply your limited resources in a smart way. You're basically trying to identify the event that is the most likely to be security relevant. As you become more certain that it's security relevant, you can apply more resources to it, right? And so like for instance, detection, you're trying to apply the filter across millions or billions of events, right? But by the time you get to an investigation, you have exponentially less events that you're investigating.

Mm-hmm.

Mm-hmm.

Yeah, the funnel that everybody draws on every vendor glossy, right? Like, the funnel is real, but the output end is different. So there's no universally acceptable false positive ratio, right? Because as we just discussed, it's almost pointless to have an industry debate about is it 99% or is it 99.99% because it's really silly. It depends on so many factors inside an organization and the type of detection and type of threat actors. So the whole FP discussion as a global standard is idiotic.

I agree with that. I think the acceptable false positive ratio should be aligned with like how much risk that thing that you're trying to detect presents to you. Again, the proxy for risk acceptance or risk control is how many of your constrained analyst units are you planning to put towards that problem? If you say, oh, I'm only willing to take, and that, that could be in the form of, I can only accept 10 false positives per day from this detection.

Mm-hmm.

That is a proxy for the amount of risk that you think that poses to your organization, right? Because you could always increase the number of false positives that you would accept, but then it's going to take more analyst units. And that ultimately, because that's a constrained resource, will take away from other detections or other investigations or other remediation efforts. And so I think the acceptable FP rate, it has to be context-specific to the detection itself.

Mm-hmm.

Let's face it, like not every ATT&CK technique is going to be as relevant As every other ATT&CK technique. You should be making that decision on a case-by-case basis, in my opinion.

I like that answer a lot. I wanna shift gears a little bit away from the false positive discussion, as much as I've enjoyed it. And getting back to your point earlier about macro detection coverage.

Sure.

How do we test for this in the real world? It can't just be like, how do you score on the MITRE bingo card, right? 'Cause A, MITRE ATT&CK is not a bingo card and nobody should treat it that way. But B, how do we actually know if our macro coverage is good?

Yeah, it's also not complete information, right? So like the ATT&CK does not include every potential technique that could ever be used, right?

It doesn't?

Surprise, surprise. Oh boy.

Well, it's a compliance standard. Attackers have to comply. Are you a MITRE ATT&CK compliant attacker? No, go away, right? That's how we do it.

I'll admit I'm much more micro-focused in my thinking than I am macro-focused.

Mm-hmm.

However, I think there is like some way to kind of evaluate the gravity of a technique, right? Which is like, how likely is a given technique to be used throughout the course of an overall attack? To some degree, let's say there was a technique that's predictably used in every single attack. If you can detect that technique with 100% accuracy, then you're going to detect everything, right? That's not possible. And so we could work our way back and kind of say, What are like the highest gravity attacks and like how confident are we that we can detect them? And then we start building out this layered detection in depth. There's 2 perspectives, detection in breadth, I guess, which is across numerous techniques as opposed to detection in depth, which is like across one technique. I don't know if that's the definition, but that just kind of dawned on me that that might be a distinction worth making. I've been thinking philosophically about this and there's like this question of Can we go look at like Red Canary, for instance, has reports on like the techniques that were used in the intrusions that they've observed over the past year. So like every year, Red Canary, Verizon, Mandiant, all these companies come out with these reports. And so we might be able to go and look at those reports and say, okay, what are the most frequently used ATT&CK techniques and how confident are we in being able to detect that? The question is, is like, are we detecting those ATT&CK techniques because we know about them?

We find a lot of keys under street lamps. Does that mean we drop a lot of keys near street lamps?

That's correct. That's the kind of problem. But then you have this idea of like, don't try to predict what's going to happen, prepare for what might happen. That's kind of the idea of we can try to predict what attack techniques are going to be used or when we're going to be attacked or where, you know, the attacker's going to get in. But really the, our history in the industry or just as humans, as a species of predicting things is, Pretty bad. And so it's better to be prepared for the worst things that could happen as opposed to trying to predict what's going to happen. So that's maybe a strategy that we could take.

This has been a theme that I've been trying to make more popular in the industry, frankly, because people call many of us in December and say, predict the threats. And my answer was like, no. For the last 10 years, I've been like, no, that's impossible. And that's also useless because when you predict, And if you convince everybody their predictions are right, then they all get blindsided by what really happens. So to me, there's active harm in prediction. I've sometimes succumbed to the temptation, but ultimately, we need to print it on big posters, don't predict, prepare, and make it more known. This is actually kind of a cool one. We're kind of getting close to time. So Tim, why don't you go for our favorite final questions? Because Jared is so cool, maybe we can ask him for 3 practical things, not 1. Oh, wow.

So Jared, I'll ask you first the easy, the softball. I have a softball question, which is, do you have recommended reading for our listeners?

Except for Popper's book, of course, because we're going to catch this one already.

One of the books that I'm reading right now is Black Swan by Nassim Nicholas Taleb. That's where a lot of the things that I've just talked about come from.

I'm friends with one of his friends and I asked once, is Taleb as insufferable in person as he is in his books? The answer is no, he's actually a pretty nice guy in person.

Oh, good. Okay. He plays up the frustrated with the academic perspective, but if you can look past that part, right, which is just like, I'm smarter than everybody and nobody else understands it, there's a lot of like really good tidbits to take away that you could really apply to detection, right? Yes. So like one of the big things that I'm interested in is, this is like very sidestepping your question, but it's one of the things I'm really interested in is like how established schools of thought in different industries or different fields of study are very applicable to cybersecurity or detection and response in general.

Mm-hmm.

A great example of that would be like Jean Piaget and his theory of cognitive development in children. He's a Swiss psychologist that is best known for like developing the idea of how we develop cognitively as we grow older. If you're familiar with the idea of assimilation and accommodation, assimilation is this idea that you build schemas in your head about how to describe things in the world, right? So you might have a dog. I have a 1-year-old. I explain to my son, That's a dog. And he's going to develop some schema that's an imperfect representation of what a dog is, right? Maybe he thinks any animal that has fur and walks on 4 legs is a dog. And that's assimil— and so like we go and we see another dog and he's like, oh cool, that's a dog. I can put that into my schema. It all works, right?

Mm-hmm.

And then we see a horse and it has, you know, fur and it walks on 4 legs. And so he might say, hey, look, it's a dog. And I say, oh no, no, no, no, no, that's not a dog. That's a horse. And so like now he assimilated that the horse is a dog because it fit into a schema. But then by me saying no, that told him that his schema was not sufficiently complex or sufficiently robust. And so now he has to accommodate, which is like basically create a new schema for the dog and then create a schema for the horse. And now you have to differentiate those things. And then there's this idea of like abstractions that he came up with, which is this idea of if I tell my 1.5-year-old, hey, go clean your room, that's not a sufficiently descriptive instruction for him, right?

Mm-hmm.

So he's probably not going to achieve the goal that I expect from him. But if I say, there's a book on the floor and I want you to put that on the shelf, like, that's a very discrete task and he's able to do that. And then over time I could kind of like say, hey, you know those 5 things that we just did? That's cleaning your room. So he can start to build out that abstraction. And I think in cybersecurity, I kind of like facetiously made this example about like, I'm just looking for bad. That actually has happened. Like somebody's actually said that to me.

Go look for bad.

That's the equivalent of saying clean your room, right?

Yeah.

Which is like, I'm just looking for bad. It's like, okay, well, how are you looking? And so like, there's this idea of like, how does assimilation and accommodation work into detection? Which is we have to build the right schemas and we have to make sure that they're sufficiently robust to like explain the phenomenon that we're trying to explain.

That's fascinating and really fits with some conversations I've had with executives here recently. I want to close with our final usual question, which normally we ask for one, but since this has been such an interesting and ranging conversation, we'll ask for 3. What are your 3 tips for improving detection practice at an organization?

The first one is think possibilistically, which is think about what's possible, not what's probable, because you haven't observed everything. And so you should assume that you don't know everything.

Mm-hmm.

Second, document your detection, identify your goal, explicitly state your assumptions, maybe include the response steps so that other people can try to criticize or understand what you're trying to accomplish. The last is, we never really talk about this, but find the base condition. So when we're talking about an ATT&CK technique, What is the thing that must happen in order for that attack technique to happen? So the simplest way to describe that is, if you're looking for malicious service creation, the base condition is that a service was created because every single time somebody creates a malicious service, they must also create a service. One of the things that we often conflate is this idea of identification, which is what are the events that are relevant to this detection, and classification, which is, is this thing bad or benign, basically. We skipped the identification phase, which is, how do we make sure that we know that we're applying our logic to every service as opposed to just some small subset of services? And I think that's a good way to really try to reduce false negatives.

I really like those answers. Those are great. Jared, thank you so much for joining us today. This has been a fantastic conversation. Anton, do you have any closing thoughts you want to add there?

No, this was amazing. My mind is still reeling. I'm actually taking notes too. A couple of possible new blog posts may come out as a result. So we need to co-author them with Jared at this point because there's his ideas.

I think we do.

Yeah, let me know.

Jared, thanks again for joining us today.

I appreciate it, guys. Thanks for having me. Cheers.

And now we are at time. Thank you very much for listening and of course for subscribing. I'm sorry, but I'm going to pester everybody to subscribe because we really need subscribers. We need more of them, more of them, more of them. Okay, now I sound positively miserable. In any case, you can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Please subscribe. You can also find us at our website, cloud.withgoogle.com/cloudsecuritypodcast. Right on the website, we have the buttons to Google Podcasts, Apple Podcasts, and whatever other source I just mentioned so that you can, guess, subscribe to the podcast. You can also follow us on Twitter, twitter.com/cloudsecpodcast, for lively debates. Your hosts are also on Twitter at Anton_Chuvakin and _TimPico. 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 episode.

Thank you, Roni.