Screaming in the Cloud - Meanwhile in ‘Meanwhile in Security’ with Jesse Trucks

Episode Date: March 4, 2021

Links:Splunk: https://www.splunk.com/Meanwhile in Security: https://meanwhileinsecurity.com/

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. the tools they needed, so they built one. Sounds easy enough. No one's ever tried that before, except they're good at it. Their platform allows teams to create consistency for the entire incident response lifecycle so that your team can focus on fighting fires faster, from alert handoff to retrospectives and everything in between. Things like, you know, tracking,

communicating, reporting, all the stuff no one cares about. FireHydrant will automate processes for you so you can focus on resolution. Visit FireHydrant.io to get your team started today and tell them I sent you, because I love watching people wince in pain. This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the enterprise, not the starship. On-prem security doesn't translate well to cloud or multi-cloud environments, and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35% faster, and helps you act immediately.

Ask for a free trial of Detection and Response for AWS today at extrahop.com slash trial. Ever notice how security tends to be one of those things that isn't particularly welcoming to folks who don't already have the word security somewhere in their job title? Introducing our fix to that, Meanwhile Insecurity. To sign up for the newsletter or to find the podcast, visit meanwhileinsecurity.com. Coming soon from the Duckbill Group. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jesse Trucks, who does, well, two things that we really care about. Let's start with the one that's easier to describe.

Jesse, you are the Minister of Magic at Splunk. Thanks for joining me. What the hell do you do? Well, I'm a security specialist, but people ask me, well, what do you do? So I'm essentially an advisor or consultant to Splunk customers, and I help them get better return on their investment for their spend on Splunk products and services, and so that they have better security. Awesome. Better security. The sort of thing everyone claims is super important to them,

usually right after it's been in the papers that security was not important to them, at least not worth doing anything about. Security has always been a weird space, and you have a strong background in security. You were at Oak Ridge National Lab doing cybersecurity, not the physical security part around the reactors, but doing supercomputer-looking stuff, right? Yes, for a while I was doing the HPC security

for the National Center for Computational Sciences. Before that, I was a system in for Anton Supercomputers for D.E. Shaw Research. That was a lot of fun. And then I was a cybersecurity operations team lead for the entire lab cybersecurity team. Again, we keep going back in time,

but one other interesting thing that I'll hit, and I promise I'll get off this track, is that you were at D.E. Shaw Research. D.E. Shaw famously being the hedge fund that Jeff Bezos worked at before going to start Amazon. And you were there, you know, 10 years, 20 years later, something in that range, in the D.E. Shaw Research Group handling provisioning of their supercomputers. And that's great and all. It's one of those things where you look at a place like D.E. Shaw and you can say an awful lot, but one thing you can't say is that they hire dumb. That's true. I often say that, and

this is fairly true, that one of the hardest days of my career was the one-day interview back-to-back with different people at D.E. Shaw, where you knew every 55 minutes they'd decide whether you'd go home. And they asked some of the most interesting, realistic, real-world questions. None of this, like, how many ping-pongs in a jet crap, but instead it was, how would you figure out the bandwidth available on a fiber link and where a problem might be? Here's a whiteboard. Oh, I like that.

It's one of those things that sounds deceptively simple, but is so open-ended, and you're looking for the trap because of the interview, and you want to perform well, and man, that's a fun one. I will not rat hole on that question today, but man, is that a fun one to go into. It was good.

Now, you do all this stuff in security and have for a long time, but the other piece of this and why we're talking about this today here is you are launching a combination newsletter and podcast here at the Duckbill Group called Meanwhile in Security. And people are sometimes thinking that I'm going to be the person that writes this. And sure, I can get up there and pretend to know things that I don't. I'm a white guy in tech, confidently making statements I don't have facts on is basically what's expected of me at that

point, right? But you actually know what you're talking about. And there's a reason that we have you telling those stories instead of me. But start at the beginning. What is, meanwhile, in security and why should anyone care? So as we all know, one of the problems that we see is security is important. And there's all the obvious reasons, don't want to get hacked, don't want to get exposed, don't want your stuff shut down, blah, blah, blah. But the real reason the security is really important and to be integrated into how operations are built from the ground up,

from not afterwards scan my new application or things like that, but built in from the ground up, especially in cloud native apps these days, because everything is a surface and therefore everything is a surface. So how do you get more ROI out of your spend on your cloud infrastructure

or your on-prem infrastructure? Do better security and do it up front. And also, one of the things is nobody knows how to talk about security except for security geeks. There's very, very few people who understand the nuances of security and the actual business impacts

of what those things do and what they are and how they interact. There's very few people who are willing to go public and talk about having one foot in business and one foot in tech. I mean, Corey, that's how you've become successful. You can speak both. Yeah, I can blend multiple areas of expertise into something forming a niche, which is great. I mean, the idea of finance and cloud computing is a small but important niche. Being able to talk to computers about security and being able to talk to people about security is more important, I would argue. And also, not so much of a niche as it is a common business problem that every company

needs to be able to traverse somehow. Yes, absolutely. And the message out there to a lot of people in their various organizations, especially in your DevOps-y kinds of operations, is you must do better security, but they're not security people. And security people generally aren't the DevOps-y IT people.

And so how do you get your SRE types to know better security? Meanwhile, on security. I love the buried pun in there, personally, but that's neither here nor there. There are a lot of podcasts about cybersecurity, information security. What is the appropriate term these days?

I don't want to deal with the community yelling at me because, honestly, I have no patience left for the InfoSec community as a whole. So that really depends on who you're talking to. If you're talking to anyone vaguely associated with the federal government or works with federal government at all, we've all given in, thrown in the towel, and we call it cyber or cybersecurity. Cyber meant something totally different when I was coming up into computers back when IRC

was the only chat option. But these days, old school InfoSec people call it InfoSec or information security or just security. But generally, most people just call it InfoSec or information security or just security. But generally, most people just call it cybersecurity because that's what the general layperson or the management people who don't know technology call it. So really, you can call it anything. And I'm going to say cybersecurity and cringe every time I say it. Everyone refers to your industry a certain way. You smile and you shrug and you put up with it.

I mean, I was on the side of DevOps shouldn't be in a job title, but then I saw a lot of people paying an awful lot of money for jobs that had the word DevOps in them. And you know what? Smile, nod, take the money. The problem I saw across the board was that there are two categories, very broadly, of folks who work with cybersecurity or infosecurity. We're going to call it, is InfoSec okay to call it? Or is that going to annoy people? InfoSec is fine. In fact, it's actually my favorite term. And I like camel case, so it's capital I, capital S.

But that's partially because it kind of irritates some people. Oh, absolutely. Irritating people is one of my favorite things to do, especially when it's intentional. The problem is there are two worlds in InfoSec. One is people who are deep into InfoSec. One is people who are deep into InfoSec talking to other people who are deep into InfoSec. And then you have InfoSec adjacent folks

where you're a DevOps person or you're an SRE type or you're managing a team. And you are very much on the hook for security being implemented properly. And yes, it's a spectrum, I get it. And properly can mean a lot of different things to a lot of different folks. But security is one of those things you have to do,

but it's not your core focus. And all the stuff I see in the InfoSec world, there are a bunch of great newsletters and podcasts in the space that speak security to people who are already deep in the weeds on security. And it's not accessible. I don't find that it resonates with me for whatever reason. to people who are already deep in the weeds on security. And it's not accessible. I don't find that it resonates with me for whatever reason.

The more I looked for something that didn't have that approach and instead talked about cloud security, which, let's be clear, is security these days, in an accessible way, the more I realized I can't find it. Well, if I'm looking for this, maybe other people are too. And thus begins our Meanwhile in Security experiment. Yeah, and one of the reasons for the title is because what happens is, is most of us have some job, and then there's security. So it's like, oh, yeah, meanwhile, over here in the security land, so,

and again, the pun, in case anybody didn't catch it, is meanwhile in security. And we call things insecure, which always cracks me up because you think of it like a therapist for a computer, although the origins are actually in grammar. And the problem is, is that people have to figure out all the security things that are relevant to their job, but their job is not security.

And on top of that, they're expected to wear five or six different hats. And the hardest hat is the one that they're focusing on right now. And then in 10 minutes, it's a different hat. It's a different hat. They're all incredibly hard jobs. And most of them have DevOps-y titles as well, even though really, like, the biggest thing these days is SecDevOps. Have you seen that one yet?

I've seen DevSecOps. And I'm sure the ordering is important. And at some point, it's one of those, how many words are you going to shove into a portmanteau? Exactly. What about QA as well? And oh, we've got to get the word Kubernetes in there somehow because the CNCF demands it. Yes. And also, if people are searching for job titles, then they'll find what you're trying to hire for. And most people I've talked to actually have DevSecOps jobs or SecDevOps or whatever way you're doing that. Generally, what they are is they're people who have a strong programming infrastructure background who have learned some security. And that's not always true. Sometimes it's security people who've learned IT stuff or like me, I came up through the ranks doing both IT ops and SecOps together. And the problem is that they can't keep up with

all of their industries that they have to. There's already too much. There's already so much bifurcation. For instance, you don't have somebody who is an amazing Linux engineer and an amazing Windows engineer and an amazing Cisco engineer because that's too much to keep track of. They can be good at all of them, but they're only going to be amazing at one of them at best. And with rare exceptions, they're our prodigies.

And so in security, same thing happens. There's also a question of how do you position something? Because on the one end of the extreme spectrum, there's room for a show that explains InfoSec concepts

to the layperson. Use a password manager. Here's what multi-factor authentication looks like and what it means. And then on the other side of it, you have folks talking about the actual seed algorithms you use behind those MFA devices. And there's an unmet need in the middle, which is, okay, I want to know how to approach an AWS account MFA story. Yeah,

I get why MFA is important. You don't need to belabor that to me, but I don't care about the underlying algorithm. What I want to know is how do I handle the root accounts MFA device without having to put it in a safe somewhere that burns down or we can't get to in a pandemic versus making it available to every person who works at my company? What are strategies real companies use around stuff like that? Because everyone wonders. That's the sort of question I want to see explored. Well, simultaneously rounding up,

what were the interesting stories that happened last week in the wide world of InfoSec that people should pay attention to? Yeah, I think that there's a combination of things that you just hit on. One is just understanding fundamental concepts. And these have to be repeated quite often because even people who are in InfoSec, we often get rusty in things that we don't work on on a frequent basis.

And then you have people who, of course, are not full-time security people. And you have new people coming along all the time. Like, okay, so what is the buffer flow exactly? Okay, well, it's this fundamental concept. What's a mental attack? Do people even do these anymore? And also, where are some resources if I wanted to deep dive and geek out on it? Where do I go? Which ones are reliable? What's the things that are most digestible? And the last thing is, how do I actually do this? Just functional things. I guess the other really last thing is, what's happened recently?

What's in the news? And meanwhile, in security, we'll cover these concepts as well as big things that happen in the news and links to things that are current events that are relevant to how we do security today. I've also said it before on the show, and I'm going to be very transparent about this. I find the InfoSec community is largely a trash fire. And they haven't quite had the same experiences that a lot of the SysAdmin community did as the DevOps movement was emerging built around empathy. I found it so abhorrent in many cases that I got largely out of those spaces. There are good people in that community working for change. I get that.

But it still has a weird lingering vibe of that, for me anyway. And I can expect that some people are going to read Meanwhile in Security and say, oh, this is way too basic for my big brain exploration of how security works. Great. That's not for you.

It's also not for someone who is sitting at home and trying to make sure that someone doesn't break into their Facebook account necessarily. It's not really for them either. It's for folks who are operating in the world of cloud slash modern computing. Hybrid, of course, is a very real deal too. And even in data centers,

a lot of this stuff all is cohesive and needs a reasonable approach. But everything that even begins to speak to those people, it seems, is vendor-captured. It's buy folks who have something to sell them, and magically everything that they talk about, all roads lead to buy my enterprise software. Yeah, and that's one of the problems, too, is that which vendors do you trust? Which vendors have a good account team for you to talk to who's going to be frank with you today? And that changes and evolves. And most of your main vendors out there, they're going to tell you perfectly true things. But we're all biased in our experiences and where we work

and what we're trying to sell. And what I want to do with Meanwhile in Security is to show people what happens when there is no bias. Because this is about what is good security? What is good methodology? And most importantly, one of the things that I've always done is teach somebody how to understand the basics. Because if you know the basics, you can derive an answer. You can re-derive if you can go back.

If you know the how and the why, you understand where it comes from, then you can make your own decisions, your own informed decisions. Even if you're not an expert in something, you know what kinds of questions to ask. You know what kinds of things to look for, whether you're asking that question of your systems or of your vendors or your coworkers or yourself. I do want to talk a little bit about our sponsorship policy on Meanwhile in Security. We have something very similar here on this show,

but with you, it's been much more explicit and drawn out. You don't know who's sponsoring any given episode or issue until you see it come out. We are building a hard firewall between you and anything sponsorship-oriented, which means you have no idea what vendor is going to appear above or below whatever it is you have

to say that week, which absolutely could lead to really interesting stories. Theoretically, if, I don't know, vulnerability scanners are bad, is your entire thesis one week. And this episode is sponsored by a vulnerability scanner. That's going to be an interesting juxtaposition, and we may have to make some apologies, but it's the way to do it because you aren't shifting your coverage based upon who's paying us. I never have either, but in your case, we're making it far more explicit. Yes, absolutely. One of the things that's very important to me, which is one of the reasons why I like working with you and your CEO, Mike Julian, is because it's a strong code of ethics, a personal code of ethics. And part of that is that I also come from sort of a tangential to a journalistic background.

I worked at a newspaper. It's where I met my wife when she was a reporter and editor there. And it's important to have the firewall between the journalistic content and the advertising content. I don't want to know who's advertising. It's not relevant to me. What's relevant to me is me producing the best possible content I can to deliver the message, to educate, train. I had so much incredible amounts of help in my career so far to give me the success that I have found. And it's my turn to pay it forward. And just like I pay it forward in other community things that I do with nonprofits.

And that separation is extremely, extremely important to me. And I thank you for that. Of course. I want to just be very clear as well that there is a vetting process that we put sponsors through. We don't usually talk about it directly with them because we politely decline to pursue anything further if they don't pass through it. But fundamentally, I take a look at their site in the abstract and, okay, let me understand what this product does. And I dig into it a bit. And it's a relatively low bar, but there has to be a problem that I can imagine or conceive of where, yeah, this is the right answer for that problem.

If I think about that problem, oh, this would be a terrible solution for that. I don't like anything about what they're doing. I mean, I can always make more money by talking to different sponsors. I can't recover credibility that I've lost by recommending garbage. And while a sponsorship is not an explicit recommendation, it appears next to my name. People are going to associate us on some level. So I make it a point to not do business with companies I feel the need to apologize for on a consistent, ongoing basis, with the possible exception of whoever names AWS services. Yeah, that was a good one. Yeah, one of the things I find really important is to always remember, and I'm glad you mentioned it indirectly. At the end of every day, if your entire house burned down, your company went bankrupt, and there's nothing left whatsoever, all you're left with is yourself, your family, your friends, and your reputation.

That's it. All this other stuff can go. It can be replaced. And so standing on the code of ethics and putting your best face out there and standing behind everything that you say and do is extremely important. Some people need dozens of tools to visualize their stack, but not you. You've got New Relic Navigator. All your hosts, services, containers, and anything else you can monitor and probably shouldn't be but are monitoring anyway are in one dense hex view, so you can check system-wide health at a glance, and you can sort by platform, service, app, what pet a team has, or any other tag you happen to have given it, which makes it easy to navigate your entire system and see what needs your attention. Go to NewRelic.com, get started for free, and tell them I sent you

because I love inflicting my personality on others. It's one of those areas where you can't regain trust after it's been lost. It's one of the things that's true in business. It's true in security. And people will forgive implementation challenges, but they won't forgive you attempting to rip them off or you making trade-offs about their security so that you can do something you need to do faster. It comes down to messaging, and I think that that's something that gets very much lost. I mean, I take two of the security sponsors that I've had on my existing shows, namely ExtraHop and Lacework. They're both solid companies who do really interesting things. I've, in both cases,

I've used demos of their products in my own AWS accounts, and I see the value of it. Oh, this is actually extraordinarily helpful. But I wanted to look at those things before I accepted it, just because, especially in the security space, it feels like the RSA Expo Hall

is a never-ending sea of primarily the same company with different logos and different marketing phrases selling what for all the world appears to be the exact same thing. Oh, and the security in any industry is bad, but in terms of trying to figure out what's what and who's the right vendor and what things are available. But cloud security, it's a murky morass of unknowns because it's something that's not actually been explored enough. And there's a lot of great vendors doing really great work in SaaS offerings as well as observability and security related to that. But you got to figure that out. Going into RSA or Black Hat showrooms, you just look at a sea of what do they all do and why are they different?

And that's the problem. You walk in there, if you don't know who they are, you don't know those vendors, it's hard enough to figure out when you're somebody who does this all day long. So I'm hoping to demystify some of that in terms of understanding the technology. Then you can go ask all the vendors all the questions you need to, to be able to find out what they're doing and why they're doing it. And especially moving into the cloud infrastructures, you know, companies are doing the lift and shift and going hybrid and before they go cloud native, it's really important. We talk about people being on one side or the other of a security divide, but one thing I see where it makes that the most clear for me is I look at various security vendors' websites, and some of them explain in reasonable terms what it is they do. And that's great.

No argument here. I might, I don't know, argue about a word choice or something, or maybe there's a better story. Fine. The others are incomprehensible to me. It is very clear they're written with the CISO in mind, who speaks in specific phrases around very specific compliance requirements or very specific terms of art in the InfoSec field. It feels almost like a CISSP is a prerequisite for an awful lot of the marketing material to even begin to make sense. When I look at something and I don't understand it, I feel like I am not the target market, which on some level I cheat and just take a shortcut to, and therefore it's probably crap, which is unfair. But it's very hard for me to see how those offerings are being articulated to the people who could actually benefit from them, assuming they're good.

Well, in a sense, it's the same problem that you solve is I look at an AWS bill and it just baffles me. You know, it's like, well, do I start drinking now or later? Instead, there's somebody who's an expert in that that can help somebody guide through that path. And I hope to be a little bit of that guiding light. And one of the things I think is important for people to, and you mentioned earlier, people need to remember, security and cloud security are one and the same, but there's an added layer.

In a data center, you can lock the door, and you can put really, really, really fancy good locks on it. It will really raise the bar up high to barrier to entry. So somebody has to be able to understand physical security, get through, get into your data center, or they can go through the network. So now you can secure the network. All your normal security things apply.

In the infrastructure you have on the cloud, there's all the cloud infrastructure that is remotely accessible. So your entire data center, effectively for you as the cloud consumer, you have all that extra layers of security. So security is the same, plus you have to deal with the cloud security.

It's really, really important. In fact, it's more important to have cloud security, it all is the same, plus you have to deal with the cloud security. It's really, really important. In fact, it's more important to have cloud security infrastructures have better traditional security mechanisms than it is for traditional on-prem solutions. I argue on some level there's a bit of an alignment there where you can save an awful lot of money by turning off things you're not using with the simultaneous argument that it's really hard to exploit something that's been turned off. Not impossible, I'm told, but still harder to do than most. And there is a spiritual alignment

of worshiping at the altar of the church of turn that shit off that I feel security and cost folks can align on. Absolutely. And especially when you're starting looking at like containerizing things and cloud native apps, you don't have to secure something if you never write it. Oh yeah.

And another approach that I find that is very similar from the security world and the billing and governance world is you talk to companies across a wide variety of industries, levels of sophistication, et cetera, and no one believes that they've gotten their cost attribution right or they're billing exactly to where it should be or their security posture where it needs to be.

Everyone believes that they really have a lot of work to do to catch up. No one looks at this and says, oh, I've nailed this. I'm doing great, except for people who are painfully naive. Yes, absolutely. And one of the things that comes up often is compliance, compliance, compliance, compliance. Is it PCI? Is it ISO this, ISO that?

Is it NIST this, NIST that? Is it FERPA, FISPA, HIPAA? Or things like in Europe, GDPR, which is actually affecting all of us in the US and everywhere else in the world because we all have European citizens looking at our things or using our products and services, or we have people working and living there. Yeah, that is a weird law that is frankly a little, I want to say overbroad in some respects. I care deeply about privacy and security. This stuff is important.

I built a custom link tracker for my newsletter, for example, that will tell me the number of unique newsletters that were sent out that have been opened and which links within them have been clicked without ever telling me what you have opened or you have clicked on. honest, I do not care, and I struggle to find a way to care less. Because I want to know, of all the links I sent out last quarter, which were the ones that were the most appealing to the point where people clicked on them and dove into them? That helps me build things like best of issues. It lets me look in the aggregate and say, okay, I don't care about IoT, but the rest of the world seems to, so I'm going to have to continue to cover it. Versus, I don't care about Windows stuff, and it looks like the readership doesn't either. Thank God, I don't have to talk about it much. It helps me inform opinions around what I should write about

because I do have an audience. I want to appeal to them. But being able to run a little bit of analysis on that in a privacy-preserving way is super important to me. But all of the tools that you can look at for sending out newsletter stuff is deep in the weeds of, oh, and then we can track them across the internet

if you want. No, I want you to not do explicitly that. A lot of the stuff that Basecamp with DHH and their hey.com stuff appeals to me at a deep level. I feel like every time we have any form of tracking that should have above it in bright letters, we are going to be watching what happens with these links

because that is fundamentally what it means. And most of the time we don't need that. So why do we do it? Oh, absolutely. And privacy is one of the things that's near and dear to me too. I'm also the principal of a small nonprofit school that I founded with my wife and another woman.

And I want to make sure that the things that we use and the services we use at that school have no school information. I'm okay with somebody knowing that this customer did X, Y, Z, as long as it doesn't tie back to individual information. Otherwise, we have FERPA violations, et cetera.

And so compliance has always been important to me. I've worked in support of just about any kind of compliance you can imagine, including in classified spaces before. And I think that that's one of the morasses that's really, really confusing is how do you do really good data-driven business, but yet maintain privacy of both your employees and your customers?

That's really what it comes down to, is you need to be able to have a functional business. We do a best effort job on our side to comply with it, but to dot the I's and cross the T's on this would effectively require a full-time person whose job is nothing other than maintaining a lot of these compliant systems. And, I mean, again, we have a list of what information we have about individuals who subscribe to the newsletter. For example, what IP address did they sign up from? We recapture that because I believe that's a requirement. And what PII do we have on them?

Well, in our case, we have their email address. Well, why do we need the email address? It needs to be a valid reason. Because it's hard to send you an email if I don't have your email address. Yes. Okay. And did they click the confirm option

on the email that we send out to validate that this really is their email address? Yeah, without it, they never show up at all. And great. Then we have a record of what was sent to them at various times. And when they unsubscribe, that shows up too. There, we have now disclosed everything we know about what you do tied to you. And I think it's important to point out that that is actually harder to do than you just list it out because- Well, what I just talked about is the ideal. What we actually have, because ESPs don't really offer a way to disable this,

I can look at what newsletters you've opened, I can look in their systems at what links you have clicked on, and that is a problem. And there's no good way to disable that with our current ESP, but the saving grace is that their interface is so terrible for looking at these things that no one ever does. And we restrict access to this, obviously. It's not useful for us. And it definitely goes to show that, okay, what's the value of all this surveillance? The answer here is not much. Well, also, I think there's a different aspect of it, too, is what is actually

legislated compared to what has been tried in court and proven realistic. I remember when I worked at AT&T, I was at SBC at the time, pre-merger, and my team was part of the first SOX audit, Sarbanes-Oxley Act. We had no idea how bad things would be. We didn't know if we're going to get in trouble. So we did all this work internally. And then when we finally got to get in trouble. So we did all this work internally. And then when we finally got to the official external audit, turns out things were just fine because we were paranoid about it

for, like, nine months. Yeah, it turns out that it's super easy to wind up inadvertently setting a foot wrong. And I looked at all of this when it was first coming out. And again, we did a best effort attempt to do all of these things, and we didn't do the dumb things, like assuming that an IP address is indicative of whether someone is considered an EU

citizen. Great, yeah, that doesn't actually work. Who knew? And again, we weren't tracking all this stuff to begin with, but it's just one of those areas where, yeah, I want Facebook and Google and large companies that are doing tens of millions of dollars a year in ad business or more to absolutely have to do these things. But this stuff also applies to rando hobbyist newsletters with a Patreon donation link in them. And where do you start and where do you stop? Yeah, and a good example there, too, is school regulations. I have an actual school in the state of Tennessee, and it's a legal school. We have a full-time teacher, and we're subject to all the same regulations and laws and inspections and data privacy for the FERPA Act and things like

that. And it doesn't matter that we have eight students in one classroom. It doesn't matter. We have the exact same burden as a large-scale district with 10,000 students. And so how do you implement that in a way that's reasonable? Same thing with HIPAA. If you're a single doctor and you do all of your own bookings and you have one room you use, like a therapist, for instance, you're still subject to the exact same requirements as Kaiser Health. So how do you navigate that? I'm hoping that we can help solve some of those things. And if you think about it in meanwhile and security, we'll take it to the side and have a little fireside chat about how you can figure that out

by knowing the requirements and how they are in both the legal and spirit of that law. And that's how you learn. That's really what it all comes down to is learning, learning as we go. And that's the goal of this podcast. Some weeks we do a better job of teaching folks things than others. At least if the takeaway here this week is sign up for Meanwhile in Security at meanwhileinsecurity.com. But also the newsletter, it's about educating people about what's going on in the world. AWS says that reInvent is a conference primarily about education, and I get that.

I can see an angle from which that is true. The problem with reInvent is it has no idea what it wants to be and thus no sense of itself, so it tries to be all things to all people at all times, and it turns out that's a really hard list of boxes to check. Absolutely. That's why you should pick a narrow focus and go for it and do it right.

Exactly. And in our case, we're doing that with explaining security to practitioners who have other work to do. And we're going to have a little fun. We certainly are. Where can people sign up once again? Meanwhileinsecurity.com. And of course, the Meanwhile in Security podcast is also available

wherever you get your podcasts from. If it's not there quite yet, let us know. By the time this airs, it should be everywhere, but it seems like there's a new podcast platform every week, and it is increasingly difficult to catch them all. Let us know. Jesse, thank you for taking the time to speak with me. As always, it is appreciated. Thank you very much, Corey. I love talking to you.

It's always a good time, and I look forward to Meanwhile in Security helping others learn better about security. Jesse Trox, the new author-slash-editor of Meanwhile in Security. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry and

insulting comment about why I truly don't understand the true meaning of InfoSec if you can manage to get the comment posted through the filters against racial slurs. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at ScreamingInTheCloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.