Screaming in the Cloud - The True Spirit of Compliance with Nickolas Means

Episode Date: June 13, 2023

Nickolas Means, VP Engineering at Sym, joins Corey on Screaming in the Cloud to discuss how Sym is looking to solve the most common and most frustrating elements of compliance. Nick reveals why he finds it valuable to focus on making it easy for people to do the right thing over preventing them from doing the wrong thing, and why he feels the true spirit of compliance involves helping teams collaboratively come up with mutually beneficial solutions. Corey and Nick also dive into the common problems that engineers experience as a result of traditional compliance methods, and why historically the compliance industry has gotten a bad rap. About NickolasNickolas Means loves nothing more than a story of engineering triumph (except maybe a story of engineering disaster). When he’s not stuck in a Wikipedia loop reading about plane crashes, he leads the engineering team at Sym, helping create the building blocks engineering teams need to build delightful developer access and approval workflows.Nick has been leading software engineering teams for more than a decade in the healthtech and devtools spaces. His focus is on building distributed organizations defined by their cultures of high trust and autonomy. He’s also an international keynote speaker, having shared his unique brand of storytelling with audiences around the world. He works remotely from Austin, TX, and spends his spare time going on adventures with his wife and kids, running very slowly, and trying to brew the perfect cup of coffee.Links Referenced:symops.com: https://symops.comTwitter: https://twitter.com/nmeans

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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. Developers are responsible for more than ever these days. Not just the code they write, but also the containers and cloud infrastructure their apps run on.

And probably the billing on top of that, which is neither here nor there. And a big part of that responsibility is app security from code to cloud. That's where Snyk comes in. Snyk is a frictionless security platform that meets teams where they are automating application security controls across their existing tools, workflows, and the AWS application stack, including seamless integrations with AWS CodePipeline, Amazon EKS, Amazon Inspector, and several others. Deploy on AWS? Secure with Snyk. Learn more at Snyk.co slash scream. That's S-N-Y-K dot C-O slash scream. And my thanks to them for sponsoring this ridiculous nonsense. Lands of the late 90s and early 2000s were a magical place to learn about computers, hang out with your friends, and do cool stuff like share files, run websites and

game servers, and occasionally bring the whole thing down with some ill-conceived software or network configuration. That's not how things are done anymore. But what if we could have a 90s style LAN experience along with the best parts of the 21st century internet, most of which are very hard to find these days. Tailscale thinks we can, and I'm inclined to agree. With Tailscale, I can use trusted identity providers like Google or Okta or GitHub to authenticate users and automatically generate and rotate keys to authenticate devices I've added to my network. I can then share access to those devices with friends and teammates or tag devices to give my team broader access. And that's the magic of it. Your data is protected by the simple yet powerful social dynamics of small groups that you trust. Try now. It's free

forever for personal use. I've been using it for almost two years personally and am moderately annoyed that they haven't attempted to charge me for what has become an absolutely essential to my workflow service. Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends over at Sim and into my verbal gristmill. They have thrown their VP of engineering, Nicholas Means. Nicholas, thank you for joining me. Thank you so much for having me, Corey, and feel free to call me Nick. I certainly shall. So let's begin at a high level. When you're starting a company and trying to sort of bootstrap and raise initial rounds of funding and the rest, you're trying to save money in a

bunch of places. And one of the most expensive things you can buy when starting a company is, of course, a vowel. You wound up not naming the company with a vowel, really. The Y is sometimes a vowel, sometimes not. It's S-Y-M. What is it you folks do exactly? Where do you folks start? Where do you stop? So the name of the company comes from the idea of helping humans and machines work together more effectively. And that's really nice and high level. It doesn't tell you any information about what we do. It feels like we assume that most startups pivot at some point. We're just going to set the scenes for that nice and early on and dive on in.

So what we actually do, the two co-founders and myself all have a background in highly compliant industries. I've done VPN stints at a couple of health tech startups. They've done similarly. And all three of us ended up building sort of a certain set of things every time we were at one of these companies. Because you have to be compliant with things. In order to be compliant with things, you have to have a set of controls. You have to restrict certain things, how people get to production, how people access customer data. And those controls, by and large, all suck. They're all painful. And every company ends up building something from scratch at some point to make them not suck quite so bad. And it seemed like there was a product opportunity there. I would argue there absolutely is. One of the big problems that I've found throughout the time that

I've been fixing AWS bills on a consultancy basis has been, we're really talking about cloud governance. But even now, by using the phrase cloud governance, three quarters of the audience immediately wound up skipping to the next podcast over on their playlist because it sounds like it is one of those incredibly boring things. And to be fair, usually when it comes to compliance, you want some of the most boring,

least creative people in the world overseeing that. Like when you wind up talking to someone at a company, they have a great sense of humor and they are constantly cracking jokes. Constantly like, what are you doing? Oh, I'm the CFO. All you hear from that is, oh, I'm about to go to prison. Awesome. Like you want the wild cutting loose CEO to have three drinks and then confide. I really like typing the number six. Awesome. Like you want the wild cutting loose CEO to have three drinks and then confide, I really like typing the number six. You want them to be predictable in a whole bunch of ways. And it always feels like compliance takes that entire mindset of it's always about risk management. It's about wanting to make sure that people don't go off script in a bunch of weird

ways. But as an engineer, what I always heard from that is slow down, don't be creative, go ahead and do things in very predictable ways, only release things once a quarter, et cetera, et cetera. And yes, that's one way to meet compliance goals, but it's a crappy way in my experience. I'm going to guess though that you have a lot more experience with the compliance world than I do because having worked a few times now for big regulated finance companies, I wanted to get the hell out of the compliance universe. Yeah, I mean, you used an interesting turn of phrase there. You used the phrase avoid going off script. I think there's a subtle turn there that actually makes all of this work a lot better. Instead of focusing on keeping people from going off script, you focus on keeping

them on script. You focus on making it easier to do the right thing than to do the wrong thing. And that takes away a significant amount of the pain involved in compliance stuff. You look at implementing controls, and everybody has the exact same reaction you just brought up about governance, because there's so much fun around this stuff. Everybody has been slowed down by one of these silly rules that makes no sense, that's checking a box and not actually meeting the spirit of any kind of meaningful improvement. Oh, cloud has absolutely doubled our speed of iteration, because it used to take six weeks to get a server racked in the data center,

and we moved our processes to cloud. And now to spin up an EC2 instance, it only takes three weeks of approvals. And at that point, it's what are you really doing? You wind up with people building on shadow ideas. But part of what contributed to the rise of cloud in the first place? Well, I can go through the annoying thing that this company wants me to do, or I have a corporate credit card. And by the time it raises the level of spend to a point where it gets scrutiny, it's in production serving customers. And what are they going to do? Some of the very early AWS sales conversations

with customers started off as, well, why should we build on top of your cloud? Asked the exec and they say, oh, sorry, you have 87 different accounts throughout your organization currently with us. We're just trying to give you some unified view and do it and possibly some discounting if you want. Yeah, these days it's a fast track

to getting yourself fired in some companies if you wind up deviating from that story. But also, people are not doing this out of malfeasance. They're trying to get their job done. And as soon as guardrails start increasing friction, making it harder to do things the right way than to go around it, people will not comply. I strongly believe that, whether it's cost, which is my universe and frankly only a business hours problem, or actual governance issues with some compliance regimes, which get those wrong and hope you enjoy some time in prison. Yeah, exactly. I mean, you know, if you look at SOC 2, for example, there's a lot of companies out there that are willing to sell you a program that will help you become SOC 2 compliance. They show you all the steps you need to take, all the programs you need to put in place. The thing they don't do is help you establish the controls that are

required. They'll tell you that you have to have somebody formally approving before software goes out to production. They won't give you any guidance whatsoever on how to put that control in place. And so it's really easy for a compliance person that's not looking to collaborate with engineering just to go, okay, I need you to put a button in the deploy process, and I need the CTO to click that button. Yes. We've always seen that as reactions to different things. I have us at a company once where there were some outages caused by bad deploys. So they decided that a VP had to sign off on every deploy.

Now, I come from the SysAdmin ops world, which explains so much about my cynical perspective on life. So the way we got that overturned within two days is we did the malicious compliance thing where, oh, we need to deploy this. Great. We are walking into the middle of a senior leadership team meeting to get them to put a tablet or computer. I need you to click the button right now. And doing that out of hours and all kinds of other things, it's, oh, yeah, how about we wind up only doing that for a significant large changes? How about that? Maybe you don't need to wake someone up at home in the middle of the night when there's a deploy going out that fixes a typo on the marketing page. Little things like that. And at some point,

it always felt like the goal of governance was either ossified scar tissue around all the ways that things have failed before, or through a frankly misguided belief that if we wind up distilling everything down to processes and procedures, eventually, someday, we can have a bunch of trained monkeys doing this job instead of people who are expensive and, you know, cynical and difficult to please. I feel like that is not the right way to think about these things. Well, I mean, the thing about those controls, it's exactly what you just said.

Nowhere in SOC 2 does it say that your VPN, your CTO, has to approve all code deploys. That's not in there. But that's the reality of life at a bunch of companies. In reality, if you just follow a software development lifecycle that has multiple people looking at code before it gets deployed, multiple people signing off on that code being okay to deploy, and you have a staging environment before you have production, you've met the control.

And SOC 2 gives you so much flexibility in how you write the control. So I think the thing that I've seen that makes compliance so much less painful is when you have somebody that is 95% the boring persona like you're talking about, but 5% creative, 5% willing to kind of get their hands dirty, empathize with the engineering team, collaborate with the engineering team, and find a way to put some of these controls in place that doesn't just bring things to a grinding halt. I have to assume that given that you've built an entire product slash company around this idea, that you have some opinions other than doing what I do, which is sitting in my lofty ivory tower and, oh, you should, in this idealized case, do things a little bit differently. But it's going to be bespoke. And the answer to any complex question, the more senior you get, is it depends.

You, of course, have built something that scales out in a bunch of different ways. How do you view that in a way that makes it not either completely useless or overly prescriptive? We focus on giving the power to engineering teams and giving the security and compliance people that work with them the power to oversee those things. You know, it'd be easy to give somebody like a click box UI, let them design controls for SOC 2 or whatever, and a user interface, but that's not how engineers think. Engineers think and express ideas in code. So we've made the rather controversial decision in the face of a bunch of no-code tools

to go low-code instead. So to build a compliance workflow in SIEM, you're going to write some Terraform. You're going to write a little bit of Python, a lot less than if you were building it from scratch, but you're going to end up with something that perfectly fits the way that you already work versus having to shift your work practices around to fit the tool.

You have inadvertently stumbled upon one of my hot buttons. There's a lot of people that take a perspective around low code. And I just want to say that that perspective is often garbage. Like, oh, that's not real program. Great. Hypothetically, if you have an idea for a business or a product or something, and it involves software, as most things seem to these days, maybe having to go to a boot camp for six months first as a prerequisite is not the best path forward. Well, you're never going to build something hyperscale in a low-code environment. Great. How many things have we built that actually need to be hyperscale that don't go

through 16 different architectural iterations between ridiculous idea one day and thing that is actually hyperscale? It's an early optimization. I have an entire production pipeline in Retool that I built using low-code. I think that that is a very powerful thing. And this idea that, oh, that's not real code, cool, what's your point? Well, and for us, one of the things that we're trying to enable

is for software engineering teams, ops teams, whoever's building these controls, to interact with a security person or a compliance person for them to be able to read the code, understand what it does, understand the way that the control has been implemented. And so we provide a bunch of frameworks around that, a bunch of things. Like you don't have to go and build a Slack workflow from scratch, and nobody has to understand that code because it's buried in the platform. The only thing that the security or compliance person has to understand is the business logic that's been put into place. Who can approve it? Who can't approve it? How does

that change after hours? How does that change if there's an incident? All of that is in very simple Python that you don't have to be an experienced programmer to be able to read. One of the big powerful things behind that is it really reduces the interrupt volume of someone coming by to an engineer who is deep in the middle of something else. And hey, guess what I have? A surprise contact switch for something that's going to take you probably 30 seconds, but then you're going to be distracted by all of this. If you give people the ability to self-serve, everything tends to work a lot more smoothly. Yeah, absolutely. And that's one of the ways we use SIEM at SIEM. We've got it in front of our

AWS production environment. So if you need to go and do anything in production, you just have to get approval from any other engineer that happens to be in the approval channel. Sort of a two keys to launch a missile model. And that works fine for our compliance needs. And it avoids there being a single point of failure that every time you need to go and get into production, you have to go and say, mother, may I?

Exactly. It's one of those things where every time you wind up with something that injects friction, people are going to find ways around it. And in some cases, this leads to positive outcomes, where when you're subject to PCI, which is a lot more prescriptive than a number of other compliance regimes, it's great. This is a lot of things that don't necessarily reflect how we work, how we want to work, etc. We can ignore it, which is not a great plan. We can wind up having to slow everything down, which is the common case. Or the right answer is we're going to build the PCI environment that is very self-contained. Just the critical stuff that needs to be in there is going to be in there. And then we can build everything that touches it around it in ways that are a lot more aligned with how we believe

software should be built. Yeah, absolutely. I mean, you silo off those high control places, but there are controls that have to extend into the rest of the business. And one of the things that I'm a very firm believer in is if you're going to impose a control upon somebody, they need to have the agency to shape and to change that control so that it lets them work the way that they want to work. I just want to call out how wonderful that is because I had a belief that looked borderline heretical 12 years ago when I said that, okay, simple rule. If you want me on call, I am empowered to change the thing that wakes me up. Whether that is the code itself, the system itself, the paging threshold and frequency, or ultimately, I'm turning the physical pager off. It's one of those things where I decide what's an emergency outside of hours on that point. And if it's going to wake me up, I need the power to

make sure it never does. Otherwise, you have no agency. It just feels like you're being victimized by the stuff. Yeah, absolutely. I mean, there was a wave of on-call regimes that ran through large companies for a while where there would be a centralized on-call team that would be responsible for responding to hundreds of services. And thankfully, we are maturing past that. We're distributing on-call rotation so that teams that actually build services are responsible for them. And it's the same mindset, right? If you're going to be participating, if you're going to be working with a system or working with a control, then you need to be able to change it. You need to be able to make it work the way that you think that it ought

to work. And in the context of compliance, you need to bring somebody along with you. You need to bring the person that's responsible for the controls that actually has to sign on the dotted line at the end of the audit period saying that we do all of these things. So you have to be able to explain what you're doing to them, but you have to be able to iterate. I have to ask, given that what you are building is going to have heavy involvement from engineering, how do you respond to the probably most common engineering objection I imagine you get, which is, well, this doesn't look hard. I could build this in a weekend. You know, it's funny. We joke that our biggest competitor is build-in-house, right? It's pretty easy to start looking at what it takes to build a from-scratch workflow in Slack to build a Slack app to understand the cost of building it in-house

because nothing about building an elegant user interface in Slack is easy or cheap. That API is difficult to work with and hard to get good user experience out of. And we've spent a lot of time polishing a lot of places in the platform. We've got good documentation. We've got a good SDK. We've got good integration with third-party services that make all of this stuff easy to do. And it does look easy on the surface. It does look like I can build it.

But we've had customers that have had that objection gone and tried to build it and come back because it's not as easy as anybody thinks. My biggest competitor for fixing AWS bills has always been Microsoft Excel. It's the, we're going to do it ourselves badly internally. Okay, great. That works for you.

Terrific. But very often it doesn't. I mean, I think a classic case study of this is in the terms of something that is well-designed, but is almost mind-bogglingly complex. And we're getting a case study in it this year is Twitter, because it looks from the outside, very simple. I wind up writing a thing and I hit the post button and it shows up in a timeline and then other people can subscribe to it or not and they see it themselves. That sounds like something you can build on a weekend.

And we look at all the ways it's now exploding and collapsing and having weird bugs that no one anticipated to realize, oh, this is a very challenging, very sophisticated application. But because it was well-designed at one point, it looks easy. Yeah. Yeah. It continues to run despite the fact that it's having less than a quarter of the staff that originally maintained it, maintaining it because those services were well-designed in the first place. They're resilient on their own and they're self-healing in a lot of cases. It's the same thing with some, you can build these tools in-house, you can build them yourself, but then you've got more software to maintain. Because once you build something, you own it forever. And the cheapest code is no code. The cheapest

code is code that you don't have to write. It's easy to look at a simple use case and understand a little bit of the cost of this. If you want a Slack workflow that gives you access to production and AWS, you can wire that up fairly quickly. Those APIs are not all that difficult. Now let's say you want to add an integration and where if you're on call in PagerDuty, you can get to production without having to get an approval. Okay, well now you've got a new API that you need to wire in.

And let's say that every time that happens, you want to open a Jira ticket so that you can record that that's happened. Well, there's another API that you've got to wire in. Whereas with SIEM, it's right there. It's a few lines of code to wire it all together. And it deploys in Terraform alongside the rest of your infrastructure. So you manage it the same way you're used to managing things.

It reminds me of my earlier career when I was deep in the configuration management weeds with Puppet and SaltStack, where the biggest competitor we had at any of those projects was always someone writing a bash script to do it themselves. And yes, you can do that, but then the requirements change, or you're going to hit a point of scale that was surprising. And one of the valuable parts of it is that when the future is uncertain, as it always is, having folks who work in environments that aren't just yours, who encounter a lot of those edge cases you're going to stumble into and can build things in is incredibly valuable. I don't think I've ever met anyone who ran an infrastructure that said, I would build it the same way if I had to start

over again. They always want to, I would fix these annoying things. Well, by having a product focused on a space like this, it's, yeah, today you can have that VP click the approve button inside the GitHub Actions workflow. Good for you. But when you get just a little bit further down the path, you aren't going to want to do that anymore. There needs to be some decision-making that builds into it.

And for certain high-risk changes, maybe a second person and so on. How do you build that logic engine? How do you build that workflow approach? How do you have a break glass thing for middle of the night when the site is down, et cetera, et cetera, et cetera. And that's exactly the sort of thing that I would expect something like Sim to get very right, just because there's always a bigger fish.

You've seen this ad fold before in other shops. And more to the point, if there's something I want to do as a part of this that Sim doesn't support, and you all look at me strangely if I ask how to do it, that's usually a good early warning sign that maybe there's something I'm not thinking about here. Because whatever the problem space is, I'm probably not the only person that has to do this. How are other companies solving for this? And it turns out that, oh, my copy of our SOC 2 report has a typo on it. That would explain a lot. That's a can instead of can't, never mind, or something like that. Well, and the flip side of that is also true. I mean, the interesting thing about working on something that is sort of wide open with

what you can wire up and build with it is we're always learning from our customers. We're always learning from the things that they're doing. And so, you know, when somebody approaches us, hey, we need to solve this particular problem. If we don't have a ready answer, we brainstorm and help figure that out. And to your point, that always extrapolates to other customers finding the same sort of thing useful.

The other bit of this that's really interesting beyond the iterability and the ability to kind of rapidly evolve these workflows is the auditability. It's helpful in a lot of these compliance regimes to have a third party tracking this data for you. So when somebody accesses AWS production, who approved that access? When somebody deploys code, who approved those deploys? Well, we sit there as kind of a third party on the side observing all of this, taking all these notes for you and piping them into

whatever audit tool that you want. So you've got that data long term, and when it comes time to audit, you've got all the evidence you need. It's already there, already collected. You don't have to go through and write a regex to parse a bunch of logs to get the information you need. And invariably that regex is always going to be different depending upon the log stuff. It's great having a unified central approach that is the trusted repository for this stuff. As you've been going to market and talking to your earlier customers and seeing the problems that you folks solve, what have you learned about the market space since you've gone into this direction? Because I feel like this is one of those products where you start designing

it thinking you know a lot about the space and you learn so much more just from the customer conversations and seeing that you can build the most finely crafted torque wrench in the world. And the customer complains because it turns out you built a crappy hammer. So I think that's been really interesting to me is how much use our Lambda integration gets. We have a lot of first-party integrations with things like IAM and IAM Identity Center and Aptible and a bunch of tools that you can interact with. But a lot of our customers have wanted to do very specific things inside their infrastructure and put those things behind an approval. And the Lambda integration turns out

to be a great Swiss army knife to do that because you can wire it up. It runs inside your firewall to take essentially whatever action that you need it to. And that gets a ton of use. Probably more than half of our customers have at least one Lambda workflow in production and I would not have expected that going in.

It's wild to me just how pervasive Lambda has become. And even from a compliance perspective, it's great because I'm like, well, it's a script that runs on a server somewhere. Yeah, it's immutable. It's version. There's a way to conclusively prove that at this invocation,

this is the code that ran the end with the following parameters done. There's no, well, looking at the timestamp on the file. Like, no, none of that nonsense. It's arguable that something that I have seen has been that Lambda is one of those rare technologies where you're seeing faster adoption in the enterprise than you are in startup land. Yeah, I would say that's true. I mean, it's so great for running undifferentiated workloads. I just need this one thing to happen really quickly, and I don't want to mess with standing up a server to run this thing that runs once a week. Okay, well, here's a computer that will run just long enough for you to run this thing and then go away. It tracks exactly what ran,

exactly when it ran, exactly how it got kicked off. And in our case, it has access to all of the internal AWS APIs that we wall off in our platform because we obviously don't want you using those things in the SIEM runtime, but you can do anything that you want to to your AWS environment from your own Lambda, and we will gladly provide the approval step ahead of kicking that job off.

Are you seeing people use Lambda-based workflows to manage on-premises things, or is it more heavily in environments that are already within the AWS boundary? The Lambda stuff that we see is almost entirely, I think it is entirely for things that are within the AWS boundary. I can't think of an instance when somebody's

managing something on-prem with it. I am increasingly discovering through the magic of Tailscale, among a few other things, that I can use that for things on-premises that talk directly in interface with my Raspberry Pi in the spare room, etc. Which is, I think some people call it hybrid, which is the business enterprise term for horrifying. Because it's a terrible pattern in some ways, but it's so convenient that it's so nice not to have to worry about some of these things from just an infrastructure point

of view. One thing that I think that AWS has done very well at, as they've evolved, has been with AWS Artifact, which ties directly to their own compliance reports, where in the early days when I was responsible for SOC 2 controls at a company, I found myself answering security questionnaires from vendors as if I was running in a data center. And sure enough, they wanted the Tor US East 1. And it turns out you can't really do that. Right. So now just pointing them to the stuff that comes out of Artifact, it's written by auditors for auditors, and they go away and leave you alone without having to explain your bespoke artisanal nonsense to them.

There's something very pleasant about being able to throw the lion's share of the work over to someone who already knows how to do it. Our audit period is ending here shortly, and I have recently been spending time in Artifact. So yes, 100%. It used to be that you would only be able to get those things under explicit NDAs. You'd have to talk to your account manager for every one. It was a back and forth process. And you didn't really know if what you were going to get was going to answer the questions that they had.

Now it's, you show up, you click things three times and you're done. The hardest part is sorting out which ones you need from the hundreds of things available with an artifact. It's like, okay, that's great. But this one is in Spanish for some reason, and that's awesome. But on some level, it feels like that should be an easy filter option. But yeah, no one ever accused AWS of building a good user interface. But once you get the thing you need and can pass it off, great.

Job over. It's one of my favorite services that most people who are what we know as happy don't know exist. Yeah. And that points to a larger industry trend, right? That companies are getting SOC 2 specifically earlier and earlier because it is becoming table stakes to be able to sell into other companies. They want to see your SOC 2 report before they're willing to work with you, before they're willing to let your software touch their infrastructure. And there is a lot of value in these compliance programs as essentially a stamp of approval that you're taking these things seriously, even with as much flexibility as SOC 2 has. Just the stamp that we've thought about these things and we have serious answers to them is a pretty important signal to be able to send to somebody

that's wanting to buy your software. We've toyed with the idea of going through the process ourselves because we get asked about it all the time, but it feels like the procurement processes that's wanting to buy your software. We've toyed with the idea of going through the process ourselves because we get asked about it all the time. But it feels like the procurement processes that ask us for it expect us to come in with a whole software suite and the rest. And yeah, if that's the world we're operating in,

it makes a lot of sense. We're a services-based consultancy. We come in as individuals. We have conversations with people and we talk about this and we have no right access to anything in your environment and give you scoped down permissions for what we talk to because we don't want the responsibility of that stuff. And a lot of companies get that intrinsically,

but there's occasionally a few you have to go round and round and round with. It just, it feels like it's one of those, okay, you're not quite there yet. You're trying to view everything through this very specific worldview. Maybe it works for your constraints and requirements, but I've never understood it. And I've learned the older I get, the more time I spend around this. I used to have such a negative perspective on compliance. And now it's, you know, everything's nuanced. There's a reason that these things are there.

It's not just a make work project for an industry that wants to slow everyone else down. It's there are risks here. These these things exist for a reason. There's a reason that you can go start Twitter for pets tonight and not be regulated. But the same is not true of first bank of Twitter pets. It's OK. Yeah. One of those things is going to require a fair bit of regulatory scrutiny. And as a society, we want that. Now, the counter argument that I don't necessarily want to get too far into is, should Twitter for Pets be regulated? And that's a can of worms that I think we'll leave for another episode. Yeah. I mean, it's, you know, the people that hate compliance the most are the people that are on the sharp end of compliance, the people

that are having to actually deal with the controls that are imposed upon them by these compliance regimes and by somebody who's taking a very literal view in interpreting the things that some of these compliance programs say that you have to put in place. And I think that's kind of bringing the conversation full circle. That's the thing that we want to change more than anything. If we can wave a magic wand and change the compliance universe, the thing that I most want is to help compliance and security people collaborate with their engineering teams and come up with mutually beneficial solutions. Things that actually, the spirit of compliance.

Oh yeah. My first PCI audit was a little bit of a challenge just because the auditor wasn't really conversant with anything that wasn't a large company. So they show up at our 12-person startup and, okay, where's the Active Directory? It's like, we don't have one of those. Okay, well, how do you authenticate to the Wi-Fi? It's like, oh, the password's on the wall. It's, well, what happens if I get on that Wi-Fi? It's, what can I do that I couldn't do from anywhere else?

Like, use that printer over there. That's it. Because everything else was the idea of the security boundary was built on identity, not on what blessed network you happen to be on. There was no special permissioning that didn't apply to the Starbucks Wi-Fi next town over. But that was one of those things where at first they thought this was a horrifying problem and they were not going to be able to certify us. And it turned into, no, we had a significantly advanced culture of security, compliance, oversight,

separation of duties, all the things you really care about. We just didn't have the trappings that that usually came across with when you're thinking about this or having the temerity to start a company longer than 18 months ago at a place that wasn't San Francisco on the latest version of a MacBook Pro running the bleeding edge version of Chrome. It turns out that there's a big universe out there. And not that there's anything wrong with either side of it until they start forgetting that not everyone operates the way that they do.

Yeah, I mean, you know, we talk about checkbox compliance a lot. And I think that's probably the biggest problem is there is a lot of checkbox compliance out there. And people have seen it not actually solve anything and just make everything harder. And so compliance gets a bad rap. For me, the one that I've been picking fights on social media about for a few years now is

encryption at rest in the cloud. Like, yes, you want full disk encryption turned on, on your laptops, your phones, your tablets, et cetera. Someone steals it from the coffee shop, you want to be out the cost of the hardware at the end. But if you can get a hard drive intact out of an AWS facility and then reassemble it with the right number of drives in the right places without, and it hasn't been encrypted, congratulations, you earned it. As far as I'm concerned, that's yours. You can keep it. Because AWS employees aren't able to do that, let alone third parties. But it is easier by far to click the box to enable encryption at rest and not spend half an hour arguing with the auditor and just get on with your day.

And recently in S3, for example, they wound up making that a default. Good for them. It's just, can we please focus on the part of the story that's relevant and germane to our business? Because that is not the threat model of modern attacks. Yeah, I mean, for a long time, how much of the internet ran on unencrypted HTTP, but it was being served off of an encrypted disk. Great. What have we solved? Oh, absolutely. It's wild to me. Even now, I still feel like there should be a reasonable way to handle, to handle, in fact, basically encryption between two points that doesn't depend on the third-party CAs with expiring CERDs and the rest. Dri drives me up a wall every time because it's always the

worst possible time. It causes the strangest issues. And there is something deeply and profoundly wrong with the fact that the failure mode from the user perspective between your connection is being intercepted by a third party and holy shit, this certificate expired two hours ago. Like those are very different use cases, but the scary warnings have trained people to treat them the same way. Yep. Yep, exactly the same.

I really want to thank you for being so generous with your time. If people want to learn more, where's the best place for them to find you? Yeah, so the best place to find out more about Sim is our website, simops.com, S-Y-M-O-P-S.com. And I should mention that Sim is completely free for teams of up to 10 people. If any of y'all out there listening, check it out. Please reach out. We'd love to hear about your experiences, help

any way we can. And if you want to get in touch with me directly, the best place to do that for now while it lasts is still Twitter. I'm on there as Nmeans. And we will, of course, include a link to that in the show notes. Thank you so much for agreeing to talk to me about all this stuff. I really appreciate it. Yeah, thanks so much for having me on, Corey. It's been a lot of fun. Nick Means, VP of Engineering at CIM. I'm cloud economist Corey Quinn,

and this has been a Promoted Guest episode brought to us by our friends at CIM. If you've enjoyed this podcast, please give a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please give a five-star review on your podcast platform of choice, along with an angry, bitter comment that will get posted in six weeks after you track down your elusive VP to click the approve button. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS.

We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.