Defining Cloud Security With Rick Doten

"RICK DOTEN: When I look forward to, and the people who are developing it, and the people who are fixing it, whether it's the cloud side, the development side, the infrastructure side, they know how to do what needs to be done. They just need clear direction. 'Oh, it's this code snippet. There's a syntax error. This needs to be corrected and this is where it needs to be corrected.' If I know that, I can then automate it. My nirvana would be that – there's somebody had said that cloud security should be more like an airbag than a seatbelt, where you physically put on a seatbelt. Cloud security should be the airbag, like if it hits on me, it's going to pop up, and it's just there to protect you."

[INTRODUCTION]

[0:00:39] 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.

[EPISODE]

[0:01:02] GUY PODJARNY: Hello, everyone. Welcome back to The Secure Developer. Thanks for tuning back in. Today, we're going to dig into cloud security, what it is, what is the sort of the past, present, future of it, and all sorts of other stuff. To talk about all of that, we have Rick Doten with us. Rick, thanks for joining the show here and coming to kind of share some knowledge and practices.

[0:01:22] RICK DOTEN: Thank you for having me. 

[0:01:23] GUY PODJARNY: Rick, let's start by maybe defining a little bit like cloud security. I think it probably has 17 different interpretations of it. What's your definition? What is cloud security?

[0:01:34] RICK DOTEN: The main difference I would say is the shared service model. That is that, you don’t have full responsibility from the hardware all the way up to the software and the user, depending on whether you're an infrastructure as a service, platform as a service, software as a service. That may vary from how much, or how little, or a lot that the cloud service provider is going to be providing some kind of service. For instance, software as a service, you not only have the infrastructure, but also the application, and maybe the identity management, and the patching of the application, things like that. 

Sharing of what you're responsible and what you're doing is really like the core of what it is, but there's still a lot of things that are very important that you're responsible for, no matter what the circumstance, such as data protection, identity management, and then also vulnerability management, and response to issues. But there is certainly big differences between traditional perimeter and data centre security than cloud security. Yes.

[0:02:31] GUY PODJARNY: Yes. I mean, I think that's a great distinction between kind of against the data centre, the on-premise, versus the cloud. But then within the cloud, cloud security oftentimes lumps in the infrastructure as a service, security and cloud security may be even in your definition. Even like a managed service that's just sort of hosting services that you own, but someone else manages might even fall kind of in that category. Is it right to think about, call it like say SaaS security, all the way to IaaS security as cloud security as a bucket. Is there enough similarity almost between the two of them, to put them under the same title?

[0:03:05] RICK DOTEN: Well, data and workloads being in the cloud, it kind of goes into the thing that I was talking about. When you're doing security operations for it, depending on those levels, and that's why I feel like you can't get away from whether it's infrastructure platform or software as a service, what you're trying to protect. Because you don't need to worry about even an infrastructure as a service. If you are a company who doesn't do greenfield development of your own applications, and you're just really using the cloud as a virtual data centre, then it's very similar. You're usually having virtualised environments, where – instead of containerised environments, for instance. Which you would normally do if you were doing your own workloads and making your own application. Even within infrastructure as a service, it might be different.

My short answer is, it really is different depending on how you're using cloud as a consumer. Then, if you're providing security services for that, the things you worry about in software as a service, again, maybe more about identity, and configuration, and data protection. Where an infrastructure more about APIs, and then when you get down to infrastructure, more about your containers, or infrastructures, code, and governance as code, and things like that.

[0:04:13] GUY PODJARNY: Yes. It's interesting. It's an interesting distinction between the levels because it's almost, I guess, the way you present it, it's almost an accumulation of things. So if you're looking at SaaS security, there's a bunch of things that you need to worry about. If you're going to do platform as a service, you need to do all of the above instead of a SaaS, and then you need to do some additional. Maybe there's some tweaks to them. Then if you're going to IaaS, you do even more doing this. As an industry, we haven't been invented terms for the subsets, right? So when someone says cloud security, you kind of need to interpret from the context whether they mean –

[0:04:44] RICK DOTEN: Very broad.

[0:04:45] GUY PODJARNY: Because it's a very different – I guess the most important things or the most important risks for say SaaS security are quite different than those for IaaS security.

[0:04:55] RICK DOTEN: As you mentioned, with IaaS security, there's levels within that. Like I said, are you just using it as a data centre replacement, or are you really doing development. Because if you then are doing development, and you have a whole CICD pipeline, that's what's kind of changed in the last 10 years is our SDLC, and when we were integrating security in the SDLC. It kind of ends with, "Okay. Now it gets pushed into production." But in a CICD pipeline, it extends into the infrastructure, the infrastructure is part of it, it can't be decoupled from it. 

That's the thing that I really kind of learned the last five years, is that when I was looking at modern application security, and you know, from the late '90s, late 2000s, I ran application pen test teams. We used to train development teams of our customers, secure coding and all the basic stuff. When I went back to look at, "Okay. Where are we now? The really thing that I found is like, the infrastructure is so embedded with it because of that infrastructure as code, and the governance, and the heavy reliance on API, and service counts and things like that.

[0:05:54] GUY PODJARNY: Yes, I think that's absolutely true, and it kind of has intertwined in it. I'm just sort of curious a little bit about, I don't know, if I'm stuck a little bit on this taxonomy things, although like an – if we want to align on it. But you've been very involved with the cloud security, and alliances, and a variety of sort of buddies over here. But there hasn't been like any choice of naming, like the top 10 sort of security concerns for cloud security, for instance, also lumps in kind of these different buckets, right?

[0:06:19] RICK DOTEN: Yes. The Cloud Security Alliance has a top 11, I don't know why I picked 11. Maybe they're like prime numbers. That have the security, cloud security issues. When you look at them, 80% of them are configuration error, weak credentials, or misconfigurations, or things like that. Then – but they're not as like medias, like the OWASP Top Ten, or what we've learned in BCM. They're kind of general because the infrastructure is really not much different than traditionally. It's just that we have a lot more access points.

The thing I've loved about the cloud security as a topic, is that it kind of reintroduced threat modelling to the world, something that I did back in the late 2000s, and then Microsoft published the book in 2005 about it. Then we kind of like it kind of fizzles off, because it's kind of hard. But now, cloud security really, really lends itself to doing a threat model, because there's so many different entry points, so many different access levels, so many different dependencies that we really need to map this out and see what it is. But I go back to your statement that, yes, when you say cloud security, it's just like saying, "Hey, I need a security person." What flavour? There are so many different types of it. What is your circumstance? 

I think a challenge in our industry, is that we're trying to play to the least common denominator. We're trying to make it – if you just do this, you'll be okay, which is very rarely the case. But we don't want to be too complex about by saying, "Well, here are 15 different circumstances, and your mileage may vary depending on your circumstance.

[0:07:44] GUY PODJARNY: Right. I guess you can get too granular or too abstract here pretty easily. I'll get off to the sort of taxonomy bandwagon, so we can get to sort of the meat of it, a little bit of it. Let's talk about cloud security and maybe, like I think, tell me if you agree. That when we talk about cloud security in the industry, the majority of attention is on IaaS security. Because I think most – well, I guess most cloud usage is probably SaaS, but most cloud security concerns are in IaaS security, because there's just – I guess, kind of more ways to shoot yourself in the foot. Are we aligned there?

[0:08:15] RICK DOTEN: Yes. Because as a consumer, I have more responsibility to it.

[0:08:19] GUY PODJARNY: Right? Yes. Which makes it – 

[0:08:20] RICK DOTEN: Where I'm kind of transferring as risk can be accepted, mitigated or transferred. I've transferred the risk of most of the security for SaaS solution to them, and I have a much smaller piece.

[0:08:31] GUY PODJARNY: Yes. Yes. That's a great way of putting it. It's like in the shared ownership, you kind of own more, and so you need own about it. Let's sort of define maybe, what is like 101 in terms of cloud security in it? What are the basics that really, if you're totally kind of fresh to it, you have to do these things, to just sort of consider yourself almost like allowed to use IaaS in a secure fashion?

[0:08:56] RICK DOTEN: Yes. Absolutely. It is still no different. The fundamentals are no different than data centre. As you know, I'm on the editorial panel of the CIS Critical Security Controls. We talked about the most basic controls, like one through six, which is asset management, got to know what it is, and cloud, it applies. The data protection would apply, configuration management, vulnerability management, and identity management. 

So if we cover those basics, those are still where you start. Because we talk about phantom networks, and cloud, and people spinning up stuff, and not knowing about it. You know, that's important to kind of know what your infrastructure is, and then where the data is, what the data is. I mean, again, just the very basics, and even with all of this ransomware related to infrastructure is not necessarily cloud, that it's the basics that really kill you and the fundamentals. I think that that's one of the challenges as people kind of go towards the exceptional, but unlikely scenarios, because it's kind of the most scary thing, and not focus on the fundamentals. So if you just know where your stuff is, know where the data is, data is protected, identities are protected, you're doing vulnerability and configuration management properly, you're 90% there. 

[0:10:07] GUY PODJARNY: Yes, and it's interesting. Because on one hand, what you've described now is the one on one. And on the other hand, the same list is the mastery of the sort of cloud. Like if you're in a place, so it's really about how well do you actually know what's running where, who's allowed to do what. So it really is about security hygiene level. Are you just kind of washing your hands or are you actually sort of –

[0:10:28] RICK DOTEN: Scrubbing –

[0:10:28] GUY PODJARNY: – cleaning room, and sort of scrubbing. In both cases, all you're doing is keeping germs out, but two different levels of skill, I guess.

[0:10:35] RICK DOTEN: I think the challenge and the implementation of those, it's so diverse as far as who's responsible. Because as organisations have evolved, and moved into the cloud, it is no longer a simple relationship between the infrastructure people, the network people, and the application people, and the security people. Now, we have – there's cloud people, there's cloud architects, there's credential management, there's secrets management, there's API, there's all these different – 

I have a keynote that I do about, cloud security is a team sport and politics get into play. Not politics as in posturing, but politics as in who's responsible. Then that's what's also different about every organisation, is it's not cut and dry, whether the cloud security team is the one to set all the standards. It's really who has the most influence, because in large companies, most of the cloud teams are refugees from other parts of the company. There are former system people, or network people, or application people, or whatever that are now the cloud team. Because obviously, this is where we're going. They may bring their respect, or they were the application architects before. Now, they're the cloud architects. So, they may have more influence on things. 

Also, all those teams need to mature in education of what cloud is, and what's unique about the cloud, and some of the more specifics I didn't get into about securing the cloud, and not understanding it. I think that that's where I've seen a lot of groups where the security team doesn't understand the uniquenesses of the cloud, where maybe the architects do and the developers do.

[0:12:01] GUY PODJARNY: Yes, which to an extent gets me back to the taxonomy. It is because we called everything cloud security, so nothing is cloud security. Basically, you can kind of choose the interpretation that most fits your sort of context, or background, or sort of areas of interest, and so it's a challenge. But maybe another way to then think about, like as we define starting points in the cloud. One is kind of these five controls that you've enumerated and just kind of getting some initial handle, some sort of 80-20, I don't know.

Another view maybe on starting with the cloud is more about indeed, the cloud maturity, because like instead of starting with cloud security, let’s talk about cloud itself. I guess, is the starting point, when you think about cloud security fundamentals, maybe it's related more to the applications, if you've kind of shifted, and lifted applications from the data centre, and you're just running them in the cloud, and the way you've described is just, you're kind of outsourcing your data centre. Then you have an initial set of security controls. I guess, if you're doing that, like let's say, you kind of imagine a scenario, very common scenario, which is – you just have a bunch of applications you've shifted and lifted, you're running them in the cloud. Now, you want to operate a cloud security program for those applications. You probably will come back to the same kind of five controls.

But what changes, what's important to know to the change to between your data centre approach before above and beyond the slices that you are now outsourcing and you don't need to worry about?

[0:13:21] RICK DOTEN: Right. Yes, that's a very good question, because that's a very common scenario. It's kind of when I cringe out, because like, "Well, that's not the point of doing the cloud." It's a starting point.

[0:13:28] GUY PODJARNY: It is because you're losing –

[0:13:29] RICK DOTEN: You have to value the on-demand elastic and self-provisioning part. You're just kind of, "I'm spinning up virtual machines, I'm cutting, pasting, and fork lifting it up there." But what will change is, for instance, there are things such as the virtual networking, the credential management, the federated identity, the use of service accounts. Those things become a lot more in play. So even doing standard vulnerability scanning, you're not just going to get Rapid7 or Nessus to just scan it from the outside. It's isolated. I have virtual networks. When you're doing security operations, that one IP address may represent multiple systems, or it might change on a regular basis, depending on how you have it set up from just even just virtualised. 

Those kinds of things become like little nuance changes that are different about it, because you're just moving to, again, a static environment, not temporary workloads, but you're in a cloud environment. Then, you have the elements of how are my backups working, and then you have the privacy of the data, what area can be in. Because in the cloud, you know where your data is. You can kind of geofence it to make sure that it's in the US, or it's in Europe, and because of GDPR extend beyond Europe. But it's not like in – this was something that years ago, 12 years ago as part of the Open Data Centre Alliance, which I forget what they turned into. I was on the board for regulatory committee.

The biggest risk of cloud security back in 2010 was one, your cloud provider going away, and then all your data is gone, and your rush in business network using it, and then Interpol takes down, and you're like, you're done. Or two, the fact that you're locked in, and the portability is not there. That still exists today to a lesser extent, but I can't just take my ball and go somewhere else. Knowing where the data is when they say, "Okay. Go ahead and give me all my data back, I'm going to go do this thing." It's like, "Well, I don't know where it is. I'll just let it kind of dissipate, and then eventually die off." 

That understanding where you knew in your data centre, your big array, storage array –

[0:15:27] GUY PODJARNY: Or something database –

[0:15:29] RICK DOTEN: – that you could point to and it's like, "There's my data."

[0:15:31] GUY PODJARNY: Yes. Yes. Okay, interesting. It's a fair bit. It's like a lot of it – even with the sort of the simple motion of lifting, and shifting an application before you threw in elasticity, before you threw in infrastructure as code. Because any of the sort of the fancy stuff, there was already kind of a fair bit the changes need to do it, which in turn implies people changes, right? Like it implies cultural, like how you talk to a lot of these different organisations, and you see it within your org. 

I guess, what are your sort of likelihood of success if you try to kind of take the same team, and maybe the same backgrounds, and sort of skill sets, and try to adapt to them to the cloud? Is that your sort of path for success, or is it more likely for you to sort of go off and sort of hire different skill sets?

[0:16:16] RICK DOTEN: It can be. It really depends on the individuals. That's like, the variable is always the people. Have lots of discussions about workforce development and hiring in security. It's really about personality and aptitude. If you have people who want to move into the cloud, because they want to learn, they want to expand and continue to learn, they're going to be fine. If you have people, just redirected — I have a video that I did at RSA for the Cloud Security Alliance couple years ago, about cloud security and how this new thing, and how we address it is similar than going back 20 years or 25 years, when we moved from Novell to TCP/IP networking. Wireless networks came in, when I had worked as a security consultant or company, and had a lot of bank customers. When the bank ATMs, the automatic teller machines were all IBM OS to warp that end of life in 2005. 

Most of the ATMs moved to embedded XP. That was a cold little change of these people who were used to. Then finally, voice over IP with phones, which is at the bottom of the buildings, and now complex networking gear. Those changes were much drastic because if phone switch person is not going to be a Cisco network or an Asterisk network person. A person who understood OS to warp at the end of some connecting back to a mini-computer is not going to stand a finicky Windows endpoint and keeping up to date. So your career is overdoing that. Cloud, it can transition, because we're still talking about the same operating system, same concepts. There are just new ways of looking at it, new rules apply. Even though, I forgot to mention also the logging in the cloud. I'll be logging maybe to this cloud, but then are going to take it back somewhere else to the data centre, and which may cost me to move the data around, or if I go to another cloud environment because that's where my sim or my data log aggregation is. 

That's, again, another little piece that you just need to kind of figure out. But I think if you have the right people, it'll be fine, kind of ramp up, because it's very, very hard to find security people because everyone needs them, and everyone wants them. They're hard to find and they're hard to keep because they get poached.

[0:18:15] GUY PODJARNY: Yes, security industry as a whole, and then Cloud security kind of in particular is definitely sort of lacking for personnel. I think that's kind of a good definition of sort of initial cloud security. It sounds like, indeed, the competencies, a lot of these are things that you just need to learn to work in an environment. You might still run whatever, the Nessus, or whatever. You just might need to run it from within sort of your network.

[0:18:35] RICK DOTEN: Right. You install the agents on it and let it reply back, There's little things you have to do. Right. 

[0:18:39] GUY PODJARNY: Maybe let's kind of move up in time a bit and sort of talk about, okay, now you're running an application that is cloud-native or at least sufficiently kind of cloud adapted to doing it. So it's using some elasticity, or like even a fair bit of elasticity. And maybe there's some serverless kind of thrown in, and there's some Kubernetes clusters kind of floating around, some infrastructure as code. Maybe not everywhere. I mean, I think that's kind of a less, like more of a rarity. So you're kind of in that reality, or more mature on your cloud journey.

Let's say, you kind of gotten to sort of the basics of your sort of control. So you're not a master of that, you sort of have some levels. What is the sort of the level-up that you need or sort of the additional competencies you should pay attention to, as you kind of evolve that cloud activity. Specifically, like before, we talked about the sort of security hygiene. Are there new security controls that you should mostly focus on or is your focus should be on levelling up your security, hygiene to sort of that more sort of dynamic surrounding?

[0:19:35] RICK DOTEN: Yes. That's a much bigger leap. That's why it's good that you started with, okay, if I just forklift my applications up to be in the cloud instead of in a data centre, as opposed to cloud-native environments, like you said, containerised DevOps kind of – continuous CICD development. Because the cloud itself is an application, so when we talk about that pipeline extending, it's because the cloud is an application into the user. That's where things really, really – so it's like a jump from here to here what we just described, and now the jump from here to there. Because some traditional concepts no longer apply. 

The most basic one being, if you have temporary workloads, than if you have a policy that have an EDR running on all of your servers, it doesn't apply, because it's only up for two minutes. It's just overhead, and you're not going to see anything anyway, and there's no way to get anything out of it because it's an isolated workload that's doing its thing and going away. So you rely more on file integrity monitoring, or postural management tools to kind of make sure that your infrastructure is code scanning, and make sure that, "Okay. Do I trust this thing? If not, then I just wipe it out and I redo it until it gets trusted, or I do something else." So how you do it becomes different. 

Security operations become very different, because even though we talked about like a way that you're doing cloud security operations or even incident response. Now, when you have a bunch of temporary workloads that are going in there, sharing different things that are up for periods of time, and you're relaying a lot more on APIs, a lot more on configuration files for infrastructure as a code for people to call. You're relying on innumerable sources for the images to go through there. Then, your configuration management process needs a lot more scrutiny.

It's not much different than your standard code repo, where you're keeping track of your vary, but then, that comes into play that now we have different teams that are responsible for the innumerable sources as opposed to the code. Which opposed to the container, is opposed to the pasture management, it's opposed to the security management. So then, it's just a lot more complicated. There's so much more value and your efficiencies that you're bringing in, and you can do so much. But it now just gets exponentially more complex. Then, this is where the developers have more control as well, instead of just, here's my application. I'll give it to somebody who then installs it, and then kind of watches it. It's continuously going – the developers are getting further in because they may be doing infrastructure code. They may be having governance as code defined for them. 

Then finally, the remediation workflow is not as straightforward. Because if we go to a traditional virtual environment, something in the infrastructure. Well then, that goes to the infrastructure people to fix it, patch it, et cetera, or configuration change. But if it's an infrastructure as code thing, depending on your organisation, and where it is, or how it is in production because you have different policies for in production and development. Then it might be that, okay, this particular serverless environment was kind of defined by the infrastructure people. They use ServiceNow to be able to do their workflow for remediation. Where if it was an infrastructure code developed through the code chain, then they would go to Jira, and then they would go into their bug fix process for that. Or it might go to a Slack Channel because this is something that's more dynamic that the NCCD team is worrying about. 

The chain, if something goes wrong, or when you need to fix something may be different. So those are just some things that to me, I'm very excited about, because there's lots more opportunity to do things, but it just gets exponentially more complicated.

[0:23:08] GUY PODJARNY: Yes, I agree with the complexity. I guess with that, flexibility, I guess brings with it a lot of potential unexpected paths and a lot of opportunities to mess it up. But if I can take what you described, of all this sort of, I guess, dynamism and sort of maybe decentralisation, also, that sort of happens in different teams. It sounds like they're kind of two key buckets that oftentimes when you say DevSecOps, another sort of term that people kind of interpret to their heart's content. But if you say DevSecOps, then they're kind of these two interpretations, that are sort of the – what I would say is like the meta interpretation of bringing security into the DevOps fold. Which tends to sort of be maybe a bit more software-oriented, a bit more sort of inclusive of everything. 

Then there's the more operational, maybe coming more into the combination of the previous phase we talked about, which is just sort of managing this infrastructure in the cloud. And the ops side of what you've described now, it's sort of the security operations, knowing what happens. The machine is not up there when you're trying to sort of inspect if it's been compromised, all the different tails. I think kind of those two worlds, if I can sort of separate maybe the DevSecOps side from the sort of the remediation flow of it. I guess I'll repeat the question from before. For the ops side, are we talking same people? Is it like the same?

Granted, people can get totally retrained and be totally – what percentage overlap, would you say between the skills and kind of mindsets of the people in that sort of first bucket of a lifted and shifted cloud security team versus at least the ops side of the sort of more cloud-native world?

[0:24:44] RICK DOTEN: Right. Yes. It's certainly a lot more education and a lot more understanding of this dev technology. Also, it will vary depending on which cloud infrastructure you're on, as well, because what tools are variable to you, how logging works, how often they kind of change the logs without telling you about it, and what tools that your development teams are using. My favourite definition of DevSecOps is really just the automation of the security. Where I look at DevOps is automating an Agile, Scrum or XP process. Now, I'm automating that. Then if I do DevSecOps, I'm automating that security portion as well.

The process is still the same, but I'm trying to get more automation into because humans can't react that fast. But specifically to your question about the humans, it's definitely, it's an increasing in the skill level, and the understanding of the environment, and how that whole CICD pipeline works, and where they fit in. 

Because security people don't fix things. This is what I tell companies all the time, like, "This is great, but I am not at a lack of things to help me find problems. I'm at a lack of helping the people who are not me fix the problems." This even came from years of pen testing. We struggle with the IT department of our customers to convince them this really needs to be fixed and how to fix it.

When I look forward to, and the people who are developing it, and the people who are fixing it, whether it's the cloud side, the development side, the infrastructure side, they know how to do what needs to be done. They just need clear direction. "Oh, it's this code snippet. There's a syntax error. This needs to be corrected and this is where it needs to be corrected." If I know that, I can then automate it. My nirvana would be that – there's somebody had said that cloud security should be more like an airbag than a seatbelt, where you physically put on a seatbelt. Cloud security should be the airbag, like if it hits on me, it's going to pop up, and it's just there to protect you.

If I find in, really, when we get into this level, and high dynamic environment, as I said before, it's all about configuration management, and voluntary management fixing these things, or as they go along. And automating that to where, "Okay, here's an issue. Here's what needs to be fixed. This is the patch that needs go in." Here's the patch, here's the button to install it. I'm going to send it to ServiceNow or Jira," whichever one. For the human to say, "Yes." Approval workload, they press the button, it gets fixed. They press another button to back it out if there's a problem. That's what we need to get to because when organisation are doing dozens or hundreds of pushes a day, and something could go wrong, we can't have – they've automated that, we can't have a manual process for security operations.

[0:27:15] GUY PODJARNY: Security has to sort of adapt to the automation. I mean, that's a great – actually, when you think about sort of the automation, that's a great basically, probably the sort of the pillar of that evolution from lifted and shifted to – instead of the dynamic environment. In the sort of lifted and shifted environment, really, it's around adapting to it to being in the cloud. It's a lot of network changes, a lot of API entry points versus kind of maybe physical entry points. That was the evolution. The second one is, the pace is going to be high, you're not going to be able to keep up so it has to be automated. That in turn is a bigger leap for people. 

Let me ask you a question of like, we talk about this here, as though it's an evolution in practice for almost any enterprise and for many companies that are smaller. It's coexistence, the sort of the first bucket of applications that you're just operating, and the ones that you're building. They coexist. Again, we kind call them the same. Sorry. I kind of got stuck a little bit on naming here. At Snyk, we've been sort of toying a bit recently and in general, in these conversations, I've been sort of increasingly thinking about the sort of this world of IT cloud versus the app cloud sort of thinking, to an extent in the definitions you've just given, but sort of the first bucket is really more of the IT cloud and the practices around it are more IT like. Versus that sort of second bucket, the cloud-native apps, which really, it should be the app cloud. 

[0:28:37] RICK DOTEN: Yes, there should be more good distinction between the two. Yes.

[0:28:40] GUY PODJARNY: I guess, within that app cloud world, should it be – I mean, even in cloud-native companies, and to be frank, even at Snyk, we sort of – still cloud security is always this mirky thing about whether it is a part of the AppSec program, or whether it is a part of kind of more of the infrastructure, the IT security, sometimes enterprise security program. I even find that more often than I expected, it falls into the second bucket versus the former, even in high-growth startups and sort of scales. I mean, what do you think – does that match what you're seeing and what do you think is right? Should app cloud security be part of the AppSec program versus the IT security?

[0:29:18] RICK DOTEN: The standard answer is it depends. That's where I go back to what I said before, is like who has the most influence, who may have the most budget, who may have the most ability to make the change. In some organisations, the developer in a very large organisation that has thousand developers, they may be the bottom of the pile. And they could take their direction from the application architects or take it from the cloud architects, et cetera, and they have nothing. But if you are a small organisation that all you do is develop applications, then the developers are king, because they're making the business. Then, they have more influence on them.

It's certainly a best practice we're seeing, is certainly embedding or developing security champions within the development team, and the infrastructure team to be able to, be able to influence and mentor people in there. Because that goes back to, it's a team sport. Depending on how some smaller organisation may have a simpler time, because they may have two security people, a bunch of developers and some cloud architects. Then, it's kind of easy, because they all sit in the same room and it's like, "Jeff, you do this. Nancy, you do that, and et cetera."

Where a bigger company, which has 15 teams in describing all of that, then it's like, "Well, that's not my thing." Because that's one thing that I talk about a lot when talking to customers like, "Hey, I think your technology is great, but I don't know who would buy it." Because it's used by these five different teams, and all of them would say, "I'm not paying for it if that's this thing. Well, I'm not paying if that's the thing." I mean, every large company kind of has this. It's never a lack of money, it's like who's willing to pay for it. The challenge is, and that's why I say it go back to it depends. Your industry, whether you're highly regulated or not, whether you are a small organisation, your size, your location, whether it's a more of a privacy-based thing. In which case, if your company has a lot of privacy issues or regulatory issues, then security may have a governance risk compliance thing that may be more influential. Because we just need to make sure we check all the boxes so we can still support our customers and be compliant, as opposed to ones who aren't. Then just like, we just need to get things done, and do good work, and make sure that we're taking our customers, give them the features that they need.

[0:31:21] GUY PODJARNY: I mean, I think it's the correct answer, and there are a lot of great examples here and around. You're right, that it depends, like different settings lead you to a different reality. I guess, though, sort of related sort of challenge on that would be, should it really be the same team? Should we have one cloud? It feels a little bit like, you have an organisation, let's call it a 50-50 split between applications you sort of operate and applications you build.

If you lean one way or the other, wouldn't it – like that team naturally be kind of mediocre at best on the other front versus the former. Should we have two distinct cloud security teams, one focusing on bucket one, and the other on sort of one on IT cloud and one on the app cloud? Should we have different sets of tools? Why are we joining them?

[0:32:09] RICK DOTEN: Yes. No, I think that's a good point. I would say, "Yes. Because if nothing else, yes, they're different tools. Yes, they're different people, they're understanding. If you're small enough, you may have someone who can understand the one. If you understand one, you understand the other. That's where I kind of go back to – this really depends on how big you are, and how many resources you have to be able to split them up. Because many organisations. I mean, I've seen twice this statistic and that in the US, the number of corporations with less than 500 people are of 99.9% of all the number of corporations. 

We're talking about like the fortune 500, and then three million other companies, right? Oftentimes, in our industry, we kind of cater to the bigger companies that have resources, have money and can buy things. But we still have to address that 99% who don't. How do we make something that would be accessible to them realising they have a lack of resources, lack of talent, or lack of money to be able to support the tools. That goes back to the fundamental that if you have good people, you don't need a lot of money, you don't need a lot of technology. Because they're going to figure out how to do it, and they can script things out, and automate things. Really, I would kind of go to the education, and the development of those resources to make them understand it more fully. We're all still maturing together in that.

You have some of the really big providers who've like have a 15-year headstart of everybody else, you know, Facebook, and Microsoft, and Google, and Amazon, et cetera. But outside of those four, you have the rest of the world who is still kind of catching up to get to their level.

[0:33:45] GUY PODJARNY: It's a good point, though. If you look at analogies in what happened in the industry, then what happens is, they get embedded into software development with DevOps. They look at the QA. Initially, everything has to go through QA, then QA was for some applications, and some of them had developers. Even actually, it's still exists, but it's less common, the dev QA, sort of like QA, but it's automation oriented. Then eventually, today, in the cloud-native company, tends to not be any QA people. Quality is a responsibility of the development team. 

Ops is a little bit similar, increasingly. At the beginning, there is no ops person, and then eventually, there's an ops person, and they kind of cater to some aspects. A lot of the others are responsibility of the developer. Security can maybe goes there. Maybe I'm slipping us into sort of the third bucket like, where do you think we're headed? If you imagine answering these questions in – I want to sort of give it a far enough, but practical, like five years' time in sort of doing it. What would you say is the reality, then what should the cloud security practice and ownership look like?

[0:34:45] RICK DOTEN: Certainly, there'll be a lot more automation. I mean, I think that your description was a very good one, and a very realistic one for what could happen as we get more understanding than we expect more from the people because they now understand it. The challenge is that – and you know better than I do. Developers are not taught security. We have to kind of impose it on them. When they pick it up, they're great, and they figure out stuff we didn't even think about. It was like, "Wow, this is really interesting things."

But I think that building security into developers, and also educating security into developers more commonly, and more early on, and educating the cloud architecture elements early on, that give them understanding. Because now they have or they may have responsibility for infrastructure of code, and spinning up different things in different ways that they didn't have in traditional development. I think that there is an empowering of the developers, but what do we expect them. Because some people just want to do the one thing that they understand, because security people are different personality type than developers. You have developers who can cross over and with exception. But traditionally, there's one group of people who like to follow guide rails, understand syntax, and do something, and solve problems. And others who have no structure, you figure it out. It hasn't been done before, so you're the one who have to understand. You have to come up with a solution to it. Those two personalities are not the same. Obviously, there's exceptions where they crossover.

I think the short answer is, like I said, automation. Maybe this is where — and I always like cringe when vendors talk about machine learning and AI. Because my first question is like, how are you vetting that because AI is biased and AI –

[0:36:19] GUY PODJARNY: It will generate something, but –

[0:36:21] RICK DOTEN: There's a whole, when talking to my peers, and organisation who are really doing AI, they spend as much on the QA of that AI to make sure the provenance is good and it's not biased towards something that's not going to give bad information. Taking that off the table, I think there is a play, because fundamentally, machines do things in a rapid sequence very accurately. And humans are slow, messy and prone to mistakes. When we start automating, there's some things – when I was in a CI SO ten years ago, I had a guy who was a developer. We would do some response first, and then he would all script it out. It was like, "Okay. Well, I don't have to go to these three machines, and pull these logs. I will just script out if this happens, I will pull these, make a ticket and send it to the human."

Let the humans do the things we're good at, which is ambiguous data, understanding complex concepts, understanding things that aren't necessarily in the view of the circumstance, business reasons and things like that. But let the machines do the stuff that they can do very well. It's like, "Okay. If this particular workload comes up, and it doesn't seem to be trusted, just take it down, spin up another one. If that's still down, then let's look at this store, so let's go look at this thing. Let's fix this, let's update the configuration, send it to it, and then send a ticket to say, I did all this stuff, and if you didn't like it, you can back it out." Really heavy, heavy automation to support the humans in that effort. Because as we're getting more and more into DevOps and DevSecOps, we got to step back and just be there when it all goes wrong as a human.

[0:37:46] GUY PODJARNY: Yes, and just sort of be open. I wonder, like the word that jumps to mind before we talked about kind of the adaptation to the cloud. Then secondly, the sort of the automation, whether that's sort of future phase is a combination on simplification. AI being kind of a big part of it, like make it easier. Because developers – not everybody might have the security knowledge or aptitude, so you need to kind of make it easier and maybe embedding. Embedding it into sort of the regular practices to doing it. So that the person getting that sort of prompt, or that issue, or that problem isn't the security person that needs to route to a developer, but rather it goes directly to the person at hand. Is that reasonable?

[0:38:24] RICK DOTEN: Yes. One of my best descriptions that somebody had said – I forget that website, whatever AI GTP, or whatever.

[0:38:29] GUY PODJARNY: Yes, ChatGPT.

[0:38:30] RICK DOTEN: Yes. The thing that is replacing is interns. The things that are very simple tasks that are done and repeatedly, let the machines do that. I think if that's what you're saying is like – and someone years ago, a guy told me a story. I'm not a chess player. They said the question of like, "Which is better? The machine or the human in playing chess?" The question is, what's the best chess player? It's a human with the machine, because machines will make this –  this is a really good move, a really bad move, but it's not good at the ambiguous ones in the middle, which humans are really, really good at.

I think that humans leveraging kind of these types of automation along with what they're doing to make them more effective and efficient, but then still falling back on them for the things that only humans can figure out.

[0:38:30] GUY PODJARNY: Right. Yes. It's almost more like offloading. It's more about, take it off my hands, either move to the platform, move it to an AI logic, move it to somewhere else, so I don’t have to worry about it. Then you narrow the sort of the slice of it.

[0:39:23] RICK DOTEN: Right. And frees them up to focus on the things that only they can do, like figure out how to make some feature and functionality work. Because all the heavy lifting, and all the grunge work they would normally have to do is already taken care of for them. Same thing for security operations, same thing for configuration management, same thing for vulnerability management.

[0:39:40] GUY PODJARNY: Right. It sort of applies to the different – yes, well, it sounds like we figured it out. Okay. So we have like a journey for the super interesting – I think like a great journey. Thanks for some of the insights here, and you talked about, just kind of to recap. Sort of starting from the definition, the somewhat over-encompassing kind of definition of cloud security that includes a lot of things. Talk about your journey, maybe starting, or at least the simplest part of it is just the cloud adaptation for applications you operate. Because you've lifted, and shifted, or you just purchased them. 

Continuing to cloud-native applications that require a bigger leap sort of as individuals and humans because they move you into automation land. Naturally requiring different mindset, different sort of maybe coding skills, or at least scripting skills, the likes. Then evolving into use of more kind of elaborate infrastructure and AI, and deeper workflows so you can offload more work, and embedded more sort of into people's day-to-day lives. Then if you have all of that, then you can have cloud security nailed. Does that sound about right?

[0:40:39] RICK DOTEN: Yes, it sounds good on paper. The application of it is the hard part. It's kind of like –

[0:40:43] GUY PODJARNY: It's not easy to do. 

[0:40:44] RICK DOTEN: Gary Larson cartoon, where it's like, here's this calculation, then a miracle happens, and then here's the answer.

[0:40:51] GUY PODJARNY: That's a good sort of tone to praise this. Rick, this has been excellent. Thanks a lot for coming onto the show. 

[0:40:55] RICK DOTEN: Oh, thank you. My pleasure. Love talking about this. 

[0:40:58] GUY PODJARNY: Thanks, everybody for tuning in. I hope you join us for the next one.

[END OF EPISODE]

[0:41:06] 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]