EP181 Detection Engineering Deep Dive: From Career Paths to Scaling SOC Teams

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior PM for Risk Analytics and Cloud Threat Detection in Google SecOps, and 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.google.com/podcasts. 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 all on our community page. Anton, we are talking about somebody who produces nearly as much content as we do today. Which is frankly impressive.

It is incredibly impressive. And moreover, while it's very unfair to compare newsletter readers to podcast listeners, it's definitely somebody with a very good audience in a very important area, which is detection engineering.

Detection engineering. Detection engineering episodes like the one we had with Tim or with other detection engineering leaders tend to do pretty well. And so listeners, I hope you enjoy today's content. as much as you've enjoyed some of our previous detection engineering content. And of course, we would be remiss if we didn't tell you this guest has a newsletter. We'll link to it in our show notes, and we encourage everybody to go check it out because I subscribe to it, I suspect Anton does, and I know there's a ton of great content in it every single week. And so with that, let's turn things over to today's guest. Today, delighted to have Zach Allen, Senior Director of Detection and Research at Datadog, joining us. Zach, thank you so much for joining us today. I want to dive right in and I want to talk about, I think, what is kind of the hardest part of the hard thing, which is detection engineering. What are the big challenges people are facing today? Because surely we had challenges 20 years ago, but what's hard nowadays?

Yeah, it's a great question. So to me, detection engineering is like 3 legs of a bar stool. It's software engineering and DevOps. It's that subject matter expertise. So what are the threat and the bad guys doing today? And it's statistics. And so when you think about someone who is really facing these types of challenges in this field, it's about scaling all of those 3 skills at the same time. There's no amount of threats, there's no amount of logs that can really overwhelm a person. And so what you need to do is you need to hone those skills and work with an org to hone those skills to scale everything up. So it really comes down to scale. If I had to answer it in one sentence, how do I scale me as a person against 5,000 rules. And that's what I think is really interesting about this field.

So this is good. And I almost like the whole DevOps connection almost made me fall in love. But I also meet, I think both Tim and me meet people who actually hear this and say, but we don't want to engineer anything. We just want to consume. We want to— so what do you with your detection engineering sort of background and thinking tell people who say, detection engineering? I don't want to engineer. I want to consume detections. Give me the little Like a little tap. I open it and detections just like start dripping from the tap.

So what do I say to someone like that?

I mean, my metaphor— sorry, let's talk about my metaphor today.

No, it's okay. It's tough, right? Because no matter whether you're an analyst and you're just consuming it, that scale and that cost is pushed somewhere. So if you're not feeling it, someone else is feeling it. So you could absolutely have an organizational setup where you have someone who's super focused on being An analyst, they're getting rules in, they're tuning, and that's all they're doing. But that cost before and cost after has to be dealt with by somebody. So do you have a SOC team that's just being drowned in false positives? Are they giving feedback to you so you can tune them? Do you have an engineering team that's beforehand, maybe within a product, that's dealing with those scales, queue pressure, things like that, really looking at data sources? So you can absolutely go down that route. It's just where are you going to spend that money to make yourself not feel that pain is where I think this kind of comes into play.

So there's like a pain balloon and we can squeeze it either onto our SOC or our engineering or our balance sheet.

That's exactly right. You know, and to kind of bring that balance sheet into accounting, like, I like to look at the economics of this almost like supply and demand. So as you're moving the costs, you know, supply increases or demand increases, that cost is incurred somewhere and that surplus is somewhere too, right? So making sure that you're just aware of that is like the first step. The second step is How much, right?

I like that.

You know, I have the— it reminded me of something we've used in the past a few times because when people look at, say, SIEM or data lake or something, they say, oh yeah, this on-prem stuff's bad. I'm just going to use cloud. But I always just grab them by the lapels and say, hey, somebody's buying hard drives. Like, you want to do storage, you want to store a petabyte of logs, great idea. But you do know whether you use cloud, on-prem, or, you know, whatever else, Somebody somewhere is buying hard drives. So it's almost, in my mind, that this was somehow reminiscent to that analogy. Like, somebody somewhere is writing detections, otherwise you're not detecting. That's it.

Yep, yep, that's right. And somebody's doing that research. Somebody's getting paged when that log source goes down. Somebody's getting paged when 200 critical alerts spawn and almost all of them are bad. Like, you just got to tell yourself, where am I going to be in this process and how much am I going to pay to be outside of it? Or at least, like, in my own little box.

So I wanna shift gears a little bit away from this pain balloon, which is a depressing topic, and talk about, uh, the other thing you do, which is this, this cool newsletter you write. What advice, aside from reading your newsletter, would you give somebody who wants to get into detection engineering? 'Cause I hear from a lot of people like, oh, I really like catching bad guys. I wanna do this, I wanna do this. And I never really know what to tell 'em other than, you know, read your newsletter.

Well, I appreciate it. I've read a lot of content and a lot of blogs. I've watched a lot of videos of how to get into this space. And it's hard to answer only in the sense of it's the same answer you give when someone says, how do I get into security? You're like, well, it depends. Where did you come from? Did you come from a degree? Did you go to a bootcamp? Were you hacking by the age of 13? So for the most part, in my opinion, for a detection engineer, you have some level of comfort with coding. Now, it doesn't have to be something crazy where you're building these huge scalable systems, but you, you're very comfortable with that. 2, you have some type of subject matter expertise in the realm of threat detection. And I would say even slice that further: cloud, host, network, email. All of those things are fair game. And especially building here at Datadog, we have a cloud security product. There's so many different log sources, right? You can only have so much expertise across all of them. So there's actually a void of talent of people that are super focused on those things. So if you kind of combine those 2 things, for the most part, you're going to start to see opportunities where you can build that detection scale, right?

I especially like the advice about getting a focus area. I always try to tell people to do that.

Yeah. I've always told folks like, just boot up a Minecraft server on DigitalOcean and put it on the internet and then see if you can protect it. Like that's your first foray into detection. And for the most part, people start to understand it, right? So.

So this is— I have a 1990s joke connected to it, but I'm not going to voice it. But it's interesting how things have changed. OK, fine. I'm sharing it. So in the 1990s, I guess the joke would be like, put a Linux server, and it would be like any server. And nowadays, it's like— so, oh, OK, fine. That's actually kind of cool.

It's running Linux. So you'll still get that Linux experience. And then you're just running some Java process. We'll see what happens open on the internet.

Ooh. That's what makes it exciting. Edge in Java.

What could go wrong?

And not a 1990s creation, presumably. Yes. So, here's the strange one. Detection engineer is presumably an engineer. So, he or she is supposed to develop something, write detection, detection code.

Right.

So, how do you think about the skills? How do you think about, like, we have examples here where somebody was a software engineer who was then pushed into the detection engineer role and actually was wildly successful? Well, not just one person. But other people think that security people need to be trained to code so that they can do it. So how do you think about this whole coding skills paradox? Is there a depth of breadth needed? Like, what's the thinking here?

Yeah, I mean, it's a tough one. I will say the security-focused computer science grads, I am seeing resumes trying to like apply to various positions people have sent me. resumes, they're doing so good. Like, by the time they're 21, they're like full CS grad. They have, you know, 15 open source projects. You know, they've interned at 3 or 4 different places. And by the time they're 21, they've done more than I've done in like my first 10 years, right? So I think there is a shift in terms of people laying that foundation. Now, to say you need a computer science foundation, you need to do like understand how to balance a binary tree in order to do threat detection is probably not where you want to go.

Hmm.

So what I tell folks, Get comfortable with building. That doesn't mean you have to build production software, but you should be able to get from 0 to 1 with whatever you're building and be able to describe that. Get comfortable with infrastructure, understanding how infrastructure is deployed, what networking is behind it, and things like that is going to be important. Lastly, understand the modern DevOps process, which you could boil it down to CI/CD. How can I commit something? How How can I open pull requests? How can I do reviews? How can I review other people's code is just as important, as well as how do I trigger a build process? How do I trigger a deploy process? I don't think you need a computer science degree for that, but to me, it kind of comes back down to that builder mentality.

I think in a few blogs, I called it an engineering-led mentality, but I think ultimately the same. This is probably the biggest hole in many detection teams, many SOCs. And I definitely feel that I've pushed— I felt resistance when I suggested that to some teams. And the result was that they kind of said, well, we really are just doing the alert triage. We don't really want to engineer anything. And ultimately, once I've met a team that basically referred to separation of duty as their excuse to not develop. They wanted to actively not be that, right? They didn't think of it as a lack. They wanted to actively not engineer anything.

Again, the cost is shifted, right?

Yes, but they were adamant that it's the right thing that they're not doing it. So do you have any kind of pithy one-liners or maybe longer philosophical explanations to really push back to that pushback?

Yeah, I actually got in trouble for this too on Twitter when I basically said that for someone, at least at my org, to be a successful detection engineer, you should at least be able to understand and describe how to deploy a microservice. And I got DMs, I got tweets to say, like, microservices is jargon, no one actually uses those, which is incorrect. And then, you know, DMs saying, like, I'll never touch code, like, I'm doing just fine writing rules. Again, all fine. A lot of my bias here is around people and small programs that are just getting started to like mid-market customers, right? I'm not talking to a major security company or major bank. I'm talking about like somebody who's at like a startup of 100 people and they're one of 2 security people. How do they do detection engineering? Or they just joined this brand new—

Should, should those people do detection engineering if there's only 2 people on the team?

Again, it's a cost thing, right? So what I would recommend to them, and here comes that dirty vendor thing we were talking about before we were recording, If you could just press something, import a couple rules to get you 80% of the way there, maybe that's detection engineering. You pay for it, but at least you're not paying for it with training, hiring, onboarding, and things like that.

Maintenance time.

Exactly.

Yeah. Okay. So I want to again, get back to your newsletter. You created this Detection Engineering Weekly. Why? What motivated this? Why does somebody start a newsletter?

I'll add, I'll pile on top. Any learnings? Do you have any learnings? Like what did you learn running it? Of course, reading all the content.

And I think it's fair for you to turn it around and say, Tim, you started a podcast. Why?

Why? Why? Don't, don't, don't.

Anton's like, don't ask me questions. I'm asking the questions here.

Yeah, no, Anton is very much, I will be asking the questions here.

Yes.

It all started with me joining this company. I knew that I needed to boot up an org to do this. I knew I needed to scale detections across 4 products. I was also doing the internal detection team, and I wanted a single place where I can go and get smart pretty quickly. And so I looked on YouTube, I looked across blogs, I looked across newsletters. I found disparate, like a peppering, I would say, of content, but I wanted one place to do it. And so one thing I learned working in a startup and at my MBA is that when you build a product, right, are you building a pain pill or you're building a vitamin? And I was feeling like a pain and I'm like, I need a place, one place to go and get this content. So I made a hypothesis that other people would find this valuable. I started doing it. I told myself, if I get to 100 subscribers, this is awesome. 'Cause really it's just this process of me collecting and analyzing everything. And now we're close to 8,000, about 60 weeks later, right? So things I learned along the way, consistency is good. So make sure you're consistent with whatever you're studying or whatever you wanna do. You can apply this in life. I would say scheduling, scheduling is important and putting things in your calendar to do focus time is important, especially when you have a family. I have 2 young kids. It was uber important I did this. And really just no matter you're building it for 100 people or 8,000 people, like it's the motivation should stay there. It doesn't really matter who's looking at it per se. I mean, of course it's great and I get this like, visceral feeling when people are opening it and sending me messages and stuff like that. That's really, really good. But overall, like, I would be doing the same thing if I divided the number of subscribers by 100.

Isn't it freaky that you guys joked about what if somebody asks us that question about the podcast, but our answers would be like 80% the same, right? Like, remember consistency versus hot guests question? Predictability and also not really caring whether you have 1, 10, 1,000 to 10,000 people listening or reading. So this is interesting that it's almost, almost like kind of uncannily matches our lessons, I think.

Yeah, I think that's, that's long-form content in general, right? Especially when it's something that you keep it episodic, like newsletters or podcasts. It's all about that long-form content and There's more in it for you than just exposure, right? Like, we're all learning, we're interacting with people, we're analyzing things. So a lot of that is very intrinsic to everything else that you get from it.

We do want to be famous, though. There's no debate about that.

No, Anton, that's just you. Anton's the one who wants to be famous.

It's a human tendency to be famous, no?

Yes.

No?

Okay, fine, fine. You can— so let me shift gears and go to sort of maybe a bit of a deeper philosophical topic. Also happens to be the one that Tim and me argued here and there. And there is even a blog, Detection is Cooking, that I think you've seen, which kind of like where this argument manifested. And I think I know what your answer would be given this whole cost shifting thing. But ultimately, when you think about the vendor-made versus customer-made detections, yes, I know from the previous conversation here that there's no magic and there's no detections made by nobody. But if I am deciding As a customer, like whether to invest money into paying for maybe a better vendor or a vendor with better detections or maybe 3 vendors instead of 1 versus investing into a team. How do you solve this one? How do I think about what to cook versus what to buy at the frozen aisle of a supermarket?

Yeah.

I'm corrupting the metaphor here.

Yeah, listeners, Anton really leads the witness here by comparing vendor detection to frozen TV dinners. But that's fine. That's fine.

I think it's your metaphor. That's a metaphor in the blog, if I recall correctly.

Yeah, I might be responsible for that.

Yes.

How far from the table do you want your detections to be is the question.

That's a good question.

Okay.

Did these outcome variables have a name?

Yeah, you know, the way I pitch this to customers or even people talking about cloning Sigma rules, right, is that it should get you 80% of the way there to whatever you want to do. If you take something and you deploy it without doing any tuning within your environments, for the most part, you should be happy with what you have if that's the cost that you want to pay for it, right? So the way I pitch it to my team is make it precise enough, make our rules precise enough so that no matter if you're a small org or a major org deployed to AWS or Google, whatever it is, these rules make sense. But they need to do 20% more to tune. They need to suppress certain things. They need to do an allow list or deny list of certain IP addresses, pull in their threat, whatever it is. So, and that works for vendors and that works for open source too. You'll see a lot of the Sigma people, for example, talk about, I think Nas says this a lot, like, don't just clone and deploy it and then like, don't touch it. You have to like, you almost have to curate it like it's a garden, right? So I think that's the trade-off I like to tell folks that use these types of vendor rules.

But there was an 80% number in the beginning. I was kind of on a ledge on the number you mentioned. So, when I—

Yeah.

What I've heard is that ideally, 80% of your detections that you consume can be from the vendor and no more frozen aisle metaphors, just from somebody cooked, not at your house. Is this a rule of thumb? Is this Would it vary a lot? Like, I'm also— I'm having this weird feeling in my head that I want to agree with that, I want to disagree with it at the same time. So, right, yeah. And this refers back to my Gartner days when we tried to answer that question for some SIEM vendors, and we got like wildly different— range was like a 0 to 100, basically, what I've heard from clients.

Right.

And this was really bizarre because we never put a conclusive number in any of the papers. So, is 80 cooked by vendor, 20 by client as a rule of thumb, or is this Tell me more.

It's a good rule of thumb, especially out of the box, right? But as you add new technologies, new data sources, you're demanding new features, or you have contexts that just the vendor does not have, that starts to shift. And so I'm going to flip that on its head too, that 20% of your time should be spent on those 80% of rules, and then 80% of your time should be spent on those 20% of the custom rules and the tuning that you build. So it's kind of like a flip there. And for the most part, that's worked. All models are wrong. Some are useful, right? So it definitely just really depends on like your systems, your threat model, what you're seeing, what your business requirements are. So it's kind of like a non-answer that I'm giving you. Non-answer answer.

But it's a bit of an answer. And also, you never said one vendor. It's basically, I would say, 20% home-cooked, 80% not home-cooked. It may be one vendor, it may be a vendor plus auxiliary vendor plus a community site with detections. So I'm just going to think while Tim is asking his questions. You set me in this brain CPU mode.

Well, I want to pick at something else you said, which is about this idea of curating or gardening these detections. That, to me, sounds like some of the issues I've run into in past lives where you get these really artisanal detections that are like one rule that is this beautiful polished thing.

Too far on the table.

Yeah, like a Michelin-starred pastry of a rule rather than enough rules to feed an army.

Right.

And so how should we think about that trade-off between, to extend the metaphor yet again, MRE rules, like meals ready to eat rules, versus Michelin pastry rules? Where should rule quality land?

Yeah.

So this is a perfect lead-on. Before I said statistics is a really important leg of the 3-legged detection bar stool. So you'll hear Jared Atkinson— he has a blog on the detection spectrum where rules are either too broad or too brittle. And what that really means is, do they have a high false-positive rate, or do they have a high true-positive rate? And there's this relationship between the two. Precision and recall is the statistics term, right? So you may be tuning something so it has such a high true-positive rate, you'll never see false positives. But the relationship is that you start to get a lot more false negatives. I feel like a lot of detection folks, they only talk about true positives and false positives and not the ratios associated with it because by the nature of statistics, again, cost has to shift.

So they overcook.

Exactly.

Or they overengineer to follow the cooking. They kind of overcook their detections. They make them too perfect.

Yes.

At the cost of— yeah, cool. I like that.

Yeah. So too brittle, too precise. You know, you could tell management we have 100% fidelity on this, which what does that mean, right? And then all of a sudden you get owned.

What does that mean?

You get owned because Because you went way too far in the true positives and you're not accounting for the false negatives. So then you have to think about, of all of these rules, do they all have to hit a certain true positive or false positive rate? Again, maybe crown jewels, you want to have more false positives because having a false negative is detrimental to the business. For something not crown jewels, maybe it's something like an alert you're kind of playing around with, a rule you're playing with. You don't want to overwhelm the SOC, so you make it really precise, and you're okay with false negatives there. So it's that relationship that it's always like a battle that you have to think about.

I think that's an easy way to trigger people on Twitter, as I tried. Like, what is the ideal false positive rate? And then these, like, little clowns show up out of the woodwork and start saying, oh, I would only accept 0.01% false positives.

Yeah.

And you, like, you want to slap them, of course, right away.

Yeah.

Because there would be alerts where you would accept 90% false positives, if the alert count is small, is low, and it saves you bacon every time, like, that's fine. So it's all very nuanced, which is good. Yeah.

And this is where, like, 1 or 2 classes in statistics or a training or something, statistics for detection engineering, just sounds like something that a lot of people need. And you're not going to go out and survey, you're not going to have a clipboard, you're not going to get people to sign anything. You're just going to understand these nuances. and how populations work and how when you draw circles within those populations, certain things tend to happen. That helps you just communicate to leadership but also to your team. You're not sitting there beating something over and over again just to try to squeeze 2% more true positives out of it. Right.

At the cost of lots of labor by really smart and very well-paid people who can be doing other things. Which, by the way, brings me to the next question I wanted to ask. It's about a backlog. I know it's almost like What's the right car to buy or something? Like, it's a very broad, strange question. But when you think about the detection engineering backlog, you have a choice of putting something on the backlog. And I feel like a lot of people struggle with this because they have, like, critical assets versus easy logs to get versus what is in the news, what's the hot branded vuln. Like, run me through a process that you would use to fill the backlog. And what informs this? This probably would pay for the price of the podcast if you just answer this one question.

Yeah, yeah. I feel like we could talk about this for hours, so I'm going to try to be concise here.

So we have exactly 5 minutes. Exactly 5 minutes.

All right, so I'm going to try my best. So this is where I think the software engineering principles can kind of come in and the idea of Agile and Scrum and product owners and product managers and things like that, where someone needs to know the business and the needs of the business, right? And so someone needs to be talking to somebody outside of the detection team. I think the fallacy is called, like, the firehouse fallacy or something along those lines, where you have a team that's just sitting there thinking about all the bad things that are happening outside the world, all the fires, but they're not talking with anybody outside the firehouse, right? So if you're not connected with the business, you're already doing the detection backlog incorrectly. That being said, once you are connected, it really kind of comes down to looking at what is that coverage for rules, what is that coverage for data sources, what are those critical assets. There are going to be things like a certain supply chain attack that happens on a Friday at 4:00 PM that management's going to be asking for detections about. So you have to prioritize those. So it's that connection with the business as a prerequisite, or I'm not even going to start, right? So that's probably how I'd answer in my allotted 5-minute time here.

So, here's the funny side story about this. So, when I was at Gartner, there were a few things that I would never put in recommendations. And they had like an inside joke about it going like, you never say, do a risk assessment and build a team. Because everybody assumes that for every big project, you need to build a team and do a risk assessment.

Right.

So, your answer unfortunately reminded me of like, sure, do a risk assessment. Like, it's a little bit that vibe of like, yeah, connect to business. Of course, that's true. But you maybe are a lead of the detection engineering team of 3. What does it mean in practical terms, connect to business? Call up a CEO? Like, what is the— give me a bit more meat behind connect to business.

Yeah. So I think the CISO or whomever, like your C-suite, is a good place to start. I really like how the threat intelligence teams do this with the threat intelligence lifecycle. They do stakeholder interviews, they then create asset lists, and then they kind of assign collection. Priorities and things like that. So you need to have some type of requirements. Compliance might be a huge driver. A previous breach might be a huge driver. Previous, like, security incidents or things that, like, you just got by on the skin of your teeth might be a huge driver. You got to go somewhere. Then it's up to you to drive those solutions. The outcomes are owned by you, but you can't get to those known outcomes until you agree that it's an outcome that you want with somebody outside of the Hmm.

That works.

Well, Zach, I hate to do this, but I have to ask our traditional closing questions.

Let's do it.

One, recommended reading aside from your newsletter Detection Weekly, and 2, a tip to help people improve their detection engineering practice.

Okay. So besides my newsletter and Anton's blog, right?

That's also in the swear jar.

Ah, yes. You've, you've listened to the podcast enough to know that that's the joke that Tim always kind of prods me in the cigar.

Yeah.

Or the SRE book.

Yeah. Or the SRE book.

Can't have the SRE book.

Awesome. Okay. Let's see. There is a book on threat detection engineering by Gary Katz, Megan Roddy, and I forgot the third person. I apologize. But they did a really, really good job of kind of framing the idea of detection and all these problems with technology, statistics, processes in one book.

That's cool.

That one's great.

That all fits in a book? That's amazing. Yeah. That must be a thick book.

Yeah. It's a great book. Yeah. It's good. It's good.

I must not read your newsletter. in detail in a good enough manner because I missed the book and I'm pretty sure you mentioned it.

I did. Yeah, I did. Yeah. So they sent me a copy to check out. Okay.

I feel kind of embarrassed. Sorry.

So that one's great if you want like something self-contained in a hardcover, something tactile. I really like— I'm staying away from Twitter a lot more now, but like Reddit's been good. Blue Team Sec is good. The specific subreddit there. I really like YouTube. Like type in YouTube detection engineering. There's a lot of people talking about it. Though that type of long-form content may not be for everybody. Medium has good stuff, though it's really hard to kind of navigate to the specific tags that you want if you type in detection engineering. I love SpectreOps. I love their blogs. I think they're really pushing a lot of the state of the art when it comes to this field. That's it off the top of my head. I guess I need to like build a list now too and keep that on the site because now I'm wondering.

That's awesome.

That's like already good weeks of reading for some people. So that's pretty amazing.

Yeah.

Thank you.

Of course.

What about the tip? One tip.

Yeah, the tip, please.

Just one tip to get better at detection engineering, is that the question?

Ooh.

Yes, just one, not 16, 15, one.

Besides put a Minecraft server running Linux on the internet. Let's see, to get better. Oh my gosh, you guys have me stumped on this one, and I know you're gonna ask me it too. Honestly, like, take a stats course. Go on Udemy. I know it sounds ridiculous, but start noticing on a lot of these stats courses that everything that you see, you can rip and replace threat detection with whatever that they're studying there. And you'd be surprised how you could take something like that and communicate it in a way that a lot of people are really starting to understand more and more. So I've been pushing this stats thing a lot. Maybe later in life I like it more than I did in middle school and high school, but there you go.

There's a lot of things I like better than I did back then.

Yep.

Zach, I can't thank you enough for joining us today. Can't thank you enough for the newsletter. And really appreciate you taking the time to sit down with us.

Awesome. 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 else 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 follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton underscore Chuvakin and underscore Tim Pico. 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.

Security.