Tips to Automate Your Cybersecurity Processes

SecurityMetrics Podcast | 7

Automate All the Things!

Tom Hatch, Co-founder and CTO of Salt Stack, Inc and host of "The Hacks" sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to discuss:

• How cybercriminal activity has become automated and widespread
• How to use automation to help close your security gaps and reduce infrastructure management challenges
• The need maintaining your applications and having different types of IT individuals address security issues

"We live in the era of continual cyber warfare, and that warfare isn't just between nation states. It's between crime syndicates, crime groups, and hacker groups that seemingly spawn from nowhere. Even a handful of folks–or even a single person–can have a very big impact when they perform these attacks." Thomas Hatch

"As an assessor, I'm seeing a gap between the people that knows there's a problem, the people who have to fix the problem, and then the people who have to approve that there was a problem and that the problem has been fixed." Jen Stone

Resources:

• Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
• Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide‍

[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.

‍

Tips to Automate Your Cybersecurity Processes Transcript

‍

Hello, and welcome again to the Security Metrics podcast. I'm Jen Stone, principal security analyst for Security Metrics. And you guys, I am so stoked. I can't even tell you.

I have with me today on the podcast a guy who, follows work for a while. Very excited to talk to him. He's gonna talk to us about security in general and also some of his solutions in particular, and, I hope you enjoy it. Tom Hatch from SaltStack, creator of Salt.

Welcome to the show.

Hey, Jen. Thanks for having me on.

Super excited. You know, I don't know if so I kind of knew who you were from just because we're in the similar industries, but I didn't know a lot about you or what you had done until one of my colleagues in the pen testing department said, Jen, if you're not following the hacks, then you should be because there's a lot of good information on there.

And so I always listen to my penetration testers because they they're super smart and have not guided me wrong yet. So, so you have a podcast. Let's talk about your podcast first since that's what I just brought up.

You guys just kind of recently started that. Right? How many episodes do you have out?

Oh, goodness. I think we're, sixteen, seventeen episodes. Yeah.

Nice.

So it's still pretty pretty fresh.

So a little bit about your background. How did you get into security?

So I, I used to work for the US intelligence community.

I've been involved in infrastructure management for a long time.

When when you manage an infrastructure, you care you care about its security.

But I learned quite a bit in the US intelligence community. And then with Salt, I started Salt mostly as, infrastructure automation. Mhmm.

But it was used from an early, very early on for cybersecurity management and primarily to roll out, security fixes, to infrastructures.

And so security's kind of been I I should say it's been the second thing that I've been involved with, throughout my career. Whereas first, I'm an operating system and automation guy, but, there's always been cybersecurity right there next to it.

Oh, I heard also that one of your previous iterations of in your career, you worked for a company called Backcountry, backcountry dot com here in Utah.

I did work for Backcountry, not for very long. That was an interesting kinda stint in my career.

The only reason I bring it up is because I too worked for Backcountry for a very short stint. And it was so I I started my career in the nineties in IT operations, and I got bored of it after, like, a decade.

And maybe I would have stuck with it as, like, my primary focus if maybe the companies I had been working for had been a little bit more interesting or the challenges that they had. But mostly, I was just, I just wanna do something completely different. And so I I changed from that to development project management.

So so I went to backcountry, and I got to do their, configurator for their car racks. Super fun. It was the really the only, software development related thing that I got to do because then they found out that I had operations background, and they're like, hey.

It's taking us twelve hours to do a release. Do you think you could kinda dive into there and help us fix that?

So I'm like, dang it. Yes. I will do that.

Yeah. That's that's how that happens. Yeah. Infrastructure management, it's it's a field where historically people just kinda get sucked into it. I I I know very few people in infrastructure management that, you know, were eighteen, nineteen, went to college and said, buy gum, I wanna manage servers for this.

You're probably right.

Degree in philosophy and needed to make money and happen to know how to use Linux.

Okay. So my undergraduate degree was in animal science.

So Yeah.

Check I'm saying it checks out. Yeah.

So, so then so you got kind of sucked into it and then realizing that it is dumb and takes time to be manual with any kind of infrastructure process. Is that what made you say, hey. I'm gonna start automating things?

Oh, yeah. I mean, I I wrote my first automation platform as a, as a research project back in college, and then, moved on and wrote another one for the, when I worked for the US intelligence community.

Then, wrote another one, working for a company called, Beyond Oblivion, and then wrote another one called Salt.

And so, a lot of my motivation when I wrote Salt was to just say, I'm sick of rewriting automation platforms. How about I make it open source so I can use this one again?

And I love that you just said that. So a lot of people are are familiar with open source, but some people are not. Can you talk a little bit about what is open source and why you chose open source for what you wrote?

Well, and when you say, explain open source, it's funny. I mean, I I explain open source to another software engineer, and they go, oh, okay. I explain it to a business person, and they go, well, that doesn't make any sense. I explain it to my mother, and she still doesn't understand.

So open source really just means that the source code is publicly released.

But the implications of that have proven to be really fascinating over over the last thirty years.

So when we go back in time, originally, when people were were writing software, there were only so many people who could even run this stuff. And so you didn't bother trying to hide your software, the code that makes it work.

And so people didn't start really aggressively hiding software or concealing software and and managing in a proprietary way until until the late seventies.

And after after that, there was already a culture of, well, we just share the software that we write.

And over the last especially the last decade, there's so much free software. So So if the source code is available, it can be used for free, but that also means that it can be extended.

The modern digital economy of the world only exists because there's so much open source software out there. There's so much stuff that you just pull something for free off of the shelf and just start using it. And that has fundamentally changed how how the world works.

And when I originally created Salt, to be perfectly honest on day one, I was thinking, yeah, if it turns into a company, great. But I'm just writing me some software.

Right.

And so my original motivations around open source were, yeah, I'd like to use this again. But as we grew, I continued to, write open source software and support open source software because it supports this much larger ecosystem.

Right?

Because it allows you to create much more complex and much more powerful systems when there's open source software all around you.

I agree.

And actually back to backcountry dot com, it were the sys sysadmins who were there were the ones who originally turned me on to the concept of those open source and the value that it could bring, and I've only seen that increase over time. So, as you said, you had written over and over again, probably solving the same problems by the time you got to Salt.

You were seeing consistent, challenges that you're facing that you wanted to solve with the software. So can you kinda give an overview of of what it was the chall the problems you're trying to solve with it originally?

Well, the problems that we face in infrastructure management have changed a lot over the years. When we go back in time to original problems I was solving, it really drilled into a pretty simple concept that I wanted to be able to, gather arbitrary information from lots of systems.

And that's fundamentally what SALT is, is this ability to send a command out to large numbers of systems and just ask them a question really fast.

So, we so, I mean, if we look at some of our customers, and some of our really big SaltStack deployments, we're able to ask a question of or make a change in an infrastructure roughly two orders of magnitude faster than anybody else.

One of one of my favorites, we had a, we we recently had a bake off, right, against, a a set a somewhat similar tool that does everything with SSH.

And, during this bake off, they decided to one of the things was a performance test.

And Salt was able to communicate with and, change the password on fifteen thousand devices in in about a half of a minute. K? A little under a minute.

And this competing piece of software, it took it about two hours and forty five minutes.

That's pretty significant.

To do the same task.

And ours was much easier to set up at that to work at that scale. So, I mean, that was really the main thing I wanted to fix was just how often it is that I need to ask my infrastructure.

Hey. Can you tell me what the status is out there? I want live status. I don't want whatever a monitoring system is giving me. I want reality.

Mhmm. And then combining that with, well, if I can ask, then I can command.

Right.

So, that again, that's really the foundational unit of what Solve is. And and even in today's infrastructures, that problem certainly still exists. Mhmm. We still have managed devices, whether they're servers, network switches, containers, whatever. Sure. And being able to ask those quest those things a question and tell them, hey, move over here, or hey, shut down this network connection. That that's still really useful.

Okay. And so but now you're like you said, the challenges change over time.

And I'm sure part of that is security. I remember so my dad was, he worked for RCA when they were still in the computer business, like, in the sixties and seventies. Right? So, use a computer program and systems analyst for them when it took six to twelve months to go on-site, set up your mainframe, and then you'd go completely different end of the country to to set up the next one because there just wasn't all that work in one town.

Right? So you wanted to be in computers, you would travel. Right? And, I remember one day, we were talking about computers in in high school and he was so mad because of some some viruses that were happening.

He's like, who are these people who are are using these computers this way? It's going to ruin it for everyone. And it and, I mean, it was quite a ramp, but it really did. You know, it went from, we're all in this together figuring this out and trying to make something work to, hey, what if I did something a little sketchy?

And to now, it's not just, pranks. It's it's active cybercriminal activity.

Oh, yeah. And on on the the the cyber criminal activity is on an international stage. I mean, we live in the era of continual cyber warfare, and that warfare is not just between nation states. It's, between, it's it's between crime syndicates, crime groups, hacker groups, and they and they spawn from seemingly nowhere. You only need a handful of folks or even just one person can have a very big impact, when they when they perform when they perform these attacks.

Right. And a lot of that comes from their automation.

So I I work with a lot of, well, companies of different sizes, but sometimes, I get this, response when I try and talk to them about some some of the security holes that I'm seeing and helping them put time and money towards resolving them. And they'll say, well, I'm not big enough or important enough to be a target.

But what they don't understand is that you don't you don't have to be specifically targeted anymore. The automation out there to to just blast everybody with an issue is massive.

And so one of the things that I really like when I I've been listening to you is is the automation that you put towards, closing some of the security gaps that I've been seeing.

Oh, yeah. And I was I was astonished when a few years ago, at the end of twenty eighteen, Gartner came out with a report, that said that ninety nine percent of breaches, the company that got hit already knew about the hole.

That's pretty massive.

If if if that's not a smoking gun, I don't know what is. Right?

Right.

Well, just so you know, almost literally all of these things, you knew that it was a problem and then you still got hacked.

Mhmm.

And so that really begs the question of saying, how do we how do we solve that last mile problem?

Right. As an assessor, I'm seeing this gap between the people who know there's a problem and the people who have to fix the problem and then the people who have to approve that there was a problem that was fixed and they're good with the current state. It's like, you know, the the the people who are running scans, the people who are implementing fixes, and then management who's saying, yeah, we're good to go. And there is not a good coordination between those three.

Oh, and then we have very rarely seen a good coordination between these three.

And that's and that's entirely what we're doing from a product perspective is that, is that I sat down and went through and and really, really wanted to break down this problem set.

Because, oftentimes, we as engineers, we get trapped in, well, I can solve this problem with code kinda mindset. But but the problems we're solving are human problems Yes.

That we're trying to solve with code. And so we have to understand how that human problem breaks down.

It breaks down in large part because of the motivations of the of the actors.

When we come in and we've got our, our security analysts as you're well aware, your motivations are to find holes.

Sure.

The motivation is that, we've we've gotta find where those issues are. But the motivation is also, how do we establish what a good security posture looks like? What are those good practices?

And then in trying to achieve those practices, they they have to be applied to those systems.

But, the cybersecurity professionals out there and analysts are doing a phenomenal job, because they are finding these issues.

And it wouldn't be right of us to then look at the same person and say, oh, by the way, you now need to understand the entire infrastructure deployment and fabric so that you can fix them.

That would be a massive ask.

Yeah. Well, yeah. That that's an very unreasonable ask.

But so what happens, of course, is that I I mean, I the I've got a I've got a presentation I give on this and and I and I paint and I paint this pyramid on the, on my slides.

And it talks about how we establish policy, and we scan for these things, and we gather alerts. And then we've got a lot of alerts, and we organize them. And then we orchestrate the alerts into different tools, and we gather them from different tools. Then we funnel those alerts into artificial intelligence because we gotta we gotta know what the really bad ones are.

And then once we know what the really bad ones are, we've spent, as an industry, billions of dollars.

Mhmm. Know what the bad ones are. And, what do we do?

What do we do with this incredibly precious information that we put here?

Really good dashboards?

We open up help desk tickets for the IT team.

Yeah. Yeah. Yeah.

Yeah. And then the IT team looks at it and says, I don't have time for this crap.

Yep. And and it's I mean, we joke about it, but that is absolutely true, and I see it over and over and over again.

And one of the other interesting things is that a lot of the cybersecurity companies have come out and said, hey. We're gonna build we're gonna try and build a way to actually automate these fixes.

And I was sitting down with, with a VP of product, just a few weeks ago.

Okay. It's been a couple of months because I could still sit down with somebody.

Yes.

And, and this is one of the dominant, sore products in the market. And I asked, how many of these problems do you have automated fixes for that are usable?

And she said, we have automated fixes for about five percent. They're usable for about two.

That's rough.

And and I'm going Yeah. Well, that that's a dominant player in the market.

And, again, I mean, what we've done is we've said, I'm not gonna make a scan without a fix unless unless there's a pretty darn good way reason I can't automatically fix that thing.

Nice.

And so over ninety five percent of our scans have fixes with them.

And I think this is important because, I mean, I don't wanna make it sound like we're beating up on help desk guys. That's where I started was the help desk. I feel for help desk people. Right? It's not like they don't want to fix things. It's not like they don't care about fixing things.

The the the amount of work that is on their plates just to keep things running, much less, oh, by the way, something might get hit by this vulnerability when they're already getting yelled at to make sure functionality of tools that people are using every day is happening. It's that's a hard balance.

Well and it's hard because, I mean, even, even internally at SaltStack, you know, we've had those discussions.

Okay. We've got server x. It's got a known vulnerability. We just found out about it. We know that if we restart service x after fixing it, there's a decent chance that it's not gonna come back up because we hate service x.

And and then we say, what's the risk?

Mhmm.

What's the risk? And then how much work is it gonna take if it doesn't come back up? And we have to say things like, we're gonna miss a release of software.

And all of a sudden, the application of that fix, you know, hey. I'm an entrepreneur. I'm a risk taker.

Right. Exactly.

Very tempting to take that risk. Mhmm.

And when you start to look at that I I relate this as a story. I've got one server that's a problem that's exposed to the Internet.

Right? Just because we don't we don't we don't build our internal systems that way.

Okay.

And we're trying to get away from that last service that's exposed to the Internet that's prone to lots of vulnerabilities.

I mean, these guys get, get a top tier CDE filed against them every four weeks, it seems. But, so, I mean, we're trying to fix those things, but, a lot of companies don't have those that luxury. Yeah. That's just how it is.

Mhmm.

And then the the infrastructure people these ops people are managing way more applications than they used to.

Yes. Yes. Well, because the business doesn't understand that they have a application they need and it's valuable to them in doing their work, And then the ops team says, hey, let's can we explain to you that we cannot have this application because we don't have enough people on the ops team? And the business side, they don't have a frame of reference to be able to staff or put resources towards managing a new application. Because to them, it's just something more that you knew that you or that you use. And to the to the operations team, they're like, that is so much more than that, and we don't have the framework to talk to you about it.

Well, the problem you just described is, like, we could do ten episodes on this.

Yeah. Because, because, we could talk about how when a business creates and publishes an application, they do not assess, the total the total investment cost.

Right.

When a business has an application, they say, well, I have an application. Yeah. It's already there.

Why do I need to invest more in something I already have?

Right. It's not like a book you put on the shelf and read occasionally.

There's a it's more like a goat that you have in a pen. You gotta I'm not kidding you. They will cause problems. They'll break out.

You gotta feed that goat.

Yeah. And so so the the security, solutions that you're coming up with, Salt, tell me a little bit more about that. So you you you have scans that you have fixes for.

It's because you don't wanna tell them about the problems you don't have a fix for or or what's We we have scans for things that we can't fix.

Okay. When I say that we can't fix something, it's because it's highly subjective.

It's something like, hey. We noticed that there's a potential security problem with how your partition table is laid out. I'm not gonna give somebody a button that says, you know, I'm just gonna start messing with your partition table.

Right? So so, yeah, we we will find it.

And to those people who it's okay if you don't know what a partition table is. Basically, is you mess with it, you don't know what you're doing, you lose a bunch of information, it's not good. So in other words, you have the scans where they can automatically fix things that are maybe a lower risk to auto fix, and then you have scans that people have to take action on because of or perhaps that there's business decisions or operational decisions behind them?

Yeah. Well, and the other thing is that, all the scans all the fixes that we present, we don't just say, hey. You're about to blindly fix everything. That would be that would be pure insanity.

Yeah. It would.

What we do is we execute the scans and we find the vulnerabilities. We find the port we find the misconfigurations, and then we present them all. And then the the thing that's really important to con to to emphasize is that when we find bad configurations and vulnerabilities, ninety some odd percent of them, yes, you can probably just update and you're gonna be fine.

But but the wise operations person knows which ones are dangerous and which ones aren't dangerous.

And they're able to go down through that list and say, safe, safe, safe, safe, not sure, not sure, terrible.

Safe, safe, safe, safe, safe. And then they can push the button on the safe ones and make them go away.

The one of these huge problems that we have inside in cybersecurity in general is that we have alert overload.

Mhmm. Mhmm.

Way too many alerts because there are so many little holes.

And if you can make the little holes go away, it becomes significantly easier for that company to rally behind.

Look.

Here's the big bad ones. Here's the problems that are invasive, but we don't think they're bad. So we're okay okay accepting that risk.

Mhmm.

Instead of saying there's a flood of cruft that we have to go through. We can get rid of all that cruft.

We can then get rid of many of the bad ones immediately so that you're focused on that little window of what are the things that are hard to fix and bad. Mhmm. And now, well, this is manageable.

Right. We've taken care of many of the bad ones, lots of the not bad ones, many of the ones that could be bad later.

How you say a a good operations person can go through.

How does, something like this work for maybe a smaller organization where they're less technical? Is this is this a solution that you recommend for for groups that already have solid IT behind them? Or is there possibly a a, application for some of these smaller organizations?

So when you say smaller organizations, I guess one of the challenges I run into is that we've got, we've got customers that have one of our customers has three hundred thousand servers that they're managing. Another one of our customers is managing fifty thousand network devices.

Right.

But we've got customers that are managing fifty servers.

Right.

And we've got customers that are managing two thousand servers.

Okay.

We rarely see a customer below, below fifty devices.

Well, and honestly, below fifty, you can kinda scramble and do things manually.

Yeah. You you can. Yeah.

It's not fun, but you can. But you hit fifty, and you darn well better have a good, IT department or things start falling down.

Well, and the other thing is that, I say customers.

When you've got below a hundred or so servers, our open source software, you know, you can usually do it for with just the the open source software.

You don't need the dashboards necessarily. Our open source software doesn't come with all of our security scans and remediations.

Mhmm.

But again, you've got thirty machines. It's and you do a scan and you go this I I can deal with this.

Right.

But if you've got two hundred machines and you do a scan, that's more than you can deal with. And I Yeah. Thirty actually is might be more than I mean, it depends on how how long those how long ago were those systems installed?

Do you sleep?

Or I said long ago, but we're we're actually working on a campaign where we scan, scan and then fix, of course, stock images on cloud providers.

That was going to be my next question. How do you deal with some of these these cloud instances that are that they're similar in a lot of ways to to the legacy type of of server farms, but there are a lot of differences in how they're set up and and the kind of control people have over what they're doing.

Oh, yeah. And so, I mean, I should make it very clear. When I say servers, I don't mean bare metal servers exclusively by not by any stretch. I mean, we're used very extensively on cloud deployments. Heaven said, we wouldn't be in business.

When, when these when these cloud deployments get spun up, the the stock images that we that are used, are generally about, forty five to fifty five percent, properly configured from a security perspective.

They, almost always have anywhere from five to a few hundred known vulnerabilities in their software.

That's I've I can con I concur. I've seen that as well. Yeah.

And, and I'm I'm amazed at how shocked people are.

When when we show them that, they go, Amazon's not giving me totally tightened up secured images. I'm like, no. Why wouldn't It's your problem.

Yeah.

I'll I'll ask people what's your what's your hardened configuration in in AWS and the look of shock on some people's faces because they say, well, we use this from them. And, and it's hard to help them understand there's a big gap there. And it's it's not I think a lot of people are led to believe that the cloud is, like a magical place, but the cloud is just servers and server images that somebody else created for you.

It's just somebody else's computer. It's just somebody else's computer. It's just someone else's computer. That's it. Exactly.

One of the things that's interesting to explain is, you you come back and you look at, you look at something like like Azure and AWS, and they they publish all the security practices that they dutifully follow.

Mhmm.

And good that they do. But those security practices are to secure their own infrastructure.

Right.

One.

Two, their infrastructure is way more complicated than anything you're ever gonna build, buddy.

And what they have told you that they are in compliance to, I hope I don't get killed for saying this. I've actually said this on the hack, so I'm I've said this enough that, I will get killed. But, what they tell you that they are in compliance with only covers about sixty percent of the cybersecurity spectrum Mhmm. That is really critical for an infrastructure of their size and complexity.

And I'm not shocked by that at all.

The things I have seen inside of some cloud providers, it terrifies me.

At, at the edge devices which have not been properly secured and I go, well, it's a good thing, but I guess the attackers just haven't sat back and said, wait a minute.

I can hit that kind of device too?

Yeah. Don't give them ideas.

You just hit that kind of device.

Like, I'm being vague.

So so, yeah. I I I think, helping people understand that it's, far beyond what they think it is that they need to secure, it's kind of it's kind of overwhelming to a lot of groups. But then also knowing that there are automated ways to know about it and take care of it, I think should at least give people ideas on what steps should I take next so that I know what direction to go. First of all, knowledge is half the battle. And then because if you don't know it, you can't fix it.

But then automating the fixes, I think, is a is some some pretty big steps forward.

And it is. And and there's reasons why, why is we haven't done this in the past.

There's a lot of reasons. And when we come back and we look at the cybersecurity industry, there's very good reasons why they haven't done this.

One of them is that when you go into a cybersecurity tool and, and you say, hey. This cybersecurity tool is gonna start mucking about with your systems and your configs.

The this is the wrong expertise. It's coming from the wrong source.

Mhmm.

It needs to come from infrastructure management and automation.

And so we have seen, again, cybersecurity companies attempt to come into these arenas, but they've really struggled to get traction.

And I'll be honest, I was on I was on a call with an investor just last night, and he basically told me I'm an idiot because, because this hasn't worked in the past. It's not gonna work now.

Oh, because he didn't stop and think how are you different from what has been happening in the past.

Right. Right. You know? And and my my answer to that is but we all know what an iPod is or sorry, an iPad is, but nobody knows what the Microsoft Jupyter was.

Right?

Just because somebody made a tablet in the past that have failed doesn't mean the next one's gonna fail, buddy.

I've never even heard of a Jupyter. Well, you say Jupyter, I think trumpets, but I don't think Microsoft made trumpets. So I haven't I don't know what that is.

They they had an experimental project in the early two thousands to create a tablet that ran for us, that nobody used.

Totally missed it.

Yeah. Yeah. We all did because it was a fluke.

And yet, the the iPad, was a successful thing. So so your point being that just because things have failed in the past doesn't mean that future attempts to make security work are also going to fail.

Right. So when we come back and we look at the progress that's been made by by some of our customers, it's really astonishing.

Some of the banks, some of the government agencies, insurance companies, as well as just small shops, web shops and startups that we have as as customers, that they are able to come back and say that their security posture is, so dramatically improved that seventy to ninety percent of their of these security alerts are just gone now.

Right.

They've just fixed them.

Because it gets so noisy when it's just Yeah. Alert after alert.

Yeah. And and they've come back and they've been able to say, we don't need as many of these cybersecurity tools anymore.

We still need them. Don't get me wrong.

But many of these organizations just they had redundant scanners.

They had tools, that were only existed because of the sheer volume of alerts.

Mhmm.

And when the volume of those alerts starts to go down, you're able to say, oh, wait. There's light at the end of this tunnel.

We we can actually deliver security.

Nice. Well and on that positive note, I really appreciate you coming on and talking to me, understanding, that there is an automation side to to cybersecurity.

From my from my perspective, a lot of people don't understand that. They don't know that that's even a possibility. So I appreciate your time talking about that.

Well, and and, Jan, I can't thank you enough. I I love what you guys are doing. And, and I and I love your podcast.

Oh, thank you.

And, and you've been more than kind because you've let me come on here and just talk about myself the whole time.

That's just That was the whole idea.

I was so excited to learn more about you and what you've got going on, and thank you so much for taking the time.

K. Thanks, Jen.

Alright. Take care. Thanks for joining us again here at Security Metrics podcast. Really appreciate your time, and Tom Hatch for joining us and telling us all about security automation.

Take care. Thanks for watching. To watch more episodes of Security Metrics podcast, click on the box on the right. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms.

See you on the slopes.

‍