How Security Teams Can Become The Hero with Andrew Wright, Director of Strategic Content at Snyk

(Intro Narrator at 00:00:03) Hello, my friends. Today, we're talking to Andrew, director of strategic content at Snyk, and we discuss how security teams can become the hero, the nature and causes of sophisticated cloud attacks, and how to go about solving culture issues in the workplace. All of this right here, right now, on the Modern CTO podcast.

(Joel Beasley at 00:00:32) This is the Modern CTO podcast. So why did you start the company?

(Andrew at 00:00:45) So as you pointed out, there's this long ago startup called Grasshopper that I had co-founded, which was in a completely different sector, which was more about grassroots advocacy. But our platform ran on Amazon Web Services around year 2009, 2010. So I became pretty familiar with AWS. But unfortunately, Grasshopper, or maybe fortunately, Grasshopper was not a success. And as I was winding it down and white gloving my customers off of the platform, an old friend of mine, Josh Stella, reached out to me and said, "Hey, you do the startup thing. I've got this idea and I want to bounce it off of somebody."

(Andrew at 00:01:28) An hour later, after a long phone call with Josh, I turned to my now wife and said, "I think I'm going back in one more time. I've got to do the startup thing." Because I'm not an expert necessarily at the time in cloud security, but what Josh was talking about sounded pretty compelling. And so we got together. We formed Fugue in 2013. That's when we became really official, and the rest is history, really.

(Joel Beasley at 00:01:57) And what does that name mean? What does Fugue mean?

(Andrew at 00:02:00) So a fugue is a type of musical composition, popularized by Bach. So if you think about baroque music, it's often a fugue. And essentially, to kind of simplify, what it means is you introduce a musical phrase, and then you continue to introduce variations on that phrase over time. And we feel like that's very much kind of how the cloud works. You know, you start with something and then you continuously deploy newer versions on top of that.

(Andrew at 00:02:31) And that's kind of the life cycle of an application these days. But where we stumbled on that is we actually had an early visualization of the Fugue product, which was really involved in, kind of think about immutable infrastructure patterns, which is, you know, never update or modify something. You replace it when you have a new version. But doing that on a schedule, and the visualization, somebody looked at it and said, "That looks like a Bach fugue, like a piano roll." And so that's how we stumbled on that.

(Andrew at 00:03:01) And my co-founder, Josh, and I are both musicians. So when that name kind of popped out there, we were like, "That's it. That's the name."

(Joel Beasley at 00:03:11) Nice. So then how did you meet the Snyk people? Did they just call you up and they're like, "Hey, bro. Want to buy your company?"

(Andrew at 00:03:17) So not exactly. You know, I think the conversation got started early on really with the adoption of infrastructure as code for cloud operations, if you will. I can, in a nutshell, describe what infrastructure as code is. But when you use cloud platforms like AWS, Azure, Google Cloud, typically, you would go into their interface, kind of their cloud console, if you will, and kind of click around manually to create virtual servers and networks and these kinds of things. And a number of years ago, maybe about half a decade ago, it really started taking off to use infrastructure as code such as Terraform or CloudFormation.

(Andrew at 00:04:04) What this allows teams to do is express in a language that the cloud provider APIs can understand. Express what your infrastructure environment should look like. All of the different components and services that you want in your environment. And then you run that against the cloud APIs to build everything in your environment. And so this is very scalable, shareable. You can create infrastructure environment templates at an organization. So it's a very efficient and consistent way to do cloud infrastructure operations. But what it also enables us to do is shift cloud security left pre-deployment and start really treating the cloud as it really is, which is just software. You know, a lot of people think of cloud providers like AWS as like a remote data center, and you can certainly treat it that way. But more and more as organizations are building and running applications natively in the cloud, they're treating the cloud just like a giant global computer.

(Andrew at 00:05:19) It's just software. We can program that computer, all of our infrastructure, modify it with code and secure that code, validate that what we're going to do is secure before we build it. So this is a really big sea change in cloud security. Typically, you know, the ops team, maybe it's the DevOps team, could build your infrastructure environment, and then the security team will come in and evaluate it, monitor it to make sure it's secure. So by securing it early, we can find and fix things when it's faster and easier to do so, just like we're seeing quite a bit with application security, and also just be more secure operating in the cloud.

(Andrew at 00:06:05) So this was an area that Fugue was heavily invested in, building out the ability to check your infrastructure as code for security and then check the end result, the running environment using the same policies. And so that was something that Snyk was interested in because Snyk is a real trailblazer in developer first application security. And now more and more application teams are treating their cloud infrastructure as just a part of the application. They also want to be able to secure the infrastructure side of things early in the development process. So that's how the conversation started.

(Andrew at 00:06:47) They were interested in what we were doing. I think we had very similar philosophies about security first, starting security with developers, empowering developers to make sure that what they're doing is secure and doing it with tools that work the way they work rather than kind of waiting until the developers deploy and then bring the security team in. Because it's not only less secure to do it that way. It's very inefficient and often results in a lot of really painful rework. You know, security team finds something late in the process. Sometimes fixing that isn't exactly easy. It might require a lot of rearchitecture or a lot of rework in the application.

(Joel Beasley at 00:07:38) Yeah. It could be super frustrating. You wrap up, you know, a change. You send it off, and then they come back, and you just have to redo the work. That was the first, before you said that, that was like the number one thing in my mind. Because when you describe this concept of security early, it just sounds like, yep. That's the most logical thing, but then it hasn't been that way for so long. And then when you describe the old way, it's like, "Oh, man. I'm so glad people like you are out there making tools to make developers' lives easier and companies more efficient too." It's not just developers' lives easier. It's the company itself is having less waste as far as time goes.

(Andrew at 00:08:17) And you'll see that too, the drive to shift security left into the development process primarily is driven by the developers. And in cloud security, it's driven often by the DevOps teams, the operations teams that are working in the cloud. Not so much to be more secure. Everybody wants to do their work securely, but their primary motivators are to get rid of these headaches that they're dealing with every day. So if you're a cloud infrastructure operations engineer and you're having to spend half your day, or, you know, somebody on your team is full time devoted to just dealing with the security tickets that are coming in from the security team and trying to figure out how do we remediate these, is the remediation going to make some kind of breaking change in the application? The rate of misconfigurations that security teams are finding in the cloud is so high that we found, you know, a typical enterprise cloud team that's operating at scale is investing, you know, 50 or more hours a week to just dealing with tickets in ServiceNow or whatever system that they're using, and they've got to go investigate these and remediate them.

(Andrew at 00:09:41) You know, give an engineer a manual annoying task, and their tendency is, "How can I automate this away? How can I program this problem off of my plate?" So that's what we're seeing with infrastructure as code, security, or developer security tools in a programmer's IDE. The motivation is I want to be spending the most amount of time as I can being creative, building things, creating value, not dealing with security headaches. So, you know, again, we all want to be secure, but the motivation for a lot of this is I want to be more productive.

(Andrew at 00:10:23) And what we are seeing too, organizations are finding when they really adopt these kinds of methodologies and improve their cloud security or their application security, they're finding it's easier to attract and retain engineering talent.

(Joel Beasley at 00:10:40) So is it set up in a way where, let's say, I'm the security leader of a company that has software engineers. Can I go into the tool and sort of set my requirements, or is it only what you guys deem necessary?

(Andrew at 00:10:54) Absolutely. So it's both, and it would not be only what we deem necessary. What you would get out of something like Snyk, Snyk Cloud primarily are like the compliance frameworks out of the box. So if you're primarily building and running a SaaS application on Azure, you might need to comply with SOC 2. Or maybe you have to comply with HIPAA or NIST or GDPR, any of the other compliance regimes.

(Andrew at 00:11:27) All of those compliance regimes have something to say about the configuration of your cloud environment, how data is managed, those kinds of things. And you don't necessarily want your team, unless they are compliance experts, you don't want them interpreting these rules. Because often, they're kind of nebulous, they're ambiguous, they're subject to a lot of interpretation. They're written in human language, and that's ultimately a huge problem with a lot of these kinds of rules. It's a binder or a PDF of a bunch of controls. But somebody has to go and say, "How do these controls apply to the cloud environment that I'm operating in in the context of the application that we're running?"

(Andrew at 00:12:16) And that's not a trivial task. And so what we do is we have experts that express all of these policies as code. So it's essentially policy as code libraries on our end that we make available to our customers. So you can just say, "I need to comply with SOC 2." And Snyk Cloud will immediately kind of tell you where you have issues and how to correct those.

(Andrew at 00:12:45) But in addition, most customers also have internal policies, you know, maybe additional security policies, rules on top of whatever compliance they have to comply with. And it might be things outside of just security too, you know, where we're allowed to operate, or, you know, are you allowed to use that mega cloud instance that's going to cost us, you know, a few grand a month. So customers can express custom policies as well and then vend those out to the team. So what then you wind up with in this kind of scenario is the security team becomes the domain expert on what's allowed and what's not allowed in their cloud environment. And with this policy as code, they're vending these policies out to the rest of their organization in a way where those software developers or cloud engineers, they have tooling that just ingests that and then just checks their work as they're working in the way that they're working.

(Andrew at 00:13:56) So one of the keys to empowering developers and engineers on security is you can't interrupt the way they're working. You can't break how they do their work. These kind of tools have to work in their tool chains, in their workflows if you want them to adopt the security tooling.

(Joel Beasley at 00:14:16) And so that's what Snyk Cloud is. It's all of those things together?

(Andrew at 00:14:20) Yep. Yes. Snyk Cloud being kind of one part of the Snyk platform. So there's Snyk application security, open source security, and cloud and container. So essentially, when you're using the cloud truly as a platform for building and running your own applications, again, you start kind of treating the cloud infrastructure as just another part of that application, and you want to secure the whole stack holistically.

(Andrew at 00:14:53) And what we see with cloud breaches, cloud attacks, is the attackers do not recognize or honor the arbitrary boundaries that we draw around things. So we might, you know, it's not uncommon to have, say, an AppSec team that's really focused on application security and organization, and then maybe a cloud security team that's really focused on the cloud infrastructure. Those teams might not be talking very much. And they might not be checking kind of the overall context of the security posture of their application and their infrastructure. But what we see a lot is the attacker might exploit something like Log4j and use that to gain residence in a cloud resource in the environment, and then from there execute a control plane compromise attack, which we should get into because I think this is something that a lot of teams are really missing. They're not understanding how cloud breaches are going down today, and they get sort of focused on this idea of misconfiguration as being the risk in the cloud.

(Andrew at 00:16:04) And that's technically true, but it's also missing a big part of the picture, and I think it's why we're seeing cloud breaches that are hitting some of the most sophisticated cloud customers out there, including cloud providers themselves. We've kind of long graduated from the negligence award kind of cloud breaches where, you know, an organization leaves all the sensitive data in an Amazon S3 object storage bucket, and they leave it wide open to the world. And, of course, somebody's going to come along and find that and steal the data and throw it up on the dark web or what have you. We still see some of that, but that used to be what we would see often in the cloud. Today, what we're seeing are pretty sophisticated cloud attacks where once the attacker gains residence on a cloud resource, maybe via an application vulnerability, it might be due to, you know, they found they got in through a misconfigured resource, or it might be source code, API keys and source code or on disk, a lot of different initial penetration vectors.

(Andrew at 00:17:21) But once they're in the cloud environment, they're after the API keys associated with that cloud resource that will enable them to operate against the control plane of the cloud provider. This is the same control plane that cloud customers use to build and run their cloud environments. But what that enables the hacker is, it's the keys to the kingdom kind of scenario. Because an attacker with that kind of access can discover all the knowledge they need about the environment, move about laterally, and then ultimately find the data they're looking for and extract it right out from under any kind of attempt at intrusion detection. Because these attacks are not traversing networks that can be tapped and monitored the way we would in the data center. Now I might find your S3 bucket that has data that I want, and I might just execute an S3 sync command and copy the contents of your bucket into a bucket in my account.

(Andrew at 00:18:32) Or maybe I find a database snapshot, and I just copy that into my account. And there's no intrusion detection. You might notice that this happens if you're monitoring your logs and analyzing your logging activity. But even then, it might just say, "Hey. Oh, no. We were breached." But you're not necessarily going to catch the attack in progress and stop it. So, you know, it's scary. I think we're all used to seeing headlines like "Company suffers cloud data breach due to misconfigured server." But if that cloud breach involved, you know, all sorts of customer data, maybe source code across multiple repos, all these kinds of different things that were stolen, we can all assume that all of that did not exist on the misconfigured server.

(Andrew at 00:19:29) So all we're getting from that headline is the initial penetration vector. But what we're not getting is this big middle part of the story of what did the attacker do after they got in and then ultimately making off with all of this data. And that's the control plane compromise scenario that cloud security teams really need to be focused on preventing.

(Joel Beasley at 00:19:54) Well, a couple questions. First, can you go a little bit deeper to how do they get your API keys?

(Andrew at 00:20:00) So there might be API keys that are left in source code.

(Joel Beasley at 00:20:05) Yeah. I know. I've seen people do that on GitHub.

(Andrew at 00:20:09) I mean, that's common. Or API keys on disk. The easiest way to prevent that from happening is just to rotate your keys on a very, very rapid level. Because what'll happen there is developers won't leave their keys in source code and use that as part of the application trying to do its work operating against cloud resources. That's just obviously the wrong way to do it.

(Andrew at 00:20:36) It's a dangerous way to do it. If you're rotating your source keys or your API keys, they're just gonna stop putting them in source code because they have no way of updating them. So you really need to be relying on key management services provided by the cloud providers to perform that role. So that's, you know, I wanna say it's a relatively easy fix to that kind of problem from happening, but we still see it happen all the time.

(Joel Beasley at 00:21:06) Yeah. You hear horror stories. I mean, I've been hearing this for a decade. Some novice person uploads their AWS keys to a public GitHub repo, and then someone just charges up a bill of $100,000. You know, that's not an uncommon thing.

(Joel Beasley at 00:21:21) I've seen it, I don't know the number specifically, but several thousand dollars. I've seen that happen more than a handful of times. So just to be clear, they will infiltrate a developer's machine or somebody who has a machine that has the API keys on it?

(Andrew at 00:21:36) Yeah. Or it could be in the source in GitHub.

(Joel Beasley at 00:21:39) Okay.

(Andrew at 00:21:40) Or, you know, I think the big takeaway for me is that there are a number of different ways that an attacker can find their way into your cloud environment. So essentially, design your cloud infrastructure environment with the assumption that attackers are gonna get in. And what you want is an environment that's inherently secure against the control plane compromise kind of scenario.

(Joel Beasley at 00:22:11) And what's the difference? What's the difference between an environment that I just spin up naturally and configure based off of need as a developer engineering team versus one that's designed to know that hackers are gonna come in here and somehow slow them down or make it difficult for them?

(Andrew at 00:22:27) Sure. So, you know, a good example would be an EC2 instance in AWS that has List S3 permissions on it. This is the kind of knowledge-gaining ability that can be very valuable for an attacker. So if I get resonance on a resource in your environment and then I, with that resource's roles and privileges, I can generate a list of all the S3 buckets in that environment. You know, chances are oftentimes, the names of those S3 buckets are gonna give me some clues as to which ones I might wanna check out first.

(Andrew at 00:23:08) So you wanna essentially strip down the IAM role, the IAM configurations for every resource, particularly the Internet-facing ones, to be the bare minimum required for that resource to do its job. And this is a hard thing for cloud engineers and developers to do because it's easier to just give them broad permission. So we kind of get into kind of a least privilege type of scenario. But yeah, you wanna make their job harder. So if they get into your cloud environment, they can't really see much.

(Andrew at 00:23:44) They can't move around to try to find what they might be looking for. They're gonna bounce more often than not because there's plenty of other low-hanging fruit out there, lower-hanging fruit than what you're providing them. So it becomes kind of a scenario where you don't wanna be doing the attacker's job for them. I liken it a lot of times to cloud environments being like, think of a castle with an outer wall. It's a pretty good outer wall, but every 50 feet inside the outer wall is a treasure map and a bag full of IDs that will enable an attacker to impersonate, you know, official castle personnel and move about the castle.

(Andrew at 00:24:29) And that's essentially what a lot of enterprise cloud environments look like. We focus on building taller, bigger, tougher walls to try to prevent any kind of incursion, but it's sort of like an M&M security. It's kind of this hard, crunchy outer shell. But once somebody gets in, it's a really soft security situation where they can move about.

(Joel Beasley at 00:24:54) How do you develop tools that, obviously least privilege is a pain in the butt for the developers because they need to get done what they need to get done, and it's just difficult. Right? Who's developing tools that are making least privilege easier for developers?

(Andrew at 00:25:08) Well, certainly, Snyk Cloud will be. And there is an open source infrastructure as code security tool called Regula out there. You can find it at regula.dev that can be helpful with this. At least find some of the more egregious kind of violations in terms of how IAM can be configured. But really, yeah, it's not always an easy fix.

(Andrew at 00:25:35) It's certainly less painful if you find these issues as you're developing infrastructure as code as opposed to an already running environment that might be rife with these kinds of violations. But the compliance regimes are typically not gonna flag these things as violations. So it really is incumbent upon, you know, either the cloud security team or the cloud engineering team to kind of go above and beyond what they might be required to adhere to from a compliance perspective to address these kinds of vulnerabilities. But yeah, you're right. I mean, there's like 700 IAM roles associated with EC2.

(Andrew at 00:26:23) And, you know, going and finding the right one for the job that you're trying to do is not, you know, it's gonna take a little bit of time.

(Joel Beasley at 00:26:32) Oh, bro. Do you just need global admin? Give it to every developer. Exactly. Yeah.

(Joel Beasley at 00:26:37) Alright. So all these things you're talking about are things that Snyk has tools to help with.

(Andrew at 00:26:43) Correct.

(Joel Beasley at 00:26:44) And then what's the website, and how do you spell it?

(Andrew at 00:26:46) It's snyk.io, S-N-Y-K.

(Joel Beasley at 00:26:51) And I wanna hear about this puppy named Patch. What's up with that?

(Andrew at 00:26:56) So Patch is kind of the mascot dog of Snyk. Obviously, Patch. You have to patch your servers. Right?

(Joel Beasley at 00:27:06) Dad jokes, dude. I love it. Exactly. And I mistakenly referred to this Doberman as a puppy. He looks like he's gonna protect your servers.

(Andrew at 00:27:15) Yeah. I think we're, you know, we're looking at also softening his image a little bit because Patch is really just a, you know, he's a family dog. He's not—

(Joel Beasley at 00:27:24) Do they have a physical, like, stuffed Patch dog in the office?

(Andrew at 00:27:28) There are. We do have some offices, but we're also a highly distributed team.

(Joel Beasley at 00:27:34) Nice. And so you guys made a decision to go mostly remote or fully remote?

(Andrew at 00:27:39) So Snyk, I believe, has been kind of a fully remote company from its inception in 2015, but there are some Snyk offices.

(Joel Beasley at 00:27:47) So there's the headquarters is in Boston, and then there's an office in London and Tel Aviv.

(Andrew at 00:27:48) As people from Tel Aviv, like, as small as they are, they're really stepping up on the stage for technology on the world stage. So—

(Joel Beasley at 00:28:04) Absolutely. And just, you know, a lot of security technology and security companies coming out of Tel Aviv for sure.

(Joel Beasley at 00:28:12) Well, because they have the mandatory service in the IDF. And they go into the IDF, and they're learning even if they didn't have, you know, from eight years old being a software developer. When they're getting into the service, they're like, oh, computers. That sounds cool. They're learning security, and they're getting paid to learn. And then they come out, and they're just like bright security people who, you know, know the different issues that exist at scale, which is honestly one of the hardest things.

(Joel Beasley at 00:28:36) The hard thing to do is to be in a position where you understand things at scale. So like me personally, I've never had a company with more than 30 people. So I don't know what type of problems people in the Fortune 500 are facing. And when I hear people come on my show and complain about some of the difficulty and the blockers, and I'm like, oh.

(Andrew at 00:28:57) Yeah. I mean, it's interesting too. So we just released the Snyk State of Cloud Security Report, which you can find at snyk.io. One of the things that I wanted to do, of course we kind of cover, like, you know, how bad is the problem and, like, a third of the organizations we surveyed suffered a cloud data breach just last year.

(Andrew at 00:29:18) So the problem is big, and it's kind of universal. But one of the things I wanted to get into was sort of, you know, beyond security. Like, you know, I've often said security is the rate-limiting factor for how fast teams can go in the cloud and how productive they can be. Because we have all the, you know, we have all these productivity tools. We have CI/CD.

(Andrew at 00:29:42) We have great IDEs, infrastructure as code to kind of generate at scale cloud environments in minutes. We can build a global network in minutes. But it's often the security concerns that slow us down. It might be the security team that says, whoa, whoa, whoa, whoa, whoa, you're going way too fast. Like, we need time to be able to review and certify that everything you're doing is secure.

(Andrew at 00:30:09) So I wanted to kind of dig into that, and what I found again was that cloud security is making it harder for teams to attract talent. You know, if you're a software engineer, do you wanna go work for an organization that kind of has a lot of this stuff solved and you're not going to have to focus a bunch of time on security? Or, you know, if you're a cloud engineer, do you want to go work somewhere that's going to force you to spend, you know, half your time dealing with manual security tasks? It's kind of a no-brainer. Yeah.

(Andrew at 00:30:39) Not interested. Right. What are the delays for deploying applications? What do those look like because of security reviews? Is it impacting your organization's ability to innovate and compete by slowing everything down?

(Andrew at 00:30:55) You talk about understanding things at scale. You know, typical cloud environment, an enterprise cloud environment might involve hundreds of thousands of resources that are changing constantly. How does any human or an army of humans wrap their head around that kind of complexity and dynamism at scale? And so these things are really not, you know, we can't solve the cloud security challenge with the tools and methods that we've used in the past. It's just not possible.

(Andrew at 00:31:30) And the security team can't solve these problems themselves. That's why, you know, we believe that security starts with the developers that are building the stuff in the first place. And if we can get security right as we're building it, designing it, and developing it, there not only will we be more secure, but the security team is actually able to scale their effort without having to scale up headcount. You know, we're able to get a lot more out of our engineering and development teams because they're just building. They're not being forced to worry about security as much as they were before.

(Joel Beasley at 00:32:09) So these are all the stats. Obviously, you know, you don't need to go stat by stat. What's one of the more interesting ones here?

(Andrew at 00:32:15) So one of the more interesting ones that I found was around kind of who's primarily responsible for cloud security. And if you ask engineers, cloud engineers, 49% of them say that the cloud engineering team is primarily responsible for cloud security. But only 19% of security professionals would say that.

(Joel Beasley at 00:32:39) Oh, really?

(Andrew at 00:32:40) Yeah. So what's going on there? I have some theories. I'd love to be able to go do a second round of surveys with these folks. But knowing what I know, what we see again is that engineers are just taking ownership over the problem because it's such a headache for them now that they're just setting about solving it.

(Andrew at 00:33:00) And again, what we found is when teams are using infrastructure as code and they secure it before they deploy, they're reducing misconfiguration by 70% and improving productivity by 70%. Median. The median improvement in productivity and the speed of deployment is 70%. That's a huge, huge improvement, a huge ROI.

(Joel Beasley at 00:33:26) Those stats make sense though because when it's their specialty, they feel like their specialty should be the ones that are doing it. And it takes time for the market to realize these tools exist and to trust them and for all that information to flow from developers and implementation to the actual security experts. Because you're right. They're engineers. We, as engineers, we solve problems.

(Joel Beasley at 00:33:50) They're like, oh, give me a problem. Right? Yep. So they're taking it into their hands, and then the security people are probably caught a little bit off guard by, like, hey. What's going on?

(Joel Beasley at 00:33:58) You know? And then do I trust whatever sort of system is behind whatever sort of policies, you know, this company has that are injecting and influencing my developers? That's why my first question to you was about do you allow the security people to come in and manage their own policies to some degree?

(Andrew at 00:34:17) So yeah. I mean, so when we look at, and we work with a lot of organizations that are moving fast and operating at scale in the cloud, it becomes kind of obvious when you're working with a lot of these organizations that there's some of them and some teams that are really getting cloud security right and others that are just really challenged. They're, you know. And what do I mean by getting it right? They're moving fast. They're reducing risk, that kind of a thing.

(Andrew at 00:34:46) And so I wanted to figure out, you know, what is it about these teams that are getting cloud security right? Like, what are they doing? Are there common traits among them that we might figure out and use to kind of do better and educate? And we did. I call it the five fundamentals of cloud security.

(Andrew at 00:35:11) And every one of these organizations that's really getting cloud security right are doing all of these things. And part of it is their security teams are embedding themselves with application development teams, with cloud DevOps teams. They're not just solely focused on, like, I need a tool that's gonna do a better job of finding issues in the running environment. They're learning about the software development life cycle for the cloud infrastructure environment. What IaC tools are being used?

(Andrew at 00:35:45) What's the applications associated with the infrastructure that we're trying to secure? Because they're focused on stopping from digging themselves into a deeper hole. If you are not trying to prevent misconfigurations and these kinds of design vulnerabilities from happening, you're just playing whack-a-mole. And you're focused on kind of finding better tools to play whack-a-mole, but you're not doing anything to stem that flow of issues that are reaching production or reaching the running environment. So these teams are spending the time learning what the engineering teams are doing and how they're doing it, and then figuring out how to build tooling into their workflows in a way that they're gonna enjoy, that they're actually going to adopt it and use it.

(Andrew at 00:36:44) Because you can throw security tools at developers all day long, and if it's not conducive in their workflow, they're just not gonna do it. And so you have to make sure that they're gonna enjoy it, that they're gonna appreciate it. They wanna do things securely. They just don't wanna have to change the way they work. Right?

(Andrew at 00:37:03) So policy as code, again, becomes kind of, I think, a big part of this because the nice, not only is policy as code a way to express policy in a language that other applications can understand and ingest and use to validate what they're doing is correct or not, but it gets everybody on the same page. So if both of us have the same rule binder of rules that we're supposed to operate under, not only are we gonna just have errors in how we interpret these things, but we're gonna have differences in interpretation. We're not necessarily gonna understand how they apply in different use cases and that kind of a thing. And the beauty of policy as code is it acts as like a lingua franca for security and compliance policy across the organization that the security team manages, but everybody can subscribe to and use in their tooling to get things right. So it becomes a way of distributing security and empowering other teams to operate securely.

(Andrew at 00:38:13) It's sort of a single source of truth.

(Joel Beasley at 00:38:16) I don't want to put you on the spot, but could you rattle off succinctly the five things they have in common, or is that not something that you have memorized?

(Andrew at 00:38:25) Oh, sure.

(Joel Beasley at 00:38:26) Okay.

(Andrew at 00:38:27) The first fundamental of cloud security that all of these organizations get right is they focus on knowledge. They know their environment. They understand everything that they have running in their environment, how it's configured, how all of the resources relate to each other. So they've kind of mapped this out on a resource graph, if you will. But they also understand how those environments are being created, whether it's infrastructure as code or a mix of infrastructure as code and kind of clicking around in the console. They understand the context of that infrastructure environment with the applications and the data that's in use in that environment. So that's one. It's sort of a know your environment kind of fundamental. The second is that they all focus on prevention and secure design. Essentially, rather than kind of having an intrusion detection mindset where we're focused on catching bad guys in the act and stopping them before they're able to do damage, these teams understand that that's not a realistic scenario for security in the cloud. So what we need to do is prevent the conditions in a cloud environment that make these kinds of modern cloud attacks possible, the control plane compromised. So how do we do that? We empower our developers, our cloud engineers. This is the third fundamental with the tools that help them design inherently secure cloud environments from the start.

(Andrew at 00:40:10) So the way to prevent and focus on secure design is by empowering those that are building and operating in the cloud with tools to do that securely. The fourth piece is the technology piece, and this is policy as code. You can't hard code these kinds of guardrails into your security tooling. It doesn't scale. It's hard to audit. But if your tooling is designed to ingest the policy as code libraries that you create and vend out to your environment, it becomes much more scalable for everybody to be operating on the same page with regard to policy. And if a change in policy happens, your policy as code can be in a repository. You have a change history there. You have a change management process for dealing with updating your policies over time. And if you update a policy or add a policy, you can now immediately see by adding this policy where in our overall cloud environment, or anywhere that we're operating, what just fell out of compliance? What do we need to address that's already running because we've added this new policy? So policy as code is number four. And then the fifth is that they measure what matters. And this is kind of, I would say, my takeaway from this one is that cloud security becomes ultimately a function of operational excellence. These teams, they know where they want to go, and then they measure religiously in a very disciplined way.

(Andrew at 00:41:53) So that might mean, you know, we want to reduce the rate of misconfiguration that's occurring in our environment, or we want to really reduce the time it takes for cloud engineers to be able to deliver infrastructure to the application teams by automating the process of validating the security of those environments, or, and then additionally, we want to be able to help our application teams deliver new applications or new features faster, or we want to make our engineering teams or our security teams more productive. These kinds of ROI stories that they attach to their cloud security program and then evaluate themselves on how they're doing against these different priorities. What you find oftentimes with organizations that kind of seem like they might be chasing their tail a lot and they're just challenged, they're not really able to kind of crack this nut, they don't even know where they want to go. Different teams have different ideas of what matters to them. Collaboration is a really big challenge.

(Andrew at 00:43:04) Organizations that are not really getting cloud security right, I guarantee they have collaboration problems. The security team's not working with the development teams. They might be using different tools. They might be using different frameworks for different stages of the development life cycle. These kinds of things, and you can never get those to reconcile, and so you get a lot of friction between teams that's hard to resolve.

(Joel Beasley at 00:43:28) I would be interested to see, potentially, in your next survey for you to have the participants self-select the quality of their culture there at the company and then connect that with the number of breaches they've had or attacks or something like that because of what you just said. Right? I get to talk to a lot of different people, and I get to go visit a lot of people, and I've seen a wide spectrum of cultures. And I can tell you that it's rare that companies have awesome cultures. But the ones I see that do have awesome cultures typically are much better off financially. They're growing, and the people there are just what I consider high quality people.

(Andrew at 00:44:14) Yeah. I think that there's some folks here that have bandied about the idea of kind of a DevSecOps cultural focused survey report, which I think is probably what you're looking for. I think you're absolutely right. In this report that we just released, I think we see signs of that. You know, organizations that are doing a much better job on cloud security than others are having an easier time retaining and attracting talent. That's probably a pretty good indicator of a good culture right there. If you're not doing this well, people are just not as happy. More headaches to deal with. Who wants to be in that environment, particularly when there's probably a dozen other companies that are really trying to lure you over? It becomes an easier decision to make to bounce if you're just, if you're only spending a quarter percent of your time actually doing the things that you love to do.

(Andrew at 00:45:23) So I think you're absolutely right. Seventy-seven percent of the organizations that we surveyed are experiencing, you know, collaboration and training kind of issues when it comes to cloud services.

(Joel Beasley at 00:45:35) Probably experiencing more incidents. That was the word I was looking for earlier. Like, how many incidents they're having within their organization versus how good the quality of communication is culturally.

(Andrew at 00:45:45) Well, and of course, you can't solve these problems with tooling alone. So, you know, Snyk is refreshing. Snyk has a no jerk rule, and it's real. And I've seen it. You just can't survive here if you treat your teammates poorly.

(Joel Beasley at 00:46:04) Can't survive in your career long term if you do that. I mean, that's just become, you know? So I'm about 35, and what I've noticed in my career is that every year, the jerk or the person that is the save the day person, that becomes less and less and less popular. And I think partly due to the fact that you used to be able to have your hands in everything, and now there's so many disciplines that are so detailed, the premium here is on your ability to work with other people.

(Andrew at 00:46:33) Sure. Absolutely. Absolutely. No amount of talent is worth having a jerk on the team dragging everybody else down. And so from that perspective, I mean, I love working at Snyk for that reason. It's pretty astounding to see. You did say something earlier, you know, if people won't change, then maybe the people need to go. Again, without the context, sometimes, if you're trying to get your organization to change, you know, maybe it's you that needs to change.

(Joel Beasley at 00:47:08) Yeah. I have found throughout my growth that the easiest way to find out if you should be digging deep to see if it's you is if you're reluctant to do so.

(Andrew at 00:47:20) Are you willing to change?

(Joel Beasley at 00:47:21) Or are you willing to even consider that you're wrong? I'm wrong a lot, dude.

(Andrew at 00:47:28) That's a whole other podcast.

(Joel Beasley at 00:47:30) Yes, it is. What didn't we cover that we want to get out there to the world? They got to download the report or go check out the report. They got to sign up for Snyk. What else do we have to get people to do?

(Andrew at 00:47:41) I think we need to get people, particularly, I think if it's the security team, recognize that you can't solve the problem, that it really is a shared responsibility. And when security teams embrace this idea of being a tool vendor for the rest of their organization to help them, to help everybody and empower them to operate more securely, we can achieve not only better security, but all sorts of different ROI stories. And, you know, really the security team becomes the hero. And I think that that's something that security teams are so used to being the bad guy, the team of no. No, you're not allowed to do that, or slow down, stop moving, stop innovating so fast because we need to come in and make sure that what you're doing is secure or not.

(Andrew at 00:48:38) In modern application development and cloud operations, we have this opportunity now for security teams to be the hero, to kind of bring the solution, not the problem. You know, I'm not focused on finding all this bad news and throwing it at my developers and my engineers to fix. But now I'm coming to my developers and my engineers and saying, I'm here to make your lives a lot easier. It's also going to make my life a lot easier on the security side because when we're successful working together, it's going to be less noise coming at me trying to kind of monitor everything and make sure that it's secure. But also, you're just going to be able to focus on doing what you love and not focusing on, oh, no, Drew's hitting me up on Slack again. I know it's bad news. Whatever it is, if Drew's hitting me up on Slack, my day's wrecked. I'm going to have to go chase down some sort of security issue. So, yeah, I think it's an opportunity for security teams to be a hero for once.

(Joel Beasley at 00:49:51) Oh, man. Drew, we made a podcast. How do you feel?

(Andrew at 00:49:53) I love it.

(Joel Beasley at 00:49:55) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.