State of Cloud Security

EPISODE 122

Guy Podjarny: “There’s a charge towards the end of the report that talks about motivations for improving cloud security, and I love it the two views that are of engineering and security, which is from an engineering lens, the most important motivation is to improve engineering productivity. From a security lens, the most important reason is to improve security productivity. The agreement is that this investment improves the productivity of both teams, just people are more acutely aware of the pain and that opportunity in their world.”

[INTRODUCTION]

[00:00:01] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk’s a developer security platform helps developers build secure applications without slowing down, fixing vulnerabilities in code, open source containers, and infrastructure-as-code. To learn more visit snyk.io/tsd. 

[EPISODE]

[00:01:20] Guy Podjarny: Hello, everyone. Welcome back to The Security Developer. Today, we have a different format episode. I think, as we all know, cloud security is sort of a hot space, and everybody agrees that it’s very important. Not everybody agrees about what it is. And there’s general consensus, though, that it is a change. It’s a departure from how we’ve been doing things, and an area that is worthy of sort of investments in definitions.

At Snyk, here, we’ve been running this annual report, which we call ‘The State of Cloud Security’, and we’ve done a special, probably the broadest version of that this year along to try and kind of keep a pulse on how people think about cloud security, why they’re doing it, what are the learnings? Is it important? And a lot more details inside of that. So, we’re going to use this episode to just sort of dig into some of the learnings, some of the conversation and talk a little bit about what they mean, and to have that conversation we have with us, Simon Maple, who is Snyk’s field CTO, and you know from past episodes. Hi, Simon.

[00:02:14] Simon Maple: Hey. 

[00:02:15] Guy Podjarny: And Drew Wright, who’s a first timer on the show here and was the primary author behind this sort of report and the survey. Drew, thanks for coming on to the show. 

[00:02:24] Drew Wright: Thanks, great to be on.

[00:02:24] Guy Podjarny: So, with that, I’m going to hand it off to Simon, who’s been sort of deeper in the report here and will kind of help us explore what’s inside here. So, Simon, onto you.

[00:02:34] Simon Maple: Thank you, Guy. Yeah, I mean, as someone who’s written a number of reports, over many years, I always really enjoy getting deep into the data, and sometimes having that hypothesis, which is then backed up by data, and very often also being surprised by many of the results that come out of this data. I think one of the core things is ultimately where we get this data from.

So, I guess, Drew, my first question really is, in terms of the report, how did you start getting the data from individuals or from the market? What was your approach there?

[00:03:02] Drew Wright: Sure. So, we commissioned the survey from a company called Propeller. They’re one of the market leaders in market research, to survey more than 400 cloud engineering and cloud security professionals. And that’s both kind of getting a cross section of the practitioners on the security side, that might be a security architect or cloud security analyst, and up to CISO or VP of cloud security.

On the engineering side, we’re talking about DevOps engineers, cloud engineers, SREs, et cetera, and exec, Head of cloud engineering, those kinds of folks. And then kind of get a spread of organisation type. So, we wanted to get a sense of what enterprise teams are experiencing and are motivated by or what their objectives are versus those at start-ups, public sector organisations, small to medium sized businesses, et cetera. And it’s spread across organisations that are using AWS or Microsoft Azure, Google Cloud pretty evenly, and then a multi-cloud footprint as well.

And then finally, we added in kind of the primary use case as sort of a sub demographic, as you will, to kind of understand how these teams are using the cloud, that might be that kind of more early, traditional, use case, where we’re using the cloud as a platform for running migrated applications from the data centre or third-party applications, versus kind of the maybe rising use case that we’re seeing more and more, which is using the cloud as a platform for building and running applications that we’re building in-house. So, that’s essentially the world that we surveyed for this report.

[00:04:45] Simon Maple: And it’s a very interesting split, actually, that you mentioned that with applications that are built in house. They obviously go through very different processes, platforms, workflows, to compare to software that we are hosting in the cloud, or maybe legacy apps like you mentioned. Guy, I know you did an amount of work looking at the kind of the differentiators between these and how we as a company, as well as the market, consider the differences between these, how they need to approach each differently. Why don’t you talk us through a little bit about that differentiation?

[00:05:13] Guy Podjarny: Yeah, I think it’s an interesting world. Cloud is the sort of massive beast and I think at the beginning, it was sort of small enough that we could talk about this in one go and kind of know it’s the cloud. But I think we’re sort of distancing from that point in time. Today, there’s a lot of ways to slice and dice it. But I think the distinction you alluded to now is an important one, and we’ve been kind of increasingly talking about this as the separation between the IT cloud and the app cloud.

So, the IT cloud might be the part of the cloud in which you primarily host your applications you purchased or you outsource, and things like that. These are the applications that you don’t generally have the source code to, or like the ability to do anything about them. So, you’re running them kind of as black boxes, they get delivered or shipped in a slightly more waterfall fashion, or maybe just the purchased elements to you. So, you don’t update them very frequently. They may be biased a bit more VM than container in them because they’re black boxes, you end up when you talk about securing them, you end up securing their perimeters. The infrastructure, the run-on, the network, you may need to reverse engineer something, and like when a problem occurs on them, then it triggers these IT workflows. You need to engage a vendor or you need to engage a contractor to make some changes because it’s not in-house. 

But IT is kind of the master of that domain and they’re able to own it. It’s not always the title IT, but it’s a centralised group. And then if you contrast that to the other side, which we call the app cloud, that’s really more about homegrown applications, and especially true for ones that are sort of deployed in a DevOps or continuous fashion. And because those applications are – they change frequently, there’s a shared ownership between the IT side, sort of central, people that own the cloud, and the people that are building the apps, you ship them off. So, the versions change all the time, and we deal with it. They’re not black boxes, they’re white boxes. It is the source code. 

So, while in the IT cloud world, you might need to default to detect and respond, the app cloud world offers you an opportunity to maybe try and sort of find problems early on, and actually prevent them in the first place. So, you have those – those are just sort of a few of many other differences. You might have blue, green, trains and dev and staging, so you have multiple versions of the clouds on the same app deployed, which is less likely to happen in the IT cloud world. There are just these million different views. So, I mean, naturally, on the Snyk side, we’re sort of bias because we think about things from the developer angle. We’re sort of biased in our products towards the sort of the app cloud and its capabilities. But I think it’s an interesting distinction in the world as a whole, as we think about practices.

[00:07:47] Simon Maple: I think it’s a really interesting one as well, because obviously, like you mentioned, the difference between white box and black box there, is really cool, because it changes the workflow. So significantly, the amount of interaction that a developer would have going through versus something which you’re just potentially hosting on the cloud. And it’s like you say, you’re much more secure in the boundary. Is there anything we saw in the report Drew, that kind of like, highlighted these differences, or maybe showed from a security posture point of view, whether one was easier to secure than the other or anything like this?

[00:08:16] Drew Wright: So, it’s interesting, because there’s at least on the surface, some contradictory data. What we found is that you’re more likely to use like cloud native kinds of patterns, architectures, such as containers and server lists, if you’re in that app cloud model. You’re building and running on the cloud, and that increases security complexity. Many respondents said that going kind of cloud native does make security more complex. That said, those use cases, the teams that are in that app cloud model are experiencing fewer serious cloud security incidents. It’s not a huge cap, but it’s a meaningful one. So, 73% of that kind of that app cloud, those app cloud teams experienced at least one serious security incident last year, that’s versus 89% of those whose primary use case is hosting migrated applications from the data centre.

So, you have, on one hand, kind of this increased complexity, which might just be this is new stuff. And we have to kind of – it has a different sort of security profile and we have to kind of figure out how to secure that. Usually, that comes with shift left on cloud security, much as teams have been shifting left on application security. More likely, you’re using infrastructure-as-code, which provides the opportunity to check the security of your cloud infrastructure pre-deployment, and development in CI/CD, and that’s a huge boon too. So, I think that the app cloud kind of model just gives you again, a better opportunity to secure the entire software development lifecycle.

In that IT cloud model, where you’re kind of hosting third-party applications, you’re less likely to be using infrastructure-as-code. You probably, one time, kind of set up the infrastructure environment, deployed the application, and then you’re just maintaining that long-lived infrastructure over time, which, I think can have some security drawbacks. I think there’s a level of ephemerality, immutability, and more kind of cloud-native patterns that have a security benefit inherent in them.

[00:10:33] Guy Podjarny: Yeah, just sort of chime in is, it’s interesting, there’s always, things get worse and worse and worse and worse and worse until you realise the situation is sort of untenable, and you have to do something about them. So, it’s interesting whether the complexity has kind of tipped us over to the other balance side in which, okay, there’s enough complexity here that we don’t think we don’t have the illusion that we can manually manage it, and we sort of reverted to infrastructure-as-code, and kind of that world. I think there some interesting info about infrastructure-as-code as well, which I’m sure we’ll dig into.

[00:11:05] Drew Wright: Absolutely.

[00:11:05] Simon Maple: Yeah. And some of those numbers, I don’t know about you Guy or Drew, if they surprised you, but some of the numbers that you mentioned, just then, Drew, earlier on about, I think it was – was it 89% for groups that are running in kind of more of the black box style cloud environments suffered a major incident in the past year. Did that seem high to you? Or was that kind of more expected?

[00:11:25] Drew Wright: It’s generally in the more expected range, having run this report every year. It’s in-line. So, a third of the organisation suffered a cloud data breach in the past year. I mean, I’d say it’s not surprising, but it never doesn’t feel a bit alarming. When you say. it’s 80% of all organisations suffered some kind of major security incident. I mean, we’re talking about, again, those cloud data breaches. It could be a serious data leak, an environment intrusion, or crypto mining in your account, which can do more damage than just running up your bill. If you’ve got, similar to like orphaned infrastructure, if you have infrastructure running in your account that you’re generally not aware of, that’s a huge security risk. You’re not scanning it or monitoring it or patching it, what have you. And we do see breaches occur, due to kind of that initial penetration vector of orphaned infrastructure or crypto mining infrastructure, those kinds of things, or even dev account, non-production account infrastructure can be a risk as well.

[00:12:37] Simon Maple: Yeah, and the numbers were 33% of people had a cloud data breach in the last year, 27% had an environment intrusion, and 23% suffered from crypto mining attacks. So, it’s kind of a little bit scary to see, just in the last year, how many, and enterprises compared to some of the other sized organisations, enterprises seem to fare a little bit better. Any thoughts on why that was the case.

[00:12:59] Drew Wright: So, a little bit of data, a little bit of hypothesis, I can throw out there, enterprises lead the way in infrastructures code use. And my hypothesis on that is that they tend to plan more, and my experience working with enterprises operating at scale in the cloud, under pretty rigorous compliance and security requirements, they’re more often than not now making it mandatory that every net new infrastructure deployment must be deployed using infrastructure-as-code, and that they have to continue using that infrastructure-as-code. That’s an important caveat there. You tend to see a lot of infrastructure-as-code get used as kind of an initial deployment mechanism, because it’s easy, it’s fast. We can take the template that maybe somebody passed over to us, that kind of gets the job done for us. We deploy our infrastructure, and then kind of abandon the infrastructure-as-code, and we’ll just use the console, that the cloud provider provides us to do any ongoing maintenance or updates.

If you do that, you tend to lose any kind of long-term security benefits of using infrastructure-as-code, as well as others, kind of an operational benefit. But if you continue to use that infrastructure-as-code, you can continue to make sure that everything that you’re doing to your environment, all the changes you’re making to your environment are secure. And what we see is, particularly in this app cloud model, the infrastructure is changing constantly. Your application developers are continuing to innovate, they’re adding more features, every time they do that, there are going to need to be changes made to your infrastructure environment, and when you use infrastructures code alongside the application development teams to make this work well, you always have that security feedback loop happening at the very beginning of the development process. So, long story short, I think that that really helps explain why enterprises are overall experiencing fewer incidents is because they’re planning more and they’re really prioritising infrastructure-as-code.

If you look at like start-ups, they tend to kind of just get going building things. Oftentimes, that happens in the console. And before too long, you’ve got an infrastructure environment already running. And it can be pretty challenging to apply infrastructure-as-code to an environment after the fact.

[00:15:27] Simon Maple: Right. And looking at the adoption stats from the report, enterprises have adopted infrastructure-as-code at 55% of enterprises doing that, versus only 36% of start-ups and 34% of public sectors. One of the most interesting stats here as well, in the report for me is, I’ll read out the headline here, “Infrastructure-as-code security reduces misconfiguration by 70%.” Again, very compelling figure. But what does it mean in terms of actually adopting infrastructure-as-code? You mentioned, it allows obviously, infrastructure-as-code, allows people to actually work on the infrastructure, work on the cloud spaces as early as they possibly can. So, during development, as they’re building up their applications. From the point of view of an IAC security, how well do you see that being adopted by developers, by other folks early?

[00:16:15] Drew Wright: Sure. So, 91% of infrastructure-as-code users are integrating security into their development and CI/CD process. So, we’d like to see that obviously be 100%. But 91% is about as close as you can get in a survey. It’s almost there, more than nine out of 10. So, we do see that when infrastructure as code is being used, security is being applied to that infrastructure-as-code, which is great.

[00:16:42] Guy Podjarny: I think Drew, you said it well around the planning element to it. And I think like fundamentally, before you use infrastructure-as-code, you need to constantly make sure to not slip. So, you do a lot of actions. And naturally, sometimes you’ll leave the door unlocked, sometimes you’ll leave the window open, because you need to constantly remember to sort of look behind you and check and verify while the, I think, infrastructure-as-code, it’s a plan. You sit down, you invest more time in deciding that this is the right way to inspect or set up or configure it, so you’ve made that decision. Now, it happens for you. It happens automatically, right? The car locks itself, when you’ve kind of walked away enough, far enough with the keys or, I guess, that caused all sorts of other problems. So, maybe they stopped doing that.

But the intent is, if it’s built into it, so it happens every time, and I think that’s a big deal. I did find though, like I will say that, we kind of glossed over a bit sort of the IAC adoption being that much higher in the enterprise. And to me, that was a good insightful moment. It’s a little bit less on security than on tech. But I mean, naturally, you think about cloud native, you think start-ups lead the way, they are cloud native. They are like born in the cloud, they run with those. You think of IAC as a modern, a forward-looking cloud native approach. So, at first, I was like, does that make sense? But then when you give it more thought, it does kind of make sense, because it sort of comes back. There’s this wave with sort of infrastructure-as-code. It’s easy to use and to set up, and it’s important to use it to scale. But when you’re in between, you’ve already set up and you’re now not yet at scale, then it might be cheaper in a tactical fashion, to not invest that time in IAC and it’s easy for start-ups to just kind of forego it and continue.

But still, I found that that on the cloud side itself, quite interesting and surprising. I do want to mention that on the security and start-ups failing their IAC, I have a good sort of theory on it. But I think another one that comes to mind is the attacker profile. And this is pure conjecture. I think here, like the report doesn’t have data to back or refute this. But I think attacks have changed over the years to go from targeted to statistical. Yes, of course, there’s also targeted ones. But it used to be that if you’re an enterprise, if you’re large enough, you’re a big enough target, and therefore attackers target you, and so you invest in security, because you’re a big enough target and it’s important and that creates a certain kind of a cycle.

While if you’re a start-up, nobody cared about you, and so nobody would attack you. And so, you can get away with sort of doing less security. But today, especially in the cloud, attackers are – there’s a whole range, whole world of attacks that I’d sort of dare say the majority, vast majority of attacks out there, which are actually statistical attacks. They take vulnerability and they seek out and the report kind of describes that sort of shift, right? It goes from finding an attacker and sort of seeking weaknesses to taking a weakness, taking vulnerability and seeking targets. And in that case, start-ups can get caught just as much. So, I think that is an industry shift, that might put start-ups in that sort of tougher place in the equation.

[00:19:49] Drew Wright: Yeah, I think that this is something that a lot of people in cloud security are missing, and it’s an important one to hit on. We’re used to seeing headlines like, “Company suffers cloud data breach due to misconfigured server.” And that headline tends, it’s technically true, but it’s also missing a huge, huge piece of the story. And it’s important for people to understand not necessarily the specifics of what happened beyond the misconfigured server. Let’s say, the hacker made off with source code from thousands of repos, and customer data across different product lines, and these kinds of things.

We can all assume, safely, that all of that source code, all those repos all that data did not reside on a single misconfigured server. But security tends to be focused on trying to prevent that misconfigured server from becoming – that server from becoming misconfigured, and you need to do that. But it’s this, again, when the attacker gets a foothold in your environment, and that may be because there was a misconfigured resource that the attacker found and exploited to kind of get in the front door, it could be an application vulnerability, such as log4j, that gives the attacker the access point that they need to get into the infrastructure environment. It could be API keys and source code. There’s a whole range of initial penetration vectors that’s certainly important for people to recognise that.

But once they’re in, they want the API keys associated with that resource that enable the attacker to operate against the cloud control plane, the very control plane that we use as cloud customers to build and configure and manage our environment. Because what that gives the attacker the ability to do is first, discover all the knowledge that they need about what’s in the environment, where might data be, give me a list of all the s3 buckets. Chances are, I might be able to figure out which s3 bucket looks the juiciest and that I want to go after. But then it also gives me the ability to move laterally, ultimately get at that data in s3 bucket, a database snapshot, these kinds of things. And then very quickly, copy that data into a resource in my cloud account. And none of these attacks traverse kind of a TCP/IP network that we would be able to monitor for intrusions or nefarious activity.

So, these attacks can happen very quickly. And this kind of pattern plays a role in every single major cloud breach we see these days. It’s not that the – “Oh, we left our s3 bucket wide open to the world and had all of our sensitive data in it, and somebody came along and stole it.” That still does happen these days. But that used to kind of dominate the cloud breach scenario, seven, eight years ago.

Today, it’s this control plane compromised kind of attack that we see. The attacker gets in somehow. But once they’re in, the cloud customer has inadvertently left them a treasure map of the environment, and a bag full of IDs that will enable the attacker to essentially impersonate official business. And there’s no intrusion detection, kind of defence against this. You can and certainly should be getting all of your logs and analysing those from a security perspective. But again, the notion that you can identify and stop these kinds of attacks in progress is a dangerous one to take from a security perspective. And that’s why we emphasise that you need to prevent the conditions in your environment that make these kinds of attacks possible. Really is your best defence.

[00:23:57] Guy Podjarny: It was a really good highlight in the report there on this type of like lateral move. It’s like automated lateral movements to kind of traverse and explore the cloud you just arrived in.

[00:24:05] Simon Maple: One other interesting stat that came out of that report was 49% of organisations find that deployment happens faster as a result of improved cloud security. And I think this is always one where when we think about cloud security, a lot of the time the reasons why we do it. And actually, there’s another very interesting stat in terms of the priorities of why developers versus security teams want to improve their cloud security posture. But the reasons we want to improve, tend to be maybe more about because we want to improve our security posture, because we want to make it more secure, harder for people to take data, to breach data. But this starts really, really showing. It can actually enable our business, it can actually allow us to deploy faster and be more competitive in the market based on our improved cloud security. Talk us through your hypothesis and how improved cloud security can achieve this.

[00:24:53] Drew Wright: Sure. Yeah. And there’s a lot there. So, I think why do organisations go to the cloud? They want to be more competitive, innovate faster, time to market agility, these kinds of things. And what we find is, all the tools and technologies and workflows are there to do that. But security increasingly becomes the rate limiting factor for how fast teams can go in the cloud, how much they can get done. And really, from an enterprise perspective how successful your digital transformation can actually be. Because until you transform how you do cloud security, it’s those old security kinds of approaches and tooling applied to this new kind of way of doing things just doesn’t work.

So, you wind up with cloud engineering teams that are really just bogged down in a lot of manual work involved with security. The security team might be – they’re continuously checking the running cloud environment for issues that need to be remediated. When they find those, they create a ticket, they throw it over to the engineering team to figure out and remediate. A lot of times, those remediations are not simple ones. It’s not just necessarily, “Oh, flip a bit on a configuration, and we’re good to go.” Sometimes those remediations would be a breaking change for the application. And so, there’s a lot of rework involved.

So, if you’re a cloud engineer, or an application developer in the cloud, and you’re spending an inordinate amount of time dealing with the security team, like ringing your phone, or hitting you up in Slack, or sending you a Jira ticket or what have you, it’s frustrating. We found last year, more than half the teams are investing more than 50 engineering hours a week, just dealing with things like remediations of issues that the security teams are finding. So, when you see that the number one motivation among cloud engineers to improve how they do cloud security is to keep our environment secure. I think that that’s both honest. I think we all want to have a more secure computing environment. But if you dig into that a little bit deeper, I think what you’ll find is, is that they’re trying to eliminate a lot of headaches, and a lot of frustration, because they want to spend more time building and less time dealing with a bunch of manual tasks.

What happens when you give a software engineer a manual task that they have to keep doing over and over? Their instinct is, how can I automate this away? How can I prevent these kinds of issues from happening, so I don’t have to deal with them, because it’s just no fun doing this?

[00:27:37] Guy Podjarny: I love, there’s a chart towards the end of the report that talks about motivations for improving cloud security, and I love it the two views there of engineering and security, which is from an engineering lens, the most important motivation is to improve engineering productivity. And from a security lens, the most important reason is to improve security productivity. The agreement is that this investment improves the productivity of both teams, just people are more acutely aware of the pain and the opportunity in their world. 

[00:28:05] Drew Wright: Absolutely. I mean, you can’t field an army of security professionals large enough to deal with this problem. And no security team alone can solve this problem. We talk a lot about the shared responsibility model between the cloud customer and the cloud provider. But within the cloud customer organisation, cloud security is a shared responsibility, and it needs to involve the security team, the engineering team, architects, the application developers, all working together early, and the security team embedding with those teams to really understand the use cases and the architectures and bring their knowledge of what’s okay, and what isn’t from a security perspective to bear in that design and development process, so we can avoid a lot of these problems.

77% of organisations are experiencing challenges, which is collaboration, and issues related to collaboration. But there’s tooling and workflows that can really help solve this policy-as-code being probably the most important one, I think, from a security team perspective as well, that I think security teams probably aren’t looking at, as closely as they should be.

[00:29:24] Guy Podjarny: Just as another fun anecdote is this productivity boost. This may be agreed in different views. But there’s another question there, which is, is the motivation to keep our environments secure? In which the engineering side said, “Yeah, you know, that’s the most important reason. That’s sort of a five out of five.” The security team is like, “Well, keep environment secure. That’s two out of five.” Basically, from a security team’s perspective, improving security and productivity, which I guess giving them the benefit of the doubt, probably they think that that in turn will kind of help us give the organisation secure. That productivity is the top gain from investing in cloud security.

[00:30:00] Simon Maple: And I think one of the other points on that same graphic actually was the engineering response to faster app and feature delivery, which was actually second lowest from the developer point of view, which really shocked me as well. Because when you think about, we always hear this narrative about how developers they care about the next feature and pushing out the next feature, et cetera, et cetera. But to hear that the thing that they want to prioritise in cloud security is, the reason they’re doing it is to keep the environment secure. It’s actually really good, and it also shows developers like we always say, developers are always trying to do the right thing. It’s where they’re enabled to do that right thing and power to do that right thing, et cetera.

One of the things I did love about this report actually, was that you did also split, as we’ve done in, I think, in previous other reports, as well, splitting the response between engineering and security, because that also does give a very interesting cultural differentiation. And I think one of those, as we’ll talk about ownership going into, it’s their shared responsibility, and so forth. One stat here, which really poked me in the eye, as I was scrolling through was the who is responsible for cloud security. And the cloud engineering team, or the engineering response was 42%, for cloud engineering team. So, I guess, almost bringing upon themselves to say, you know, we want to be responsible for this, or we believe we’re responsible for this.

However, the security response, and I think this has actually been similar across a number of reports that we’ve seen, not just in the cloud security, but AppSec, and other spaces in the open source security report, the security team, were actually over half less than that. So, not only 19% of security folks thought that the cloud engineering team were responsible for security. Is this something which is saying that developers and engineering teams are more wanting to take the security responsibility than the security team are willing to give it to them? Is there a cultural misalignment here with responsibilities, do you think? Guy, maybe this is one for you. I know you’re always very interested in his whole responsibility shift and ownership.

[00:31:52] Guy Podjarny: Yeah. It’s fascinating. It definitely drew my attention as well. And I think, I guess the kind of the interesting bit, it’s always we do these different sorts of surveys and all of that, and it’s I think the seeing similar patterns across the different reports and different spaces, does reaffirm, maybe sort of a lens on what’s happening. I think there’s definitely sort of a bit of a pull or push. I think there’s some trepidation, some fear in the security sense of acknowledging, of answering a question like, “Who’s primarily responsible for cloud security?” With an answer that isn’t, “Security. That’s kind of their job, it’s kind of what they’re paid for.”

So, you know, there’s some complexity probably in sort of an understanding the survey questions are never perfect. But I do think there’s a shift, there’s a transformation happening in the industry. And really, we need security organisations to become platform teams, to become engineering teams. I mean, on this podcast, every time I raise the question around skills and sort of hiring into the organisation, there’s just fairly consistent views that security leaders today, that are so forward thinking, they hire for coding skills, they hire for engineering skills. There’s a perception that it’s easier to teach security than it is to sort of teach development, software development with these individuals. And there is a transition in which these teams need to become teams that build the tools, build the platform, build the competencies, to enable the developers to actually build things that are secure, whether it’s policy-as-code, or whatever it is, instead of the methodology.

They remain the expert, they remain the escalation point. I think that’s the shift that sort of rocking their world, rocking the security world, maybe even a bit more than the engineering world. The only kind of other comment, maybe that I would say here is come back a little bit to that IT cloud, app cloud. And I don’t know, Drew, if we have data, but this, survey is always, whenever you get an answer to a question, you want to ask five others. I also feel like because the cloud is so conflicted, you say cloud security, and I think to half or to some subset of the people, they would really mostly hear IT cloud. And you say, the other part, the other half would mostly hear app cloud and sort of homegrown applications. And I think that distinction is very different. Because if you hear IT cloud, when you hear cloud security, then clearly, you wouldn’t bias cloud engineering ownership. Cloud engineering only exists, probably, in the world of sort of app cloud. That’s not true. Cloud engineering has broader, but they probably naturally bias in favour of the app cloud. So, I don’t know, Drew, if that makes sense, or it’s consistent with –

[00:34:30] Drew Wright: It does, from what I’ve seen is ownership aside, cloud security, and cloud in compliance kind of gets rolled up into this a lot. These responsibilities and tasks do tend to land on them whether or not they are officially primarily responsible for cloud security. It’s not the security team that’s doing the remediations it’s the security team, you know, sending a request over, a ticket over. Or, if it’s a compliance burn down list of things that we need to do to bring our cloud environment into compliance, that’s going to fall on the engineering team to get done.

So, when you present tasks and problems to the engineering team, they’re going to want to try to figure out better ways to do it. And that’s, I think, where we see this discrepancy, that the cloud engineers are saying, “Yeah, we are primarily responsible. We’re taking more ownership over this.” Again, of course, we all want to be more secure, we want our environment to be more secure. But we need to take more ownership over this because the process is broken. And we know that there’s better ways to do it. There’s infrastructure-as-code tools. There’s policy-as-code we can use these kinds of things to make our lives easier, and be more productive. To make it easier to retain and hire other engineers.

If you’re an organisation and your cloud security process is broken, and your cloud engineers are having to spend a lot of time doing this kind of stuff that nobody really likes to do, it actually becomes more challenging to hold on to those engineers, or to attract additional engineers, when there’s other organisations that have kind of – they’re doing a better job on this front, and they’re not going to like saddle their engineers with the compliance hat for three months, or those kinds of things. We find too that cloud engineers are a little bit more optimistic about security over the next year and beyond. So, 55% of cloud engineers think the problem is going to get worse. We’ll just put it out there that pessimism still kind of rules in the sense of it’s a big problem, and the attack surface is complex, and the attackers are getting really sophisticated. But the security teams are, they’re more pessimistic about the future than the cloud engineering teams. And I think that that’s because engineers are engineering solutions to this problem.

[00:37:04] Guy Podjarny: I’m kind of smiling a bit here, because I feel, it’s the whole kind of builder versus breaker mentality a little bit, that sort of optimism element to it. Engineering is almost like naturally optimistic, you’re building things, you’re sort of creating something that didn’t exist before, and you need to believe that it can be created, and that it would work, and security is naturally pessimistic. It assumes something is flawed. It sort of assumed there is a problem. And so, that world is almost like a negative by design. Not to say that the individuals are negative, and it has optimists and has pessimists in it. But there’s a natural, a certain sort of selection bias that happens over there, which I guess, I come back a little bit to the platform engineering, or the notion of security teams becoming platform teams, because I think that bias is backed builder, and get out of the cycle.

[00:37:50] Drew Wright: I think cloud security architect is a role that that we are seeing up here more and more at organisations and is a really critical one. I think, security professionals out there that want to do more in cloud security, and advancing cloud security would do well, looking at architect certifications, learning more about how cloud architecture works, and certainly from a security standpoint, and then go sit with these teams, your cloud platform teams, your DevOps teams, to really understand what they’re doing, how they’re doing it, the CI/CD process for their cloud infrastructure, their IAC tools. This is going to reap huge dividends. And again, we see not only does infrastructure-as-code security, reduce the rate of misconfiguration by 70%, that means you’re not digging the hole deeper continuously over time. You are actually starting to reverse the trend and reduce the amount of noise and tickets and alerts and things that you need to you know, that need to get remediated. But we’re also saying that teams are 70% more productive when we’re doing a good job on infrastructures, code security, and that we’re delivering faster as well.

So, the bottom line for organisations is pretty huge when you really focus on kind of operationalising your secure cloud security process, across teams and across the software development lifecycle.

[00:39:23] Simon Maple: And I think, to wrap up this episode, let’s look a little bit to the future. I see, one of the stats here was 58% of developers and security professionals predict increased risk over the next year. And I think that’s in part because one of the other stats, 77% of organisations state problems with poor training and collaboration is a major challenge. So, if you had unlimited budget, unlimited resources, where would you maybe – one place that you might invest heavily to help reduce that risk going forward in future?

[00:39:55] Drew Wright: So, I’d say building on a foundation of policy-as-code that can be integrated into a lot of different things that your organisation is doing, is probably the best place to invest. And the reason why I think policy-as-code is so critical is, not only can it be a basis for – first, let’s talk about really quick what policy-as-code is. It’s the ability to express compliance policies, security policies, in a language that other applications can understand and use to evaluate the correctness of what’s being done. What this means is, is that our security policies aren’t solely written in a human language, which is going to be misinterpreted, and there’s going to be confusion about how to apply these policies to whatever work it is that I’m doing. It’s very difficult for security teams to ensure that all of the security policies are being followed, and that they’re being followed consistently.

But when you adopt policy-as-code, you are now able to express these policies in a way where you can vend them out to the rest of the organisation, and all these different teams, cloud teams, application teams, can use that policy-as-code in their work, in their IDE, in their CI/CD pipeline with their IAC tools, in their cloud environment, in a uniform way to ensure that everything is correct at every stage that we’re operating, and there’s no confusion, there’s no differences of interpretation. So, it has kind of an aligning factor. Everybody’s operating under a single source of truth as to what’s allowed and what’s not allowed. As policies get updated, you know, we’re going to learn new things, we’re going to understand new attack vectors, and create new policies to address those and immediately be able to – we’re just managing our policies in a Git repo, like we do the rest of our code. And so, it becomes this is a way for security teams to scale their effort without having to scale up headcount.

[00:42:08] Simon Maple: And it’s also great to be able to have that as part of a similar dev space, similar dev float. It’s in a Git repo, it’s in a format that devs can easily read and maybe even contribute to, as well. So, that’s a great answer. I think that’s a really important step for organisations to take.

[00:42:24] Drew Wright: Organisations that are they’re looking at every organisation should really be making policy-as-code a priority. Look at Open Policy Agent, it’s an open-source policy-as-code framework. It’s part of the Cloud Native Computing Foundation, and it enjoys the support of Fortune 500 companies, and it has a huge ecosystem around it, and it’s incredibly flexible. So, you can use Open Policy Agent for a wide variety of use cases, including infrastructure-as-code and cloud security, but Kubernetes and other use cases. So, it’s really a fantastic project and I suggest everybody go check it out.

[00:43:04] Simon Maple: Absolutely. Of course, please do check out the report as well. Actually, there’s a lot of really interesting insights, and it’s very, very educational to see how others in the industry are dealing with these challenges as well. Drew, very briefly as well, how can someone – obviously, links and things like that will be in the show notes, but how would someone get their hands on this report?

[00:43:23] Drew Wright: So, the report is available at snyk.io. I think it’s the Resources section, I’ll have to double check that. And there’s a landing page there, where we give you a considerable amount of overview over what’s in the report, and then you can download the report for free and it really digs into each of those different areas.

[00:43:42] Guy Podjarny: Thanks, Drew. I think like a Google for ‘State of Cloud Security Report’ will help you find that as well. And yeah, you can get it for free. The intent is to, just like the podcast, do some knowledge sharing here.

Thanks, Drew for the great report. Thanks, Simon for the great moderation here and insights. And for anyone listening, and, as we experiment, with different formats for different sort of type of information that we can share, and what can we do to sort of help spread the knowledge in the ecosystem and bring that knowledge, we’d love to hear from you. We’d love to hear feedback. So, if you like this format of an episode, more discussion with some sort of anchor of data, then do let us know on the Twitter sphere or LinkedIn or whatever. I hope you enjoyed the episode and that you join us for the next one.

[OUTRO]

[00:44:28] ANNOUNCER: Thanks for listening to The Secure Developer. That’s all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you’d like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don’t forget to leave us a review on iTunes if you enjoyed today’s episode.

Bye for now.

 [END]